Hyland Connect

resplin · ‎06-05-2015

The official documentation is at: http://docs.alfresco.com

Actions Content Modeling Action Service Java_API

Actions

An action represents a parameterized unit of work that can be applied to a node.

Using the action service, actions of specific types can be created. The type of an action indicates the action implementation that will be used when the action is executed and information about how the action can be parameterized.

Parameter values can be set on an action. Some actions may have mandatory parameters. These must be set prior to execution.

Details of the parameter types, names and optionality can be found on the action definition for the action type. These are available via the action service API.

The action service can be used to execute an action against a node, called the actioned upon node.

Action Conditions

An action can optionally have a number of conditions.

An action condition is used to indicate whether an action can be executed. They are created in a similar manner to actions and can also be parameterized.

The action service can be used to directly evaluate the current state of a condition against a specific node.

When executing an action, the default behaviour is to check the conditions before attempting to execute the action. If the conditions fail, the action will not be executed.

Evaluation of the conditions can optionally be surpressed when calling the action service.

If no conditions are specified the action will always be executed.

Multiple conditions are combined using the logical operator AND.

The logical operator NOT can be applied to the result of an condition by setting the attribute 'invert' on a condition.

Composite Actions

Saving Actions

Actionable Aspect

If a node has actions or rules stored against it then the actionable aspect is applied to that node. Saving an action or rule via the service layer will trigger the automatic addition of this aspect.

The actionable aspect has a single child association that points to a folder of type ActionFolder which extends SystemFolder. There is behaviour in the server that automatically creates this folder when the actionable aspect is added to the node.

The ActionFolder type has two associations, one to the stored actions and the other to the stored rules. The association to the rules is ordered, thus providing the execution order of the rules for that node.

Default Actionable Aspects

Classifiable

Select Classifiable as an aspect to enable categories to be assigned to a content item.

Complianceable

This aspect is no longer valid.

Dublin Core

Select Dublin Core as an aspect if you want to add the following properties to the Document Details for a content item:

Publisher
Contributor
Type
Identifier
Source
Coverage
Rights
Subject

Effectivity

Select Effectivity as an aspect to add the following properties to the Document Details for a content item:

Effective From
Effective To

Emailed

Select Emailed as an aspect to add an Email Data section to the Document Details for a content item. It includes the following properties:

Originator
Addressee
Addressees
Sent Date
Subject

Summarizable

Select Summarizable as an aspect if you want to add a Summary property to the Document Details for a content item.

Templatable

This aspect is no longer valid.

Versionable

Select Versionable as an aspect to version a content item each time it is edited (checked out and checked back in or updated).

Action Failure Handling

If an action is being executed synchronously then the exception that causes the action failure is raised up through the action service. This will cause the calling transaction be rolled back and all changes, including those made before the action lost.

If an action is being executed asynchronously then it is running in its own transaction so its failure will not effect an other transactions completing.

If an action has a compensating action specified, then this may be queued for execution when failure occures in an attempt to compensate for the failure. Compensating actions are only queued for execution when asyncronous actions fail.

The conditions on a compensating action are never evaluated and they are always executed asynchronously.

Action Execution History

The action execution history provides a log of the actions executed against a node, their current execution status and the outcome.

Actions can be optionaly placed in the execution history. This is indicated by setting the AddToExecutionHistory flag on the action object. By default this flag will be set to true for rules (i.e. automated rules) and false for manually executed rules.

If a node has a action execution history the ActionExecutionHistory aspect is applied to the node. This has associations to nodes of type ActionExecutionDetails which has a reference to the action being executed, the type of action (rule, action, ...), an indication of the current execution status (pending, running, complete, failed), any error messages raised during the rule execution (if it failed) and details of the execution time.

Asynchronous Action Execution

In order to execute an action asynchronously the ExecuteAsynchronously attribute on the action should be set to true.

When executing an action via the action service, actions marked for asynchronous execution are delegated to the AsynchorousActionExecutor implementation that is injected into the action service.