|
•
|
A Value Trigger runs Actions whenever a value change in the database meets the criteria set in the rule. For example, a user changes a Data Field value from No to OK using a pop-up menu and submits the change from a browser. After updating the database with the new information, Xinet will check the configured Trigger Sets to see if any are set to occur when the field value changes to OK or when the value changes from No. The change to that field is what will cause the Trigger Rules (if any qualify) to run their Actions.
|
|
•
|
A Date Trigger runs Actions when a certain time-based condition is met. For example, if a field named Due Date is set to 9:30, and there is a Date Trigger configured to run Actions when the time reaches one hour before the time in Due Date, then at 8:30 this trigger will run its Actions.
|
|
•
|
A File Event Trigger runs Actions upon changes to the file system which effect a file’s history. You can have the Xinet database tie any of the following file-system changes within the Active Path to fire a Trigger:
|
Aggregated Upload: For a batch upload of multiple files, triggers a single action (rather than an action for every item)
New File : A file previously unknown to the database arrives inside the
Active Path
Delete: A file is deleted from within the
Active Path
Download High Res : A high-resolution image is downloaded from the
Active Path through Xinet
Download FP0: An FPO is downloaded from an
Active Path through Xinet
Upload : A user uploads a file to an
Active Path on the Xinet server. If set up, this may also trigger a
New File event.
Image Order : A user uses the Xinet
Custom Image Order CGI on a file in the
Active Path
Move Into : A user moves a file into a folder within an
Active Path from a place in the file system that is not within that
Active Path
Image Replacement : An image has been OPI-replaced in a print queue (including PDF/IR queues). Useful for accounting purposes when interested in tracking asset use, such as downloads, copies, and writes. That list now includes
Image Replacement.
Portal Trigger: The
portalDI setevent Action or the
venturelog(8)
-portaltrig flag has been invoked. Allows developers to program custom Triggers that do not require a metadata Field change.
|
•
|
An Annotation Event Trigger runs Actions upon changes to Annotations, including:
|
New Annotation: A Xinet Portal user adds an Annotation to a Xinet file preview.
Edit Annotation : A Xinet Portal user edits an Annotation in a Xinet file preview.
New Rectangle : A Xinet Portal user adds a Rectangle Annotation to a file
Annotation preview.
New Sketch : A Xinet Portal user adds a new Annotation using the Sketch
Annotation tool.
New Stamp : A Xinet Portal user adds a new Stamp Annotation to a file
Annotation preview
Edit Rectangle: A Xinet Portal user edits an existing Rectangle Annotation.
Annotation
Edit Sketch: A Xinet Portal user edits an existing Sketch Annotation.
Annotation
Edit Stamp : A Xinet Portal user edits an existing Stamp Annotation.
Annotation
Each type of trigger is useful in different scenarios. If you require immediate feedback about a change in the database, such as Approval Status, then a
Value Trigger Rule is best for monitoring that change. If you want to have things occur at a certain time, such as
90 minutes before the file is due at the press, send it via FTP, then a
Date Trigger Rule will be appropriate. If you want a change within the file system to initiate some further
Action, for example, a Xinet user uploads a file, then a
File Event Trigger is appropriate.
File Events either occur or they don’t. You don’t need to narrow down their trigger points. When the
Event occurs, Xinet will run the associated
Actions. For
Date and V
alue Triggers, however, you must set some conditions. Once established, the database will verify that the conditions in the rule are met. If they are, then the associated
Actions will run following the sequence as established by and listed in the GUI.
No matter how it is triggered, after each Action finishes, it will return information about whether it ran successfully. When the
Action finishes successfully, Xinet will execute the next
Action in the
Trigger Rule. The administrator must specify, when configuring
Triggers and
Actions, what Xinet should do should an
Action fail. The
Xinet ADMINISTRATION view presents four possibilities:
If the administrator chooses Continue for the
Rule, the next
Action (if any) will execute regardless of the success of the previous
Action. If the administrator chooses
Exit or
Exit and Notify, the
Trigger Set will not run any further
Actions. Exit and Notify will also send e-mail using the
On Failure email settings for the
Trigger Set.
