Common actions

The Convert action library "Common" actions control the operation of subsequent Convert actions. For example, when performing an action that converts a multi-page document to a set of single page TIF documents, the newly created TIF images have new names that are generated at runtime. By first calling the action Micropattern prior to calling a conversion action such as PDFFREDocumentToImage, or SplitMultipageTiff, the naming convention can be adjusted. All of the common actions will adjust how the conversion actions work when they call called prior to other convert actions. All of the common actions work in a similar manner to control subsequent conversion actions.

This action can be called from any level and subsequent Convert library actions will use this setting. Subsequent actions can be on different rules or rulesets, but must be within the same task profile. Typically the common actions are called once per batch, for example on a batch open event within the DCO hierarchy. Convert actions that create new files from documents are typically called on the page or document node for the file to convert. This allows the common configuration action to be called once and then the conversion action can be called for each target file. It is allowed to call the common action on the same rule as a conversion action. If the common action called with the same value each time then it is redundant because the setting is already set. For greatest efficiency, set the common actions on a batch open event for the ruleset.

When a conversion of a document fails it may be desired to continue processing files in the batch or perhaps the batch should be stopped so the conversion problem can be reviewed and corrected prior to continuing. The common conversion actions provide a set of actions that control the behavior when document cannot be converted. The actions are: ExceptionSetHandler, ExceptionSetFileTypes, ExceptionSetVariableName, and ExceptionTaskCondition. Using these actions, the application designer can decide how the application should handle these failures. Processing can be continue, processing logic can respond and take action on a failure or the batch can be set to an abort state to allow the batch to be reviewed. When using Rulerunner to process batches, Rulerunner has a configuration setting that will stop processing subsequent batches if an abort condition is raised or will still continue processing waiting batches. When an application is configured to abort when a conversion fails, also confirm that the Rulerunner configurations are set to respond as desired to an abort condition.

Smart Parameters

Parameters that use an "@" notation, such as "@X.xxxx", "@P.xxxx", "@STRING()", "@PILOT()", etc., are known as "smart parameters". The data passed as a parameter to an action is evaluated at runtime. For example, "@X" is notation for accessing the current object. "@P" accesses the page object, which could be the current object, or a parent object. Being evaluated at runtime, allows recognized data or other batch specific data to be passed to actions or stored as metadata. A smart parameter such as @DATE could be used to name export files based on the current date. Similar smart parameters retrieve the current batch ID, current batch directory, current operator ID, and more. Smart parameters are a very powerful mechanism of getting data from other areas of the application and copying it into a new location or passing it as a parameter to an action. It is recommended that the smart parameter documentation is reviewed to understand the full capabilities available. The top-level help of the ValidationAndTextAdjustments action library also has information about smart parameters. Some characters such as +, \ and . also have special smart parameter meaning and may be interpreted as a smart parameter. This can be controlled using smart parameter syntax.