| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 12c (12.2.1) E70070-01 |
|
 前 |
 次 |
ホーム > Oracle WebCenter Contentによる開発 > コンテンツ・サーバーのJCRアダプタの使用
| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 12c (12.2.1) E70070-01 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > コンテンツ・サーバーのJCRアダプタの使用
この章では、Oracle WebCenter Content ServerのJava Content Repository (JCR)アダプタの使用方法について説明します。
この章の内容は次のとおりです。
Java Content Repository APIは、標準化された方法でコンテンツ・リポジトリにアクセスするための仕様です。この仕様は、Java Community ProcessのもとでJSR-170として開発されました。これには、Java APIのコンテンツ・リポジトリおよびJava Content Repository (JCR)が含まれています。
JSR-170仕様に関連する標準的なAPIは、コンテンツ・サーバーのJCRアダプタで機能し、公開されます。JCR 1.0 APIは、必須であり、基礎となるフレームワークの一部として事前デプロイされ、統合される必要があります。
Oracleアダプタは、完全に標準に基づいており、J2EEコネクタ・アーキテクチャとWebサービス・アーキテクチャの両方に準拠しています。JCRアダプタは、どのJSR-170準拠のアプリケーション上にもデプロイでき、標準ベースのJCR仕様を通じてコンテンツ・サーバーと通信することを可能にします。
JCR標準は、拡張可能なノード・タイプおよびコンテンツ・プロパティに基づいた階層型のデータ・モデルを使用します。このデータ・モデルは、リポジトリの、基礎となるストレージ・サブシステムによって使用されます。詳細は、JCRおよびJSR-170標準を参照してください。
nt:folderノード・タイプは、構造化されたノード・コレクションを表します。これは、多数のファイル・システムで採用されているディレクトリまたはフォルダのコンセプトに密接に関連しており、通常、ファイル・システム・ディレクトリをコンテンツ・リポジトリにマップするときに使用されるノード・タイプです。
nt:resource子ノードは通常、追加のリソース・メタデータが必要な場合にプレーン・バイナリ・プロパティのかわりに使用されます。
nt:fileノード・タイプは、なんらかのコンテンツのあるファイルを表します。
nt:unstructuredノード・タイプは、すべての種類のプロパティおよび子ノードをノードに追加することを許容します。これは通常、ノード内に格納されるコンテンツについて何も情報がないときに使用されます。
これは、次のような、コンテンツ・サーバーのJCRアダプタのデータ・モデルです。
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>
JCRアダプタは、JSR-170仕様をサポートするどのアプリケーションでも使用できますが、このアダプタでは、カスタム統合が必要です。このカスタム統合では、いくつかのAPIとランタイム・ライブラリで構成されている、基礎となるフレームワークがインストールされている必要があります。
|
注意: JCRアダプタとRemote Intradoc Client (RIDC)を除いて、これらのAPIとランライム・ライブラリはすべて、Oracle JDeveloperおよびOracle WebCenterで提供されています。 |
Application Development Framework (ADF)のランタイム・ライブラリのいくつかは必須であり、アプリケーションにインストールされている必要があります。これらのファイルは、Oracle JDeveloperインスタンスにあります。JDeveloperの「ADFランタイム・インストーラ」ウィザードを使用してインストールすることも、手動でインストールすることも可能です。
アプリケーションに次のADFランタイム・ライブラリがデプロイされている必要があります。
adf-share-base.jar
adf-share-ca.jar
adf-share-support.jar
adflogginghandler.jar
これらのライブラリをアプリケーションに手動でインストールする場合は、libディレクトリにインストールする必要があります。たとえば、TomcatへのインストールではTOMCAT_HOME/common/libディレクトリを使用し、Oracle WebLogic ServerへのインストールではWL_HOME/ADF/libディレクトリを使用します。(Oracle WebLogic Serverの場合、ADFおよびlibディレクトリを作成する必要があります。)
アプリケーションにRemote Intradoc Clientがデプロイされている必要があります。RIDCは、コンテンツ・サーバーとの通信のためのシン通信APIを提供します。このAPIは、コンテンツ・サーバー・インスタンスへのデータ抽象化を除去する一方で、接続のプーリング、セキュリティおよびプロトコルの固有情報を処理するためのラッパーを引き続き提供します。RIDCは、JCRアダプタの配布ファイルに含まれており、Oracle Technology Network (OTN)で入手できます。
第30章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。
アプリケーションにJava Content Repository (JCR) APIがデプロイされている必要があります。JCR APIはJDeveloperから使用できます。または、Apache Software FoundationのWebサイト(http://www.apache.org/)からダウンロードすることもできます。
JCR APIは、JSR-170仕様にも含まれていて、Java Community ProcessのWebサイト(http://www.jcp.org/)からダウンロードできます。
次のJCR統合ライブラリは必須であり、アプリケーションにデプロイされている必要があります。
jcr-common-runtime.jar
ojcr.jar
ojdbc5.jar
これらのファイルは、JDeveloperインスタンスにあります。
次のXML統合ライブラリは必須であり、アプリケーションにデプロイされている必要があります。
xmlparserv2.jar
xquery.jar
これらのファイルは、JDeveloperインスタンスにあります。
コンテンツ・サーバーとの通信を可能にするには、アプリケーションにJCRアダプタがデプロイされている必要があります。JCRアダプタは、基礎となるフレームワークの一部としてRemote Intradoc Client (RIDC)を利用し、一般的なJSR-170アーキテクチャと連携して機能します。
JCRアダプタのデプロイでは、それぞれのJSR-170準拠アプリケーションの一般的な指示に従ってください。JCRアダプタは、埋込みのデプロイメント・ディスクリプタ(rep_descriptor.xml)を使用します。デプロイメントでは、多くのアプリケーションがデプロイメント・ディスクリプタを使用して、管理インタフェースまたはデプロイメント・ウィザードの一部として構成エントリを移入します。アプリケーションで管理インタフェースまたはデプロイメント・ウィザードを使用していない場合、デプロイメント・ディスクリプタを直接編集し、必要な値を指定する必要があります。
JCRアダプタとコンテンツ・サーバー間の通信を可能にするには、次の項目を構成します。
通信方法
ソケット通信(リスナー・ポート)
セキュア・ソケット通信(SSL)
Web通信(Webサーブレット・フィルタ)
ユーザー・エージェント
キャッシュ設定
この構成設定では、プロバイダ名と通信方法を指定する必要があります。
CIS_SOCKET_TYPE_CONFIG: この構成設定は、コンテンツ・サーバーとの通信方法を定義します。オプションは、socket、socketsslおよびwebです。次に例を示します。
oracle.stellent.jcr.configuration.cis.config.socket.type
socket (リスナー・ポート)の通信方法では、RIDCがコンテンツ・サーバーのリスナー・ポートを使用するように指定されます。通信方法としてsocketを使用する場合は、必須の構成値を指定する必要があります。
socketsslの通信方法では、通信プロトコルとしてセキュア・ソケット通信(SSL)を使用することが指定されます。通信方法としてsocketsslを使用する場合は、ソケット通信とセキュア・ソケット通信の両方の構成値を指定する必要があります。
web (Web サーバー・フィルタ)の通信方法では、RIDCがWeb サーバー・フィルタ経由で通信することが指定されます。Web サーバー・フィルタは、各リクエストに対して個別の認証を要求します。通信方法としてwebを使用する場合は、必須の構成値を指定する必要があります。
通信プロトコルとしてセキュア・ソケット通信(SSL)を使用する場合は、次の構成設定の値を指定する必要があります。
SERVER_HOST_CONFIG: コンテンツ・サーバーが実行されているマシンのホスト名。デフォルト値はlocalhostです。
oracle.stellent.jcr.configuration.server.host
SERVER_PORT_CONFIG: コンテンツ・サーバーがリスニングしているポート。デフォルト値は16200です。
oracle.stellent.jcr.configuration.server.port
通信プロトコルとしてセキュア・ソケット通信(SSL)を使用する場合は、ソケット通信(リスナー・ポート)と次の構成設定の両方の値を指定する必要があります。
KEYSTORE_LOCATION: キーストア・ファイルの場所と名前。
oracle.stellent.jcr.configuration.ssl.keystore.location
KEYSTORE_PASSWORD: キーストア・ファイルのパスワード。
oracle.stellent.jcr.configuration.ssl.keystore.password
PRIVATE_KEY_ALIAS: 認証のための秘密鍵のエイリアス。
oracle.stellent.jcr.configuration.ssl.privatekey.alias
PRIVATE_KEY_PASSWORD: 秘密鍵のパスワード。
oracle.stellent.jcr.configuration.ssl.privatekey.password
ソケット通信の値については、第32.4.2項「ソケット通信(リスナー・ポート)の構成」を参照してください。
アプリケーションがWebサーバー・フィルタ経由で接続する(Web通信):場合は、次の構成設定のいずれかの値を指定する必要があります。
SERVER_WEB_CONTEXT_ROOT_CONFIG: /context_rootという形式の、コンテンツ・サーバーのWebサーバー・コンテキスト・ルート。この設定により、Oracle WebCenterおよび他のアプリケーション統合で、よりシームレスな統合が実現します。
例: /cs/
SERVER_WEB_URL_CONFIG: コンテンツ・サーバーのWebサーバー拡張機能への完全URL。プロトコル(通常はhttpまたはhttps)、ホスト名、ポート、相対Webルートおよび拡張ルート(通常はidcplg)を含みます。ポート80以外のポートを使用する場合は、ポート番号を指定する必要があります。
例: http://myserver.example.com:8080/cs/idcplg/
oracle.stellent.jcr.configuration.server.web.url
オプションで、次の構成設定の値を指定して、JCRリクエストを識別することができます。
CIS_USER_AGENT_CONFIG: RIDCユーザー・エージェントに添付する文字列。この値を設定すると、JCRアダプタによって行われるリクエストの識別に役立ちます。
oracle.stellent.jcr.configuration.cis.config.userAgent
オプションで、次のキャッシュ設定の値を指定できます。
VCR_CACHE_INVALIDATION_INTERVAL: WebCenter Content SPIがキャッシュの無効化をチェックするポーリング間隔(分単位)。デフォルトは0(ゼロ)で、キャッシュの無効化は行われません。最小値は2分です。
com.oracle.content.spi.ucm.CacheInvalidationInterval
VCR_BINARY_CACHE_MAX_SIZE: VCRバイナリ・キャッシュに格納されるドキュメントの最大サイズ(バイト単位)。デフォルト値は102400 (800KB)です。
com.bea.content.federated.binaryCacheMaxEntrySize
コンテンツ・サーバーによって管理されるコンテンツは、主に次の4つの表によって追跡されます。
これらの表は、コンテンツのメタデータ、状態およびアクションに加えて、各ファイルに関連付けられている情報も追跡します。
この表は、コンテンツの各リビジョンに関する主要な情報を追跡します。
リビジョンごとに1行
同じコンテンツIDおよびRevClass IDを共有し、同じコンテンツを持つ異なるリビジョン
各リビジョンのシステム・メタデータ
リビジョンのメタデータ: コンテンツID、タイトル、作成者、チェックイン日など
カテゴリ化およびセキュリティのメタデータ: タイプ、セキュリティ・グループ、ドキュメント・アカウント
様々なアクションの状態情報
索引の作成
Workflow
ドキュメント変換
リビジョンの追跡と取得に役立つ数値IDとテキスト・ラベル
各リビジョンの一意のdID値(表内の主キー)
コンテンツの一意のdRevClassID値
各リビジョンのリビジョン番号をマークするためのリビジョンID
この表は、各コンテンツ・リビジョンに関連付けられているファイルの情報を追跡します。
リビジョンごとに1行
リビジョンごとに複数行、次のファイルそれぞれに1行
プライマリ
代替
Web表示可能
ファイル情報: 元の名前、場所、言語、サイズなど
この表には、拡張メタデータ・フィールドが含まれます。
リビジョンごとに1行
メタデータ・フィールドごとに1列
DocMetaDefinition表に格納されている各フィールドの定義
この表は、各コンテンツ・リビジョンの情報を追跡します。
コンテンツ・アイテムごとに1行
コンテンツの変更がロックされた行
一意のdDocNameおよびRevClassId値
現在の索引付きリビジョン
日付およびユーザー:
作成日および作成者
最終変更日およびユーザー
所有者
コンテンツ・サーバーは、リポジトリを検索するための様々な方法を提供します。メタデータの検索は、Revisions、Documents、DocMetaおよびRevClasses表に基づいて行うことができます。テキスト検索を効率的に実行するには、Oracle Databaseの全文検索機能を利用し、検索索引を保持するためのIdcText表を作成します。
IdcText
この表には、Revisions、Documents、DocMetaおよびRevClasses表から選択された列に加えて、他のデータの列も含まれます。
Revisions、RevClassesおよびDocuments表からの事前定義リストが含まれます。
DocMeta表からの、検索可能と示されているカスタム・メタデータが含まれます。
OtsMeta列(CLOBフィールド)には、SDATAセクション、および他の列に存在しない追加の索引付け可能フィールドが含まれます。ただし、SDATAには大きな制限があります。
OtsContent列には、索引付け可能なドキュメントが含まれます。
ResultSetInterface列は、ソートやカウント予測、またはドリルダウンに使用できます。
ファイル・ストア・プロバイダを使用して、ファイル・システム、データベース、他のデバイス、またはこれら3つの任意の組合せで、コンテンツ・サーバーによって管理されるファイルを配布できます。ファイルは、Content Server 11gのSecureFilesに格納されます。データベース支援のファイル・ストレージの場合、FileStorageおよびFileCache表に、各ファイルに関連した情報が格納されます。
FileStorage
この表には、ファイル情報と一部の追加情報が格納されます。
BLOB(バイナリ・ラージ・オブジェクト)フィールドに格納されるファイル(Content Server 11gにおけるSecureFile)
データベース管理者は、追加のBLOB最適化を有効にすることができます。たとえば、SecureFilesによる重複排除、圧縮、暗号化などです。
コンテンツ・サーバーによって管理される特定のファイルを指すdIDおよびdRenditionID
少数のフィールドの追跡情報: 最終変更日およびファイル・サイズ
FileCache
この表には、ファイル・システムにキャッシュされているファイル、特定のタイプの処理(抽出、変換など)およびWebサーバーによるクイック・アクセスのためのポインタが格納されます。このポインタは、クリーンアップの実行にも使用されます。
