The initial setup and configuration are time-consuming. 

The initial setup was not much of an issue.

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

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

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

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

I was not involved in the original setup.

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

The setup is straightforward.

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

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

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

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

The initial setup is straightforward.

The initial setup was straightforward.

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

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

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

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.

As a beginner, the setup was pretty hard due to a lack of deep guidance or documentation.

The initial setup was a bit tedious due to a lack of proper user guides.

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.

The initial setup was pretty straightforward, with no major difficulties encountered.

The initial setup was complex as we wanted to set it up on different environments like Windows and Linux.

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.

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.

The initial setup for ActiveBatch Workload Automation was straightforward.

It was straightforward to set up. Only in the end, when we were importing files, did we feel a little more documentation would have been required.

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

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

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.

The technician who researched solutions and found ActiveBatch was the guiding force as far as getting it installed, set up, and configured. So I don't have a lot of experience with that side of it. I've mostly been designing how jobs should work and be built. The setup seemed like it was straightforward from what I could tell. I don't think it was super-difficult.

It took us a good year or two to fully convert all of our jobs to ActiveBatch. But that was because we had a large number of jobs that were in the old tool and we had to be careful about adjusting things that are in a production environment. We spaced it out a while to get everything converted.

Our implementation strategy was mostly looking at which clients had more complex jobs and which clients had simpler jobs, so that we could start with the simpler ones as we were getting our feet wet using the tool. Then it was just scheduling out which clients would be converted when and creating the jobs to mirror what we already had in the other tool. It was nothing too complicated.