ActiveBatch by Redwood Reviews

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

ActiveBatch Workload Automation enables us to automate and manage a wide range of business processes. 

It helps in automating complex workflows that may involve multiple tasks. The platform provides a smooth integration between various other systems, applications, and their databases. 

It is best suited for hybrid IT environments. 

ActiveBatch provides robust job scheduling capabilities. It allows the users to schedule and execute the tasks at specific times. The platform ensures that tasks are assigned to the respective resources efficiently. 

Error Handling is one of the best standout features of ActiveBatch.

ActiveBatch Workload Automation has truly been a transformative solution for my organization. 

It has completely changed the work environment. It has made work much easier and faster. The time taken by the tasks to get executed has gradually decreased over time. 

Managing the complex workflows and arranging the job processes has become easier. The platform handles a wide range of automation tasks, ranging from simple job scheduling processes to complex processes. 

The integration capabilities and reliability of the software are exceptional. 

The built-in templates have been of great help in speeding up the automation processes.

ActiveBatch's integration capabilities are impressive. It can connect smoothly with various other systems. It ensures that data flows smoothly between the systems. This has improved the overall data accuracy. 

The reporting and monitoring features have been a game-changer as it helps to keep track of the job status. This helps in identifying the issues and resolving them as soon as possible. This ensures that the task execution runs smoothly without any interruptions. 

The way ActiveBatch handles and adapts to the changing demand is remarkable.

The user interface can be improved so that it is more appealing and accessible to new users. 

Enhancing the debugging tools can help users to identify the issues more effectively. 

Improved mobile access can enable us to monitor and handle workflows with ease. 

Machine Learning features can be added in the future and offering advanced customization could be of great help. 

Pricing of the product can be made transparent so that new users can get an idea about the operational costs associated with the product.

I have been using ActiveBatch Workload Automation for the past seven months.

The overall scalability provided by ActiveBatch is great.

I switched from a previously used solution to a more modern automation solution like ActiveBatch due to the fact that the features in ActiveBatch were more advanced and it helped me resolve all the issues. 

The previous automation tool could not adapt to the changing requirements. With ActiveBatch, the work has become truly exceptional.

In terms of ROI, ActiveBatch has given significant value to the organization. There have been reduced operational costs and improved efficiency. It has allowed us to allocate the resources more wisely.

I'd advise users to start by knowing what the actual requirement is and thoroughly assess the automation needs. New users should take advantage of the demos and trial versions so they get an idea of the platform.

The task scheduling was manual earlier, and it was a very difficult and time-consuming task to schedule jobs. Even after this process, it was difficult to find out what was wrong if the job/task has been failed. With the help of ActiveBatch Workload Automation, the entire workflow automation has been automated, and we can schedule our entire process from a single point of contact with features like real-time monitoring. We're streamlining IT operations, getting centralized security, and having quick and reliable integration features that are game changers in the industry.

Active Batch has helped us in a lot of ways. For example, earlier, the process was very time-consuming, and we needed to always have some resources to monitor everything. We needed a resource to schedule, and the entire workflow was not easy. With ActiveBatch, we schedule the tasks automatically and monitor them efficiently to track the tasks in real-time. Mainly, we have streamlined our entire IT operations. Now, we don't always need a resource to schedule or manage things. It does its tasks on its own, and even we can track and audit them efficiently and effectively.

There are many features I found very useful. It was the automatic scheduling of jobs and monitoring in real-time that were very useful. It has streamlined the entire IT operations. A lot of organizations are getting help from this. For developers, it is easy to orchestrate the workflows and the integration has been very easy. We can easily integrate ActiveBatch workload with any tool without any headache. We can optimize existing scripts also. Auditing is made simpler for administrators now.

Whenever there is an overload, we are seeing crashes happening. It is something that has to be taken care of. 

Triggers play a predominant role in doing an automated task after an event. It was eventually used to erase the boilerplate code, however, unfortunately, the triggers are not very reliable in ActiveBatch. It is not performing what it had to do at certain times. 

The application is a bit complicated and it is not very user-friendly for beginners. That might be a disadvantage until they get familiar with it.

I've used the solution for six to 12 months.

We did not previously use a different solution. 

ActiveBatch is the best in terms of reliability and helps with cost-cutting. The licensing was a complete green flag for the product from my side.

We did not evaluate other options.

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.

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.

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.

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

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

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.

The technical support is pretty good.

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

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

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.

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

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.

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.

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

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

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

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

We're able to create workflows without coding.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using ActiveBatch for almost five years.   

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

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

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

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

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

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

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

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

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