（Power Automate）Plannerに登録したタスクの期限が近い場合に通知するフローを作成する
現在、私が所属しているチームではタスク管理ツールにMicrosoft Plannerを使用しています。 単純な親子関係のないタスクであれば簡単に管理できて、チェックリストや期限の設定もでき、進捗状況や割当状態をグラフやカレンダーで可視化することができます。 また、Web会議は Teams を主に使用していることもあり、連携するならこれが今の所ベストな選択肢となっています。 感覚的には Trello と同じように使えるのもポイントです。
しかし、Planner そのものに期限を通知するための仕組みはありません。 そのため、業務で利用する際に「遅延しているタスク」がモリモリ増えていって、このままではタスク管理している意味がない！と思い、Power Automate で毎日通知するようにしました。
今回はその方法についてまとめておきます。
環境
- Power Automate
- Planner
- チャットツール
チャットツールは何でも良いです。Slack や Teams ならコネクタがあるのでそちらを使いましょう。 弊社では Chatwork を使っていたのでカスタムコネクタを作ってメッセージを送るようにしました。
今回は Power Automate がメインで、カスタムコネクタや Planner についての話はしません。
やりたいこと
やりたいことは以下の３つです。
- 当日が期限のタスク一覧を通知する
- その週が期限のタスク一覧を通知する
- 遅延しているタスク一覧を通知する
実際のところ、この３つは通知が必要なタスクかどうかの判断以外はすべて同じなので１つだけ説明して、他は差分箇所のみ紹介します。 そしてこれを実行すると以下のようなメッセージが表示されます。
通知するメッセージには以下の情報を記載します。
- 期限
- タスクタイトル
- 割り当てられた担当者の名前
フローを作成する
フローは次のような構成になっています。 全体のざっくりとした流れはスケジュール実行→Plannerからタスク取得→通知用メッセージ初期化→条件に一致するタスクを収集・メッセージの整形→チャットに送信となっています。 詳細は番号にそって説明します。
1. スケジュールの設定
説明するまでもないですね。通知したい時間を設定します。 タスクの通知なので、できれば朝一番か業務開始直前とかが良いと思います。
2. タスクを一覧表示します
Planner から該当するグループ・プランのタスクを収集します。 こちらも説明は不要ですね。 取得したいグループ・プランIDを指定するだけです。
3. 変数を初期化する／4. 変数を初期化する 2
今回、変数は２つ用意しました。 １つは期限であるタスク一覧を通知するためのメッセージで、もう１つは実際に通知するメッセージです。 参考までに今回は以下のように設定しました。
③期限であるタスク一覧を通知するためのメッセージ
・名前：task_list
・種類：文字列
・値：（何も設定しない）
④実際に通知するメッセージ
・名前：chatwork_send_message
・種類：文字列
・値：（何も設定しない）
なぜこんな回りくどいやり方をするかと言うと、今日が期限のタスクが０件の場合にどう通知するかを考慮したためです。
今日が期限のタスクが０件の場合、通知された側としては何が表示されていればいいでしょうか？ 今回のケースでは「今日が期限のタスクは０件です。」と通知するようにしました。
仮に、「通知しない」という選択をした場合、フローが動いているのかどうか通知を見た側はわかりません。 そうなるとフローが間違っているのか期限になるタスクが無いのか判断できません。 そうなるよりは通知は増えますが、「０件です」と表現したほうがわかりやすいと思います。 （チームによってどう通知するべきかは変わるのでここは調整してください）
この要件を満たしたいので、「3. 変数を初期化する」に期限が今日であるタスク一覧の通知用メッセージを代入し、「4. 変数を初期化する 2」に実際に通知するメッセージを代入します。
5. タスク一覧を収集してメッセージを整形する
ここが一番のメインです。収集したタスクを条件に一致するかどうか判断し、一致する場合はメッセージを作成します。 収集するタスクは複数あるのでループで処理していきます。 更に詳しく見ていきます。
ポイントは２つ。「a. 通知すべきタスクかどうかを判断する」の条件と「b. 割当先ユーザーごとにメッセージを整形する」のメッセージ整形部分です。
a.通知すべきタスクかどうかを判断する
ここでは、「今日が期限のタスクかどうか」を判断します。 条件式には次のものを設定しています。
- ＜empty(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime'])＞次の値に等しい＜false＞
Planner では期限dueDateTimeは空欄でも許容されます。空欄の場合はこれ以降の条件式で比較した場合、エラーになるためこの条件を先頭に持ってきています。 - ＜値 達成率＞次の値未満＜100＞
Planner の達成率は数値で表現され、範囲は 0 ～ 100 となっています。100 だと達成してしまうため、100 未満としています。 - ＜ticks(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime']) ＞次の値以上＜ticks(addDays(utcNow(), 0))＞
期限が UTC の現在日時以降かどうかを判断しています。わざわざaddDaysで 0 日を加算しているのは、この後の条件式と比較しやすいためです。 また、判定する期間を変える場合（例えば今週期限のタスクを収集するといったケース）、0 の部分を変更するだけでいいので少し楽できます。 - ＜ticks(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime'])＞次の値未満＜ticks(addDays(utcNow(), 1))＞
期限が UTC の現在日付＋１日以前かどうかを判断しています。上の条件と組み合わせて"今日"という条件を作り出しています。
b.割当先ユーザーごとにメッセージを整形する
条件に一致したタスクを収集できたら次はメッセージの整形です。 Planner では、１つのタスクに対して複数ユーザーを割り当てることができます。 通知するのであればタスクに割り当てられた全員に通知するべきです。
通知メッセージの内容は要件次第ですが、今回は１つのタスクに複数ユーザーが割り当てられた場合、ユーザーごとに１行メッセージを追加していくことにしています。
「割当先ユーザーごとにメッセージを整形する」がループになっているのはそのためです。
このループでは割り当て先ユーザーIDを値としています。
実は、Planner でタスクを収集しても割り当てられたユーザー名は取得できません。
そこで、ユーザーIDを使います。
このユーザーIDは、Microsoft 365 の ID に紐付けられています。 なので、Microsoft 365 の「ユーザー プロフィールの取得（V2）」を選択し、"ユーザー（UPN）"に Planner から取得したユーザーID を指定してやればOKです。
そうすればメッセージの整形に取得したユーザーの表示名を使用することができます。
6. 期限が今日のタスクがあるか判定する
ここまでで、期限が条件に一致するタスクを通知するためのメッセージを作っているので、そのメッセージが空であれば「タスクが無いことを通知する」。そうでなければ「条件に一致したタスク情報一覧を通知する」ようにしています。
条件式は、具体的には以下のような式になっています。
empty(variables('task_list'))
task_listは「③期限であるタスク一覧を通知するためのメッセージ」が入っています。
この値が空である（empty(variables('task_list'))がtrueである）ということは「今日が期限のタスクが１つも無い」ということになります。
逆にこの値に何か入っている（empty(variables('task_list'))がfalseである）ということは「今日が期限のタスクが少なくとも１つはある」ということになります。
条件式がtrueの場合とfalseの場合とでそれぞれ通知したいメッセージを作ります。
タスクがない場合は通知しないという選択肢もありますが、フローが失敗している場合も通知はされないため、「フローが成功してかつ、今日が期限のタスクがない」ということを共有したかったので、タスクがないときも通知は実施しています。
このあたりはフローの目的やフローをどこに通知するか等によって決めておくべきでしょう。
7. チャットに新しいメッセージを追加する
ここは説明するまでもないですが、メッセージを特定のチャットルームに通知しています。 できれば、どのフローから通知されているかもメッセージに含めておくと良いでしょう。
期限を変えてみる
フローが作成できたので、他の期限を設定します。 フローを別名保存しておきましょう。
ここで大事なのが、期限ごとのフローで同じタスクを通知しないというところです。 制御するためにはa.通知すべきタスクかどうかを判断するの条件を変えてやればOKです。
その週が期限のタスク一覧を通知する
条件は単純です。「通知の翌日からその週の最終日まで」とすれば良いのです。 具体的には、次のとおりです。
- ＜empty(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime'])＞次の値に等しい＜false＞（変更なし）
- ＜値 達成率＞次の値未満＜100＞（変更なし）
- ＜ticks(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime']) ＞次の値以上＜ticks(addDays(utcNow(), 1))＞
- ＜ticks(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime'])＞次の値未満＜ticks(addDays(utcNow(), 6))＞
太字にした箇所を UTC 現在日時の１日後～６日後で期限の日付を比較しています。ここでticks(addDays(utcNow(), 0))としてしまうと、今日が期限のタスクも取得できてしまいます。
遅延しているタスク一覧を通知する
こちらは更に単純です。
- ＜empty(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime'])＞次の値に等しい＜false＞（変更なし）
- ＜値 達成率＞次の値未満＜100＞（変更なし）
- ＜ticks(items('タスク一覧を収集してメッセージを整形する')?['dueDateTime']) ＞次の値以下＜ticks(addDays(utcNow(), 0))＞
タスクの期限が UTC の現在日時よりも過去の日時かどうかを判断しているだけです。
Planner は通知機能が弱いので Power Automate で良い感じに通知してあげるとかなり使い勝手が良くなります。 もっと良い方法をご存じの方は是非コメントください！
（Power Automate）実行中のフロー名を関数を使って取得する
小ネタです。 Power Automate で特定のチャットツールにメッセージを送るようなフローをよく作るのですが、フローが増えてくるとどれで送ってるんだっけ？となりがちです。 個人的によくやる手として以下のような一文を最後につけて送信しています。
（このメッセージは Power Automate - ＜フロー名＞ によって送信されました。）
こうすることで「どのツールの」「どの機能を使っているか」を明確にすることができます。 ただ、フロー名を後で変更した場合など、固定値を入力していると変更し忘れて意味をなさなくなる可能性があります。 できれば、フロー名の変更にも追従したい＆コピペできるようにしたい！
そんな場合は次の関数を呼び出せばOKです。
workflow()?['tags']?['flowDisplayName']
これをメッセージに埋め込んでおけばフロー名の変更にも対応できます。
ちなみに以下のリファレンスで記載されているworkflow().run.nameを呼び出すとフローのIDが取得できます。
初見だとこっちのほうがフロー名ぽいんですけどね。
Azure DevOps REST APIで大量のPull Requestを取得する際の注意点について
先日、Azure Repos で管理しているリポジトリの Complete 済みの全 Pull Request を取得したいという要件があったので Azure DevOps REST API を使いました。 その時、条件の指定方法によっては取得できる Pull Request の数が想定より少ない数しか取得できない、という現象が発生しました。 回避方法はあったのですが、割と使われやすい API であり、今後もハマリポイントになりそうなので備忘録として残しておきます。
今回使用する Azure DevOps REST API はこちら。
開発環境
- .NET Core 3.1
- C#
- Visual Studio Code
今回は C# でしか検証していません。他の言語などでは挙動が変わる可能性があるのでご了承ください。 また、 Visual Studio Code の REST API でも試しましたが、こちらの場合は応答はありましたが結果が表示されないという現象が発生しました。原因については分かっていません。
問題点
まずはコードを。事前に NuGet でNewtonsoft.JsonとSystem.Net.Httpを追加しておきます。
using System; using System.Text; using System.Net.Http; using System.Threading.Tasks; using System.Net.Http.Headers; namespace AzureDevOps.Api { class Program { static async Task Main(string[] args) { string auth = Convert.ToBase64String(Encoding.ASCII.GetBytes(":<Personal Access Token>")); using (HttpClient httpClient = new HttpClient()) { httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", auth); HttpRequestMessage message = new HttpRequestMessage(HttpMethod.Get, $"https://dev.azure.com/<organization>/<project>/_apis/git/repositories/<repository>/pullrequests?api-version=6.0"); HttpResponseMessage response = await httpClient.SendAsync(message, HttpCompletionOption.ResponseContentRead); if (!response.IsSuccessStatusCode) { throw new HttpRequestException(response.RequestMessage.ToString()); } string json = await response.Content.ReadAsStringAsync(); dynamic pullRequests = Newtonsoft.Json.JsonConvert.DeserializeObject(json); System.Console.WriteLine($"Pull-Requestの数:{pullRequests.count}"); } } } }
細かい説明は省きますが、目的は API で指定したリポジトリの Pull Request 数を出力しています。 検証対象の環境では Pull Request の数が 2000 を超えているものを使用しました。
この時点では、以下のように何の条件も指定していません。
https://dev.azure.com/<organization>/<project>/_apis/git/repositories/<repository>/pullrequests?api-version=6.0
これを実行すると以下のような結果が出力されます。
Pull-Requestの数:62
期待値としては 1000 以上ですが、そうはなっていません。
原因
ググると同じ問題にハマっている人がすぐに見つかりました。
どうやらこの振る舞い自体は API 側の仕様のようで、条件が指定されていない場合、何千件もの Pull Request を返すことになるため返却される件数が少なくなっている（らしい）とのことです。 つまり、対策は上記のページにも書いてあるとおり、条件を指定して返却される件数を指定してやれば良いのです。
対策
今回のように Complete 済みの全 Pull Request を取得するといった要件の場合、次の URI パラメータを使用します。
- $skip
- $top
- searchCriteria.status
実際の URI は次のようになります。
https://dev.azure.com/<organization>/<project>/_apis/git/repositories/<repository>/pullrequests?$skip=n&$top=1000&searchCriteria.status=completed&api-version=6.0
$skip=nとしているのは複数回 API を呼び出さなければならないためです。
さて、これに対応したコードは次のようになりました。
using System; using System.Text; using System.Net.Http; using System.Threading.Tasks; using System.Net.Http.Headers; namespace AzureDevOps.Api { class Program { static async Task Main(string[] args) { int totalCount = 0; string auth = Convert.ToBase64String(Encoding.ASCII.GetBytes(":<Personal Access Token>")); using (HttpClient httpClient = new HttpClient()) { httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", auth); int numberOfCalls = 0; do { HttpRequestMessage message = new HttpRequestMessage(HttpMethod.Get, $"https://dev.azure.com/<organization>/<project>/_apis/git/repositories/<repository>/pullrequests?$skip={numberOfCalls * 1000}&$top=1000&searchCriteria.status=completed&api-version=6.0"); HttpResponseMessage response = await httpClient.SendAsync(message, HttpCompletionOption.ResponseContentRead); if (!response.IsSuccessStatusCode) { throw new HttpRequestException(response.RequestMessage.ToString()); } string json = await response.Content.ReadAsStringAsync(); dynamic pullRequests = Newtonsoft.Json.JsonConvert.DeserializeObject(json); int count = (int)pullRequests.count; if (count == 0) break; totalCount += count; numberOfCalls += 1; } while (true); } System.Console.WriteLine($"Pull-Requestの数:{totalCount}"); } } }
これで 1000 件を超える Pull Request の取得にも対応できます。
おまけ
今回作成したコードで API の条件に指定した件数によって実行時間がどのくらい変わるのか試してみました。 件数は 100 / 500 / 1000 で３回実施しました。
| 回数 | 100件 | 500件 | 1000件 |
|---|---|---|---|
| １ | 00:00:21.7547365 | 00:00:39.0122263 | 00:00:36.1842337 |
| ２ | 00:00:32.3838879 | 00:00:38.4844625 | 00:00:34.9170869 |
| ３ | 00:00:32.5571534 | 00:00:38.5509034 | 00:00:28.5829396 |
微妙なところですが、まぁ、誤差の範囲かなーと思います。 取得件数による応答時間はあまり変わらないので、取得する際の要件次第で１回あたりの取得件数は変えるのが良さそうです。
在宅勤務になったのでコーヒーミルを買いました
私の勤務している会社は緊急事態宣言に伴い在宅勤務となりました。 普段から勤務中は個包装ドリップタイプのコーヒーを飲んでいるのですが、それらは全部会社に置き忘れてしまったので、せっかくだしコーヒーミルを買って豆を挽いて飲むようにしました。
今回は新しく買ったコーヒーミルを紹介していきたいと思います。
買ったもの
買ったのは HARIO の手動ミルです。 手動ミルを買ったのは初めてでしたが、レビュー数が多く安定していたのとまとまった量の豆を挽きたかったのでこちらを選択しました。
このミルは挽いた豆をそのまま蓋をして保存できるのですが、100g とか 200g 挽いてるとさすがにたりなさそうなのでミニキャスターも購入しました。
なお、HARIO のコーヒーフィルターとドリッパーは形状が円錐になっているので、スーパーなどでは同型のものが売り場においていない可能性があるのでご注意ください。
HARIO(ハリオ) コーヒーミル ブラック コーヒー粉100g 手挽き セラミック スケルトン MSCS-2B
- メディア: ホーム&キッチン
HARIO(ハリオ) 珈琲キャニスター M ブラック コーヒー粉200g MCN-200B
- メディア: ホーム&キッチン
HARIO(ハリオ) V60 計量スプーン シルバー コーヒー粉すりきり12g ステンレス 日本製 M-12SV
- メディア: ホーム&キッチン
私はもともと 60V のドリッパーは持っていたのですが、持っていない方はこちらも購入したほうが良いと思います。
HARIO(ハリオ) V60透過ドリッパー01 クリア 1-2杯用 コーヒードリッパー 日本製 VD-01T
- メディア: ホーム&キッチン
無事必要なものが到着したので早速豆を挽いてみました。
予想はしていましたが、200g 挽くのに 30分くらいかかりました。 普段からインドア派な私にはなかなかの重労働です。。。 在宅勤務のちょっとした運動と考えれば結構いい感じなんですけどね。
それでもやっぱり挽きたてのコーヒーは香りが良く、それだけで気分が高揚します。 ついでにミニキャスターもインテリアとしてもなかなかに優秀です。計量スプーンがいい味出してます。
コーヒー豆ごとに色違いのキャスターを使うとより一層おしゃれになります。 （背景が残念ですが）
HARIO(ハリオ)キャニスター M ホワイト MCN-200W 1個入
- メディア: ホーム&キッチン
HARIO (ハリオ) V60 計量スプーン Wood M-12WD
- メディア: ホーム&キッチン
注意点
このコーヒーミルは豆の粗さを調節することができます。 取説ではメモリを調節することで、豆の粗さを自由に変えられますと記載されていましたが、ぶっちゃけどれがメモリかわかりませんでした！
で、色々試した結果、どうやら以下の赤いところがメモリらしいです。
流石に初見でこれはわからんよ…
いくつか試してみた
コーヒーミルを買ってから以下の豆を試しに飲んでみました。
個人的にはキリマンジャロのほうが好きですがちょっとお高め。 UCC コーヒーは値段の割に美味しいので、よく飲む人は買っておいて損は無いでしょう。
また、5月1日より U ブレンド豆以外のコーヒー豆が 1,000円 から 1,200円 に価格が変更になるそうです。欲しい方は今のうちに少し買い置きしておいても良いかもしれません。
こんなご時世ですが、自宅で楽しめそうなことはどんどんやっていっても良いかもしれません♪
良きコーヒーブレイクを！
Azure Pipelines Task の拡張機能を開発する
前回は Azure DevOps の拡張機能の Hello World を実施しました。
今回は Azure DevOps の中でも最も利用されるであろう Azure Pipelines に自作した Task を追加していきます。
参考ページ
今回は上記のページに沿って拡張機能を作っていきます。 ただ、上記では Node.js + TypeScript を使って開発されています。単純に手順に沿って作っていけば普通に作れてしまうため、あまりこのエントリで紹介する意味がありません。
なので、ちょっと趣向を変えて Node.js ではなく、PowerShell を使って開発していきます。 PowerShell を使った Task 拡張機能の作り方は Microsoft 公式では見当たらなかったため、以下のページを参考にしています。
環境構築
各種ツールを適宜インストールします。今回は Visual Studio Code を使っていますが、エディタはお好みのものを使ってください。
- Node.jsをインストールする
- TypeScript Compilerをインストールする
- VS Codeをインストールする
npm i -g tfx-cliを実行してtfx-cliをインストールする
Azure Pipelines Task を開発する
今回作るもの
はじめに今回作るものをお見せしておきます。 サンプルなので特にタスクそのものが意味を持つわけではありませんが、画面で入力した値を作成した Task が受け取ってビルドログに表示します。
タスク設定画面
ビルドログ
カスタムタスクを作る
カスタムタスクを作るまでの手順は上記参考ページに従っていきます。
以下のリンク見出しのCreate task scaffoldingを実行します。
次に、task.jsonを作成します。こちらも上記のページからコピーして作ってください。
適宜編集した後、最後のexecutionのみ以下のように変更します。
targetには、実行する PowerShell スクリプト名を記載してください。
{ "$schema": "https://raw.githubusercontent.com/Microsoft/azure-pipelines-task-lib/master/tasks.schema.json", "id": "{{GUID}}", "name": "{{タスクの名称（英数字のみ、半角スペース使用不可）}}", "friendlyName": "{{タスクの表示名（ユーザーに見えるタスク名はこっち。未入力なら name が使われる}}", "description": "{{タスクの説明}}", "helpMarkDown": "", "category": "{{タスクのカテゴリ。Build とか Utility とか。}}", "author": "{{publisher 名と同じにする}}", "version": { ...省略... }, "instanceNameFormat": "{{ここはパイプラインやビルドログに表示する内容。$(変数)で変数も使える。}}", "inputs": [ ...省略... ], "execution": { "PowerShell3": { "target": "powershell.ps1", "platforms": ["windows"], "workingDirectory": "$(currentDirectory)" } } }
VstsTaskSdkを使う
VstsTaskSdk を Node.js で使用する場合は参考ページの手順に従ってください。 ここでは PowerShell の VstsTaskSdk を使用する方法について説明します。
VstsTaskSdkのモジュールをインストールする
以下のコマンドを実行してローカル端末に VstsTaskSdk をインストールします。
Install-Module -Name VstsTaskSdk -AllowClobber
インストールしたモジュールを拡張機能のps_modulsフォルダに保存する
インストールできたら拡張機能のフォルダ配下にあるps_modulesフォルダ上で以下のコマンドを実行します。
Save-Module -Name VstsTaskSdk -Path "<ps_modules フォルダ>" -Force
これを実行するとps_modulesフォルダ配下にVstsTaskSdkフォルダが作成されます。
その配下にバージョン番号名のフォルダが出来上がりますが、このバージョン番号フォルダ配下のファイルをVstsTaskSdkフォルダに移動させてください。
以下のようになるのが正解です。
PowerShellスクリプトからVstsTaskSdkを呼び出す
スクリプトは次のように書いたらOKです。
以下はGet-VstsInputを呼び出しています。
[CmdletBinding()] param() try { $samplestring = Get-VstsInput -Name "samplestring" } finally { Trace-VstsLeavingInvocation $MyInvocation }
なお、SDK のモジュールはそこそこの数があります。 以下のページを参照するとちょっとしたヘルプが記載されているので参考にしてください。
manifestファイルを作ってパッケージを公開する
manifest ファイル（vss-extension.json）の作り方とパッケージの公開方法は前回の記事を参照してください。
作ったTaskを実行する
ここは特に迷いませんね。Azure Pipelines のビルドパイプラインからタスクを追加するだけです。
このように割と簡単に Azure Pipelines Task を作ることができました。 PowerShell に慣れている方ならわざわざ Node.js を使う必要もありません。
