This chapter describes how to use the Java Content Repository (JCR) adapter for Oracle WebCenter Content Server.
This chapter includes the following sections:
Section 31.2, "Installing Required APIs and Runtime Libraries"
Section 31.4, "Configuring Communication with Content Server"
The Java Content Repository API is a specification for accessing content repositories in a standardized manner. This specification was developed under the Java Community Process as JSR-170 and includes the Content Repository for Java API and the Java Content Repository (JCR).
The standard APIs associated with the JSR-170 specification are functional and exposed in the JCR adapter for Content Server. The JCR 1.0 API is required and must be predeployed and integrated as part of the underlying framework.
Oracle adapters are fully standards based and compliant with both the J2EE Connector Architecture and the Web Services Architecture. The JCR adapter can be deployed on any JSR-170-compliant application to enable communication with Content Server through the standards-based JCR specification.
The JCR standard uses a hierarchical data model based on extensible node types and content properties. This data model is used by the repository's underlying storage subsystems. For more information, see the JCR and JSR-170 standards.
The nt:folder node type represents a structured collection of nodes. It is closely related to the directory or folder concept found in many file systems and is the node type that is normally used when mapping file system directories to a content repository.
The nt:resource child node is normally used instead of a plain binary property when more resource metadata is required.
The nt:file node type represents a file with some content.
The nt:unstructured node type permits all kinds of properties and child nodes to be added to a node. It is normally used when nothing is known about the content that will be stored within a node.
This is the data model for the Content Server JCR adapter:
A Folder [nt:folder]
+- jcr:content [nt:resource]
+- jcr:created DATE
<returns dCreateDate for the folder>
+- ojcr:owner STRING
<returns dCollectionOwner for the folder>
+- ojcr:creator STRING
<returns dCollectionCreator if it is available,
otherwise it returns dCollectionOwner>
+- ojcr:lastModifier STRING
<returns dCollectionModifier if it is available,
otherwise it returns dCollectionOwner
+- ojcr:lastModified STRING
<returns dLastModifiedDate>
+- ojcr:displayName STRING
<returns dCollectionName for the folder>
+- idc:defaultMetadata [nt:unstructured]
<metadata that should by default be applied to content checked
into this folder. see idc:metadata under nt:file/jcr:content for
example fields>
+- idc:folderMetadata [nt:unstructured]
+- idc:dCollectionName STRING
+- idc:dCreateDate DATE
+- idc:dCollectionPath STRING
+- idc:dLastModifiedDate DATE
+- idc:dCollectionOwner STRING
+- idc:dCollectionGUID STRING
+- idc:dParentCollectionID INTEGER
+- idc:dCollectionQueries INTEGER
+- idc:dCollectionEnabled INTEGER
+- idc:dCollectionInherit INTEGER
+- idc:dChildManipulation INTEGER
+- idc:dCollectionID INTEGER
+- idc:dCollectionCreator STRING
+- idc:dCollectionModifier STRING
+- idc:folderPermissions [nt:unstructured]
+- idc:userCanRead INTEGER
+- idc:userCanWrite INTEGER
+- idc:userCanDelete INTEGER
A Document.txt [nt:file]
+- jcr:content [nt:resource]
+- jcr:data=...
+- jcr:created DATE
<returns dDocCreatedDate from the RevClasses table>
+- ojcr:creator STRING
<returns dDocCreator from the RevClasses table>
+- ojcr:lastModifier STRING
<returns dDocLastModifier from the RevClasses table>
+- ojcr:lastModified STRING
<returns dDocLastModifiedDate >
+- ojcr:author STRING
<returns dDocAuthor for the document>
+- ojcr:comment STRING
<if xComments exists as a metadata field, that is returned>
+- ojcr:displayName STRING
<returns the filename>
+- ojcr:language STRING
<if xIdcLanguage exists as a metadata field, that is returned>
+- idc:metadata [nt:unstructured]
<returns values for everything in the RevClasses table,
please see the definition of that table to see exactly what is defined
+- idc:dID INTEGER
+- idc:dDocName STRING
+- idc:dDocTitle STRING
+- idc:dDocAuthor STRING
+- idc:dRevClassID INTEGER
+- idc:dRevisionID INTEGER
+- idc:dRevLabel STRING
+- idc:dIsCheckedOut INTEGER
+- idc:dSecurityGroup STRING
+- idc:dCreateDate DATE
+- idc:dInDate DATE
+- idc:dOutDate DATE
+- idc:dStatus STRING
+- idc:dReleaseState STRING
+- idc:dWebExtension STRING
+- idc:dProcessingState STRING
+- idc:dMessage STRING
+- idc:dDocAccount STRING
+- idc:dReleaseDate DATE
+- idc:dRendition1 STRING
+- idc:dRendition2 STRING
+- idc:dIndexerState STRING
+- idc:dPublishType STRING
+- idc:dPublishState STRING
+- idc:dWorkflowState STRING
+- idc:dRevRank INTEGER
<all custom metadata properties for a revision
like idc:xComments STRING>
The JCR adapter can be used with any application that supports the JSR-170 specification, but the adapter requires a custom integration. This custom integration requires that an underlying framework consisting of several APIs and runtime libraries be installed.
Note:
All of these APIs and runtime libraries are provided with Oracle JDeveloper and Oracle WebCenter, with the exception of the JCR adapter and Remote Intradoc Client (RIDC).
Several of the Application Development Framework (ADF) runtime libraries are required and must be installed on your application. These files are available in your Oracle JDeveloper instance. You can perform the installation using the ADF Runtime Installer wizard in JDeveloper, or you can do it manually.
The following ADF runtime libraries must be deployed on your application:
adf-share-base.jar
adf-share-ca.jar
adf-share-support.jar
adflogginghandler.jar
If you choose to manually install these libraries on your application, they must be installed in the lib directory. For example, an installation on Tomcat would use the TOMCAT_HOME/common/lib directory, and an installation on Oracle WebLogic Server would use the WL_HOME/ADF/lib directory. (For Oracle WebLogic Server, you must create the ADF and lib directories.)
Remote Intradoc Client must be deployed on your application. RIDC provides a thin communication API for communication with Content Server. This API removes data abstractions to the Content Server instance while still providing a wrapper to handle connection pooling, security, and protocol specifics. RIDC is included with the JCR adapter distribution file and is available from the Oracle Technology Network (OTN).
For more information, see Chapter 30, "Using RIDC to Access Content Server."
The Java Content Repository (JCR) API must be deployed on your application. The JCR API is available from JDeveloper or for download from The Apache Software Foundation website at http://www.apache.org/.
The JCR API is also part of the JSR-170 specifications download from the Java Community Process website at http://www.jcp.org/.
The following JCR integration libraries are required and must be deployed on your application:
jcr-common-runtime.jar
ojcr.jar
ojdbc5.jar
These files are available in your JDeveloper instance.
The JCR adapter must be deployed on your application to enable communication with Content Server. The JCR adapter utilizes Remote Intradoc Client (RIDC) as part of the underlying framework and works in conjunction with the general JSR-170 architecture.
Follow the general instructions of your specific JSR-170-compliant application for deploying JCR adapters. The JCR adapter uses an embedded deployment descriptor (rep_descriptor.xml). Upon deployment, many applications will use the deployment descriptor to populate the configuration entries as part of an administration interface or deployment wizard. If your application does not use an administration interface or deployment wizard, you will need to edit the deployment descriptor directly and provide the required values.
To enable communication between the JCR adapter and Content Server, you configure these items:
Communication method
Socket communication (listener port)
Secure Socket Communication (SSL)
Web communication (web servlet filter)
User agent
Cache settings
You must supply the provider name and communication method with this configuration setting:
CIS_SOCKET_TYPE_CONFIG: This configuration setting defines the communication method with Content Server. The options are socket, socketssl, and web. For example:
oracle.stellent.jcr.configuration.cis.config.socket.type
The socket (listener port) communication method specifies that RIDC should use the Content Server listener port. If socket is used as the communication method, you must provide the required configuration values.
The socketssl communication method specifies that secure socket communication (SSL) be used as the communication protocol. If socketssl is used as the communication method, you must provide configuration values for both socket communication and secure socket communication.
The web (web server filter) communication method specifies that RIDC should communicate through the web server filter, which requires individual authentication for each request. If web is used as the communication method, you must provide the required configuration value.
You must supply values for these configuration settings if secure socket communication (SSL) is used as the communication protocol:
SERVER_HOST_CONFIG: The hostname of the machine on which Content Server is running. The default value is localhost.
oracle.stellent.jcr.configuration.server.host
SERVER_PORT_CONFIG: The port on which Content Server is listening. The default value is 16200.
oracle.stellent.jcr.configuration.server.port
You must supply values for both socket communication (listener port) and these configuration settings if secure socket communication (SSL) is used as the communication protocol:
KEYSTORE_LOCATION: The location and name of the keystore file.
oracle.stellent.jcr.configuration.ssl.keystore.location
KEYSTORE_PASSWORD: The password for the keystore file.
oracle.stellent.jcr.configuration.ssl.keystore.password
PRIVATE_KEY_ALIAS: The private key alias for authentication.
oracle.stellent.jcr.configuration.ssl.privatekey.alias
PRIVATE_KEY_PASSWORD: The private key password.
oracle.stellent.jcr.configuration.ssl.privatekey.password
For information about socket communication values, see Section 31.4.2, "Configuring Socket Communication (Listener Port)."
You need to supply a value for one of these configuration settings if your application is connecting through the web server filter (web communication):
SERVER_WEB_CONTEXT_ROOT_CONFIG: The web server context root for Content Server, in the format /context_root. This setting provides a more seamless integration for Oracle WebCenter and for other application integrations.
For example: /cs/
SERVER_WEB_URL_CONFIG: The full URL to the Content Server web server extension. Include the protocol (usually http or https), host name, port, relative web root, and extension root (usually idcplg). If a port other than port 80 is used, the port number needs to be specified.
For example: http://myserver.example.com:8080/cs/idcplg/
oracle.stellent.jcr.configuration.server.web.url
You can optionally supply a value for this configuration setting to identify JCR requests:
CIS_USER_AGENT_CONFIG: A string to append to the RIDC user agent. This value can be set to help identify requests made by the JCR adapter.
oracle.stellent.jcr.configuration.cis.config.userAgent
You can optionally supply values for these cache settings:
VCR_CACHE_INVALIDATION_INTERVAL: Polling interval used by the WebCenter Content SPI to check for cache invalidations, in minutes. Defaults to 0 (zero), cache invalidation disabled. The minimum value is 2 minutes.
com.oracle.content.spi.ucm.CacheInvalidationInterval
VCR_BINARY_CACHE_MAX_SIZE: Maximum size of documents stored in the VCR binary cache, in bytes. The default value is 102400 (800 KB).
com.bea.content.federated.binaryCacheMaxEntrySize
Content managed by Content Server is primarily tracked by four tables:
These tables track the content's metadata, state, and actions as well as information that is associated with each file.
This table tracks core information about each revision of the content:
One row per revision
Different revisions with the same content that share the same content ID and RevClass ID
System metadata for each revision:
Metadata for revisions: content ID, title, author, check-in date, and so on
Metadata for categorization and security: type, security group, doc account
State information for various actions:
Indexing
Workflow
Document conversion
Numeric IDs and text labels to help track and retrieve a revision:
A unique dID value for each revision (the primary key in the table)
A unique dRevClassID value for the content
A revision ID to mark the revision number for each revision
This table tracks information for files that are associated with each content revision:
One row per revision
Multiple rows per revision, one row for each of these files:
Primary
Alternate
Web-viewable
File information: original name, location, language, size, and so on
This table contains extended metadata fields:
One row per revision
One column per metadata field
Definition for each field stored in the DocMetaDefinition table
This table tracks information for each content revision:
One row per content item
Row locked for content modification
Unique dDocName and RevClassId values
Current indexed revision
Dates and users:
Creation date and creator
Last modified date and user
Owner
Content Server provides various ways to search the repository. Metadata searches can be based on the Revisions, Documents, DocMeta, and RevClasses tables. To efficiently perform text searches, the full-text search feature of Oracle Database can be utilized, and the IdcText table can be created to hold the search index.
This table contains selected columns from the Revisions, Documents, DocMeta, and RevClasses tables as well as columns for other data:
It contains a predefined list from the Revisions, RevClasses, and Documents tables.
It contains custom metadata that is indicated as searchable from the DocMeta table.
The OtsMeta column (CLOB field) contains an SDATA section and additional indexable fields that are not in the other columns. However, SDATA has significant limitations.
The OtsContent column contains an indexable document.
The ResultSetInterface column can be used for sorting or count estimation, or to drill down.
The File Store Provider can be used to distribute files managed by Content Server on the file system, a database, other devices, or any combination of these. The files are stored in SecureFiles in Content Server 11g. For database-backed file storage, the FileStorage and FileCache tables store the information related to each file.
This table stores file information and some additional information:
File stored in a BLOB (binary large object) field (SecureFiles in Content Server 11g)
The database administrator can turn on additional BLOB optimizations. For example, deduplication, compression, and encryption with SecureFiles.
Values for dID and dRenditionID that point to a particular file managed by Content Server
Tracking information in a small number of fields: last modified date and file size
This table stores pointers for files cached on the file system, for certain types of processing (extraction, conversion, and so on), and for quick access by the web server. This pointer is also used to perform cleanup.