On this Page

    FolderMonitor

    FolderMonitor is an application for processing "submitted" data files. FolderMonitor runs as a background task on a server. The system administrator will have had to make decisions on where collateral, e.g. form files will be deployed on the server, where scripts are kept, and where data files are to be submitted for processing. User applications write data files into a specific file folder(s) that are monitored by FolderMonitor. When files appear in these folders, FolderMonitor will process one file at a time; determine what processing is required on it, and execute a nominated-by-you JavaScript script to do the processing.

    FM on Windows...

    There is a FolderMonitor Service (DocOriginFolderMonitorSvc) that runs as a Windows Service. Typically it is set to start automatically on reboot.

    There is also a GUI program — DocOriginFolderMonitorConsole — that allows a system administrator to start, stop, and look at the log of a FolderMonitor process.

    When the system administrator uses the FolderMonitorConsole app to start FolderMonitor processing, the service launches the actual DocOriginFolderMonitor application as a background app. It is that app that watches the folders it is configured to watch, for any submitted data files to process.

    On Windows, one can configure FolderMonitor to use multiple monitor instances. See Multiple Monitors and -monitor. When that is done, the FolderMonitorConsole app allows you to start an individual monitor instance (or all at once, if desired).

    FM on Unix...

    There is no DocOriginFolderMonitor Service, nor any DocOriginFolderMonitorConsole.

    The system administrator runs the DocOriginFolderMonitor process directly via the command line. Undoubtedly they will end that command line with an ampersand (&) so that the app will continue to run in the background as they continue to use the system console for other duties. Something like:

    {path to DocOrigin folder}/DocOrigin/DO/Bin/DO DocOriginFolderMonitor -monitor "{instance or monitor name}" &

    The instance or monitor name can refer to a section of an INI file, see FM.ini on the Multiple Monitors page. Of course, the command would also specify any needed options, almost certainly via an @xxxxx.prm command line reference.

    A convenience starter shell script named 'fm', is provided in the .../DO/Bin directory. It is just a script, copy and edit it as you see fit. It enables one to say: fm start, fm stop, and several other actions that may be of interest. Do examine the script and tailor it to your needs. It is not intended to be a see-all/do-all interface for any site, but an example of what you can do. You will likely want to adjust it to reflect the queues/folders that you use. On re-install, we will overwrite 'fm', so copy it and make it your own.

    Note that multiple instances of the FolderMonitor process can be run in the background. They operate independently. To get FolderMonitor's pid:

    ps -ef | grep "DocOriginFolderMonitor"

    You stop a FolderMonitor process on Linux the same way as you would stop any background job on Linux, by using the kill command:

    kill -s TERM {pid}

    kill does not abort the job that is being processed. The default signal sent by the kill command is SIGTERM. FolderMonitor catches SIGTERM. The signal handler just sets a flag and continues. Because we catch the signal, it is not propagated to FMTransaction, which is the child process that actually processes a job. If the flag is set when we finish processing a job, or when we have finished a scan for new jobs, we do the usual shutdown, reporting quarantined files etc. But any job being processed when the kill signal was received is safely done.

    We don't believe that the DocOrigin product should take over your site. Rather it should fit into what you already do. That is why we provide fm as only an example for you to revise, or even discard. We do not want to impose constraints on how you do your work. Nor do we want to provide a system with so many configurable options that you need another system to configure those options! We believe that we should keep it open, and keep it simple. For any individual site, the specific operations needed should be easy to accomplish -- and understand.