ActiveBatch by Redwood Reviews

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. 

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It allows for lower operational overhead.

I buy features when I have need of them.

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

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

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

ActiveBatch is used for multiple purposes, including as SAP jobs, file transfer systems (FTP), and data warehouse loads. 

ActiveBatch has numerous functionalities that support different types of workflows, including batch calls and service calls. 

The format of job scheduling is well organized and very similar to what we use in everyday life hence making it easy to use. It is able to control jobs for multiple environments over and across different servers.

We can use and set up automated remediation and alerts for operations that we have created.

ActiveBatch has reduced work by providing automated workflows across several different applications. ActiveBatch also has some of the triggers, such as FTP file triggers, message queue triggers, and so on, to run jobs sequentially, making sure they will be handled in a reliable way. 

It sets up alerts for operational peace of mind. It also has custom rules that we can apply to advanced data/time scheduling and fiscal calendar. 

The best feature that it has solved is the ability to trigger jobs upon completion of warehouse nightly batch jobs.

ActiveBatch has numerous capabilities in the automation tool environment. A normal IT person can only scratch the surface of the tool, whereas a developer who has knowledge of the development of the application over a cloud will likely be able to utilize the maximum of the automation tool. 

There are many of the major utilities, like file transfer systems, job scheduling systems, and others triggers that are amazing to use.

The documentation is very limited, and it can be improved. 

The service for Level One support could be made more reachable. Service pack updates are sometimes hidden/undocumented. This can cause some of the jobs to break up after the SP is installed. They need to ensure users are using the technical support to configure everything at the initial usage. It is sometimes hard to set up permission levels.

I've used the solution for one year.

We send out requests to leaders for the inputs, and the inputs are either shared via emails or uploaded on SharePoint. Then, we download that data process them, and convert them to consumable format in Excel, the excel files then get uploaded onto SQL servers which are connected to visualization tools, post refresh we publish the reports onto services.

The entire process of scheduling, running DB jobs, applying security, refreshing DB, publish was done manually and repeated whenever new inputs come in, now ActiveBatch has streamlined the entire flow with a minimal error rate.

My team consists of five associates. We mainly deal with pricing, sales operations, reporting, forecasting, and several other analytics.

The use of ActiveBatch has made all our lives easy by automating a lot of manual repetitive tasks that we do on a daily basis. We save hours and effort aand gain a high accuracy rate.

Approximately ~20 hours of manual effort have been reduced to ~5 hours with the help of ActiveBatch.

It has enabled us to work on multiple platforms at the same with its capability to integrate with other applications and web services.

The most valuable feature is the drag-and-drop functionality, which makes it a very easy-to-use software for anyone who is working on the software for the very first time. There is minimal coding knowledge required.

I like the ability to integrate with other applications, software, and cloud services which empowers anyone using the software to work on various platforms at any given time.

The job scheduling feature increases the efficiency of the software as it requires minimal manual intervention.

ActiveBatch is a powerful and robust workload automation tool that is the best in the market. I do not see major setbacks in the software. However, there are a few things that need to be improved to make it more efficient and provide a better user experience, such as: 

• reducing the lag
• having more security privileges
• pricing that is more affordable.

However, these minor improvement areas would not impact the efficiency or accuracy of the software. ActiveBatch still remains on top of all the workload automation software out in the market.

I've used the solution for one year.

I do not foresee any challenges with the software scalability, bigger organizations can easily deploy however pricing might be the primary concern for smaller organizations.

I do not have a case to bring out as I have not faced an issue and have never needed to reach out to support.

Positive

There was no transition from similar software.

The initial setup is a little complex; providing a well-documented user guide would resolve the issue.

We handled the setup in-house.

In terms of ROI, the solution has saved manual hours (from ~20 hours to ~5 hours in a month) and increased accuracy by ~17%.

The initial setup is a little complex. Subscriptions can be made for a group at a reasonable price.

I did also evaluate Jira.

The software is definitely the best. With minor fixes, it could be great and remain very competitive.

The primary use case of using ActiveBatch Workload Automation Software is that it enables IT teams to define, schedule, and execute a wide range of batch jobs and workflows, including file transfers, database changes, and application integrations (and much more), all from a single central platform. 

The software can automate mission-critical business processes with ease. My work environment has a large number of applications that must be handled simultaneously. In this scenario, the software really helps to monitor all the processes, which reduces manual intervention and human error while increasing productivity.

My organization's IT operations have been made more efficient by Active Batch, which automates time-consuming, repetitive procedures. The active batch may assist in making sure that crucial activities are carried out in the proper sequence and at the appropriate time with the use of features like job dependencies, event triggers, and notifications. 

Additionally, the software offers real-time monitoring and reporting features that let IT teams keep tabs on the progress of their batch operations and workflows. 

Overall, the software helps organizations improve the reliability and performance of their IT systems.

The Active Batch Workload Automation Software has a feature that I truly appreciate: it automatically distributes workloads over various servers and resources, improving performance and ensuring that the necessary resources are used for the right jobs. 

The software also supports a wide variety of platforms and applications, including Windows, Linux, Unix, and many more popular enterprise applications, making it a flexible and versatile solution for automating critical business workflows. I highly recommend the software.

While ActiveBatch is a robust and comprehensive workload automation software, I feel that it will be of great help if it is improved in the following areas:

As more organizations are moving towards a cloud-based infrastructure, ActiveBatch could incorporate more capabilities that support popular cloud platforms, such as AWS, Azure, and Google Cloud. 

Active Batch could also offer deeper integration with DevOps tools to enable more streamlined and automated software development processes. 

Apart from these enhancements, everything about the software is highly appreciated.

I have been using this solution for the past six to 12 months.

ActiveBatch has a fantastic interface allowing us to efficiently create, manage and monitor workflows. It also offers a drag-and-drop visual workflow designer, enabling users to create complex workflows without coding quickly.    

We can integrate this with various platforms and technologies, including Windows, Linux, Unix, and SQL Server, and this makes it a flexible tool that can be used to automate a variety of IT processes. 

ActiveBatch helped us automate and schedule routine tasks such as data backups, file transfers, database updates, and report generation, which frees IT staff to focus on other studies.

The most valuable feature of ActiveBatch Workload Automation software is its pre-built job steps. The software comes with an extensive library of pre-built job steps that can be used to automate processes in various systems and applications. Due to this, users won't need to create their scripts, which can save time and lower the possibility of errors.

ActiveBatch is a little complex. A steep learning curve can be associated with using ActiveBatch, and it may take some time for a few users to become proficient with the tool.    

Apart from that, I can easily say that ActiveBatch is the best in the business. 

I've used the solution for more than a year.

Overall it is a stable, great solution.

It is a very good, scalable solution.

Technical support is great.

Positive

Previously I was using a different solution.

I switched since that solution was slow and also the cost was more.

The setup is straightforward.

We deployed the solution with the help of an expert.

This solution is better compared to other software.

We mainly evaluated options based on the cost and flexibility of the software.

ActiveBatch is used for scheduling our nightly batch processes. That is our main use at this point. It includes billing, processing, claims, commission statements, and a lot of reporting. It's all tied into that batch process.

We do use the built-in REST call process for nightly printing, coming out of that batch cycle. We distribute the nightly reports out of the batch cycle to different departments using ActiveBatch. It's used for FTP processing every week coming out of the weekly commissions process.

The most important part to us is to keep those nightly batch cycles in an easy to read format, which is where ActiveBatch Plans come into play. We run these cycles in four different environments, from development to production and a couple stops in between. Keeping all of those jobs separate from one another is key for us.

Outside of batch, we do run a process every five minutes throughout the day during business hours to scrape data from our mainframe entry system to our new policy administration system. As people enter claims into the mainframe system, those claims get moved over within five minutes, rather than waiting for the mainframe batch cycle to run that night and those claims not being seen until the next day. That saves us up to 24 hours. The business end-users can get that data within five minutes now.

ActiveBatch has allowed us to move forward quickly with our modernization effort, to get off of the mainframe and to move that data to a distributed environment. It has been huge for us to use ActiveBatch to run these nightly processes: everything from Dev to QA, UAT, and Production. Those are all cycles that we run every night to allow different users to test processes that they're working on in each of those stages, to get them into production and off the mainframe.

With the systems we're using now, it's a lot easier with ActiveBatch. The mainframe is so manual. If there's a problem with some mainframe code, it requires a call to a developer, but our new system works great with ActiveBatch because everything is built into that system. There's no JCL code or mainframe COBOL code, up front. Our batches just work seamlessly between ActiveBatch and our new administration system. We've had no problem with our batch processing from that point of view. Whereas with the mainframe, it's a struggle at times. If we have a problem with a job and it cancels, we may be waiting three hours for a developer to get online, troubleshoot, test, and get a fix in place so we can finish the cycle. We've not had that issue with ActiveBatch.

A lot of the built-in processes are among the most valuable features because when just starting out, although I went through the ActiveBatch Boot Camp — and I've got a couple of other people who went through it as well — it was a little overwhelming, not having used the product.

We found it easier once we were using the product and then doing refreshers on the Boot Camp or doing the deep dives that ActiveBatch provides. Even the Knowledge Base articles allow us to grow and let us know what we can use in our environment.

We're able to use the Plans, rather than seeing individual jobs within all four of our environments. Seeing all of these jobs individually would be overwhelming to try to easily decipher workflows, whereas everything is nested nicely within each Plan for us. It makes it very easy to read the next day, and to look at how each cycle ran. It also helps with troubleshooting if there's an issue with one of them at night.

As far as centralization goes it's nice because we can see all these processes that are tied to this larger process. The commissions, FTP processing, the reporting, the file moves to the business users — all that is right there. It's very easy to read. It's easy to tie it together, visually, and see where each of these steps fits into the bigger picture.

Other important features for us are file triggers, file constraints, and job constraints, because of the sequential nature of the batch process. The file triggers have made our processes more efficient and reduced delays. It might be minimal at this point, but it would still be a manual process that would have had to be done. Our second-shift operator would have to wait each night for that mainframe cycle to finish and then manually trigger certain processes within each of our ActiveBatch cycles.

It's also a very flexible product. We're just over a year in and we're still getting our feet wet and realizing its potential. One thing I am anxious to roll out — and I've tried to push some business end-user meetings, but it's still a little early in the process as everyone has been so busy with the overall modernization effort — is the Self-Service Portal. It will allow the business users to run processes on-demand, rather than putting in a ticket to have IT do it for them. This would also allow other IT users to see any processes they may be testing, in the ActiveBatch environment.

In addition, the Jobs Library has been a tremendous asset. For the most part, that's what we use. There are some outliers, but we pretty much integrate those Jobs Library steps throughout the process, whether it's REST calls, FTP processes, or file copies and moves. We do use some process job steps to call out external batch processing through external scripts, but most of what we're using is what is built-in, at this point. That has helped us to build end-to-end workflows.

When our mainframe process ends each night it sends out an email to certain users that the system is up, so that they can log on and do work on the mainframe at that point. We tried to use that email as a trigger for our ActiveBatch printing processes but it didn't work out too well. I believe it ended up being a bug that they're going to address in a future release.

But at the same time, that was an easy fix. We were able to change that from an email trigger to a file trigger. Now we have the mainframe job, in addition to sending out that email, create four text files that will trigger our four batch cycles through ActiveBatch. That has worked out great for us.

One thing I've noticed is that navigation can be difficult unless you are familiar with the structure that we have in place. If someone else had to look at our ActiveBatch console and find a job, they might not know where to find it. That being said, I have been using that search function a lot lately. That search function is definitely your friend.

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

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

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

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

We didn't have a previous solution.

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

Out-of-the-box, it was a challenge to understand the best way to structure it for our system. Obviously you don't know what you don't know. Once we started using it, we realized the best way to lay it out for ourselves and it became easier and easier over time. I've had to move things around a great deal to make it easier because we weren't sure, when starting, how to set it up, as far as our environment goes with its file structure and object structure.

As far as objects go, it's pretty straightforward. It's like any other file structure. It's just a matter of knowing what you need for your environment, which is something you learn as you go: You need these things in this folder, you need those items in that folder. Do you want all your FTP processes in one folder or do you want them underneath a certain project that they're tied to?

As far as setup and configuration go, they're very straightforward. I've never seen an issue with that or with upgrading.

The planning stage took a while. We got the product and then I and another operator went through the training, which we did in a week. The actual deployment has been scattered. The initial deployment went well, but it was staggered because there were, and still are, different pieces flowing in, a little at a time. It won't be really set until we get all of our business on this platform. It's as set as it can be right now. The actual deployment slowly fell into place. I hate to say it took two months to deploy this product. It didn't. But to get to where we were comfortable running that first batch cycle, it probably did, but that's no fault of ActiveBatch. That's just developers getting the pieces to us and then us figuring out how to use ActiveBatch in the most efficient manner.

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

For ActiveBatch there were five or six people within Operations/Infrastructure involved in the deployment. We're a small-to-midsize company with a couple of hundred employees.

It's hard to say how many hours it has saved because it is new. There have been a lot of hours put into learning the product. For instance, putting SSIS packages in has required a lot of Knowledge Base research on ActiveBatch's site. The Knowledge Base is tremendous there. I've really never had an issue finding plenty of information, sometimes more than enough information, to decipher. But in terms of man-hours, at this point, it's just figuring out the system and how to set up these jobs to work together. Those savings will definitely really be seen down the road.

But our return on investment is because it has allowed us to move forward with this project. Even with just using new business, it's allowed us to move incredibly fast when it comes to putting these batch processes in place. So far there's limited data and each cycle runs in 10-20 minutes, but at the same time, on the back end, it's providing that foundation. So we'll know what we need to do when we have more data. For example, currently, load-balancing is counterproductive. There's so little processing going on that it would take longer to load balance this 10-minute cycle than it would be to just run straight through.

The cost is outside the scope of my job responsibilities. Obviously we're using it, so it was worth the cost. I think it's a tremendous product. I don't know what the cost is compared to others, but having seen the results, it's worth it.

We recently signed up for the certification courses and training, which is money well spent. Anything involving training is money well spent, but especially with a new product that is going to be a major part of your environment and your business. From what I've seen, the videos and online training through ActiveBatch are tremendous. They provide examples, and they actually provide a test environment with jobs that you can put into ActiveBatch. You're able to run these jobs, make changes to them and work through the training with them.

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

Jump in. That's what we did and we're seeing the results. I can't stress enough how much it's allowed us to move forward with this modernization project. Overall, it really has been seamless. There have been a lot of hours on my part, learning the system and researching different processes that I need to put in place for the cycles. But to anyone else, the end result probably appears seamless. It is a lot of work learning it, especially if you have no prior knowledge of enterprise job schedulers and that type of flow. But ActiveBatch provides a wealth of information; their Knowledge Base is tremendous. The support gets back to you pretty much immediately. It might take them a couple of days here and there while they're researching or working with their engineers to replicate a problem.

And sign up for the training, for sure, as well as the additional training certification. In the year since I took the Boot Camp and worked my way through putting this in place to meet our immediate needs, when I revisited the Boot Camp, I found there was a ton of stuff that you forget that you can be using. In that initial Boot Camp, you're really not sure exactly what you're going to use it for. Once you start seeing ActiveBatch processes in your system and go through that training again, you realize, "Oh yeah, I can definitely see where I can tie this in," or "Yeah, we can definitely use that here or we could use this function in this way instead of that way." It will definitely help you become more efficient.

It's easy to learn the basics. It's just a matter of knowing what you need to know, what you need to use it for. At that point the ball is in your court because, while it can definitely be challenging, at the same time it's very rewarding to see things fall into place the way you pictured them. It is a very powerful tool and we've only barely scratched the surface. Keep learning. I'm learning more and more processes within ActiveBatch every day. It's definitely an ongoing process.

What I've learned from using ActiveBatch is that the sky's the limit. With all the additional, third-party licenses — Active Directory, System Manager — at this point it seems endless for us. I honestly don't know where we would be without it at this point.

We just started testing SSIS packages, as we're trying to move those off of the SQL environment and into ActiveBatch, rather than setting up schedules within SQL. We started testing one, out-of-the-box, and we're ready to move that to production this week. There will be more after that.

We aren't leveraging the cloud. We are trying to get into that area but, at the same time, we're focused on this part of our modernization project right now, getting off of the mainframe first and onto the distributed systems. Then we can take it another step. We don't have any of those additional licenses for integration with things like SharePoint, Informatica, or ServiceNow. Those options are definitely something my manager has his finger on. He knows those are available and he realizes ActiveBatch can definitely be leveraged to a greater extent.

Our developers work outside of ActiveBatch. It's mostly me who puts together the ActiveBatch jobs. The developers are mainly mainframe developers who don't touch ActiveBatch, or they are application developers who tie everything together into this entire modernization effort. There are a ton of products tied into that effort, ActiveBatch being one. ActiveBatch "brings the others together," such as printing from a third-party vendo, our insurance suite for billing, claims, commissions, etc. A new underwriting tool will also be tied in eventually. So most of the developers are working on those other applications. Direct users of ActiveBatch boil down to me and a couple others who are familiar with Activebatch but who are not as familiar with it as I am.

Currently, any issues with the batch processes are more the result of a learning curve for us.

I would rate the solution at eight out of 10. I'm a stickler with ratings. Nine would be the highest I would ever give anything because nothing is perfect. Here, it comes down to the fact that the navigation can be clunky at times, but I think that's more on you to learn. One thing ActiveBatch could do is provide more examples of real-life business use and business case examples, that show how others have structured their systems. That would probably be a big help. They do tell you how to organize jobs within Plans and you can nest things that way, but more real-life examples would probably have helped me to see how other businesses are using it or how their folder or their object structures are set up.

I love the product. It's exactly what we were looking for.

We have around 20 scheduled jobs we run every few hours. These include our price fetching jobs, market tracking jobs, subscription checking jobs, profit calculation jobs, etc. These are pretty long scripts with complex instructions to handle multiple data from a different database, microservice APIs, and many public market exchange APIs. All this data crunching was difficult to perform and maintain before ActiveBatch, however, once we started using ActiveBatch workload automation software, scheduling these jobs and tracking data crunching became easy. 

ActiveBatch has improved our organization by making job scheduling and API integrations very easy to use and to get started with. Earlier, we needed to assign these tasks to a high-paying highly-skilled resource. Now, we can train anyone to do the same job with very little effort. Our operation costs are significantly reduced because of ActiveBatch. Now, anyone can complete automation tasks without much knowledge of how computer API works and with no knowledge of coding. This has made our automation easier.

Some of the features we found useful for our use case are:

• Job scheduling. It has helped with scheduling complex jobs with simple scripts.
• API integration. It is very easy to set up regular Rest API calls and data gathering.
• Time Savings. Tracking multiple servers for downtime and multiple jobs logs is very time-consuming. We have to switch between multiple tabs and applications for all this. However, ActiveBatch made it very easy to track the downtime of our own services and logs of our cron jobs very easily. 

Overall, we found these valuable

Some improvements can be made to the user interface. I personally love to see ActiveBatch keep up with current trends in UI development. 

Also, some improvements can definitely can be made to make ActiveBatch more beginner friendly.

The custom theme could be a new feature suggestion for ActiveBatch.

Apart from these, I don't have any suggestions for ActiveBatch. They did a pretty good job of giving the best state-of-the-art features. All of these features are very well thought out and very useful

I've used the solution for two years.

The stability is great.

The scalability is great. We are onboarding new users, and our number of jobs is growing. We have not faced any problems.

Technical support offers great support with a fast response time.

Positive

ActiveBatch is the first software of this nature that I have used. 

The initial setup is straightforward.

We handled the implementation with an in-house team.

ActiveBatch gave us a good ROI in our organization.

The features provided in ActiveBatch are worth buying, and the cost makes sense for the number of features provided.

We did some research on VMware and IBM Workload Automation.