Our primary use case is for file automation: detecting the presence of files, moving files from one system to another, doing FTP uploads, FTP downloads, and a large number of custom execution methods. Custom execution methods are a way to create your own code that extends the JAMS toolset.
For example, in one of our systems, it has a tool that needs to be run in order to import a file into that system, which is very proprietary. However, those file import definitions are dynamic inside of the system; you could have 100 different file formats. We created a custom file import/export method for our system. The JAMS job calls the other system's API. The JAMS job definition tells it the path of the file to load and what parameters to use. It then reads and displays the remote system's API return results. Custom execution methods are the meat and potatoes of what we use JAMS for.
We have a single production JAMS server that serves as the primary JAMS node where most of our work is done. We have an agent server where the primary node issues some job commands to run on that agent. Then, we have a test JAMS server which we use when we are testing execution methods and other things. We have plans to stand up a failover server, but have not done so. The back-end database for our JAMS production system is Microsoft SQL Standard Edition and all our servers are on Windows.