JAMS

Extremely few instances of crashes and bugs.

We mostly use JAMS for a smaller department and haven't had the chance to try to expand it yet

I can't give it a higher score because there have been many times that teammates have abandoned scripts because Jams wouldn't take what they were testing and gave no clear reason why.

Have not had any issues with scalability since having the application. It's easy to add more agents.

The product is quite flexible. There are a number of features and functions that we use on a daily basis, and there are many features that are available that we have not yet needed or explored (like setting up jobs with the ability to do FTP or Sftp file transfers).

It is scalable to have agents and more users but the script running on agents lacks all functionality as running the script on the main server.

By installing Agents on servers throughout the organizations, you can run a DB Script on a DB Server, move files around the network and kick off jobs on servers in different parts of the organization: JAMS Runs on its own server, isolated from others. Through an agent on a Processing Server (work Server) files can be picked up, processed and moved to a destination server to be processed into another application on another server. You don't need an agent if you are just moving files around, you need an agent if you want to run a process or API Call on the destination server.

Again, we're a small firm, but can afford JAMS and get tools that are often targeted (and priced) for significantly larger organizations.

I think its a well architected solution. The ability to spread workload across multiple agents really helps manage any number of jobs. Being able to concurrently run multiple from different agents is key.

Between PowerShell scripting (our primary language used), VBS, SQL connectivity and functionality, Command Line execution, SFTP functionality, encryption via PowerShell modules, etc. JAMS allows us to scale our usage of the software to levels that were initially not foreseen. It's great to have a toolset that allows us to be able to automate tasks that weren't realized before using the software.

Deploying JAMS is a testament to our commitment to excellence in modernisation our software system and our ability to adapt to changing circumstances. It’s crucial to recognise the hard work of every team member who has contributed to the success of implementing a new job batch processor.

From an end-user perspective, very flexible and effective, easy to use.

We have had trouble scaling up as JAMS has limited scalability without increasing your JAMS instances.

Overall, very good. However, its rigidness in folder structure can make it inconvenient to organically expand job list.

We have the client in a central location and deploy agents that connect back wherever they are required. Meaning it can be managed and configured from one location.
We can run any number of Jobs on each agent as required there is no minimum per agent, so no wasted jobs on a quiet agent

Based on our use cases the application and services have the potential to scale well; but from our deployment the need to be more scaled or highly available has not been required.

I don't have enough information to go on, but for the things we have been testing, I have not come across any road blocks.

Its really easy to deploy agents to additional endpoints.

I can only speak in in regards to scalability in the volume of jobs we have created. Many of our jobs exist in multiple environments, with each environment having its own unique folder names, connection strings, etc. We incorporate parameters on the folder level that contain the unique environment information. The jobs reference these values from the folder they are contained in, so we can easily copy a job from DEV to TEST and the source is the same but the values passed from the parameters are not. This makes it very easy to create many new jobs and copy them across multiple environments and have them work.