はじめに
この記事は、RPA Advent Calendar 2024 12月17日担当分の記事です。
今回は以前に自社、現場で作成したPower Automate（クラウドフロー）でRSSを定期的に取得しTeamsへ通知する実装サンプルについて記事にいたしました。
Power AppsやPower Automate など英語発信のブログを日々スケジュールで取得してタイトル翻訳の上Teamsへ通知する内容でした。（土日は翌営業日に通知）
はじめに 今回は以前に自社、現場で作成したPower Automate（クラウドフロー）でRSSを定期的に取得しTeamsへ通知する実装サンプルについて記事にいたしました。以前 RPACommunityさんでLT登壇させていただいた際の内容という感じですが、実装部分の記事を作っていなかったの...
ただこれが半年ほど前からPower Platform系としてサイトがまとまり、URLが変わったんですが、そのタイミングでfeedに追加されるのにタイムラグが発生するようになり、数日間位feedに載ってこなくなりました。
本来はほどなくfeedに追加されてRSS受信を出来るのですがそれが出来なくなっています。
そのうち解消するだろうと待っていましたがいまのところ一向に回復しないためフローをスケジュール受信から都度受信に変更するように改修するにいたりました。今回そのあたりを記事にいたします。
Power Apps や Power Automate などのRSSがすぐに取得できない状態(feed登録が遅れている）
Power AppsのBlogの新しいURLは「Power Apps Archive – Microsoft Power Platform Blog」となっています。
こちらへは最新の記事が出るたびに追加されます。
以下は2024年12月9日頃にみた内容ですが、12・4に2件追加されています。その前は11・19ですね。
以下はこのページのFeedです。URLの末尾に/feed とした内容となります。この内容をRSS受信してます。
FeedのURLmicrosoft.com/en-us/power-platform/blog/power-apps/feed/
見てみると、12/4の分がまだありません。。最新で載っているのは11/19 の分までとなってます。。
以下はこのページのFeedです。URLの末尾に/feed とした内容となります。この内容をRSS受信してます。
FeedのURLmicrosoft.com/en-us/power-platform/blog/power-apps/feed/
見てみると、12/4の分がまだありません。。最新で載っているのは11/19 の分までとなってます。。
しばらく（数日間）待つと追加される感じでした。
NOTE実は上記に載っていない状態でもRSS取得アクションでは（載る前日）に取ってこれているケースもありました。 どうも完全にリンクしているわけでもないようです。
このあたり、FeedやRSSの仕組みについてはそれほど詳しくないのでざっくりと見た感じの情報となりますのでご容赦ください。上記のRSSのページをハードリフレッシュしたら更新されたりもしましたが、それでも遅れている内容であったり。
いずれにしても数日～1週間くらい記事掲載からRSS取得が遅れる状態は変わりませんでした。
都度取得するトリガーへ変更して通知タイミングを調整するように変更
上記の状態が長く続いているため、元々の実装では、スケジュール取得でRSS一覧を取得、そこから1日分（月曜は土日含む3日分）の公開日の記事をリストしてTeamsへ投稿していました。
これが、RSS一覧取得した際にまだ載っていないので無しとして投稿されず、数日たってからFeedに載っても取得対象とする期間は既に過ぎているため投稿されない。という状態でした。
日々正常終了するけども、1件の通知も来ないという状態です。残念。。。
NOTEあくまでPower AppsやPower Automate 系の最近のBlogについてのお話です。他のRSSを取得するフローの場合は通常問題ありません。
元々のフロー
以下元のフロー概要です。月～金9時に動かしRSSのリストを取得、そこから公開日が1日分（月は3日分）を取得してテーブル形式で通知（タイトル、概要翻訳）という感じです。
毎週のスケジュールだと遅そう
それなら1週間（月曜日）に一回だけ取って通知するでもいいかと思ったんですが、結構取得が遅れるので投稿タイミングによっては通知されるのがその2週間後位だったりするなーと。これもあんまりイケてないかと思いました。
上記のためスケジュール取得はやめて、都度取得する実装にしました。
この場合でも、実際に記事が投稿されてから数日間遅れますが、都度サイトを見に行くよりはましなので。
NOTEこの場合、特に海外の発信なので夜間だったり、休日だったりと通知されるタイミングが読めません。休みの夜中や早朝に通知が来ても怒られてしまいますので通知するタイミングの調整が必要でした。
ざっくりと以下全体像です（一部2パターン分の実装のため不要な個所もあり）
RSSのトリガーを「フィード項目が発行される場合」トリガーに変更
まずトリガーを「RSS＞フィード項目が発行される場合」に変更します。
そして,RSS フィードのURLに従来通りのURLをしていします。
Power Appsの場合は以下です。
Power Apps BlogのFeed URLhttps://www.microsoft.com/en-us/power-platform/blog/power-apps/feed/
※スケジュールトリガーは削除します。最初から作ったほうが楽かもなのでやりやすい方で
TIPSたまにしか通知が来ないので、作っている途中は普通の手動トリガーにしたり、検証の時はいったんよく通知の来るRSSに変えて検証するなどした方が良いです。問題なさそうなら上記URLを指定して最終確認する感じですね。
トリガーの設定で分割をオフにする
追加時点ではオンになっていると思います。これは通知ごとに個別に来る設定です。
一定期間で2つ以上ある場合、オンだとそれぞれキックされますが、オフだと2つ分を一回のキックで取得されます。
TIPS今回のフローの場合、どちらでも影響はそれほどないのですが、遅れて載る分、2，3一気に来るケースも多いと予想し、通知も複数前提でテーブル形式で表示するようにしているのでこのように調整しました。
※オンのままの場合は連続でそれぞれ通知が来て、それぞれがテーブル形式になっている。というくらいの違いです。
通知時刻の調整編
上記を変更して後はそのまま通知すれば楽なんですが、元々朝9時にまとめて通知していた点もありますし、休日や夜間、早朝などいつ通知が来るのか読めません。
そのため、以下ルールで通知時刻を調整するようにしました。
- 受信したのがAM9時以前なら当日の9時まで待機して通知
- AM9時以降なら翌営業日のAM9時まで待機して通知
上記、ぱっと見は簡単にそうですが、月～木は時間によりその日または翌日の投稿、金曜日の朝9時前だと当日、9時以降なら土日を挟んで次の月曜日に通知するようにしないといけない。土曜、日曜も月曜日に通知する。という調整が必要です。
TIPSちなみに祝日判定も入れ込む事は出来ますが、面倒さが増すので今回は見送りました。
もともとも祝日判定はやっていなかったので。気が向けばですね。
一応パターンを表にすると以下のような感じですね。
ロジックを考えるいい機会だったので新人に考えさせてみた
この辺の実装ロジックは何パターンかあると思います。いい機会だと思ったので新人にこの辺りのロジックを考えさせてみました。
実直に曜日を判定して、IF文で分けて、さらに時間判定を行い、待機時間を調整して。。などですね。
その他にも一定期間で待機ループさせて、その時点の曜日や時刻で判定して解除するなどもありますかね。
ひとまず考えさせてみたところ、分岐がかなりの数になり、最終通知部分もそれぞれの最後におんなじこと書いてるなどになりました。
そこから、この部分はそれぞれに同じアクション書いているので保守性も考慮して、変数化して後で一本化して１アクションで対応したほうがスマートだよね？
曜日より時間帯を先に判断して調整した方が良さそうだよね。。などとメンバー内でアドバイスしながら、よりスマート（早い、分かりやすい、合理的）な実装があるということを話すいい機会となりました。
最終的にうちのデキる後輩君が時間を一旦投稿タイミングに調整してズレをなくし、曜日の部分で数式で分けて通知する。というかなりスマートな実装となり現場で実装しました。
ただ、初学者にはすんなりと理解が難しいかなーという点もあり、何事もバランスだよなーと感じたりも。
今回以下に載せているサンプルは依頼前に自分でぼやーと考えていた、それほど難しくはない実装である程度はスマートなものという感じのものです。
先に時刻で日付を調整して分岐を減らす
とりあえず時刻9時より前か後かで変わるので、ここは統一させた方が楽ですよね。
ということで一旦9時以降の場合は翌日扱いとしました。
そうすると当日の判定後にさらに時間によっての分岐がなくなるので、実装や考え方がスマートになります。
実装：対象日、投稿時刻を用意、一旦日本時間へ
以下実装ですが、まず、対象日の変数を用意しています。最終的に投稿する日時用の変数ですね。次に投稿する時刻（例では9時）にしています。これをベースに日付調整をします。
で、RSSの受信はUTC時刻で来る（少なくともPower Platform系は）だったので、理解しやすいように一旦日本時間に調整をしています。投稿時刻も日本時間での数値ですね。
TIPS実は後々待機時間を設定する際にはUTC時刻にする必要があるのでちょっと無駄があるのですが、理解しやすさを優先して一旦日本時間にしてます。
受信した時間のみ抜き出す
次に取得した日本時間の時間部分のみ抜き出します。8時なら8、15時なら15ですね。
CodeformatDateTime(body(‘タイム_ゾーンの変換’),’HH’)
受信した時間が投稿時間（9時）より前か後かで日付を1日足すORそのまま
次に条件アクションで取得した時間が投稿時間と比較してそれ以上の場合（10時とか15時とか）は当日の投稿はしないので、1日たして翌日にしています。9時より前ならそのままですね。
それぞれを変数 対象日に一旦指定します。日付を足す式はaddDaysです。
※条件式にする際に明示的に数値型に変換しないとエラーとなるので取得時間は数値にしてます。
Code//条件
@int(outputs(‘作成_時間取得’)) が次の値以上 @variables(‘投稿時刻’)
//はい →1日足している
変数（対象日）：@{addDays(body(‘タイム_ゾーンの変換’),1)}
//いいえ →そのまま
変数（対象日）：@{body(‘タイム_ゾーンの変換’)}
上記を一旦やることで投稿時間前後かの判断が後々いらなくなります。
調整後の曜日を取得
上記調整後にその日の曜日を取得します。曜日の取得は「dayOfWeek」式を使います。
結果は日～土までで、0～6となります。日曜日は0、月曜日は1、土曜日は6ですね。
式関数のリファレンス ガイド – Azure Logic Apps | Microsoft Learn
Code@{dayOfWeek(variables(‘対象日’))}
土日の判定を行う
曜日の数値を使って土日の判定をします。
土曜日の場合は月曜日にするため＋２日します。日曜日なら＋１日ですね。
※事前の調整で金曜日の午後は土曜になっているのでその考慮は不要、日曜日の午後も月曜日になっているので不要
この部分も条件アクションを使ってシンプルに書けます。が、さらにいうと式で書けば1アクションで済みます。
ここは見た目の分かりやすさを重視するか、それほど難しい式ではないのでアクション数減らす実装とするかは引継ぎの点なんかを考慮してどっちにするか？という感じでしょうか。
条件式アクションでの実装例
取得した曜日が0（日曜日）の場合は対象日にさらに1日足します。
そうではなく6（土曜日）の場合は対象日にさらに2日足します。
TIPS以下の例だと変数値（対象日）に自身の変数を参照して式を書くとエラーとなるため、一旦作成アクションに入れてそれを使い変数値（対象日）に結果を入れなおしてます。
この点はMVPコルネさんが資料に上げている「追跡対象のプロパティ」の追加で自身の変数を参照して1アクションで完了させる実装とすることも可能です。
Power Automateの「設定」について学んでみよう！ | ドクセル
式での実装例（作成アクション）
こちらは上記を式で書いたパターンです。1アクションで済むのでよりスマートになります。ただ、式に慣れていない方がみるとすぐの読み解きが難しい場合もあります。
※クラウドフローの式は冗長になりがちだったり、スっと頭に入ってこないケースも多いので
そのあたり運用も鑑みてのケースバイケースかと思います。
Code//対象日の曜日が6なら2日、0なら1、それ以外は0の日付を足す
@{addDays(variables(‘対象日’),if(equals(outputs(‘作成_対象日の曜日’),6),2,if(equals(outputs(‘作成_対象日の曜日’),0),1,0)))}
投稿時刻を調整し延期期限を設定（UTCに戻す）
上記で投稿する日付を確定出来たので、その日付の投稿時刻（サンプルでは9時）に調整します。
対象日の0時に一旦するため、startOfDay式を使ってます。そこにaddHoursで投稿時刻（9時）を足してます。
Code//対象日の0時にして投稿時刻を足す →投稿日の9時にする
@{addHours(startOfDay(variables(‘対象日’)),variables(‘投稿時刻’))}
※上記 式で土日判定をしている場合は「variables(‘対象日’)」を「outputs(‘作成_式での土日判定版’)」へ置き換えてください
スケジュール：延期期限で日時をUTCで指定する
指定した日時まで待機させるには アクション「延期期限」を使います。カテゴリはスケジュールですね。
延期期限に指定する日付の形式はUTC形式となるので、先ほどまでで調整した日時をUTCに変換します。
変換にはconvertToUtc式を使います。元のタイムゾーン(日本）は’Tokyo Standard Time’を指定します。
この辺りは公式ご参考ください。
式関数のリファレンス ガイド – Azure Logic Apps | Microsoft Learn
タイムゾーンについて Default Time Zones | Microsoft Learn
Code//日本時間からUTC時刻へ変換
@{convertToUtc(outputs(‘作成_投稿時刻調整’),’Tokyo Standard Time’)}
TIPS※延期の方は指定した時間（秒や分、日など）待機します。○○分待機させるなどの場合はこっちですね。
今回は指定した日時で投稿したいため延期期限を使っています。
指定期限まで待機後に受信したRSS（複数対応）を翻訳、Teamsへ通知
上記で指定期限までの待機の実装が出来ました。
以降は以前の記事と同様に取得した件数分を翻訳をかけてTeamsへテーブル形式で投稿するとなります。
翻訳やTeams投稿の部分は以前の記事に書いてますので、詳細はそちら参照ください。
はじめに 今回は以前に自社、現場で作成したPower Automate（クラウドフロー）でRSSを定期的に取得しTeamsへ通知する実装サンプルについて記事にいたしました。以前 RPACommunityさんでLT登壇させていただいた際の内容という感じですが、実装部分の記事を作っていなかったの...
翻訳してテーブル形式へ調整
変更点としては、以前のフローでは取得した対象から対象日でフィルターして、その上位10件をTakeとしてループ）などとしていた処理が不要となり、取得したRSS受信件数分ループして翻訳、その後Teams通知する。とシンプルになった感じです。
以下の翻訳やHTML作成部分の実装は変更していないので以前の記事の内容をご参考ください。
apply to eachには「@{triggerOutputs()?[‘body/value’]}」を指定しています。
Teamsへ通知（スレッド形式で指定）
Teamsアクションのチャネル内のメッセージで応答します。で指定したチャネルの特定メッセージに返信する形で投稿します。
上記で翻訳した件数分を結合してテーブル形式でHTMLで投稿します。
Code//投稿の本文
<table>@{join(outputs(‘Compose’),”)}</table>
おわりに
ということで、今回思ったより長くなってしまいましたが、以前のスケジュールRSS取得フローがPower AppsやPower Automateの場合、RSSが遅れて通知されるため機能しなくなったのでやむなく調整した内容を記事にしました。
実装そのままだと限定的になりますが、特定の期間まで待機させる際に土日や他の条件を加味して調整するロジックの部分は応用が利く内容かなと思いました。
また、メンバーでもどのようなロジックがより適切か、クラウドフローのルールや運用も加味した実装はどういったものがよりベターか。など色々考えるよい機会となりました。
同じようにRSSが取れず困っている方へのお助けやロジック部分が何かのヒントになれば幸いです。それでは！
関連記事
はじめに 今回は以前に自社、現場で作成したPower Automate（クラウドフロー）でRSSを定期的に取得しTeamsへ通知する実装サンプルについて記事にいたしました。以前 RPACommunityさんでLT登壇させていただいた際の内容という感じですが、実装部分の記事を作っていなかったの...
Power AppsときどきAutomate。初学者からその先へ進む方向けのワンランク上の技術情報ブログです。
この記事は役に立ちましたか？
もし参考になりましたら、下記のボタンで教えてください。
コメント