The last new feature we have is a simple one which comes quite handy when you need to read through logs. As you know, batch jobs are just programs processed in batch mode, and each time the job is triggered, a new job instance is created and tracked separately. Each of those instances is unique and therefore has a unique ID.
By default, Mule automatically generates an UUID for it. However, because UUIDs are not easy to read, correlating a log message to the actual execution can be challenging. It is even more difficult when several job instances are running at the same time.
To solve this problem, we added a new property to the batch:job definition called “Job Instance ID”:
This attribute takes an MEL expression which evaluates the results each time the job is triggered. Then the output value is used as the job instance ID.
This attribute is:
- Optional: If not set, then Mule will generate a UUID as usual.
- An MEL expression: Constant values are not allowed.
- Unique: You have to make sure that the MEL expression always returns unique values. If the expression returns a non-unique ID, an error will occur, and it will not create a job instance.
Let’s see how a simple batch log looks like without using this feature:
As you can see, the job instance ID is ’20ae8500-d1a7-11e5-af90-6003089b5498′ which is not meaningful at all. It is hard to correlate that ID to an actual execution, especially if you have many jobs running at the same time or if you run many jobs a day.
This is how the same log looks with the custom job instance:
As you can see, the job instance ID is now ‘Job from 2016-02-12T13:34:10.481-03:00’ which makes it a lot easier to identify the instance from its timestamp. Depending on how often your jobs trigger and depending on what business purpose they serve, you might choose to use another criterion to build the ID.
This update was a short one and hopefully, it was useful too!
Thanks and enjoy the 3.8 batch improvements!