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. For example, in the screenshot below, you see all the param.name$ variables are created automatically. Each script section, however, offers a custom code section where you can enter script code to perform further processing that the job design doesn't provide internally.
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:
| • | inbound to manage the inbound libraries and contents |
| • | doc to manage a single document, which is an instance of the inbounddoc object |
| • | filter to run filter code (filters is an alias for filter) |
| • | lookups to run lookup code |
| • | validation to run validation code (validations is an alias for validations) |
| • | compare for detection code to compare values |
Also used if the job utilizes grid zones or fields:
| • | grid to manage grid zone data |
There are several sections, each executed at specific times during processing, and each offering a custom section to add code to:
| • | initialize is run as each document is loaded into memory. This code should be used to create additional objects beyond those automatically provided as the Preset objects listed in the comment area. |
| • | zones is run to capture zone data into variables, ahead of detection logic or other assignment logic. |
| • | detect is run whenever auto-detection is specified for the job process. Its purpose is to set a variable "pass" to 1 (true) or 0 (false), to determine if this job should be applied to the document. If you wish to set a job name for later images in a job batch process, after a job has been detected, you can set selectjob$=jobname$. |
| • | fields is run to assign values to custom data fields. Validations are also run here. |
| • | identification is run to assign values to identification fields. Validations are also run here. |
| • | finalize is run after the document has been processed. This code should clean up any objects or settings created in the initialize code. |
| • | preupload is run before a document is transferred to an archive library. It is possible to cancel the transfer by setting the variable errmsg$ to a message. |
| • | postupload is run after a document has been transferred. A message can be provided to the user by setting errmsg$ to a value, though unlike preupload, this does not cancel the transfer. |
Reserved Variables
The following variables can be used for special purposes in scripting:
| • | selectjob$ to set the job name to a known value. This can be used in custom detection logic to fix a job name once detected for a batch, such as during header/attach logic where you want the first job detected to be the job used throughout the batch. |
| • | 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, or just doctype and docid. This list can be manipulated by script code if necessary. For example, if a document is split, the new documents can be added to doclist$ for processing during the current batch. Be sure to separate lines with linefeed ($0a$ or chr(10)) characters. To avoid endless loops, be careful to avoid setting this variable to a static value. |
| • | 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