4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

#PowerPlatform デザインパターン 予約投稿

Last updated at Posted at 2022-02-03

Power Platform で仕組みを作成するにあたり「自分だったらこうするかなー」というパターン、皆さん持っていませんか?そんな「自分だったらこういう設計にする!」という、所謂「デザインパターン」みたいなモノを記録しておこうかと思ったのでチャレンジする企画です。
今回は「SharePoint Online(以降、SPO)へ予約投稿したい」という要望に対するアプローチです。

ユースケース

前述どおりなので、あえて細かいコトを説明する必要もないかな?と思いますが、念のため。

  1. 投稿先はカスタムリスト。一方的に情報を発信する場所
  2. 投稿者は「公開予定日時」を指定して事前に投稿したい
  3. 指定した「公開予定日時」を超過するまで、その他ユーザーからは見られたくない
  4. 「公開予定日時」は厳密でなくてよい。指定したタイミング”以降”で表示されれば OK

これぐらいのルールで続けます。

アーキテクチャ

当方だったらどうするか?です。2パターン考えてみました。

パターン1:Power Automate 単体型

SPO の該当リストへ、何らかの方法で「自分以外の権限を排除」した状態で、かつ「公開予定日時」を指定できる列へ値を入れてアイテムを作成させます。その状態であれば、アイテム投稿をしたユーザー以外は対象アイテムを閲覧することができなくなるハズです。

加えて、Power Automate で対象のリストを監視します。監視といっても、1日n回のタイマー処理で問題無いでしょう。個人的には1回/日で良いんじゃないかと思っちゃいますが、管理する情報に依存するので適宜ご判断をってポイントですかね。タイマー処理が実行されたタイミングよりも「公開予定日時」が前の対象を抽出し、該当するアイテムに『投稿者以外が閲覧などできる権限』を付与すれば、あたかも予約投稿されたかのようになりますよね。
画像1.png
上記アーキテクチャですが、詳細未検証なのでチョッと不安なのが「サイトの管理者」もアイテムの権限を切られていたら、フローからでもアイテムが見れないかもしれない・・・。そんな時は管理者も権限付与しておいてしまえば良いんですけどね。

ちなみに、アイテム登録時は手動じゃなくてアプリ等を経由しても良いと思います。シンプルな状態で説明したかったので上記イメージです。このパターンを紹介しておいてナンですが、個人的に現実的ではないと思ってますw 権限を切ったり付けたりするのって手間ですし、結果的に「アイテム単位の個別権限設定」になるので管理が煩雑になりますよね。局所的・限定的な利用シーンがあれば光るかもしれません。

参考URL

Power Automate で SPO のリストアイテム権限を操作する場合は下記が参考になると思います。

Power Automate のフローで SharePoint リストアイテムの権限を操作してみるidea.toString();

リスト アイテムとファイルのアクセス許可を管理し、Power Automateする

Power Automate でフィルターしたい場合はフィルタークエリーを利用すると幸せになれるかもしれません。

【#PowerAutomate Tip's】フィルタークエリー (OData クエリ) メモ

パターン2:Power Apps + Power Automate 複合型

パターン1がツラいなら登録画面を Power Apps で作ってしまえばいいじゃない、というのがパターン2です。こちらはイメージを確認するだけで、ある程度の内容が想像できるんじゃないかなー、と思っています。

画像2.png

Power Apps で「公開予定日時」を含んだ登録画面を提供してデータ登録はアプリ経由で実施させる。
 ↓
アプリからは一次領域としてのデータソース(イメージは Dataverse)へ格納。
 ↓
パターン1のように Power Automate のフローで公開予定日時を監視。
 ↓
公開予定日時を超過したタイミングで該当リストへアイテム登録。

一次領域のデータソースは Dataverse でなくても実現できます。ただし、選択したデータソースによって固有の弱点や制約などがあるでしょうから、その点を踏まえて適宜判断して設計・実装してください。
データソースを中継することによって細かな権限設定から解放されます。ゴールであるリストに対して、フローで書き込むユーザー以外は閲覧権限設定にしておけば基本問題ないかな、という状態になるでしょう。フローでリストに書き込むので、機械的に付与したい属性情報なども補完できますね。

お断り

実装に関する詳細は記載しませんし、全ての意図も記載しておりません。あくまで”自分だったら、こんなアーキテクチャ”という考察記事です。そのため「ここがうまくデキないんですけど」等のご質問には対応いたしません。当方の方針として、自分たちで調べて、実装して試してみて、使ってみて初めて身につくモノがあると考えております。ですので、是非ともご自身で挑戦をしてください。
どうしても・・・、という場合は、お仕事として対応できる方(※当方含めて)にご相談ください。

「こういう設計のが良いのでは?」
「こういうデザインもあるよね!」
というご意見は大歓迎です。

まとめ

欲しい仕組みは自分でつくる!(盟友 J リスペクト)ってノリで、考えてみました。

  • 公開するタイミングをどう考えるか?(時限式をいかに作るか?
  • 予約しておく=どこかに仕込みの場所が必要

「時限爆弾式」と言い換えてもよいですね。”爆弾”という単語がアレですが、予約というよりも時限式って発想があると他にもパターンが作れそうかなぁ、ですねー。目的は「定めたタイミングで期待した動作をしてほしい」ですから、その本質を貫けば良いと思います。

それでは、皆さま、素晴らしい Power Platform Life を!

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?