背景
Teams への通知をしようとすると、超えられない壁の一つとして立ちはだかるのが、これ
特定の条件下であれば、 チャンク (chunk) で簡単に回避できるようになった、という紹介です
条件
表など、繰り返しデータで too large になっていて、card を分割可能
詳細
Adaptive Card で動的に表通知をしようとすると、結構簡単に超えてしまう
回避方法としては、サイズを減らすしかないので、以下などが考えられる
- プロパティを減らす
- Default なら消す
- プロパティを集約する
- 上位で定義して、継承させることで、定義数を減らす
- 表示列を減らす
- 表示情報を削る
- 表示内容を圧縮する
- 体言止めだったり、Summary表示だったり
- 表示行数を一定数以下にとどめて分割
ここで、最後の、行数分割が最終手段になるわけだが、従来だと・・
- 全体Loop
- Loop変数で、.Skip(25).Take(25) みたいに一定行数取得
- Post
ってなって、かなり面倒な上に、Apply to Each だと iterationIndexes() が使えないので、index も制御する必要がある
で、ここで救世主 チャンク (chunk) の登場です
実装例
- 元となる行データを、適切な大きさで分割(Chunk)
- Apply to each で分割したものを Loop
- あとは、元の通知をほぼそのまま利用
@{chunk(variables('Rows'), 30)}
union() は、情報排除されるので、利用時は注意。
動作例
一括の場合はエラーになるものも、適切なサイズで分割したものは、複数のCardで送信されて問題無し
以下は送信例
あとがき
簡単になったとはいえ、365通知とか最近HTMLの肥大化が進んでるので、HTML系を転送すると簡単に超えてくるし、そもそもHTMLの縮小化手段が乏しくて困る・・
keyword
how to avoid "payload is too large" by chunk