MakeのIteratorとAggregator｜配列・bundle・まとめ通知を理解する

注文と商品の二つの単位を決める

練習入力はorder_id=O-101、itemsにsku=Aが2個、sku=Bが1個という配列を持たせます。目標は商品ごとの確認を行い、注文ごとに一つの結果を作ることです。ここで使うIDや商品は架空です。商品行を台帳へ書くのか、通知文を作るだけかでも後続の処理数は変わります。

すでに複数bundleならIteratorを増やさない

Iteratorは一つの配列を、要素ごとのbundleに分けるモジュールです。前段の検索がすでに一商品につき一bundleを出しているなら、配列を分けるためのIteratorは不要かもしれません。まずRun onceなどを練習環境で使い、前段の出力が配列なのか複数bundleなのかを確認します。

Arrayに分割する配列を割り当てる

IteratorのArray欄へ前段のitems配列を割り当てます。後続では商品ごとのskuやquantityを使い、order_idも処理結果と関連付けます。項目が割当て候補に現れないときは、元のJSONやWebhookのデータ構造を確認し、安全な練習入力で前段の出力を取得します。実在の顧客データを構造学習のために使う必要はありません。

Aggregatorで集計範囲を明示する

Array aggregatorのSource Moduleには、どのモジュールからのbundleをまとめるかを設定します。商品処理の結果をまとめるなら、その範囲に必要な処理が含まれるようにします。Aggregatorは受け取ったbundleをまとめるため、前段で除外した商品を元に戻したり、別実行の結果を自動的に集めたりする仕組みではありません。

後で使う項目を集約結果に含める

集約範囲内の項目が、そのまま後続で全部使えるわけではありません。結果に必要なorder_id、sku、quantity、判定をAggregatorで含めます。注文ごとに分ける必要がある場合はGroup byにorder_idを設定する方法を検討します。異なる注文を一通にまとめたい場合は、逆に注文単位の分割が目的に合うかを確認してください。

空配列と全件除外の意味を決める

itemsが空の注文と、商品はあるが全件フィルターで除外された注文は別の状態です。AggregatorのStop processing after an empty aggregation設定により、空の集約でも後続へ進めるかが変わります。「対象なし」と通知するのか、通知せずレビューへ残すのかを業務で決め、空だから成功とだけ記録しないようにします。

件数を増やしてクレジットと通知数を見る

架空の1商品、複数商品、空配列、同じ注文IDの再送、二つの注文を確認項目にします。商品ごとの処理と注文単位の通知数を分けて数え、履歴で実際のモジュール実行を確認してください。配列の長さが増えると後続の処理も増え得ます。ここには実測の費用や処理速度は掲載していません。

集約は重複防止や日をまたぐ保管の代わりではない

Aggregatorでまとめた後でも、同じ注文を再実行すれば再通知する可能性があります。注文IDや商品IDに基づく処理状態を別に持ちます。週をまたいで蓄積する集計なら、台帳へ保存し、対象期間を決めて取得する設計にしてください。

• 期間を決めて週次レポートを作る
• 注文と通知の重複処理を防ぐ
• 処理数が増えたときの費用を点検する