みなさん、こんにちは。

今回は、モノのインターネット（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 は、この 2 種類が統合された新しいデータベースサービスです。利用者にとって 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 にケースを作成する。を実装します。

まとめ

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

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

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

みなさん、こんにちは。

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

膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 概要

事前準備

大まかな手順は 5 つです。Azure のサブスクリプションが必要になります。お持ち出ない方は、評価版を申し込みください。

- Azure Cosmos DB アカウントの作成
- サンプルデータの登録
- Azure Cosmos DB コネクタの構築
- Dynamics 365 Online の作成
- Azure Logic Apps の作成

Azure Cosmos DB アカウントの作成

1. Azure ポータルにログインします。

2. [新規] > “Azure Cosmos DB” を検索します。

3. 作成ボタンをクリックします。

4. 必須項目を入力します。

API では NoSQL である MongoDB なども選択できます。

Geo 冗長の有効化をチェックすることでグローバル配布機能が有効化されます。

5. [作成] ボタンをクリックします。

6. 完了すると自動的に作成した Azure Cosmos DB アカウントが開かれます。

以上でアカウントの作成は完了です。

サンプルデータの登録

続いて、サンプルデータを登録していきます。今回は、正常と異常のセンサーデータを登録します。

1. [データエクスプローラー] メニューを開きます。

2. [New Colllection] をクリックします。

3. DatabaseID, Collection ID に任意の名前を付けます。

4. Strage capacity は、今回は評価用のため、Fixed にします。スループットも既定のままにします。

Fixed (10 GB) の画面

Unlimited の画面

Unlimited にすると、Partition Key を指定できるようになります。Azure Cosmos DB は、世界規模で分散配置されるマルチモデルのデータベース サービスです。Partition Key は、データを論理的なグループに分けることで、分散配置されたデータにも高速にアクセスできるようになります。詳細はこちらを参照ください。

https://docs.microsoft.com/ja-jp/azure/cosmos-db/partition-data

また、スループットの最大値を 100,000 まで上げることができます。

※最大値を上げるとコストが増えます。事前に十分にお見積もりください。

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

5. 作成されます。

6. 正常データを登録します。Documents をクリックします。

6. [New Document] をクリックします。

7. データを登録する画面が表示されます。

8. “id” は行キーのため、ユニークな値にしました。また、センサーデータの状態として ”status” を追加します。

9. [Save] します。

10. “sensor_1” というデータが登録できたことがわかります。

11. 続けてデータを登録します。そのうち 1 件は、status: NG のものを登録します。

以上でサンプルデータの登録は完了です。

データの確認

登録したデータから異常なデータをクエリしてみましょう。

1. [New SQL Query] をクリックします。

2. クエリ画面が表示されます。

3. そのまま [Excute Query] をクリックします。すべてのデータが表示されます。
なお、”_rid” などの項目は、自動的に生成されるものです。

4. 続いて、異常なデータのみ抽出するクエリを実行してみます。

[status が “NG” と等しい ]

[status が “NG” と等しくない ]

クエリの構文については以下を参照ください。

https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql-query#WhereClause

まとめ

今回は、Azure Cosmos DB の準備を紹介しました。記事で深く触れなかったパーティション分割は別の機会に試したいと思います。次回は、Dynamics 365 Online および Logic Apps を準備していきます。

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

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

みなさん、こんにちは。

前回に続き、膨大なセンサーデータから自動で異常を検知して 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 が設定されています。

以上です。

まとめ

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

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

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

みなさん、こんにちは。

前回に続き、膨大なセンサーデータから自動で異常を検知して 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 Customer Engagement (旧 Dynamics CRM) オンラインをご利用のお客様に関わる重要なお知らせをお伝えする記事が Microsoft Dynamics ブログ に公開されましたので、本 Blog でもご紹介いたします。こちらは特に、現在 バージョン 8.2 をご利用のお客様にとって重要な変更となります。

Title : Dynamics 365 のアップデート方法を刷新
URL : https://community.dynamics.com/b/dynamicsblog-ja-jp/archive/2018/07/11/modernizing-the-way-we-update-dynamics-365

■重要な変更点

上記記事の [すべてのユーザーが 1 つの最新バージョンを利用] セクションにございます通り、全てのお客様は、最新のバージョンをご利用いただく必要があります。

従来は最新バージョン (現行 9.x)、一つ前のバージョン (同 8.2)、二つ前のバージョン (同 8.1)のご利用が可能でしたが、
バージョン 8.1 をご利用のお客様は、既に通知が行われております通り、2 月から 7 月 31 日 の期間内に最新バージョンへの更新が必要です。
バージョン 8.2 をご利用のお客様は、2019 年 1 月 31 日までに最新バージョンに更新していただく必要があります。

更新をスケジュールする方法については、こちらをご参照ください。

■影響を受けるお客様

現在 バージョン 8.2  をご利用のお客様は、本ポリシー変更の影響を受けます。

バージョン 8.2  をご利用のお客様は、従来のポリシーであれば、次期メジャー アップデートまで更新をスキップできますが、この変更により、2019 年 1 月 31 日までに最新バージョンへの更新が必要となります。

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

みなさん、こんにちは。

Microsoft Office 365 Service Communications API を使用した Dynamics 365 Customer Engagement (CE) のサービス監視について紹介します。最初に本記事で概要を説明します。弊社が提供しているブログ Dynamics 365 Customer Engagement in the Field の記事を翻訳したものです。次回以降で実際に評価環境で試していきます。

情報元: Monitoring Dynamics 365 CE service health and messages using the Microsoft Office 365 Service Communications API

====================================================

最近、Microsoft Dynamics 365 CE サービスの正常性を監視するオプションについて、お客様と会話をしました。具体的な要望は、Office 365 管理センターより提供されているサービス正常性の表示よりもより高い可視性が必要とのことでした。これにより Dynamics 365 サービス管理者は便利にサービスの正常性を確認できます。しかし、場合によっては、利用者がこれらのメッセージにアクセスするために Office 365 内で適切な役割を持たないため、実際は管理者に依存するようになることがあります。

そこで Office 365 Service Communications API を見つけました。 これを確認すると、独自の認証メカニズム、サービス契約などを持つ 2 つの別個のエンドポイントがあり、Office 365 Service Communications API と Office 365 Service Communications API (プレビュー) が作成されました。両方の API を利用して得たものは、Office 365 サービス管理者 または認証のために（AOBO）の代理として動作するパートナー役割と、OAuth を使用するパートナーロールが必要です。 つまり、Office 365 にログインするのと同様のユーザー名とパスワードを使用する、もう一方は、Client ID と Client Secret を使用します。 これをあなたのアプリケーションセキュリティチームと議論して、どのオプションが適切か判断してください。ただし、元の API リファレンスで推奨されている OAuth のプレビューエンドポイントをお勧めします。

以下の記事では、アプリケーションを Azure Active Directory に登録するのに必要な手順を詳述しています。

https://msdn.microsoft.com/en-us/office-365/get-started-with-office-365-management-apis

利用可能なデータとイベントに関しては、2 つのバージョンの API では大きな違いは見られないため、ここから プレビュー API について説明します。元の API に興味がある場合は、サンプルMVCアプリケーションを参考にしてください。

認証トークンを取得すると、Office 365 Service Communications API (プレビュー) への任意の要求に追加できるようになりました。 API は、テナント識別子 (テナント GUID またはテナント名、たとえば contoso.onmicrosoft.com) と希望の操作を取るようにフォーマットされています。

https://manage.office.com/api/v1.0/{tenant_identifier}/ServiceComms/{operation}

私が作成した評価用テナントに対するリクエストのサンプルは次のとおりです。

Request:

GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Services

Authorization: Bearer <authorization bearer token>

Host: manage.office.com

上記の通りリクエストは、認証ヘッダーと正しい URL で簡単に GET ることができます。 上記により Office 365 テナント内のすべての Office 365 アプリケーションの現在のサービスを提供します。 この記事は Dynamics 365 CE に焦点を当てます。Dynamics 365 のステータスのみ取得するため CurrentStatus API コールにフィルタを追加してみましょう。(太字)

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"

}

]

}

このレスポンスオブジェクトを確認します。FeatureServiceStatusDisplayName プロパティを参照してください。Dynamics 365 の現在のステータス (Status) と、サインイン(Sign In)、組織アクセス(Organization access)、コンポーネント/機能(Components/Features)などの機能を確認できます。 このレスポンスでは、Dynamics 365 の現在のステータスが “Service Restored” であり、影響を受ける特定の機能が「コンポーネント/機能」であることがわかります。

続いて過去機能がどれくらいの間影響を受けていたかを得るには、以下のように HistoricalStatus を使用できます。

Request:

GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/HistoricalStatus?$filter=Workload%20eq%20'DynamicsCRM'

Authorization: Bearer <authorization bearer token>

応答の全文は膨大なため割愛しますが、応答の中では、メッセージセンターの識別子を含む一定期間にわたる Dynamics 365 の機能のステータスを得ることができます 。

最後に、現在の停止しているサービス、および計画されているメンテナンスのメッセージを確認できる GetMessages を紹介します。GetMessages は、タイトル、説明、メッセージテキスト、影響日、影響を受けたテナント、メッセージIDなどを返します。このメソッドは、多くの点で非常に有益です。現在の停止しているサービスの確認、計画されたメンテナンスのメッセージの確認できます。メッセージはフィルターできます（メッセージ識別子、特徴、関心領域、時間枠など）。

特定の条件でフィルタリングするためのサンプルリクエストのリファレンスを次に示します。

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 CE の現在のステータスとその機能、潜在的な劣化がテナントに与える影響の情報、アプリケーションで実行される計画的な更新とメンテナンスの計画に関する情報を提供する API があります。 API を使用するようにワークフローをスケジュールする方法と、Microsoft Flow を使用して現在のステータスとメッセージを単一のユーザーまたは配布リストに報告する電子メールを送信する方法を詳しく説明する次のブログ記事を先読みしましょう！

References:

Get started with Office 365 Management APIs

About Office 365 Admin Roles

Office 365 Service Communications API Overview

Office 365 Service Communications API Sample Code

Office 365 Service Communications API Overview (preview)

Thanks and happy coding!

Ali Youssefi

====================================================

まとめ

Office 365 Service Communications API を利用すると Office 365 テナント内にあるサービスの正常性を取得できます。
次回は、実際の評価環境を利用して Dynamics 365 CE のサービス正常性を取得してみましょう。お楽しみに。

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

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

みなさん、こんにちは。

前回に続き、Office 365 Service Communications API を使って Dynamics 365 CE のサービス監視を試してみます。
まだ前回の記事をご覧になっていない方は一読ください。

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

Office 365 管理センターの正常性

Office 365 の管理センターにてテナントに含まれるサービスの正常性を確認することができます。

正常性メニュー配下に 2 つのメニューがあり、主に以下の情報が確認できます。

- サービス正常性（現在の状態、過去の状態）
- メッセージセンター（予定されているメンテナンス情報）

早速 Office 365 Service Communications API で取得してみます。

事前準備

最初に Office 365 Service Communications API を呼び出すクライアントアプリを決めます。
プログラムを書いてもいいですが素早く検証するため OAuth2.0 に対応した PostMan というツールを利用します。
アプリが決まったら、取得先の Office 365 テナントの Azure AD にアプリを登録します。

以下は PostMan を使用した例です。

1. Office 365 管理センターにログインします。

2. [管理センター] > [Azure Active Directory] をクリックします。

3. Azure Active Directory 管理センターが開かれます。[Azure Active Directory] > [アプリの登録] をクリックします、

4. [新しいアプリケーションの登録] をクリックします。

5. 名前、アプリケーションの種類、サインオン URL を入力し、[作成] をクリックします。

今回は PostMan を利用するため以下になります。

サインオン URL : https://www.getpostman.com/oauth2/callback

6. アプリの画面が開かれます。アプリケーション ID の値をコピーし、メモ帳に貼ります。

これがクライアントで利用する Client ID になります。

7. [設定] をクリックします。

8. [必要なアクセス許可] をクリックします。

9. [追加] > [APIの選択] で “Office 365 Management APIs” をクリックし [選択] をクリックします。

10. 続いてアクセス許可を 2 つ選択し、[保存] します。

11. [設定] メニューに戻り、[キー] をクリックします。

12. 説明と有効期限を設定し、[保存] をクリックします。

12. 保存した直後のみ値が表示されます。値をコピーしメモ帳に保持します。

画面が切り替わると値が非表示になるため注意してください。

これがクライアントで利用する Client Secret になります。

以上で事前準備は完了です。

まとめ

今回は APi を利用するため Office 365 テナントにアプリを登録しました。次回は、実際にサービス正常性を取得してみましょう。

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

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

みなさん、こんにちは。

前回は、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 で取得できることがわかりました。
次回は、今後のメンテナンス情報などのメッセージセンターの情報を取得してみます。お楽しみ。

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

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

みなさん、こんにちは。

前回は、Office 365 から Dynamics 365 サービスの正常性を取得しました。今回は、現在予定されているメンテナンス情報を取得してみます。
まだ前回の記事をご覧になっていない方は一読ください。

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

メンテナンス情報

Office 365 管理センターには前回取得したサービスメンテナンス情報のほかに、今後計画されているメンテナンス情報が表示されています。今回はこの情報を API で取得してみたいと思います。

- メッセージセンターの情報を取得
- 特定のメッセージを取得

[Office 365 管理センターのメッセージセンター]

メッセージセンターの情報を取得

最初に、すべてのメンテナンス情報を取得してみましょう。メンテナンス情報は、メッセージセンターから取得できます。

1. URL に以下を入力します。

https://manage.office.com/api/v1.0/<テナント名>.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'MessageCenter'

2. [Send] をクリックします。

3. メッセージセンターの情報を取得できたことを確認します。

この画像の場合、54 個の取得できました。1件目は、MC120728 We're removing Visio Web Access from SharePoint Online というメンテナンス情報です。

Office 365 管理センターで確認すると確かに 54 件のメンテナンス情報が確認できます。また、1 件目の MC120728 We're removing Visio Web Access from SharePoint Online は一番下に表示されていました。つまり、API では、古い順に取得され、管理センターでは、新しい順に表示されています。

特定のメッセージを取得

次にメッセージセンターの情報から特定のメッセージのみ取得してみましょう。メッセージは、’MC’ で始まるものです。

1. URL を入力します。Send をクリックします。

https://manage.office.com/api/v1.0/<テナント名>.onmicrosoft.com/ServiceComms/Messages?$filter=Id%20eq%20'MC147927'

2. 1 件だけ取得できたことがわかります。

なお、’IsMajorChange’ が ‘true’ のものが管理センターの上部に表示されるメジャーアップデートのメッセージのようです。

まとめ

いかがだったでしょうか。Office 365 Communication API を利用すれば、Office 365 管理センターの正常性やンテナンス情報を取得できることがお判りいただけたと思います。現在はプレビューという位置づけで、例えば、メッセージセンターの情報をさらに ‘DynamicsCRM’ のみでフィルターしたいといったことは、今後の機能強化で期待したいと思います。ぜひお試しください！

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

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