Conceptually, applications represent containers of documents with common characteristics as defined and enforced by the application. A single instance of Oracle Content Server may not be able to handle the multiple applications required by an organization. In order to scale a solution to handle the multiple applications required, multiple Content Server instances can be used. However, an application cannot be divided across multiple Content Server instances. To support multiple Oracle Content Server instances, you must associate each application with its target Content Server instance. To represent this at the Oracle I/PM level, a new object has been added to the public API known as the repository. The repository object is responsible for keeping track of the connection information to each Content Server instance. Each application will be associated with a particular repository. For more information about creating connections to repositories, see "Managing Connections".
The following table identifies how Oracle I/PM document properties map to Content Server document properties.
| Oracle I/PM Document Property | Content Server Property | Comment |
|---|---|---|
| Id | dDocName | |
| Name | dOriginalName | Could also come from dDocTitle but dDocTitle can be changed in Content Server user interface |
| Properties.ApplicationId | xIPMSYS_APP_ID | Custom metadata field |
| Properties.ApplicationName | none | Read from Application definition not from Content Server |
| Properties.BatchId | xIPMSYS_BATCH_ID | Custom metadata field |
| Properties.CharacterSetName | xIPMSYS_CHAR_SET | Custom metadata field |
| Properties.CreateDate | xIPMSYS_CREATE_DATE | dCreateDate is when a revision is checked in. If additional revisions are checked in, the value of dCreateDate tracks the revision. So this should be implemented as a custom metadata field. |
| Properties.Creator | xIPMSYS_CREATOR | Custom metadata field. dDocAuthor is the user who checks in a revision. If additional revisions are checked in, the value of dDocAuthor tracks the revision. So this should be implemented as a custom metadata field. |
| Properties.DocUrl | none | Will be computed with imaging code. There is a Content Server IdocScript function to compute the URL in the weblayout directory. |
| Properties.Language | xIPMSYS_LANG | Customer metadata field |
| Properties.LastModifiedBy | dDocAuthor of latest revision | |
| Properties.LastModifiedDate | dCreateDate of latest revision | |
| Properties.LockedBy | dCheckoutUser | Content server does not have a locking concept other than checking out a document to prevent others from checking it out. |
| Properties.LockedDate | none | |
| Properties.MimeType | dFormat | |
| Properties.RetentionPolicyName | none | |
| Properties.Size | dFileSize | |
| Properties.StoragePolicyDate | none | |
| Properties.StoragePolicyName | none | |
| Properties.Version | dRevisionID | This distinct from dRefLabel which can be modified by the user. |
| Properties.VolumeName | none | If a file store provider is configured and used, this could come from the rules. |
| FieldValues | Custom metadata fields defined by Application | |
| Permissions.Delete | Delete | Can be determined from IdocScript userHasGroupPrivilege(dSecurityGroup, “D”) function (or code that implements the function). |
| Permissions.Grant | Admin | Can be determined from IdocScript userHasGroupPrivilege(dSecurityGroup, “A”) function (or code that implemented the function) |
| Permissions.Modify Fields | Write | Can be determined from IdocScript userHasGroupPrivilege(dSecurityGroup, “W”) function (or code that implements the function) |
| Permissions.Update | Write | Can be determined from IdocScript userHasGroupPrivilege(dSecurityGruop, “W”) function (or code that implements the function) |
| Permissions.View | Read | Can be determined from IdocScript userHasGroupPrivilege(dSecurityGroup, “R”) function (or code that implements the function) |
| AnnotationPermissions | N/A | Annotation permissions are managed via I/PM Entity Beans. |
| Revision History
Audit History |
<Versions>
<Content Tracker> |
Revision history is provided as part of DOC_INFO service.
Auditing history must be obtained by reading the appropriate auditing data via the Content Tracker APIs. |