The initial use case is that we use it to centralize everything, including all jobs from across different environments. Our goal is to be able to do all of the maintenance centrally.
When our jobs run, our team handles the jobs and they are not assigned to other teams. The output, which is on the backend and put into the database, is available for everyone.
JAMS helps us to deal with the small issues that come up here and there because we implement notifications for jobs. Whenever a job fails, it sends a notification and most of the time, there is a setting in the configuration that has to be changed. We have JAMS configured in a data-driven setup.
Whenever a job runs, it reads the configuration settings that are specific to it. If ever there is an issue, it's typically because we have the wrong configuration. In cases like this, we tweak the configuration and then somebody runs the job again by right-clicking on it.
We have JAMS set up so that we are running two interactive agents. One is a scheduler and the other is exclusive for SSIS execution. These are important to us and without them, it's going to negatively affect the business.
The way that we implemented and use JAMS is in a centralized configuration. We don't have people running jobs on their desktop because it would mean that we don't have visibility of it. Instead, everything has been migrated to JAMS so that it can run centrally. If anybody needs to run a job or perform any execution, especially for production, they can do so in JAMS. Later, we can look and see who ran what jobs at what times, and if ever there is a modification then we will know who modified it.
JAMS is able to handle exceptions in different ways. The way that we have it configured is to notify us. The process may be retried several times and we can set the limit for this. We also configure what the delay is between retries. It will depend on the use case and how long it takes. However, if it fails then it has to notify another group so that they can take a look at what the exception was.
We have a job that is similar to a report subscription, and this is done for each of our 50 partners. Prior to JAMS, we were required to run 50 different jobs. As it is now, given that JAMS is data-driven, we have only created a single job. It is written as a workflow with those configuration items. We don't need to change the job or add to it. Instead, it reads the configuration table and runs the 50 processes right away.
If there is a process that needs to be disabled then we do so in the configuration table, and the workflow picks up the changes. Having a single job taking care of the 50 processes makes the system more flexible.
JAMS helps free up time for our IT staff because it's centralized and the logging is there. The time that IT spends troubleshooting a job has been significantly reduced. The amount of time it saves varies on a case-by-case basis. For a more complex job, it can save more time. If we consider SSIS, it has its own logging capabilities but it requires that somebody with the right permissions go in and open the logs. Not everybody has permission for that, so the job depends on perhaps a single person. Often, that person has several responsibilities and other things to do, so the task can take longer to complete. JAMS collects all of the relevant logs, and having them centralized means that several people can view them, rather than only those with that application-specific set of permissions. This is one of the reasons that it saves us time.
The most valuable feature for us is that it's DR-ready. With respect to disaster recovery, it has the built-in capability for failover to our DR site. If all of the required ports are open, it can be done seamlessly.
We test the disaster recovery capability every now and then because it is important for us to be able to failover to another site. As long as that works, if we have a problem then it's business as usual. A problem doesn't impede our work because there's no interruption in the service.
Writing the JAMS schedule is nice because we can use natural language in English. For example, we can specify days by writing "the first of March" or "the second of March". It's clear. Being able to specify the schedule in this way is good.
JAMS saves us time when it comes to troubleshooting stalled jobs because of the logging that it provides. It allows us to go to the execution history, look at the log, and find the problem. Even if the log is very large, it provides a path for us to follow and find what we need to look at. We can typically solve issues in an hour or less because of the logging.
The PowerShell integration is great. When there are things that we couldn't do out of the box, they have execution methods that we can use in PowerShell that make things more flexible for us.
The search capability needs to be improved because when we try to search for a job, it's hard to do. We have to know where it is. This is really the functionality that I think is lacking.
We have been using JAMS for approximately three years.
JAMS is a pretty stable solution that handles the resources very well.
This product is highly scalable.
We have two people on the administration side and another ten people who are working with it. They are using it as part of their support role with the helpdesk. We also have a developer that creates the jobs, which are then scheduled by JAMS.
We will probably increase our usage in the future. Right now, we're implementing the web client of JAMS. When we get to the point that we are fully using it, including the web component, then that may be the time for us to look into expanding our usage. At this point, we want to be able to maximize the use of JAMS, and so far, it seems that there's a lot to JAMS that we haven't really used yet.
I would rate the support very high.
First, the response time is very good. When we engage the support engineers, they always know what to provide us with so that we can figure out what's wrong. Whenever we need to go to meetings, it's always a learning experience. They're very smart.
JAMS did not replace other monitoring tools and it was able to solve the problem that we had.
I was not the person that initially set up JAMS. It's not complex but that person didn't follow the procedure fully. When I took over the implementation and setup, JAMS provided a checklist. It was good because I was able to follow each of the steps. From what I can tell, in the initial setup, we didn't follow it to a tee, and this caused some complexity on our end.
The deployment took about a year in total, although in a typical situation, I think that two weeks would be enough time to implement it. Depending on how much work needs to be done, it may take a month to complete.
In our team, we have a two-week scrum process and it would be quicker for us to do. Our security and infrastructure are also different than it is in the rest of the organization. For example, we can set up our own VM, database, and scheduler if they are not already set up.
JAMS provides a list of the best practices with regard to security.
We have two people in-house that are responsible for maintenance.
There are a lot of features in JAMS that we haven't used yet. For example, there is a special calendar and we haven't even tried to utilize it. However, we would like to eventually use it to its full potential.
In summary, this product is top class. I would like to commend all of the engineers and support team at JAMS, and I highly recommend it to others.
I would rate this solution a nine out of ten.
Hi JAMS customer – I wanted to follow-up on your review to let you know our development team is finalizing JAMS v7.5 which will include search capabilities. Be on the lookout for this update coming Fall 2022.