Microsoft 365 管理センターのメッセージセンターを確認していたところ、以前に下記の投稿で紹介した手法が 2021 年 12 月 17 日で利用できなくなるようでした。どうやら、これまで利用できていた manage.office.com のエンドポイントが停止するようですね。
Microsoft Flow で Office 365 の障害情報をチェックする
https://idea.tostring.jp/?p=4732
というわけで、さっそく Microsoft Graph API に作り替えてみようと思います。
Azure AD にアプリを登録
Microsoft Graph API で必要な権限は「ServiceHealth.Read.All」です。「アプリケーションの許可」で登録しておきましょう。
| アクセス許可の種類 | アクセス許可 |
|---|---|
| アプリケーションの許可 | ServiceHealth.Read.All（管理者の同意が必要） |
今回の権限は「管理者の同意が必要」ですので、登録したアプリの [API のアクセス許可] から、[管理者の同意を与えます] をクリックしておきましょう。また、いつものように [証明書とシークレット] から [新しいクライアント シークレット] で「クライアント シークレット」を生成してメモしておくと良いでしょう。
そのほか、[概要] から「アプリケーション（クライアント）ID」と「ディレクトリ（テナント）ID」を確認してメモしておきましょう。
HTTP アクションを設定する
以前と同様に、今回も HTTP アクションを利用します。HTTP アクションは PREMIUM アクションとなるため、有償の課金プランが必要です。
指定する URI は次の通りです。このエンドポイントからは、障害情報のみが返ってくるようです。
Get serviceHealthIssue – Microsoft Graph v1.0 | Microsoft Docs
https://docs.microsoft.com/en-us/graph/api/servicehealthissue-get
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues
単純に取得してしまうと件数が多いため、直近の情報のみを取得できるように $filter クエリを設定しておきましょう。「$filter」のクエリを追加し、次のような値を入れておきます。これで、実行時点から過去 3 時間以内の更新情報を取得することができます。
lastModifiedDateTime gt @{addHours(utcNow(),-3)}
ここまでで HTTP アクションは次のように設定されます。
あとは、先ほどの Azure AD に登録したアプリの情報を設定しましょう。
| HTTP アクションの設定項目 | 設定値 |
|---|---|
| 認証 | 「Active Directory OAuth」を選択 |
| テナント | Azure AD のディレクトリ（テナント）ID |
| 対象ユーザー | https://graph.microsoft.com |
| クライアント ID | Azure AD のアプリケーション（クライアント）ID |
| 資格情報の種類 | 「シークレット」を選択 |
| シークレット | Azure AD のクライアント シークレット |
戻り値は JSON なので、次は JSON の解析を行いましょう。
戻り値 JSON の解析
テスト実行してみた結果から得られた戻り値の JSON を元に解析用のスキーマーを作成します。
{
"type": "object",
"properties": {
"@@odata.context": {
"type": "string"
},
"value": {
"type": "array",
"items": {
"type": "object",
"properties": {
"startDateTime": {
"type": "string"
},
"endDateTime": {
"type": [
"string",
"null"
]
},
"lastModifiedDateTime": {
"type": "string"
},
"title": {
"type": "string"
},
"id": {
"type": "string"
},
"impactDescription": {
"type": "string"
},
"classification": {
"type": "string"
},
"origin": {
"type": "string"
},
"status": {
"type": "string"
},
"service": {
"type": "string"
},
"feature": {
"type": "string"
},
"featureGroup": {
"type": "string"
},
"isResolved": {
"type": "boolean"
},
"highImpact": {
"type": [
"string",
"null"
]
},
"details": {
"type": "array"
},
"posts": {
"type": "array",
"items": {
"type": "object",
"properties": {
"createdDateTime": {
"type": "string"
},
"postType": {
"type": "string"
},
"description": {
"type": "object",
"properties": {
"contentType": {
"type": "string"
},
"content": {
"type": "string"
}
}
}
},
"required": [
"createdDateTime",
"postType",
"description"
]
}
}
},
"required": [
"startDateTime",
"endDateTime",
"lastModifiedDateTime",
"title",
"id",
"impactDescription",
"classification",
"origin",
"status",
"service",
"feature",
"featureGroup",
"isResolved",
"highImpact",
"details",
"posts"
]
}
}
}
}
2 点だけ手直ししている箇所があり、endDataTime と highImpact は null が返ってくることがあるようなので、それでも動くように書き換えています。他はおそらく大丈夫かと思いますが、動かしながら様子を見て、必要があれば手直しをしていく感じにしようと思います。
フローの全体
というわけで、今回作成したフローの全体はこのようになりました。3 時間おきに過去 3 時間分の更新情報を取得し、Twitter に投稿するという感じです。
実行間隔やデータの連携先などは、要件に合わせて変更しましょう。また、今回利用した情報以外にも多くの情報が得られるようでした。
動作を確認
手動実行してみたところ、まずは動くことを確認できました。あとは、時間をおいて様子を伺いながらエラーなどを確認していきたいと思います。
さいごに
こうした API の停止などは、フローを作ってから忘れたころにやってきますね。今回のフローについては作成したのが 2019 年ですから約 2 年前でした。また、利用していた API が Preview 版だったということもあり、早くの停止だったという感じですね。
API の動作などを確認し直す必要はありましたが、今回は修正の手間もほとんどかからずに改修を終えられてホッとしました。
この API を利用した連携は、なかなか重宝していたんですよね。
