Assignment policies are sets of rules that DFC-based applications apply to determine the correct file store or retention store for each new content file added to the repository. Assignment policies require a Content Storage Services (CSS) license. Any client application built on DFC applies assignment policies automatically if CSS is enabled in the repository.
Assignment policies can only be applied to the SysObject type and its subtypes, and are represented in the repository by persistent objects. A particular object type can have only one associated assignment policy. When a new content file is added to the repository, the assignment policy engine determines whether the object type of the file has an active associated assignment policy. If there is no active assignment policy for the type, the assignment policy engine determines whether the supertype of the object has an active associated assignment policy. If there is an active assignment policy for the file type or a supertype, the system applies the policy and stores the file accordingly. If no policy is found or if none of the rules match in an applicable policy, the system uses the default algorithm to determine the correct storage area. If none of the rules match in the applicable assignment policy, the policy engine does not further search the type hierarchy.
Assignment policies consist of rules that define the criteria for storing content files in the correct storage area. There are two types of rules:
Standard rules
Standard rules determine storage area based only on the object format and content size. Standard rules can have one to five criteria.
Custom rules
Custom rules can be based on the values of any standard or custom SysObject property, provided those values are present before an object is saved. There are no restrictions on the number of conditions in a custom rule. The properties and values are specified using methods, such as getString(), getInt(), or getRepeatingString(). Custom rules follow the Java syntax for any conditional statements in the rule. For custom rule examples, refer to Custom assignment policy rule examples.
There is no syntactical difference between the two types of rules. During rule validation, a standard rule is translated into the same syntax used for custom rules.
Assignment policies are applied only to new content files, whether they are primary content files or renditions. An assignment policy’s rules are applied in the order in which they are listed within a policy. If a rule is met, the remaining rules are ignored. To match a rule, all conditions in the rule must be satisfied. An assignment policy is applied when
A content file is first saved or imported into the repository.
A new version of a document is created, because versioning creates a new content file.
A document is checked out and checked in and a new version results, the policy is applied to the new version of the content file.
An existing document is modified and saved as the same version of the document.
Assignment policies are not applied or enforced under the following conditions:
An application sets the a_storage_type SysObject property.
If a_storage_type is set by an application, assignment policies do not execute for any of the primary content pages (content added using a Setfile). Documentum client applications do not generally set this property.
The application specifies the storage location for a secondary rendition during an addrendition call.
If a storage location is already provided, the policy engine does not execute the policy for this particular secondary rendition.
Assignment policies are not enabled.
The properties of an existing documents are modified and saved the changes without checking out and versioning the document. The content is saved into its current storage location.
The DFC policy engine is turned off.
Assignment policies are enabled but a policy does not exist for an object type or for any of the types supertypes.
A document does not satisfy any of the conditions in the applicable policy.
The content is replicated (content associated with a replica object).
The content is loaded into a repository with dump and load.
The content generated by a refresh API.
If the assignment policy engine encounters an error in a rule at runtime (for example, if a property name is invalid), the assignment policy engine returns an error and the save operation on the document or object fails. This behavior can be overridden by setting the DFC client-preference flag in the dfc.properties file on the application server host where Webtop or Documentum Administrator is installed:
dfc.storagepolicy.ignore.rule.errors=true
If this flag is set to true, the assignment policy engine ignores the faulty rule and attempts to apply the next rule in the policy.