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, #6 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.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: August 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

ActiveBatch Workload Automation Pricing Advice

What users are saying about ActiveBatch Workload Automation pricing:
  • "ActiveBatch is currently redesigning themselves. In the past, they were a low cost solution for automation. They had a nice tool that was very inexpensive. With their five-year plan, they will be more enhancement-driven, so they're trying to improve their software, customer service, and the way that their customers get information from them. In doing that, they're raising the price of their base system. They changed from one pricing model to another, which has caused some friction between ActiveBatch and us. We're working through that right now with them. That's one of the reasons why we're why we were evaluating other software packages."
  • "The pricing was fair. There are additional costs for the plugins. We have the standard licensing fees for different pieces, then we have the plugins which were add-ons. However, we expected that."
  • "If you compare ActiveBatch licensing to Control-M, you're looking at $50,000 as opposed to millions."
  • "I like ActiveBatch Workload Automation's licensing model because they're not holding you down on an agentless model or agent model, where every server needs to have an agent. That's the main selling point of the solution and I hope they stay that way."
  • "Currently, we are paying approximately $7,000 yearly, which includes support."
  • ActiveBatch Workload Automation Reviews

    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
    Richard Black - PeerSpot reviewer
    Systems Architect at a insurance company with 201-500 employees
    Real User
    Top 20
    Everything runs automatically from start to finish; we don't have to worry about somebody clicking the wrong button
    Pros and Cons
    • "Since we are no longer waiting for an operator to see that a job is finished, we have changed our daily cycle from running in eight hours down to about five. We had a third shift-operator retire and that position was never refilled."
    • "There are some issues with this version and finding the jobs that it ran. If you're looking at 1,000 different jobs, it shows based on the execution time, not necessarily the run time. So, if there was a constraint waiting, you may be looking for it in the wrong time frame. Plus, with thousands of jobs showing up and the way it pages output jobs, sometimes you end up with multiple pages on the screen, then you have to go through to find the specific job you're looking for. On the opposite side, you can limit the daily activity screen to show only jobs that failed or jobs currently running, which will shrink that back down. However, we have operators who are looking at the whole nightly cycle to make sure everything is there and make sure nothing got blocked or was waiting. Sometimes, they have a hard time finding every item within the list."

    What is our primary use case?

    We are using ActiveBatch to automate as many of our processes as we can, limiting the amount of time operators are running recurring jobs. Included in that is about 99.5 percent of our nightly cycles. We call a mixture of executables: SSIS jobs, SQL queries, and PowerShell scripts. We also call processes in both PeopleSoft and another third-party package software.

    How has it helped my organization?

    As an IT department, we do solutions for the entire business and control everything. Our nightly cycles affect everybody in the company, so we do have some jobs that we run in one department, then create output which goes to another department. Based on email distribution lists, we can let anybody in the company know when things run.

    We don't really use ActiveBatch for sharing knowledge. It's more for sharing output. We have some processes that run SSRS reports that distribute links to many people across the organization all at once, so they all get the same data fed to them simultaneously.

    The most complex process that we run is our nightly cycle, which is made up of about 230 individual jobs triggered based on other jobs completing or files showing up in the system. It integrates a mixture of executables, a third-party policy system called LifePRO, and PeopleSoft. With all the handshaking back and forth between the systems, it allows an operator to start a job at around eight o'clock at night. Then, at around two in the morning, the last job finish with very minimal interaction from the operator, who is more sitting there watching to see if a job fails or not.

    The operator used to run a job for our nightly cycles and go off doing something, then they would come back to see if the job was finished. If it was, they would start the next job. With the operator's intervention, this entire process would run for around eight hours. We have managed to streamline that down, because we're no longer waiting for an operator to look for a job completion, to run in about five hours. This allows us to have one nighttime operator instead of two, so we have cut the number of staff at night in half.

    Additionally, daytime jobs are what we are starting to focus on now to allow our daytime operators to basically sit there and watch different jobs run. We'll be retraining both the nighttime and daytime operators to do different jobs. For example, with our nighttime operator, while the job is running in the background, she doesn't have to do anything anymore. She has now been tasked with other systems, like upgrading servers, and doing other things that cannot be done when the majority of our staff are in the building. So, not only have we removed half of our nighttime staff, we have repurposed our one person whose there to do both jobs.

    Internally, we ran a number of executables. Our operators used to run these jobs all manually and press buttons within our console. Now, all those processes are automated. The operator doesn't do anything. We have a number of reports that just get generated automatically throughout the course of the night or based on their own dependency. The operators used to have to wait for a specific job to finish before they could do all these pieces. Currently, those just automatically trigger on their own. In addition to that, with our financial system, PeopleSoft, we can call any job within it automatically. This is without our operators even opening up the PeopleSoft console. In our LifePRO policy system, we have about 150 jobs that we can call those automatically as well, including some daytime jobs that run processes every five minutes. Instead of having the operator sit there like Homer Simpson pressing a button, these jobs trigger automatically, ensuring that all the data is kept updated in real-time.

    It is a system that calls other jobs. Therefore, it will return error codes from those other systems. If it's a job that is truly an ActiveBatch job and doing biomanipulation, it will return error codes. The logs associated with those error codes are usually pretty in-depth to let you know exactly what happened. This prevented problems from becoming fires. We have an email that goes out every day with a list of all the jobs that failed to ensure that we hit every single one and can take care any issues.

    We have one job that runs every 30 minutes, handling batch input into our system. If one of those jobs fails, then it keeps the rest of them from working the rest of the day. Then, if one of those fails, the entire team that supports that is notified immediately, giving them the full amount of time to rectify the issue before the next time that process runs. In the past, when this was done manually, we would have to wait for someone to notice that there was an error and then find the right person to deal with it. Now, within 10 seconds, an email has been sent out saying, "There is an issue. Fix it."

    For our nightly cycles, we have some cycles that will run from start to finish without a single error because it is controlling when jobs run. It does a lot of clean up before the system starts. Therefore, it knows where certain files are supposed to be and where they are. So, we don't have to worry about somebody clicking the wrong button; everything runs from start to finish.

    What is most valuable?

    We can control the runtime of files, based on timing, by a file showing up. They can be controlled by an email being sent into the system. We get error codes back. Therefore, we have one centralized location where we can see how jobs are running. We have the ability to notify end users when jobs are finished or if there are problems with jobs. It's a very robust system, which allows for a lot of different functionality.

    The system is very easy to use. In a short amount of time, we trained a couple people who have been able to create jobs on their own. For the two people whom I have trained so far, I spent about an hour or two with them. They were able to start creating minor jobs themselves by looking at existing jobs. We gave them minor jobs to work on. Then, within a couple hours, they were able to create jobs and processes that work correctly.

    A lot of our processes are jobs that we know run one job after another, along with a hierarchical system, e.g., once this one job finishes, it triggers these three. Then, as soon as those three are done, it triggers a fifth job. The scheduling of those in that format is very easy to do. 

    You can set up automated controls where as soon as one job finishes, then another one kicks off. You can put in constraints where a job won't start until other situations are met. It's very easy to use.

    The console is very easy and flexible to use. Whenever we have come up with something that we wanted to try in ActiveBatch, we have managed to find a solution. When you're calling an application, you can call it through a batch job or script. You can also call the executable directly or through PowerShell. Depending on how it's running and how the security needs to pass through the system, there are many different ways to get the processes to work.

    ActiveBatch provides a central automation hub for scheduling and monitoring, bringing everything together under a single pane of glass. There is a daily activity screen within ActiveBatch that shows you every job currently running. You can look in the past and future. I think you can set it all the way up to seven days in the future. So, if you have jobs scheduled to run on a timeframe, then those will show up. It will show everything that is on hold. You can limit it down to show only the stuff that has run in the last hour, if you are trying to deal with a specific problem. You can set the ranges, to say, "Okay, show me between 5:00 and 8:00 PM." It is very easy to use in that regard.

    It handles a lot of different business-critical system for us. We have applications that our agents use out on the field which trigger other things that run in the office. Those run every five minutes looking for input to make sure that we can keep things running smoothly. Things that we would have needed to have the operators, or somebody, just running every couple of minutes, we have about a dozen of those run automatically looking for input to keep things running. It also allows our financial system to integrate with all our other systems without anybody having to do the work. Our whole nightly cycle is automated through this. We just did an inventory, and I think we have about 500 unique jobs that we run through ActiveBatch now. These are things that somebody would have had to run manually in the past.

    You can keep history of run times, so you can start setting up SLAs on job performance. We have one job setup now where if that job takes more than 15 minutes to run, then it automatically aborts the job, sending an email saying, "This job needs to be looked at, as it's running past its run time."

    The have done a pretty good job with the operator interface. There are a number of different screens which can be used to see what is going on. We have chosen the daily activity screen because it gives the most complete view of what's going on: what's finished, what's failed, and what's currently running.

    The performance on ActiveBatch has been stellar.

    What needs improvement?

    There are some issues with this version and finding the jobs that it ran. If you're looking at 1,000 different jobs, it shows based on the execution time, not necessarily the run time. So, if there was a constraint waiting, you may be looking for it in the wrong time frame. Plus, with thousands of jobs showing up and the way it pages output jobs, sometimes you end up with multiple pages on the screen, then you have to go through to find the specific job you're looking for. On the opposite side, you can limit the daily activity screen to show only jobs that failed or jobs currently running, which will shrink that back down. However, we have operators who are looking at the whole nightly cycle to make sure everything is there and make sure nothing got blocked or was waiting. Sometimes, they have a hard time finding every item within the list.

    Now, it integrates well with our other solutions. There were some issues initially with getting ActiveBatch to work, but once we found a solution that worked, it was easy to replicate. The initial issues were a mixture of the fact that very few people had done this type of work before, and partly the person we had working on it at the time. We're not sure exactly what the issue was. We actually reached out to ActiveBatch who helped us to get this to work. 

    It is a very complex application because the code we are trying to connect to was COBOL based and still dealt with INI files. So, we had to trick the system into thinking it was calling the system the exact same way. Once we did, everything worked fine, including getting the error messages back and being able to display them within ActiveBatch.

    It was the connection between systems that became complex. Basically, we had to set about a dozen environment variables within a script in ActiveBatch. So, when we called the outside application, all those variables were set and we could understood what it was trying to do. The complexity was on the actual calling of the third-party application. It was not from the ActiveBatch side.

    You have to be careful with automation tools. We had one job where the person who initially programmed it created an infinite loop, so it kept triggering itself. It ran for less than a second, so we couldn't stop it. 

    Buyer's Guide
    ActiveBatch Workload Automation
    August 2022
    Learn what your peers think about ActiveBatch Workload Automation. Get advice and tips from experienced pros sharing their opinions. Updated: August 2022.
    620,600 professionals have used our research since 2012.

    For how long have I used the solution?

    The company has been using ActiveBatch for about five or six years. I have been using it for about three years.

    What do I think about the stability of the solution?

    Stability-wise, there is only one function that we have had trouble with. We haven't even reached out to ActiveBatch to try and figure it out because we're trying to figure out what is causing it. There is one DLL within the system that gets the current date, but will just stop working from time to time. The rest of the system is very stable. On occasion, we will have to reboot a server to release some locks on things, but that's once a month where we have to do anything like that.

    I maintain all the jobs in production. There is nothing out of the ordinary that needs to be done. It does its own self-cleanup. It also deletes history periodically on its own.

    What do I think about the scalability of the solution?

    We started with just a few jobs and are right now up to 500 jobs that we run. When adding new things, it allows you to put everything in its own folders, so you can keep track of different parts. You can flag them as part of different systems, if you want. As we have added more things, we have seen no degradation in the performance.

    We use it more as an automation tool, so it is just running jobs. In terms of people who go into ActiveBatch to look at it, we have our two daily operators who go in and look how things are running. We do have some jobs that they go in and trigger, because we're still automating the actual execution of these jobs, but they're all still controlled from ActiveBatch. We have a number of programmers, probably about a dozen, who will go into ActiveBatch. Some will tinker around with creating jobs that they need in our test system. Some will go into production to see how their jobs ran, if they're supporting the system. They can go in and see what the end result was, if it came back successful, had a warning, or an error. They can look at the logs to see what the problem was, allowing them to fix the process themselves.

    Right now, we don't have any end users going into the system directly. We're building them a web interface front-end where they will be able to trigger specific jobs, so they can see the jobs that they can control. We have it setup through the ActiveBatch API so it returns the results to that web interface of how the job ran the previous time and when it ran last.

    Our nightly cycle is 99.5 percent automated right now. We're finishing up the last few pieces of that. We have started looking at all of our daytime operator jobs. Those are being worked on next. All of our reports sent out to users on a daily basis are all automated within ActiveBatch to be triggered at specific times and sent out. The next piece that we will be working on is giving our programmers the ability to bring up Azure sites as needed, then we will be starting to add in all of our FTP jobs into ActiveBatch as well.

    How are customer service and support?

    In the past, we haven't used their technical support that much. The few times that I have called and asked them questions, they have been very easy to work with and get the answers from. They are in the process of changing their whole structure on how they support their clients, along with having their pricing structures change. 

    They are trying to make the system more user-friendly from the support side, so you can go and look for the information yourself as opposed to trying to call someone.

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

    Previously, we have only used some scheduling through Microsoft Schedulers and SSRS schedulers.

    How was the initial setup?

    I was not involved for the initial setup. Though, the installation of ActiveBatch was straightforward. 

    I was involved the last time that we did an upgrade. Everything was straightforward. Moving the jobs from one version to the next was relatively straightforward. The initial application that they picked to interface with was one of our more complex ones. That may have been why the person who was doing the program initially had an issue, because nobody had done this before with this type of system. 

    There are a lot of APIs for packages that you can get with ActiveBatch for doing connections. We don't use a lot of their integration tools, though it does integrate with a lot of different ones. The one we do use right now is PeopleSoft. The issues with the integration of PeopleSoft have been more on the PeopleSoft side, not the ActiveBatch side. We had to reconfigure how we had PeopleSoft setup, so it would allow outside applications to communicate into it.

    Once we decided to do the installation, I think it was done in the course of a day over a weekend.

    What about the implementation team?

    We did the installation ourselves. It was done by our systems department. One of my coworkers did all the work. She installed the new system and exported everything out of the old version into the new one. On top of that, we broke one system into two, because we used to have our model and production on one server. In the course of upgrading to version 12, we put our test and production systems on different servers.

    What was our ROI?

    Since we are no longer waiting for an operator to see that a job is finished, we have changed our daily cycle from running in eight hours down to about five. We had a third shift-operator retire and that position was never refilled.

    The person who used to run all these jobs now just watches the system run. She is doing other stuff while she is working. On top of that, with the pandemic, we have managed to be able to allow our second shift operator to run everything remotely from home. They don't even have to be in the building anymore to run our cycles.

    The central automation hub for scheduling and monitoring brings everything together under a single pane of glass by streamlining everything:

    1. It takes less time to run everything.
    2. It's less expensive because we no longer have the extra operator running jobs.
    3. There is less chance of an operator clicking the wrong button because we run both a test system and production system side by side. In the past, where they might have run the job in the wrong system, this makes sure that the correct system is running the right jobs.
    4. It automatically will send an output where it needs to go in real-time. We have management reports that used to have to be run by an operator. Now, if management comes in early, the report is there just waiting for them.

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

    Make sure that the pricing is in the contract.

    ActiveBatch is currently redesigning themselves. In the past, they were a low cost solution for automation. They had a nice tool that was very inexpensive. With their five-year plan, they will be more enhancement-driven, so they're trying to improve their software, customer service, and the way that their customers get information from them. In doing that, they're raising the price of their base system. They changed from one pricing model to another, which has caused some friction between ActiveBatch and us. We're working through that right now with them. That's one of the reasons why we're why we were evaluating other software packages. For the time being, we are staying with ActiveBatch because we like it the best of the four.

    Up until now, if you wanted to do a training class through them or go into some of their deep dives, you needed to pay additionally for that. The new way that they are doing their structured agreements has that all part of the contract. Now that we will be paying for it, we will be looking at their deep dives a lot more and seeing the stuff that they have done in the past.

    Which other solutions did I evaluate?

    It is the only automation tool that we're using. We are actually moving items from other automation tools that we have into this, so we have one central location where everything is automated. In the past, we have used some of our Microsoft Servers' scheduling tools and SQL Servers to automate the distribution of reports. Now, we are moving everything into one place so it's all controlled centrally. Then, you can look in one place to see where everything is. 

    We have looked at a few different solutions in this past six months to see if they offer that same type of functionality and evaluated three other ones, which are very similar. I like ActiveBatch the best among the four solutions. The other tools seemed to not have the file manipulation tasks, and kept saying, "Well, you can do that in Doc." I thought, "That's okay. Welcome to the eighties." They basically said, "We don't have any filing manipulation tools built in because you can do that other ways." However, we're trying to put everything in one place. There is a lot of archiving of files that we do based on different criteria. For example, there was one job that we wrote which looks at the size of an Access database. When the size of the file gets too large, it notifies that team, saying, "You need to go delete data out of it." Those kinds of things were not available within other solutions.

    What other advice do I have?

    I would recommend reaching out to a client who has used it, especially if you have questions. While talking with customer support is great, people who use it on the build have better knowledge of how to use it in the business area.

    We haven't used any of the APIs directly through ActiveBatch yet. We have started playing around with having our own little outside website which allows our end users to trigger jobs directly within ActiveBatch. But, we have not fully implemented that yet.

    We have started looking at cloud solutions for bringing Azure sites up and down. We have not implemented that yet.

    I would rate this solution as a nine out of 10.

    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.
    PeerSpot user
    Jason Fouks - PeerSpot reviewer
    Sr Technical Engineer at Compeer Financial
    Real User
    Top 20
    We can automate just about anything
    Pros and Cons
    • "ActiveBatch's Self-Service Portal allows our business units to run and monitor their own workloads. They can simply run and review the logs, but they can't modify them. It increases their productivity because they are able to take care of things on their own. It saves us time from having to rerun the scripts, because the business units can just go ahead and log in and and rerun it themselves."
    • "They have some crucial design flaws within the console that still need to be worked out because it is not working exactly how we hoped to see it, e.g., just some minor things where when you hit the save button, then all of a sudden all your job's library items collapse. Then, in order to continue on with your testing, you have to open those back up. I have taken that to them, and they are like, "Yep. We know about it. We know we have some enhancements that need to be taken care of. We have more developers now." They are working towards taking the minor things that annoy us, resolving them, and getting them fixed."

    What is our primary use case?

    It does a little bit of everything. We have everything from console apps that our developers create to custom jobs built directly in ActiveBatch, which go through the process of moving data off of cloud servers, like SFTP, onto our on-premise servers so we can ingest them into other workflows, console apps, or whatever the business needs.

    How has it helped my organization?

    We use it company-wide. With us being a financial organization, we rely on a bunch of data from some of our parent companies that process transactions for us. We are able to bring all that data into our system, no matter what department it is from, e.g., we have things from the IT department that we want to do maintenance on, such as clearing out the logs in IAS on the Exchange Server, to being able to move millions of dollars with automation.

    If there is a native tool for it, then we try to use it. We have purchased the SharePoint, VMware, and ServiceNow modules. Wherever we find that we can't connect in because the native APIs aren't there, we have been using PowerShell to strip those rows out into an array of variables that have worked pretty well. So far, we have not found a spot where we can't hook in to have it do the tasks that we are asking it to do.

    We have only really tapped into SharePoint native integration because we haven't gotten to the depths of being able to use the ServiceNow and some of the other integrations. However, being able to use the native plugins has been very helpful. It saves us from having to write a PowerShell script to do the functionality that we are looking to do. We are really trained to write it, because within the old process that we used to use, we would do a lot of PowerShell as the old tool just wouldn't do what we're asking it to do. We are finding a lot of processes within ActiveBatch are now replacing those PowerShell scripts because ActiveBatch can just do it. We don't have to teach it how to do it.

    We can do things within ActiveBatch, not having to teach it everything. That is the biggest thing that we've been learning with it: It's easy to use and its workflows work a lot better. The other day, we ran into a problem where Citrix ShareFile, which is one of our SFTP locations, was being stupid where it would disconnect from the SFTP server. It was all just a time out. Well, ActiveBatch has a process included where we can troubleshoot the connection failures and have itself heal enough to be able to get the data off of the SFTP server. Being able to discover the functionalities of ActiveBatch self-healing has been a lifesaver for us.

    We have so many different processes out there with so many different schedules. My boss looked at it one day and noticed there was somewhere between 1,000 and 2,000 processes a day. The solution gives us that single pane of glass to see everything under one spot because we have four execution agents constantly running, so there are processes happening at all times of the day and night.

    We are actively monitoring all our ActiveBatch processes using SolarWinds Orion. If a process doesn't run, a service is not running on one particular execution agent, etc., Orion will alert us to that. I don't think that we have set up anything too major within ActiveBatch to figure out what is going on. I know that we have HA across everything. So, we are running four execution agents and two jobs schedulers. Having all that stuff put together, then it does failover to the other location if there is a problem with one of the sites.

    What is most valuable?

    The most valuable feature is being able to ingest some PowerShell scripting into variables that we can then utilize in loops. Our first rendition of doing PowerShell into variables was being able to pull some Active Directory computers using a PowerShell script and Active Directory PowerShell modules, then we were able to take that and dump it into a SharePoint list, because we keep inventory of all our servers. It was through the process of trying to understand how to get something out of PowerShell into an array and being able to process that out into something else that it would become useful down the road.

    There are some things that ActiveBatch can't do natively, which is no fault to them. It's just the fact that we're trying to do things that just don't exist in ActiveBatch. With us being proficient in PowerShell scripting, we were able to extend the ActiveBatch environment to be able to say, "We'll run this PowerShell script and get the array that we're looking for, but then take that and do something native within ActiveBatch that can ultimately meet our goals."

    The ease of use has been pretty good. I have been able to create workflows and utilize different modules within the job library, which has worked out really well. 

    ActiveBatch's ability to automate predictable, repeatable processes is good. It does that very nicely. A lot of what we do is we pull files down from SFTP servers and put them onto our local file servers. Based on that, we are able to run a console app that developers have written, which is a lot more complicated, for doing various tasks. Our console apps are easy to set up because we have templates already drawn up. So, if we just right click into our task folder, we can quickly create an item in there that we can start up for doing an automation feature. Just being able to use PowerShell to drop variables into the ActiveBatch process has worked really well now that we understand it.

    What needs improvement?

    I know that there are some improvements that I have brought back to the development team that they want to work on. The graphical interface has some hiccups that we have been noticing on our side, and it seems a little bit bloated. 

    While the console app works well, they have some crucial design flaws within the console that still need to be worked out because it is not working exactly how we hoped to see it, e.g., just some minor things where when you hit the save button, then all of a sudden all your job's library items collapse. Then, in order to continue on with your testing, you have to open those back up. I have taken that to them, and they are like, "Yep. We know about it. We know we have some enhancements that need to be taken care of. We have more developers now." They are working towards taking the minor things that annoy us, resolving them, and getting them fixed.

    For how long have I used the solution?

    We did a proof of concept back in April.

    We are in the process of migrating all our old processes over to ActiveBatch. The solution is in production, and we do have workloads on it.

    What do I think about the stability of the solution?

    It is pretty stable. Now that we have worked through the details and ensured that we can do a failover to let the process do what it needs to do, we haven't seen any problems with it.

    We are about 90 percent done migrating our processes.

    What do I think about the scalability of the solution?

    Right now, we have four execution agents, and they are sitting pretty idle for the most part. If we find that we're starting to see taxed resources on our execution agents, then we have the capability of spinning up more. So, we can run hundreds of servers and automation, if we wanted to.

    There are only three of us who have been working with ActiveBatch, which is a good fit. We have one admin who is a developer first, then admin second. Then, there are two of us, who are server people first and developers second. All three of us manage all the different job libraries out there.

    In the entire organization, there are about 1,300 of us using the different processes. A lot of people who would be more hands-on are the IT department, mainly because we are directly involved with all the different console apps. We have actually got a significant number of console apps, just because SCORCH couldn't do some of the things that ActiveBatch can do, so our developer teams went in and created the console app. At this point, all that ActiveBatch really needed to do was to be able to run an executable and provide an exit code on it, then let us know if it fails. There are some other business units who are involved a bit more along the way due to the movement of money, for example.

    It is heavily used, at least in terms of what is out there. There is a lot of interest in adoption of using it in the future along with a lot of processes that people are really pushing to get put into ActiveBatch. They still have the mentality that a lot of it needs to be done as a console app. However, with us just ending the migration phase of things, we are trying to just get everything moved over so we can shut down the servers. Then, the next step in the future, probably 2021, we'll end up focusing on what ActiveBatch can do without us having to write a console app. 75 percent of the time, we could have ActiveBatch do it natively. There is just a matter of getting a lot of the IT developers to feel comfortable with adopting it as a platform.

    How are customer service and technical support?

    I am working with them on their tech support. We have a customer advocate with whom we have been working. She has been awesome. We have had some issues where tech support will suggest one thing, then we are sitting there scratching our heads, going, "Do we really need to go that complicated on a solution?" Then, we reach out to our customer advocate, who comes back, saying, "No, this is how you really need to do it. I'm going to take this ticket and go train that tech support person. So, in the future, you don't get the answer you did." Therefore, their tech support is a bit rough around the edges, but I foresee in the next six months to a year, they will be on their game and able to provide exactly the answers within the timeframe that we expect.

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

    We see ActiveBatch as the Center of Excellence for all things related to automation for our business. It is the best solution that we have had compared to what we were running before, which was Microsoft System Center Orchestrator (SCORCH). We don't want to have a whole bunch of different solutions out there. Being able to have one solution that can do all our automation is the best way to do it.

    We switched over because of the intelligence. We were right in the middle of trying to decide whether we were going to upgrade SCORCH to the latest version or if it was time for us to go a different path. As we started going down through the different requirements that we needed SCORCH to do, we decided that it was time for us to go in a different direction. SCORCH had to be taught everything you wanted it to do, whereas there are a lot of processes that ActiveBatch will just go ahead and handle.

    The performance is about the same between the two solutions in terms of doing what they are supposed to do. Where we really have the advantage is the fact that we don't have to reinvent the wheel, e.g., triggers within Active Batch are native and can be set up pretty quickly and easily. Whereas with SCORCH, we struggled with trying to get a schedule setup for that trigger or being able to rely on constraints. For example, if a file doesn't exist, then you really can't do anything. In SCORCH, we had to teach it that if you don't see a file, then hold on a second because we have to wait. Where ActiveBatch just says, "Oh, okay. I know how to do that."

    In certain cases, ActiveBatch has resulted in an improvement in workflow completion times, because of the error retries. We can take care of them by telling ActiveBatch that if you have a problem, go ahead, try it again, and modify this. If the job runs at two o'clock in the morning and it failed with SCORCH, we always had to go back, figure out what happened, and how to get it run again. It might have been something as stupid as no network connection, because one of our upstream providers had an outage. Whereas, at least with ActiveBatch, we have been able to build in that self-healing or error detection. Once it sees the connection, it can go ahead and just correct the problem. For example, the Internet might go down from 2:00 AM to 2:15 AM, then by 2:30 AM, it's all back up and running. ActiveBatch can go ahead and finish the task. Where with SCORCH, we were finding that it would fail. Then, at seven o'clock in the morning, we got to troubleshoot any issues that might have come up. 

    A lot of times, troubleshooting did not take very long, as it depended on the process. If it's something that could be downloaded from the SFTP, then that relied on several other steps that needed to take place. That might have delayed it a bit because we had to walk through five different processes that normally would have been scheduled to run at 3:00 AM versus 2:00 AM. So, if the Internet is out between 2:00 AM and 2:15 AM, ActiveBatch heals that first process before the second one runs at 3:00 AM. Then, we don't have to go through and do any added troubleshooting because step one didn't work, and step two failed because we can't troubleshoot it until we get up and start looking at it that day.

    How was the initial setup?

    The initial setup was straightforward.

    It took two to three hours to deploy, by the time we had all the intricacies done that we wanted.

    We knew that we wanted it to be highly available in two data centers for DR purposes, because some of these processes move millions of dollars of money between accounts (in various pieces for wire transfers). I think HA was the big thing that we were trained to ensure that our strategy was based around. 

    The only other strategy was the fact that we have multiple environments that we go through to test our solution out first. When we are done, we export/promote it up to the production environment.

    What about the implementation team?

    The good part was that we really didn't have to do the install because we ended up getting a proof of concept setup with one of their engineers. So, we didn't have to do the initial setup ourselves, but we did build two other environments: one in our test environment and one in our development environment. Based on the fact that we walked through it the first time with the proof of concept, I was able to go back and reproduce every step that they walked us through on day one to build out the test and dev environments.

    What was our ROI?

    I have absolutely seen ROI. Coming from the admin point of view, it has streamlined the process of being able to just implement something instead of having to teach the software how to do its job. From our point, I know that I have implemented a couple of different processes that were not a migration piece, and it's been fairly easy for us to deploy because we know what the business unit wants to do with it. For us to implement, it takes us about 20 minutes to get it perfected on my side, then I can have developers run with it, test it, and figure out what their code was doing to make it happen. So, the biggest thing is that it is easy to use.

    I know that there are enough processes out there that it's worth a gold mine. We can automate just about anything that we would ever want to. If we wanted the lights to turn on at a certain time, we could go ahead and turn the lights on at a certain time, and it would just happen.

    ActiveBatch's Self-Service Portal allows our business units to run and monitor their own workloads. They can simply run and review the logs, but they can't modify them. It increases their productivity because they are able to take care of things on their own. It saves us time from having to rerun the scripts, because the business units can just go ahead and log in, then rerun it themselves. 

    This solution improves our job success rate percentage. The biggest thing is having built-in capabilities of error detection, retries, and the ability to self-heal.

    ActiveBatch has saved us man-hours. We don't have to rerun some of these scripts on behalf of the business unit. Or, if there is a script that fails, it can go ahead and self-heal, fixing itself. That is all unaccounted for troubleshooting time while helping our business units. 

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

    The pricing was fair. 

    There are additional costs for the plugins. We have the standard licensing fees for different pieces, then we have the plugins which were add-ons. However, we expected that.

    Which other solutions did I evaluate?

    We had a consultant come in and try to share with us all the different tools. However, there isn't a lot of competition out there for automation capabilities.

    A major component was that the vendor is thinking five years ahead, looking to future-proof our business. When we were making our decision, we were either ready to go with either upgrading SCORCH or a different path. We wanted to be in connection with an organization who had a long-term plan. We didn't want to revisit this in one to three years down the road.

    What other advice do I have?

    We have been able to learn it pretty quickly. We were kind of thrown right in after we got the proof of concept up and going. We had a couple of use cases drawn up and implemented, and they showed us how to do it. Our boss ended up buying the software, and said, "Ready, set, go. We're going to start migrating all these different processes over." We really didn't get time to learn it. Based on what we knew about our previous application that we were using for automation, we were able to step right in and do the best we could. We have been doing weekly, one- to two-hour sessions where three of us get together, just understand the solution, and try to work through all the details. We have been able to learn it pretty quickly without having too much training or knowledge.

    We have gone through and given the business units a demo of what the possibilities are for sharing knowledge and ideas. At the end of the day, there is a team of three of us who are actually implementing all the processes so we keep a kind of standard. However, to give a business unit an idea of what the functionality is and how we could best utilize it, we at least give them the 30,000 foot view of what ActiveBatch could do, then we build it.

    We mainly use it for console apps, but we haven't explored them in real depth. I know that we could get even deeper. At some point down the road, a lot of the console apps that our developer teams create will more than likely become native ActiveBatch processes which we will no longer need the console apps to run.

    For the admins, the biggest lesson learnt would be in those first 30 days going through and learning through the Academy. They have an online Academy that they have out on their website. The biggest struggle that we had was just the fact that we were trying to do this migration not knowing all the different features of the software. We ran into trouble where we would try and implement something (and we wanted to do it by best practices because we want to get it right the first time), but there were features that we were discovering along the way that we had no idea about until all of a sudden we needed that feature. Then, we would go back, and go, "Oh, you know what? That last procedure that we just implemented. It would've been really cool if we would have known that at the time."

    If we would have taken the first 30 to 60 days, or even a week long crash course, in ActiveBatch development to get all the highlights of everything that the software could physically do, that would have helped us immensely just to make sure that we knew what was going on and how it worked. We probably would have implemented some of our migrations a little differently than we have them done today. So, we will have to circle back and revisit some of those processes and reinvent them.

    Take that time and learn the solution. Make sure you understand the software, at least at a higher level, maybe not the 30,000 foot view, but maybe the 1,000 foot view and get through the Academy first. Once you get through the Academy, then you can go ahead and start implementing the job libraries and how you want it to lay out and be implemented. Even after nine months of working with the software, we're still discovering features that we wish we would have known nine months ago coming into the migration.

    I would probably rate the software as a nine and a half or 10. I would rate the tech support as probably a six, but they are improving immensely. If I had to give it an overall score, I would go with an eight (out of 10).

    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.
    PeerSpot user
    Buyer's Guide
    ActiveBatch Workload Automation
    August 2022
    Learn what your peers think about ActiveBatch Workload Automation. Get advice and tips from experienced pros sharing their opinions. Updated: August 2022.
    620,600 professionals have used our research since 2012.
    PeterBirksmith - PeerSpot reviewer
    Senior System Analyst at a insurance company with 5,001-10,000 employees
    Real User
    Top 5
    Native API calls are very good and very easy, enabling us to tie in to a large range of solutions, including Tableau and ServiceNow
    Pros and Cons
    • "The most valuable feature is its stability. We've only had very minor issues and generally they have happened because someone has applied a patch on a Windows operating system and it has caused some grief. We've actually been able to resolve those issues quite quickly with ActiveBatch. In all the time that I've had use of ActiveBatch, it hasn't failed completely once. Uptime is almost 100 percent."
    • "A nice thing to have would be the ability to comfortably pass variables from one job to another. That was one of the things that I found difficult."

    What is our primary use case?

    We have roughly 8,000 jobs that run every day and they manage anything from SaaS to Python to PowerShell to batch, Cognos, and Tableau. We run a lot of plans that involve a lot of constraints requiring them to look at other jobs that have to run before they do. Some of these plans are fairly complicated and others are reasonably simple.

    We also pull information from SharePoint and load that data into Greenplum, which is our main database. SharePoint provides the CSV file and we then move it across to Linux, which is where our main agent is that actually loads into the Greenplum environment.

    Source systems acquire data that goes into Greenplum. There are a number of materialized views that get populated, and that populating is done through ActiveBatch. ActiveBatch then triggers the Tableau refresh so that the reports that pull from those tables in Greenplum are updated. That means from just a bit after source acquisition, through to the Tableau end report, ActiveBatch is quite involved in that process of moving data.

    We have 19 agents if you include the Linux environment, and 23 if you count the dev environments. It's huge.

    It's on-prem. We manage the agents and the scheduler on a combination of Windows and Linux.

    How has it helped my organization?

    We have some critical processes in ActiveBatch that go to finance and to the auditors in our organization. Those processes are highly critical because that allows us to trade. If those reports don't get to them, we get penalized by the government or by APRA or by some financial institutions. ActiveBatch, in this particular case, is absolutely critical for getting those reports out.

    We have SLAs requiring us to get reports out by a certain time of day or by a certain day of the month, by a certain time. We're judged on whether those reports go out. ActiveBatch, being as stable as it, is only impacted by external factors like the network and database performance. But otherwise, we are quite comfortable with the way ActiveBatch is able to handle these jobs without our having to look at them.

    Because the connections between ActiveBatch and other tools are automated, it gives us more time to do other things, and more interesting things. If something goes wrong, we can go back and have a look in the logs that are produced and that explain what's going on, and we can then repair it. It's an enabler, and it provides us with more time to get on with other jobs. It's something that's critical and it runs by itself and we're really happy it does that. We have that time available because we're not actually manually babysitting processes.

    It provides a central automation hub for scheduling and monitoring, bringing everything together under a single pane of glass, absolutely. There is finance, sales, marketing. Pretty much every department has a job that we deal with. It's quite heavily integrated into our whole stack. As an insurance company, our major events department, for example, is critical because every time there's a storm or a hail event or a cyclone somewhere, those reports must get out in a timely manner. I can't think of any department that isn't impacted by ActiveBatch, running some report for them.

    The single pane of glass helps the DataOps team manage all of the processes that are supported by ActiveBatch as the main scheduling tool. We've created a dashboard which pulls information from ActiveBatch, information that we can share with the organization. They can look at jobs and the schedules and, if necessary, run their own jobs from that point. It's like the lungs of our company.

    Overall, it has helped to improve workflow completion times by 70 to 80 percent, easily. Once you've built a job, it just runs and no one has to concern themselves with it doing what it's doing. They will get the notification or the file or the email that says it's processed and they move on with their day.

    In addition, we had a guy who was spending seven hours in a week to extract, compile, and then export information into a CSV file, and then another few hours to get it transferred to another department. We were able to build a PowerShell script, with a query that could easily be updated, that was automated through ActiveBatch. It takes 10 minutes to run. What that guy was doing in hours, we are now doing within minutes.

    What is most valuable?

    One of the valuable features is the ability to tie ActiveBatch into other applications using API calls. The native integrations and REST API adapter for orchestrating the entire tech stack are very good and user friendly. We have a product called ServiceNow, which is a call tracking system. If a problem occurs, ActiveBatch will send an API call into ServiceNow, and it will raise a ticket to say that there's a problem. That gives us an auditing process. We're also using API calls for Tableau and we're also using some API calls for SharePoint. We tie ActiveBatch into a lot of different applications.

    Also, the overall ease of use is brilliant. It's easy to pick up. We can get a newbie up and running within a day, using ActiveBatch. It's not to the extent where that person will know some of the more complicated issues, but in terms of being able to build a job and export or run the job, it's within a couple of hours. Within a day, people are quite comfortable with the application. We've just signed an agreement with ActiveBatch which gives us all the education materials now. That means we'll be applying more advanced features. It's really good as far as ease of use goes.

    We use the solution across all sorts of organisational branches. It's used for SaaS and SAP, which is finance. We have fraud and Salesforce, which is for the sales group. It's also used with marketing and major events because, when there's a storm, we need to know what's going on. We also have the ability to pull from external sources, meaning external vendors such as Guidewire. So ActiveBatch is widely utilised and probably more widely utilised than the executives realise. It's well embedded in our company.

    What needs improvement?

    We have moved to version 12, and I believe that interface is more of a "webbie" look and fee. 

    A nice thing to have would be the ability to comfortably pass variables from one job to another. That was one of the things that I found difficult. Other than that, it's all good.

    For how long have I used the solution?

    I've been with this company for over 10 years and it was already here before I arrived.

    What do I think about the stability of the solution?

    The most valuable feature is its stability. We've only had very minor issues and generally they have happened because someone has applied a patch on a Windows operating system and it has caused some grief. We've actually been able to resolve those issues quite quickly with ActiveBatch. In all the time that I've had use of ActiveBatch, it hasn't failed completely once. Uptime is almost 100 percent.

    With those 8,000 jobs that run in a 16-hour period, the majority of the time we're spending about an hour of the day with ActiveBatch, repairing problems. There are issues where we have to re-run a job because of it exceeding its runtime. Or when a job fails, even though the alert goes out to the end user, we still have to tap the user on the shoulder and say, "Did you look at this alert? We've got a problem here, can you please fix it?" Other than that, it pretty much runs itself. Overall, ActiveBatch saves us a huge amount of time, being as stable as it is.

    If we were having to repair everything, on an ongoing basis, we would be spending more than five or six hours a day, so we are saving at least five to six hours a day by using this tool. The improvement to the business is quite substantial. People aren't having to manually do anything that would normally take them two or three hours to do. Those things are being done within a matter of minutes and then passed on. And those five or six hours are just for us in our department. You can multiply that by the number of people who would normally have done something manually and who now have it done through ActiveBatch in minutes.

    We're looking at more than a 98 percent success rate for uptime and for running jobs. The only time that something falls over is not to do with ActiveBatch itself, rather it's to do with problems with either the network, the database, or developers.

    What do I think about the scalability of the solution?

    The scalability is brilliant. We've got 23 machines. We have redundancy integrated into this environment. 

    If a server goes down, we can turn that queue off and re-queue those jobs to another server, while we get a new image spun up and restarted. In that situation, the delay is in getting the IT guys to spin up the image. If we could get an image spun up when it failed, it would be a matter of five or 10 minutes to be back in business with that server. As it is, once the IT guys do spin it up, we kick off from there.

    The main interface is used by about 12 people. The dashboard that we've built on top of it is probably used by 70 to 80 people. But the number of people it affects is in the thousands across the entire organization.

    It's heavily utilized across a number of departments in the organization and they really do rely on ActiveBatch to stay up and stable and to provide their reporting mechanisms.

    How are customer service and support?

    We've had a couple of issues where we've had to log a defect with ActiveBatch. But the guys at ActiveBatch are really responsive. We had things fixed in 24 hours, and they're in a different time zone. The response time is exceptional. This is one of the few vendors that I can say is highly responsive and that shows a level of commitment that I don't think many other organizations show.

    How would you rate customer service and support?

    Positive

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

    ActiveBatch replaced Windows Scheduler, Chrome jobs that had been running on some servers. There was also another scheduling tool that popped up somewhere but that data was moved into ActiveBatch. The scheduling from Cognos was also moved into ActiveBatch because it was more convenient, and some of the Tableau scheduling was moved into ActiveBatch as well.

    How was the initial setup?

    The initial setup was straightforward. It's super-easy to install and super-easy to set up. Even on the Linux box, it was really easy to install and set up and run. There was no real complexity in the installation process.

    Most of the time with setup or upgrades is spent testing. We usually deploy agents within 20 minutes. The scheduler and the database might take an hour and a half, but because the agents are on virtual machines, we have an image and we just spin that image up. If something goes wrong, we can just spin up a new image and get that agent started straight away. In terms of testing, when we do disaster recovery, we redeploy to a disaster recovery environment and then we test that the connections are working, the jobs are running, and that there are no problems. That's where most of the time is spent, not in the deployment itself.

    We usually have two people involved in the process, one who is the primary and one who is the secondary. And then we have a couple of people on standby. The primary does the installation and the secondary is looking over their shoulder for learning purposes. Then we have a few people on the IT side in case there is a problem with the operating system or the network that we have to deal with, but they're not involved until there's a problem. The DBA is also on-call just in case there's an issue with the database.

    Maintenance-wise, it's only if something happens that we go and look. We have a job that looks at the health of the database that ActiveBatch uses. It's pretty much all automated, so it looks after itself. We have another job that pings the servers to make sure that all the ports that it needs are running and open. We also have jobs that look at the network latency so that if the network latency is beyond a certain point, it notifies IT and us. It also looks at the operating system and the actual directories. Unless we schedule it for an upgrade, which we do every six months, we don't look at maintenance for that six months unless there's a problem.

    What about the implementation team?

    ActiveBatch has been implemented in-house.

    What was our ROI?

    It pays for itself because it gives the DataOps team more time to be involved in other projects. It allows the organization to move forward without having to worry about doing anything manually. ActiveBatch is performing a huge service to the organization in terms of reducing the number of man-hours required to do manual tasks.

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

    If you compare ActiveBatch licensing to Control-M, you're looking at $50,000 as opposed to millions.

    Which other solutions did I evaluate?

    ActiveBatch isn't the only scheduling tool that we have. There's also a product called Control-M, but control-M is a lot more expensive and mostly manages mainframe. ActiveBatch is at a very modest price for running a very complex process.

    We can expand ActiveBatch more readily than Control-M because, with Control-M, you pay for X number of runs in a run book. If you want to extend that run book, they want half-a-million dollars, or more, for 500 jobs. We can expand ActiveBatch. We could go to 10,000 jobs and it wouldn't cost us any more. It's only if we were to add more agents to load balance that we would be charged any more, and it wouldn't be anywhere near what Control-M charges.

    I've mainly been involved with ActiveBatch and it's hard to compare another vendor when there hasn't been a vendor to compare against. As far as performance is concerned, Control-M and ActiveBatch are on par, but they're not the same because Control-M is really just moving files and running programs on mainframes, whereas we're running against Windows and Linux environments.

    The other one that's being utilized at the moment is Apache Airflow, but that's more for the developers because they like to be able to program the backend, rather than to use a frontend interface. We've been looking at how that works, but we haven't seen it to be very stable for a production environment. You can't compare Airflow with ActiveBatch, in effect.

    What other advice do I have?

    My advice would be to jump on it straight away. With the ease of installation, the expandability or scalability of the product across multiple servers with different agents, the ability to not only use Windows but Linux as well, and the fact that you can build complex plans that have multiple constraints, multiple types of scheduling, and multiple types of alert mechanisms, it's highly expandable. You're going to have a lot of fun with it.

    It's highly flexible and easy to use. In terms of what we can do, we still haven't gone to the Nth degree of what we can't do with ActiveBatch. It's incredibly flexible. We're running shell scripts that run Python scripts. We've got PowerShell scripts and batch scripts. We tie into different applications. We still haven't exhausted the potential of ActiveBatch. That's what I've learned.

    Predictability is something that is out of the control of ActiveBatch. We can set a job to run against a database, but it's really going to be the network or the database that will impact ActiveBatch. ActiveBatch will continue to run. There is an average run time that we look at, but if the network has high latency or the database is under load, the time will increase. ActiveBatch will continue to run as normal. The frequency of ActiveBatch failing is quite rare.

    We use the ActiveBatch interface up to a certain point, and then we start looking at running Python and shell scripts. That's why we have the Linux agent. We call a shell script which runs a Python script that does some manipulation and passes that information back. And then there are a number of plans that manipulate the process. In this particular plan, the CSV file is created and it's dropped into a file location. ActiveBatch is polling for that location. It sees that file. Then a Python script runs and creates an MD5 hash. When you download a file from the internet, there's an alphanumeric number that indicates whether that file is valid or not. The MD5 hash is generated on the file and when it's moved to another location, another MD5 hash is generated to determine whether there was a change in that file when it moved from A to B. It's a validation to make sure that no data was corrupted during the movement from where the file was dropped to where the file landed. Once it has been validated, the file is then moved into another location where it's uploaded into the Greenplum database and a notification is sent to whomever was involved in that particular process. It's quite involved.

    If a job fails, we have set it to wait for a few minutes and to then re-run. If that fails, we can trigger another job to continue on in that process flow, if the failed job isn't critical. Some of the plans are quite complicated and have a certain amount of logic involved, but that enables us to navigate around problems that might otherwise need a developer's assistance, if it doesn't affect the overall plan process. As long as there are no constraints involved that require the next job to run, and it can move around that job and continue on, that's how we set it up.

    We're looking forward to version 12 to see how that goes as well. We've also mirrored the database, the backend database that ActiveBatch uses. We have a failover process which was just recently installed. If one database fails, we can switch over immediately to the other database in real time.

    Overall, we're really comfortable with how ActiveBatch is performing and with what it's doing.

    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.
    Flag as inappropriate
    PeerSpot user
    Dustin McVey - PeerSpot reviewer
    BI Data Integration Developer - EIM at a healthcare company with 10,001+ employees
    Real User
    Top 20
    Maintains dependencies and constraints among a large number of workflows and it always triggers jobs at the appropriate time
    Pros and Cons
    • "We leverage the solution's native integrations regularly. We have to get files from a remote server outside the organization, and even send things outside the organization. We use a lot of its file manipulation and SFTP functionality for contacting remote servers."
    • "Between version 10 and version 12 there was a change. In version 10, they had each object in its own folder. But on the back end, they saw it at the root level. So when we moved over to version 12, everything was in the same area mixed together. It was incredibly difficult and we actually had to create our own folders and move those objects—like schedules, jobs, user accounts—and manually put those into folders, whereas the previous version already had it."

    What is our primary use case?

    Primarily, we've been using it in a localized way, but it's becoming more and more of an enterprise tool as the knowledge is shared throughout the team and department. But primarily it has been used for ETL-type work. My team is data integration and we use it to schedule our Informatica PowerCenter workflows as well as DataStage. We also use it for a lot of file transfers, such as SFTP stuff. And we've recently explored some API calls that we can use to interface with Qlik.

    How has it helped my organization?

    It's really helpful with scheduling and setting up dependencies. I primarily use it with our data warehouse and there are a lot of dependencies. First you have to load XYZ tables before it's filtered and presented in the reporting layer. It really helps to maintain those constraints and dependencies.

    We use it to schedule our data warehouse. We use the Informatica PowerCenter tool and we have Oracle's out-of-the-box Data Warehouse so there are a lot of workflows that need to run, either sequentially or that are dependent on one another. ActiveBatch really handles hundreds of workflows on a schedule and it definitely maintains those constraints. I've never seen a failure to trigger a job at an appropriate time. We definitely rely on it heavily in that regard.

    ActiveBatch was originally purchased as a scheduler, to enable us to execute DataStage jobs, but once we started to grow, and our use cases started to vary, we realized that we could use the pre-built SFTP capabilities. Previously, we had to code things in our DataStage tool where it wasn't as intuitive. You really had to get into the programming. But a business user can certainly use ActiveBatch to set up an SFTP connection, as long as they have the information. It's pretty easy to do that. Moving SFTP files around is certainly valuable to the business because I work for a hospital. The health system is definitely reliant on the data that we move around, and ActiveBatch really executes the ETL workflows that actually transform and move the data. We rely on it to appropriately schedule and execute those workflows to get the data to the right place.

    The solution has become our center of excellence for all things related to automation in our organization. We started with DataStage and then we acquired the Informatica tool and we use ActiveBatch for that. Now we're seeing we can use the scheduling capabilities of ActiveBatch to call our Qlik refresh applications. We're starting to expand ActiveBatch as an enterprise solution and other departments are also finding that they can do all the remote scripting that they used to have to do manually, or that operations would have to do, in ActiveBatch and it will take care of that on a schedule, instead of wasting man-hours.

    It also provides proactive error detection, even in real time. Almost all of our workflows have a lot of notifications set up to either email, or page, or create a ServiceNow ticket if there is a failure. We're notified immediately if something's not working as it should. That has prevented problems from becoming fires. If we didn't get those notifications, if our data warehouse was not operating as we expected it to, that certainly would cause some problems. 

    In addition, in terms of workflow completion times, I don't know what we would have done without it, as far as scheduling goes. It would probably be a lot more complicated to schedule a lot of our workflows through these other products that are more focused on the data manipulation and are not as concerned with scheduling. So to be able to schedule and set up dependencies has been pretty valuable for us. It has improved our workflow completion rates by five hours per day, because we execute our workflows daily. It has also reduced our man-hours by something like 60 percent. It has a lot of intuitive stuff so that instead of building out code for it, we can just plug-and-play with it. You put in the right parameters and it takes care of it for you.

    We have definitely been able to re-assign staff to more value-added activities as a result of using ActiveBatch. Something that has been very valuable for us is that we have been able to build our solutions in a way that, if they fail, ActiveBatch actually tries to restart them itself, without any manual intervention. If that fails it goes to our operations team. Before, that was something that our ETL or data integration team had to handle ourselves. Being able to push those issues to ActiveBach and to the other team, it has really saved us a lot of time.

    What is most valuable?

    We do a lot of very specific scheduling. You could do it as simply as, "Hey, run this every day at six o'clock," or you could do something like an exact date and exclude bank holidays. It has a very robust scheduling aspect.

    We use a lot of SFTP stuff. With version 11 and version 12 they came out with a managed file transfer. They have a lot of pre-programmed "job steps" so that you don't have to develop custom code. You can just say, "Copy file. SFTP file." They build up a lot of the common uses that you would be looking to develop yourself.

    We leverage the solution's native integrations regularly. We have to get files from a remote server outside the organization, and even send things outside the organization. We use a lot of its file manipulation and SFTP functionality for contacting remote servers. 

    ActiveBatch also has a lot of pre-built looping structures, reading files, looping-if-branch; basic programming concepts are pre-built for you and robust. That's definitely nice.

    It's very easy to use. I was self-taught before any training was available for our company. It's very easy to learn to use yourself. I have a technical background but even some of our business users, with some light training, would be able to navigate and use the tool very easily. Things like the copy files or move files are very intuitive.

    It's extremely flexible. In addition to that pre-built functionality and the ability to create API calls, it allows us to create our own service library. That wasn't default but they said "Hey, we have this package where you can build your own library." It also has some different scripting of job steps. If I want to use PowerShell to achieve something that might not be out-of-the-box, I've been able to leverage that utility to achieve whatever we're looking to do. If there's a problem that needs a solution that may not be available in our ETL products, my first go-to is ActiveBatch to do some scripting.

    What needs improvement?

    Between version 10 and version 12 there was a change. In version 10, they had each object in its own folder. But on the back end, they saw it at the root level. So when we moved over to version 12, everything was in the same area mixed together. It was incredibly difficult and we actually had to create our own folders and move those objects—like schedules, jobs, user accounts—and manually put those into folders, whereas the previous version already had it. They did allow us to filter so that we could see things, but that was not nearly as effective as what we had become used to having.

    For how long have I used the solution?

    I've been using ActiveBatch Workload Automation for three years.

    What do I think about the stability of the solution?

    It's very stable. Any of the issues that we tend to see are related to the product that ActiveBatch is trying to talk to. For example, we use the web service for our Informatica tool, and issues we see are on the PowerCenter side, not the ActiveBatch side.

    What do I think about the scalability of the solution?

    I know it has features for scaling, so as we continue to build it out as an enterprise tool we're able to use what they call a Virtual Root. The team using it doesn't see everybody else's work, they only see what's relevant to them. That's really neat. 

    We went from one team using it to some four or five teams using it now. The other teams are just starting, but I don't see any collisions. It's easy to grow.

    We have about 30 users of the solution, including developers, solution architects, operations, trainers, administrators, and data modelers.

    How are customer service and technical support?

    Their support is good. For every support question I've raised they've had very responsive teams. To date, we haven't submitted an issue that they haven't been able to correct or provide some sort of solution for.

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

    Before ActiveBatch, as they created jobs, they used our DataStage tool as the scheduler. That functionality was within the product.

    How was the initial setup?

    I was involved in the deployment of the current version. We originally had version 10, but within the last year we upgraded to version 12 and I played a role in that. From my perspective as a user of the application, it was very seamless, especially moving our existing workflows. We needed to keep them running on the new version and the backward compatibility was spot-on.

    That upgrade process took about three months but that was not a dedicated, focused effort. There were a lot of other variables.

    What other advice do I have?

    I would recommend taking the time to understand the different objects and features so that, as you grow as an enterprise, the architecture is already in place and you're not figuring it out as you go, like we did.

    The ability to automate predictable, repeatable processes is something that we haven't leveraged as much. It's the Heuristic Queue Allocation where it can schedule and manage execution of workflows with whatever resource is available. With that said, I do notice that it does track, by default, the average run time and how long jobs run. There are some default analytics that it provides.

    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.
    PeerSpot user
    Production Control Manager at a tech services company with 51-200 employees
    Real User
    Saves us a lot of money by not having to do the work manually
    Pros and Cons
    • "ActiveBatch can automate predictable, repeatable processes very well. There is no real trick to what ActiveBatch does. ActiveBatch does exactly what you would expect a scheduling piece of software to do. It does it in a timely manner and does it with very little outside interference and fanfare. It runs when it is supposed to, and I don't have to jump through a bunch of hoops to double check it."
    • "The reporting needs improvement. There is a real need for the ability to generate audit reports on the fly. It needs to be a lot easier than what I can do right now. This is a major item for me."

    What is our primary use case?

    We provide parking enforcement support for cities around the USA. So, if you are a municipality, then you may have a contract with us. We would provide you with services that would range from parking enforcement to tollway enforcement. It really depends on the end user and what the community's business is.

    All of our automation runs through ActiveBatch. We have probably close to 2,500 jobs running each day that provide support for different municipalities around the US. All of our clients' data comes to us via a scheduled set of file movements within the arrangement of ActiveBatch. At midnight, every night, we get every ticket that a municipality issued in the last 24 hours, then we put that into our database so the municipality can ensure that they get that money collected within a reasonable length of time for collection purposes.

    Each community has its own set of required rules that have to be followed, e.g., what kind of delay can happen before you make sure you collect on the debt from the citizen for having had a parking violation to when the next time you are going to go out and try to double check if they have not paid their fines.

    It is deployed via our own internal network connections. It is a locally-sourced platform for us. We don't have a lot of really complex job flows. It just isn't the nature of our business, because you can't really take municipalities data someplace else. However, our data is shared in a data center in Wisconsin and a data center in Indiana, thus our data is in both locations every day.

    How has it helped my organization?

    ActiveBatch supports 250 municipalities around the USA for parking enforcement. In addition to that, there are almost another 200 that we support. They just go out and find out who owned the vehicle that had the violation, whether it be a toll road violation or a parking violation. There are a lot of moving pieces which are supported by ActiveBatch every day.

    What is most valuable?

    The combination of time scheduled events to running the import of data into our in-house databases is always critical, and that happens every day. Critical individual pieces for us are timed events.

    ActiveBatch can automate predictable, repeatable processes very well. There is no real trick to what ActiveBatch does. ActiveBatch does exactly what you would expect a scheduling piece of software to do. It does it in a timely manner and does it with very little outside interference and fanfare. It runs when it is supposed to, and I don't have to jump through a bunch of hoops to double check it.

    What needs improvement?

    The reporting needs improvement. There is a real need for the ability to generate audit reports on the fly. It needs to be a lot easier than what I can do right now. This is a major item for me.

    We are starting to look at doing tablet and mobile device support. An easier interface to set that up would be nice. However, at the same time, part of that is my own firm's requirements. It is not easy internally to support signing up and configuring remote access, if anything, making that easier would definitely be a plus.

    For how long have I used the solution?

    We have been using ActiveBatch since 2012, and I have been part of the company since 2014. So, we have been using it for a reasonable length of time.

    What do I think about the stability of the solution?

    I find the solution very stable. 

    What do I think about the scalability of the solution?

    I run jobs across two domains, all US time zones, and I have not found an issue where I couldn't run a job across a specific time zone yet. So, I think it's pretty scalable. It does what I am looking for it to do every day, and I have not found an issue where I couldn't do something. I don't have to chase after anybody to help me figure out, "How do I make the software do X, Y, and Z?"

    A team of four of us, including myself, configure and monitor the software. I can't tell you how big the IT team is that supports the agents, which is how ActiveBatch runs, but there are a number of folks in that position. As a firm, we are not very big in numbers, but we respond pretty quickly if there is a problem somewhere internally that needs to be looked at and something has to be jumped on.

    I find ActiveBatch very user-friendly and responsive. We are a pretty small company, as far as numbers go, and if it couldn't support what we're doing, then I would find another solution.

    How are customer service and technical support?

    If I have issues with it, then Advanced Systems Concepts, Inc. (ASCI) has been very supportive with assisting us. They would jump in and help resolve the issue very quickly. They have been a joy to work with. I really haven't had any major issues with them. I have always walked away with, "Oh, here's the solution for the immediate problem." From my standpoint, that is always what I am looking for first, so I have been very happy.

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

    I have been involved in automated scheduling software since 1989. I find this to be the easiest product that I have ever used, especially compared to Robot Schedule and CA AutoSys as well as an in-house scheduling software that I had designed and developed at one time.

    How was the initial setup?

    I was not involved in the original setup.

    What was our ROI?

    We support an awful lot of clients. I look at what happens within our scheduler every morning for a review, and it is running 2,500 different workflows that probably have on average seven to eight job steps. On a normal day, I may have five that I have to worry about. If something went wrong, then I may have to rerun a job from earlier on, but that's it. There are not a lot of failures in the product.

    We run an awfully lean group to accomplish all the work that we have to do. So, there is not a lot of extra time spent running a job. The job runs when it was designed to run, and that's pretty much every day. It does save us a lot of money, certainly more than doing it manually.

    Which other solutions did I evaluate?

    The decision for ActiveBatch was already in place when I joined the company, and there hasn't been any movement to go outside to some other solution.

    What other advice do I have?

    Jump in and really look at what you are looking at, i.e. don't be afraid to question the vendor, and say, "Can it do this? Can it do that?" So, when you make the decision to use the software, you have done your due diligence and this solution will work for you. I personally think far too many people jump into the decision to buy an automated software piece without really understanding what they are asking it to do. You really have to know, "What am I looking for this software to do for me?" If you don't do that, you are probably going to find yourself unhappy at some point in time, saying, "Well, this really isn't what I thought I was getting." Then, that will end up being your own fault: The more effort you put in ahead of time, the better off you're going to be. Know ahead of time, "What am I going after here that will work for me?"

    I may not know when a client municipality is going to deliver a file to us. So, a lot of our jobs run as events, not by time. In other words, it may run at three o'clock tomorrow morning or may not run until five o'clock the next morning, because the municipality wasn't ready to send us the data yet. It is a combination of what we have scheduled, as opposed to what we react to when a file is delivered to us.

    I would rate this solution as an eight and a half (out of 10).

    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.
    PeerSpot user
    BhaskerChittibabu - PeerSpot reviewer
    Manager at a financial services firm with 501-1,000 employees
    Real User
    Top 20
    Useful prebuilt jobs, stable, and scalable
    Pros and Cons
    • "One of the most valuable features of this solution is the versatility of the prebuilt jobs."
    • "Any product is going to have some room for improvement, no matter what. I see the company has already ventured into AWS and they're constantly trying to improve the managed file transfer which they have recently improvised. I think they bought a software called JSCAPE and they're trying to improve it, which is good. I am not sure if JSCAPE would be part of the base product but currently, you have to buy a separate license for it, which doesn't make sense. If it was Microsoft, ServiceNow, or integrating with other software vendors, I would understand but JSCAPE is now in-house and I'm not sure if they can justify having a separate license for JSCAPE. I would probably expect them to be packaging JSCAPE into the base product. They did switch over from a perpetual license model to a subscription model, which hurt the company a little bit. Nobody is offering the perpetual model anymore. As long as the transition is fair for both the companies, I think it should be fine and not burn us out."

    What is our primary use case?

    ActiveBatch Workload Automation is a standard scheduling tool that you have on the market. The ultimate goal is to run everything powered through ActiveBatch Workload Automation, but we are always constantly trying to move from our legacy processes, which always takes a lot of time and effort. However, all of the new processes we are focused on implementing through ActiveBatch Workload Automation.

    What is most valuable?

    One of the most valuable features of this solution is the versatility of the prebuilt jobs.

    What needs improvement?

    Any product is going to have some room for improvement, no matter what. I see the company has already ventured into AWS and they're constantly trying to improve the managed file transfer which they have recently improvised. I think they bought a software called JSCAPE and they're trying to improve it, which is good. 

    I am not sure if JSCAPE would be part of the base product but currently, you have to buy a separate license for it, which doesn't make sense. If it was Microsoft, ServiceNow, or integrating with other software vendors, I would understand but JSCAPE is now in-house and I'm not sure if they can justify having a separate license for JSCAPE. I would probably expect them to be packaging JSCAPE into the base product. They did switch over from a perpetual license model to a subscription model, which hurt the company a little bit. Nobody is offering the perpetual model anymore. As long as the transition is fair for both the companies, I think it should be fine and not burn us out.

    For how long have I used the solution?

    I have been using ActiveBatch Workload Automation for a few years.

    What do I think about the stability of the solution?

    ActiveBatch Workload Automation is scalable.

    What do I think about the scalability of the solution?

    The scalability of the solution is good.

    How are customer service and support?

    The technical support was difficult if you wanted to escalate the issue, it takes a little bit longer to escalate. Their service model does not allow for everybody to be on the hotline all the time. I understand that, but unfortunately, with a production system, that's what it is. If there is a bug, you want that hotline as soon as possible, because we don't know the impact of it. If it can widespread, if there is an issue, or if it's contained within one or two jobs. Luckily this has not been the case. 

    It's all same architecture and framework of which you built upon several things. If there's a problem with it, you want to know it way before it impacts the other jobs.

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

    I like ActiveBatch Workload Automation's licensing model because they're not holding you down on an agentless model or agent model, where every server needs to have an agent. That's the main selling point of the solution and I hope they stay that way.

    Which other solutions did I evaluate?

    I have evaluated other solutions, such as Control-M.

    What other advice do I have?

    I rate ActiveBatch Workload Automation an eight out of ten.

    I rated ActiveBatch Workload Automation high because the licensing model is way better than other solutions, such as Control-M or other companies that charge a lot more. I like their agentless model because most of the scheduling companies put in the rules saying, that for each server you touch, you need an agent. Otherwise, they cannot communicate, and will not work. This is a large advantage for ActiveBatch Workload Automation their Agent model is great.

    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    PeerSpot user
    DBA at a venture capital & private equity firm with 11-50 employees
    Real User
    Top 5
    Good support and the scheduling works well
    Pros and Cons
    • "From a scheduling point of view, it is pretty good."
    • "The interface is not that user-friendly and is a little tough to navigate."

    What is our primary use case?

    I am the administrator handling all of the ActiveBatch-related activities. It is used for all of our processes, scheduling, and basically all of the automation.

    What is most valuable?

    The schedule is good because you don't miss any issues. Let's say you reboot the server and there are still things pending, they will resume. From a scheduling point of view, it is pretty good.

    What needs improvement?

    The reporting needs to be made easier, such as by including a dashboard. As it is now, I have to go to each and every folder in order to see the reports. If I had a higher-level view, such as Tableau-based reporting, then it would be very useful. Right now, it is built-in with the existing GUI and it is very limited. If they were to detach that and provide the data with a template report then that would be the best way to go.

    The interface is not that user-friendly and is a little tough to navigate.

    In the future, I would like to see support for mobile alerts so that we don't have to log in to find out whether there is a problem.

    I would also like to see more support for cloud-based environments. For example, we might want our workflow to include Snowflake from Amazon. So far, all of our work is on our on-premises servers, whether it is moving a file or running a database. We are now extending out and would like to use ActiveBatch to bring in more controls. Examples include using Snowflake or Redshift in my workflow. That would be very helpful.

    For how long have I used the solution?

    I have been using ActiveBatch for approximately 13 years, since 2007.

    What do I think about the stability of the solution?

    Overall, it is quite stable. Over the years, we have had very few issues with stability.

    What do I think about the scalability of the solution?

    Our company is small, with perhaps seven or eight people using ActiveBatch. We have hundreds of jobs running and we haven't had any problems. The scheduler continues to do its job.

    How are customer service and technical support?

    The technical support is pretty good.

    How was the initial setup?

    The initial setup was very straightforward and never gave me a problem.

    What about the implementation team?

    The setup and maintenance are done in-house. We have overnight support group from India and they manage the nightly processes using ActiveBatch.

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

    We are currently paying a yearly fee, although they are greatly increasing their prices and changing to a subscription-based model. Currently, we are paying approximately $7,000 yearly, which includes support.

    Which other solutions did I evaluate?

    Before choosing ActiveBatch, we looked at a couple of products and run a pilot with Control-M. 

    What other advice do I have?

    We look at different products and this is definitely a very good one. I do not have much familiarity with the cloud-based solutions but on a Windows platform, this one is pretty good.

    Overall, this is a good product but there are a lot of improvements that can be made to the interface to make it more user-friendly. Also, if I were rating the reporting then I would only score it a six and a half. Finally, we do need a solution that can reach out to cloud environments.

    I would rate this solution an eight out of ten.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    PeerSpot user
    Nick Sainato - PeerSpot reviewer
    Nick SainatoProduct Marketing Specialist at a tech vendor with 51-200 employees
    Vendor

    Hi there! Thank you for being such a longtime user and continued supporter of ActiveBatch. We appreciate the detailed review and wanted to take the opportunity to respond to some of your comments regarding areas of product improvement. I’m happy to share that we can achieve many of the use cases you’ve mentioned within Version 12 of ActiveBatch.

    First, V12 makes major improvements to our reporting facilities, refreshing our Reporting Services to become the new Instance Reporting facility, and creating a brand new reporting facility for Template Reports. This allows you to extensively report on all objects system-wide on a variety of properties and data points. What’s more, this facility operates through a pre-created ETL job that will automatically deposit new data into a heavily-documented Template Reporting database on a designated interval. This allows you to use a built-in database reporting service such as SSRS, or allows you to connect to tools like Tableau or Power BI. We include examples in our documentation of popular reports.

    V12 also brought an entirely new, high-performance Console that replaces the V11-and-earlier Admin application. This responsive, modern UI has a familiar feel while dramatically improving the user experience. You can do things like tab documents, open multiple views and editors at one time, and tab overarching connections to multiple Job Schedulers. We released a native mobile app for iOS and Android at the same time, meaning you can enable push notifications to approved devices, and monitor the status of your operations from anywhere in the world. You can also respond to alerts by re-triggering failed jobs, re-queueing jobs sitting in a machine bottleneck, and perform object operations like disabling and triggering.

    Finally, we’d like to reiterate the powerful abilities of our Service Library and Rest API Adapter, which allows you to connect, without scripting, to any server, service, or application. If our prebuilt Job Steps for Amazon EC2 only solve one piece of your cloud strategy, then you can easily connect to other services like Snowflake in just a few minutes. You can easily turn the resulting methods and functions into your own custom drag-and-drop Job Steps for infinite extensibility.

    We hope ActiveBatch continues to be an essential component of your organization’s IT strategy and critical IT operations. Please contact us and we can provide more information, documentation, and training materials on the features above.

    Senior Data Engineer at a insurance company with 501-1,000 employees
    Real User
    Top 20
    Very straightforward configuration and easy integration with other systems
    Pros and Cons
    • "Easy to configure and simple to develop new features."
    • "A cloud option is not provided as a free feature, making it a costly solution for smaller organizations."

    What is our primary use case?

    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. 

    What is most valuable?

    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. 

    What needs improvement?

    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. 

    For how long have I used the solution?

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

    What do I think about the stability of the solution?

    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. 

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

    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.  

    How was the initial setup?

    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.

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

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

    What other advice do I have?

    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. 

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: I am a real user, and this review is based on my own experience and opinions.
    Flag as inappropriate
    PeerSpot user
    Buyer's Guide
    Download our free ActiveBatch Workload Automation Report and get advice and tips from experienced pros sharing their opinions.
    Updated: August 2022
    Buyer's Guide
    Download our free ActiveBatch Workload Automation Report and get advice and tips from experienced pros sharing their opinions.