IT Central Station is now PeerSpot: Here's why

ActiveBatch Workload Automation OverviewUNIXBusinessApplication

ActiveBatch Workload Automation is #5 ranked solution in top Managed File Transfer (MFT) tools, #5 ranked solution in top Workload Automation tools, and #7 ranked solution in top Process Automation tools. PeerSpot users give ActiveBatch Workload Automation an average rating of 8 out of 10. ActiveBatch Workload Automation is most commonly compared to Control-M: ActiveBatch Workload Automation vs Control-M. ActiveBatch Workload Automation is popular among the large enterprise segment, accounting for 64% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 27% of all views.
ActiveBatch Workload Automation Buyer's Guide

Download the ActiveBatch Workload Automation Buyer's Guide including reviews and more. Updated: July 2022

What is ActiveBatch Workload Automation?

Orchestrate your entire tech stack with ActiveBatch Workload Automation and Enterprise Job Scheduling. Build and centralize end-to-end workflows under a single pane of glass. Seamlessly manage systems, applications, and services across your organization. Eliminate manual workflows with ActiveBatch so you can focus on higher value activities that drive your company forward.

Limitless Endpoints: Use native integrations and our low-code REST API adapter to connect to any server, any application, any service.

Proactive Support Model: 24/7- US-based support and predictive diagnostics.

Low Code Drag-and-Drop GUI: Easily build reliable, customizable, end-to-end processes.

ActiveBatch Workload Automation was previously known as ActiveBatch.

ActiveBatch Workload Automation Customers

Informatica, D&H, ACES, PrimeSource, Sub-Zero Group, SThree, Lamar Advertising, Subway, Xcel Energy, Ignite Technologies, Whataburger, Jyske Bank, Omaha Children's Hospital

ActiveBatch Workload Automation Video

Archived ActiveBatch Workload Automation Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Shaun Guthrie - PeerSpot reviewer
Senior Operations Administrator at Illinois Mutual
Real User
Provides critical functionality in moving from our mainframe to a distributed environment
Pros and Cons
  • "As far as centralization goes it's nice because we can see all these processes that are tied to this larger process. The commissions, FTP processing, the reporting, the file moves to the business users — all that is right there. It's very easy to read. It's easy to tie it together, visually, and see where each of these steps fits into the bigger picture."
  • "The Jobs Library has been a tremendous asset. For the most, that's what we use. There are some outliers, but we pretty much integrate those Jobs Library steps throughout the process, whether it's REST calls, FTP processes, or file copies and moves... That has helped us to build end-to-end workflows."
  • "One thing I've noticed is that navigation can be difficult unless you are familiar with the structure that we have in place. If someone else had to look at our ActiveBatch console and find a job, they might not know where to find it."

What is our primary use case?

ActiveBatch is used for scheduling our nightly batch processes. That is our main use at this point. It includes billing, processing, claims, commission statements, and a lot of reporting. It's all tied into that batch process. We do use the built-in REST call process for nightly printing, coming out of that batch cycle. We distribute the nightly reports out of the batch cycle to different departments using ActiveBatch. It's used for FTP processing every week coming out of the weekly commissions process. The most important part to us is to keep those nightly batch cycles in an easy to read format, which is where ActiveBatch Plans come into play. We run these cycles in four different environments, from development to production and a couple stops in between. Keeping all of those jobs separate from one another is key for us. Outside of batch, we do run a process every five minutes throughout the day during business hours to scrape data from our mainframe entry system to our new policy administration system. As people enter claims into the mainframe system, those claims get moved over within five minutes, rather than waiting for the mainframe batch cycle to run that night and those claims not being seen until the next day. That saves us up to 24 hours. The business end-users can get that data within five minutes now.

How has it helped my organization?

ActiveBatch has allowed us to move forward quickly with our modernization effort, to get off of the mainframe and to move that data to a distributed environment. It has been huge for us to use ActiveBatch to run these nightly processes: everything from Dev to QA, UAT, and Production. Those are all cycles that we run every night to allow different users to test processes that they're working on in each of those stages, to get them into production and off the mainframe. With the systems we're using now, it's a lot easier with ActiveBatch. The mainframe is so manual. If there's a problem with some mainframe code, it requires a call to a developer, but our new system works great with ActiveBatch because everything is built into that system. There's no JCL code or mainframe COBOL code, up front. Our batches just work seamlessly between ActiveBatch and our new administration system. We've had no problem with our batch processing from that point of view. Whereas with the mainframe, it's a struggle at times. If we have a problem with a job and it cancels, we may be waiting three hours for a developer to get online, troubleshoot, test, and get a fix in place so we can finish the cycle. We've not had that issue with ActiveBatch.

What is most valuable?

A lot of the built-in processes are among the most valuable features because when just starting out, although I went through the ActiveBatch Boot Camp — and I've got a couple of other people who went through it as well — it was a little overwhelming, not having used the product. We found it easier once we were using the product and then doing refreshers on the Boot Camp or doing the deep dives that ActiveBatch provides. Even the Knowledge Base articles allow us to grow and let us know what we can use in our environment. We're able to use the Plans, rather than seeing individual jobs within all four of our environments. Seeing all of these jobs individually would be overwhelming to try to easily decipher workflows, whereas everything is nested nicely within each Plan for us. It makes it very easy to read the next day, and to look at how each cycle ran. It also helps with troubleshooting if there's an issue with one of them at night. As far as centralization goes it's nice because we can see all these processes that are tied to this larger process. The commissions, FTP processing, the reporting, the file moves to the business users — all that is right there. It's very easy to read. It's easy to tie it together, visually, and see where each of these steps fits into the bigger picture. Other important features for us are file triggers, file constraints, and job constraints, because of the sequential nature of the batch process. The file triggers have made our processes more efficient and reduced delays. It might be minimal at this point, but it would still be a manual process that would have had to be done. Our second-shift operator would have to wait each night for that mainframe cycle to finish and then manually trigger certain processes within each of our ActiveBatch cycles. It's also a very flexible product. We're just over a year in and we're still getting our feet wet and realizing its potential. One thing I am anxious to roll out — and I've tried to push some business end-user meetings, but it's still a little early in the process as everyone has been so busy with the overall modernization effort — is the Self-Service Portal. It will allow the business users to run processes on-demand, rather than putting in a ticket to have IT do it for them. This would also allow other IT users to see any processes they may be testing, in the ActiveBatch environment. In addition, the Jobs Library has been a tremendous asset. For the most part, that's what we use. There are some outliers, but we pretty much integrate those Jobs Library steps throughout the process, whether it's REST calls, FTP processes, or file copies and moves. We do use some process job steps to call out external batch processing through external scripts, but most of what we're using is what is built-in, at this point. That has helped us to build end-to-end workflows.

What needs improvement?

When our mainframe process ends each night it sends out an email to certain users that the system is up, so that they can log on and do work on the mainframe at that point. We tried to use that email as a trigger for our ActiveBatch printing processes but it didn't work out too well. I believe it ended up being a bug that they're going to address in a future release. But at the same time, that was an easy fix. We were able to change that from an email trigger to a file trigger. Now we have the mainframe job, in addition to sending out that email, create four text files that will trigger our four batch cycles through ActiveBatch. That has worked out great for us. One thing I've noticed is that navigation can be difficult unless you are familiar with the structure that we have in place. If someone else had to look at our ActiveBatch console and find a job, they might not know where to find it. That being said, I have been using that search function a lot lately. That search function is definitely your friend.
Buyer's Guide
ActiveBatch Workload Automation
July 2022
Learn what your peers think about ActiveBatch Workload Automation. Get advice and tips from experienced pros sharing their opinions. Updated: July 2022.
610,518 professionals have used our research since 2012.

For how long have I used the solution?

I have been using ActiveBatch for about a year-and-a-half.

What do I think about the stability of the solution?

I've not had any major issues with ActiveBatch at all. It seems extremely stable. We've not had any downtime. We've had issues here and there with different processes, but nothing that has affected the overall environment. Granted, we don't have very many users on it; it's mostly processing at this point.

What do I think about the scalability of the solution?

In terms of bandwidth, we've not had an issue. There are no limitations that I can see.

How are customer service and support?

The email support can be hit-or-miss. Overall, I've had a pretty good experience with it. They're quick to reply and they let you know exactly what they need. You get it to them and they dig into it and get back to you. Sometimes it can be cumbersome emailing back and forth and waiting for replies. Overall, it's been good.

Which solution did I use previously and why did I switch?

We didn't have a previous solution. We were looking for a product that could handle a company-wide insurance systems modernization project. This project has been in the making for years. It boiled down to putting new products on our distributed systems, migrating data from the mainframe to those distributed systems, and eventually sun-setting the mainframe. This approach makes more sense since it's simpler to start with new products rather than migration to begin with and this also allowed us a nice starting point with ActiveBatch.

How was the initial setup?

Out-of-the-box, it was a challenge to understand the best way to structure it for our system. Obviously you don't know what you don't know. Once we started using it, we realized the best way to lay it out for ourselves and it became easier and easier over time. I've had to move things around a great deal to make it easier because we weren't sure, when starting, how to set it up, as far as our environment goes with its file structure and object structure. As far as objects go, it's pretty straightforward. It's like any other file structure. It's just a matter of knowing what you need for your environment, which is something you learn as you go: You need these things in this folder, you need those items in that folder. Do you want all your FTP processes in one folder or do you want them underneath a certain project that they're tied to? As far as setup and configuration go, they're very straightforward. I've never seen an issue with that or with upgrading. The planning stage took a while. We got the product and then I and another operator went through the training, which we did in a week. The actual deployment has been scattered. The initial deployment went well, but it was staggered because there were, and still are, different pieces flowing in, a little at a time. It won't be really set until we get all of our business on this platform. It's as set as it can be right now. The actual deployment slowly fell into place. I hate to say it took two months to deploy this product. It didn't. But to get to where we were comfortable running that first batch cycle, it probably did, but that's no fault of ActiveBatch. That's just developers getting the pieces to us and then us figuring out how to use ActiveBatch in the most efficient manner.

What about the implementation team?

We implemented ActiveBatch on our own, but we did work closely with the provider of our new policy administration system and learning how the two products would work together for batch processing. I have worked very closely with someone there to tie in with ActiveBatch. I don't believe he had experience with ActiveBatch prior to that, but one of his coworkers did and he called on that coworker from time to time. We mostly worked on using ActiveBatch to call those external processes through the scripts that were provided to us. That's where we had to get them involved because that was also a new product to us, and it still is. So we were trying to learn how that product worked, how ActiveBatch worked, and how to get them to work together. For ActiveBatch there were five or six people within Operations/Infrastructure involved in the deployment. We're a small-to-midsize company with a couple of hundred employees.

What was our ROI?

It's hard to say how many hours it has saved because it is new. There have been a lot of hours put into learning the product. For instance, putting SSIS packages in has required a lot of Knowledge Base research on ActiveBatch's site. The Knowledge Base is tremendous there. I've really never had an issue finding plenty of information, sometimes more than enough information, to decipher. But in terms of man-hours, at this point, it's just figuring out the system and how to set up these jobs to work together. Those savings will definitely really be seen down the road. But our return on investment is because it has allowed us to move forward with this project. Even with just using new business, it's allowed us to move incredibly fast when it comes to putting these batch processes in place. So far there's limited data and each cycle runs in 10-20 minutes, but at the same time, on the back end, it's providing that foundation. So we'll know what we need to do when we have more data. For example, currently, load-balancing is counterproductive. There's so little processing going on that it would take longer to load balance this 10-minute cycle than it would be to just run straight through.

What's my experience with pricing, setup cost, and licensing?

The cost is outside the scope of my job responsibilities. Obviously we're using it, so it was worth the cost. I think it's a tremendous product. I don't know what the cost is compared to others, but having seen the results, it's worth it. We recently signed up for the certification courses and training, which is money well spent. Anything involving training is money well spent, but especially with a new product that is going to be a major part of your environment and your business. From what I've seen, the videos and online training through ActiveBatch are tremendous. They provide examples, and they actually provide a test environment with jobs that you can put into ActiveBatch. You're able to run these jobs, make changes to them and work through the training with them.

Which other solutions did I evaluate?

Maybe at a higher level in our company there was some research into other solutions and came to ActiveBatch as the best solution. As far as I know, it has always been ActiveBatch. I was hearing that name long before we had it in hand.

What other advice do I have?

Jump in. That's what we did and we're seeing the results. I can't stress enough how much it's allowed us to move forward with this modernization project. Overall, it really has been seamless. There have been a lot of hours on my part, learning the system and researching different processes that I need to put in place for the cycles. But to anyone else, the end result probably appears seamless. It is a lot of work learning it, especially if you have no prior knowledge of enterprise job schedulers and that type of flow. But ActiveBatch provides a wealth of information; their Knowledge Base is tremendous. The support gets back to you pretty much immediately. It might take them a couple of days here and there while they're researching or working with their engineers to replicate a problem. And sign up for the training, for sure, as well as the additional training certification. In the year since I took the Boot Camp and worked my way through putting this in place to meet our immediate needs, when I revisited the Boot Camp, I found there was a ton of stuff that you forget that you can be using. In that initial Boot Camp, you're really not sure exactly what you're going to use it for. Once you start seeing ActiveBatch processes in your system and go through that training again, you realize, "Oh yeah, I can definitely see where I can tie this in," or "Yeah, we can definitely use that here or we could use this function in this way instead of that way." It will definitely help you become more efficient. It's easy to learn the basics. It's just a matter of knowing what you need to know, what you need to use it for. At that point the ball is in your court because, while it can definitely be challenging, at the same time it's very rewarding to see things fall into place the way you pictured them. It is a very powerful tool and we've only barely scratched the surface. Keep learning. I'm learning more and more processes within ActiveBatch every day. It's definitely an ongoing process. What I've learned from using ActiveBatch is that the sky's the limit. With all the additional, third-party licenses — Active Directory, System Manager — at this point it seems endless for us. I honestly don't know where we would be without it at this point. We just started testing SSIS packages, as we're trying to move those off of the SQL environment and into ActiveBatch, rather than setting up schedules within SQL. We started testing one, out-of-the-box, and we're ready to move that to production this week. There will be more after that. We aren't leveraging the cloud. We are trying to get into that area but, at the same time, we're focused on this part of our modernization project right now, getting off of the mainframe first and onto the distributed systems. Then we can take it another step. We don't have any of those additional licenses for integration with things like SharePoint, Informatica, or ServiceNow. Those options are definitely something my manager has his finger on. He knows those are available and he realizes ActiveBatch can definitely be leveraged to a greater extent. Our developers work outside of ActiveBatch. It's mostly me who puts together the ActiveBatch jobs. The developers are mainly mainframe developers who don't touch ActiveBatch, or they are application developers who tie everything together into this entire modernization effort. There are a ton of products tied into that effort, ActiveBatch being one. ActiveBatch "brings the others together," such as printing from a third-party vendo, our insurance suite for billing, claims, commissions, etc. A new underwriting tool will also be tied in eventually. So most of the developers are working on those other applications. Direct users of ActiveBatch boil down to me and a couple others who are familiar with Activebatch but who are not as familiar with it as I am. Currently, any issues with the batch processes are more the result of a learning curve for us. I would rate the solution at eight out of 10. I'm a stickler with ratings. Nine would be the highest I would ever give anything because nothing is perfect. Here, it comes down to the fact that the navigation can be clunky at times, but I think that's more on you to learn. One thing ActiveBatch could do is provide more examples of real-life business use and business case examples, that show how others have structured their systems. That would probably be a big help. They do tell you how to organize jobs within Plans and you can nest things that way, but more real-life examples would probably have helped me to see how other businesses are using it or how their folder or their object structures are set up. I love the product. It's exactly what we were looking 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.
Georg Johansen - PeerSpot reviewer
Operations Manager at Statkraft AS
Real User
Our business users are able to set up and maintain their own jobs
Pros and Cons
  • "We use the main job-scheduling feature. It's the only thing we use in the tool. That's the reason we are using the tool: to reduce costs by replacing manual tasks with automated tasks and to perform regular, repetitive tasks in a more reliable way."
  • "It could be easier to provide dashboards on how many jobs are running at the same time; more monitoring."

What is our primary use case?

Most of the jobs are for the automation of processes, but we also use it for IT operations, including monitoring. We execute over 20,000 jobs daily.

It's moving data files and doing a lot of calculations in hydrology and the like. The business users are maintaining their own jobs, setting them up, configuring, and maintaining them. They only contact us, in IT,  if there are any problems. 

ActiveBatch is completely on-prem but the rest of our organization has many different kinds of infrastructure and locations, both in the cloud and in 16 countries. We have about 4,000 employees.

How has it helped my organization?

The automation has saved us many hours although I can't say exactly how many.

We're able to create workflows without coding.

I would imagine it has also resulted in an improvement in workflow completion times as well.

Our IT organization is using it for monitoring. We get information by running checks using ActiveBatch to obtain information to provide to the monitoring systems. It helps us keep systems up and to receive early warning about problems.

What is most valuable?

We use the main job-scheduling feature. It's the only thing we use in the tool. That's the reason we are using the tool: to reduce costs by replacing manual tasks with automated tasks and to perform regular, repetitive tasks in a more reliable way.

It's quite customizable because it supports many different platforms and technologies, and it covers almost everything we need to set up different jobs in our environment. We are using it mostly for our Windows and Unix servers and we are using different triggers, for example, Apache ActiveMQ. It is used by many different applications and systems. We use various databases, including Oracle, SQL Server, Microsoft, as well as Active Directory.

We are at the beginning of implementing agents in our Azure cloud. We haven't used that part very much yet but it will be used. We are moving more and more systems from on-prem to the cloud, so it will increase gradually.

What needs improvement?

It could be easier to provide dashboards on how many jobs are running at the same time; more monitoring.

For how long have I used the solution?

We've been using ActiveBatch for at least 10 years. We're on version 11 but we are planning to upgrade to version 12 in a couple of months. 

I'm not an end-user, I'm just responsible for making sure it's working. I troubleshoot if something is wrong and I do upgrading and installing.

What do I think about the stability of the solution?

It's pretty reliable. If it's organized and configured in an optimal way it works pretty well, but it requires a lot of planning. For example, you have to make sure that end-users don't have too many privileges because they can mess things up. It's very important to plan carefully before implementing.

We have had some issues in one of our installations in Germany, but they are still on version 10, which is quite an old implementation. They will replace that with the new version 12 in the near future.

What do I think about the scalability of the solution?

The scalability is quite good. You can add more agents. We haven't had any performance problems or issues with it.

The number of jobs and the number of applications that take advantage of ActiveBatch are growing constantly within our company. 

Which solution did I use previously and why did I switch?

Other than scheduling in Windows, I don't think our company had a previous solution.

How was the initial setup?

ActiveBatch was already implemented when I came to this company, but I have been here for a couple of upgrades.

Some parts of the setup are straightforward and some parts are more complex. The main features are pretty straightforward to set up but when it comes to the features that require an internet information server, it's a bit more tricky to set the secure connections and certificates, etc. We struggled a bit with that but we had good support from the vendor. They were able to make it work.

The implementation itself doesn't take a long time, but it takes a lot of planning: Security, execution agents, and the like. 

There are two of us who work with ActiveBatch maintenance, but it's not a full-time responsibility. We have between 100 and 200 people who transact with it. Some of them have read-only access so that they can view the jobs.

Which other solutions did I evaluate?

I also have experience with CA Workload Automation. It has been some years since I worked with it but it's the same concept and the same features but doing things in slightly different ways. 

What other advice do I have?

Start with a simple, small version and try some simple tasks to see how effective it is.

Using  ActiveBatch I have learned that the potential for reducing costs using an automation tool is huge, and that when the business becomes aware of it they really embrace the product.

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.
Buyer's Guide
ActiveBatch Workload Automation
July 2022
Learn what your peers think about ActiveBatch Workload Automation. Get advice and tips from experienced pros sharing their opinions. Updated: July 2022.
610,518 professionals have used our research since 2012.
Peter MacDonald - PeerSpot reviewer
Senior IT Architect at a pharma/biotech company with 5,001-10,000 employees
Real User
Makes the environmental passback of an SDLC process seamless
Pros and Cons
  • "What ActiveBatch allows you to do is develop a more efficient process. It gave me visibility into all my jobs so I could choose which jobs to run in parallel. This is much easier than when I have to try to do it through cron for Windows XP, where you really can't do things in parallel and know what is going on."
  • "I can't get the cleaning up of logs to work consistently. Right now, we are not setup correctly, and maybe it is something that I have not effectively communicated to them."

What is our primary use case?

We use it for a variety of different tasks, most of which are related to data management tasks, such as scheduling, processes related to updating business intelligence reporting, or general data management stuff. It's also used for some low level file transfers and mergers in some cases. 

We use the solution for execution on hybrid machines, across on-prem, and cloud systems. We have code that it is executed on a cloud environment, various Windows and Unix servers.

We are on version 11, moving to version 12 later this year.

How has it helped my organization?

We found that the solution created simplicity for us with our workflows and process automation. It gives me the folder and job name, then I'm done. I don't have to remember a plethora of things and that makes life a lot easier. Once you get it setup and have it configured, you don't have to remember it anymore. It allows you to focus on doing the right thing. 

I find it super flexible. Every time that I ask if the solution can do something, they say, "Yes." I have not been able to come up with a challenge so far that they have not been able to do.

It definitely allows the ability to develop the workflow. It has reduced the amount of coding. Some groups don't pay attention to that, as they are very much an old school group. I am trying to get people to do things differently, but that's just changing habits.

One process may at some point time run across five different servers in parellel before coming back to a final point of finishing. They built that in, where it say, "Every time we do certain things, execute this package." All I have to do is drag that package into the master package and master plan. It's very modular. 

All our workflows are efficient. This solution allows for tighter integrations across environments where you don't necessarily want developers cross pollinating each others' code. It's more or less about securing code. I have people who are experts in doing PowerCenter. They don't have any idea what they're doing in other solutions. You don't want them accidentally editing the wrong code. Therefore, it helps keep related things isolated, but allows them to communicate.

For code maintenance, it's really simplified it. For things that are coded, like day-to-day Unix or Windows level batch type jobs, this means I don't have to rewrite the code and I can easily migrate it from the environment. I can do this by leveraging variables and naming practices. I can basically develop code, do development, migrate it through our four environments, and not made changes to the code at all. It makes the environmental passback of an SDLC process seamless.

What is most valuable?

One of the great features that they have implemented is called Job Steps. It is a much more mechanical way to control processes. It allows us to connect to external providers. For example, we were a big Informatica shop. The development time to create a job that can execute a task or workflow (once you have the initial baseline set up) takes you about a minute to say, "I created this new job in Informatica. I have created an equivalent job to run the batch, then about a minute later, it was done." It improves the development time to market and getting things done.

What ActiveBatch allows you to do is develop a more efficient process. It gave me visibility into all my jobs so I could choose which jobs to run in parallel. This is much easier than when I have to try to do it through cron for Windows XP, where you really can't do things in parallel and know what is going on.

Improvement in workflow completion times has to do with optimization. The ability to do true parallel submittal of jobs, then be able to pay attention to the status of those job simultaneously to know when they are done, that is what creates the optimization.

The solution provides us with a single pane of glass for end-to-end visibility of workflows. It has a very broad, deep scale vision of what's going on. You can go down to an individual job level or see across the whole system and different groups. Because we roll out by project area, each project has their own root group folder that they use to manage their routines. We don't have a master operational group yet that is managing it. Therefore, each of group does its own operational support for it. However, if I look at things in it, there are a lot of shared things that we have put in there. If a machine is taking too long, I can go focus on that. E.g., why is it taking so long? Then, I can let people know that we have a particular routine that is running poorly.

What needs improvement?

I can't get the cleaning up of logs to work consistently. Right now, we are not setup correctly, and maybe it is something that I have not effectively communicated to them. This has been my challenge.

For how long have I used the solution?

I have been using this solution since 2007: 13 years.

What do I think about the stability of the solution?

The stability is rock solid. The four failures that we have had are related to issues we've done to our server or environment. Mostly, they are self-inflicted failures. There was a bit of cross pollination for what we were doing with security procedures where we experienced interruption. ActiveBatch hadn't updated itself directly to handle that situation.

We use the solution’s API extensibility. It has helped with the stability. It allows us to know when a job fails. If there's a problem connecting to a server or a job fails because something has gone wrong with a server, then we know very quickly. 

Four people are needed for development and maintenance of this solution. I am the primary admin but I don't support the solution on a day-to-day basis. I have a secondary gentleman, who like me, is also an admin. There are two others who primarily deal with the database. There's not a lot to it, except for the log stuff. When it comes to individual job failures, that's not our domain. That's the domain of each group maintaining their space. We also manage security issues.

What do I think about the scalability of the solution?

We are not the biggest shop out there. In our production environment, there are about 10 group who are doing work on a daily basis. Our user base is primarily developers and a few technical business analysts. There are approximately 50 to 100 users.

We have administrators, operations people, and developers. Administrators have full control across all environments. Operators have the ability to execute and see things across many of the environments. Developers can only work on a nonproduction event. 

For what we are doing on a relatively modest machine, ActiveBatch hasn't had any issues.

I haven't had to scale it yet. It has been a simple server for 13 to 14 years now. I haven't had to go to multicluster. We have a failover setup. However, we don't use that for parallel processing. It is more just for failing. 

How are customer service and technical support?

I'm on a first name basis with many of their engineers and developers. I have passed on some challenging things since my history goes so far back. They have always been very responsive to answering questions and providing the right knowledge base article. They are open to suggestions and very interactive.

Which solution did I use previously and why did I switch?

We first implemented this a number of years ago, it took our processes from several hours overnight, and not knowing if those jobs failed until we checked in the morning, to having an ActiveBatch team as an overnight team who watched jobs for us. Though, sometimes they would take an hour or two before they realized something had failed. Now, we have it so that team is responding within minutes. The alerting that texts and emails you has improved our ability to respond in a timely fashion.

How was the initial setup?

We installed versions 5, 6, 8, 9, and 11. Upgrades have always been seamless. It has been able to recognize code from previous versions, even 10 years ago, and update it.

Every time we do a redeployment, we go through the same process. We develop, upgrade the dev environment, and have people check to make sure their job still work. We then take that environment and migrate it to our test environment where we totally check it. That usually goes faster because we are just moving the database forward, checking to make sure everything works, and then moving onto the next page. Typically, we do a new server for production. We don't upgrade in place. I've done the upgrade in place without a problem in the dev environment, and it does go faster. I find it very clean, and I've not had a problem. Most of the issues are related to consumers of the tool.

We have only used it in one scenario. It took us a bit of time to get it setup as we have two halves of our processes. One is the data management process that happens multiple times a day. When that is completed, we want see reporting based on these processes. What we have is an event base that is executable. The viewable data sets are in different folders so these two groups don't actually see each other. That is routine, but they are able to read and have scheduled events.

What about the implementation team?

I installed it. To install it and get the environment up and running, it takes less than a day. Once my database is up and I have access to install the software, it takes an hour or two for me to get it up and running.

What was our ROI?

Over the years that I have used this, it has probably saved us several hundred hours of development time for other teams and my own. 

The solution has absolutely resulted in an improvement in job success rate percentage. We can see what the problems are and isolate them sooner. We are able to catch these problems and alert people.

It allows for lower operational overhead.

What's my experience with pricing, setup cost, and licensing?

I buy features when I have need of them.

What other advice do I have?

Right now, we only use the Informatica AI and Informatica PowerCenter. We are looking at  a ServiceNow integration. Some of the other ones, like Azure, we don't need right now as we continue to grow it organically. It's more as teams migrate technologies. We want to have an opportunity to have a conversation with them, and say, "Hey, come in and do it this way."

We are not using all the features yet. E.g. we don't use any load balancing variables.

I would rate the solution as an eight to nine (out of 10).

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
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.
Data Warehouse Operations Analyst at a leisure / travel company with 1,001-5,000 employees
Real User
Map View feature makes it easy to see what the dependencies are; we get a visual, top-down look at what flows are running
Pros and Cons
  • "One of the valuable features is the ability to trigger workflows, one after another, based on success, without having to worry about overlapping workflows. The ability to integrate our BI, analytics, and our data quality jobs is also valuable"
  • "The thing I've noticed the most is the Help function. It's very difficult, at times, to find examples of how to do something. The Help function will explain what the tool does, but we're not a Windows shop at the data warehouse. Our data warehouse jobs actually run on Linux servers. Finding things for Linux-based solutions is not as easy as it is for Windows-based solutions. I would like to see more examples, and more non-Windows examples as well, in the Help."

What is our primary use case?

We use ActiveBatch to run the data warehouse production batch schedule, which is 24/7. We run, on average, about 200 distinct workflows each day to update the warehouse. And once the warehouse tables are loaded, we trigger our business intelligence reports and our analytics reports. We also use ActiveBatch to run a software tool called iCEDQ for data quality, as well as some Alteryx jobs.

Our production servers are in a co-location, and the solution is deployed onsite there.

How has it helped my organization?

Before we had ActiveBatch, we used the Informatica Workflow Scheduler, and we would have to start a downstream workflow, but have it wait for the completion of the first one by a trigger file. So "Workflow B" would be waiting for a control file that said "Workflow A" is done. If we had to do reruns — sometimes we would create a control file by mistake and that would throw off the next day's run — and we'd have to do manual reruns. With ActiveBatch, it's very easy to say, "Workflow A is done, run B," and onward: "Run C, Run D," as soon as they're done. You don't need to worry about whether a control file was created, or how long is the job going to wait for. It gives you much simpler and easy-to-understand control of the flow of jobs, as they run.

Using ActiveBatch hasn't really reduced our code base because we would be developing these workflows in Informatica if we weren't using ActiveBatch. But the scheduling and integration into the batch schedule for something new are much simpler and save us a little bit of time, now that we have everything developed, for the most part. We may go a month without adding anything to our schedule and we may go four or five months without adding anything to the schedule, but it gives us an easier understanding of the flow of the data and helps us make sure dependencies are met in a more straightforward fashion than through the Informatica scheduler.

ActiveBatch hasn't really improved our job success rate percentage. If a job fails, we still get our failure messages from Informatica, and in some cases from ActiveBatch. The biggest benefit is that the biggest issue we were having was the timing of all of the downstream applications from the warehouse, and it has greatly improved that.

And it has saved man-hours, although it has not reduced headcount. It has saved man-hours in that situation when we would have issues and our old scheduling solution would break down because of them. This allows us to not have to worry about how to start the downstream applications, based on the warehouse. I would estimate it saves us about 20 hours per month.

What is most valuable?

One of the valuable features is the ability to trigger workflows, one after another, based on success, without having to worry about overlapping workflows. 

The ability to integrate our BI, analytics, and our data quality jobs is also valuable. We used to have everything set up just based on time: Run the data warehouse until five in the morning, run BI at 5:30 in the morning. There were times that we missed the deadline so that when the BI jobs would run, the data would be incomplete, or we had a big gap in time where we were missing out on starting early. It has really saved us a lot of man-hours compared to when we would have a data issue and we would have to manually restart all of the downstream jobs, after the warehouse.

ActiveBatch also provides us with a single pane of glass for end-to-end visibility of workflows. That simplifies the process when we check to see if things have run or how they're running. The Map View feature makes it easy to see what the dependencies are. It's helpful to have a visual, top-down look, from start to finish, at what flows are running when you need to look into that.

In terms of the unlimited bandwidth, as far as I can tell it's handled all of our volume without any issues whatsoever. For the analytics stuff and the business intelligence stuff, I don't keep track of how many jobs they have running each day. I can only really check the warehouse, but as far as I can tell it has handled the total volume of our needs without any issue whatsoever.

We use event triggers and file events, and one job we have uses email triggers. Especially for the business side, if they have a list of call center people or a list of promotions or some costing information that they need loaded into the warehouse, it allows us to say to them, "We don't need a dummy file and we don't need a blank file. Whenever you have a file ready to go, just put it on a shared drive and the job will automatically pick it up." So it simplifies our interactions with the business and allows them more flexibility to get their work done. The triggering doesn't so much reduce delays but it alleviates the need either to have the business create a dummy file or to code the job in such a way that if it doesn't find a file to run each day, it won't error-out or have to send an informational message. If we get a file a day, or if we get five files in a day, or if we only get one file every six months, the job just runs when the business has the data available, without our having to worry about it.

What needs improvement?

We also use an Oracle trigger, although we've had inconsistent performance with the Oracle trigger. It had to do with the timing of the Oracle logs. The Oracle trigger function wouldn't work because Oracle had a lock on the archive log file. We have had a couple of cases where we had to remove that Oracle trigger function from our schedule. But we still use it for some cases.

The thing I've noticed the most is the Help function. It's very difficult, at times, to find examples of how to do something. The Help function will explain what the tool does, but we're not a Windows shop at the data warehouse. Our data warehouse jobs actually run on Linux servers. Finding things for Linux-based solutions is not as easy as it is for Windows-based solutions. I would like to see more examples, and more non-Windows examples as well, in the Help.

For how long have I used the solution?

I have been using ActiveBatch for almost five years.   

What do I think about the stability of the solution?

Stability has been excellent. In the four or five years I can't even think of a time when the scheduler went down. We use two agents for production, and a scheduler and two agents for tests, and I can think of maybe three times that we had to reboot one of the agents. But I can't think of a time when the scheduler actually went down.

What do I think about the scalability of the solution?

It seems very scalable. We use a very small portion of the functionality and the available types of jobs. Of the job steps in the library, we only use about 2 or 3 percent of them. We bought it for a specific purpose and it served our purpose quite well.

How are customer service and technical support?

We have used the technical support. On a scale of one to 10, I'd give the Knowledge Base a six or seven. I would give the actual support folks an eight-and-a-half or nine.

It just depends on who you get to respond to your question or to your issue. We've had folks that have been excellent and have pinpointed the problem right away and given us a clear solution to our problems. And there have been times when we have gotten someone who doesn't quite understand the product and it feels like we're providing them more answers than they're providing us. That's been rare but I can think of at least one case where we had to say, "Can you put somebody else on or ask for some help on our question?" And they eventually did, but it was kind of frustrating. But for the most part, it's been fine.

Which solution did I use previously and why did I switch?

Ninety-five percent of the warehouse jobs that we run that were Informatica jobs have been replaced with ActiveBatch. We have a couple of jobs with some specialized logic that we haven't taken the time to figure out how to do in ActiveBatch yet. Of the 200 workflows, we run a day, 190 of them or so run through ActiveBatch.

What was our ROI?

We have seen ROI with the solution. It has simplified the warehouse job flow, our analytics workflow, as well as our business intelligence and data quality workflows. I don't know the exact cost per year of the solution, but it has simplified and made things much easier to understand in terms of dependencies among our data flows.

What other advice do I have?

The breakthrough for us was when we were able to take completely different software tools and integrate them into one long flow of data. We have our Informatica jobs which then trigger some PLC to SQL jobs in ActiveBatch, but they also trigger Alteryx jobs, which is its own software tool. It can integrate and execute iCEDQ, which is its own software, as well as Tableau. The ability to trigger those jobs from completely different software tools, in one flow, has saved us a lot of time and a lot of headaches.

Don't be afraid to dig in and try things. I said one of the weaknesses is the Help, but the Help function has helped me figure a few things out. We have jobs that update the pager email to go from an offsite pager to an onsite pager and back again. So don't be afraid to take the time to try to figure something different out. There are some useful things in the Help.

I'm the primary person using ActiveBatch in the warehouse. A month ago, we had a lot more people using it, but in the travel industry we've already had some severe layoffs. There were 10 people using ActiveBatch. They were all data analysts or data quality analysts, and I am the data warehouse developer. There were also business intelligence developers.

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.
Supervisor IT Operations at a insurance company with 501-1,000 employees
Real User
Reduction of coding and development costs are substantial
Pros and Cons
  • "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 will have to be made. This makes things nice. 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."
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

Eight years.

What do I think about the stability of the solution?

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."

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

Everything was a manual effort before ActiveBatch.

How was the initial setup?

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."

What about the implementation team?

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.

What was our ROI?

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. 

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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. 

What other advice do I have?

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.

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.
Client Service Manager/Programmer at a tech vendor with 51-200 employees
Real User
Automation for workflow triggering and stability have increased our efficiency, reduced delays
Pros and Cons
  • "One of the most valuable features is the job templates. If we need to create an FTP job, we just drag over the FTP template and fill out the requirements using the variables that ActiveBatch uses. And that makes it reusable. We can create a job once but use it for many different clients."
  • "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... the learning curve is the hardest part."

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.

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 technical 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.
Buyer's Guide
Download our free ActiveBatch Workload Automation Report and get advice and tips from experienced pros sharing their opinions.
Updated: July 2022
Buyer's Guide
Download our free ActiveBatch Workload Automation Report and get advice and tips from experienced pros sharing their opinions.