ActiveBatch by Redwood Reviews

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

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

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

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

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

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

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

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

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

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

I rate this solution eight out of 10. 

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

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

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

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

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

ActiveBatch Workload Automation is scalable.

The scalability of the solution is good.

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

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

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

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

I rate ActiveBatch Workload Automation an eight out of ten.

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

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

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

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

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

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

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

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

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

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

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

I find the solution very stable. 

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

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

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

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

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

I was not involved in the original setup.

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

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

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

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

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

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

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.

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.

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 controls just about everything in our organization. We do server monitoring with our EDI feeds being inbound and outbound. We do Oracle processing with it. 

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

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

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

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

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

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

I find all the features valuable. 

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

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

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

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

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

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

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

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

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

Eight years.

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

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

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

Everything was a manual effort before ActiveBatch.

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

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

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

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

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

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

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

We did evaluate other products before purchasing.

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

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

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

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

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

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