When should you use a Bundled Batch Job?

In F&O, you can easily upgrade your custom batch jobs from a “classic” batch job to a bundled batch job. But what would doing that mean or change how work gets done? First, let’s review a visual.

This shows the basic process for scheduling and execution of a bundled batch job. This can look sort of similar to a individual task model batch job but a bundle in this context is a group of tasks that will be executed using 1 thread. A bundle batch job has parameters the define a start and an end that has at least more than 1 elements in it where individual task modeling has a parameter that defines an individual unit of work – 1 task for 1 thing to be completed.

Pros

The first advantage of using a batch-bundled batch job is execution sequence. In the data contract for the batch-bundled batch job, you can define how the workload is defined for what is processed using Lists, ranges, or anything you like that indicates a subset. However that is defined, the batch job will execute items in the order presented for the given subset. You can change this behavior also but by default, if given a list, we’ll iterate over the list in the order presented. This means if you prepare your data contract values in a specific order for a reason, the batch job will execute the work units in that order. This can help with transactions posting in a specific order rather than transactions posting in any order on a given transaction date. 

The next advantage is this approach reduces batch system overhead in some scenario. Finding a batch job, a batch task, and work to execute takes time to execute for the batch system. When using Individual Task Modeling, each work unit has this overhead from the batch system. Batch-Bundling will have this same overhead but only for each bundle rather than each task so the overhead gets absorbed by the entire bundle rather the individual task. Compared to a “classic” batch job, Batch-Bundling has higher overall overhead but since we’re grouping work units, its a small amount of additional overhead. Consider a classic batch job with 1,000 record to process with 1 batch job with 1 batch task. That would have an overhead amount of 1 – only 1 batch task needs to start. A batch bundled batch job with 50 work units per bundle would have 1 batch job, 20 batch tasks with 50 work units in each. This would have overhead of 20 – 20 batch tasks needs to start. Finally, consider Individual Task Modeling with 1 batch job, 1000 batch tasks with 1 work unit in each task. That would have an overhead amount of 1,000 in that instance.

Related to reducing overhead, an additional benefit is that we get some parallelism per bundle – if we build the batch job to take advantage of it.Using the previous example of 20 bundles of 50 work units, we can have as many bundles processing as the batch system has capacity for. If we have 8 threads available for our batch-bundled batch job, we can process 8 bundles at any given time. This gives us some parallelism compared to a “classic” batch job which would be single-threaded for all work units where work units would be represented by each record presented by the Query and QueryRun.

Finally, batch-bundling allows you to group together the same or similar tasks into logical groupings. Consider that you want to create a batch process for Sales Orders where you post a confirmation, pick list, packing slip, then invoice. You can design your code and batch job to create the bundles for the confirmation postings, then another set of bundles for the pick lists, another set of bundles for your packing slip and so on. You can also make each step dependent on the prior step using batch constraints so you can have a group of confirmation work, a group of pick list, and so on, and know that it’ll post in the order created in the batch bundle. We have total control over what posts when and under what conditions each bundle of work units can progress. This gives us great control for advanced orchestration scenarios. This also simplifies management as we can manage based on bundle rather than work unit.

Cons

One of the biggest disadvantages with batch-bundling its since we are grouping some work units together, if we don’t plan out the processing of the work unit well with appropriate amounts of logging and error handling, it can be difficult to identify what went wrong in some scenarios. Errors can also cascade if we have dependencies in the batch system. We can get around this, typically, by building the work unit logic class under the assumption that everything before “now” has failed and what you’re about to do will also fail – until proven otherwise. An example of how that can something simple into something not-so-simple can be found here.

The next disadvantage is related to advanced orchestration scenarios. There is the potential for increased wait times on some bundles dependent on other bundles and similarly on some work units in a bundle. Consider the example earlier where we want to post SO confirmations, pick lists, and so on. If we are having any performance issues with one bundle or posting type, that will slow down other parts of the batch job or the bundle. This is ordinarily not an issue as time will fix most issues but this is something to consider. In some way we are getting the worst of a “classic” batch job being single threaded and an Individual Task Modeled batch job in one place. We can mitigate this with monitoring and adjusting bundle size based on the performance issues that present. We can set batch bundle size anywhere from 2 to any number larger than 2. You’ll have to tinker, record, and suggest a bundle size that works best for whatever you’re trying to achieve.

Another potential disadvantage is that task within a bundle are execute sequentially, preventing the bundle from truly becoming parallel within itself. Depending on design and use, that could be a desired outcome or just a known limitation of this style of batch job. During execution, the bundle is just a subset of a larger “classic” RunBaseBatch so we get more throughput in terms of the overall set but not inside the subset. Consider you have 1k work units to complete, each bundle would get 200 of those work units so we have 5 bundles. That fastest execution for the entire batch job would be the fastest 1 bundle could execute. Overall, an improvement compared to a RunBaseBatch workload but we’re just taking how that executes and breaking it into smaller chunks and we likely get some benefits of different bundles executing at the same time across the batch system. This provides better overall throughput but we’re just taking a big problem and dividing it into smaller problems.

General Guidance on When to Use ( or Not )

This style of batch job is great for tasks where the workload in and of itself doesn’t have dependencies on anything else inside the workload. For example, if we have a batch job posting Sales Order Packing Slips, that would be a good fit for that style of workload. All warehouse transactions have already occurred elsewhere and each sales order doesn’t care about any other sales order so they can post in any order and no one sales order cares about any other sales order. Next, this style of batch job is still a good option to minimize batch system overhead while optimizing throughput. “Classic” batch jobs offer the least amount of overhead typically but this style is a good contender in that area. We have a little more overhead but a lot more throughput so it’s more than a fair trade off. Lastly, this style is a good fit where our tasks are part of a logical grouping or a single set in a larger business process. This ties back in with our first point; Sales Orders Packing Slips don’t care about any other Sales Order Packing Slip. Similarly, this style of batch job is good for batch jobs that do similar things such as post packing slips for physical sales, then another that posts packing slips for virtual sales ( like sales of egift cards ). We would have batch jobs setup to post all the packing slips for the various scenarios then another set of batch jobs to invoice sales orders based on other various scenarios. 

This style of batch job isn’t great where you’re looking for maximum throughput. Throughput for this style is improved as compared to classic but if throughput is the thing you’re most interested in, another option may be better. Additionally, if the tasks in the bundle don’t have a somewhat predictable runtime at a per work unit level, this will result in batch job run times that are also unpredictable. As a general positioning statement, a classic batch job that takes 10 minutes to run is considered “better” from an administrative perspective than a version of that same batch job as a bundle batch job that takes somewhere between 1 and 10 minutes. When scheduling batch jobs, admins like to see reliability above performance because if we have to run batch jobs as part of a length process, we want to be able to carve out windows if time to schedule various parts of a batchable process. Lastly, as a minor consideration, debugging can be tricky because we can have x number of bundles running and if we’re interesting in debugging an issue present only on Sales Order 123, we have to schedule a job just for that order rather than try to sift through different bundles trying to find the execution for a specific parameter.