Using the ‘monitorFolder’ method

The Scripting Module now provides a mechanism to automatically execute an ExtendScript file when a specific ‘trigger’ file is dropped into a monitored folder.

Starting monitoring

The ‘monitorFolder’ method should be called on the EasyCatalog object to begin polling a specific folder – e.g.

Four folders are required for the monitoring process:

  1. An ‘in‘ folder, which will be monitored for a file to trigger the script.
  2. A ‘processing‘ folder: the file(s) currently being processed by the script will be moved here immediately prior to the script being executed.
  3. A ‘processed‘ folder: if the script executes successfully, the processed file(s) will be moved to this folder
  4. An ‘errors‘ folder: if the script does not execute successfully, the processed file(s) will be moved to this folder.

The first parameter is the path to the script that will be executed when a file is dropped into the ‘in‘ folder; the last parameter is a regular expression pattern that defines the type of file you’re watching for (in the example shown above, dropping a ‘.xml’ file into the ‘In’ folder will trigger the script ‘myscript.jsx’).

Triggering the script with multiple files

Inside of the ‘in’ folder, you can also drop a sub folder containing the ‘trigger’ file and any number of supporting files that the script may require to run.

Note, however, that the script will be triggered as soon as a file with a name matching the trigger pattern is dropped into the sub folder. For this reason, you would need to give the trigger file a unique file extension or pattern and ensure that it is dropped into the folder last.

For example, you may want to process three xml files in your script, so you could create a folder in the ‘in’ folder and drop in files called:

  1. File-1.xml
  2. File-2.xml
  3. File-3.xml

The trigger pattern (the final parameter for the ‘monitorFolder‘ method) would then be ‘.*-3\.xml’.

When the trigger file appears in the sub-folder, the entire sub-folder will be moved to the ‘processing‘ folder and the additional files (File-1.xml, File-2.xml in this case) will be passed in the ‘pSupportingFiles‘ array (see below).

The trigger script

The script file specified by the first parameter to the ‘monitorFolder‘ method will be called each time a file whose name matches the pattern specified by the last parameter is dropped into the ‘in‘ folder.

The script is passed a number of parameters so that it can determine where it is running from, which file triggered the script to be executed, etc:

  • pScriptFile: a file object that contains the script being executed
  • pDropFolder: a file object that specifies the ‘in’ folder
  • pProcessingFolder: a file object that specifies the ‘processing’ folder
  • pErrorsFolder: a file object that specifies the ‘errors’ folder
  • pTriggerFile: a file object that specifies the input file that triggered the script to be called
  • pSupportingFiles: an array of file objects that contains other (non-trigger) files that were in the same folder as the trigger file.

For example, in the trigger script, to synchornize a data source with the file that triggered the script to be called:


If the script fails to execute successfully, the file(s) will be moved to the errors folder specified by the monitorFolder call.  There will also be a file called ‘Error Ticket.xml‘ which contains:

  • An ‘error‘ node, which has a ‘message’ attribute containing the error message generated by executing the script.
  • An ‘arguments‘ node which shoes the files passed to the script
  • A ‘urldownloaderrors‘ node which contains details of any URL-based images that failed to download.  This node will only be populated if you have fields whose ‘location’ in Field Options is set to ‘URL‘ (not ‘URL(Live)‘).  It is possible that the script itself executed successfully but some of the images failed to download (in which case, the job will still be considered to be in error and moved to the errors folder).

The error folders created in the errors folder will be removed after a period of one week.

NOTE: Use of this function in a desktop environment may violate the end user license agreement for Adobe InDesign, and is provided for testing solutions that will ultimately be transferred to InDesign Server.  Please consult your EULA with Adobe for further information.