I've seen many shops with hundreds of OS-level jobs to manage — file copies, system reboots, defrags, FTP jobs, and so forth — and the admins there all have done the same thing: They go from server to server to check on job success, or to troubleshoot a dependent job that failed, and then manually walk through the entire process again if a dependent job has failed, because all the subsequent jobs failed. This is no longer necessary with ActiveBatch.
ActiveBatch 5.0, from ASCI (Advanced Systems Concepts Incorporated), is the ETL (extract, transform, and load) tool of the operating-system world. It can run scheduled OS jobs from any server in your environment and can add workflow, notification, error handling, and centralized management.
Upon job failure, ActiveBatch can prevent subsequent jobs from even firing, and when any job fails, the solution can trigger a number of actions, complete with workflow, to correct known problems and restart the process from any point. The solution also can alert an admin not only if a job fails, but if it’s taking longer than usual or taking up too many resources.
Installing ActiveBatch is very easy. You just have to have a server and a database picked out. After installation, there is a bit of a learning curve to get past, as it’s a very intricate program with a lot of nuances to learn.
I have experience with Version 4.0 of ActiveBatch, and I found that ASCI has made such significant improvements to Version 5.0 that even I had to learn a few basics before I could really do much with it. After you’ve nailed a few basic concepts, you can get up and running fairly quickly. Yet, even after you’ve worked with it for several months, you’ll continue to discover new things about it.
I tested several types of jobs with varying workflows. One of my favorites is the event-based execution of jobs, jobs set to run based on a certain type of event, such as a WMI (Windows Management Instrumentation) event, or, more commonly, the presence of a file in a directory.
It really pays to think outside the box and come up with your own implementations of this functionality. It can be used in a number of creative ways, such as for monitoring, diagnosing, and fixing system problems.
For example, you could easily set up ActiveBatch with a job that checks certain system performance counters and takes appropriate actions based on the results. It can even e-mail your ticketing system to open a help desk ticket if it’s unable to resolve the issue. This is very similar to the scenario I tested, and ActiveBatch performed flawlessly.
I also set up a scenario that had ActiveBatch copying and deleting files between servers, e-mailing results, and performing certain actions when a step on the workflow failed. I set this test to run against three servers at intervals of two minutes for slightly more than a month. ActiveBatch never skipped a beat. It was solid, fast, and very easy to monitor and manage.
Really nice views
ActiveBatch provides many different views of your enterprise jobs. The System View is the most useful for operations staff, as it allows them to see the current status and immediate result of every job in the queue. The icons in the System View show job dependencies and workflow, and are color-coded based on the current run status and the last execution result.
Placed on a large monitor in a NOC (network operating center), it is easy for anyone to see when there’s a problem, and where it occurred. The Run Book shows job schedules in a calendar view, whereas the Daily Activity View shows job executions in a detailed list.
There’s also no need to switch servers when a job must be created, run, troubleshot, or reconfigured. With the centralized execution queue, every aspect of working with jobs on every server in your enterprise is right at your fingertips.
I timed the creation and management of these jobs both through ActiveBatch as well as natively from each server’s console. Without ActiveBatch, I couldn’t program the complex (or even simple) dependencies I wanted, nor was I able to create any kind of real error handling. Windows’ native job scheduler simply doesn’t have workflow capability, nor can you do any kind of reporting like you can with ActiveBatch.
The only problem I had with ActiveBatch was in executing certain types of legacy jobs. Processes that rely on mapped drives or other older practices may not perform as expected in ActiveBatch. This may or may not prove problematic, depending on how easy the process is to alter.
ActiveBatch 5.0 is a real enterprise-level job scheduler. Although complex to learn, it truly saves time by providing centralized job execution, management, and monitoring.
The solution’s highest mark is for its capability to automate a complex workflow of jobs between any number of disparate systems against different operating systems and provide visual confirmation of job execution statuses in one view. The capability to alert based on performance is another boon.
Ease of use (20.0%)
Overall Score (100%)
|ASCI ActiveBatch 5.0||10.0||8.0||9.0||8.0||9.0||9.0|
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
It's all about knowing how to build an open source community -- plus experience running applications in...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Among dozens of options for developing Go programs, Gogland, Visual Studio Code, and Cloud9 rise to the...
Real-world uses are emerging, but to gain broad deployment the HoloLens headsets and related gear must...
The potential of deep learning seems boundless, but developers are still learning how to put it to...
What we learned at the RSA Conference: The security industry is failing its task of keeping users and...