Processing the Job

Once the job name has been established, a job processing script (JPS) is called to process the job. A file called jobName.wjs is expected to be available in the "scriptFolder" (the -scriptFolder command line option). Like all script files, any job processing script must be saved in UTF-8. This script is run to process the data file. If the script is not found, an attempt is made to run a script called Default-JobProcessing.wjs as found in the DO/Bin folder of the installation location. If this does not exist an error is triggered.

The processing script is JavaScript that can use all the standard DocOrigin extensions. See Scripting for details. In addition, the script has available to it the _job (Current Job and Command Line Parameters) object with the job name and data file name set. Your script can use these to read the file.

Also, the JND script (or a DocOrigin PI) can set properties in _job.options. These properties are available to your JPS to use as it sees fit. Note though that these _job.options properties are NOT passed through to Merge. Your form's script does not have access to _job.options properties. If you wish to transfer info to Merge you should use the -cache command line option.

Sample Processing Script:

var args    = {};                                       // place to house Merge args
args.form   = "$R/DO/Samples/" + _job.name + ".xatw";   // our default design file name
args.data   = _job.datafile;                            // the data file we were given
args.output = "$U/Output/"  + _job.name + ".pdf";       // chosen default output location

##include "$O/JobProcessing.wjs"

var rc = _merge(args);                 					// run Merge

return rc;

The above example uses, by site convention, whatever job name is passed to it, as the name of the form file (.xatw). The form file is expected to be in the samples folder such that the delivered samples work out-of-the-box, but surely you will override that.

By defining your own override JobProcessing.wjs file you can override the parameters that are setup by default to be passed to _merge(). In fact, you could ignore these parameters altogether, not even call _merge(), and return before the default call to _merge() is executed. You have complete control; this is just a stub.

It runs DocOrigin Merge to create a PDF file of the same name. Merge's return code is returned to FolderMonitor. If a non-zero return code came from Merge, FolderMonitor will log this as an error in the ErrorFolder.

Note that all of this is for default processing. If you have defined a jobName.wjs file, then these default processing steps won't be used at all. Rather it will execute the jobName.wjs file that you defined.

Once processing has completed, the file is removed from the active Queue. If the processing resulted in an error return from the processing script, (a JavaScript return(n) where n is non-zero), or an error occurs in the opening or compiling of the script, the job data file is moved to the Error folder specified by the command line -errorFolder setting. Along with the original data file, there will be a .log file created with the same base filename. It contains the last few lines of FolderMonitor's logfile. This file can be examined to quickly determine the source of the failure.

We recommend that a client's JavaScript program uses a positive integer between 200 and 250. That way you will always be able to tell whether the error was detected by your own JavaScript or by a DocOrigin program.

If the processing runs successfully, the script should return a value of 0 (zero). The job is then deleted from the Queue. If the optional -processedFolder option has been specified on the command line, or more likely, in the DocOriginFolderMonitor.prm file, a copy of the processed data file will be written to that folder.