Array Aggregator not aggregating?

Title.

My goal with using an Array Aggregator, is to have 1 Bundle of 20 Collections, that I’ll use a sort(;;) on.

What I get is 20 Bundles of 1 Collection each, and the scenario “flows through” per row.

It was previously suggested to me to use an Iterator to feed rows into the Array Aggregator, but it didn’t help with my goal of aggregating.

Am I misunderstanding what an Array Aggregator is, thinking that it collects inputs into a single array? If so, what aggregator module / method should I use instead?

For reference:
https://hq.integromat.cloud/en/help/tools/flow-control
Array aggregator is an aggregator module, which allows to merge several bundles into one single bundle.

Hi, seems that you didnt map your modules correctly, can you please share your scenario blueprint and module input and output, thanks!

1 Like

Hi Karim!

For work reasons, I cannot share the actual blueprint, but I have made a test scenario that’s a duplicate of my current flow

EDIT - updated the blueprint to make it closer to what I’m doing

blueprint (10).json (14.6 KB)

Looks like the iterator is doing nothing.

Remove it and set the “Source Module” of your aggregator to the Iterator before the HTTP module, where the actual bundles are coming from?

2 Likes

In the real scenario, there is an API call that generates the ids that feeds the query parameter of the second API call.

The second API call is expected to get called as many times as there are ids fed to it.

There is no actual Tools[9] and Iterator[10] in the real scenario, and these are only to mock the id return of the first API.

My focus is on what happens after the second API call, and that why won’t Array Aggregator aggregate the second API call’s returns into a single array?

Because the bundles are coming from whatever is before it.

If there is no first iterator, then try setting the source module to one of the modules before the second API call.

3 Likes

Update: so
(A) I put an iterator immediately after the first API call (instead of my using split() to parse through the ids),
(B) refactored so that it feeds the ids to the second API call,
(C) set the earlier iterator to be the array aggregator’s source module, and it now works as expected.

It’s a weird quirk that’s not well-explained when I took Make Academy :slight_smile: One kind of expects the array aggregator to
(1) aggregate whatever its immediate source gives out (whether it’s an iterator or otherwise), and
(2) it should not be dependent on an additional iterator placed somewhere in the flow; I still don’t have my head wrapped around why everything works after putting the iterator where it is

In any case, thanks for the help @samliew!

2 Likes

Nope. That’s not how it works. You need to set the source module to where the bundles are created/coming from.

Links

Here are some useful links and guides you can use to learn more on how to use the Make platform, apps, and app modules. I found these useful when I was learning Make, and hope they might benefit you too —

General

Help Center Basics

Articles & Videos

2 Likes

Adding this post so as not to be misunderstood.

Which is why I’m calling it a Make “quirk”, that an array iterator and array aggregator should technically be “paired”, whereas speaking in the general non-Make logical sense

In any case, thanks again!