Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.8)
  3. Reference
  4. Batch Processing
  5. Batch Processing Reference

  6. Using MEL with Batch Processing

Using MEL with Batch Processing

Mule runtime engine version 3.8 reached its End of Life on November 16, 2021. For more information, contact your Customer Success Manager to determine how to migrate to the latest Mule version.

All of the functions and attributes below are usable within MEL expressions anywhere in Mule where the context makes sense.

These attributes can be referenced in any element inside or after your batch job:

Attribute Description

recordVars

Use to access record variables by name.

totalRecords

Total number of records in the batch.

loadedRecords

Number of records loaded in Loading phase.

processedRecords

Number of records processed at this point.

failedRecords

Number of records processed and failed in at least one step.

batchJobInstanceId

ID of the batch job instance

inputPhaseException

Exception object for exception in Input phase.

loadingPhaseException

Exception object for exception in Loading phase.

completePhaseException

Exception object for exception in Complete phase.

MEL Functions that Involve Batch Jobs

These functions can be used anywhere in your batch jobs, in any component that supports MEL expressions.

Function

Description

isSuccessfulRecord()

Boolean function indicating processing status of record.

isFailedRecord()

Boolean function indicating processing status of record.

failedOnInputPhase()

Boolean function indicating whether or not batch processing failed at the Input phase.

failedOnLoadingPhase()

Boolean function indicating whether or not batch processing failed at Loading phase.

failedOnCompletePhase()

Boolean function indicating whether or not batch processing failed at Complete phase.

failureExceptionForStep()

Receives the name of a step as a String argument. If the current record threw exception on that step, then it returns the actual Exception object. Otherwise it returns null

getStepExceptions()

Returns a java Map<String, Exception> in which the keys are the name of a batch step in which the current record has failed and the value is the exception object itself. If the record hasn’t failed in any step, this Map will be empty, not null. Also, the Map contains no entries for steps in which the record hasn’t failed.

getFirstException()

Returns the Exception object for the very first step in which the current record has failed. If the record hasn’t failed in any step, then it returns null.

getLastException()

Returns the Exception object for the last step in which the current record has failed. If the record hasn’t failed in any step, then it returns null.

These MEL expressions evaluate batch step failures. Consider that failed asynchronous processes inside your batch step would not be considered as step failures by the runtime.
For example, if you have this batch step:

<batch:step name="Batch_Step">
  <file:outbound-endpoint path="output" outputPattern="test.file" connector-ref="File" responseTimeout="10000" />
</batch:step>

Because the file outbound endpoint is one-way, the message is dispatched and the batch step continues processing. So no step failure would be recorded by the runtime. This would mean that the MEL function isFailedRecord() would still return false, even if the outbound endpoint inside the batch step fails.

You can force the runtime to record the outbound-endpoint failure as a batch step failure by referencing the outbound endpoint as a synchronous process:

<batch:step name="Batch_Step">
    <logger message=" #[server.dateTime]: payload is: #[payload]" level="INFO" category="BATCH_STEP_BEGIN" />
    <flow-ref name="create-file" />
</batch:step>

<flow name="create-file" processingStrategy="synchronous">
    <file:outbound-endpoint path="src/test/resources/output" outputPattern="test.file" connector-ref="File" responseTimeout="10000" />
</flow>

Or by enclosing the asynchronous process inside a transactional scope:

<batch:step name="Batch_Step">
    <logger message=" #[server.dateTime]: payload is: #[payload]" level="INFO" category="BATCH_STEP_BEGIN" />
    <transactional action="ALWAYS_BEGIN" doc:name="Transactional">
    	<file:outbound-endpoint path="src/test/resources/output" outputPattern="test.file" connector-ref="File" responseTimeout="10000" />
    </transactional>
</batch:step>

Example Use of A MEL Function in a Batch Job

For example, suppose you have a batch job with the following Batch Step:

batch+function1

Here you can add the following expression into the Set Payload transformer:

batch+function2

In this case, this expression will return a Java Map for the current record where the key is the name of the batch step and the value is the exception object. This expression will of course only evaluate batch steps through which the current record has already passed, it can’t evaluate any batch steps that may come after it.

See Also