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.
This section contains the following topics:
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. For Content Server 11g, a profile trigger field should be automatically configured. For Content Server 10g, configure a profile trigger field by doing the following:
Add EnableIdcProfileField=1 as a general configuration variable to the 10g Content Server config.cfg file. For information on adding a general configuration variable to Content Server, see the documentation that came with the product.
Restart Content Server.
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 Oracle WebCenter Content System Administrator's Guide for Content Server.
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:
Create a new contribution folder to hold the application content. Make a note of the folder's identifier, for example 932000007.
Add a new profile rule and make note of the name. For example, App_<X>_Folder.
Select the Folder (xCollectionID) field and set the type to Info Only.
Enable Use default value and set the default value to the folder identifier obtained above. This allows people checking content in using the Content Server check in form to see the assigned folder.
Enable Is derived field and set the default value to the folder identifier obtained above. This allows the value to be set upon check in from any source, including from Imaging upload.
Setting the rule in this manner will not allow users to move content from one folder to another, including the trash folder. To allow the ability to delete documents and move files between folders, change the derived value to use custom script and add something similar to:
<$if not (IDC_SERVICE like "COLLECTION_DELETE_LOT|COLLECTION_RESTORE_ITEM")$>
<$dprDerivedValue="932000007"$>
<$endif$>
Edit the application profile for the Imaging application you wish to modify and add the rule defined above to the Rules tab.
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.
Create a new retention category and make note of the retention category identifier. For example, you could use App <X> Category.
Add a new profile rule and make note of the name. For example, you could use App_X_Category_rule.
Select the Retention Category field (xCategoryID) and set the type to Info Only.
Enable Use default value and set the default value to the retention category identifier obtained above. For example, App X Category. This allows people using the Content Server check in form to see the assigned category.
Enable Is derived field and set the default value to the retention category identifier obtained above (App X Category). This allows the value to be set upon check in from any source, including from Imaging upload.
Note:
If the category to which you are mapping the documents is a category that is a records-only category, you will also need to add a field for xIsRecord and set its default and derived values to "1".
Edit the application profile for the Imaging application you wish to modify and add the rule defined above to the Rules tab.
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 URM system, a number of restrictions are applied to Imaging content.
If the Imaging document is subject to a freeze in Oracle URM and you attempt to delete the document from Imaging, you will recieve 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 URM 10g, content associated with "Records-only" Categories are subject to the same restrictions.
If Imaging is connected with a system using Oracle URM 11g, content associated with categories using the "Restrict Edits", "Restrict Revisions" or "Restrict Deletes," designators are subject to the same restrictions in Imaging.
WARNING:
The "rule" used to associate content with an Oracle URM category must be carefully constructed per the instructions for integrating with Oracle URM. 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.
Add a new profile rule and make note of the name. For example App_X_IRM).
Select the IRMProtection field (xIRMProtection) and set the Type to Info Only.
Enable Use default value and set the default value. This value must match an Oracle IRM context. This allows people using the Content Server check in form to see the assigned IRM classification.
Enable Is derived field and set the default value. This value must match an Oracle IRM context. This allows the value to be set upon check in from any source, including Imaging upload.
Note:
If IRM is not configured correctly, or the value does not match a valid context, you will be unable to check content into Content Server because it will fail IRM validation.
Edit the application profile for the Imaging application you wish to modify and add the rule defined above to the Rules tab.
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.
Configure Content Server and Imaging to use the same LDAP-based identity store that Oracle WebCenter has been configured to use.
For information on configuring WebCenter and Content Server to use an LDAP identity store, see Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.
Configure Content Server as the bridge between Imaging and WebCenter Document Service using an Imaging supported version of Java.
WebCenter Spaces' Document Service uses the Folders component, and Imaging must be configured to automatically specify Folders for checked in content. For more information regarding configuring Imaging with Folders, see the section Section 8.1.3, "Working With Folders."
For further information regarding WebCenter Spaces integration with Content Server, see Oracle Fusion Middleware Administrator's Guide for 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 Section 7, "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 (Content Server 11g) xIPMSYS_CREATE_DATE (Oracle Content Server 10g) |
dDocCreatedDate (11g) or xIPMSYS_CREATE_DATE (10g) is the date a document is initially created. When additional revisions are checked in, the value the property tracks the initial document creation date. When using Oracle Content Server 10g, xIPMSYS_CREATE_DATE is implemented as a custom metadata field. |
|
Properties.Creator |
dDocCreator (Content Server 11g) xIPMSYS_CREATOR (Oracle Content Server 10g) |
dDocCreator (11g) or xIPMSYS_CREATOR (10g) is the user who initially creates a document. When additional revisions are checked in, the value of the property tracks the original creator.When using Oracle Content Server 10g, xIPMSYS_CREATOR is implemented as a custom metadata field. |
|
Properties.DocUrl |
none |
Will be computed with imaging code. There is an Content Server IdocScript function to compute the URL in the weblayout directory. |
|
Properties.LastModifiedBy |
dDocLastModifier (Content Server 11g) dDocAuthor of latest revision (Oracle Content Server 10g) |
dDocLastModifier (11g) or dDocAuthor (10g) is the author of the latest revision. If additional revisions are checked in, the value of the property tracks the revision. |
|
Properties.LastModifiedDate |
dDocLastModifiedDate (Content Server 11g) dCreateDate of latest revision (Oracle Content Server 10g) |
dDocLastModifiedDate (11g) or dCreateDate of the latest revision (10g) 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 via 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 via the Content Tracker APIs. |