1
1

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 1 year has passed since last update.

PowerAutomate: chunk() で payload is too large を回避する

Posted at

背景

Teams への通知をしようとすると、超えられない壁の一つとして立ちはだかるのが、これ
image.png

特定の条件下であれば、 チャンク (chunk) で簡単に回避できるようになった、という紹介です

条件

表など、繰り返しデータで too large になっていて、card を分割可能

詳細

Adaptive Card で動的に表通知をしようとすると、結構簡単に超えてしまう

回避方法としては、サイズを減らすしかないので、以下などが考えられる

  1. プロパティを減らす
    1. Default なら消す
  2. プロパティを集約する
    1. 上位で定義して、継承させることで、定義数を減らす
  3. 表示列を減らす
    1. 表示情報を削る
  4. 表示内容を圧縮する
    1. 体言止めだったり、Summary表示だったり
  5. 表示行数を一定数以下にとどめて分割

ここで、最後の、行数分割が最終手段になるわけだが、従来だと・・

  1. 全体Loop
  2. Loop変数で、.Skip(25).Take(25) みたいに一定行数取得
  3. Post

ってなって、かなり面倒な上に、Apply to Each だと iterationIndexes() が使えないので、index も制御する必要がある

で、ここで救世主 チャンク (chunk) の登場です

実装例

image.png

  1. 元となる行データを、適切な大きさで分割(Chunk)
  2. Apply to each で分割したものを Loop
  3. あとは、元の通知をほぼそのまま利用
chunk 30 行で分割の例
@{chunk(variables('Rows'), 30)}

union() は、情報排除されるので、利用時は注意。

動作例

一括の場合はエラーになるものも、適切なサイズで分割したものは、複数のCardで送信されて問題無し
image.png
以下は送信例
image.png

あとがき

簡単になったとはいえ、365通知とか最近HTMLの肥大化が進んでるので、HTML系を転送すると簡単に超えてくるし、そもそもHTMLの縮小化手段が乏しくて困る・・

keyword

how to avoid "payload is too large" by chunk

1
1
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
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?