ルドルフもわたるふもいろいろあってな

Microsoft 365、Power Platform、PowerShellについて調べたことや検証したことなどを投稿します。技術の話は面白い。

【解説編その1】プレミアムアクションを使わずAzureADアプリも作らずにPower AutomateでMicrosoft TeamsのスレッドをCSVに保存する

掲題のフローの解説編その1です。

フローをGitHubで公開しました。
github.com

概要編について

今回の投稿は概要編に記載したフローの解説編です。概要編は以下のリンクから参照してください。フローの実行手順についても概要編に記載しています。
wataruf.hatenablog.com

この回で解説する範囲

解説する範囲のフロー図

この回で解説する範囲のフローは以下の通りです。

この範囲で解説するステップ

この範囲で解説するステップは以下の通りです。

  1. 保存対象のスレッドを指定してフローを開始
  2. 投稿一覧を格納するための配列変数を初期化
  3. Graph APIを使って指定したスレッドにある"親の投稿"を取得
  4. Graph APIを使って"親の投稿"に対する返信をすべて取得

解説

1.保存対象のスレッドを指定してフローを開始

このフローはTeams の「選択したメッセージの場合」トリガーを使用しています。

このトリガーは任意の投稿を起点にしてフローを開始するトリガーです。

このフローは"親の投稿"を起点として処理を行います。そのため、会話をCSV保存したいスレッドの親の投稿で「・・・」>「その他の操作」>「スレッドをOneDriveにCSV保存」をクリックしてフローを開始します。フローの開始時に手動で入力させる情報は無いのでアダプティブカードは使いません。

2.投稿一覧を格納するための配列変数を初期化

これは「変数」>「変数を初期化する」アクションです。後続のアクションでGraph APIから取得したデータを格納するために使います。

3.Graph APIを使って指定したスレッドにある"親の投稿"を取得

「Teamsから投稿を取得する」処理を行うアクションをまとめたスコープです。このスコープで使用しているアクションは2つです。

スコープ内のアクションについて解説します。

まずは「Office 365 Groups」>「HTTP 要求を送信します (プレビュー)」アクションを使います。概要編で解説した、Graph APIに対してHTTP要求を行うためのアクションです。

要求先のURIで使用している「チームID」と「チャネルID」と「メッセージID(= "親の投稿"のID)」は、「選択したメッセージの場合」トリガーの出力を使用します。

 "parameters": {
     "Uri": "https://graph.microsoft.com/beta/teams/@{triggerBody()?['entity']?['teamsFlowRunContext']?['channelData']?['team']?['aadGroupId']}/channels/@{triggerBody()?['entity']?['teamsFlowRunContext']?['channelData']?['channel']?['id']}/messages/@{triggerBody()?['entity']?['teamsFlowRunContext']?['messagePayload']?['id']}",
     "Method": "GET",
      "ContentType": "application/json"
 },


次は「変数」>「配列変数に追加」アクションです。Graph APIから取得した"親の投稿"のデータを、先ほど初期化した配列変数に追加します。

4.Graph APIを使って"親の投稿"に対する返信をすべて取得

先ほどの工程で取得した、"親の投稿"に対する返信をすべて取得します。

アクションをひとつずつ解説します。

4-1.「変数を初期化する-リクエスト先URI」アクション

これは「変数」>「変数を初期化する」アクションです。後続のアクションで「Office 365 Groups」>「HTTP 要求を送信します (プレビュー)」アクションを使って、返信を取得する際のHTTP要求先を定義します。

1回のHTTP要求で取得できる返信の最大件数は既定で20件です。そのため、すべての返信を取得するためには、HTTP要求を複数回実行する必要があります。また、実行するたびにHTTP要求先URIが変わります。"親の投稿"を取得したときとは異なりHTTP要求が複数回行われる場合がある、かつ、HTTP要求先URIが変動するため、このURIはHTTP要求アクションに直接記載するのではなく、変数にします。

4-2.「Do until-返信をすべて取得する」アクション

これは「コントロール」>「Do until」アクションです。スレッド内にある返信をすべて取得するまでHTTP要求を繰り返し行うために使います。

Do until 内の処理内容は以下の通りです。

  1. 「リクエスト先URI」が空白であるかを判定する。空白でなければ2以降の処理を実行。
  2. Graph API を使って返信を取得する
  3. 2で取得したデータを投稿一覧の配列に追加する
  4. 「リクエスト先URI」を更新 する
  5. 1に戻る

1 の「リクエスト先URI」が空白であるかを判断する式は下記の通りです。変数「リクエスト先URI」が空であるかどうかをempty関数で判定し、その結果が true であるかどうかで判断します。

@equals(empty(variables('リクエスト先URI')), true)

ちなみにこの判定条件を「@equals(variables('リクエスト先URI'), null)」としてはいけません。リクエスト先URIが無い場合の変数「リクエスト先URI」の値は nullではなく空文字になるためです。

4-2-1.「HTTP 要求を送信します-返信を取得する(プレビュー)」アクション

「Office 365 Groups」>「HTTP 要求を送信します (プレビュー)」アクションを使います。変数「リクエスト先URI」に対してHTTP要求を送り、スレッド上の返信を取得します。

4-2-2.「Apply to each-返信を配列に追加する」>「配列変数に追加-返信を配列に追加する」アクション

Apply to eachを使った繰り返し処理で、投稿一覧の配列変数に対して返信のデータを追加します。

配列(投稿一覧)に対して配列(返信)を追加するためにApply to each と配列変数に追加アクションを使っています。
 ※ここはもっとスマートなやりかたがあれば教えていただきたいです。(´・ω・`)

4-2-3.「変数の設定-リクエスト先URI」アクション

これは「変数」>「変数の設定」アクションです。リクエスト先URIを更新します。

「HTTP 要求を送信します (プレビュー)」アクションを実行した際に、1回の取得件数の最大値ではデータを返しきれない場合はAPIが次の要求先URIを返します。それが「nextLink」です。「変数の設定」アクションを使って、変数「リクエスト先URI」を更新します。データを終端まで返しおえた場合は空文字を返します。

"inputs": {
    "name": "リクエスト先URI",
    "value": "@{body('HTTP_要求を送信します-返信を取得する')?['@odata.nextLink']}"
 },

リクエスト先URIの更新が終わったら、Do Until の繰り返し実行判定に戻ります。

今回の範囲の結果として得られるもの

今回の範囲の結果として得られるものは、配列「投稿の一覧」のデータです。

これを後続の処理でこねこね整形していきます。そちらについては次回解説します。

今回は以上です。

追記:解説編その2を投稿しました。

wataruf.hatenablog.com