概要
前回の続きです。
Power Automateによる「検温報告」の仕組み(1)
Power Automateによる「検温報告」の仕組み(2) - 検温報告を求めるフロー
Power Automateによる「検温報告」の仕組み(3) - 検温報告を受けるフロー
このフローは、LINE WORKSのBotからのCallbackを受けて実行されます。
Q1~Q5の5回、回答があるたびにCallbackされるので、1人の回答で計5回実行されることになります。
Q1は、前回の「検温報告を求めるフロー」でメッセージをPOSTしていますが、Q2~Q5はこのフローでメッセージをPOSTしています。
- Q1が回答されたら、Q1の回答を記録してQ2をPOST
- Q2が回答されたら、Q2の回答を記録してQ3をPOST
:
実行ステップ
トリガー
LINE WORKSのBotのCallbackを受け取るため、「HTTP要求の受信時」トリガーを使用します。
フローを保存すると、HTTP POSTのURLが発行されるので、コピーボタンでコピーして、LINE WORKSのBotに設定します。
LINE WORKS APIのシークレット取得
前回と同じなので省略
ユーザーリストの取得
これも前回と同様
その後、フィルター処理しているのは、回答したユーザーの情報を取得するため、絞り込んでいます。
トリガーに含まれる accountId でユーザーを特定しています。
IDで絞り込んでいるので、フィルター処理の結果は要素数が1の配列になるはずなので、firstを使って取り出します。(定番テク)
first(body('アレイのフィルター処理'))?['name']
回答5、または、随時の発言
ここが一番の悩みどころでした。
Q5は「その他の自覚症状」ですが、QuickReplyのボタンではなく自由記入欄で、ただのテキストメッセージだとpostbackを付けられず、IDを付けられない。
それだけであれば、ユーザーは分かるので、そのユーザーを探してExcelに記入することもできますが、検温報告を求める以外でもユーザーからメッセージが飛んでくる恐れがあり、その場合以前のメッセージを上書きしてしまう可能性があります。
なので、Q5は任意回答として、回答があった場合はExcelの行を追加する形で対応しています。(表に行を追加アクション)
なんらかのメッセージがあれば、管理者(私)にメッセージを飛ばして、このフローは終了です。
質問ごとにスイッチ
次のスイッチアクションで質問ごとに処理を分岐させていますが、その前にQuick Replyで返されたPostbackを解析します(JSON の解析)
解析したJSONの"q"を基に分岐します。
(スイッチは横に広がって見にくい・・・)
どの分岐も基本的に手順は同じです。
Excelに回答を記録→次の質問をPOST→基準を超えたら緊急連絡(体調不良がなければ終了)
Excelに記録
Excelの「行を更新」アクションで、「検温報告を求めるフロー」で追加した行に記録していきます。
ここで日時から作成したID文字列をキー値に指定します。
次の質問をPOST
「検温報告を求めるフロー」と同様、ごりごりJSONを書いてPOST
postbackの"q"は、"q2"にする必要があります。(エンコードされていると2ばかりで分かりづらい・・・)
異常を判定
回答は文字列で返されるので、力技で判定。
異常があれば、緊急連絡メッセージを作り、異常がなければここで終了(終了しないと、異常がなくても空の緊急連絡メッセージが飛んでしまいます)
他の質問の分岐は文言や異常判定の条件が異なるぐらいなので、省略。
管理者へ緊急連絡メッセージを投稿
体調異常があった場合には、別Botで管理者へメッセージを投稿します。
同じBotでも構わないですが、その場合、緊急連絡メッセージを受け取った管理者は自分の検温報告のQuickReplyのボタンが消されてしまうので注意。
まとめ
Power Automateを使い始めて初期の頃に作ったフローで、今から見るとつたない所もありますが、支障はないのでこのままかれこれ1年半ぐらい使い続けてます。
それ以前は安否確認サービスで検温報告を行っていましたが、運用の手間がかかるため、何とか手間をかけずにできないかと、悪戦苦闘しながら作った覚えがあります。
APIを叩く、というのもこれが最初でした。
それまではJSONもろくに知らずに、Postmanで見よう見まねでAPIを叩いて、レスポンスが返ってきたときは、感動ものでしたね。
これならいけると、Power Automate per Userプランをぽちって、HTTPアクションにのめり込んでいくのでした。
非常に今更感のあるネタで恐縮ですが、何かの参考になれば幸いです。