Make Array Aggregator: preserve fields and group the right records

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Choose the boundary and the grouping key

Make aggregators combine incoming bundles within a source-module operation. The Source Module identifies where aggregation starts. Group by can produce a separate output bundle for each distinct key. Values from source and intermediate bundles are not automatically available after aggregation; include required values in the aggregator's configuration. The empty-aggregation setting controls whether processing stops when no bundles reach the aggregator.

Our design recommendation is to write the final destination object before configuring the aggregator. Specify whether it represents one order, one customer or a whole run. The correct boundary follows that contract, not the point on the canvas with the fewest visible modules.

A synthetic two-order example

Assume a safe source operation provides five transformed line bundles: three belong to order A and two to order B. Your proposed destination needs one summary per order. Grouping by the stable order ID should produce two summaries containing three and two lines respectively. Those expected counts are specific to this sample, not a claim that every source operation spans multiple orders.

Write the intended summary schema: order_id, customer_reference and an array of line_id, quantity and validated unit amount. These are editorial example fields. Decide whether customer_reference is repeated within each line or carried separately, then inspect the exact final structure. Do not assume an intermediate module's field remains accessible downstream merely because you can see it earlier in the run.

Configuration and inspection procedure

1. Identify the module that emits the set of bundles to combine and select it as the aggregation source.
2. Choose the stable grouping key required by the destination object.
3. Select every field needed after the aggregation, including identifiers used for reconciliation.
4. Run the two-order sample without external writes and inspect output bundle count and membership.
5. Confirm that no line from order A appears under order B and that required identifiers survive.
6. Connect the destination only after the output matches the declared schema.

Test empty and inconsistent data

Suppose a filter removes every line for one order. Decide whether that should produce no action, a review item or an explicit empty summary. Verify the selected empty-result behavior with synthetic input; an empty result should not accidentally create a customer-facing document with missing items.

Also test two bundles with the same order ID but conflicting customer references. Our recommendation is to reject or flag that conflict before creating a summary, rather than quietly taking an arbitrary value. An aggregation operation groups records; it does not establish that their business fields agree.

Reconcile totals without guessing currency

For a simple fictional sample, three lines might carry amounts 10, 20 and 30 in the same declared currency and with quantity already accounted for. The expected sum is 60. If your input instead stores unit prices, multiply by quantity under an explicit rounding policy before comparing totals. Do not combine different currencies into one unlabeled number.

Choose aggregation only when the destination needs it

If the destination accepts independent line updates, retaining individual bundles may be easier to recover after a partial failure. Use aggregation when the contract requires a combined object or summary, then keep the input IDs and output key in the run record. This article provides a design and validation example, not a tested accounting calculation or a performance benchmark.