A workflow is a set of rules (grouped by workflow event) to be executed sequentially for every given job being processed. A workflow can be assigned to be executed on multiple seeds, which means that all seeds that have the same workflow assigned will share all its rules.
A workflow rule is any application or script to be executed as part of the workflow. They can be used to process the content or control the flow of the jobs received in the workflow.
Type | Description |
---|---|
Application | Rules that reference an Aspire application contain the maven coordinates of the application and the properties to configure it. |
Template | Rules created from a workflow template contain the ID of the template and the properties to configure it. The type of these rules matches the one from the referenced template (Custom, Application, etc.) |
Custom | A custom groovy script rule contains the script to execute. |
Folder | A type of template created to contain references to other rules. |
Templates are predefined workflow rules. In general, groovy scripts are used for common job operations like adding or copying fields. The templates can be used by creating a rule that references it and including the required properties.
Name | Description |
---|---|
add-static-acl | Adds the configured ACL to the ACLs list of all jobs. |
add-static-group | Adds the configured group to the groups list of all jobs. |
override-with-public-acl | Overrides the ACLs of a job with a single PUBLIC:ALL ACL. |
override-acl | Overrides the ACLs of a job with the ACL provided. |
override-acl-domain | Overrides the domain of all the ACLs with the provided domain. |
dump-document | Logs the content of the job with the configured log severity level. |
log | Logs the specified message with the configured log severity level. |
exception | Throws an exception with the configured message. This will cause the job to fail. |
exception-conditional | Throws an exception with the configured message if the specified job field matches the configured value. This will cause the job to fail. |
terminate | Terminates the job if the specified job field matches the configured value. This ceases the processing of the job. |
terminate-conditional | Terminates the job. This ceases the processing of the job. |
terminate-by-file-extension | Terminates the job based on the extension of the URL field. This ceases the processing of the job. |
terminate-by-file-size | Terminates the job based on the value of the dataSize field. This ceases the processing of the job. |
terminate-by-file-name | Terminates the job based on the names of the URL field. This ceases the processing of the job. |
field-copy | Copies the value of the source field to a target field. This does not override a previous existing target field, it creates a new one with the same name. |
field-fallback-copy | Copies the value of the source field to a target field only if the target field does not exist. |
field-default | Creates the configured field with the specified value if it does not exist. |
field-set | Overrides the configured field with the specified value, the field is created if it does not exist. |
boolean | Checks if a field matches a specific value. The execution of job will continue to the condition it matches. |
field-equals | Checks if a field matches another. The execution of job will continue to the condition it matches. |
field-isEmpty | Checks if a field value is empty or null, or if it does not exist. The execution of job will continue to the condition it matches. |
switch | Executes a switch statement on the specified field. The execution of job will continue to the condition it matches. |
switch-custom | Executes a switch statement on the specified field. The execution of job will continue to the condition it matches. |
A virtual set of rules to be executed sequentially that lives inside a workflow object, there are 7 different events possible, each event is triggered upon different stages within the lifespan of a document:
Each event is composed of a set of items. Each item defines an action to execute in the event, and in some cases they can contain nested event items. There are three types of event items:
These items are references to rules that will be executed in the event, each reference contains the ID of the rule to execute. References to rules of type “Folder” can contain nested references or exit items.
The exit items are used to finish the execution of the event at a specific point. Any job processed by this item will exit the workflow event, but it does not mean that the job will be terminated. The processing of the job will be continued by the next stage, pipeline, or event.
Conditions are items used to control the flow of a job. If a job matches the condition statement, the job will be processed by the items contained by the condition, if not, it will continue to the next item in the workflow. Conditions items are always nested to references of rules of type “Choice”, and they can contain other references and exit items. All condition items are associated to the template “Condition”.