Custom Scripting

Custom scripting is a feature that provides a great deal of flexible control over how a job operates.  Much of the script code is generated by the server, based on the job's configuration.  A number of variables are pre-defined for you, including the idp object and an idpdoc object for the current document.  You can see these defined in comments in the initialize section at the top of the script.

There are multiple sections of the script, each executed at different times as the job is processed.

•initialize runs when the job first begins, with each document that arrives in the inbound source or when the user chooses to rerun the job.
 

•fields assign variables to each field defined in the job.  These variables can be used by custom fields code or in either of the following sections.  Note that you can change a field value in memory by simply manipulating its field.name$ variable, to store a value permanently, use the doc'putfield() method.
 

•identification performs archive data assignments, generally with expressions to assign doc'property values.
 

•finalize performs any final code required by the job, such as final validations or calculations required.

There are also two additional sections processed when a document is transferred out to the archive library and post-processing is performed.

•preupload runs just before the transfer is attempted.  Note this will not run if there are any failed validations on fields.  If there is a need to perform any further final validation, the custom code can set the variable errmsg$ to a value, and the transfer will not be performed, and the user will see the error message.
 

•postupload runs after the transfer has been performed.  This is where post-processing logic is executed.

Each of these sections has some code generated by the job design, particularly noticeable in the fields and identification routines, along with custom sections where user-defined script code can be entered.  When the job runs, each standard routine runs, including its custom code.

In the custom code section, you can enter any valid UnForm scripting code, which is based on the PxPlus Basic language.  The code is identical to that used to program code blocks, except that block if statements are not restricted from using curly braces (see Block If, below).

Scripting makes heavy use of objects, as several are exposed automatically while the script runs, used by the auto-generated code and available for custom code.  The following objects are available in all sections of script code:

•idp to manage the inbound libraries and contents

•doc to manage a single document, which is an instance of the idpdoc object

•lookups to run lookup code

•validation to run validation code (validations is an alias for validations)

•compare for detection code to compare values

Reserved Variables

The following variables can be used for special purposes in scripting:

•jobname$ contains the name of the job that has been detected, or preassigned.
 

•doclist$ contains a line-feed delimited list of documents to be processed, where each line contains tab-separated source ID, doctype, and docid.
 

•srcid$, doctype$, docid$ contain the current document being processed, and should be treated as read-only
 

•errmsg$ can be set to a message in preupload code, to prevent the upload from proceeding.
 

•targetlib is a library object of the library the image has been transferred to, available in the postupload code.
 

•subid$ contains the subid of the newly transferred image file, available in postupload code.
 

•xmlsubid$ contains the subid of the newly created and transferred xml data file, available in postupload code.

Block If

This is valid in custom scripting:

if a=b then {

 # code if a=b

} else {

# code if a<>b

}

This is valid in both custom scripting and code blocks:

if a=b then

 # code if a=b

else

# code if a<>b

end if