Multiple Monitors

As of 2.0.157.37, FolderMonitor has had the ability to run multiple instances which thereby allows one to achieve greater throughput, as jobs may be run simultaneously and make use of however many CPUs your server is configured with.

Each monitor instance watches its own set of folders for incoming jobs. As usual, the first folder, in the list of folders you configure a monitor to watch, gets the highest priority. All jobs in that folder must be completed before the monitor will look at the next folder in the list of folders that you configured it to watch. Note that if a job shows up in any higher priority folder than the one currently being processed then as soon as the current job is done, processing will revert back to doing the jobs now found in higher priority folders.

With multiple monitors, each monitor instance runs at the same priority, competing for system resources. Each monitor instance must be configured to watch its own set of folders, not overlapping with any other monitor's set of folders.

How does one get multiple monitors? Well ...

On Unix...

It's easy, just start up more FolderMonitor programs to run independently of each other in the background. Of course, each one you start must be given a parameter file (.prm) that is specific to the monitor's business intent. It would define which folders were of interest to that monitor, what job name discovery script to use, error file folder, processed file folder, ... – i.e. the usual.

On Windows...

One provides a DocOriginFolderMonitorSvc.prm file (in the usual .../User/Overrides folder) which simply lists the names you wish to give to the monitor instances that you want to have. E.g.

-monitor Payroll:Manual
-monitor AdHoc:Automatic
-monitor LongJobs:Manual

Pick any names you like (even with spaces, but do you really want them?). Use as many as you like.

The Automatic or Manual attribute determines whether or not these monitor instances will be started up automatically when the DocOriginFolderMonitorSVC service itself is started.

The DocOriginFolderMonitorConsole can be used to start/stop any monitor (as chosen from a dropdown list). Or to stop them all with one convenient GUI selection.

When directed to start a FolderMonitor instance, the service will launch the FolderMonitor app passing it a parameter file name such as DocOriginFolderMonitorAdHoc.prm -- for the AdHoc named monitor that you listed. It is your job to provide those .prm files, configured in the usual way for a FolderMonitor, i.e. defining which folders it is to watch, the job name discovery script to use, etc.

That's it. As easy as that. Pick some names for the monitor instances you want and provide their configuration details. Individual monitor start/stop control is easy with the DocOriginFolderMonitorConsole.

FM.ini

(As of 3.1.002.03)

Instead of maintaining several PRM files for many instances of FM, you can instead configure all of the options for all of your monitors in a single ".ini" file. That file must be deployed at $O/DocOriginFolderMonitor.ini. The existence of that file will mean that none of your FolderMonitor-related PRM files, if they exist, will have any effect. FM INI files use the _profile (Access Profile Files) functionality.

The INI file is required to have sections. The section names would be the names of the monitor instances that you would like to use. E.g. [AdHoc], [HiPri], [Payroll]. Those names could have blanks in them but that is probably a bad idea, especially if you intend to use a third-party INI editor to maintain your INI file. Within each of those sections, you specify the options that you want to apply to that FolderMonitor instance. E.g. scriptFolder=$O. Notice the lack of a leading dash and the need to use an = sign. Otherwise, it is the same set of option specifications that you would have made in a PRM file.

You can start out your INI file with a section named [COMMON] . In that section, you can specify default options that you wish to apply to all the FolderMonitor instances. You can, if you like, repeat an option under an individual FolderMonitor instance section, so as to override the option setting you placed under [COMMON]. The INI file also supports a [DEFINE] section, see _profile (Access Profile Files).

In options queuen, ErrorFolder, and ProcessedFolder  you can use the %i placeholder, which gets substituted with the applicable FolderMonitor instance name. For example, entries such as:

queue1=$U/FolderMonitor/%i/Jobs/*.*
ProcessedFolder=$U/FolderMonitor/%i/ProcessedJobs
ErrorFolder=$U/FolderMonitor/%i/FailedJobs

can be used in the [COMMON] section if you have standardized on your folder naming conventions across your various FolderMonitor instances.

You may include other custom sections with your own option settings. These will be ignored by built-in FolderMonitor processing but may be advantageous to you if, as part of your processing, you used the various _profile functions to load the INI file and grab your user options from it.

How does FolderMonitor know which sections are FolderMonitor instance sections versus custom user sections? Every FolderMonitor instance section, to be recognized as such, must have a MonitorStart=Automatic/Manual entry. Yes, that's right, the INI file replaces the DocOriginFolderMonitorSvc.prm as well. The service will detect the INI file and determine which instances exist and whether to start them automatically or not.

Even FolderMonitor instance sections can have unknown-to-FolderMonitor user options in them. They will be ignored. Of course, in doing that you run a risk that DocOrigin might invent an option name that matches one that you have used. Beware.

Both a leading ; or * comment out a line. A third party 'INI Editor' may have stricter rules.

FMTransaction

A DocOriginFolderMonitor instance doesn't actually process a job itself. It invokes an FMTransaction helper app to process one job, then exit. It is that helper app that actually invokes the nominated job name discovery script and deduced job processing script, which in turn probably invokes DocOrigin Merge and may invoke filters as well.

The reason for using a spawned helper app is that it keeps the long-running DocOriginFolderMonitor instance immune from the effects of [user] code that leaves file handles open or that leaks memory. Such things are cleaned up by the OS when the helper app exits after doing one job.