Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Core Components
  4. Batch Processing
  5. Refining Batch Steps Processing

  6. Batch Job Instance ID

Batch Job Instance ID

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Users of batch processing frequently need the ability to determine a Batch job’s instance ID during the execution phases of a Batch job.

The Batch job instance ID is useful to:

  • Pass the local job instance ID to an external system for referencing and managing data

  • Improve the job’s custom logging

  • Send email or SMS notifications for meaningful events

Example

Mule exposes the batch job instance ID through a flow variable of key batchJobInstanceId. That flow variable is available at the beginning of the input phase. The flow variable is also available in every step and in the on-complete phase.

batch job instance id c4362

The log output produces the following:

com.mulesoft.mule.runtime.module.batch.internal.engine.DefaultBatchEngine: Created instance '7dc5cad0-ab09-11e8-a790-9801a7b055d3' for batch job 'CreateLeadsBatch'

Custom Batch Job Instance ID

You can use a Mule expression to specify a unique identifier for each batch job by passing a Job Instance Id attribute that takes a MEL expression.
Note that constant values are not allowed for batch jobs and if the MEL expression returns a previously seen value, Mule throws an exception and does not create the job instance. If you don’t set a job instance ID, Mule auto generates a UUID to assign to your instance.

The UUID generated for the job instance described above is ba01e1a0-f5c7-11e4-9414-10ddb1daeb6d. As you can tell, it’s not a human readable identifier making it hard to correlate to an actual execution and considering you could be running multiple jobs at the same time, this ID is not meaningful at all.

In order to guarantee uniqueness, you can set the Job Id to take server date through the MEL expression:
#['Job From ' + server.dateTime.format('dd/MM/yy hh:mm:ss') + '.' ].

This names the execution instance Job From 15/01/16 05:23:12.

com.mulesoft.module.batch.engine.DefaultBatchEngine: Created instance Job From 15/01/16 05:23:12 for batch job contacts-to-SFDCBatch
com.mulesoft.module.batch.engine.DefaultBatchEngine: Starting input phase
com.mulesoft.module.batch.engine.DefaultBatchEngine: Input phase completed
com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Starting loading phase for instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch'
com.mulesoft.module.batch.engine.queue.BatchQueueLoader: Finished loading phase for instance Job From 15/01/16 05:23:12 of job contacts-to-SFDCBatch. 3 records were loaded
com.mulesoft.module.batch.engine.DefaultBatchEngine: Started execution of instance 'Job From 15/01/16 05:23:12' of job 'contacts-to-SFDCBatch'

The logs of a properly identified instance are easier to read.

<batch:job jobName="CreateLeadsBatch" maxFailedRecords="1000" jobInstanceId="#['Job From ' + server.dateTime.format('dd/MM/yy hh:mm:ss') + '.' ]">
	<batch:process-records >
		<batch:step name="LeadExistsStep">
			...
		</batch:step>

		<batch:step name="LeadInsertStep" acceptExpression="vars.leadNotFound">
			...
		</batch:step>
	</batch:process-records>
	<batch:on-complete >
		...
	</batch:on-complete>
</batch:job>

See Also