ActiveBatch by Redwood Reviews

ActiveBatch controls just about everything in our organization. We do server monitoring with our EDI feeds being inbound and outbound. We do Oracle processing with it. 

It is very comprehensive for what we do and a central point of everything in our organization at this point.

We have some things coded out to execute processes on systems internal to us, but nothing out of the cloud. We have web based products that are internal and made available to our internal users. We have some external users who use these web based products. We control those from within ActiveBatch where we do remote logins and can control some of the processes. This is for internal and external clients' availability.

It reduces the load and manual efforts on everybody's parts. With a thousand jobs running on a daily basis, it allows our programming staff to focus on other things rather than deal with manual programming efforts, taking quite a load off our programming staff. 

The nice thing about ActiveBatch is once we have created a specific job that can be easily be replicated to another job, then minimal changes have to be made. Reduction of coding is substantial in a lot of cases. The replication of one job to another is just doing a few minor tweaks and rolling it into production. This decreases our development costs substantially. 

Automated integrations have helped us build end-to-end workflows. When we send an ACH to the bank, it used to be that a report would had been generated, then somebody had to call the bank and provide the bank with the totals. We are calculating all that now within ActiveBatch, then sending an automated email to the bank informing them of what is contained within the actual ACH. This has eliminated the need for several people in accounting or finance to have to deal with this work. It runs flawlessly. Though, it took a while to develop, it's a good case example.

We do have FTP file triggers and file triggers internally. We don't have to wait for somebody to say, "Hey, we've posted a file. Can you process it?"  The nice thing about ActiveBatch is we can specifically look for triggers, pick stuff up, and process it the minute it hits. So, it takes that step out of the equation of using internal or external people, and asking, "Something's been posted. Can you take care of it?" Instead, it's done and out of the way. This reduces delays.

I find all the features valuable. 

A lot of our server monitoring has becoming more critical. We monitor CPU loads and disk space requirements. Those are becoming more helpful to us from an automation standpoint, where it makes business decisions on returns. It really helps out the entire IT department and the entire company, as it takes a lot of the manual effort away from a lot of people.

It takes a lot of the manual effort off a lot of people from having to continually look at information. We make business rules within jobs. If something is wrong, it will get somebody out of bed in the middle of the night and let them know there is a problem. Rather than people coming in the morning, we have people who get up in the middle of the night and start working. Because when there's a server issue, that just creates a whole problem. This eliminates a lot of that since we catch these problems. We're taking a proactive approach to our internal structures.

The solution provides us with a single pane of glass for end-to-end visibility of workflows. The nice thing about ActiveBatch is you can see at a glance what is running and what's going to run (future runs). It gives us a good snapshot of everything that's going on, which is something that was lacking for years. With our window pane, we can see exactly everything that will happen at a glance.

The console is extremely flexible. We have incorporated things into ActiveBatch that a lot of people never thought possible, e.g., a lot of the server monitoring stuff and we have over a 1000 jobs that run out of it on a nightly basis. From an automation standpoint, it is really reducing the need for so much manual effort, which creates its own problems because we have a thousand jobs. Somebody has to look to determine if there are any issues. So, we have business rules put in place in all our jobs which try to make it easier for everybody. We do banking information, EDIs, specific automation for other applications, service monitoring, and reporting. A lot of the stuff is called from other systems and imported into ActiveBatch, then manipulated. It's so comprehensive.

It may require some weird programming of things. However, most of the time, we can solve the problem and set solutions in place, then it's carried forward to other jobs. 

I would really like to get into Active Directory stuff with it, but that creates a problem in our security audits, etc. We have to tread carefully down that road.

Moving to version 12 will be a real challenge for us because we have to put in a whole new server, as we are on one now that is obsolete. Plus, when we build the whole thing out, we will need to: 

• Build out a test environment. 
• Go through every single one of the jobs, then test out everything on maneuvers.

We will have to engage ActiveBatch in a contractual relationship to help us with this because it will be a huge project.

Eight years.

I have a great impression of the stability. We just keep adding to it, and this thing never fails. It just runs. Comparing that to our back-end systems where there are always problems, ActiveBatch just continually runs. That's what I've told our executive team. I said, "The only time there's a failure in this company is when your back-end systems screw up."

We have limited users in this product. We have a couple of developers (EDI specialists) who look at some of this stuff. We probably have several hundred people who end up with the end result (report distribution) of ActiveBatch via email. We distribute mainly via phones.

I have emailed Active Batch about a couple of things. I have always had great experiences with the technical support guys. Some of them just go above and beyond their call of duty. They are fabulous to work with.

Everything was a manual effort before ActiveBatch.

There are so many different components that we had to integrate with Oracle. There was a lot of back-end work which had to be done when the server was originally built out. Missing those steps would have ended up creating some problems. We had to go through it a couple of times before we got everything straightened out. With the Oracle integration, there are a lot of components that have to be installed correctly. Even when migrating to version 10, we had some issues with that too. There are a lot of internal components with Oracle.

This is sort of where ActiveBatch system falls down just a bit. While it's easy to say, "Your Oracle people need to deal with this." Our Oracle people know nothing about ActiveBatch. There is this back and forth, where ActiveBatch says, "Your Oracle people should be dealing with this," and Oracle people say, "No, we don't know anything about ActiveBatch." Then, it all falls back on me as to what happens. Nobody is taking responsibility. This is the biggest failing for ActiveBatch. It would be nice if Advanced Systems Concepts, Inc. could just say, "We'll help you with this entire process."

We contracted with ActiveBatch to help move us from version 9 to 10. It took us two or three times to get it right because there were components that ActiveBatch wasn't clear on about needing to be installed. They finally came back and helped us on this because we had an engagement contract with them. However, it took a couple of times to do this. The problem in a production environment is you don't have a lot of leeway for downtime. The jobs that we have, they run 24/7/365. Trying to find an open slot to do migrations is pretty difficult.

With the automation efforts that we have done over the years, we have gotten our money back. We save thousands of man-hours annually.

The use of the solution resulted in an improved job success rate percentage of 90 percent. It reduces manual efforts. Once you take manual efforts out of the equation and put business rules in, we find the failures that occur are usually external to the company, not internal anymore. Job failures during the day are a handful out of a thousand jobs, and usually an external issue. It is external vendors not following their rules, though we have business rules and alerts set up to inform them. We send emails back to external clients, and say, "Something was supposed to be posted, and it wasn't posted." In that sense, it has eliminated a lot of those manual effort steps as well. It is all self-contained in ActiveBatch.

Use of the solution has resulted in a 60 to 70 percent improvement in workflow completion times. 

I don't think we've ever had a problem with the pricing or licensing. Even the maintenance fees are very much in line. They are not excessive. I think for the support that you get, you get a good value for your money. It's the best value on the market. I've worked with a lot of products in my career, and this is by far one of the best products I've ever seen. You're getting your value.

We did evaluate other products before purchasing.

We asked for a proof of concept on this solution that ActiveBatch provided. We looked at the scalability, integration, ease of use, and constructing automated jobs. Those were the driving forces in the selection of these products. Their job libraries are so nice. You don't have to be a rocket scientist to figure some of this stuff out. 

It is a great product. I can't speak enough about it. We haven't found anything that we can't overcome in ActiveBatch. When they put this product out, they thought it out and put a lot of nice stuff into it. There are features we haven't touched yet, even though we have been on it for so many years.

We have never really uncovered anything that's a problem. It is a well-thought-out product and one of the best that I've ever worked with. I would rate this product as a 10 out of 10. I really like this product.

Think about what you want to automate, then put a process flow in place. For somebody who wants to start this, take one job and put a process flow in place, then develop it within the system. Once you get one product in place, it is pretty easy to replicate it. Initially, to get started on some of this, it can be a horrifying effort. It looks overwhelming, but once you get going on this stuff, get one job in place, and figure out what to do, then it's pretty easy to replicate across the board.

All our back-end systems are Oracle driven from an integration standpoint. Oracle interfaces are very nice which helps us a lot because we can do a lot of coding and take care of a lot of the back-end Oracle stuff. However, we don't use external things, like Amazon, as that is against our security

We just started looking at email triggers, but have not implemented any at this point.

We used this solution for automating our batch processing which includes data load, refreshing data marts and refreshing the Power BI reports. We were using it for end-to-end automation, primarily for data delivery to reporting. We used every end-to-end process. The company is a customer of ActiveBatch. 

The solution is easy to configure and it's simple to develop new features, batch processing, or set up new process automation. It's also user-friendly for the operations team. I had experience on both sides working initially in operations, supporting the batch processing, and later on in development. Configuration is straightforward and it's easy to integrate with any system. All systems can be connected under one product rather than having to buy different tools to automate batch processing. The PowerShell feature or automatically using VBScript and the like offers good value. 

We haven't explored the cloud aspect of the solution because it's very costly. I think it should be provided as a free feature, which would be wonderful for organizations unable to take on the added expense of moving to the cloud. 

I used this solution for eight years up until a month ago when I moved to a different company. 

Yes, it is a stable solution but there are ongoing legacy issues that have carried through over the last few versions and which haven't yet been resolved. If there is too much batch processing happening some processes don't run properly. It doesn't happen all the time and we're able to manage it. 

The solution is scalable. We had around 50 people in the company using ActiveBatch as a tool. It was embedded more into the business side so it was used by the finance department, and the risk department, and it was used in customer marketing.

Customer support was helpful in providing the workarounds. Their knowledge base is very clear and they were very helpful for us in terms of creating more options. They provided a lot of the APIs and we were able to do our own DIY kinds of things. We created our own solutions using ActiveBatch and did our own monitoring so we could get enriched reporting. They were very helpful and provided us with good information.  

The product can be installed on any machine and it's very straightforward. If you know what you're doing it doesn't take long at all. Our implementation was all carried out in-house.

I'm unaware of the licensing costs but I know there is an additional fee for connecting to an SAP environment. 

This is a very good tool and I'm really missing it in my new company because I don't have a robust enterprise-wide scheduling tool and a really good tool for automating end-to-end.

I rate this solution eight out of 10. 

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.