What is our primary use case?
In our company we deal with a lot of data processing. Clients will send us extract files that we load into our system so that we can run calculations. And all of that is orchestrated using ActiveBatch automation. To summarize, we have software that we use to calculate values, but we need to receive the files from the client, get them to the right spot, and get them ready for processing. All of those steps are done using the automation tool.
The integrations we mainly use it with are FTP and SQL and we use a batch file or a script file to call our internal programs. It does have the ability to call PowerShell scripts and we do use some of those. We just don't have a need to use a lot of PowerShell because most of our software is designed using a different language.
How has it helped my organization?
The biggest example of the way it has improved things — and this is actually why we moved to ActiveBatch — is that most of our jobs are our processes that run overnight. That's the critical time for us because we have to load and calculate this data overnight so that the clients can have it in the morning. Our old automation tool would frequently have jobs that just failed, with no reason given. It would not track the history, so there was no way to determine if there was a pattern of failure. And it was difficult to restart jobs. That's what moved us to ActiveBatch: knowing that the job is going to run, and that if it does fail it's going to give adequate information as to why it failed. Typically, any failure in our case is data-related or due to code on our side. Rarely has it ever been an issue with ActiveBatch itself. Having that stability, especially doing our overnight processing, is the biggest benefit to our business from using ActiveBatch.
If you're a programmer, you can certainly write out scripts and design jobs that are similar to programs. But a lot of our technicians who use it do not have a programming background, and it's simply a matter of using the templates that are already provided. You do not have to have any kind of programming background to be able to use the software.
While we've never had a whole lot of scripting done, even with our old tool, with ActiveBatch it's very easy to have junior employees log into the system. They can learn how to create jobs. It's definitely something that's accessible by more junior level employees, as well as senior level.
It also has the capability for event-driven automation to trigger workflows based on specific emails, file events, FTP file triggers, message queues, date database modifications, tweets, etc. For us, the big one is a file trigger, when a file arrives on our FTP server in a certain location. We'll occasionally use a database trigger as well. And we use the scheduling capability that it has to run a job at a certain date and time. These abilities have definitely increased efficiency and reduced delays. It's mainly from the stability of the automation. Even with the old software, it had that same capability, but it just wasn't as reliable. It would just have odd failures that we never could quite explain, and the vendor could not either. ActiveBatch, having that stability and being able to use those triggers to automatically trigger our jobs and get them running overnight, greatly enhances our efficiency. Having a team manually do those things would take much longer.
I don't know if I could quantify the improvement in job success rate percentage, but when I joined this particular department it was right around the time that the transition was being made from the old automation to ActiveBatch. What I do know is that there were enough failures and instability in the old automation tool to trigger moving to a new tool, which is ActiveBatch. Since then, we have not had those types of issues. It's very reliable and very stable which is exactly what we need.
I would think there has been improvement in workflow completion times, just from the stability standpoint. The way we create and use jobs in ActiveBatch is similar to what we did before. If everything worked as designed, I imagine that the old tool and ActiveBatch would probably process things in the same timeframe. It's just that ActiveBatch is much more stable. There aren't as many failures. The speed factor, for what we use it for, would probably be similar with any automation tool because we use it for such straightforward, simple tasks. Based on all the other performance indicators, I would imagine it's just as fast, if not faster than other tools.
Because we're a pretty small company, using a tool like this doesn't necessarily reduce headcount, but it allows us to not have to add headcount.
What is most valuable?
We mostly use the fairly straightforward features of the solution:
- copying and moving files from one location to another
- FTP processes to send and receive files
- database queries to update certain data elements.
It's nothing super-complex, but these are things we would not be able to do manually without adding a lot more time to the process.
It's also very easy to restart jobs at a certain point, in the event of a failure. Things like that are things that we didn't want to have with some of our former automation tools: overall ease of use.
In addition, you can go to one screen and see every job that is currently running and what the status of that job is. You can scroll up or down and see jobs that ran in the past jobs and jobs that are scheduled to run in the future. It makes it easier to monitor jobs. A lot of our processes run overnight. We have a team that monitors the automation jobs to make sure everything's running and to correct any failures that may happen. They are able to easily see the status of everything using ActiveBatch, without having to click on multiple jobs to see an individual status. They can get a summary of it on the summary view.
It's pretty customizable, from what I can tell. We haven't had a need to customize a lot of things because most of what we do is pretty straightforward. But you can script out a PowerShell script and use some of the internal functions and features of ActiveBatch within the script. You could, theoretically, customize it pretty extensively. We just haven't had a need to do that very much.
What needs improvement?
The only thing is that it does have a little bit of a learning curve because it is fairly complex. You have to learn how it does things. I don't know if it's any worse than any other tool would be, just because of the nature of what it does. Like many things, you learn how to do something initially and then, a year or two later, you might find a better way to do it and you have to adjust how you did it before. So the learning curve is the hardest part. Even then isn't bad, because any tool is going to have that type of learning curve.
We're migrating to version 12 and I know they've made a lot of improvements that can help with navigating that application. I expect that would improve it.
Buyer's Guide
ActiveBatch by Redwood
December 2024
Learn what your peers think about ActiveBatch by Redwood. Get advice and tips from experienced pros sharing their opinions. Updated: December 2024.
824,067 professionals have used our research since 2012.
For how long have I used the solution?
We started migrating to ActiveBatch around 2012 so we've been using it for about eight years. We are currently on version 10 with plans to upgrade soon to version 12.
What do I think about the scalability of the solution?
We've never run into any bandwidth issues, but we're also a pretty small company. The number of jobs that we run is much smaller than a larger company would run. We've talked with other companies that use ActiveBatch and they have far more jobs running concurrently than we do. They have never expressed any issue with bandwidth either.
From my experience, it seems like it's very scalable. You can create jobs in a manner that they can be reused for multiple clients, using variables. We've never had any issue with the number of concurrent jobs running.
ActiveBatch is running around 300 jobs for us. As our company grows, we'll use it more and more. It's integral to our processing that we have built our business around. As we get more and more clients, we will be using and creating more and more jobs. Eventually, we'll probably need to add additional resources to help with that. It's as scalable as our company is.
How are customer service and support?
Their support is excellent. If we run into any issue, and we can't find a solution on the forums, we'll create a ticket with them and we'll get a response very quickly, especially compared to some of our other vendors. They've always been able to help out and find a solution or answer to our questions, which is great.
Which solution did I use previously and why did I switch?
Our previous solution was AutoMate BPA.
We switched because we needed stability. We also needed something that was easy to use where we could have certain functionality, like restarting jobs from different points and reusing steps for multiple clients. Those were things we just did not have in the old tool. Having that stability and the ability to see if a job failed and having adequate log information to indicate why it failed are the biggest reasons why we moved over.
How was the initial setup?
The technician who researched solutions and found ActiveBatch was the guiding force as far as getting it installed, set up, and configured. So I don't have a lot of experience with that side of it. I've mostly been designing how jobs should work and be built. The setup seemed like it was straightforward from what I could tell. I don't think it was super-difficult.
It took us a good year or two to fully convert all of our jobs to ActiveBatch. But that was because we had a large number of jobs that were in the old tool and we had to be careful about adjusting things that are in a production environment. We spaced it out a while to get everything converted.
Our implementation strategy was mostly looking at which clients had more complex jobs and which clients had simpler jobs, so that we could start with the simpler ones as we were getting our feet wet using the tool. Then it was just scheduling out which clients would be converted when and creating the jobs to mirror what we already had in the other tool. It was nothing too complicated.
What was our ROI?
We have definitely seen ROI. It's a critical component of how we do things now. It has definitely been worth everything we've paid so far, and more.
What's my experience with pricing, setup cost, and licensing?
From what I recall, the price was fairly in line with other automation tools. I don't think it's exorbitantly expensive, relatively speaking. It's definitely been worth every penny for us. It hasn't been the case that we have thought, "Oh, it's too expensive. We need to find something else." It's worth it for us, by a large margin.
In addition to the licensing fee, I believe there is a cost for how many different agents you need to put on servers. There's some additional licensing that you can get, that we haven't had a need for, where you can add jobs that work with VMware or other third-party tools, to open up that part of it.
Which other solutions did I evaluate?
One of our other technicians was the lead on finding a new automation tool. Along with ActiveBatch, he found three or four others that he thought might have good potential. I was on a few calls where they were demoing the software, and there wasn't really anything that fit for us as well as ActiveBatch did.
What other advice do I have?
Take the time to get a good feel for how it works. That's the biggest thing. Once you have that, start creating the jobs. I would expect that people will be very satisfied with how well it runs and the flexibility that the tool has.
In terms of execution on hybrid machines or across on-prem and cloud systems, it's not applicable for us at this point. All our stuff is hosted. We're not doing anything in the cloud right now, although that may be something that's in our future. But right now, it's just used for servers that we have in our data center.
We have a team of about six or seven people who use ActiveBatch at least a little bit. But only three of us are the "power users." ActiveBatch is designed to have different roles but all three of us do a little bit of all of them. So we haven't divided it out yet in terms of having an operations person or a design person. My role leans more toward designing jobs. The technician that found ActiveBatch, his role leans more towards the operation and administrative side of getting things installed and working on upgrading the application. The third guy does a little of both.
We're pretty satisfied with everything. Their support is great. It does everything we need it to do. There isn't anything that we're having to find workarounds for.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
