--- schema_version: "1" id: 5e3226b79c6fe411a0019010b8fa1603e69109ae25fc27068a8f28251a116e43 title: Aggregators Module Multiple Examples collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/aggregators-module/1.0/aggregators-multiple-examples.md canonical_url: https://docs.mulesoft.com/aggregators-module/1.0/aggregators-multiple-examples source_site: docs.mulesoft.com content_type: documentation content_hash: 5a15012aea98b241f29f6f62ce3aa257140d7c04d1c88cf7addad92c65252030 description: MuleSoft Documentation Site release: "1.0" latest: false --- --- product: Aggregators Module version: 1.0 --- # Aggregators Module Multiple Examples > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A common use case for an aggregator is to store multiple values, then process them as a batch later. You can accomplish this aggregation using the **Size based aggregator** scope. Suppose that the data that you want to aggregate is a person’s name that was previously stored in a variable with name `personName`, and you want to process batches of 100 elements. Once all the data is collected, you want to execute some logic defined in a flow with the name `whatToDoWithAllTheseNames`. So, you could use this: ```xml #[vars.personName]

``` If you do not want to execute an action for every new element because that would cause too many executions, you can use `incremental-aggregation`. For example, you could execute an action every time your list of names increases by an increment of 10% as shown here: ```xml #[vars.personName]

``` You can assume that the logic to be executed is in another flow named `partialAction`. If you do not want to wait forever to fill every batch, you can process all the events that you have even if the `maxSize` value is not reached, by setting a timeout for your aggregator. The following example sets the timeout to 10 seconds. ```xml #[vars.personName]

``` To make sure that the logic that processes all aggregated elements executes once a timeout occurs, you also need to include a listener, for example: ```xml

``` For this case, the data types that come from the `aggregation-complete` route and `aggregator-listener` are the same. So, for the execution of the flow `whatToDoWithAllTheseNames`, it does not matter where the data comes from. However, with this configuration, when the aggregation is complete, the flow `whatToDoWithAllTheseNames` triggers twice: once from the `aggregation-complete` route `flow-ref`, and again from the `flow-ref` in the flow with the `aggregator-listener`. To avoid multiple executions of the same logic, wrap the `flow-ref` value `aggregator-listener` in a `choice` component that uses the `isAggregationComplete` attribute to check for an incomplete aggregation: ```xml ... #[vars.personName]

...

``` In this example, the `flow-ref` is called only when a timeout triggers that flow. Lastly, you realize that you need to process each person according to nationality. This information comes in a variable. However, in this case, assume that you want to process every person from the same country together in the same batch. You can split them accordingly with a group-based aggregator. For example, assume that the person’s nationality was previously stored in a variable with name `personNac`. In this case, the flow should contain this: ```xml #[vars.personName]

``` The flow also needs a listener for timeouts: ```xml

``` Notice that the example does not configure an eviction time in the aggregator. That is because the default value is `0`, which means the eviction occurs directly after the group is released, which is the desired behavior. Therefore, if a group finishes or is timed out, a subsequent value can be added to the group without being rejected. ## See Also - [Aggregators Module Examples](https://docs.mulesoft.com/aggregators-module/1.0/aggregators-examples) - [Aggregators Module Reference](https://docs.mulesoft.com/aggregators-module/1.0/aggregators-module-reference)