With Tools Release 9.2.5.x on E1 9.2, JD Edwards now has the option to enable and configure Virtual Batch Queues (VBQ). Batch processes (UBE and Reports) are a fundamental aspect of a healthy Enterprise One system. With the implementation of the new VBQ feature JD Edwards now adds many key enhancements around flexibility and elasticity to the system.
Once VBQ has been setup, it acts as a Queue Management system before jobs are sent to a specific server. The system allows us to define multiple servers to a virtual queue and configure that virtual queue to be the destination for jobs. If we setup three batch servers within a virtual queue and send a job to that queue, the system will determine which server should execute it. For example, if this virtual queue is thirty wide (10 for each server) and we have jobs waiting, the next job in line for that queue will go to the first server in the cluster that becomes open.
The queue width is also flexible based on configuration of the VBQ. So, we can adjust based on server resources for each server in a virtual cluster. You may have a VBQ defined to run across three batch servers, although one of those has less RAM installed. So, we configure the two larger servers to run 10 wide each and the third, smaller server to only be 5 wide. The result will provide a VBQ which can process 25 jobs concurrently across the three servers.
A critical factor that was required for this to be successful is around single threaded queues and the ability to retain the functionality it provides. The new VBQ system does manage to retain the power of single threaded queues, and now allows us to manage it across multiple servers. We can define a VBQ as single threaded within the system, so Enterprise One will ensure that jobs run in order even if that queue spans across multiple servers.
Another key aspect addresses an issue that has challenged users around failed jobs due to simple data issues. Functionality has been included to provide the ability to resubmit a job which ended in error, without having to re-enter data selection and processing options. This will save time and frustration for end users working within the system.
System administrators will be excited about VBQ for multiple reasons. The flexibility that this feature offers will allow more options in supporting a live production system.
· System maintenance will be more flexible as we can pull a server out of the mix to do maintenance and not hold up jobs from processing. They will just process on the other servers defined within the VBQs.
· The ability to re-run bulk jobs in error due to a hardware failure. With the ability to move or resubmit jobs between servers and/or job queues, we can recover much faster than before.
· Provide flexibility to utilize compute power of the entire system to manage processing jobs will help balance the resources across the system. Even if this is just to provide some additional compute power for month-end/year-end activities, so normal day activities are not impacted.
Some things to consider around VBQ as of the 9.2.5.1 release. This functionality is only supported on Windows, Linux and UNIX platforms which are support by Enterprise One 9.2 technical requirements. Due to the native queue management design on the iSeries, VBQ is not supported on that platform currently.
Server Congruence is also a factor for servers that will be grouped into a VBQ virtual host. They need to be configured identical in most aspects. Such as Operating System, E1 port, DB type, OS time zone, and printer definitions to name a few. The VBQ feature also requires that Batch storage in the Database be enabled. Which will centralize all the reporting output for easy retrieval and management.
VBQ is another great tool which enhances JD Edwards and show how it continues to improve as we move forward. This will be very helpful for current systems and allows for many new options in the future of JD Edwards.
- Todd Burton is a Senior JD Edwards Technical Architect with Main Street APPs.