What needs improvement with ActiveBatch Workload Automation?

After upgrades we are facing a few issues and errors triggered, so focusing on this would be appreciated. Some of the advanced features in the user interface are a bit confusing even after referring to the documents. Improvement in support is much needed; there is a lack of training videos that would help us gain more understanding of the product. Sometimes, triggering fails and we have to face a lot of issues, Initially while setting up installation we will be confused. Integration with other applications should be improved

There are a few improvements needed: * ActiveBatch Workload Automation is a super robust application for regular SQL tasks or other file maintenance - although it needs a few tweaks. * ActiveBatch's user interface needs an update as some features are hidden and repetitive clicks are needed to access those. * ActiveBatch scalability can be increased to help working on larger workloads. * ActiveBatch event-based triggers are not reliable at times. * ActiveBatch UI could use a little more help, and video tutorials would be greatly appreciated for user guides.

This product is the gold standard of all the automation tools around. You can schedule jobs easily. It is faster and also more efficient. The product also provides a detailed dashboard after the endpoint security scans are performed. The only service that needs improvement is integration support. There are very few documents that provide us with detailed information on the troubleshooting of errors that occur during integration with the existing environment. The team could create more documents and also publish blogs to support customers with queries.

The product should be improved by providing a customization option. It would be very helpful in getting our own options as required. The software can still be more user-friendly. By providing training, we could explore as many options as possible, and the mistakes could be more easily avoided. Pricing can be minimized a bit. Instead of having to upgrade each of the execution agents, there should be a mechanism in place where the agents are automatically updated when a new version is released. Otherwise, it is very good software.

Setting up the software was hard. This could still be made easier. At times, the email alerts won’t work properly. There should be proper documentation for the email workflow. The new version looks good, however, it has lots of lag and often crashes - unlike the older versions. Exporting the documents in .jpg format was a bit difficult. Customer Service could be better.

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

The only issue I have is the price. It is a bit high compared to the other similar tools, yet the use case has been brilliant compared to others. An additional feature would be the easy download of the data. I'd like to see that in this as a tool. Except for the GUI, everything looks good.

The monitoring dashboard could have been more user-friendly so that in the monitoring dashboard itself, we can see the total number of jobs created in the system and how many were currently active/scheduled/chained. The reports could have more pre-defined options, such as killed/failed jobs from the current month. That way, we can get the reports quickly and help the audit process. Whenever any job fails in the system, it should be listed based on the priority of the job incident and should generate and assign it to the respective job owners.

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.

An area for improvement in ActiveBatch Workload Automation is its interface or GUI. It could be a little better. There isn't any additional feature I'd like to see in the tool, except for the GUI, everything looks good.

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.

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.

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.

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 know that there are some improvements that I have brought back to the development team that they want to work on. The graphical interface has some hiccups that we have been noticing on our side, and it seems a little bit bloated. While the console app works well, they have some crucial design flaws within the console that still need to be worked out because it is not working exactly how we hoped to see it, e.g., just some minor things where when you hit the save button, then all of a sudden all your job's library items collapse. Then, in order to continue on with your testing, you have to open those back up. I have taken that to them, and they are like, "Yep. We know about it. We know we have some enhancements that need to be taken care of. We have more developers now." They are working towards taking the minor things that annoy us, resolving them, and getting them fixed.

We are moving to version 12 soon, and I believe that interface is going to be more of a "webbie" look and feel, but I can only comment on version 11 which is what we have. A nice thing to have would be the ability to comfortably pass variables from one job to another. That was one of the things that I found difficult. Other than that, it's all good.

There are some issues with this version and finding the jobs that it ran. If you're looking at 1,000 different jobs, it shows based on the execution time, not necessarily the run time. So, if there was a constraint waiting, you may be looking for it in the wrong time frame. Plus, with thousands of jobs showing up and the way it pages output jobs, sometimes you end up with multiple pages on the screen, then you have to go through to find the specific job you're looking for. On the opposite side, you can limit the daily activity screen to show only jobs that failed or jobs currently running, which will shrink that back down. However, we have operators who are looking at the whole nightly cycle to make sure everything is there and make sure nothing got blocked or was waiting. Sometimes, they have a hard time finding every item within the list. Now, it integrates well with our other solutions. There were some issues initially with getting ActiveBatch to work, but once we found a solution that worked, it was easy to replicate. The initial issues were a mixture of the fact that very few people had done this type of work before, and partly the person we had working on it at the time. We're not sure exactly what the issue was. We actually reached out to ActiveBatch who helped us to get this to work. It is a very complex application because the code we are trying to connect to was COBOL based and still dealt with INI files. So, we had to trick the system into thinking it was calling the system the exact same way. Once we did, everything worked fine, including getting the error messages back and being able to display them within ActiveBatch. It was the connection between systems that became complex. Basically, we had to set about a dozen environment variables within a script in ActiveBatch. So, when we called the outside application, all those variables were set and we could understood what it was trying to do. The complexity was on the actual calling of the third-party application. It was not from the ActiveBatch side. You have to be careful with automation tools. We had one job where the person who initially programmed it created an infinite loop, so it kept triggering itself. It ran for less than a second, so we couldn't stop it.

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.

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.

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

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

The only thing is that it does have a little bit of a learning curve because it is fairly complex. You have to learn how it does things. I don't know if it's any worse than any other tool would be, just because of the nature of what it does. Like many things, you learn how to do something initially and then, a year or two later, you might find a better way to do it and you have to adjust how you did it before. So the learning curve is the hardest part. Even then isn't bad, because any tool is going to have that type of learning curve. We're migrating to version 12 and I know they've made a lot of improvements that can help with navigating that application. I expect that would improve it.

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.