Imaging uses the functionality of a database to store and retrieve uploaded documents. Documents are stored based on criteria specified in the application in which they reside.
When an application is created in Imaging, a corresponding profile and set of profile rules are created in the Content Server repository. It is expected that a profile trigger field has been configured.
Note:
The profiles that are automatically generated when an application is created in Imaging are assigned to the Administrators security group by default. These profiles can be made available to other user groups by modifying the standard Content Server profile rules. See the Administering Oracle WebCenter Content for more information. If the application is later modified in Imaging, the Content Server profile rules are reset and may need to be modified again to add other user groups.
The IpmRepository component sets up global profile rules to group system fields and ensure their display when an application profile is created. These profiles are created or updated each time Content Server is started.
Note:
You can disable the automatic update of the global profile rules by setting the Content Server configuration setting IpmUpdateProfileRules to 0 (zero). For information about configuring Content Server, see the Administering Oracle WebCenter Content.
The IpmRepository component creates the following rules:
Name | Description | Global Rule |
---|---|---|
IpmSystemFields |
Groups Imaging system fields. Can be used to include Imaging system fields in a profile. |
No |
IpmSystemFields_Hide |
Hides the Imaging system fields by default. To show the fields, include a rule that shows the fields (see IpmSystemFields rule). |
Yes |
IpmSystemFields_Restricted |
Restricts the ability to choose Imaging-specific values in security group and document type. |
Yes |
Any global rule does not need to be referenced by a specific profile in order to be active.
When an application is created, a profile and rules are created to handle the display of the application fields. The profile rules determine how the application fields are grouped and provide any default values for those fields. The following table describes the rules:
Name | Description | Global Rule |
---|---|---|
IpmApp_<X>_Fields |
Groups the application fields |
No |
IpmApp_<X>_Fields_Hide |
Hides the application fields |
Yes |
IpmApp_<X>_Defaults |
Sets defaults for Imaging system (Security Group, IPM Application ID) fields and application specific fields |
No |
In the rule names above, <X> is replaced with an internal application identifier. Any rules that are not global rules need to be referenced by a profile to become active.
A profile is created for the application and is given IpmApp_<X> as the profile name, where <X> is an internal application identifier. The label for the rule is the application name.
Imaging does not automatically assign application documents to a folder. However, by modifying an application profile and profile rules, you can automatically assign documents to a specific folder. To modify application rules to automatically assign documents to a specific folder, do the following:
Note:
If an application is modified in Imaging, and the modification includes an application name change, then the rule you just added to the application profile will need to be added again.
Imaging does not automatically assign documents to a retention category or life cycle. However, by modifying an application's profile and profile rules, you can automatically assign documents to a retention category or life cycle. The following steps are for assigning a retention category value. If you wish to assign a life cycle, substitute xLifeCycleID for xCategoryID.
Note:
If an application is modified in Imaging, and the modification includes an application name change, then the rule you just added to the application profile will need to be added again.
When Imaging content is configured correctly with an Oracle WebCenter Content RM system, a number of restrictions are applied to Imaging content.
If the Imaging document is subject to a freeze in Oracle WebCenter Content RM and you attempt to delete the document from Imaging, you will receive the error "The documents cannot be deleted because they are in a legislative hold in the repository." You will be unable to update the document in Imaging, or move or copy the document to another application. Only the Imaging or WebCenter Content Administrator will be able to delete documents which are frozen. Once unfrozen, the restrictions within Imaging are removed.
If Imaging is connected with a system using Oracle WebCenter Content RM and you use RM features in WebCenter Content to control content, content associated with Imaging is subject to the same level of control.
WARNING:
The "rule" used to associate content with an Oracle WebCenter Content RM category must be carefully constructed per the instructions for integrating with Oracle WebCenter Content RM. Failure to create this rule correctly may assign Imaging content to records categories or allow them to be frozen, which restricts an Imaging user's ability to modify the document if necessary.
When using the WebCenter Content Adapter for Content Server to allow Oracle Universal Records Manager to use multiple Content Server repositories, you must ensure that security groups are consistent between the Content Server and Oracle URM. The WebCenter Content Adapter does not synchronize security groups created by Imaging with Oracle URM.
If an application is created in Imaging that adds security groups to the Content Server repository, you must manually configure the same security groups on Oracle URM that was created by Imaging. This should be done prior to uploading any content to the Imaging application. Additionally, if there is any modification to an Imaging application or to document security in an application, you must manually update the security groups in Oracle URM.
Note:
Imaging metadata fields are not propagated to Oracle URM at all, so documents in Oracle URM do not have any indication of the values specified in Imaging.
Imaging does not automatically assign application documents to an IRM classification. However, by modifying an application profile and profile rules, you can automatically assign documents to an IRM classification.
Note:
If an application is modified in Imaging, and the modification includes an application name change, then the rule you just added to the application profile will need to be added again.
Imaging documents are not automatically accessible within WebCenter Spaces, but documents can be automatically assigned to Folders visible within WebCenter Spaces. Manual configuration and modification of an application profile and profile rules are required to ensure that Imaging documents will be accessible.
For further information regarding WebCenter Spaces integration with Content Server, see Administering Oracle WebCenter Portal.
Conceptually, applications represent containers of documents with common characteristics as defined and enforced by the application. A single instance of 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 Content Server instances, you must associate each application with its target Content Server instance. To represent this at the Imaging 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 Imaging document properties map to Content Server document properties.
Imaging Document Property | Content Server Property | Comment |
---|---|---|
Id |
dDocName |
|
Name |
dOriginalName |
Could also come from dDocTitle but dDocTitle can be changed in the Content Server user interface |
Properties.ApplicationId |
none |
Custom metadata field |
Properties.ApplicationName |
none |
Read from Application definition not from Content Server |
Properties.BatchId |
xIPMSYS_BATCH_ID |
Custom metadata field |
Properties.CreateDate |
dDocCreatedDate |
dDocCreatedDate is the date a document is initially created. When additional revisions are checked in, the value the property tracks the initial document creation date. |
Properties.Creator |
dDocCreator |
dDocCreator is the user who initially creates a document. When additional revisions are checked in, the value of the property tracks the original creator. |
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.LastModifiedBy |
dDocLastModifier |
dDocLastModifier is the author of the latest revision. If additional revisions are checked in, the value of the property tracks the revision. |
Properties.LastModifiedDate |
dDocLastModifiedDate |
dDocLastModifiedDate is the date the last revision was checked in. If additional revisions are checked in, the value of the property tracks the 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.Size |
dFileSize |
|
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 through Imaging 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 using the Content Tracker APIs. |