Configuration type AutoExecute

Configuration entries of type AutoExecute are used to configure functional modules of the censhare system, that are to be triggered automatically by rules. 

The following description applies to an average AutoExecute configuration dialog. Actual dialogs might vary.

Overview

Rules can be based on schedules, intervals, or events. Depending on its hardcoded functionality, an AutoExecute module will perform on assets or not. The module for rebuilding database indexes, for example, does not deal with assets at all. The module for the creation of previews of image assets, for example, performs on image assets.

Configuration

1. Standard header of all configuration entries with the internal name of the module, a description, and a comment field, that can be used to keep track of the changes.

2. ServerActions contain a general setup section to define the rules and restrictions of the manual triggering preconditions. The options are:

   • Server name: if empty, the AutoExecute module is made available to all Application Servers, otherwise it can be restricted to a specific server.

   • Enabled: this flag toggles the overall availability of the AutoExecute module.

   • Title and Description: These values can be overwritten. The title field determines the name, under which the AutoExecute module appears in internal system monitors and in the configuration list.

   • Version: this is a unique version number of the module. It is copied into the customized version, to ease the process of reviewing customization files after a system upgrade.

3. The Trigger events section determines under which condition the AutoExecute module comes to life, on which assets it will perform and how the execution will be performed internally. The options are:

   • Setup:

     • Work package size: if the AutoExecute module works on multiple assets, this parameter will break the operation into work packages that are executed sequentially, each package dealing with as many assets as defined as work package size. This is to limit the transaction size in the database on those modules that potentially deal with a large number of assets.

     • Parallel execution: this parameter determines whether multiple work packages can be executed at the same time.

     • Persistent events: persistent events will be fired only once and if they fail to complete they will cause an error and remain in the event task list with an error state. Non-persistent events will automatically be fired again if they fail, limited by the Retries on error parameter.

     • Process limit: this parameter defines, how many instances of that module are allowed to run at the same time (in threads, rather than work packages!).

     • Retries on error: defines the maximum of retries of failed non-persistent modules.

     • Local file system (implemented with censhare 4).

     • Ignore remote events: check this flag to restrict the execution of the AutoExecute module to events that were sent from the local ApplicationServer.

   • Trigger events:

     • Asset event: this trigger offers a broad selection of system-generated events (from a popup menu), which can be used to wake up the AutoExecute module. Some of the events are hierarchical to allow for very specific triggers. The workflow has changed event, for example, comes with submenus to narrow down the selection to specific workflows and workflow steps. If more than one asset event is defined, the events will be OR-connected, which means that any of the events will trigger the AutoExecute module.

     • Timer event: this event will continuously trigger the AutoExecute module in the given interval.

     • Cron event: this event allows to schedule the AutoExecute module at certain times and days, according to the

       For more information, see this cron pattern syntax.

     • Generic asset event: this event allows to trigger the AutoExecute module by custom events (and by doing so, optionally pass parameters to the module). This is a complex feature – please refer to a censhare project manager or an application engineer for further details.

   • Asset filters:

     The asset filters only apply to those AutoExecute modules, that perform on assets. While the Trigger events only control on which occasions the module will come to life, the asset filters will determine which assets the module will perform its tasks. It is important to understand that some of the triggering asset events will behave as pre-triggers. For example, a trigger that fires each time an asset is checked-in, will forward the asset that caused the event to the AutoExecute module. The entries in the Asset filter section will be applied afterwards and only on the one asset that was passed by the trigger. But if a timer or cron event was used to trigger the module, there will be no pre-selection of assets and the Asset filter will apply to the entire database. It is therefore essential to make a very careful filter selection, which passes only as many assets as really necessary to the AutoExecute module.

     Clicking in the Asset filter field produces the standard filter dialog, as known from the censhare Client.

4. If an AutoExecute module performs on assets, an Asset structure section might be shown with the following options:

   • Hierarchical: checking this option will expand a sub-dialog of arbitrary complexity. The idea here is to take the assets that were passed by the trigger and made it through the Asset filters and follow their children according to the chosen rules. Independency of the hardcoded functionality of the AutoExecute template, the same task might be performed on all matching asset children, but it is also possible that the children are subject to different behavior than the first level assets.

   • Modification mode: this allows to define whether the asset should be displayed as checked out during the operation.

   • Process user: in case, the asset is to be displayed as checked out during the operation, this parameter allows to display any user of the user list to appear as the checked out by users. It is recommended to create dedicated, invisible users for this purpose.

5. If a ServerAction performs on assets, an Asset update section is shown with the following options:

   • Update asset afterwards: this opens a dialog that allows modifying certain metadata, like workflow or domain, after the execution of the ServerAction. This feature is typically used to automatically change the status of an asset after executing the ServerAction on it.

   • Send new asset events: this allows to send custom-made system events depending on the outcome of the operation of the module (successfully finished, skipped, or failed). This feature is used to automize chains of events, where one module will trigger the next one.

6. The final section in each configuration dialog finally contains the individual parameters for the functional configuration of that specific ServerAction.