---
schema_version: "1"
id: 3ad3ad91ae6b509224c3cc2b9b610bc8a6d69b914c255f131431c8ed41aab7bc
title: Migrating the Batch Module
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/migration-core-batch.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/migration-core-batch
source_site: docs.mulesoft.com
content_type: documentation
content_hash: d1a353e0faadc1dd57502dd9cd1706f37da1015e52a0481b2a92d04814b6a444
description: MuleSoft Documentation Site
release: "4.3"
latest: false
---
---
product: Mule Runtime
version: 4.3
---

# Migrating the Batch Module

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Batch module was introduced to handle Extract Transform Load (ETL) functionality.

What’s covered in this section:

- [Migrating the Batch Element](#batch_scope)

- [Migrating Record Vars to Vars](#record_var)

- [Support for Non-Java DataSets](#non_java_datasets)

- [XML Changes to Batch Elements and Attributes for Mule 4](#xml_changes)

## Migrating the Batch Element

In Mule 3, Batch was a top-level element, at the same level as a flow. In Mule 4, the `<batch:job>`
element is a scope that lives inside a flow so that it is easier to understand, invoke dynamically,
and interact with other Mule components.

This also means that there is no `<batch:input>` anymore. The role of the `<batch:input>` is now
accomplished by whatever set of processors are in the flow before the `<batch:job>` is triggered.

- `<batch:job>`: Even though Batch is a scope, it has a name. No Mule app can have two `<batch:job>`
  definitions with the same name. This allows better tracking and management when one single flow
  defines more than one job

- `<batch:execute>`: This operation does not exist anymore. Instead, just invoke whatever flow
  contains the bach job.

Mule 3 example

```xml
<batch:job name="batchJob">
    <<batch:input>>
        <poll frequency="10000">
            <sfdc:query ..../>
        </poll>
    </<batch:input>>
    <batch:process-records>
        <batch:step name="batchStep1">
          <mp />
          <mp />
      </batch:step>
      <batch:step name="batchStep1">
        <event processor/>
        <event processor/>
      </batch:step>
    <batch:process-records>
</batch:job>
```

Mule 4 example

```xml
<flow name="flowOne">
  <scheduler>
			<scheduling-strategy>
				<fixed-frequency frequency="10000"/>
			</scheduling-strategy>
		</scheduler>
  <batch:job jobName="batchJob">
    <batch:process-records>
      <batch:step name="batchStep1">
        <event processor/>
        <event processor/>
      </batch:step>
      <batch:step name="batchStep1">
        <mp />
        <mp />
      </batch:step>
    </batch:process-records>
  </batch:job>
</flow>
```

## Migrating Record Vars to Vars

Unlike a regular flow, Batch processes at the record level instead of message level.

In Mule 3, you use record-level variables (`recordVars`) to attach variables to a particular record,
just like you use Flow variables (`flowVars`) for the Mule message.

In Mule 4, variables (`vars`) replace `recordVars`. Variables are part of the Mule event in Mule 4.
From within the `<batch:step>`, you can modify a variable that existed before the `<batch:job>`
began executing, and you can do it for one particular record, without side effects on the other
ones.

The Mule 3 example here uses `recordVars` within an expression in a For Each component:

Mule 3 Example

```xml
<batch:step name="commitStep">
  <batch:commit size="10">
    <foreach>
      <expression-component>
        record.payload = 'foo';
        record.recordVars['marco'] = 'polo';
      </expression-component>
    </foreach>
  </batch:commit>
</batch:step>
```

The Mule 4 example here uses `vars` within an expression in a For Each component:

Mule 4 Example

```xml
<batch:job jobName="batchJob">
  <batch:process-records>
    <batch:step name="batchStep">
      <batch:aggregator doc:name="batchAggregator" size="10">
        <foreach doc:name="For Each">
          <script:execute engine="groovy">
            <script:code>
              vars['marco'] = 'polo'
              vars['record'].payload = 'foo'
            </script:code>
          </script:execute>
        </foreach>
      </batch:aggregator>
    </batch:step>
  </batch:process-records>
</batch:job>
```

## Support for Non-Java DataSets

In Mule 3, the batch input phase required a Java structure. So, for input data in formats such as
XML or JSON, you first needed to transform to Java, then make DataWeave use streaming in that
transformation to avoid running out of memory for large datasets.

For example, suppose you have this source data pushed to your app through an HTTP call:

Example: JSON Input Data

\[ { "name": "Luke Skywalker", "darkSide": true }, { "name": "Ben Solo", "darkSide": true }, {
"name": "Obi-Wan Kenobi", "darkSide": false } \]

In Mule 3, you need to transform that JSON to Java before passing it over, something like this:

Mule 3 Example

```xml
<batch:job name="forceJob">
   <<batch:input>>
     <http:listener path="/forceWielders" config-ref="forceListener" />
     <ee:transform>
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
                  output application/java
                  ---
                 payload
                }]]></ee:set-payload>
            </ee:message>
     </ee:transform>
   <<batch:input>>
   .....
</batch:job>
```

In Mule 4, Batch can automatically determine that the payload is a JSON array and perform the
splitting on its own, for example:

Mule 4 Example

```xml
<flow name="useTheForceBatch">
  <http:listener path="/forceWielders" config-ref="forceListener" />
  <batch:job jobName="forceJob">
    ....
  </batch:job>
</flow>
```

You no longer have to set streaming in Mule 4 because of the automatic streaming framework it uses.
So, when you migrate to Mule 4, you can avoid a transformation step.

## XML Changes to Batch Elements and Attributes for Mule 4

- Camel Case attributes: Following the Mule 4 DSL guidelines, and in order to improve consistency,
  all DSL attributes have been changed to camel case. For example, `max-failed-records` is now
  `maxFailedRecords`, `accept-policy` is `acceptPolicy`, and so on.

- MuleSoft removed the `filter-expression` parameter from the `` <batch:step>` `` element. This
  attribute was deprecated in Mule 3.6 and should be replaced with `accept-expression` parameter.

- The `<batch:commit>` is now called `<batch:aggregator>`.

## See Also

- [Batch Processors](https://docs.mulesoft.com/mule-runtime/4.3/batch-processing-concept)