はじめに
この記事は①概要編 ②受付フロー編 ③更新フロー編 の3本立てのうち、③更新フロー編です。
今回で一連の解説は終わりになります。
フローの解説
When someone responds to an adaptive card
まずはトリガーです。
Teamsコネクタの[誰かがアダプティブ カードに応答した場合]を選択します。
急に英語になるのは何なのでしょうか…?
…気にせず続けます。
[アダプティブ カードの入力]に前回受付フローで作成したアダプティブカードの本文(JSON)を、[カードの種類 ID]も同様に前回と同じCard Type IDを入力します。
[アダプティブ カードの入力]は一見意味がないように思えましたが、入力することでスキーマが形成され、後続のアクションに動的な値としてカードのInputを使用することができるようになります。
メッセージ詳細を取得する
アダプティブカードの中身を取得するために、まずはメッセージ詳細を取得します。
triggerBodyにメッセージID,TeamID,ChannelIDがそれぞれ含まれていますので、動的な値から設定します。ChannelIDだけは動的な値から選択できなかったので、直接数式を記述しています。
{
"messageId": "@triggerBody()?['entity']?['teamsFlowRunContext']?['messagePayload']?['id']",
"threadType": "channel",
"body/recipient/groupId": "@triggerBody()?['entity']?['teamsFlowRunContext']?['channelData']?['team']?['aadGroupId']",
"body/recipient/channelId": "@triggerBody()?['entity/teamsFlowRunContext/ChannelData/Channel/Id']"
}
いったんここまでの状態で、テスト実行をしてみます。
[メッセージ詳細を取得する]アクションの出力をよくよく確認すると、アダプティブカードの中身が文字列として返ってきているのがわかります。
カードの中身を取り出す
以下の数式でアダプティブカードの中身を取り出します。
attachmentsプロパティが配列になっているのでfirst関数で単一要素にし、取り出したcontent文字列をjson関数でオブジェクトに変換します。
json(
first(
body('メッセージ詳細を取得する')?['attachments']
)?['content']
)
またテスト実行し、jsonオブジェクトを確認します。
そうすると、アダプティブカードを作成した時と同じ構成の内容が取得できたことを確認します。
ここから目的の値、先頭に記載しておいたリストアイテムのIDを取得します。
jsonオブジェクトのbodyは、itemsプロパティの階層となっており、固有のプロパティ名から目的の値にアクセスすることができません。なので、「bodyのx番目のitemsのy番目のitemsの…」と、並び順と階層で指定していきます。
サンプルと同じ構成のカードであれば、目的の値は先頭に配置されているため、以下の式で取得できます。
first(
first(
outputs('作成_-Card_JSON-')?['body']
)?['items']
)?['text']
JSONと仲良しであれば、先頭のようなわかりやすい位置でなくとも自在に値を取得できるはずなので、カードから様々な情報を取得できるとさらに応用が効くと思います。
項目の更新
リストアイテムのIDが取得できたら、あとは更新するだけです。
IDに先ほどアダプティブカードから取得したIDを入力し、アダプティブカードのInput(今回の例ではドロップダウンボックスから入力されたStatus)で更新させます。
後処理
チャネルを起点としたリストの更新は以上で完了ですが、このままではチャネルから更新ボタンを押した人へのリアクションがないため、ちゃんと更新できたかがわかりません。
なので、更新したことがわかるようなメッセージを返信として追加することにしました。
また、完了Statusになった後は状況を更新させる必要がないため、[チャットやチャネルのアダプティブ カードを更新する]アクションでカードを更新し、更新ボタンを消しています。
(2パターンのみの分岐なので、スイッチではなく条件分岐でよかったのですが、初めは更新Statusごとに処理を分けようとしていた名残でスイッチになっています)
おわりに
解説は以上です。
いかがだったでしょうか?アダプティブカードのjsonから中身を取り出す泥臭い方法でしたが、アダプティブカードの応答を複数のカードから受け取れるようになるので、[誰かがアダプティブ カードに応答した場合]トリガーの可能性が広がるとよいなと思います。
おまけ
解説記事を書いている途中で、SharePointリスト側にチャネルに投稿したメッセージIDを保存しておけばjsonを解析する必要がないことに気が付きました…。
(絶対にそっちの方が簡単。。。)
リストに保存した情報は更新される可能性があるのに対し、リストIDとアダプティブカードは普通には更新できないので、この方法を使うメリットもあるのかな?あったらいいな。。。😇