You can use EMC Centera as the fixed content system in support of a fixed storage area.
See the Create a Fixed Content Device Wizard to create the fixed content device containing the configuration parameters for the Centera fixed content device system.
Refer to EMC Centera documentation for full information.
Configure Content Engine to support Centera delete methods using the Configuration tab of the file storage area property sheet. See View and modify storage area properties to open this property sheet. The settings there map to the Centera delete methods as follows:
File store configuration | Centera delete methods |
---|---|
If Allows Delete is not selected | Delete request fails. |
If Allows Delete is selected, the following options: | |
Non-recoverable |
C-clip is deleted. Centera shreds BLObs. |
Destructive |
Same as Non-recoverable. |
Purge |
C-clip is deleted. If Centera settings allow it, BLObs are purged. |
The key components of the Centera content model are named the Content BLOb and the C-clip, as seen below.
A Content BLOb, or BLOb, is equivalent to a Content Engine content element; it represents one unit of addressable content. A BLOb is irreducible in the Centera API; there is no concept of sub-structure within a BLOb. A BLOb consists of a series of data bytes understood by applications, but not by Centera.
A C-clip, or clip, is very roughly equivalent to a Content Engine document; it represents a related set of Content BLObs. A clip has a name and a set of tags. The tags contain attributes and references to BLObs; each tag has a set of attributes and a reference to one BLOb.
BLObs and clips are both storable within the Centera repository, and both are addressable within the repository. Clips hold references to BLObs, and consumers of the Centera system, such as Content Engine, hold references to clips (not to specific BLObs).
BLObs and clips are immutable within a Centera system; once committed to the system, they cannot be altered but can be deleted. A clip can be opened, the tags can be changed, and the clip can be rewritten, but the clip is not replaced. Instead, a new clip is stored, that is, a new reference to the clip is generated when the clip is stored.
The content system creates a tag for each content element. Each tag is created with the top tag as the parent, which creates a hierarchy that is only one level deep. When the content system opens a clip for read access, it opens it in FLAT navigation mode, then uses FPClip_FetchNext to advance to the proper tag. The Centera referral BLOb contains a list of content element sequence numbers, the position of the content element sequence number in the list corresponds to the tag 'index' (meaning the order in which the tags were added).
A parameter in the Centera Fixed Content Device specifies the size threshold for embedding content in the C-clip (with 0 meaning never embed).
Restriction Centera supports scrubbing content on deletion for both normal and fixed file stores; the content is over-written in a manner that completely prevents it from ever being read in the future. However, there is no corresponding mechanism for scrubbing indexed content from the CBR indexes. Therefore, indexing and scrubbing can potentially conflict with one another. Another point to consider is that fixed file stores support destructive delete. This feature writes a bit pattern over the file contents, but does not necessarily destroy the data, since data stored in the NTFS MFT might not be overwritten. We recommend that you use the non-recoverable Area Delete Method for Centera to ensure deletion of all content. The destructive and purge options are not recommended since they rely on the Centera blob purge mechanism, which has limited application.
By default, the Content Engine Centera provider does not specify the collision avoidance behavior when creating content. The provider simply passes FP_OPTION_CLIENT_CALCID_STREAMING to FPTag_BlobWrite. The collision avoidance behavior is as follows:
For performance reasons, store small content (for example, less than 20k) in the tag of the clip. The clip must always be read before the content BLOb, and reading a clip brings all tags and all data of the tags into memory. Storing the content in the tag eliminates performing a separate retrieval from Centera.
There are two potential drawbacks to storing content in the clip:
By default content is never stored in the clip. However, a Centera provider configuration parameter can override this behavior and embed content up to 100K in size (the Centera maximum) in the clip. See Fixed Content Devices properties (General tab) for more information.
The document content retention period is set once, when the document is checked into a Centera store. The retention period is not exposed via the Content Engine API. It can only inherit the value defined for the fixed storage area (all fixed storage areas have a retention period, and all documents checked into the storage area receive the retention period of the storage area).
The document retention period is computed during check in, and applied as a system read-only property known as the ContentRetentionDate. Note the default retention period of a fixed file store is expressed as an elapsed time (number of seconds), but the ContentRetentionDate is expressed as a date/time format (the document cannot be deleted before this date and time).
The content system fails any attempt to delete content with a retention period that prevents deletion. The Content Engine Service pre-filters delete requests, and fails any requests prevented by the ContentRetentionDate value.
The RetentionPeriod property works with the retention period support of the Centera server. If the RetentionPeriod property is greater than 0, then its value is converted from minutes to seconds and passed to the Centera FPClip.setRetetentionPeriod method.
Other values for the Fixed Content Area RetentionPeriod property have the following effect:
Retention Period Setting |
Result |
---|---|
RetentionPeriod.ZERO (0) | No retention (can be deleted immediately).
In Content Engine, no ContentRetetentionDate is set for the Document. In Centera, the library constant FP_NO_RETENTION_PERIOD is used in the FPClip.setRetentionPeriod method. |
RetentionPeriod.INFINITE (-1) | Infinite retention (can never be deleted)
In Content Engine, a date of 12/31/9999 23:59:59.000 UTC is used as the ContentRetentionDate for the Document. In Centera, the library constant FP_INFINITE_RETENTION_PERIOD is used in the FPClip.setRetentionPeriod method. |
RetentionPeriod.DEFAULT(-2) or RetentionPeriod.UNDEFINED (-101) | Centera is used to calculate the retention date based on the following criteria:
If DefaultRetentionPassThrough is true on CenteraFixedContentDevice
Else If Centera device’s default retention is NO Retention
Else Infinite retention is used, and a date of 12/31/9999 23:59:59.000 UTC is used as the ContentRetentionDate for the Document. |
RetentionPeriod.NOT_ALLOWED (-102) | EngineRuntimeException is thrown. This is the default if no RetentionPeriod property is defined for the FixedStorageArea. Thus, a RetentionPeriod property must be defined on the FixedStorageArea to have a valid configuration. |
Clip retention and purging BLObs is controlled by the Centera compliance licensing model, as seen in the table below from the Centera Version 2.0 Programmer’s Guide. Note the name changes in version 3.0 of the SDK.
Basic | Basic Compliance (ce) Also known as Governance Edition in 3.0 SDK |
Compliance Complete (ce+) Also known as Compliance Edition Plus in 3.0 SDK |
|
---|---|---|---|
Retention periods | No | Yes | Yes |
Default retention period | 0 | 0 | Infinite |
Purge data | Yes | Yes | No |
Delete data | Yes | Only if retention period has expired | Only if retention period has expired |
Centera security is based on the following:
Content Engine integration with Centera keeps all clip identifiers secret, and does not allow a user to ever view the value.
Centera also supports 'application' security, which consists of deploying matching security modules (for example, a file) on both the Centera client and server systems. Application security can be used to control what high level operations (read, write, delete, query) a Centera client can perform. In Centera, all content in the repository is in a single pool, and the content cannot be separated by application.
The pool address (connection string) holds a set of Centera pool addresses, each mapped to a set of Content Engine service computers. This allows Content Engine to take advantage of Centera replication, by specifying the primary cluster in the pool address as the cluster that is near the Content Engine service computer. For example, you have two sites, London and Houston, each with its own Centera system, and each Centera system replicating to the other. Content Engine computers in the London site must specify the pool address as primary=London,secondary=Houston, where computers in the Houston site must specify the pool address as primary=Houston,secondary=London.
The XML appears as follows:
SiteMap:<?xml version="1.0" encoding="UTF-16"?> <FnProviderAttributes> <FnProviderAttribute Name='SiteDefinition' Id='900'> <AttrValue Datatype='string'>London</AttrValue> <AttrValue Datatype='string'>Houston</AttrValue> </FnProviderAttribute> <FnProviderAttribute Name='PoolAddress' Id='300182'> <AttrValue Datatype='string'> primary=199.245.235.96,secondary=199.245.235.92 </AttrValue> <AttrValue Datatype='string'> primary=199.245.235.92,secondary=199.245.235.96 </AttrValue> </FnProviderAttribute> <FnProviderAttribute Name='London' Id='910'> <AttrValue Datatype='string'>wachdev11</AttrValue> <AttrValue Datatype='string'>wachdev21</AttrValue> </FnProviderAttribute> <FnProviderAttribute Name='Houston' Id='911'> <AttrValue Datatype='string'>wachdev41</AttrValue> <AttrValue Datatype='string'>wachdev42</AttrValue> <AttrValue Datatype='string'>wachdev43</AttrValue> </FnProviderAttribute> </FnProviderAttributes>
Attribute ID 900 defines the list of sites (London and Houston). Attribute ID 300182 defines the pool address strings for each site (must be in the corresponding position of the site attribute). Attributes 910 and 911 define a mapping between a site and the computers of the site (an attribute ID can not be repeated, the range of 910 to 999 is reserved for mappings).
Important If the Centera fixed content device has a sitemap file configured, make sure that it is encoded as a UTF-16 file. Otherwise, any attempt to migrate content to the Centera device will fail.