WebCenter Content Content Server開発者ガイド

11g リリース1(11.1.1)

E10807-04(原本部品番号:E10807-04)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

新機能および変更された機能

- 11g リリース1 (11.1.1)の新機能

- 11g リリース1 (11.1.1)の変更された機能

第I部 Oracle WebCenter Content Serverのカスタマイズの開始

1 Oracle WebCenter Content Serverの概要

- 1.1 コンテンツ・サーバーのアーキテクチャの概要

- 1.1.1 WebCenter Contentのディレクトリおよびファイル

- 1.1.1.1 WebCenter Contentのディレクトリの用語

- 1.1.1.2 binディレクトリ

- 1.1.1.3 configディレクトリ

- 1.1.1.4 componentsディレクトリ

- 1.1.1.5 resourcesディレクトリ

- 1.1.1.6 weblayoutディレクトリ

- 1.1.2 リソース

- 1.2 カスタマイズのタイプ

- 1.3 カスタマイズの計画

- 1.4 コンテンツ・サーバーのカスタマイズで推奨されるスキルとツール

- 1.5 コンテンツ・サーバーの動作

- 1.5.1 起動動作

- 1.5.1.1 起動手順

- 1.5.1.2 構成のロードの影響

- 1.5.2 リソースのキャッシング

- 1.5.3 ページ・アセンブリ

- 1.5.4 データベースとの対話

- 1.5.5 ローカライズされた文字列の解決

- 1.5.6 アプリケーション統合

2 Oracle Fusion Order Demoサンプル・アプリケーションの概要

- 2.1 Fusion Order DemoおよびSuppliersモジュールについて

- 2.2 Fusion Order Demoアプリケーションの設定

- 2.3 Suppliersモジュールの実行

- 2.3.1 Suppliersモジュール・コード

- 2.3.2 Suppliersモジュールのページ

第II部 コンテンツ・サーバー・インタフェースのルック・アンド・フィールの変更

3 コンテンツ・サーバー・インタフェースのカスタマイズ

- 3.1 コンテンツ・サーバー・インタフェースのカスタマイズについて

- 3.1.1 スキンとレイアウトのタイプ

- 3.1.2 スキン

- 3.1.3 レイアウト

- 3.2 別のスキンまたはレイアウトの選択

- 3.2.1 別のスキンまたはレイアウトの選択方法

- 3.2.2 実行時に行われる処理

- 3.3 新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成

- 3.4 スキンまたはレイアウトのテンプレートの変更

- 3.4.1 動的パブリッシュについて

- 3.5 匿名ユーザー・インタフェースの変更

- 3.5.1 匿名ユーザー・インタフェースの変更方法

- 3.5.2 実行時に行われる処理

- 3.6 ログイン・ページのURLの変更

- 3.7 新規レイアウトの作成およびパブリッシュ

- 3.8 パブリッシュされたファイルの使用の最適化

- 3.8.1 ファイルのバンドル

- 3.8.2 パブリッシュされたファイルの参照

4 動的サーバー・ページの作成

- 4.1 動的サーバー・ページについて

- 4.1.1 ページ・タイプ

- 4.1.1.1 IDOCファイル

- 4.1.1.2 HCSTファイル

- 4.1.1.3 HCSPファイル

- 4.1.1.4 HCSFファイル

- 4.2 Webページの外観およびナビゲーションの変更

- 4.2.1 構文

- 4.2.1.1 Idocスクリプトの式

- 4.2.1.2 比較演算子

- 4.2.1.3 特殊文字

- 4.2.1.4 メタデータの参照

- 4.2.2 Idocスクリプトの関数

- 4.2.2.1 docLoadResourceIncludes関数

- 4.2.2.2 executeService関数

- 4.2.3 開発に関する推奨事項

- 4.2.3.1 一般的ガイドライン

- 4.2.3.2 HCSFガイドライン

- 4.2.4 HCSFページ

- 4.2.4.1 ロード・セクション

- 4.2.4.2 データ・セクション

- 4.2.4.3 フォーム・セクション

- 4.3 動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルの作成

- 4.4 HCSTページの作成

- 4.5 HCSPページの作成

- 4.6 HCSFページの作成

- 4.6.1 フォームの共通コード

- 4.6.1.1 ファイル情報の取得

- 4.6.1.2 ファイル拡張子の参照

- 4.6.1.3 フォーム情報の定義

- 4.6.1.4 フォーム・フィールドの定義

- 4.6.1.5 非表示フィールドの定義

- 4.6.1.6 フォームの送信

- 4.7 HCST、HCSP、HCSFの各ページのWebブラウザでの表示の確認

第III部 コンテンツ・サーバーの機能の変更

5 システム設定の変更

- 5.1 システム設定の変更について

- 5.2 管理サーバーを使用したシステム設定の変更

- 5.3 システム・プロパティ・アプリケーションを使用したシステム設定の変更

- 5.4 Webレイアウト・エディタを使用したライブラリおよびシステム・ホーム・ページのカスタマイズ

- 5.5 ユーザー管理アプリケーションを使用したユーザーのセキュリティおよびアカウントの定義

6 構成情報の変更

- 6.1 構成情報の変更について

- 6.2 Idocスクリプトのカスタム・スクリプト言語を使用した構成の変更

- 6.3 他の開発ツールおよびテクノロジを使用した構成の変更

7 サービスのカスタマイズ

- 7.1 サービスのカスタマイズについて

- 7.2 コンテンツ・サーバーと通信するためのサービスのカスタマイズ

- 7.3 データベースにアクセスするためのサービスのカスタマイズ

8 「アクション」メニューの生成

- 8.1 「アクション」メニューの生成について

- 8.2 表示表の作成

- 8.2.1 「ヘッドライン表示」表

- 8.2.2 「サムネイル表示」表

- 8.3 「アクション」メニューのカスタマイズ

第IV部 コンポーネントによるコンテンツ・サーバーのカスタマイズ

9 コンテンツ・サーバーのコンポーネントの開始

- 9.1 標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントについて

- 9.1.1 コンポーネント・ファイルの概要

- 9.1.2 コンポーネントの使用

- 9.1.3 ディレクトリおよびファイルについて

- 9.1.3.1 HDAファイル

- 9.1.3.2 カスタム・リソース・ファイル

- 9.1.3.3 データ・バインダ

- 9.1.3.4 manifestファイル

- 9.1.3.5 その他のファイル

- 9.1.3.6 一般的なディレクトリ構造

- 9.1.4 開発に関する推奨事項

- 9.1.4.1 コンポーネントの作成

- 9.1.4.2 コンポーネント・ファイルでの作業

- 9.1.4.3 開発コンテンツ・サーバーの使用

- 9.1.4.4 コンポーネント・ファイルの編成

- 9.1.4.5 ネーミング規則

- 9.2 コンポーネントを管理するためのツール

- 9.2.1 コンポーネント・ウィザード

- 9.2.2 拡張コンポーネント・マネージャ

- 9.2.3 ComponentTool

- 9.3 コンポーネント・ファイル

- 9.3.1 idc製品の_components.hdaファイル

- 9.3.2 Components ResultSet

- 9.3.3 コンポーネント定義(Glue)ファイル

- 9.3.3.1 ResourceDefinition ResultSet

- 9.3.3.2 MergeRules ResultSet

- 9.3.3.3 Filters ResultSet

- 9.3.3.4 ClassAliases ResultSet

- 9.4 Webページをアセンブルするためのリソース

10 コンテンツ・サーバーのコンポーネントの有効化と無効化

- 10.1 コンポーネントの有効化と無効化について

- 10.2 コンポーネントの有効化

- 10.3 コンポーネントの無効化

11 コンポーネント構成の更新

- 11.1 コンポーネント構成の更新について

- 11.2 拡張コンポーネント・マネージャを使用したコンポーネント構成の更新

- 11.3 「instanceの構成」画面を使用したコンポーネント構成の更新

12 Content Trackerのカスタマイズ

- 12.1 Content Trackerについて

- 12.1.1 Content TrackerおよびContent Trackerレポート

- 12.2 Content Trackerのコンポーネントおよび機能

- 12.2.1 DataBinderダンプ機能

- 12.2.1.1 DataBinderダンプ機能の値

- 12.2.1.2 DataBinderオブジェクトのダンプ・ファイルの場所

- 12.2.1.3 DataBinderオブジェクトのダンプ・ファイルの名前

- 12.2.2 パフォーマンスの最適化

- 12.2.3 インストールの考慮事項

- 12.3 構成およびカスタマイズ

- 12.3.1 構成変数

- 12.3.1.1 アクセス制御リストおよびContent Trackerレポートのセキュア・モード

- 12.3.1.2 セキュリティ・チェック・プリファレンス変数の値

- 12.3.1.3 SctAccessLogのエントリのファイル・タイプ

- 12.3.2 Content Tracker構成変数の手動設定

- 12.3.3 外部ユーザーおよびコンテンツ・アイテムの追跡

- 12.4 サービス・コール構成

- 12.4.1 サービス・コール構成ファイルについて

- 12.4.1.1 一般的なサービス・コール・ロギング

- 12.4.1.2 拡張されたサービス・コール・トラッキング機能

- 12.4.1.3 サービス・コール構成ファイルの内容

- 12.4.1.4 ResultSetの例

- 12.4.2 Content Trackerロギング・サービスについて

- 12.4.3 サービス・コール情報の管理

- 12.4.3.1 SctServiceFilter.hdaファイルの手動編集

- 12.4.3.2 Content Trackerロギング・サービスを呼び出すための必要なDataBinderフィールドの設定

- 12.4.3.3 アプリケーションからのContent Trackerロギング・サービスの呼出し

- 12.4.3.4 IdocスクリプトからのContent Trackerロギング・サービスの呼出し

- 12.4.4 サービス・コール管理およびユーザー・インタフェース

- 12.4.4.1 サービス・エントリの追加、編集または削除

- 12.4.4.2 フィールド・マップResultSetの追加、編集または削除

- 12.5 Content Trackerのカスタマイズ

- 12.5.1 アクティビティ・メトリックのSQL問合せ

- 12.5.1.1 アクティビティ・メトリックのSQL問合せのカスタマイズ

- 12.5.2 外部ユーザーおよびコンテンツ・アイテムの追跡

- 12.6 Webビーコンの機能

- 12.6.1 Webビーコンのユースケース

- 12.6.2 Webビーコンの概要

- 12.6.3 Webビーコン・オブジェクト

- 12.6.4 Webビーコン参照

- 12.6.4.1 URL参照のフォーマット構造

- 12.6.4.2 配置および取得スキーム

- 12.6.4.3 データの取得と格納

- 12.6.5 Webビーコン参照の削減処理

- 12.6.6 ガイドラインと制限事項

- 12.6.6.1 制限事項

- 12.6.6.2 ガイドライン

- 12.6.7 Webビーコン埋込みの例

- 12.6.7.1 HTMLに埋め込む方法の例

- 12.6.7.2 JavaScriptに埋め込む方法の例

- 12.6.7.3 JavaScriptを処理する方法の例

13 Content Categorizerのカスタマイズ

- 13.1 Content Categorizerについて

- 13.2 Content Categorizerのカスタマイズ

14 カスタム・コンポーネントのダウンロード

- 14.1 カスタム・コンポーネントのダウンロードについて

- 14.2 拡張コンポーネント・マネージャを使用したコンポーネントのダウンロード

- 14.3 Oracle Technology Networkからのコンポーネントのダウンロード

15 カスタム・コンポーネントの作成

- 15.1 カスタム・コンポーネントの作成について

- 15.2 コンポーネントのリソースの作成

- 15.2.1 HTMLインクルード

- 15.2.1.1 superタグ

- 15.2.1.2 HTMLインクルード・リソースの編集

- 15.2.2 動的データ表

- 15.2.2.1 表の形式の指定

- 15.2.2.2 動的データ表リソースの編集

- 15.2.2.3 表のプロパティの指定

- 15.2.2.4 Dynamicdata Idocスクリプト関数の使用

- 15.2.3 文字列リソース

- 15.2.3.1 文字列パラメータ

- 15.2.3.2 文字列リソースの編集

- 15.2.4 動的表

- 15.2.4.1 動的表のマージ・ルール

- 15.2.4.2 動的表リソースの編集

- 15.2.5 静的表

- 15.2.5.1 静的表のマージ・ルール

- 15.2.5.2 静的表リソースの編集

- 15.2.6 問合せ

- 15.2.6.1 問合せの例

- 15.2.6.2 問合せリソースの編集

- 15.2.7 サービス

- 15.2.7.1 サービスの例

- 15.2.7.2 サービス・リソースの編集

- 15.2.8 テンプレート

- 15.2.8.1 テンプレート・ページとレポート・ページ

- 15.2.8.2 テンプレート・リソースの編集

- 15.2.9 環境リソース

- 15.2.9.1 環境リソースの例

- 15.2.9.2 環境リソースの編集

- 15.3 コンポーネント定義ファイルの作成

- 15.4 コンテンツ・サーバーの再起動によるコンポーネントの適用

16 コンポーネントのインストール

- 16.1 コンポーネントのインストールについて

- 16.2 インストールするコンポーネントのパッケージ化

- 16.3 拡張コンポーネント・マネージャを使用したコンポーネントのインストール

- 16.4 コンポーネント・ウィザードを使用したコンポーネントのインストール

- 16.5 ComponentToolユーティリティを使用したコンポーネントのインストール

17 コンポーネントのアンインストール

- 17.1 コンポーネントのアンインストールについて

- 17.2 コンポーネントのアンインストール方法

第V部 環境へのWebCenter Contentの統合

18 環境へのWebCenter Contentの統合の開始

- 18.1 統合方法について

- 18.2 Webサービスの概要

- 18.3 仮想フォルダおよびWebDAV統合

- 18.3.1 仮想フォルダ

- 18.3.2 WebDAV統合

- 18.3.2.1 WebDAVクライアント

- 18.3.2.2 WebDAVサーバー

- 18.3.2.3 WebDAVアーキテクチャ

19 統合のためのWebCenter Content Webサービスの構成

- 19.1 統合のためのWebCenter Content Webサービスの構成について

- 19.1.1 WebCenter Content Webサービス

- 19.2 Webサービス・ポリシーを使用したWebサービス・セキュリティの構成

- 19.2.1 WS-Policyを使用したWS-Securityの構成

- 19.3 SAMLサポートの構成

- 19.3.1 キーストアの構成

- 19.3.2 キーストアを使用するための、WebCenter Contentに対するJPSの構成

- 19.3.3 クライアントCSFの作成

- 19.3.4 キーストアおよびCSFを使用するためのJavaクライアントの構成

20 コンテンツ・サーバーでのJavaServer Pagesの統合

- 20.1 JSP統合について

- 20.1.1 JSP実行

- 20.1.2 Tomcat

- 20.1.3 機能

- 20.2 JSPサポートの構成

- 20.3 サンプルのページのロード

21 IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス

- 21.1 IdcCommandユーティリティについて

- 21.2 IdcCommandの設定

- 21.2.1 コマンド・ファイルの指定

- 21.2.1.1 コマンド・ファイルの構文

- 21.2.1.2 優先順位

- 21.2.1.3 特殊タグと特殊文字

- 21.2.2 構成オプションの指定

- 21.2.2.1 コマンド・ファイル

- 21.2.2.2 ユーザー

- 21.2.2.3 ログ・ファイル

- 21.2.2.4 接続モード

- 21.3 IdcCommandの実行

- 21.4 ランチャの使用

- 21.4.1 引用符のルール

- 21.4.2 計算される設定

- 21.4.3 ランチャの環境変数

- 21.4.4 ユーザー・インタフェース

- 21.4.5 ランチャの構成

- 21.4.6 構成ファイルの例

- 21.5 リモートでのサービスのコール

22 統合のためのCOM APIの使用

- 22.1 COM APIについて

- 22.2 IntradocClient OCXコンポーネントを使用したコンテンツ・サーバー・サービスのコール

- 22.2.1 OCXインタフェース

- 22.2.2 IdcClient OCXの説明

- 22.2.2.1 OCXイベント

- 22.2.2.2 OCXメソッド

- 22.2.2.3 OCXプロパティ

- 22.2.2.4 IdcClient OCXインタフェース

- 22.2.3 IdcClient OCXコントロールの設定

- 22.2.3.1 IdcClient OCXコンポーネントの設定

- 22.2.3.2 ビジュアル・インタフェースの作成

- 22.2.4 IdcClientのイベント

- 22.2.4.1 IntradocBeforeDownload

- 22.2.4.2 IntradocBrowserPost

- 22.2.4.3 IntradocBrowserStateChange

- 22.2.4.4 IntradocRequestProgress

- 22.2.4.5 IntradocServerResponse

- 22.2.5 IdcClient OCXのメソッド

- 22.2.5.1 AboutBox

- 22.2.5.2 Back

- 22.2.5.3 CancelRequest

- 22.2.5.4 DoCheckoutLatestRev

- 22.2.5.5 DownloadFile

- 22.2.5.6 DownloadNativeFile

- 22.2.5.7 Drag

- 22.2.5.8 EditDocInfoLatestRev

- 22.2.5.9 Forward

- 22.2.5.10 GoCheckinPage

- 22.2.5.11 Home

- 22.2.5.12 InitiateFileDownload

- 22.2.5.13 InitiatePostCommand

- 22.2.5.14 Move

- 22.2.5.15 Navigate

- 22.2.5.16 NavigateCgiPage

- 22.2.5.17 Refresh Browser

- 22.2.5.18 SendCommand

- 22.2.5.19 SendPostCommand

- 22.2.5.20 SetFocus

- 22.2.5.21 ShowDMS

- 22.2.5.22 ShowDocInfoLatestRev

- 22.2.5.23 ShowWhatsThis

- 22.2.5.24 StartSearch

- 22.2.5.25 Stop

- 22.2.5.26 UndoCheckout

- 22.2.5.27 ViewDocInfo

- 22.2.5.28 ViewDocInfoLatestRev

- 22.2.5.29 ZOrder

- 22.2.6 IdcClientのプロパティ

- 22.2.6.1 ClientControlledContextValue

- 22.2.6.2 HostCgiUrl

- 22.2.6.3 Password

- 22.2.6.4 UseBrowserLoginPrompt

- 22.2.6.5 UseProgressDialog

- 22.2.6.6 UserName

- 22.2.6.7 Working Directory

- 22.3 ODMA APIを使用した、デスクトップ・アプリケーションからコンテンツ・サーバーへのアクセス

- 22.3.1 ODMAクライアント

- 22.3.2 ODMAインタフェース

23 RIDCを使用したコンテンツ・サーバーへのアクセス

- 23.1 Remote Intradoc Client (RIDC)について

- 23.1.1 HttpClientライブラリ・バージョン4の使用

- 23.2 接続の初期化

- 23.3 クライアントの構成

- 23.4 ユーザーの認証

- 23.5 サービスの使用

- 23.6 接続プーリングについて

- 23.7 ストリームについて

- 23.8 バインダについて

- 23.9 コンビニエンス・クラスについて

- 23.9.1 ユーザー・セキュリティの設定

- 23.9.2 ADF接続ファサードの設定

- 23.10 RIDCフィルタについて

- 23.11 RIDC JDeveloper拡張機能の使用

- 23.11.1 RIDC拡張機能のデプロ

- 23.11.2 RIDCテクノロジが備わった新しいアプリケーションとプロジェクトの作成

- 23.11.3 接続の処理

- 23.11.4 サービス・コールの例

24 コンテンツ・サーバーのJCRアダプタの使用

- 24.1 Java Content Repositoryアダプタについて

- 24.1.1 JCRデータ・モデル

- 24.1.2 コンテンツ・サーバーのJCRアダプタ・データ・モデル

- 24.2 必要なAPIおよびランタイム・ライブラリのインストール

- 24.2.1 ADFラインタイム・ライブラリのインストール

- 24.2.2 Remote Intradoc Client (RIDC)のデプロイ

- 24.2.3 JCR APIのデプロイ

- 24.2.4 JCR統合ライブラリのインストール

- 24.2.5 XML統合ファイルのインストール

- 24.3 JCRアダプタのデプロイ

- 24.4 コンテンツ・サーバーでの通信の構成

- 24.4.1 通信方法の指定

- 24.4.2 ソケット通信(リスナー・ポート)の構成

- 24.4.3 セキュア・ソケット通信(SSL)の構成

- 24.4.4 Web通信(Webサーバー・フィルタ)の構成

- 24.4.5 ユーザー・エージェントの構成

- 24.4.6 キャッシュ設定の指定

- 24.5 コンテンツ・アイテムに関する情報の検索

- 24.6 検索索引の使用

- 24.7 ファイル・ストア・プロバイダの使用

25 WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成

- 25.1 WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成について

- 25.1.1 Webサービス・フレームワーク

- 25.1.1.1 XMLデータ

- 25.1.1.2 WSDLインタフェース

- 25.1.1.3 SOAP通信

- 25.1.1.4 UDDIレジストリ

- 25.1.1.5 DIMEメッセージのフォーマット

- 25.1.1.6 実現技術を連携させる方法

- 25.1.1.7 実装アーキテクチャ

- 25.1.1.8 .NET上の実装

- 25.1.1.9 SOAPプロトコル

- 25.2 SOAPクライアントを使用したコンテンツ・サーバーへのアクセス

- 25.2.1 Java SOAPクライアントの使用

- 25.3 SOAPを使用したコンテンツ・サーバー・サービスのコール

- 25.3.1 SOAPパケットのフォーマット

- 25.3.1.1 HTTPヘッダー

- 25.3.1.2 ネームスペース

- 25.3.1.3 ノード

- 25.3.2 特殊文字

- 25.3.3 SOAPレスポンス/リクエストを使用したサンプルのサービス・コール

- 25.3.3.1 サーバーのPing

- 25.3.3.2 新しいユーザーの追加

- 25.3.3.3 既存のユーザーの編集

- 25.3.3.4 ユーザー情報の取得

- 25.3.3.5 ユーザーの削除

- 25.3.3.6 コンテンツ・アイテムのチェックイン

- 25.3.3.7 コンテンツ・アイテムのチェックアウト

- 25.3.3.8 コンテンツ・アイテムのチェックアウトを元に戻す

- 25.3.3.9 コンテンツ・アイテム情報の取得

- 25.3.3.10 ファイルの取得

- 25.3.3.11 検索結果の取得

- 25.3.3.12 表のデータの取得

- 25.3.3.13 基準ワークフロー情報の取得

- 25.4 Active Server PageにおけるSOAPパケットの使用

- 25.4.1 サンプルのSOAPリクエスト

- 25.4.2 サンプルのActive Server Page

- 25.5 WebCenter ContentにアクセスするためのWSDLファイルの生成

- 25.5.1 WSDLファイルについて

- 25.5.1.1 WSDLファイル構造

- 25.5.2 サンプルのWSDLファイル

- 25.5.3 WSDLファイルの生成

- 25.5.4 WSDLファイルからのプロキシ・クラスの生成

- 25.6 WSDLファイルのカスタマイズ

26 DesktopTagコンポーネントのカスタマイズ

- 26.1 DesktopTagコンポーネントについて

- 26.2 DesktopTagおよびOracleCleanContentコンポーネントの有効化

- 26.3 DesktopTagを使用したコンテンツ・アイテムのチェックアウトとチェックイン

- 26.3.1 File Get操作

- 26.3.2 ファイルのチェックイン操作

- 26.4 チェックアウト済コンテンツ・アイテムへのプロパティの追加

- 26.4.1 カスタム・プロパティの表示

- 26.4.2 コンテンツ・サーバーの外部からのドキュメントのチェックイン

- 26.5 DesktopTagコンポーネントの構成

- 26.5.1 DesktopTagFormatsプロパティ

- 26.5.2 DesktopTagPrefixプロパティ

- 26.5.3 DesktopTagFieldsプロパティ

- 26.5.4 DesktopTagPrefixCustomプロパティ

- 26.5.5 DesktopTagFieldsCustomプロパティ

- 26.5.6 DesktopTagPrefixExtendedプロパティ

- 26.5.7 DesktopTagFieldsExtendedプロパティ

- 26.5.8 DefaultTaskPaneUrlプロパティ

- 26.5.9 DesktopTagLogプロパティ

- 26.5.10 DesktopTagFormatsExcludeプロパティ

第VI部 付録

A トラブルシューティング

- A.1 トラブルシューティング機能について

- A.2 サーバー・エラーの表示

- A.3 ページ・データの表示

- A.4 リソースのロードの監視

索引

Oracle® WebCenter Content

Content Server開発者ガイド

11g リリース1(11.1.1)

E10807-04(原本部品番号:E10807-04)

2011年11月

Oracle WebCenter Content Content Server開発者ガイド, 11gリリース1(11.1.1)

E10807-04

Copyright c 1994, 2011, Oracle and/or its affiliates.All rights reserved.

原本著者:  Bonnie Vaughan

原本協力著者:  Sean Cearley, Sandra Christiansen, Will Harris, Karen Johnson, Jean Wilson

寄稿者:  Sharmarke Aden, Scott Nelson, Rick Petty, David Truckenmiller, Ron van de Crommert

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

Oracle WebCenter Content Serverは細かい設定をしなくてもすぐに高度な機能が利用できますが、自社サイトの要件に合わせて様々に調整することも可能です。この開発者ガイドでは、コンテンツ・サーバー・インスタンスのカスタマイズに役立つ情報を提供します。

対象読者

このガイドは、ビジネスや組織に固有なコンテンツ管理のニーズを満たすように、Oracle WebCenter Content Serverソフトウェアをカスタマイズしたいと考えている開発者や管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middlewareドキュメント・セットの一部である、次のOracle WebCenter Content 11gリリース1(11.1.1)のドキュメントを参照してください。

- Oracle WebCenter Content Content Serverアプリケーション管理者ガイド

- Oracle WebCenter Content Idocスクリプト・リファレンス・ガイド

- Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス

- Oracle WebCenter Contentサービス・リファレンス・ガイド

- Oracle WebCenter Content Content Serverシステム管理者ガイド

詳細は、次のOracle Fusion Middleware 11gリリース1(11.1.1)のドキュメントも参照してください。

- 『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』

- Oracle Fusion Middleware Oracle WebLogic ServerのJAX-WS Webサービスの開始

- 『Oracle Fusion Middleware Oracle Web Services Manager相互運用ガイド』

- Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング

- 『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』

- Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイド

表記規則

このマニュアルの表記規則は、次のとおりです。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

新機能および変更された機能

この項では、Oracle WebCenter Contentの新機能および変更された機能について説明します。これらの機能は、Oracle WebCenter Content Server開発者向けに書かれたこのガイドの対象範囲です。

11g リリース1(11.1.1)の新機能

11gリリース1(11.1.1)の新機能は次のとおりです。

- このガイドには、次のドキュメントにすでに記載されている情報も含まれています。

- Dynamic Server Pagesガイド

- Stellent Developer's Kit(SDK)のスタート・ガイド

- Idcコマンド・リファレンス・ガイド

- コンテンツ・サーバー・インタフェースの変更

- Oracle Fusion Middleware Content Server JCRアダプタ・ガイド

- Oracle Fusion Middleware Remote Intradoc Client (RIDC)開発者ガイド

- WSDLジェネレータおよびSOAPの使用方法

- コンポーネントの処理

- Webサービス
WebCenter Contentでは、Oracle WebLogic ServerのWebサービスを使用しています。詳細は、第19章「統合のためのWebCenter Content Webサービスの構成」を参照してください。

- ComponentTool
コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ツールを実現するために、ComponentToolユーティリティが追加されました。詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

- Oracle WebCenter Content Serverのデプロイメント: WebLogic Serverのドメインに、コンテンツ・サーバーがWebCenter Contentとともにデプロイされました。これにより、コンテンツ・サーバーの構成と管理が変更されました。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

11g リリース1(11.1.1)の変更された機能

11gリリース1(11.1.1)の変更点は次のとおりです。

- Oracle WebCenter Contentのディレクトリおよびファイル: WebCenter Content 11gリリース1(11.1.1)は、Oracle WebCenter Contentの完全メディア・インストレーションの一部として提供され、WebCenter Contentのディレクトリおよびファイルが付属しています。WebCenter Content 11gインスタンスのディレクトリ構造は、Oracle Universal Content Management 10gインスタンスとは異なります。WebCenter Content構造を理解して操作するうえで重要な用語およびパス名の説明については、第1.1.1.1項「WebCenter Contentのディレクトリの用語」を参照してください。

- SOAP: SOAPはOracle WebLogic Serverに同梱されており、Oracle WebCenter Contentにはありません。

- Webフォーム・エディタ: Webフォーム・エディタのユーザー・インタフェースとFCKEditorはサポートされていません。

- CISが非推奨に: Content Integration Suite (CIS)が非推奨になりました。開発者およびシステム統合者は、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)を使用します。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。詳細は、第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。

- Oracle Enterprise Content Management Suite (Oracle ECM)がOracle WebCenter製品スタックの一部となり、最も完全に統合された企業コンテンツ管理のオープン・プラットフォームを提供するようになりました。それに応じて、Oracle WebCenter Content Serverのソフトウェアおよびドキュメントも再ブランド化されました。

第I部

Oracle WebCenter Content Serverのカスタマイズの開始

この部では、Oracle WebCenter Content Serverのカスタマイズの概要を示し、カスタマイズに利用可能なツールおよびリソースについて説明します。この部では、Oracle Fusion Order Demoサンプル・アプリケーションについても説明します。

第I部は、次の章で構成されています。

- 第1章「Oracle WebCenter Content Serverの概要」

- 第2章「Oracle Fusion Order Demoサンプル・アプリケーションの概要」

1 Oracle WebCenter Content Serverの概要

この章では、Oracle WebCenter Content Serverのカスタマイズの概要を示し、カスタマイズに必要なツールおよび利用可能なリソースについて説明します。

この章では、次の項目について説明します。

- 第1.1項「コンテンツ・サーバーのアーキテクチャの概要」

- 第1.2項「カスタマイズのタイプ」

- 第1.3項「カスタマイズの計画」

- 第1.4項「コンテンツ・サーバーのカスタマイズで推奨されるスキルとツール」

- 第1.5項「コンテンツ・サーバーの動作」

トラブルシューティングのヒントについては、付録A「トラブルシューティング」を参照してください。

1.1 コンテンツ・サーバーのアーキテクチャの概要

カスタマイズ・プロジェクトを開始する前に、コンテンツ・サーバーのアーキテクチャおよびその動作について理解しておく必要があります。カスタマイズを効率的かつ効果的に作成するには、Oracle WebCenter Contentのディレクトリとファイル、利用可能なリソース、およびコンテンツ・サーバーの動作を理解しておく必要があります。

WebCenter ContentのWebユーザー・インタフェースであるコンテンツ・サーバーは、アプリケーションとしてOracle WebLogic Serverのドメインにデプロイされています。コンテンツ・サーバーの機能については、第1.5項「コンテンツ・サーバーの動作」を参照してください。

コンテンツ・サーバーは、IBM WebSphere Application Serverにデプロイすることもできます。詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドのIBM WebSphereでのOracle WebCenter Contentの管理に関する項を参照してください。

1.1.1 WebCenter Contentのディレクトリおよびファイル

カスタム・コンポーネントまたは動的サーバー・ページを作成する場合は、次の各ディレクトリに格納されているWebCenter Contentのファイルを主に操作します。

- bin

- config

- components

- resources

- weblayout

注意:
これらのファイルでデフォルトの変数を変更すると、WebCenter Contentが正常に動作しなくなる可能性があります。構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

1.1.1.1 WebCenter Contentのディレクトリの用語

Oracle WebCenter Contentのドキュメントでは、Oracle WebCenter Contentのインストール、構成およびデプロイに関連付けられたディレクトリ内の変数を指すときに、次の用語を使用しています。

- IdcHomeDir: この変数は、WebCenter ContentのOracleホームにあるucm/idcディレクトリを参照しており、このディレクトリには、WebCenter Contentサーバー・メディアが置かれています。サーバー・メディアは、Oracle WebCenter Content Server、Oracle WebCenter Content: Inbound RefineryまたはOracle WebCenter Content: Recordsを実行できます。これは本質的には、読取り専用のディレクトリです。デフォルトの場所はWC_CONTENT_ORACLE_HOME/ucm/idcです。デフォルトの場所の変数部分は変更してもかまいませんが、パスはucm/idcから変更しないでください。

- DomainHome: アプリケーション・サーバー上で実行するためにOracle WebCenter Contentアプリケーションがデプロイされる、ユーザー指定のディレクトリ。DomainHome/ucm/short-product-id/binディレクトリには、intradoc.cfgファイルおよび実行可能ファイルがあります。DomainHomeのデフォルトの場所はMW_HOME/user_projects/domains/base_domainですが、このパスとドメイン名(base_domain)は、アプリケーション・サーバーにOracle WebCenter Contentアプリケーションをデプロイするときに変更できます。

- short-product-id: アプリケーション・サーバーにデプロイされているOracle WebCenter Contentアプリケーションのタイプの略称。この名前は、コンテキスト・ルート(HttpRelativeWebRoot構成のデフォルト値)として使用されます。使用される値は次のとおりです。

- cs (Content Server)

- ibr (Inbound Refinery)

- urm (Records)

- IntradocDir: アプリケーション・サーバーにデプロイされているOracle WebCenter Contentアプリケーションの一部であるコンテンツ・サーバーのインスタンスに固有の構成ファイルおよびデータファイル用のルート・ディレクトリ。このIdocスクリプト変数は、Content Server (cs)、Inbound Refinery(ibr)、Records(urm)いずれかのタイプのコンテンツ・サーバーのインスタンスに対して構成されます。IntradocDirのデフォルトの場所はDomainHome/ucm/short-product-idですが、IntradocDirディレクトリは、(intradoc.cfgファイルで定義されているように)別の場所にあってもかまいません。指定したディレクトリは、インスタンス・ディレクトリへの絶対パスで、特定のサーバーまたはノードに固有である必要があります。これらのディレクトリ・ファイルの中には、起動ファイル(intradoc.cfgおよび実行可能ファイル)が含まれています。

1.1.1.2 binディレクトリ

binディレクトリは、コンテンツ・サーバーの起動ファイルのルート・ディレクトリです。ここには、intradoc.cfgファイルと、コンテンツ・サーバーのサービス、アプレットおよびユーティリティを実行する実行可能ファイルが含まれています。これはDomainHome/ucm/short-product-id/binにあり、そこのshort-product-idによって、Content Server(cs)、Inbound Refinery(ibr)、Records(urm)のいずれが対象であるかが指定されます。binディレクトリの内容を表1-1に示します。

表1-1 起動ファイルのbinディレクトリの内容

要素

説明

実行可能ファイル

サービス

- IdcServer

- IdcServerNT

アプレット

- IntradocApp (管理ツールをすべて起動)

ユーティリティ

- BatchLoader

- Installer

- IdcAnalyze

- ComponentWizard

- SystemProperties

- IdcCommand

intradoc.cfgファイル

コンテンツ・サーバーのサービス、アプレットおよびユーティリティの設定を含む構成ファイル

注意:
コンテンツ・サーバーが自動サービスとして設定されているときに、コンテンツ・サーバーのサービス(IdcServerまたはIdcServerNT)をコマンドラインから起動しようとすると、このポートはリスニングできず、すでに使用中ですというエラー・メッセージが表示されます。

intradoc.cfgファイルは、ディレクトリ、インターネット、Inbound Refineryの設定など、コンテンツ・サーバーのシステム変数を定義するために使用します。これらの変数のうちのいくつかは、WebCenter Contentのシステム・プロパティ・ユーティリティを使用して設定できます。例1-1は、一般的なintradoc.cfgファイルを示しています。

例1-1 lintradoc.cfgファイル

<?cfg jcharset="Cp1252"?>
#Content Server Directory Variables
IntradocDir=C:/oracle/idcm1/
WebBrowserPath=C:/Program Files/Internet Explorer/iexplore.exe
CLASSPATH=$COMPUTEDCLASSPATH;$SHAREDDIR/classes/jtds.jar

#Additional Variables
HTMLEditorPath=C:/Program Files/Windows XP/Accessories/wordpad.exe
JAVA_SERVICE_EXTRA_OPTIONS=-Xrs

1.1.1.3 configディレクトリ

configディレクトリは、IntradocDir/configにあります。IntradocDirのデフォルトの場所はDomainHome/ucm/short-product-idですが、IntradocDirディレクトリは、(intradoc.cfgファイルで定義されているように)別の場所にあってもかまいません。configディレクトリの内容を表1-2に示します。

表1-2 configディレクトリの内容

ファイル

説明

config.cfg

システム構成変数を定義します。

config.cfgファイルは、コンテンツ・サーバー・システムのグローバル変数を定義するために使用します。これらの変数のうちのいくつかは、WebCenter Contentのシステム・プロパティ・ユーティリティを使用するか、または管理サーバー一般構成ページで変数を変更して設定できます。例1-2は、一般的なconfig.cfgファイルを示しています。

例1-2 config.cfgファイル

<?cfg jcharset="Cp1252"?>
#Content Server System Properties
IDC_Name=idcm1
SystemLocale=English-US
InstanceMenuLabel=JeanWTestSystem
InstanceDescription=idcm1
SocketHostAddressSecurityFilter=127.0.0.1|10.10.1.14

#Database Variables
IsJdbc=true
JdbcDriver=com.internetcds.jdbc.tds.Driver
JdbcConnectionString=jdbc:freetds:sqlserver://jwilsonnote:1433/oracle1;charset=UTF8;TDS=7.0
JdbcUser=sa
JdbcPassword=UADle/+jRz7Fi8D/VzTDaGUCwUaQgQjKOQQEtI0PAqA=
JdbcPasswordEncoding=Intradoc
DatabasePreserveCase=0

#Internet Variables
HttpServerAddress=jwilsonnote
MailServer=mail.example.com
SysAdminAddress=sysadmin@example.com
SmtpPort=25
HttpRelativeWebRoot=/oracle/
CgiFileName=idcplg
UseSSL=No
WebProxyAdminServer=true
NtlmSecurityEnabled=No
UseNtlm=Yes

#General Option Variables
EnableDocumentHighlight=true
EnterpriseSearchAsDefault=0
IsDynamicConverterEnabled=0
IsJspServerEnabled=0
JspEnabledGroups=

#IdcRefinery Variables

#Additional Variables
WebServer=iis
UseAccounts=true
IdcAdminServerPort=4440
SearchIndexerEngineName=DATABASE
VIPApproval:isRepromptLogin=true
Vdk4AppSignature=SF37-432B-222T-EE65-DKST
Vdk4AppName=INTRANET INTEGRATION GROUP
IntradocServerPort=4444

1.1.1.4 componentsディレクトリ

IntradocDir/data/componentsディレクトリには、システム・コンポーネントを構成するためにコンテンツ・サーバーが使用するファイルが含まれています。componentsディレクトリの内容を表1-3に示します。

表1-3 data/componentsディレクトリの内容

ファイル

説明

idcshort-product-id_components.hda

コンテンツ・サーバー・システムに追加されているコンポーネント、およびそれらが有効になっているか無効になっているかを識別します。例: idccs_components.hda。

component.hda

コンポーネントの構成ステータスを識別します。

helpというコンポーネントの構成ステータスを定義するcomponent.hdaファイルを例1-3に示します。

例1-3 component.hdaファイル

<?hda version="11.1.1.2.0-dev idcprod1 (091209T125156)" jcharset=UTF8 encoding=utf-8?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
@end
@ResultSet Components
2
name
location
help
components/help/help.hda
@end

1.1.1.5 resourcesディレクトリ

IdcHomeDir/resourcesディレクトリには、adminとcoreという2つのディレクトリが含まれています。

resources/coreディレクトリには、Webページをアセンブルするためにコンテンツ・サーバーが使用するファイルが含まれています。resources/coreディレクトリのサブディレクトリを表1-4に示します。

表1-4 resources/coreディレクトリの内容

サブディレクトリ

説明

config

コンテンツ・サーバーのベース構成ファイルを格納しています。

idoc

IdocScriptのdynamichtml定義およびdynamicdata定義を格納しています。

install

インストーラおよび関連アプリケーションによって使用されるファイルを格納しています。

javascript

公開エンジンによって処理され、weblayoutディレクトリ内でRAW JavaScriptファイルとなるファイルを格納しています。

jspserver

jspserver XMLファイルを格納しています。

lang

コンテンツ・サーバーの、ローカライズされた文字列定義を格納しています。

reports

コンテンツ・サーバーのレポートのテンプレートを格納しています。

resources

コンテンツ・サーバーのリソース定義(問合せ、ページ・リソース、サービスなどのリソース・データ)を格納しています。

tables

IdocScriptのリソース表定義を格納しています。

templates

コンテンツ・サーバーのすべてのページ(レポートは除く)のテンプレートを保持しています。

resources/adminディレクトリのサブディレクトリを表1-5に示します。

表1-5 resources/adminディレクトリの内容

サブディレクトリ

説明

idoc

IdocScriptのdynamichtml定義およびdynamicdata定義を格納しています。

tables

IdocScriptのリソース表定義を格納しています。

templates

コンテンツ・サーバーのすべてのページ(レポートは除く)のテンプレートを保持しています。

1.1.1.6 weblayoutディレクトリ

DomainHome/ucm/short-product-id/weblayoutディレクトリには、コンテンツ・サーバーのWebサイトの各種ページで表示するためにWebサーバーで利用可能なファイルが含まれています。weblayoutディレクトリのサブディレクトリを表1-6に示します。

表1-6 weblayoutディレクトリの内容

サブディレクトリ

説明

groups

Web で表示可能なコンテンツ・アイテムおよび動的サーバー・ページを格納しています。

images

アイコンやホーム・ページのグラフィックなどのイメージを格納しています。

resources

レイアウト、スキンおよびスキーマ情報を格納しています。

1.1.2 リソース

リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。これには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。

リソースはコンテンツ・サーバー・ソフトウェアの重要な部分なので、カスタム・コンポーネントまたは動的サーバー・ページを作成しようとする前に精通しておく必要があります。リソース・ファイルは、コンポーネント・ウィザードを使用して作成、編集または削除できます。コンポーネント・ウィザードは、カスタム・リソースを作成するときの開始ポイントとして使用することもできます。

リソースは異なるカテゴリに分類され、これについては表で説明します。この表に一覧表示されている最初の5つのタイプは、リソース・タイプのリソースとも呼びます。これらのリソース・タイプを表1-7に示します。

表1-7 リソース・タイプ

リソース・タイプ

説明

標準的なリソースの例

HTMLインクルード

コンテンツ・サーバーの複数のWebページで使用されるHTMLマークアップおよびIdocスクリプト・コードの断片を定義します。

IdcHomeDir/resources/core/idoc/std_page.idoc

動的データ表

HTML表定義、インタフェース・メニュー・アクション、またはメタデータ・フィールドに関する情報をロードするIdocスクリプト内から、あるいは、SharedObjectにロードされた静的表に対する代替としてJavaコード内から、dynamicdataインクルードのデータの表を定義します。

IdcHomeDir/resources/core/idoc/std_data.idoc

文字列

ユーザー・インタフェースおよびエラー・メッセージ用にローカライズされた文字列を定義します。

IdcHomeDir/resources/core/lang/cs_strings.htm

動的表(HDAフォーマット)

動的な(頻繁に変更される)コンテンツをコンテンツ・サーバーに表形式で提供します。

IdcHomeDir/resources/core/templates/templates.hda

静的表(HTMLフォーマット)

静的な(めったに変更されない)コンテンツをコンテンツ・サーバーに表形式で提供します。

IdcHomeDir/resources/core/tables/std_locale.htm

問合せ

データベース問合せを定義します。

IdcHomeDir/resources/core/tables/query.htm

サービス

コンテンツ・サーバーで実行できるサービスのスクリプトを定義します。

IdcHomeDir/resources/core/tables/std_services.htm

テンプレート

特定のWebページをアセンブルするためにコンテンツ・サーバーが使用するコードを含むテンプレートを定義します。

IdcHomeDir/resources/core/templates/checkin_new.htm

環境

コンテンツ・サーバーの構成設定を定義します。

IntradocDir/config/config.cfg

1.2 カスタマイズ・タイプ

コンテンツ・サーバーでは、主に3種類の変更を行うことができます。

- 製品のルック・アンド・フィールの変更
コンテンツ・サーバー・インタフェースのルック・アンド・フィールをカスタマイズして、組織の仕様に合わせることができます。インタフェースの変更は、標準のコンテンツ・サーバーWebページに表示されるアイコンを置換するような簡単なものから、インタフェース全体を再設計するような複雑なものまで可能です。

- 製品の機能の変更
製品の機能を変更することによって、コンテンツ・サーバーをビジネスや組織の機能に合わせることができます。たとえば、デフォルトの日付やタイムスタンプを変更したり、チェックイン動作の機能を変更したりできます。

- 環境への製品の統合
シェル・スクリプト、SOAP、J2EE、JSPおよびクラスタを使用して、コンテンツ・サーバーをサイトの現在の環境により緊密に統合できます。

1.3 カスタマイズ計画

カスタマイズを開始する前に、カスタマイズを行う理由を明確にすることが重要です。たとえば、企業ブランドを追加するには、レイアウト・サンプルの変更を使用して追加できます。また、セキュリティ機能を変更するには、デフォルトのセキュリティ設定を変更するためのコンポーネントを使用できます。

多くの場合、カスタマイズは、コンテンツ・サーバーを組織のビジネス・プラクティスに適合させるために行います。ビジネス・プロセスを評価した後、コンテンツ・サーバーをカスタマイズする前にプロシージャに軽微な変更を加えたほうが効率的だとわかることもよくあります。

カスタマイズは、主に次の6つの手順で行います。

1. カスタマイズする理由を特定します。
企業パーソナライズを行いますか。ナビゲーション・オプションや素材を表示する、より適切な方法があるかどうかを検討します。明らかになったニーズのタイプに応じて、どのツールを使用するのが最適であるかを判断できます。

多くの場合、表示に関する詳細を変更することで、ユーザーの満足度を高めることができます。レイアウト、色、イメージなどのアイテムを変更することによって、ユーザーの要望に対応できることがよくあります。

2. カスタマイズを慎重に計画します。
カスタマイズによってコンテンツ・サーバー環境がどのように変更されるかについて、周辺的な影響も含めて検討します。すべてのカスタマイズは、サイトの本番環境とは切り離してテスト環境で行う必要があります。

3. 使用可能なソリューションがあるかどうかを確認します。
サポートWebサイトのサンプルに、様々なタイプのカスタマイズが用意されています。既存のコンポーネントを少し編集すると、使用できるようになる場合があります。そのままの状態で使用できるサンプルが数多く提供されています。これらは、WebCenter Contentの機能を例示、強化または拡張するコンポーネントやファイルです。

4. 問題を評価し、その問題を解決することがどの程度必要であるかを評価します。
問題によっては、解決に要する労力が結果に見合わないほど大きい場合があります。カスタマイズでなく、ビジネス・プラクティスに軽微な変更を加えることが必要となることがあります。

5. 個別の環境でカスタマイズを完全にテストします。
可能な場合は、エンド・ユーザーがテストに参加するように調整します。テストがリリースのすべての条件を満たすと、ユーザーに変更内容とその実装方法を通知します。

6. 作成したカスタマイズをドキュメント化します。
すべての変更は、実際のカスタマイズ内においても（たとえば、動的サーバー・ページやコンポーネント内にコメントなどとして）、個別のREADMEドキュメントとしても、できるかぎり完全にドキュメント化する必要があります。このドキュメントには、後になってカスタマイズに追加するために必要となる可能性のある人のために、履歴監査証跡が記載されています。

1.4 コンテンツ・サーバーのカスタマイズで推奨されるスキルとツール

コンテンツ・サーバーでは、高度な機能を提供するために様々なテクノロジが組み合されています。コンテンツ・サーバーを変更するには、これらのテクノロジの一部またはすべてについて一定の経験およびスキルが必要です。

コンテンツ・サーバーをカスタマイズするために必要な技術的なスキルは、カスタマイズの複雑さによって異なる場合があります。たとえば、多くのカスタマイズは、HTMLおよびIdocスクリプトの知識で実行できます。

このリストでは、コンテンツ・サーバーの変更に必要となる可能性のあるテクノロジおよび経験を、重要度の高いものから順に説明します。

- コンテンツ・サーバーのアーキテクチャ
システムのカスタマイズを開始する前に、コンテンツ・サーバーの動作とコンポーネントおよび動的サーバー・ページの機能を十分に理解しておく必要があります。

- HTMLおよびカスケード・スタイル・シート(CSS)
コンテンツ・サーバーWebページのテンプレートを変更するには、HTMLおよびCSSについて十分に理解する必要があります。テンプレートでHTMLを使用する場合、作業は複雑ではありませんが、テンプレートではHTML表を常時使用し、フォームを頻繁に使用します。std_page.idocファイルとstd_css.idocファイルには、デフォルトのテンプレートのルック・アンド・フィール（フォントやレイアウトなど）を制御するためのカスケード・スタイルシートが含まれています。

- Idocスクリプト
Idocスクリプトは、コンテンツ・サーバーのカスタム・サーバー側スクリプト言語です。ほぼすべてのコンテンツ・サーバーWebページにはIdocスクリプト・コードが含まれており、様々なページ要素を処理するためのメソッドが提供されています。

- JavaScript
コンテンツ・サーバーのほとんどのページの内部コンテンツではJavaScriptを使用していませんが、「検索」「チェックイン」「更新」の各ページは顕著な例外です。これらのページのかわりに呼び出されるカスタマイズを作成する前に、JavaScriptについて理解しておく必要があります。また、レイアウトを変更するには、JavaScriptを理解する必要があります。レイアウトの変更は、設計およびナビゲーションにおいてJavaScriptおよびカスケーディング・スタイルシートに大きく依存します。

- Structured Query Language(SQL)
コンテンツ・サーバーでは、データベースに対する問合せを実行するためにSQLを使用しています。SQLの知識があれば、標準的な問合せの理解および独自のカスタム問合せの作成に役立つ場合があります。

- Javaプログラミング
コンテンツ・サーバーはJavaクラスとともに実装されます。基礎となる機能を変更する前に、Javaおよびコンテンツ・サーバーのJavaクラス・ファイルについて十分に理解しておく必要があります。ただし、Javaを使用しなくても、製品を広範にカスタマイズできます。

- その他のプログラミング
複雑なカスタマイズまたはWebCenter Contentと他のシステムとの統合を行う場合、Visual Basic、COM、.Net、C++、VBScriptなどの他のツールの経験が役立つ場合があります。

コンテンツ・サーバーをカスタマイズする場合、次のツールが有用な場合があります。

- テキスト・エディタ
ほとんどの製品カスタマイズは、Microsoft WordPadやviなどの通常のテキスト・エディタを使用して実行できます。

- HTMLエディタ

注意:
グラフィカルHTMLエディタではソースのHTMLを頻繁に変更するため、Idocスクリプトのタグが、コンテンツ・サーバーで認識されなくなった文字列に変換される可能性があります。グラフィカル・エディタを使用する場合は、非グラフィカル・モードで編集してください。

HTMLページの操作にはグラフィカルHTMLエディタのほうを使用する場合は、非グラフィカル・モードを使用して編集します。

- 複数のブラウザ
コンテンツ管理システムとのインタフェースで使用される可能性があるWebブラウザの複数のバージョンで、カスタマイズをテストする必要があります。Internet Explorer、FirefoxおよびChromeでは、コンテンツの表示は同じではなく、同じブラウザの異なるバージョンで異なる動作が示される場合があります。

- JavaScriptデバッガ
JavaScriptデバッガによって、JavaScript開発のタスクが簡略化される場合があります。数多くのJavaScriptデバッガがインターネットからダウンロード可能です。

- Java用の統合開発環境(IDE)
カスタマイズの際にJavaコードの開発が必要になる場合は、適切なJava開発環境が必要です。

1.5 コンテンツ・サーバーの動作

WebCenter Contentをカスタマイズする前に、Oracle WebCenter Content Serverの動作について理解しておく必要があります。

- 起動動作

- リソースのキャッシング

- ページ・アセンブリ

- データベースとの対話

- ローカライズされた文字列の解決

- アプリケーション統合

コンテンツ・サーバーの概要については、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンテンツ・サーバー管理の概要に関する項を参照してください。

1.5.1 起動動作

起動時に、コンテンツ・サーバーのインスタンスでは内部初期化が実行され、次のアイテムがロードされます。

1. 構成変数

2. 標準的なテンプレート、リソースおよびレポート

3. カスタム・コンポーネント(テンプレート、リソース、構成変数、レポートなど)

図1-1に、起動時にコンテンツ・サーバーで実行される4つの手順を示します。これらの手順の詳細は、第1.5.1.1項「起動手順」で説明します。

図1-1 コンテンツ・サーバーの起動動作

「図1-1 コンテンツ・サーバーの起動動作」の説明

1.5.1.1 起動手順

起動時にコンテンツ・サーバーで実行される手順は次の4つです。

1. 内部初期化を行います。
コンテンツ・サーバーで初期化が行われると、コンテンツ・サーバーのJavaクラス・ファイルが読み取られ、Java仮想マシン(JVM)が起動します。DomainHome/ucm/short-product-id/intradoc.cfgファイル内に変数があれば、それも初期化されます。

2. 構成変数をロードします。
初期化後、コンテンツ・サーバーでは、IntradocDir/configディレクトリにあるconfig.cfgファイルがロードされます。このファイルには、システム・プロパティと構成変数が格納されており、それらは名前と値のペア(SystemLocale=English-USなど)で定義されています。

構成ファイル内に含まれているデフォルト情報は、Oracle WebCenter Contentのインストール・プロセスで提供されたものですが、このファイルは次のような様々な方法で変更できます。

- 管理サーバー一般構成ページ(「管理」メニューからアクセス可能)を使用する

- Oracle WebCenter Contentインストール(UNIXオペレーティング・システム)のbinディレクトリ内にある実行可能ファイルSystemPropertiesを実行する

- 構成ファイルを直接編集する

- カスタム・コンポーネントを使用する

config.cfgファイルを変更するたびに、コンテンツ・サーバーを再起動して変更内容を有効にする必要があります。

3. 標準的なリソース、テンプレートおよびレポートをロードします。
コンテンツ・サーバーが正しく機能するようにするには、数多くの標準的なリソース、テンプレートおよびレポートをロードする必要があります。構成設定のロード後、コンテンツ・サーバーでは、IdcHomeDir/resources/core/templates/templates.hdaファイルおよびIdcHomeDir/resources/core/reports/reports.hdaファイルのエントリが読み取られます。これらのファイルからコンテンツ・サーバーに、どのテンプレートをロードすべきかが指示されます。テンプレートおよびレポートのページで標準的なリソースが参照されれば、ロードしたテンプレートによって、そのリソースがロードされます。

4. カスタム・コンポーネントをロードします。
コンテンツ・サーバーは、IntradocDir/data/components/idcshort_product_id_components.hdaに一覧表示されているコンポーネントのすべてをロードし、さらに、IdcHomeDir/components/ComponentName/ComponentName.hdaにあるシステム・コンポーネント、またはIntradocDir/custom/ComponentName/ComponentName.hdaにあるカスタム・コンポーネントをロードします。

1.5.1.2 構成のロードの影響

複数の構成ファイルのロードの順序が持つ影響を理解しておくことが重要です。それは、1つの変数が複数のファイルで設定されている場合、最後にロードされた変数が優先されるためです。たとえば、IntradocDir/data/components/component_name/config.cfgファイルより前にIntradocDir/config/config.cfgファイルがロードされた場合、config/config.cfgファイルで設定された変数の値が、component_name/config.cfgによって変更されることがあります。

ファイルは、次に示す順序でロードされます(各コンポーネントにすべてのファイルが存在しているわけではありません)。

1. DomainHome/ucm/short-product-id/bin/intradoc.cfg

2. IntradocDir/config/config.cfg

3. DomainHome/ucm/short-product-id/custom/component_name/*_environment.cfg
このファイルがないコンポーネントもあれば、名前がenvironment.cfgになっているファイルもあります。

4. IntradocDir/data/components/component_name/install.cfg

5. IntradocDir/data/components/component_name/config.cfg

6. DomainHome/ucm/short-product-id/bin/intradoc.cfg
このファイルは、起動の最後に再度読み取られ、他の設定より優先されるものが許可されます。

たとえば、リストにあるファイルのそれぞれで同じ変数が設定された場合、intradoc.cfgファイルが最後にロードされたため、そのファイルにある変数の値が優先されます。

構成を表示する場合は、GET_SYSTEM_AUDIT_INFOサービスを使用して、すべての構成エントリ、およびそれらが設定された場所を表示できます。

コンポーネントの変数を変更する場合は、拡張コンポーネント・マネージャの「コンポーネント構成の更新」領域を使用できます。この領域には、component_name/config.cfgファイルで編集可能な構成のあるコンポーネントのドロップダウン・リストが表示されます。コンポーネントを選択して「更新」をクリックすると、コンテンツ・サーバーの「コンポーネント構成の更新」ページに進みます。

構成ファイルは手動で編集することもできます。拡張コンポーネント・マネージャの「コンポーネント構成の更新」リストにコンポーネントが表示されていない場合は、構成ファイルのいずれかで直接変更できます。

1.5.2 リソースのキャッシング

コンテンツ・サーバーでは、テンプレート・ページおよびリソースのキャッシングが次のように処理されます。

- テンプレート・ページおよびリソースは、コンテンツ・サーバーにロードされると、ページ表示が迅速になるようにメモリーにキャッシュされます。

- テンプレート・ページ、レポート・ページまたはHTMLインクルード・リソースを変更した場合、あるいは動的サーバー・ページに対するリビジョンにチェックインした場合は、変更内容は即座に有効となります。
関連付けられたWebページに対する次回の要求、またはページのリフレッシュによって、変更内容が反映され、新しい情報がキャッシュされます。この処理が行われるのは、ページ要求ごとにページが動的にアセンブルされるためです。構成変数DisableSharedCacheCheckingを設定することによって、この動作を無効にして、パフォーマンスを向上させることができます。

- それ以外のコンポーネント・ファイル(サービス、問合せ、環境変数、表、idcshort-product-id_components.hdaファイル、template.hdaファイルなど)を変更した場合は、コンテンツ・サーバーを再起動して、変更内容を有効にする必要があります。そのような変更が即座に実装された場合、コンテンツ・サーバーが正しく動作しなくなる可能性があります。
文字列の変更後にコンテンツ・サーバーを再起動する必要はありません。ただし、「管理アクション」ページの「Webレイアウト公開」領域で、「文字列と動的ファイルのパブリッシュ」または文字列、静的ファイルおよび動的ファイルのパブリッシュをクリックして、ww_strings.jsファイルを再パブリッシュする必要があります。詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

1.5.3 ページ・アセンブリ

コンテンツ・サーバーでは、動的Webページをアセンブルするために、IdcHomeDir/resourcesディレクトリに格納されているファイルにある次の情報を使用します。

- Webページの構造と書式
この構造と書式は、特定のHTMLテンプレート・ファイルで定義されています。テンプレート・ファイルは、主にresources/core/templatesディレクトリに格納されていますが、resources/core/reportsディレクトリおよびresources/admin/templatesディレクトリに格納されているテンプレートもあります。

- テンプレートで参照されるリソース
これらのリソースは、resourcesディレクトリのサブディレクトリ内の.htmファイルおよび.idocファイルにあります。リソースには、HTMLおよびIdocスクリプトのマークアップ、ローカライズされた文字列、データベースからデータを収集する問合せ、および情報を条件付きで書式設定する特殊コードが考えられます。

原則として、それぞれのWebページには、次のリソースが含まれます。

- ページの標準的なヘッダー

- ページの標準的な先頭

- ページの標準的な末尾

コンテンツ・サーバーのリソースはすべて起動時にメモリーにキャッシュされるため、コンテンツ・サーバーには、ページに表示される標準的な断片の定義があります。さらにコンテンツ・サーバーでは、標準的なリソースと、テンプレートで指定された一意のリソースを組み合せて、Webページを作成します。

動的サーバー・ページの場合は、テンプレート・ページとカスタム・リソース・ファイルがコンテンツ・サーバーにチェックインされます。これらのページのいずれかがWebブラウザによって要求されると、コンテンツ・サーバーでは、ファイル拡張子が動的サーバー・ページと認識され、それによって特殊な処理が可能となります。その時点では、ページ・アセンブリ・プロセスは、標準的なプロセスと本質的に同じです。ただし例外として、そのページでは、resourcesディレクトリ内の標準的なリソースと、コンテンツ・サーバーにチェックインされたカスタム・リソースの両方が使用できます。

1.5.4 データベースとの対話

Oracle Databaseなど、一部のデータベースでは、すべての列名が大文字で返されます。したがって、コンテンツ・サーバーがこれらのデータベースから問合せ結果を受け取ると、大文字からコンテンツ・サーバーで使用される値に、列名をマップする必要があります。

このケース・マッピング問題では、あるデータベースを使用するコンテンツ・サーバーのインスタンス用に作成されたカスタム・コンポーネントが、別のデータベースを使用するコンテンツ・サーバーのインスタンスでは正しく機能しない場合が考えられます。

列名をマップするために、IdcHomeDir/resources/core/resources/upper_clmns_map.htmファイルには、ColumnTranslationというマッピング表が含まれています。WebCenter Contentデータベースのフィールドでないフィールドにアクセスするコンポーネントを作成するとき(たとえば、WebCenter Contentデータベース内のカスタム表にアクセスするコンポーネントを作成する場合)に、このファイルに問合せ値を追加します。

upper_clmns_map.htmファイルの使用については、第5章「システム設定の変更」を参照してください。

1.5.5 ローカライズされた文字列の解決

ローカライズされた文字列とは、ユーザー・インタフェースとエラー・メッセージを、ユーザーのロケールで指定された言語で表示する手段です。コンテンツ・サーバーでは、ベース言語の文字列リソース・ファイルをロードし、サポートされているあらゆる言語のリソース・ファイルもロードします。ハードコード化されたテキストを表示するかわりに、テンプレート・ページ、アプレットおよびエラー・メッセージがこれらのリソース・ファイル内の文字列IDを参照し、この文字列IDはさらに、ユーザーのロケール情報を含むExecutionContextを使用して解決されます。

1.5.6 アプリケーション統合

コンテンツ・サーバーは、コンテンツ中心のWebサイトに向けたコンテンツ管理ソリューションの役割を果たすだけでなく、スケーラブルなコンテンツ管理インフラストラクチャも提供しており、このインフラストラクチャは、数多くの多様な環境やプラットフォームで複数のエンタープライズ・アプリケーションをサポートします。この統合ソリューションにより、他のエンタープライズ・アプリケーションは、コンテンツ管理システムで管理されているコンテンツにアクセスできます。また、これらのアプリケーションには、全文検索やメタデータ検索、ライブラリ・サービス、ワークフロー、サブスクリプション通知、幅広く品揃えされている統合メソッドを通じたコンテンツ変換機能などの重要なコンテンツ管理機能が提供されています。

コンテンツ・サーバーとエンタープライズ・アプリケーションの統合については、第18章「環境へのWebCenter Contentの統合の開始」を参照してください。

2 Oracle Fusion Order Demoサンプル・アプリケーションの概要

この章では、Oracle Fusion Order Demoサンプル・アプリケーション、その設定方法、およびSuppliersモジュールの実行方法について説明します。

この章では、次の項目について説明します。

- 第2.1項「Fusion Order DemoおよびSuppliersモジュールについて」

- 2.2項「Fusion Order Demoアプリケーションの設定」

- 第2.3項「Suppliersモジュールの実行」

この章で示している手順は、Oracle WebLogic Serverでサンプル・アプリケーションを設定および実行するためのものです。コンテンツ・サーバーは、IBM WebSphere Application Serverにデプロイすることもできます。詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドのIBM WebSphereでのOracle WebCenter Contentの管理に関する項を参照してください。

2.1 Fusion Order DemoおよびSuppliersモジュールについて

Oracle Fusion Order Demoサンプル・アプリケーションでは、オンライン・ショッピング用のWebアプリケーションを通して電子デバイスが販売されています。顧客はWebサイトにアクセスし、登録して、製品を注文できます。

デモの表示と実行には、Oracle JDeveloper 11gをインストールする必要があります。このデモには、アプリケーションをダウンロードする必要があります。これらのタスクの実行手順については、第2.2項「Fusion Order Demoアプリケーションの設定」を参照してください。

アプリケーションをインストールして実行した後は、Oracle JDeveloperを使用してコードを表示できます。既存の顧客としてログインして注文を行うと、実行時にアプリケーションを表示できます。

Fusion Order DemoのSuppliersモジュールでは、Java EEを使用してWebサプライヤ管理システム用のWebアプリケーションを作成する処理を示します。デモ・アプリケーションを通して、要点が示され、サンプル・コードが提供されます。

Suppliersモジュールは、Modelという名前のビジネス・サービス・プロジェクトとViewControllerという名前のWebユーザー・インタフェース・プロジェクトで構成されます。ViewControllerプロジェクトを実行して、JDeveloperでFusion Order DemoのSuppliersモジュールを実行します。ViewControllerプロジェクトでは、ビュー・テクノロジとしてJavaServer Faces(JSF)を使用し、Modelプロジェクトでは、EJBとの対話に際して、プロジェクトはADFモデル・レイヤーに依存します。Suppliersモジュールについての知識を深め、実装の詳細を理解するには、第2.3.1項「Supplierモジュール・コード」および第2.3.2項「Supplierモジュールのページ」を参照してください。

2.2 Fusion Order Demoアプリケーションの設定

Fusion Order Demoアプリケーションは、OracleデータベースとOracle JDeveloper 11gを使用して実行されます。サポートされるプラットフォームは、JDeveloperによってサポートされるプラットフォームと同じです。

Fusion Order Demoアプリケーションを設定する手順は次のとおりです。

1. Oracle JDeveloper 11gをインストールし、インストールの前提条件を満たします。Fusion Order Demoアプリケーションには、既存のOracleデータベースが必要です。

2. Oracle Technology NetworkからFusion Order Demoアプリケーションをインストールします。

3. Mozilla FireFoxバージョン2.0以上またはInternet Explorerバージョン7.0以上をインストールします。

4. 画面解像度1024×768以上をサポートするモニターでアプリケーションを実行します。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Order Demoアプリケーションの設定に関する項を参照してください。

2.3 Suppliersモジュールの実行

Fusion Order DemoアプリケーションのSuppliersモジュールを実行する手順:

1. 『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Order Demoアプリケーションの設定に関する項に記載のとおり、Fusion Order Demoアプリケーションをダウンロードし、インストールします。

2. Oracle JDeveloperでアプリケーションを開きます。

1. JDeveloperのメイン・メニューで、「ファイル」メニューから「開く」を選択します。

2. デモ用ZIPファイルを解凍した場所に移動し、SupplierModuleディレクトリからSupplierModule_2.0.jwsアプリケーション・ワークスペースを選択して「開く」をクリックします。
図2-1は、アプリケーション・ワークスペースにファイルを開いた後のアプリケーション・ナビゲータを示しています。ワークスペースの各プロジェクトの詳細は、第2.3.1項「Supplierモジュール・コード」を参照してください。

図2-1 Oracle JDeveloperでのSuppliersモジュール・コード

3. アプリケーション・ナビゲータで、「アプリケーション・リソース」アコーディオン・タイトルをクリックし、パネルを展開します。

4. 「アプリケーション・リソース」パネルで、「接続」、「データベース」の順にノードを展開します。

5. FOD接続を右クリックし、「プロパティ」を選択します。

6. 「データベース接続の編集」ダイアログで、表2-1のように各自の環境に合せて接続情報を変更します。

表2-1 Fusion Order Demoアプリケーションの実行に必要な接続プロパティ

プロパティ

説明

ホスト名

データベースのホスト名。次に例を示します。

localhost

JDBCポート

データベースのポート。次に例を示します。

1521

SID

データベースのSID。次に例を示します。

ORCLまたはXE

ユーザー名とパスワード(fod/fusion)は変更しないでください。これらはそのままにしておきます。「OK」をクリックします。

7. アプリケーション・ナビゲータで、「モデル」を右クリックして「再ビルド」を選択します。

8. アプリケーション・ナビゲータで、「ViewController」を右クリックして「実行」を選択します。
login.jspxページが表示されます。このモジュールでのセキュリティの構成上、まずログインする必要があります。

9. 「ユーザー名」にSHEMANT、「パスワード」にwelcome1と入力します。

ログインすると、browseページが表示され、製品を検索できます。結果の表で製品を選択すると、製品情報の編集や削除を行えます。ページの上部のコマンド・リンクを使用して、仕入先の情報を編集したり、仕入先を新たに追加できます。実行時のSuppliersモジュールの詳細は、第2.3.2項「Supplierモジュールのページ」を参照してください。

2.3.1 Suppliersモジュール・コード

Oracle JDeveloperでプロジェクトを開くと、各プロジェクト内のアーティファクトの確認を開始できます。Modelプロジェクトには、Webアプリケーションにデータを表示できるようにするJava クラスとメタデータ・ファイルが含まれています。oracle.fodemo.commonプロジェクトには、アプリケーション内の複数のクラスで使用されるコンポーネントが含まれています。oracle.fodemo.supplierプロジェクトには、仕入先のデータへのアクセスに使用されるコンポーネントが含まれています。図2-2は、Modelプロジェクトおよび関連するディレクトリを示しています。

図2-2 JDeveloperでのModelプロジェクト

ViewControllerプロジェクトには、バッキングBean、デプロイメント・ファイル、JSPXファイルなど、Webインタフェース用のファイルが含まれています。「アプリケーション・ソース」ノードには、マネージドBeanおよびバッキングBean、国際化に使用するプロパティ・ファイル、Oracle ADFによってバインド・データの表示に使用されるメタデータなど、Webクライアントで使用されるコードが含まれています。「Webコンテンツ」ノードには、JSPファイル、イメージ、スキン・ファイル、デプロイメント・ディスクリプタ、ライブラリなどのWebファイルが含まれています。図2-3は、ViewControllerプロジェクトおよび関連するディレクトリを示しています。

図2-3 JDeveloperでのViewController プロジェクト

2.3.2 Suppliersモジュールのページ

Supplierモジュールには、ユーザーが次のタスクを実行できる8個のメイン・ページが含まれています。

- 製品の検索: browse.jspxページでは、ユーザーは製品を検索できます。検索結果は、表に表示されます。図2-4は、browseページの検索フォームを示しています。

図2-4 Supplierモジュールの検索フォーム

- 表内の行データの編集: browse.jspxページの表から、ユーザーは製品を選択し、「Update」を選択してproductInfo.jspxページに移動できます(製品リンクのクリックでも、このページに移動します)。表から、ユーザーは「Remove」をクリックし、選択した製品を削除できるポップアップを起動することもできます。図2-5は、browseページの表を示しています。

図2-5 browseページの表

- フォーム内の行データの編集: productInfo.jspxページで、ユーザーは行のデータを変更できます。選択リストには、製品ステータスの有効な値が含まれています。「ファイルの選択」ボタンを使用して、ユーザーはグラフィック・ファイルをアップロードできます。このファイルはフォームの下に表示されます。図2-6は、productInfo.jspxページを示しています。

図2-6 製品の詳細ページ

- 「サプライヤの追加」リンクをクリックすると、図2-7に示す、新規サプライヤの作成に使用されるregisrationDetails.jspxページに含まれる一連のページに移動します。

図2-7 仕入先作成トレイン

- アプリケーションへのログイン: login.jspxページで、ユーザーはアプリケーションにログインできます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion WebアプリケーションでのADFセキュリティの有効化に関する項を参照してください。

第II部

コンテンツ・サーバー・インタフェースのルック・アンド・フィールの変更

この部では、Oracle WebCenter Content Serverインタフェースの外観およびナビゲーションの変更に使用できる様々な方法について説明します。

第II部は、次の章で構成されています。

- 第3章「コンテンツ・サーバー・インタフェースのカスタマイズ」

- 第4章「動的サーバー・ページ」

3 コンテンツ・サーバー・インタフェースのカスタマイズ

この章では、Oracle WebCenter Content Serverインタフェースのルック・アンド・フィールのカスタマイズに使用できる様々な方法について説明します。ユーザー・インタフェースの外観を変更する場合はスキンとレイアウトを使用し、ナビゲーションを変更する場合は動的サーバー・ページを変更します。

この章では、次の項目について説明します。

- 第3.1項「コンテンツ・サーバー・インタフェースのカスタマイズについて」

- 第3.2項「別のスキンまたはレイアウトの選択」

- 第3.3項「新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成」

- 第3.4項「スキンまたはレイアウトのテンプレートの変更」

- 第3.5項「匿名ユーザー・インタフェースの変更」

- 第3.6項「ログイン・ページのURLの変更」

- 第3.7項「新規レイアウトの作成およびパブリッシュ」

- 第3.8項「パブリッシュされたファイルの使用の最適化」

ヒント:
この章で説明されている方法以外の方法でも、ユーザーに提示されるメタデータ・フィールドを変更したり、チェックイン・ページや検索ページなどのユーザー・インタフェースで使用されるプレゼンテーションのタイプを変更できます。メタデータ・フィールドの作成と変更、およびコンテンツ・プロファイルの作成については、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のリポジトリ・コンテンツの管理に関する項を参照してください。

3.1 コンテンツ・サーバー・インタフェースのカスタマイズについて

スキンとレイアウトは、代替色スキームと代替ナビゲーション設計を実現しています。

3.1.1 スキンとレイアウトのタイプ

Oracle WebCenter Content Serverには、いくつかのスキンとレイアウトがデフォルトで同梱されています。さらに、カスタム・スキンとカスタム・レイアウトを設計することもできます。スキンまたはレイアウトを変更するときには、インタフェースのルック・アンド・フィールを変更します。スキンとレイアウトは、「ユーザー・プロファイル」ページに用意されているオプションから選択できます。

スキンまたはレイアウトを作成および変更するには、HTML、カスケード・スタイル・シートおよびJavaScriptを理解してさえいれば十分です。外観の変更後、編集されたレイアウトおよびスキンがパブリッシュされ、同じ環境内にいる他のユーザーが使用できるようになります。

注意:
新規スキンまたはカスタム・スキンを作成できるのは管理者のみです。ユーザー・インタフェースのデフォルトのルック・アンド・フィールの設定の詳細は、第3.3項「新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成」を参照してください。

3.1.2 スキン

スキンによって、色スキームが定義され、さらに、グラフィック、フォント、フォント・サイズなど、レイアウトの外観の他の面が定義されます。(デフォルトのスキンはOracle)。カスタム・スキンを設計したり、既存のスキンを変更できます。

3.1.3 レイアウト

レイアウトによって、ナビゲーション階層表示が定義され(デフォルトのレイアウトは「トレイ」)、カスタム・レイアウトを設計できます。カスタム・レイアウトによって、システム全体の動作とルック・アンド・フィールが変更されます。変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。用意されているレイアウトは次のとおりです。

- トレイ: 標準的なOracleスキンを備えたこのレイアウトが、デフォルトのインタフェースです。高水準のナビゲーションは、ナビゲーション・トレイを通じて実現します。

- トップ・メニュー: このレイアウトでは、ナビゲーションを提供するトップ・メニューを備えた代替ルックが実現します。

3.2 別のスキンまたはレイアウトの選択

代替色スキームを実現する別のスキン、または代替ナビゲーション設計を実現する別のレイアウト、あるいはその両方を選択できます。

3.2.1 別のスキンまたはレイアウトの選択方法

「ユーザー・プロファイル」ページで利用可能なユーザー・パーソナライズ設定を使用すると、ユーザーは、コンテンツ・サーバーのレイアウト、またはスキンを変更できます。

重要:
このパーソナライズ機能は、Internet Explorerの7以上、またはMozilla Firefoxの3以上のバージョンで使用できます。

別のスキンまたはレイアウトを選択する手順は次のとおりです。

1. コンテンツ・サーバーの「ホーム」ページのトップ・メニュー・バーで、your_user_nameをクリックします。
「ユーザー・プロファイル」ページが表示されます。

2. 目的のスキンおよびレイアウトを選択します。

3. 「更新」をクリックして変更を表示します。

3.2.2 実行時に行われる処理

別のスキンまたはレイアウトを選択した後は、ログインするたびに、そのスキンまたはレイアウトがコンテンツ・サーバーのユーザー・インタフェースとなります。

3.3 新規ユーザーおよびゲスト向けのデフォルトのスキンおよびレイアウトの構成

コンテンツ・サーバーのインスタンスのデフォルトの動作を変更するために、次に示す値をIntradocDir/config/config.cfgファイルに配置できます。

- LmDefaultSkin: ゲストおよび新規ユーザーによって使用されるスキンの名前。デフォルトは「Oracle」です。

- LmDefaultLayout: ゲストおよび新規ユーザーによって使用されるレイアウトの名前。デフォルトは「トレイ」ですが、「トップ・メニュー」に設定することもできます。

3.4 スキンまたはレイアウトのテンプレートの変更

「トップ・メニュー」レイアウトと「トレイ」レイアウトは、デフォルトでシステムに含まれています。この2つのレイアウトには、2つのスキン・オプション(「Oracle」と「Oracle2」)があります。レイアウトはJavaScriptで記述されており、スキンのルックはカスケード・スタイル・シートを使用して作成されます。

コンテンツ・サーバーに付属しているテンプレート・ファイルを変更してスキンおよびレイアウトを変更することも、他のユーザーと共有可能なコンポーネントを作成して新規のスキンおよびレイアウトを設計することもできます。

3.4.1 動的パブリッシュについて

コンテンツ・サーバーが起動するか、またはPUBLISH_WEBLAYOUT_FILESサービスが実行されると、std_resource.htmファイルにあるPublishedWeblayoutFiles表が使用され、ファイルがweblayoutディレクトリにパブリッシュされます。このパブリッシュ・メカニズムをカスタム・コンポーネントで使用するようにするには、テンプレートを作成し、そのテンプレートを使用するカスタム行をPublishedWeblayoutFiles表にマージします。

他のユーザーのファイルを変更またはカスタマイズする場合は、そのユーザーのテンプレート、またはPublishedWeblayoutFiles表にあるそのユーザーの行を無効にできます。他のユーザーのテンプレートでリソース・インクルードが使用されている場合は、それらのインクルードをいずれも無効にするか、または標準的なsuper表記法を使用して独自のIdocスクリプト・コードを挿入することができます。コンポーネントが無効になっていると、ファイルはパブリッシュも変更もされなくなり、コンテンツ・サーバーはそのデフォルトの状態に戻ります。

自分の作成したものに対する変更および追加を、他のユーザーが簡単にできるようにすることに加え、Idocスクリプトを使用して、以前は静的だったこれらのファイルを構成することもできます。たとえば、カスタム構成フラグの値に応じてファイルが変更されるようにすることができます。Idocスクリプトのカスタム機能を記述し、自分のテンプレート内から参照することによって、コンテンツ・サーバーのコアなオブジェクトおよび機能を使用できます。

このIdocスクリプトはパブリッシュ時に一度評価されるため、IdcHomeDir/resources/core/idoc/std_page.idocファイルから通常使用するようにはIdocスクリプトを使用できません。ユーザーがそのファイルを要求した時点では、すでに作成されているため、作成に使用されたスクリプトは、現在のサービスのDataBinderオブジェクトにも、現在のユーザーに関するいずれの情報にもアクセスできませんでした。

これにより、これらのファイルで記述できるIdocスクリプトのタイプが制限されます。ユーザーまたはサービスとともに動的に変化する情報を必要とするCSSまたはJavaScriptを記述する場合は、このコードを必要とするページにコード・インラインを含めることを検討してください。これにより、Webサーバーによって配信されるページのサイズが増えるため、使用される帯域幅の量が増えます。

3.5 匿名ユーザー・インタフェースの変更

匿名のランダム・ユーザーのインタフェースを変更するには、ExtranetLookコンポーネントを使用できます。この例としては、コンテンツ・サーバーをベースにしたWebサイトを、外部の顧客がログインなしで利用できるようにする必要があるが、そのWebサイトに自社の従業員が投稿できるようにしたい場合が挙げられます。

コンテンツ・サーバーがOracle WebLogic Serverで実行中の場合は、ExtranetLookコンポーネントによって、特定のページでの権限が変更され、アクセスするには書込み権限が必要となります。またこのコンポーネントでは、静的ポータル・ページを少し変更して、匿名のランダム・ユーザーに見せないリンクを除去することも行われます。

注意:
ExtranetLookコンポーネントでは、Oracle WebLogic Serverにフォームベースの認証を提供したり、カスタマイズ可能なエラー・ページを提供することもありません。

ExtranetLookコンポーネントは、コンテンツ・サーバーとともにインストールされています。このコンポーネントを使用するには、コンポーネント・マネージャを使用して有効にする必要があります。

Webページをカスタマイズして顧客がコンテンツを簡単に検索できるようにしたり、従業員にログインを付与してログイン時にインタフェースを表示できるようにすることができます。カスタマイズを行うには、ExtranetLook.idocファイルを変更して、ユーザー・ログインに基づいてカスタマイズできる動的リソース・インクルードを提供します。IDOCファイルは、コンテンツ・サーバーのリポジトリにチェックインされるため、コンテンツ・サーバーのテンプレートによって参照できます。

3.5.1 匿名ユーザー・インタフェースの変更方法

コンテンツ・サーバーのWebサイトの匿名ユーザー・インタフェースのルック・アンド・フィールを更新するには、IntradocDir/data/usersディレクトリに格納されている次のファイルを変更します。

- prompt_login.htm

- access_denied.htm

- report_error.htm

匿名ユーザー・インタフェースを変更する手順は次のとおりです。

1. Webレイアウト・エディタを表示します。

2. 「オプション」メニューから「ポータルの更新」を選択します。

3. ポータル・ページを目的どおりに変更します。動的リソース・インクルードを使用して、このページをカスタマイズできます。

4. 「OK」をクリックします。

5. ExtranetLook.idocファイルを目的どおりにカスタマイズします。

6. コンテンツ・サーバーからExtranetLookコンテンツをチェックアウトします。

7. 改訂されたExtranetLook.idocファイルをコンテンツ・サーバーにチェックインします。

3.5.2 実行時に行われる処理

ポータル・ページを変更してExtranetLook.idocファイルをカスタマイズした後は、ユーザーがログインしないでWebサイトにアクセスするときは常に、その設計がコンテンツ・サーバーのユーザー・インタフェースとなります。

3.6 ログイン・ページのURLの変更

コンテンツ・サーバーのログイン・ページのURLは、そのコンテキスト・ルート(通常は/cs/)を変更することによって変更できます。HttpRelativeWebRootプロパティを使用して相対コンテキスト・ルートを設定してもURLは変更できません。それは、ログイン・ページにはこのプロパティの値が適用されないためです。ユーザーがログインするWebロケーションを変更する必要がある場合は、デプロイ・プランを使用してWebCenter Contentアプリケーションを再デプロイできます。

ログイン・ページのURLを変更する手順は次のとおりです。

1. WebCenter Contentがデプロイされているドメインの管理者として、Oracle WebLogic Server管理コンソールにログインします。

2. 左側の「ドメイン構造」領域で、ドメインの名前で「デプロイメント」をクリックします。「デプロイメントのサマリー」ページの「制御」タブにある「デプロイメント」表の「Oracle WebCenter Content - コンテンツ・サーバー」をクリックします。
このアプリケーションは、表の2ページ目か3ページ目にある場合もあります。

3. デプロイ・プランへのパスを書き留めます。
WebCenter Contentインスタンスのプランが指定されていない場合は、次のようにして作成できます。

1. 「Oracle WebCenter Content - コンテンツ・サーバー」ページの「設定」で「構成」をクリックします。

2. 「構成」タブ上の任意のパラメータの値を変更します。

3. 「保存」をクリックします。

4. 「デプロイメント・プランの保存」ページでデプロイ・プロセスへのパスを確定するか、またはパスを変更します。

5. 「OK」をクリックします。

4. テキスト・エディタで、次のように、デプロイ・プランの2箇所に行を追加します。

1. original_loginpage_path変数とoriginal_loginerror_path変数を、それぞれ<variable-definition>要素の<variable>要素に追加します。この例では次のようになります。

<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>ServletPlugin</application-name>
<variable-definition>
<variable>
<name>original_loginpage_path</name>
<value>/content/login/login.htm</value>
</variable>
<variable>
<name>original_loginerror_path</name>
<value>/content/login/error.htm</value>
</variable>
<variable>
<name>SessionDescriptor_timeoutSecs_12996472139160</name>
<value>3600</value>
</variable>

2. cs.warファイルのweb.xmlの<module-descriptor>要素に、2つの<variable-assignment>要素を追加します。これらの要素によって、original_loginpage_path変数とoriginal_loginerror_path変数に、次の値がそれぞれ割り当てられます。

- /web-app/login-config/form-login-config/form-login-page

- /web-app/login-config/form-login-config/form-error-page
次に例を示します。

<module-override>
<module-name>cs.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
<variable-assignment>
<name>original_loginpage_path</name>

<xpath>/web-app/login-config/form-login-config/form-login-page</xpath>
</variable-assignment>
<variable-assignment>
<name>original_loginerror_path</name>

<xpath>/web-app/login-config/form-login-config/form-error-page</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
<module-override>

5. stopManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバー(デフォルトではUCM_server1)を停止します。

- UNIXスクリプト:
DomainHome/bin/stopManagedWebLogic.sh UCM_server1

- Windowsスクリプト:
DomainHome\bin\stopManagedWebLogic.cmd UCM_server1

6. 管理コンソールで、ドメインの名前で「デプロイメント」をクリックします。

7. 「デプロイメント」表で「Oracle WebCenter Content - コンテンツ・サーバー」を選択して、「更新」をクリックします。

8. 「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」を選択し、デプロイ・プランへのパスが正しいことを確認して「終了」をクリックします。

9. 再デプロイが正常に完了したら、「変更の適用」をクリックします。

10. startManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを起動します。

- UNIXスクリプト:
DomainHome/bin/startManagedWebLogic.sh UCM_server1

- Windowsスクリプト:
DomainHome\bin\startManagedWebLogic.cmd UCM_server1

11. 管理コンソールで「デプロイメント」をクリックします。

12. 「デプロイメント」表で「Oracle WebCenter Content - コンテンツ・サーバー」を選択して、「起動」メニューから「すべてのリクエストを処理」を選択します。

13. WebCenter Contentアプリケーションが起動したら、ログイン・ページのURLが変わったことを確認します。

3.7 新規レイアウトの作成およびパブリッシュ

新規レイアウトの作成およびパブリッシュに必要な一般的な手順は次のとおりです。

1. IdcHomeDir/resources/core/tables/std_publishing.htm内のLmLayouts表に表をマージして、新規レイアウトを定義します。レイアウトID、ラベル、および有効(1に設定)になっているかどうかを定義します。

2. IdcHomeDir/resources/core/tables/std_publishing.htm内のPublishedWeblayoutFiles表に表をマージします。この新しい表では、コンテンツ・サーバーのテンプレートから作成され、weblayoutディレクトリにプッシュアウトされたファイルについて説明します。それぞれのスキン・ディレクトリにプッシュアウトするために必要なskin.cssファイルを指定します。

3. std_publishing.htm内のPublishedStaticFiles表に表をマージします。ここには、imagesのように、weblayoutディレクトリにパブリッシュするファイルを含むディレクトリが一覧表示されています。

3.8 パブリッシュされたファイルの使用の最適化

コンテンツ・サーバーに対し、パブリッシュされたファイルをバンドルして一括配信して、サーバーへのページ・リクエストの数を最小に抑えるように指示することができます。さらに、パブリッシュされたページを、Idocスクリプトを使用して参照することによって、ファイルを最適化できます。

3.8.1 ファイルのバンドル

複数のリソースをまとめて、バンドルというユニットにパッケージすることができます。バンドルとは、パブリッシュされたリソースを1つ以上含む単一のファイルです。JavaScriptとcssのリソースのみを、同じタイプの他のリソースのみとバンドルする必要があります。バンドルを行うと、ページがロードされたときのクライアントのオーバーヘッドを減らすことには役立ちますが、クライアント解析、コンパイルおよび実行オーバーヘッドは増えます。一般的には、類似したテーマを持つリソース、および同時に含まれると予想されるリソースをバンドルすることをお薦めします。たとえば、リソースA、BおよびCがあらゆるページで必要であり、リソースD、EおよびFはめったに必要とはならないが、必要となるときは一括して必要になるとわかっている場合は、A、BおよびCをまとめてバンドルし、D、EおよびFは別のバンドルに入れることをお薦めします。

コンテンツ・サーバーのコア向けJavaScriptリソースはほとんどすべて、2つのバンドルのいずれかにバンドルされます。1つはyuiBundle.jsで、これにはサードパーティであるYahooユーザー・インタフェース・ライブラリによって提供されるスクリプトが含まれ、もう1つはbundle.jsで、これにはそれ以外のリソースが含まれます。

リソースをどのようにバンドルするかを決定するには、PublishedBundles表が使用されます。本質的に、バンドルを識別するのは、そのターゲットであるbundlePath、すなわちバンドルへのパス名(weblayoutディレクトリへの相対パス)、およびどのリソース・クラスが含まれているか除外されているかを記述したルールのリストです。この表にあるloadOrderの値が適用されるのは、フィルタリング・ルールの適用順序であり、バンドルでのリソースの表示順序ではありません。

注意:
Oracle Universal Content Management 10gでは、別の表を使用し、各バンドルでのリソースの順序を決定するloadOrderの値がありましたが、その後、バンドルは変化しました。

静的なweblayoutファイルの内容がクライアント・マシンおよびWebプロキシにキャッシュされ、それによって、使用されるサーバー帯域幅の量が大幅に減りました。そのため、ベスト・プラクティスとして、可能なかぎりこれらのタイプのファイルを使用してください。

ただし、クライアントのブラウザによって要求されるそれぞれの静的weblayoutファイルでは、そのファイルの最新バージョンがクライアントにあることを確認するためだけに、サーバーとの間で双方向通信を行う必要があります。これは、ファイルがキャッシュされている場合にも当てはまります。これらのファイルの数が増えると、ページ・リクエストごとにサーバーから行われるダウンロードの回数も増えます。

双方向通信の回数を最小に抑えるようにするため、コンテンツ・サーバーでは、パブリッシュされた複数のファイルをバンドルして、一括配信されるようにできます。この機能は、サーバーのIntradocDir/config/config.cfgファイルで次の構成を設定することで無効にできます。

BundlePublishedWeblayoutFiles=false

バンドルは、例3-1に示すように、
std_publishing.htmファイル内のPublishedBundles表を使用することによって実行されます。

例3-1 std_publishing.htmファイル内のPublishedBundles表

<@table PublishedBundles@>
<table border=1><caption><strong>
<tr>
<td>bundlePath</td>
<td>includeClass</td>
<td>excludeClass</td>
<td>loadOrder</td>
</tr>
<tr>
<td>resources/bundle.js</td>
<td>javascript:common</td>
<td></td>
<td>128</td>
</tr>
. . .
</table>
<@end@>

この表の列は、次のとおりです。

- bundlePath: バンドルがパブリッシュされる最終的な位置。このパスはweblayoutディレクトリに対する相対パスです。

- includeClass: これは、どのリソースをバンドルに含めるかを決定するために使用されます。

- excludeClass: これは、どのリソースをバンドルから除外するかを決定するために使用されます。

- loadOrder: includeClassフィルタとexcludeClassフィルタの適用順序。

前の例では、javascript:commonクラスのファイルは、resources/layouts/commonBundle.jsにある単一のバンドルにパブリッシュされます。このクラスに一致する、バンドルされたすべてのファイルの内容が付加されて、その位置に格納される単一のファイルが形成されます。

3.8.2 パブリッシュされたファイルの参照

パブリッシュされたファイルのほとんどは(バンドルされているものもいないものも含めて)、ページに含めるにはHTML内から直接参照できる必要があります。そのため、指定された状況でどのファイルを含めるかを把握することが難しくなることがあります。バンドルを有効にするか無効にするかをサーバー管理者が決められる場合は特にそうです。指定されたページに、必要なファイルのすべてを容易かつ透過的に含めるには、単純なIdocスクリプト・メソッドを使用できます。

たとえば、(前述したように)javascript:commonバンドルに関連付けられているファイルをすべて含むページを記述していて、2番目の表に記述されているバンドルに加えて、最初の表に記述されているファイルのすべてを含むHTMLを記述していない場合は、ファイルごとにサーバーに尋ねられます。これではバンドルの目的が否定されます。ファイルごとに、実際に存在しているかどうかがサーバーに対してpingされるからです。

例3-2に、あるページのHEADセクション内のIdocスクリプト・コードを示します。このコードでは、ページ上のこれらのファイルが含まれます。

例3-2 ファイルのバンドルを参照するためのIdocスクリプト

<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>

ここに抜粋したコードでは、バンドルがオフになっていても、javascript:commonファイルがすべて含まれます。javascript:commonでなくjavascriptが渡された場合は、javascriptをクラスの先頭とするファイルがすべて含まれます。

このPublishedResources結果セットはloadOrderでソートされるため、loadOrderが最も低いファイルおよびバンドルが最初に含まれます。より大きなloadOrderを持つファイルでは、それ以前に宣言されていたJavaScriptメソッドまたはCSSスタイルが無効になります。

4 動的サーバー・ページの作成

この章では、動的サーバー・ページを作成してWebページの外観およびナビゲーションを変更するために必要なビルディング・ブロックの使用方法について説明します。

この章では、次の項目について説明します。

- 第4.1項「動的サーバー・ページについて」

- 第4.2項「Webページの外観およびナビゲーションの変更」

- 第4.3項「動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルの作成」

- 第4.4項「HCSTページの作成」

- 第4.5項「HCSPページの作成」

- 第4.6項「HCSFページの作成」

- 第4.7項「HCST、HCSP、HCSFの各ページのWebブラウザでの表示の確認」

4.1 動的サーバー・ページについて

動的サーバー・ページとは、コンテンツ・サーバーにチェックインされ、Webページを動的に生成するために使用されるファイルのことです。動的サーバー・ページは通常、Webページのルック・アンド・フィールおよびナビゲーションを変更するために使用されます。たとえば、動的サーバー・ページは、次のタスクを実行するために使用できます。

- Content PublisherによってパブリッシュされるWebページを作成する

- HTMLフォームを実装する

- Webサイト全体で一貫性のあるルック・アンド・フィールを維持する

動的サーバー・ページには、次のようなファイル・フォーマットがあります。

- IDOC: 独自のスクリプト言語です。

- HCST: Hypertext Content Server Template。IdcHomeDir/resources/core/templatesディレクトリに格納されているコンテンツ・サーバーの標準的なテンプレートに似ています。

- HCSP: Hypertext Content Server Page。HTMLに対応したバージョンのHCSTページで、通常はパブリッシュされたコンテンツに使用されます。

- HCSF: Hypertext Content Server Form。HCSPページおよびHCSTページに似ていますが、Webブラウザから記入して送信することのできるHTMLフォーム・フィールドが含まれています。

動的サーバー・ページを使用すると、コンテンツ・サーバーでは、コンテンツ・サーバーにチェックインしたカスタム・テンプレート(HCST、HCSP、HCSFいずれかのファイル)を使用して、Webページが動的にアセンブルされます。このテンプレートでは、同じくコンテンツ・サーバーにチェックインしたテキスト・ファイル(IDOCファイル)からHTMLインクルードが呼び出されます。

Webページのルック・アンド・フィールおよびナビゲーションを変更するには、HCS*テンプレート・ページまたはIDOCファイル、あるいはその両方を変更して、改定後のファイルを新たなリビジョンとしてチェックインします。変更内容がすぐにわかります。

コンテンツ・サーバーとともに動的サーバー・ページを使用すると、次のメリットが得られます。

- カスタマイズの導入とテストを迅速かつ容易に行うことができます。動的サーバー・ページのリビジョンをチェックインするだけで変更内容が即座に実装され、コンテンツ・サーバーを再起動する必要はありません。

- Webページでは、標準的なHTMLにはない機能を利用できます。たとえば、CGIスクリプトなしで、HTMLフォームをコンテンツ・サーバーに直接送信できます。また、Idocスクリプトを使用すると、コンテンツ・サーバーに関する環境および状態の情報を直接操作できます。

- コンポーネント・ファイルをインストールしたり常時監視する必要はありません。ファイルが大量にあったり、システムが高度にカスタマイズされている場合は、コンポーネントの維持とトラブルシューティングが難しくなることが考えられます。動的サーバー・ページのほうが、カスタマイズのすべてを含んだコンテンツ・アイテムを少しチェックインするだけなので、操作しやすくなります。

- カスタマイズを個々のページに適用できます。動的サーバー・ページを使用すると、グローバルではなく単一のページにカスタマイズを適用できるため、コンテンツ・サーバーのページの標準的なコーディングに手を入れなくてすみます。

動的サーバー・ページを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。

- 動的サーバー・ページは、コンテンツ・サーバーのコアな機能の変更には使用できません。動的サーバー・ページは、Web設計とフォーム・ページのカスタマイズに最も役立ちます。

- 動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があります。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。

図4-1は、動的サーバー・ページを生成および使用するプロセスを示しています。

図4-1 動的サーバー・ページのプロセス

「図4-1 動的サーバー・ページのプロセス」の説明

4.1.1 ページ・タイプ

動的サーバー・ページには次の4つのタイプがあり、ファイル名の4文字の拡張子によってコンテンツ・サーバーで識別されます。

- IDOC

- HCST

- HCSP

- HCSF

4.1.1.1 IDOCファイル

IDOCファイルは、HCST、HCSP、HCSFの各ページによって呼び出されるHTMLインクルードを含むテキスト・ファイルです。

詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

4.1.1.2 HCSTファイル

Hypertext Content Server Template(HCST)ファイルは、コンテンツ・サーバーの標準的なテンプレート・ページに似たテンプレート・ページであり、Webページをアセンブルする際にフレームワークとして使用されます。

- HCSTページが使用される代表的なケースは、ページのコンテンツ自体が動的な場合、または、検索ページ、検索結果ページ、カスタム・チェックイン・ページなどでコンテンツ・サーバー機能が必要とされる場合です。

- このタイプのページは、動的にアセンブルされたコードでほとんどが構成されているため、HCSTファイルはコンテンツ・サーバー内で索引が付けられません。

4.1.1.3 HCSPファイル

Hypertext Content Server Page(HCSP)ファイルは、パブリッシュされたWebページで、そのページには、実際のWebサイトのコンテンツが表示されます。

- HCSPファイルの代表的な作成方法としては、テンプレートとしてHCSTページを使用し、Content PublisherによってWebページを生成すること、または、HCSFページによってコンテンツ・サーバーでフォームを送信することがあります。

- このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSPファイルはコンテンツ・サーバー内で索引が付けられます。

4.1.1.4 HCSFファイル

Hypertext Content Server Form(HCSF)ファイルは、HCSPファイルに似ていますが、Webブラウザから記入して送信することのできるHTMLフォーム・フィールドが含まれている点が違います。

- ユーザーがHCSFページからフォームを記入して送信すると、HCSFページのXML要素によってメタデータが定義された別のコンテンツ・アイテムとして、HCSPファイルがチェックインされます。

- このタイプのページは、Web表示可能なコンテンツが含まれているため、HCSFファイルはコンテンツ・サーバー内で索引が付けられます。
HCSFページの詳細は、第4.1.1.4項「HCSFファイル」を参照してください。

4.2 Webページの外観およびナビゲーションの変更

動的サーバー・ページは、カスタム・コンポーネントとは異なる形でコンテンツ・サーバーに実装されていますが、WebCenter Contentコンポーネントのアーキテクチャ概念、特にコンテンツ・サーバーのテンプレートおよびHTMLインクルードに精通している必要があります。詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

動的サーバー・ページとともにコンテンツ・サーバーのインスタンスをカスタマイズするには、次の基本手順を実行します。

1. カスタム・インクルードを含むIDOCファイルを作成します。

2. IDOCファイルをコンテンツ・サーバーにチェックインします。

3. IDOCファイルを参照するHCSTファイル、HCSPファイルまたはHCSFファイルを作成します。

4. HCS*ファイルをコンテンツ・サーバーにチェックインします。

5. コンテンツ・サーバーで検索するか、またはパブリッシュされたWebページからリンクすることによって、WebブラウザでHCS*ファイルを表示します。

ヒント:
Content Publisherとともに動的サーバー・ページを使用することは、Web公開の強力なツールになる可能性があります。詳細は、Content Publisherのドキュメントを参照してください。

4.2.1 構文

異なるタイプの動的サーバー・ページは、解釈も表示も異なっているため、ファイル内のIdocスクリプトは、異なるコーディングを行う必要があります。次の表は、それらの違いをまとめたものです。

ファイル・タイプ

.idoc

.hcst

.hcsp

.hcsf

全文索引作成

なし

なし

あり

あり

Idocスクリプトの式

<$ … $>

<$ … $>

<!--$ … -->
[!--$ … --]

<!--$ … -->
[!--$ … --]

比較演算子

記号(==)

記号(==)

特殊演算子(eq)

特殊演算子(eq)

特殊文字

記号(&)

記号(&)

エスケープ・シーケンス(&amp;)

エスケープ・シーケンス(&amp;)

メタデータの参照

必須

必須

必須

必須

注意:
Idocスクリプトでは、標準的なHTMLインクルードのコーディングを使用します。詳細は、第15.2.1項「HTMLインクルード」を参照してください。
HCSTでは、コンテンツ・サーバーの標準的なテンプレートのコーディングを使用します。詳細は、第15.2.8.1項「テンプレート・ページとレポート・ページ」を参照してください。

HCSPとHCSFでは特殊なコーディングが使用され、ページを静的にも動的にもレンダリングでき、全文索引を作成できます。

4.2.1.1 Idocスクリプトの式

HCSPページとHCSFページでは、Idocスクリプトの式は一般的に、HTMLコメント・タグ間に配置されます。ページが静的に表示されるときには、このように配置することによって、Webブラウザでページ・コンテンツを表示でき、コンテンツの書式設定に使用されている動的コードがあっても無視されます。またこれによって、全文索引作成エンジンが、これらのページのコンテンツの索引を正常に作成できます。

次に、いくつかの例を示します。

- IDOCファイルまたはHCSTファイル: <$include MyIdocExpression$>

- HCSPファイルまたはHCSFファイル: <!--$include MyIdocExpression-->

状況によっては、HTMLコメントの開始と終了を制御することもできます。HCSPファイルとHCSFファイルでは、この操作を行うには、例4-1に示すように、Idocスクリプトの式の後にある終了タグで、ダッシュ(-)を他の文字に置換します。

例4-1 HCSPファイルまたはHCSFファイルでのHTMLコメントのシャープ記号によるデリミタ

<!--$a="ab"##> HTML comment remains open
<a href="<!--$myUrlAsVariable##>">MyUrl</a> Static view does not see this
<!--$dummy=""--> <!—Ended the comment area-->.

例4-1では、ダッシュ(-)がシャープ記号(#)に置換されています。

HCSPファイルとHCSFファイルでの別のオプションとしては、例4-2に示すように、標準的なHTMLコメントの開始タグおよび終了タグ(< >)を大カッコ([])に置換します。このように置換すると、XHTMLパーサーでは、静的に表示されたときにすべてのスクリプトを適切に識別できます。

例4-2 HCSPファイルまたはHCSFファイルでのHTMLコメントの大カッコによるデリミタ

<!--$a="ab"--] HTML comment remains open
<a href="[!--$myUrlAsVariable--]">MyUrl</a> Static view does not see this
[!--$dummy=""--> <!—Ended the comment area-->.

4.2.1.2 比較演算子

HCSPページとHCSFページでは、(==などの)標準的な比較演算子は、HTMLパーサーにとっては特殊な意味があるため使用できません。動的サーバー・ページでは、次の比較演算子を使用します。

IDOCファイルまたはHCSTファイル

HCSPファイルまたはHCSFファイル

説明

==

eq

等価かどうかをテストします。

!=

ne

非等価かどうかをテストします。

<

lt

より小さいかどうかをテストします。

>

gt

より大きいかどうかをテストします。

<=

le

以下かどうかをテストします。

>=

ge

以上かどうかをテストします。

たとえば、次のコードは、変数countの値が10より大きいかどうかを評価します。

IDOCファイルまたはHCSTファイル

HCSPファイルまたはHCSFファイル

<$if count > 10$>
<$"Count is greater than"$>
<$endif$>

<!--$if count gt 10-->
<!--$"Count is greater than"-->
<!--$endif-->

4.2.1.3 特殊文字

HCSPページとHCSFページでは、アンパサンド(&)などの特殊文字は、HTMLパーサーにとっては特殊な意味があるため使用できません。HTMLまたはXMLの標準的なエスケープ・フォーマット(&amp;や&#038;など)を使用する必要があります。

注意:
HCSPページまたはHCSFページからdocLoadResourceIncludes関数をコールするときには、エスケープ文字&amp;を使用することが特に重要です。詳細は、第4.2.2.1項「docLoadResourceIncludes関数」を参照してください。

次の例に示すように、Idocスクリプトでは、先頭にバックスラッシュ文字を置くことによって、文字列に引用符を含めることができますが、HCSPページまたはHCSFページでは、引用符はHTMLのエスケープ文字で表す必要があります。

- IDOCファイルまたはHCSTファイル: "Enter \"None\" in this field."

- HCSPファイルまたはHCSFファイル: "Enter &quot;None&quot; in this field."

HCSTページでは、\nを使用して行送りが挿入されます。HCSPページでは、行送りをファイルに直接挿入するか、または行送りの数値ASCII番号を使用してXML内にエンコードします。

注意:
&文字列の結合演算子をjoinという単語に置換できるようになりました。たとえば、[!--$a join b--]と記述できます。それまでは、[!--$a & b--]と記述していました。要素の属性内のXMLパーサーでは、最初のものは受け入れられますが、2番目のものは受け入れられません。

4.2.1.4 メタデータの参照

動的サーバー・ページでは、いくつかのメタデータ値が、ref:という接頭辞付きで格納されており、その値はページで利用できますが、ResultSetの値を置換するものではありません。(このため、動的サーバー・ページによる結果セットの汚染が防止されます。)

動的サーバー・ページで次のメタデータ値のいずれかを参照する場合は、ref:接頭辞を含める必要があります。

- hasDocInfo

- dDocName

- dExtension

- dSecurityGroup

- isLatestRevision

- dDocType

たとえば、次の文では、ドキュメント・タイプがPageであるかどうかを判別します。

<$if strEquals(ref:dDocType,"Page"))$>

4.2.2 Idocスクリプトの関数:

動的サーバー・ページでは、Idocスクリプトの次の2つの特殊関数が必要です。

- docLoadResourceIncludes

- executeService

4.2.2.1 docLoadResourceIncludes関数

IDOCファイルでHTMLインクルードを使用できるようにするには、次の例に示すように、HCS*ファイルでdocLoadResourceIncludes関数をコールする必要があります。この関数では、現在のページのアセンブルに使用できるように、指定されたIDOCファイルからすべてのインクルードがロードされます。例4-3に、HCSTファイルからこの関数をコールする形式を示します。

例4-3 HCSTファイルでのdocLoadResourceIncludes関数コール

<$docLoadResourceIncludes("dDocName=system_std_page&RevisionSelectionMethod=Latest")$>

例4-4に、HCSPファイルまたはHCSFファイルからこの関数をコールする形式を示します。

例4-4 HCSPファイルまたはHCSFファイルでのdocLoadResourceIncludes関数コール

<!--$docLoadResourceIncludes("dDocName=system_std_page&amp;RevisionSelectionMethod=Latest")-->

4.2.2.1.1 docLoadResourceIncludes関数をコールするための要件

- 指定されたコンテンツ・アイテムのネイティブ・ファイルでは、拡張子が.idocになっている必要があります。

- docLoadResourceIncludesコールは、HCS*ファイル内で最初のインクルードの前に配置する必要があります。この関数は、ページのHEADセクション内に配置することをお薦めします。

- HCS*ページからdocLoadResourceIncludes関数をコールするときには、正しいアンパサンド文字を使用する必要があります。詳細は、第4.2.1.3項「特殊文字」を参照してください。

4.2.2.1.2 パラメータ

どのIDOCファイルを呼び出すかを指定するには、docLoadResourceIncludes関数で次のパラメータを使用します。

- dDocNameとdIDのいずれかを定義する必要があります。両方のパラメータをいっしょに使用することはやめてください。

- dDocNameを定義する場合は、RevisionSelectionMethodをLatestまたはLatestReleasedに定義する必要があります。

- dIDを定義する場合は、RevisionSelectionMethodを定義しないでください。あるいは、RevisionSelectionMethodをSpecificに定義します。

パラメータ

説明

dDocName

IDOCファイルの「コンテンツID」の値を指定します。
このパラメータは、「コンテンツID」の値がわかっているときには常に存在している必要があります。エラー・メッセージは、フォームなど、他の機能と同様に、これが存在しているという想定に基づいています。

dID

IDOCファイルの特定のリビジョンの一意のID番号を指定します。

RevisionSelectionMethod

このIDOCファイルのいずれのリビジョンを使用するかを指定します。

- Latest: 最後にチェックインされたリビジョンのドキュメントが使用されます(ワークフロー内のリビジョンを含みます)。

- LatestReleased: 最後にリリースされたリビジョンのドキュメントが使用されます。

- Specific: dIDを使用した場合にのみ使用します。

Rendition

このIDOCファイルのいずれのレンディションを使用するかを指定します。

- Primary: プライマリ(ネイティブ)ファイル。これは、Renditionの値が指定されていない場合に有効となるデフォルト値です。

- Web: Web表示可能ファイル。

- Alternate: 代替ファイル。

4.2.2.2 executeService関数

executeService関数は、動的サーバー・ページ内からコンテンツ・サーバーのサービスを実行します。次に例を示します。

HCSTファイル: <$executeService("GET_SEARCH_RESULTS")$>

HCSPファイルまたはHCSFファイル: <!--$executeService("GET_SEARCH_RESULTS")-->

- executeService関数でコールできるサービスは、パラメータ入力が必要でないという意味で、「スクリプト可能」である必要があります。

- スクリプト可能なサービスのアクセス・レベルは32以上です。詳細は、第18章「環境へのWebCenter Contentの統合の開始」を参照してください。

- コンテンツ・サーバーの標準的なサービスについては、IdcHomeDir/resources/core/tables/std_services.htmファイルを参照してください。

- executeService関数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

- サービスの詳細は、第18章「環境へのWebCenter Contentの統合の開始」を参照してください。

パフォーマンスのヒント:
サービスの使用は控えめにしてください。ページ上でサービス・コールが多すぎると、パフォーマンスが影響を受けたり、スケーラビリティが制限される場合があります。

4.2.3 開発に関する推奨事項

動的サーバー・ページの開発を支援するための次の推奨事項には、一般的なガイドラインとHCSFのガイドラインが含まれています。

4.2.3.1 一般的なガイドライン

次の推奨事項は、すべてのタイプの動的サーバー・ページの開発に当てはまります。

- テンプレートは、できるだけ簡略でコードのないものにします。テンプレートはHTMLインクルードのみにして、コードと条件はすべてIDOCファイルに入れるようにします。これが特に役立つのはHCSFページで、そこでは、送信されたフォームも、IDOCファイルに対する変更に反映されます。

- Oracle WebCenter Content Serverのインスタンスをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。動的サーバー・ページを頻繁に改定すると、廃止されるコンテンツ・アイテムが大量に発生する場合があることを頭に入れてください。本番インスタンスにデプロイする前に、開発システムでできるだけ多くの作業を済ませてください。また、古くなったページを定期的に削除することをお薦めします。

- 動的サーバー・ページを使用してWebサイトを開発するときには、開発プロセスとコントリビューション・プロセスを、所有の観点で考えます。

- 構造(サイトの設計とナビゲーションを含む)は、Webマスターが所有しています。動的サーバー・ページを使用するときには、構造は、IDOCファイルに定義されているインクルードに含まれており、そのインクルードとともに制御されます。

- コンテンツ、すなわちWebページの実際のテキストは、コントリビュータが所有しています。動的サーバー・ページを使用するときには、コンテンツは主として、IDOCファイル内のインクルードを利用するHCSPファイルに含まれています。

- Content Publisherとともに動的サーバー・ページを使用することは、Web公開の強力なツールになる可能性があります。Word文書またはHCSFページを使用してコンテンツを作成し、Content Publisherを使用して、そのドキュメントを、パブリッシュされたHCSPファイルに変換することができます。SCPテンプレートで前にインクルードと後ろにインクルードのオプションを使用して、追加のIdocスクリプト・インクルードを挿入できます。

- Content Publisherで動的サーバー・ページをパブリッシュする場合は、ドキュメントを簡単に識別できるように接頭辞オプションを使用します。

- 一貫性のあるネーミング規則を使用します。たとえば、「システム」レベルのインクルードの場合は、IDOCファイルにsystem_std_pageという名前を付け、そのファイル内の各インクルードに、system_を接頭辞とする名前を付けることができます。こうすると、インクルードを見つけやすくなります。

- 動的サーバー・ページのタイプごとにコンテンツ・タイプを作成することをお薦めします(HCSF_templatesやsubmitted_formsなど)。

- 優れたコーディング手法に従って、動的サーバー・ページに常にコメントを入れて、カスタマイズの記録を残してください。

4.2.3.2 HCSFガイドライン

次の推奨事項は、HCSFページの開発にのみ当てはまります。

- フォームを設計する際には、テンプレートがどのように使用されるかを検討してください。

- このテンプレートは、フォームを送信するユーザーのロールに応じて変わるか

- 送信されたコンテンツは、重要なワークフローに入るか

- どのようなデフォルトのメタデータ値を設定するか

- 複数のライン入力に対するResultSetがフォームに含まれるか

- フォームのパラメータがWebブラウザからWebサーバーに渡され、Oracle WebCenter Content Serverを通じてフィルタリングされてWebブラウザに戻されるときに、そのパラメータが表示されるようにするには、次のようにして、インクルード・コードのmethod属性をPOSTからGETに変更します。

<form name="<$formName$>" method="GET" action="<$HttpCgiPath$>">

- DataScriptというフォーム・フィールドを、送信されているフォームに追加した場合、その値に対するIdocスクリプトがあれば、Oracle WebCenter Content Serverがフォームを処理するときにそのスクリプトを評価します。

4.2.4 HCSFページ

Oracle WebCenter Content ServerテンプレートおよびHTMLフォームに対する標準的な書式設定ルールを遵守することに加えて、HCSFページでは、Oracle WebCenter Content Serverによる処理を可能とする特殊なセクションとタグがいくつか必要です。これらの特殊セクションは、通常のHCSFファイルでは次の順序で表示されます。

1. ロード・セクション

2. データ・セクション

3. フォーム・セクション

完全なHCSFページの例は、第4.1.1.4項「HCSFファイル」を参照してください。

4.2.4.1 ロード・セクション

HCSFページの先頭にあるロード・セクションでは、ファイルをHTMLファイルとして宣言し、IDOCファイルをロードして、ページに関する他の情報をロードします。例4-5は、一般的なロード・セクションを示しています。

例4-5 HCSFページのロード・セクション

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<!--$docLoadResourceIncludes("dDocName=my_idoc_page&amp;RevisionSelectionMethod=Latest")-->
<meta NAME="idctype" CONTENT="form; version=1.0">
<!--$defaultPageTitle="Department News Form"-->
<!--$include std_html_head_declarations-->
</head>

ロード・セクションには、次の3つのアイテムがあります。

- HTML宣言

- docLoadResourceIncludes関数

- meta要素

- 変数とインクルード

4.2.4.1.1 HTML宣言

HTML宣言では、次の構文でファイルをHTMLファイルとして指定しています。

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

4.2.4.1.2 docLoadResourceIncludes関数

docLoadResourceIncludes関数では、現在のページのアセンブルに使用できるように、指定されたIDOCファイルからすべてのインクルードがロードされます。詳細は、第4.2.4.1.2項「docLoadResourceIncludes関数」を参照してください。

4.2.4.1.3 meta要素

meta要素がContent Publisherによって使用され、これが特殊なタイプのページであることを示します。

- この要素は、フォームがContent Publisherによってパブリッシュされていない場合は不要です。

- meta要素は、HTMLファイルのHEADセクションの内側に配置する必要があります。

- metaタグには次の構文を使用します。

<meta NAME="idctype" CONTENT="form; version=1.0">

4.2.4.1.4 変数とインクルード

HCSFページのHEADセクションには、必要に応じて、変数定義とHTMLインクルードが含まれる場合があります。HEADセクションの中で、デフォルトのページ・タイトルを定義し、std_html_head_declarationsコードをロードする行を、例4-6に示します。

例4-6 HCSFページのHEADセクションにおける変数定義とインクルード

!--$defaultPageTitle="Department News Form"-->
<!--$include std_html_head_declarations-->

4.2.4.2 データ・セクション

HCSFページのデータ・セクションには、フォームの処理に使用されるルールおよびメタデータ情報が含まれます。データ・セクション内の情報とページの表示との間には、次のように緊密な関係があります。

- HCSFページがユーザーに配信された時点で、データ・セクション内の情報がDataBinderオブジェクトに解析され、フォーム・セクションにマージされます。

- フォームが送信された時点で、データ・セクション内の情報がリクエストとマージされ、データ・セクションに再び書き出されます。詳細は、第9章「データ・バインダ」および第9.1.3.1.1項「HDAファイル内の要素」を参照してください。

4.2.4.2.1 データ・セクションの構造

例4-7に示すように、データ・セクションは、Idocスクリプトのタグidcbegindataとidcenddataの間に配置されたXML要素で構成されます。

例4-7 HCSFページのデータ・セクション

<!--$idcbegindata-->
<idcformrules isFormFinished="0"/>
<model_number content="html">AB-123</model_number>
<revision>12</revision>
…
<!--$idcenddata-->

データ・セクションには次のルールが適用されます。

- データ・セクションは、HTMLファイルの、フォーム・セクションの先頭より前にある<BODY>セクションの内側に配置する必要があります。

- Idocスクリプトの変数定義とインクルードは、データ・セクションの中ではなく、前後に配置します。

- データ・セクションで使用されるXML要素のタイプは、次の2つです。

- idcformrules要素

- メタデータ要素

- データ・セクションでは、次のタイプの書式設定を使用することもできます。

- ネストされた要素

- XML要素の参照

- フォーム要素

- ResultSet

4.2.4.2.2 idcformrules要素

idcformrules要素では、データ・セクションにおけるコンテンツ・サーバーのルールを定義します。この要素では、isFormFinishedとresultsetsのいずれか1つの属性が必要です。

- IsFormFinished属性: isFormFinished属性は、フォームを再送信できるかどうかを示します。

- フォームを再送信可能と指定する場合は、次の属性値を使用します。

<idcformrules isFormFinished="0"/>

- フォームを再送信不可能と指定する場合は、次の属性値を使用します。

<idcformrules isFormFinished="1"/>

このコードでは、読取り専用のフォームになります。

- resultsets属性: resultsets属性は、データ・セクション内のいずれのXML要素がResultSetと解釈されるかを示します。

- この属性では、1つ以上のXMLタグ名をカンマで区切って指定します。次に例を示します。

<idcformrules resultsets="volume,chapter">

- ユーザーへのHCSFページの配信中に、コアのコンテンツ・サーバーがresultsets属性を読み取り、必要に応じて、名前を指定した空のResultSetをDataBinderオブジェクトに配置して、マージに利用できるようにします。
データ・セクションにおけるResultSetの書式設定の詳細は、第4.2.4.2.7項「ResultSet」を参照してください。

4.2.4.2.3 メタデータ要素

メタデータ要素では、ブラウザにフォームを表示するときにフォーム・フィールドに表示されるメタデータ値を指定します。次に例を示します。

<model_number>AB-123</model_number>

各メタデータ要素には、その要素にどのタイプのコンテンツが含まれるかを示すcontent属性を割り当てることができます。次に例を示します。

<model_number content="html">AB-123</model_number>

- content属性の値としては、htmlとtextのいずれかが可能です。textは、この要素のコンテンツを、厳密にテキストと解釈することを示します。htmlは、この要素のコンテンツをHTMLと解釈することを示します。

- メタデータ要素にcontent属性が指定されていない場合は、デフォルトでhtmlが設定されます。

- Content Publisherでは、content属性以外の属性はすべて無視されます。

4.2.4.2.4 ネストされた要素

HCSFページをContent Publisherによってパブリッシュしない場合は、データ・セクション内でネストされたXML要素(別名ノード)を使用できます。例4-8は、<chapter>要素内でネストされた<section>要素を示しています。

例4-8 データ・セクション内でネストされたXMLタグ

<chapter title="Chapter 1">
This is the beginning of the chapter.
<section title="First Section">
This is the first section of the chapter.
</section>
</chapter>

注意:
ネストされたXML要素は、Content Publisherでは許可されません。

4.2.4.2.5 XML要素の参照

ネストされたXML要素を参照するには、ルートレベルの要素から始め、要素レベルの間に感嘆符(!)を使用します。次に例を示します。

chapter!section

任意の要素の属性を参照するには、タグ名の後ろにコロン(:)を使用します。次に例を示します。

chapter!section:title

- データ・セクション内の要素を参照する場合は、次の文のいずれかが真の場合にのみ、フォームの送信時に要素の値を元のデータ・セクションにマージできます。

- root要素がすでに、データ領域で参照されています。

- root要素が、ExtraRootNodesフォーム要素内で参照されています。

- タグの接頭辞部分が、resultsetsフォーム要素内のResultSetとして参照されています。

- デフォルト値は、タグ・パスに:default接尾辞を適用することによって指定できます。デフォルトの要素には、後で評価できるように、Idocスクリプトが含まれている場合もあります。例4-9に、dDocTitleのデフォルト値を指定するための書式を示します。

例4-9 メタデータのデフォルト値の指定

<input type=hidden name="dDocTitle:default" value="<$'MyTitle ' & dateCurrent()$>">0

4.2.4.2.6 フォーム要素

- ExtraRootNodesフォーム要素を使用すると、フォームのデータ・セクション内のタグを指定するのではなく、Idocスクリプトの変数を作成してそれにタグ名を付加することによってタグを追加できます。フォームの最後で、ExtraRootNodesの値に文字列の値を代入して、元のデータ・セクションにマージできます。

- resultsetsフォーム要素を使用すると、データ・セクション内のResultSetを指定するのではなく、ResultSetとしてタグを追加できます。

- ExtraRootNodesフォーム要素とresultsetフォーム要素では、カンマで区切られたタグのリストを使用します。

idcformrules resultsets属性にmychapters!chapter要素がまだ定義されていない場合に、有効なResultSetとしてそれを追加するフォーム要素を、例4-10に示します。また、必要に応じて、ルート要素mychaptersも追加されます。

例4-10 ResultSetに要素を追加するフォーム要素

<input type=hidden name="resultsets" value="mychapters!chapter">
<input type=hidden name="ExtraRootNodes" value="mychapters">

4.2.4.2.7 ResultSet

次のように、HCSFページのデータ・セクション内のXML要素を使用して、ResultSetを定義できます。

- idcformrules要素のresultsets属性を使用して、ResultSetを指定する必要があります。

- 要素名は完全修飾されている必要があり、ルート・ノードからの参照のフルパスを使用する必要があります。

- ResultSetの列は、要素コンテンツおよび要素属性です。

ResultSetでのXML要素の繰返しとネストに対する制限については、例4-13と例4-15を参照してください。

例4-11は、volumeとchapterという2つのResultSetを定義するXML要素を示しています。

例4-11 HCSFページのデータ・セクションにおけるResultSetを定義するためのXML要素

<idcformrules resultsets="volume,chapter">
<volume title="First Volume">
Volume content here
</volume>
<chapter title="First Chapter">
Chapter content here
</chapter>

このコードでは、それぞれ2つの列を持つ2つのResultSetに評価されます。例4-12は、これらのResultSetを示しています。

例4-12 XML要素で定義されたResultSet

@ResultSet volume
2
volume
volume:title
Volume content here
First Volume
@end
@ResultSet chapter
2
chapter
chapter:title
Chapter content here
First Chapter
@end

HCSFページをContent Publisherによってパブリッシュしない場合は、データ・セクション内でResultSetに対して繰り返された要素を使用できます。繰り返された要素は通常、コードをループ処理してResultSetを作成する場合に役立ちます。

ResultSetのために繰り返された要素には次のルールが適用されます。

- 繰り返された要素は、ResultSetの一部でないかぎり許可されません。

- 繰り返されたXML要素は、Content Publisherでは許可されません。

例4-13は、chapter ResultSetのためにchapter要素がどのように繰り返されるかを示しています。

例4-13 ResultSetのために繰り返された要素

<idcformrules resultsets="chapter">
<chapter title="First Chapter">
Some content here
</chapter>
<chapter title="Second Chapter">
More content here
</chapter>

このコードでは、2つの列と2つの行を持つResultSetに評価されます。例4-14は、このResultSetを示しています。

例4-14 繰り返された要素で作成されたResultSet

@ResultSet chapter
2
chapter
chapter:title
Some content here
First Chapter
More content here
Second Chapter
@end

ResultSetにはネストされた要素があってかまいませんが、例4-15に示すように、ネストされた要素を親要素内で繰り返すことはできません。この例に示したコードでは、最初の<chapter>要素内で<section>要素を追加しようとしても許可されません。

例4-15 ResultSetのために繰り返されたネスト済要素

<idcformrules resultsets="chapter">
<chapter title="First Chapter">
Some content here
<section title="First Section of First Chapter">
Section content
</section>
</chapter>
<chapter title="Second Chapter">
More content here
</chapter>

例4-16に示すように、このコードでは、4つの列と4つの行を持ち、最後の2つのセルが空白のResultSetに評価されます。

例4-16 繰り返されたネスト済要素で作成されたResultSet

@ResultSet chapter
4
chapter
chapter:title
chapter!section
chapter!section:title
Some content here
First Chapter
Section Content
First Section of First Chapter
More content here
Second Chapter

@end

ResultSetの編集には、次のガイドラインが適用されます。

- ResultSet内の特定の行を更新するには、リクエスト・パラメータでResultSetの行番号を指定する必要があります。シャープ記号(#)がコンテンツ・サーバーによって使用され、特定の行を示します。#文字を使用して行を指定しない場合は、行が付加されます。まだ存在していない行番号を指定した場合は、十分な空の行が追加されて、編集対象となる行が提供されます。
例4-17は、ResultSetの最初の行(行0)を更新する方法を示しています。

例4-17 ResultSetでの行の要素

<input type="text" name="comment#0"
value="new comment">
<input type="text" name="comment!title#0"
value="new title"

- 感嘆符(!)を使用して、ResultSetに新規の行を挿入します。
たとえば、comment ResultSetに作成者とタイトルのフィールドを挿入するには、入力フィールドにcomment!authorとcomment!titleという名前を付けることができます。これらのフィールドがResultSetにまだない場合は、フォームの送信時に追加されます。

- ResultSetから行を削除するには、例4-18に示すように、すべてのフィールド値を空にして、空白となるようにします。

例4-18 ResultSetからの最初の行の削除

<input type="hidden" name="comment#0" value="">
<input type="hidden" name="comment!title#0" value="">
<input type="hidden" name="comment!date#0" value="">
<input type="hidden" name="comment!author#0" value="">

ResultSetから行を削除するための別の方法としては、DeleteRowsフォーム要素を、ResultSet名と行番号のカンマで区切られたペアのリストに設定します。たとえば、comment ResultSetから行2を削除し、book ResultSetから行5を削除するには、DeleteRowsフォーム要素を次のコンマで区切られたペアに設定します。

comment:2,book:5

4.2.4.3 フォーム・セクション

フォーム・セクションには、HTMLフォーム要素の表示など、ページに必要な機能のためのコードが含まれます。アセンブルされたWebページのフォーマットを制御するために、HTML表内に、フォーム・プロパティ、フォーム・フィールドおよびフォーム・ボタンが配置されます。

コードの例は、第4.6.1項「フォームの共通コード」を参照してください。

4.2.4.3.1 フォームの先頭

例4-19に示すように、フォーム・セクションの先頭は、2行のIdocスクリプトです。

例4-19 フォーム・セクションを開始するためのIdocスクリプト

<!--$formName="HTMLForm"-->
<!--$include std_html_form_submit_start-->

the std_page.idocリソース・ファイルのstd_html_form_submit_startインクルードには、POSTメソッドを使用して標準的なHTMLフォームを作成し、IdcServiceをSUBMIT_HTML_FORMに設定して、dID変数を現在のHCSFページの値に設定するためのコードが含まれます。例4-20は、このコードを示しています。

例4-20 HCSFページの標準的なHTMLフォーム

<form name="<$formName$>" method="POST"action="<$HttpCgiPath$>">7
<input type=hidden name="IdcService"value="SUBMIT_HTML_FORM">
<input type=hidden name="dID" value="<$SourceID$>">

4.2.4.3.2 フォーム・プロパティ

フォーム表は通常、プロパティの定義で始まります。この定義とは、フォーム・フィールドとしてフォームを作成し、そのフィールドを編集可能にして、フィールド・キャプション領域のサイズを設定するものです。例4-21は、これらのプロパティ定義を示しています。

例4-21 フォーム表のフィールド・プロパティ定義

<!--$isFormSubmit=1,isEditMode=1-->
<!--$captionFieldWidth=200, captionEntryWidth=80-->

4.2.4.3.3 フォーム・フィールド

例4-22に示すように、それぞれの入力フィールドを作成するには通常、数行のコードが使用されます。

例4-22 フォーム上に入力フィールドを作成するためのコード

<!--$eval("<$product_name:maxLength=250$>")-->
<!--$fieldName="model", fieldCaption="Model Number"-->
<!--$include std_display_field-->

注意:
表示が適切に行われるようにするために、追加のコードが必要となるフィールドもあります。たとえば、テキスト領域のサイズを増やすために、標準的なstd_memo_entryインクルードを無効にすることが必要になる場合があります。そのためには、次のように、IDOCファイルにカスタム・インクルードを定義します。

<@dynamicalhtml std_memo_entry@>
<textarea name="<$fieldName$>" rows=15 cols=50 wrap=virtual><$fieldValue$></textarea>
<@end@>

- DataScript: DataScriptというフォーム・フィールドを、送信されているフォームに追加した場合、その値に対するIdocスクリプトがあれば、コンテンツ・サーバーがフォームを処理するときにそのスクリプトを評価します。
(HCSPフォーム内のデータ・アイランドから生成された)表が2つあり、1つの表の中にあるエントリがもう1つの表の中のエントリを参照しています。最初の表の行を更新するときに、2番目の表の特定の列および行の値を変更することが目標です。この値変更を行うために、例4-23に示すように、Idocスクリプトを使用し、JavaScriptを記述してDataScriptの値を設定できます。

例4-23 表の行を更新するときの、別の表のフィールド値の変更

modifyRowAndColumn(row, column, value)
{
document.myform.DataScript = "<$setValue('#local', 'table2!'"+ column + "#'"+ row +
"','" + value + "')$>";
}

次に、更新フォームの送信中に、column = "myColumn"、row="1"、value = "Test"とした関数をコールすると、送信前のDataScript値は次のようになります。

DataScript.value = <$setValue('#local', 'table2!myColumn#1', 'Test')$>

フォームが送信された後、表table2の行1の列table2!myColumnが更新されて、値Testが反映されます。

DataScriptを使用すると、データ・アイランドにある他のエントリを、その名前を参照するHTMLフォーム・フィールドを実際に作成しなくても、自由に編集できると言うこともできます。

4.2.4.3.4 フォームのボタン

フォームの送信ボタンとリセット・ボタンを作成するには通常、2行のコードが使用されます。例4-24は、これらの行を示しています。

例4-24 フォームの送信ボタンとリセット・ボタンを作成するためのコード

<input type=submit name=Submit value=" Submit ">
<input type=reset name=Reset value="Reset">

4.2.4.3.5 フォームの末尾

フォーム要素とデフォルト値がすべて定義された後、</form>タグでフォームを終了する必要があります。

4.3 動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルの作成

動的サーバー・ページが相互に連携することによって、コンテンツ・サーバーの動作を変更することができます。動的サーバー・ページを作成できるようにするには、参照するページ用のカスタム・インクルードを含むIDOCファイルを作成しておく必要があります。

動的サーバー・ページ用のカスタム・インクルードを含むIDOCファイルを作成する手順は次のとおりです。

1. 例4-25に示す書式で、カスタム・インクルードを含むIDOCファイルを作成します。

例4-25 カスタム・インクルード

<@dynamichtml HelloWorld@>
<H1>Hello World/<H1>
<@end@>

この例では、最初のインクルードはHelloWorldと名付けられ、2番目のインクルードでは、HTMLコードを1行定義しています。

2. 拡張子を.idocとしてこのファイルを保存します(例、helloworld.idoc)。

3. このIDOCファイルをコンテンツ・サーバーにチェックインします。このとき、helloworldのように、別のファイルから参照できるコンテンツIDを指定します。

このIDOCファイルは、参照元のいずれのHCS*ページでも利用可能です。

4.4 HCSTページの作成

HCSTファイルでIDOCファイルを参照することによって、HCST動的サーバー・ページを作成できます。

HCSTページを作成する手順は次のとおりです。

1. 例4-26に示すHCSTファイルのような、IDOCファイル内のインクルードを参照するHCSTファイルを作成します。

例4-26 カスタム・インクルードを参照するHCSTファイル

<HTML>
<HEAD>
<$docLoadResourceIncludes("dDocName=helloworld&RevisionSelectionMethod=LatestReleased")$>
</HEAD>
<BODY>
You should see it:
<$include HelloWorld$>
</BODY>
</HTML>

この例では、<HEAD>タグの後の行によってhelloworld.idocファイルがロードされ、IDOCファイル内のインクルードがこのHCSTページで利用可能となります。<BODY>タグの後の2番目の行によって、helloworld.idocファイルのHelloWorldインクルードのコードが表示されます。Idocスクリプトの標準的なタグ<$...$>が使用されていることに注意してください。

2. 拡張子を.hcstとしてこのファイルを保存します(例、helloworld.hcst)。

3. HCSTファイルをコンテンツ・サーバーにチェックインします。

4.5 HCSPページの作成

HCSPファイルでIDOCファイルを参照することによって、HCSP動的サーバー・ページを作成できます。

HCSPページを作成する手順は次のとおりです。

1. 例4-27に示すHCSPファイルのような、IDOCファイル内のインクルードを参照するHCSPファイルを作成します。

例4-27 カスタム・インクルードを参照するHCSPファイル

<HTML>
<HEAD>
<!--$docLoadResourceIncludes("dDocName=helloworld&amp;RevisionSelectionMethod=LatestReleased")-->
</HEAD>
<BODY>
You should see it:

<!--$include HelloWorld-->
</BODY>
</HTML>

この例では、<HEAD>タグの後の行によってhelloworld.idocファイルがロードされ、IDOCファイル内のインクルードがこのHCSPページで利用可能となります。<BODY>タグの後の2番目の行によって、helloworld.idocファイルのHelloWorldインクルードのコードが表示されます。HTMLコメント・タグ<!--...-->が使用されていることに注意してください。

2. 拡張子を.hcspとしてこのファイルを保存します(例、helloworld.hcsp)。

3. HCSPファイルをコンテンツ・サーバーにチェックインします。

4.6 HCSFページの作成

一般的なHCSFページとそれに関連付けられたIDOCファイルを例4-28に示します。この例では、ユーザーが記入して送信し、コンテンツ・アイテムとして製品の説明を入力できるフォームを作成します。

HCSFページを作成する手順は次のとおりです。

1. 例4-28に示すように、form_std_pageというIDOCファイルを参照するHCSFファイルを作成します。

例4-28 HCSFファイル内の製品の説明フォーム

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<!--$docLoadResourceIncludes("dDocName=form_std_page&amp;
RevisionSelectionMethod=Latest")-->

<head>
<meta NAME="idctype' CONTENT="form; version=1.0">

<!--$include form_head_section-->

</head>

<!--$include form_pre_xml_section-->

<!--$idcbegindata-->
<idcformrules isFormFinished="0"/>
<product_name content="html">

</product_name?
<model_number content="html">
SC-
</model_number>
<summary_description>
Enter a summary here.
</summary_description>
<full_description>
Enter a full description here.
</full_description>
<author>
<division>
Household Products
</division>
<revision>

</revision>
<!--$idcenddata-->

<!--$include form_post_xml_section-->

</body>
</html>

この例では、htmlタグの後の行によって、form_std_pageをコンテンツIDとするIDOCファイルがロードされ、IDOCファイル内のインクルードがこのHCSFページで利用可能となります。

これがコンテンツ・サーバーのHTMLフォームであるとContent Publisherで認識されるようにするには、metaタグが必要です。

form_std_page IDOCファイルに定義されている、metaタグの後の2つのインクルードによって、Webページの先頭にコードが生成されます。

idcformrulesタグのisFormFinished属性によって、フォームが未完成であることがコンテンツ・サーバーに伝えられるため、フィールドを編集してフォームを送信できます。

タグごとにcontentプロパティを設定する必要はなく、デフォルトでhtmlが設定されます。

idcbegindataタグとidcenddataタグによってXMLタグ付き領域が定義され、それによって、フォームのルールおよび初期メタデータが指定されます。

XMLタグの各セットのテキストが、フォーム上の対応するフィールドに入力されます。

form_std_page IDOCファイルに定義されている、この例の最後のインクルードによって、Webページの末尾にコードが生成されます。

2. product_form.hcsfとしてこのファイルを保存します。

3. HCSFファイルをコンテンツ・サーバーにチェックインします。

4. 例4-29に示すように、カスタム・インクルードを含むIDOCファイルを作成します。

例4-29 カスタム・インクルードを含むIDOCファイル

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<body>

<@dynamichtml form_head_section@>
<!--standard includes for a standard hcsp page-->
<$defaultPageTitle="Product Description Form"$>
$include std_html_head_declarations$>
<@end@>

<@dynamichtml form_pre_xml_section@>
<!--This code is here for static viewing.-->
<$if 0$>
<body>
<$endif$>

<$include body_def$>
<@end@>

<@dynamichtml form_post_xml_section@>

<$include std_page_begin$>
<$include std_header$>

<$formName="HTMLForm"$>
<$include std_html_form_submit_start$>

<table>

<$if strEquals(ref:dExtension,"hcsf"))$>
<$isHcsf=1$>
<$else$>
<$isHcsp=1$>
<$endif$>

<$if isHcsf$>
<$isFormSubmit=1,isEditMode=1$>
<$endif$>

<$captionFieldWidth=150, captionEntryWidth=200$>

<$eval("<$product_name:maxLength=250$>")$>
<$fieldName="product_name", fieldCaption="Product Name"$>
<$if isHcsp$><isInfoOnly=1$><$endif$>
<$include std_display_field$>

<$eval("<$model_number:maxLngth=250$>")$>
<$fieldName="model_number", fieldCaption="Model Number"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<$fieldName="summary_description",
fieldCaption="Summary Description",
fieldType="Memo"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<fieldName="full_descripton",
fieldCaption="Full Description",
fieldType="Memo"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<$eval("<$author:maxLength=250$>")$>
<$fieldName="author", fieldCaption="Author"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<$eval("<$division:maxLength=250$>")$>
<$fieldName="division", fieldCaption="Division"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<$eval("<$revision:maxLength=250$>")$>
<$fieldName="revision", fieldCaption="Revision"$>
<$if isHcsp$><$isInfoOnly=1$><$endif$>
<$include std_display_field$>

<tr>
<td colspand=2><hr></td>
</tr>
<tr>align=center>
<td colspan=2>
<$if isHcsf$>
<input type=submit name=Submit value=" Submit ">
<input type=reset name=Reset Value="Reset">
<$endif$>
<input type=hidden name="dDocTitle:default"
value="<$"Product Description  " & dateCurrent()$>">
</td>
</tr>
</table>
</form>
<$include std_page_end$>

<@end@>

</body>
</html>

この例では、form_head_sectionインクルードによって、ページ・タイトルと、(std_page.htmリソース・ファイル内のstd_html_head_declarationsインクルードを参照する)HTMLの標準的なheadセクションのコードが定義されます。

form_pre_xml_sectionインクルードによって、ページが静的に表示できるようになり、(std_page.htmリソース・ファイル内のbody_defインクルードを参照する)コンテンツ・サーバーの標準的なWebページのコードが定義されます。

form_post_xml_sectionインクルードでは、フォーム・フィールドが定義されます。std_page.htmリソース・ファイルに定義されている、std_page_beginインクルードとstd_headerインクルードによって、コンテンツ・サーバーの標準的なWebページのコードが定義されます。これらのインクルードの後の2行によって、フォーム名と、(std_page.htmファイル内のstd_htm_form_submit_startインクルードを参照する)HTMLの標準的なフォームのコードが定義されます。

tableタグの後の条件では、これが送信済で編集可能なフォームまたはページであるかが、ファイル名の拡張子に基づいて判別されます。これが編集可能なページ(isHcsf=1)の場合は、次の条件によって、フィールドをフォーム・フィールドとして作成して編集可能にする変数が設定されます。条件の後の行では、フィールド・キャプションの表セルの幅が150ピクセルに設定され、入力フィールドの表セルの幅が200ピクセルに設定されています。

eval関数では、テキスト・フィールドの最大長が250文字に設定されています。

fieldNameタグでは、フィールドの名前、キャプションおよびタイプが定義されます。fieldTypeが定義されていない場合は、デフォルトでTextが設定されます。

これが送信済のフォーム(isHcsp=1)の場合は、if isHcsp条件によって、フォーム・フィールドを読取り専用にする変数に設定されます。

std_page.htmリソース・ファイルに定義されているstd_display_fieldインクルードによって、フォーム・フィールドを作成するコードが定義されます。

これが編集可能なフォーム(isHcsf=1)の場合は、if isHcsf条件によって、「送信」ボタンと「リセット」ボタンが作成されます。

if isHcsf条件の後の行では、ドキュメント・タイトル(dDocTitle)が自動的に生成されます。

std_page.htmリソース・ファイルに定義されているstd_page_endインクルードによって、Webページの末尾にコードが生成されます。

5. form_std_page.idocとしてこのファイルを保存します。

6. このIDOCファイルをコンテンツ・サーバーにチェックインします。このとき、コンテンツIDをform_std_pageに指定します。(これは、HCSFページによって参照される名前です。)

7. コンテンツ・サーバーでHCSFコンテンツ・アイテムを検索します。

8. フォームを表示するためのリンクをクリックして、WebブラウザにHCSFページを作成します。フォームは、図4-2のサンプルのようになります。

図4-2 Webブラウザに表示するHCSFページを作成するためのフォーム

9. サンプルの値をいくつか使用してフォームに記入し、「送信」をクリックします。
HCSPページとしてコンテンツ・アイテムが作成されます。

10. コンテンツ・サーバーでHCSPページを検索します。

11. WebブラウザにHCSPページを表示するためのリンクをクリックします。図4-3は、ページがどのように表示されるかを示しています。

図4-3 HCSPページ

4.6.1 フォームの共通コード

HCSFページおよび関連付けられているIDOCファイルで広く使用されている機能は次のとおりです。

- ファイル情報の取得

- ファイル拡張子の参照

- フォーム情報の定義

- フォーム・フィールドの定義

- 非表示フィールドの定義

- フォームの送信

4.6.1.1 ファイル情報の取得

サービスDOC_INFO_SIMPLEを実行すると、特定のファイルのメタデータがページで利用可能になります。例4-30は、このサービスを実行するためのIdocスクリプトを示しています。

例4-30 メタデータを取得するためのIdocスクリプト

<$dID=SourceID$>
<$executeService("DOC_INFO_SIMPLE")$>

4.6.1.2 ファイル拡張子の参照

例4-31に示すように、フォームのif文でファイル拡張子を参照して、フォームが送信済(.hcspファイル)か未送信(.hcsfファイル)かを判別できます。

例4-31 ファイル拡張子を参照するための文

<$if (strEquals(ref:dExtension,"hcsf"))$>
<$isHcsf=1$>
<$else$>
<$isHcsp=1$>
<$endif$>

ref:接頭辞については、第4.2.1.4項「メタデータの参照」を参照してください。

4.6.1.3 フォーム情報の取得

例4-32に示すように、2行のコードによって、フォーム名と、HTMLフォームを開始するための標準的なインクルードが定義されます。

例4-32 HTMLフォームの名前と標準的なインクルード

<$formName="HTMLForm"$>
<$include std_html_form_submit_start$>

例4-33は、フォーム・プロパティを定義するための一般的なコードを示しています。

例4-33 フォーム・プロパティ

<table border=0 width=100%>
<$isEditMode=1,isFormSubmit=1$>
<$captionFieldWidth="25%", captionEntryWidth="75%"$>

4.6.1.4 フォーム・フィールドの定義

例4-34に示すように、フォーム・フィールドを表示するには、標準的なIdocスクリプト変数とstd_display_fieldインクルードを使用します。

例4-34 フォーム・フィールドを表示するための標準的なIdocスクリプト

<$fieldName="news_author",fieldDefault=dUser,fieldCaption="Author",isRequired=1,requiredMsg = "Please specify the author."$>
<$include std_display_field$>

フィールドが正しく表示されるようにするために、追加のコードが必要となるフィールドもあります。たとえば、メモの標準的なテキスト領域は縦が3行、横が40列ですが、テキスト領域のサイズを増やすために、標準的なインクルードを無効にすることが必要になる場合があります。例4-35は、標準的なstd_memo_entryインクルードを示しています。

例4-35 メモ・フィールドの標準的なインクルード

<@dynamichtml std_memo_entry@>
<textarea name="<$fieldName$>" rows=3 cols=40 wrap=virtual> <$fieldValue$></textarea>
<@end@>

指定したサイズ(この場合は、縦が15行、横が50列)にテキスト領域を増やすために、カスタムstd_memo_entryインクルードを使用する方法を、例4-36に示します。

例4-36 メモ・フィールドのカスタム・インクルード

<@dynamichtml std_memo_entry@>
<textarea name=<$fieldName$> rows=15 cols=50 wrap=virtual><$fieldValue$></textarea>
<@end@>

4.6.1.5 非表示フィールドの定義

コントリビュータが変更できない非表示フィールドを定義することによって、送信されたフォーム(HCSP)のメタデータを指定できます。たとえば、次のコードでは、送信された各フォームにドキュメント・タイプNews_Formsが割り当てられます。

<input type=hidden name="dDocType" value="News_Forms">

次のコードでは、送信されたフォームのセキュリティ・グループが指定されます。

<input type=hidden name="dSecurityGroup" value="Public">

4.6.1.6 フォームの送信

フォームの送信時に、Java関数をコールして追加の検証または処理を実行することもできます。次に例を示します。

<input type=button name=Submit value="Save" onClick="postCheckIn(this.form)">

4.7 HCST、HCSP、HCSFの各ページのWebブラウザでの表示の確認

HCST、HCSP、HCSFいずれかのファイルを保存した後で、例4-37に示すように、Webブラウザでのページ表示を確認できます。

例4-37 HCSTページとHCSPページの表示

1. コンテンツ・サーバーでhelloworldコンテンツ・アイテムを検索します。

2. WebブラウザにHCSTファイルとHCSPファイルを表示します。両方とも、図4-4の例のようになります。

図4-4 Webブラウザに表示されるHelloWorldコンテンツ・アイテム

「図4-4 Webブラウザに表示されるHelloWorldコンテンツ・アイテム」の説明

第III部

コンテンツ・サーバーの機能の変更

この部では、Oracle WebCenter Content Serverの基本機能を変更する方法について説明します。

第III部は、次の章で構成されています。

- 第5章「システム設定の変更」

- 第6章「構成情報の変更」

- 第7章「サービスのカスタマイズ」

- 第8章「アクション・メニューの生成」

5 システム設定の変更

この章では、Oracle WebCenter Content Serverの基本機能を変更する方法について説明します。

この章では、次の項目について説明します。

- 第5.1項「システム設定の変更について」

- 第5.2項「管理サーバーを使用したシステム設定の変更」

- 第5.3項「システム・プロパティ・アプリケーションを使用したシステム設定の変更」

- 第5.4項「Webレイアウト・エディタを使用したライブラリおよびシステム・ホーム・ページのカスタマイズ」

- 第5.5項「ユーザー管理アプリケーションを使用したユーザーのセキュリティおよびアカウントの定義」

この章で示している手順は、Oracle WebLogic Serverでシステム設定を変更するためのものです。Oracle WebCenter Contentは、IBM WebSphere Application Serverにデプロイすることもできます。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

5.1 システム設定の変更について

Oracle WebCenter Content Serverには、ニーズに応じてシステム全体の機能を変更するために設定できる機能が数多く用意されています。たとえば、コンテンツ管理システムの設定をカスタマイズするには、Oracle WebCenter Content Server内にある次の管理ツールを使用できます。

- 管理サーバー

- システム・プロパティ・ユーティリティ

- Webレイアウト・エディタ

- ユーザー管理アプリケーション

- その他の管理カスタマイズ
これらのツールを使用してシステム設定を変更することに加えて、別のやり方で他の設定を変更して自社のサイトのニーズを満たすことができます。

- 「管理アプレット」メニューから利用できるワークフロー管理ツールを使用して、ワークフローを設計、カスタマイズおよび実装できる

- 構成マネージャを使用して、新規のカスタム・メタデータ・フィールドを作成してデフォルト値を設定できる

- コンテンツ・プロファイルを使用して、カスタマイズされたアクション画面(チェックイン、検索、チェックアウトなど)を作成できる

5.2 管理サーバーを使用したシステム設定の変更

管理サーバーは、Oracle WebCenter Content Serverのシステム全体の設定を構成するときに使用できるWebページの集まりです。これらのWebページにアクセスするには、管理サーバーのメイン・ページが表示されるポータル・ナビゲーション・バーの「管理」トレイから「管理サーバー」をクリックします。このページからは、実行中の各サーバーのステータスを確認したり、コンソール出力を確認することができます。

管理サーバーを使用したシステム設定の変更の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のシステム設定の管理に関する項を参照してください。

5.3 システム・プロパティ・アプリケーションを使用したシステム設定の変更

コンテンツのセキュリティ、インターネット設定、ローカライゼーションなどの設定について、Oracle WebCenter Contentのシステム全体の設定を構成する場合には、システム・プロパティ管理アプリケーションを使用します。システム・プロパティ・アプリケーションでは、次のオプションを設定できます。

- コンテンツ・サーバーのオプション機能

- コンテンツ・アイテムのセキュリティに関連するオプション

- インターネットおよびWebとの対話に関連するオプション

- JDBC接続性オプション

- タイムゾーンやIPフィルタなどの機能

- ローカライゼーション機能

- ディレクトリ・パス

Oracle WebCenter Contentのシステム・プロパティを設定するための主要なツールはアプリケーション・サーバーですが、目的によっては、システム・プロパティ・アプリケーションを使用する必要があります。これらのオプションを設定するには、管理レベルの権限は不要で、インスタンスがインストールされているディレクトリにアクセスするだけです。

システム・プロパティ・アプリケーションを使用したシステム設定の変更の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のシステム設定の管理に関する項を参照してください。

5.4 Webレイアウト・エディタを使用したライブラリおよびシステム・ホーム・ページのカスタマイズ

ライブラリおよびシステム・ホーム(ポータル)ページのカスタマイズには、Webレイアウト・エディタを使用します。このエディタにアクセスするには、「管理アプレット」ページで「Webレイアウト・エディタ」をクリックします。Webレイアウト・エディタ内では、ライブラリ内のローカルWebページの構成を変更し、自社のサイトの新規ポータル・ページを構築できます。自社のローカル・サイトの外のWebサイトへのリンクを作成します。

Webレイアウト・エディタでWebページの作成に使用できる画面については、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のWebレイアウト・エディタのインタフェースに関する項を参照してください。

5.5 ユーザー管理アプリケーションを使用したユーザーのセキュリティおよびアカウントの定義

ユーザー管理機能を使用して、自社のサイトのユーザーのセキュリティ・グループ、エイリアス、ロールおよびアカウントを定義できます。この画面にアクセスするには、メニューの「管理」トレイから「管理アプレット」を選択して、ユーザー・ページの管理アプレットで「ユーザー管理」をクリックします。この画面にあるオプションは、エイリアスの作成、セキュリティ・グループの権限の設定、ロールおよびそれらのロールに関連付けられている権限の確立、およびユーザーに関して格納されている情報のカスタマイズを行うために使用します。

詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のセキュリティおよびユーザー・アクセスの管理に関する項を参照してください。

6 構成情報の変更

この章では、Idocスクリプトのカスタム・スクリプト言語を使用して、または他の開発ツールおよびテクノロジを使用して、Oracle WebCenter Content Serverの構成を変更する方法について説明します。

この章では、次の項目について説明します。

- 第6.1項「構成情報の変更について」

- 第6.2項「Idocスクリプトのカスタム・スクリプト言語を使用した構成の変更」

- 第6.3項「他の開発ツールおよびテクノロジを使用した構成の変更」

6.1 構成情報の変更について

構成情報は、コンテンツ・サーバーのサーバー側の専用スクリプト言語であるIdocスクリプトを使用して変更できます。Idocスクリプトを使用すると、変数を参照したり、条件付きでコンテンツをHTMLページに含めたり、問合せから返された結果をループ処理できます。Idocスクリプトは(クライアント側でなく)サーバー側で評価されるため、ページ要素が評価されるのは、ブラウザが要求してから、要求されたページがクライアントに返されるまでの間です。

高度なカスタマイズ、および他のビジネス・システムとの統合には、コンテンツ・サーバーでサポートされている、他の開発ツールおよびテクノロジを使用できます。

6.2 Idocスクリプトのカスタム・スクリプト言語を使用した構成の変更

Idocスクリプトは主に、次の状況で使用されます。

- インクルード・コードの場合、インクルードは、Oracle WebCenter Content Server Webページの作成に使用されるコードを定義します。これは、リソース・ファイル内で一度定義されたら、必要に応じてテンプレート・ファイルによって参照されます。インクルードは、ほとんどすべてのOracle WebCenter Content Server Webサイトで使用されます。
既存のインクルードに対する例外を定義するスーパー・タグも使用できます。スーパー・タグはインクルードに対して、既存のインクルードで始め、指定されたコードを使用して、そのインクルードに追加するか、またはそのインクルードを変更するように指示します。

- 変数の場合は、変数を使用してOracle WebCenter Content Serverの動作をカスタマイズできます。変数の値は、config.cfgファイルなどの環境リソースに格納でき、Oracle WebCenter Content Serverで事前設定されているものも数多くあります。独自のカスタム変数を定義することもできます。

- 関数の場合は、数多くの組込みグローバル関数がOracle WebCenter Content Serverで使用されています。これらによって、日付フォーマットや文字列比較などのアクションが実行されます。結果を返す関数もあれば、「プロファイル」ページにあるようなパーソナライズ機能に使用される関数もあります。

- 条件の場合は、コードをテストしたり、アセンブルされたWebページにコードを含めたり、アセンブルされたWebページからコードを除外する場合に、条件を使用できます。

- ループの場合は、Idocスクリプトを使用して利用できるループ処理には2つのタイプがあります。1つはResultSetループで、問合せから返されたResultSetの行ごとに、一連のコードが繰り返されます。もう1つはwhileループで、これは条件付きループです。

- 管理領域(ワークフローのカスタマイズ、Webレイアウト、アーカイバ、検索式など)において。

使用方法、構文および構成変数については、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

6.3 他の開発ツールおよびテクノロジを使用した構成の変更

高度なカスタマイズ、および他のビジネス・システムとの統合のために、コンテンツ・サーバーでは、次の開発ツールおよびテクノロジをサポートしています。

- VBScript

- ASP

- J++

- JavaScript

- ASP+

- J2EE

- Java

- JSP

- COM

- Visual Basic

- DreamWeaver

- .Net

- C++

- Visual InterDev

7 サービスのカスタマイズ

この章では、Oracle WebCenter Content Serverのサービスをカスタマイズする方法について説明します。

この章では、次の項目について説明します。

- 第7.1項「サービスのカスタマイズについて」

- 第7.2項「コンテンツ・サーバーと通信するためのサービスのカスタマイズ」

- 第7.3項「データベースにアクセスするためのサービスのカスタマイズ」

7.1 サービスのカスタマイズについて

コンテンツ・サーバーのサービスは、Oracle WebCenter Content Serverで実行される関数またはプロシージャです。Oracle WebCenter Content Serverと通信したりデータベースにアクセスするには、Oracle WebCenter Content Serverのサービスをコールする(サービス・リクエストを行う)ことが唯一の方法です。

いずれのサービスも、(Oracle WebCenter Content Serverの外から)外部的にコールするか、 (Oracle WebCenter Content Server内から)内部的にコールできます。クライアント・サービスは通常、外部的にコールされ、管理サービスは内部的にコールされます。サービスでは、サービスに渡された任意のパラメータに基づいて、サービス自体の属性、およびリクエストを実行するアクションを使用します。

Oracle WebCenter Content Serverの標準的なサービスは、DomainHome/resources/core/tables/std_services.htmのStandardServices表に定義されています。サービス定義には、メインの要素として次の3つが含まれています。

- サービス名。

- サービス属性。サービスの次の面を定義します。

- サービス・クラス: サービスからアクセスできるJavaクラスを指定します。これによって、サービスで実行できるアクションが決定されます。

- アクセス・レベル: サービスにユーザー権限レベルを割り当てます。

- テンプレート・ページ: サービスの結果を表示するテンプレートを指定します。

- サービス・タイプ: サービスを別のサービス内でサブサービスとして実行する場合に指定します。

- 通知された件名: サービスによって通知されるサブシステムを指定します。

- エラー・メッセージ: アクション・エラー・メッセージによってオーバーライドされない場合、サービスによって返されます。

- サービス・アクション。アクションの次の面を定義する、コロンで区切られたリストです。

- アクション・タイプ

- アクション名

- アクション・パラメータ

- アクション制御マスク

- アクション・エラー・メッセージ

サービスを理解して使用することは、コンポーネントの作成とOracle WebCenter Content Serverのカスタマイズにおける不可欠の部分です。詳細は、第18章「環境へのWebCenter Contentの統合の開始」を参照してください。

7.2 コンテンツ・サーバーと通信するためのサービスのカスタマイズ

クライアントでは、コンテンツ・サーバーと通信するためのサービスを使用しています。クライアントとサーバーどちらの側からもサービス・コールを実行できるため、Webブラウザのクライアントの代理としても、システム自体の内部でもサービスを実行できます。

サービスの詳細は、第15.2.7項「サービス」を参照してください。

サービスのカスタマイズの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドのサービスのカスタマイズに関する項を参照してください。

7.3 データベースにアクセスするためのサービスのカスタマイズ

クライアントでは、Oracle WebCenter Contentデータベースにアクセスするためのサービスを使用しています。いずれのプログラムでもHTMLページでも、コンテンツ・サーバーに情報を要求するサービスを使用できます。

サービスの詳細は、第15.2.7項「サービス」を参照してください。

サービスのカスタマイズの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドのサービスのカスタマイズに関する項を参照してください。

8 「アクション」メニューの生成

この章では、「アクション」メニューを生成する方法について説明します。

この章では、次の項目について説明します。

- 第8.1項「「アクション」メニューの生成について」

- 第8.2項「表示表の作成」

- 第8.3項「「アクション」メニューのカスタマイズ」

8.1 「アクション」メニューの生成について

以前のバージョンのOracle WebCenter Content Serverでは、コンポーネントの作者は、検索結果ページで使用される表のようなHTML表を作成して、HTMLコードをコピーおよび貼付けする必要がありました。表の中の情報はHTMLと混合しており、データと表示は区切られていませんでした。

同じ問題は、アクション・メニューにも当てはまっていました。表およびメニューではデータと表示が緊密に結合していたため、CSS変更で行われた変更を除き、Oracle WebCenter Content Serverのすべての表に対してグローバルな変更を実行することはできませんでした。表とメニュー両方の特定の面を、コンポーネントでターゲットにしたり変更することも困難でした。

ページのアクション・メニューをカスタマイズするために、開発者は、次のインクルード・ファイルのいずれかを無効にして、PageMenusData結果セットを変更することができます。これらのインクルードはすべて、DomainHome/resources/core/resources/std_page.idocファイルに定義されています。

- custom_searchapi_result_menus_setup

- custom_docinfo_menus_setup

- custom_query_page_menus_setup

- custom_audit_info_menus_setup

さらに、データの結果セットを設定し、そのデータを使用してページを表示する特定のリソース・インクルードを呼び出すことによって、検索結果ページで使用されていたような表を作成できます。結果セットは、「キュー内のワークフロー」ページや「検索結果」ページにあるようなアクション・メニューの作成にも使用できます。

アクション・メニューとHTML表の表示フレームワークを使用すると、開発者は、システムの残り部分のルック・アンド・フィールと一致する迅速かつ柔軟なWebページを作成できます。また、コンポーネントの作者がこれらを使用すると、サーバー上の「ヘッドライン表示」表と「サムネイル表示」表のいずれか、またはすべて、さらにアクション・メニューのいずれかに対して、拡張、追加およびオーバーライドを容易に行うことができます。

8.2 表示表の作成

次の表示タイプごとに、検索結果ページには別々の表が使用されます。

- ヘッドライン表示

- サムネイル表示

例8-1に示すように、どのような表の設定でも、最初の手順の1つは、表示するドキュメントを取得することです。

例8-1 ドキュメントを取得するためのコード

<$QueryText = "dDocAuthor <matches> `sysadmin`"$>
<$executeService("GET_SEARCH_RESULTS")$>

8.2.1 「ヘッドライン表示」表

次の例は、「ヘッドライン表示」表の作成方法を示しています。ここで説明する概念は、他の表タイプの作成にも使用されます。

例8-2に示すように、このプロセスの最初の手順は、表の列を記述する結果セットを作成することです。

例8-2 表の列を記述するためのResultSet

<$exec rsCreateResultSet("ColumnProperties",
"id,width,headerLabel,rowAlign")$>

<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "dDocName"$>
<$ColumnProperties.width = "150px"$>
<$ColumnProperties.headerLabel = lc("wwDocNameTag")$>
<$ColumnProperties.rowAlign = "center"$>

<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "dDocTitle"$>
<$ColumnProperties.width = "auto"$>
<$ColumnProperties.headerLabel = lc("wwTitle")$>
<$ColumnProperties.rowAlign = "left"$>

<$exec rsAppendNewRow("ColumnProperties")$>
<$ColumnProperties.id = "actions"$>
<$ColumnProperties.width = "75px"$>
<$ColumnProperties.headerLabel = lc("wwActions")$>
<$ColumnProperties.rowAlign = "center"$>

ColumnPropertiesという結果セットが作成されます。表の各行は、作成する表の列に対応しています。各列には、いくつかの属性を関連付けることができます。より共通性の高い属性をいくつか、次に示します。

- id: これは必須の属性です。作成中の表の各列には、IDを関連付ける必要があります。このIDは、あらゆる行で何を表示するかを決定するために、後で使用されます。

- width: 列の幅。これは、100px、15em、autoなどのCSS幅宣言のいずれかにでき、これによってサイズが自動指定され、表のできるだけ多くの部分が埋められます。

- headerLabel: この列のヘッダーに表示するテキスト。

- rowAlign: コンテンツを左詰め、右詰め、中央揃えのいずれにするかを示すもの。

- headerURL: 列ヘッダーのテキストをURLにリンクするために使用されます。

例8-3に示すように、次の手順は、表の各行にどのデータを表示するかを指定することです。

例8-3 結果セットに表示するデータ

<$exec rsCreateResultSet("RowData","dDocName,dDocTitle,actions")$>
<$exec rsAppendNewRow("RowData")$>
<$RowData.dDocName = "<$dDocName$>"$>
<$RowData.dDocTitle = "<$dDocTitle$>"$>
<$RowData.actions = "<$include doc_info_action_image$>"$>

ColumnProperties結果セットには、技術的に表の各列に行がある一方、RowDataにある行は1つのみです。この結果セットに入力されるデータは、次の形式になります。

<$RowData.%COLUMN_ID% = "%IDOCSCRIPT%"$>

RowData結果セットの各列は、最終的な表に表示される実際の列を参照します。この結果セットの各列には、前に宣言されたColumnProperties結果セットで対応するIDがあります。この結果セットの各セルには、Idocスクリプトの式が割り当てられます。さらに、これがHTMLドキュメントに書き込まれるにつれて、各行の表示中に評価されます。

次に、表に各行を表示するために、リソース・インクルードを作成する必要があります。

<$include create_slim_table_row_include$>

このリソース・インクルードを呼び出すと、slim_table_row_includeリソース・インクルードが作成されます。RowData結果セットの解析と評価は、表の行ごとに行うのでなく、一度だけ行われます。

複数の行インクルードを設定するには(たとえば、アイテムのタイプごとに別々の行を表示する単一の表の場合)、次の手順を使用します。

1. RowData結果セットを削除して再作成します。

2. 作成するリソース・インクルードの名前にrowIncludeNameを設定します。

3. create_slim_table_row_includeをもう一度インクルードします。

例8-4は、表を表示するコードを示しています。

例8-4 表を表示するためのコード

<$include slim_table_header$>
<$loop SearchResults$>
<$include slim_table_row_include$>
<$endloop$>
<$include slim_table_footer$>

表の外観を検索結果ページの表のようにするには、スクリプトで次の値を設定します。

<$UseRowHighlighting = true$>

「ヘッドライン表示」表に、ある特殊なカスタマイズを行うと、コンポーネントの作者または管理者は誰でも、任意の列のデータの表示方法を簡単にオーバーライドできます。例8-5は、コンポーネント内から宣言できるカスタム・インクルードを示しています。

例8-5 コンポーネント内でのカスタム・インクルード宣言

<@dynamichtml slim_table_title@>
<b><$dDocTitle$></b>
<@end@>

dDocTitle:slimTableCellInclude=slim_table_titleがIntradocDir/config/config.cfgファイルに追加されるか、またはスクリプト内から設定された場合は、定義されたカスタム・インクルードを使用して、dDocTitleを列IDとする「ヘッドライン表示」表がすべて表示されます。これによって、これらの列ではRowDataが無効となります。

8.2.2 「サムネイル表示」表

「サムネイル表示」の表は、別のやり方で作成されます。ColumnProperties結果セットとRowData結果セットは作成されません。そのかわり、例8-6に示すように、列の数が設定され、各セルのペイントにはIdocスクリプトのインクルード名が使用されます。これは、他の方法に比べて、カスタマイズの容易さもデータドリブン性も劣っていますが、このタイプの表は、構造もずっと単純です。

例8-6 「サムネイル表示」表のセルのコード

<$numDamColumns = 4$>
<$damCellIncludeName = "my_sample_dam_cell"$>
<$include dam_table_header$>
<$loop SearchResults$>
<$include dam_table_item$>
<$endloop$>
<$include dam_table_footer$>

8.3 「アクション」メニューのカスタマイズ

カスタマイズの最初の手順は、 Actions列に「アクション」メニュー・アイコンを追加することです。例8-7では、前に使用されたサンプルの「ヘッドライン表示」表の各行に、アクション・メニューを組み込んでいます。

例8-7 行にアクション・メニューを組み込むためのコード

<$RowData.actions = "<$include action_popup_image$>" &
" <$include doc_info_action_image$>"$>

これによって、適切な列にアクション・イメージが挿入されます。ただし、それをクリックしても何も起りません。実際のメニューがHTMLページに書き込まれているわけではないからです。例8-8は、このメニューの作成に使用するデータを作成するコードを示しています。

例8-8 「アクション」メニューを作成するためのデータ

<$exec rsCreateResultSet("PopupProps",
"label,onClick,function,class,id,ifClause")$>

<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwCheckOut")$>
<$PopupProps.function = "<$HttpCgiPath$>?IdcService=CHECKOUT" &
"&dID=<$dID$>&dDocName=<$url(dDocName)$>" &
"&dDocTitle=<$url(dDocTitle)$>"$>
<$PopupProps.class = "document"$>
<$PopupProps.id = "checkout"$>

<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwGetNativeFile")$>
<$PopupProps.function = "<$HttpCgiPath$>?IdcService=GET_FILE" &
"&dID=<$dID$>&dDocName=<$url(dDocName)$>" &
"&allowInterrupt=1"$>
<$PopupProps.ifClause = "showNativeFileLink"$>
<$PopupProps.class = "document"$>
<$PopupProps.id = "getNativeFile"$>

<$exec rsAppendNewRow("PopupProps")$>
<$PopupProps.label = lc("wwTest")$>
<$PopupProps.function = "javascript:alert('<$js(dDocName)$>');"$>
<$PopupProps.ifClause = "showTestAction"$>
<$PopupProps.class = "debug"$>
<$PopupProps.id = "alertDocName"$>

このコードでは、PopupPropsという結果セットが作成され、各行は作成中のメニューのアクションに対応します。各アクションには、いくつかの属性を関連付けることができます。より共通性の高い属性をいくつか、次に示します。

- label: アクションのラベルとして表示される文字列。

- function: このアクションに関連付けるURLまたはJavaScriptメソッド。

- class: このアクションの分類。これは、「検索」、「ドキュメント」、「ワークフロー」のように単純なもの、さらにはコンポーネントの名前にすることができます。アクションがグループに配置され、その同じグループ内の残りのアクションで有効か無効かを迅速に設定できます。

- id: 別の分類方法で、「class」よりずっと具体的です。この方法はアプリケーションに固有のもので、これを使用すると、特定のアクションがメニュー内に表示されないようにすることができます。

- ifClause: そのアクションをHTMLドキュメントに書き込もうとするたびに評価されるオプションの属性。この句がFALSEに評価された場合、このアクションは表示されません。

- isDisabled: 1に設定された場合、このアクションは絶対に表示されません。

- linkTarget: このリンクでページを別のウィンドウに表示する場合に使用されます。この属性は、任意のアンカー・タグのターゲットを指します。

例8-9に示すように、このデータが設定されたら、この「アクション」メニューを書き込むIdocスクリプトのリソースの作成に使用できます。

例8-9 「アクション」メニューを書き込むためのリソース

<$include create_action_popup_container_include$>

このリソースは、create_slim_table_row_includeのように機能します。action_popup_container_includeというIdocスクリプトの新規リソースが作成されます。その名前を変更するために、スクリプトで<$actionPopupContainerIncludeName = new_include_name$>と設定できます。

例8-10は、「ヘッドライン表示」表の各行でこのインクルードが呼び出されるようにするコードを示しています。

例8-10 表の各行でインクルードを呼び出すためのコード

<$exec rsCreateResultSet("PopupData", "actions")$>
<$exec rsAppendNewRow("PopupData")$>
<$PopupData.actions="<$include action_popup_container_include$>"$>

このコードでは、RowData結果セットに似たPopupData結果セットが作成されます。これは同じような構造になっており、ユーザーがアクション・イメージをクリックするまで非表示になっているアクション・メニューのコンテナの出力先として使用されます。

ここで作成された表には「アクション」メニューがあり、これは、適切なイメージをクリックするたびに検索結果ページに通常表示されるものに似ています。

これらのアクションの編集は、PopupProps結果セットに行を追加するか、またはその結果セットから行を削除したり、すでに存在している行を編集することによって行われます。このタイプのカスタマイズ以外にも、disabledActionPopupClasses変数およびdisabledActionPopupIds変数を設定することによって、アクションを非表示にすることができます。例8-11に示すように、これらは、config/config.cfgファイルまたはIdocスクリプト自体で設定できます。

例8-11 「アクション」メニューでアイテムを非表示にするためのコード

<$disabledActionPopupClasses = "workflow,folders"$>
<$disabledActionPopupIds = "getNativeFile,alertDocName"$>

これらの変数を設定すると、workflowとfoldersのいずれかをクラスとするアクション、またはgetNativeFileとalertDocNameのいずれかをIDとするアクションが、常に非表示となります。これらの変数を使用すると、Oracle WebCenter Content Serverの管理者およびコンポーネントの作者は、グローバルに、または特定のページで、特定のアクションを非表示にすることができます。

コンポーネントの作者は、Idocスクリプトのリソース・インクルードの数をオーバーライドして、グローバルに、またはターゲットを絞って、この領域の機能を変更できます。次に示すインクルードは、利用可能なリソース・インクルードのごく一部です。

- custom_add_to_action_popup_data

- custom_modify_action_popup_data

- classic_table_row_pre_display

- slim_table_row_pre_display

- custom_row_pre_display

第IV部

コンポーネントによるコンテンツ・サーバーのカスタマイズ

この部では、Oracle WebCenter Content Serverのコンポーネント(コンテンツ・サーバーの機能を変更するプログラム)を操作する方法について説明します。

第IV部の内容は次のとおりです。

- 第9章「コンテンツ・サーバーのコンポーネントの開始」

- 第10章「コンテンツ・サーバーのコンポーネントの有効化と無効化」

- 第11章「コンポーネント構成の更新」

- 第12章「Content Trackerのカスタマイズ」

- 第13章「Content Categorizerのカスタマイズ」

- 第14章「カスタム・コンポーネントのダウンロード」

- 第15章「カスタム・コンポーネントの作成」

- 第16章「コンポーネントのインストール」

- 第17章「コンポーネントのアンインストール」

9 コンテンツ・サーバーのコンポーネントの開始

この章では、Oracle WebCenter Content Serverのコンポーネント(コンテンツ・サーバーの機能変更に使用されるプログラム)を操作する方法について説明します。

この章では、次の項目について説明します。

- 第9.1項「標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントについて」

- 第9.2項「コンポーネントを管理するためのツール」

- 第9.3項「コンポーネント・ファイル」

- 第9.4項「Webページをアセンブルするためのリソース」

9.1 標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントについて

コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンテンツ・サーバーのコアな標準機能を追加または変更するために、コンテンツ・サーバーには、標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントが含まれています。

9.1.1 コンポーネント・ファイルの概要

カスタム・コンポーネントを定義するときには、次のファイルを作成または変更します。

- idcshort-product-id_components.hdaファイル: どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。

- コンポーネント定義(またはglue)ファイル: カスタム・コンポーネントのリソースがどこにあるかをコンテンツ・サーバーに伝えます。

- 異なるカスタム・リソース・ファイル: コンテンツ・サーバーの標準リソースに対するカスタマイズを定義します。

- テンプレート・ファイル: カスタム・テンプレート・ページを定義します。

- その他のファイル: コンテンツ・サーバーのグラフィック、Javaコード、ヘルプ・ファイルなどに対するカスタマイズが含まれています。

これらのファイルの詳細は、第9.1.3項「ディレクトリおよびファイルについて」を参照してください。

コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。

- HDA

- HTM

- CFG

- Java CLASS

コンポーネント・ウィザードでコンポーネントを構築または解凍する場合、あるいはコンポーネント・マネージャでコンポーネントをアップロードおよびダウンロードする場合は、次のファイルを使用します。

- 圧縮されたZIPファイル: 他のコンテンツ・サーバーのインスタンスにコンポーネントをデプロイするために使用されます。

- manifest.hdaファイル: コンポーネントZIPファイルから解凍またはアップロードされたファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。

9.1.2 コンポーネントの使用

コンポーネントとは、実行時にOracle WebCenter Content Serverと対話するように設計されたモジュール式のプログラムです。コンポーネント・アーキテクチャ・モデルは、オブジェクト指向のテクノロジから派生したもので、巨大ですべてを包括した(ただし扱いにくい)アプリケーションを作成するのではなく、小さなモジュールを使用して、必要に応じてOracle WebCenter Content Serverをカスタマイズすることを促進しています。

注意:
必要なファイルとリソースを手動で作成することによって、カスタム・コンポーネントを作成できます。ただし、コンポーネント・ウィザードは、手動の方法に比べて制限がなく、これを使用すると、よくある誤りが多く発生することはありません。

コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。

- HDA

- HTM

- CFG

- Java CLASS

コンポーネントは通常、Oracle WebCenter Content Serverのコアな機能を変更するために使用されます。たとえば、コンポーネントは、次のタスクのいずれかを実行するために使用できます。

- 標準的なセキュリティ機能を変更する

- 検索結果が要求され、返されるやり方を変更する

- (Macintoshクライアントや専用のCADプログラムなど)特定のシステムとOracle WebCenter Content Serverが提携できるようにする

Oracle WebCenter Content Serverとともにコンポーネント・アーキテクチャを使用すると、次のメリットが得られます。

- 製品の整合性を損なわずにソース・コードを変更できます。
Oracle WebCenter Content Serverでは、そのリソースの多くが外部のテキスト・ファイルからロードされるため、ファイルを表示してシステムの状況を分析し、そのファイルを要件に合わせてコピーおよび変更できます。

- 複数のプラットフォームにわたり、複数のインスタンスでカスタム・コンポーネントを使用できます。
カスタム・コンポーネントを作成してある場合は、それをZIPファイルとしてパッケージ化し、他のOracle WebCenter Content Serverのインスタンスにロードできます。数多くのカスタム・コンポーネントは、元の開発プラットフォーム以外のOracle WebCenter Content Serverプラットフォームで機能できます。

- トラブルシューティングのために、個別のコンポーネントの有効と無効を切り替えることができます。
カスタマイズをグループ化して、各コンポーネントがOracle WebCenter Content Serverの特定の関数または領域をカスタマイズするようにできます。障害が発生した場合は、コンポーネントを1つずつ無効にすると、トラブルを迅速に隔離できます。

- Oracle WebCenter Content Serverのインスタンスは、カスタマイズを損なわずに再インストールまたはアップグレードできます。
カスタム・コンポーネントは、既存の製品リソースを置換するのではなく、無効にします。Oracle WebCenter Content Serverの標準ファイルを置換しても、カスタマイズに影響が発生しない場合もあります。

カスタム・コンポーネントを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。

- カスタム・コンポーネントによって、システム全体の動作とルック・アンド・フィールが変更されます。変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。

- カスタム・コンポーネントは、Oracle WebCenter Content Serverのコアな機能に対する変更の影響を受ける場合があります。新機能によってコンポーネントの動作が変わる場合があるので、Oracle WebCenter Content Serverの将来のリリースでカスタマイズが機能するという保証はありません。アップグレードするたびに、カスタム・コンポーネントを調べてテストする必要があります。

- 単純なカスタマイズでは、コンポーネントが不要な場合もあります。単純なコンポーネントの数が多いと、管理が難しくなる可能性があります。

コンポーネントをインストールして、Oracle WebCenter Content Serverによる使用を有効にする必要があります。Oracle WebCenter Content Serverに付属しているコンポーネントは自動的にインストールされ、デフォルトで有効か無効になります。カスタム・コンポーネントをインストールして、使用可能にする必要があります。コンポーネントの操作に際しては、次のいくつかのツールが利用可能です。

- コンポーネント・ウィザードを使用すると、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、コンポーネントの新規作成や既存のコンポーネントの変更を行う場合、およびコンポーネントをパッケージ化して他のOracle WebCenter Content Serverのインスタンスで使用できるようにする場合に使用できます。詳細は、第9.2.1項「コンポーネント・ウィザード」を参照してください。

- 拡張コンポーネント・マネージャは、Oracle WebCenter Content Serverでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、新規コンポーネントを追加したり、コンポーネントをOracle WebCenter Content Serverで有効または無効にできます。詳細は、第9.2.2項「拡張コンポーネント・マネージャ」を参照してください。

- ComponentToolは、Oracle WebCenter Content Serverに、コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ユーティリティです。

コンポーネントのアーキテクチャおよび作成の詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

9.1.3 ディレクトリおよびファイルについて

コンポーネントの作成に使用されるファイルは次のとおりです。

- HDAファイル

- カスタム・リソース・ファイル

- manifestファイル

- その他のファイル(サイト用にカスタマイズされたファイル、コンポーネントZIPファイル、カスタム・インストール・パラメータ・ファイルなど)

WebCenter Contentの典型的なディレクトリ構造では、コンポーネントのファイルは、DomainHome/ucm/short-product-id/customディレクトリのcomponentディレクトリに格納されています。

コンテンツ・サーバーでは、変数値や参照キーなどのデータをキャッシュするために、データ・バインダを使用します。

9.1.3.1 HDAファイル

HyperData(HDA)ファイルは、構造化された単純なASCIIファイル形式で、プロパティおよび表データを定義するために使用されます。これは、どのコンポーネントが有効および無効になっているか、またそのコンポーネントの定義ファイルがどこにあるかを判別するために、コンテンツ・サーバーによって使用されるテキスト・ファイルです。

HDAファイル形式が役立つのは、頻繁に変わるデータです。それは、サイズがコンパクトで形式が単純であれば、コンテンツ・サーバーでデータ通信が、より高速かつ簡単になるからです。

HDAファイル・タイプは、次のコンポーネント・ファイルの定義に使用されます。

- コンポーネント・ファイル(idcshort-product-id_components.hda)

- コンポーネント定義ファイル

- manifestファイル

- 動的表リソース・ファイル

- テンプレート・リソース・ファイル

例9-1は、customhelpというコンポーネントを指すidccs_components.hdaファイルを示しています。

例9-1 コンポーネントのidccs_components.hdaファイル

<?hda charset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
@end
@ResultSet Components
2
name
location
customhelp
custom/customhelp/customhelp.hda
@end

9.1.3.1.1 HDAファイル内の要素

それぞれのHDAファイルには、ヘッダー行と、1つ以上のセクションが含まれます。ヘッダー行では、コンテンツ・サーバーのバージョン、キャラクタ・セット、およびHDAファイルのJavaエンコーディングが特定されます。HDAファイルにダブルバイト(アジア言語)の文字が含まれている場合は、正しいキャラクタ・セットとエンコーディングを指定して、コンテンツ・サーバーがファイルを適切に読み取れるようにする必要があります。ヘッダー行はシングルバイト文字には不要ですが、HDAファイルに含めておくことをお薦めします。

PropertiesとResultSetという2種類のセクションは、コンポーネント開発に該当します。これらのセクションは、ファイルのプロパティ(名前や場所など)や、データの表または列および行を定義するResultSetを定義する場合に使用されます。ResultSetは、問合せの結果を表すことがよくあります。それ以外のセクションのタグはすべて、内部アプリケーションでの使用に目的が限定されています。

HDAファイルのセクション内では、コメントは許可されません。ただし、最初のセクションの前、セクションとセクションの間、または最後のセクションの後であれば、HDAファイルにコメントを配置できます。HDAファイルのセクション内の空白行は、NULL値と解釈されます。最初のセクションの前、セクションとセクションの間、または最後のセクションの後の空白行は無視されます。HDAファイルには、必須のセクション・タイプがないため、未使用のセクションは削除できます。

- Propertiesセクションには、名前と値のペアのグループが含まれます。カスタム・コンポーネントの場合、Propertiesセクションで最も一般的な名前はLocalDataであり、これは、名前と値のペアが、現在のHDAファイルに対してのみ有効という意味です。
EnvironmentというPropertiesセクションで、名前と値のグローバルなペアを定義することもできますが、このセクションが使用されることはめったにありません。config.cfgなどの構成ファイルで、グローバルな環境変数を定義することをお薦めします。

例9-2は、HDAファイルのPropertiesセクションを示しています。

例9-2 HDAファイルのPropertiesセクション

@Properties LocalData
PageLastChanged=952094472723
LocationInfo=Directory,Public,
IsJava=1
refreshSubMonikers=
PageUrl=/intradoc/groups/public/pages/index.htm
LastChanged=-1
TemplatePage=DIRECTORY_PAGE
IdcService=PAGE_HANDLER
LinkSelectedIndex=0
PageName=index
HeaderText=This is a sample page.  The Page Name must remain index.  The Page Properties for this index page should be customized.
PageFunction=SavePage
dSecurityGroup=Public
restrictByGroup=1
PageType=Directory
PageTitle=Content Server Index Page
@end

- HDAファイルの各ResultSetセクションでは、データの表または列および行を定義します。ResultSetは、データベースに情報を渡すか、またはデータベース問合せの結果を表すために使用できます。ResultSetセクションの構造を次に示します。

- 最初の行では、@ResultSet resultset_nameという形式を使用して、ResultSet表の名前を定義します。

- 2番目の行では、列の数を定義します。

- 次のn行では、列名を定義します。

- 残りの行では、表の各セルの値を定義します。

- セクションの最後の行は、@endという形式を使用して、この表を終了しています。

例9-3は、列が4つ、行が3つあるScoresというResultSetを示しています。

例9-3 HDAファイルのResultSetセクション

@ResultSet Scores
4
name
match1
match2
match3
Margaret
68
67
72
Sylvia
70
66
70
Barb
72
71
69
@end

次の表は、ResultSetデータを列形式で示しています。ResultSetには、どのような名前でも指定できます。

name

match1

match2

match3

Margaret

68

67

72

Sylvia

70

66

70

Barb

72

71

69

コンテンツ・サーバーでは、事前定義されたResultSetをいくつか、次の名前で使用します。それらの名前は、カスタム・コンポーネントの表には使用しないでください。

ResultSet名

場所

目的

Components

IntradocDir/data/components/idcshort-product-id_components.hda

作成した任意のカスタム・コンポーネントの名前と場所を定義します。short-product-idの短縮製品ID(cs、ibr、urm)を指定する必要があります。

IntradocReports

IdcHomeDir/resources/core/reports/reports.hda

コンテンツ・サーバーのデフォルトのレポート・テンプレートを指定します。

IntradocTemplates

IdcHomeDir/resources/core/templates/templates.hda

コンテンツ・サーバーのデフォルトのテンプレートをすべて指定します(検索結果テンプレートとレポート・テンプレートは除く)。

ResourceDefinition

DomainHome/ucm/short-product-id/custom/component_name/component_name.hda

カスタム・コンポーネントのリソースを定義します。

SearchResultTemplates

IdcHomeDir/resources/core/templates/templates.hda

コンテンツ・サーバーのデフォルトの検索結果テンプレートを指定します。

9.1.3.1.2 idccs_components.hdaファイル、idcibr_components.hdaファイルまたはidcurm_components.hdaファイル

idcshort-product-id_components.hdaファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えるテキスト・ファイルです。

idcshort-product-id_components.hdaファイルは常に、IntradocDir/data/componentsディレクトリに格納されています。必要に応じてこのファイルを変更するために、コンポーネント・ウィザード、コンポーネント・マネージャおよびComponentToolを使用できます。

注意:
リリース11gR1では、components.hdaファイルとedit_components.hdaファイルが、idcshort-product-id_components.hdaという1つのファイルに結合されました。管理サーバーでidcshort-product-id_components.hdaファイルが見つからず、レガシー・ファイルが見つかった場合は、そのレガシー・ファイルのデータが移行され、適切なデータを含むidcshort-product-id_components.hdaファイルが作成されます。

例9-4は、スキーマ・コンポーネント、構成の移行コンポーネント、SOAPコンポーネントなど、いくつかの有効なコンポーネントをリストしたidccs_components.hdaファイルを示しています。

例9-4 複数の有効なコンポーネントのidccs_components.hdaファイル

@properties LocalData
blDateFormat=M/d/yy
@end
@ResultSet Components
2
name
location
SchemaDCL
custom/SchemaDCL/SchemaDCL.hda
ConfigMigrationUtility
custom/ConfigMigrationUtility/Cmu.hda
Soap
custom/Soap/Soap.hda
@end

9.1.3.1.3 コンポーネント定義ファイル

コンポーネント定義ファイルは、定義したカスタム・リソースを指します。このファイルでは、カスタム・リソース、ResultSetおよびマージ・ルールに関する情報を指定します。このコンポーネント定義ファイルは、コンポーネントをまとめる「glue(接着剤)」の役割を果たすので、glueファイルと呼ばれることもあります。

コンポーネントの定義ファイルは通常、component_name.hdaという名前であり、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。

注意:
idcshort-product-id_components.hdaファイルとcomponent_name.hdaファイルを混同しないでください。idcshort-product-id_components.hdaファイルは、インストールされているすべてのコンポーネントの追跡に使用されます。component_name.hdaファイルには、1つのコンポーネントに固有の情報が含まれます。

9.1.3.2 カスタム・リソース・ファイル

カスタム・リソース・ファイルでは、コンテンツ・サーバーのカスタマイズを定義します。通常はHDAファイルですが、HTMファイルの場合もあります。

コンポーネントのカスタム・リソース・ファイルは通常、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。リソース・ファイルの中には、resources/core/templatesのようなサブディレクトリに配置されるものもあります。

これらのリソースを表9-1に示します。

表9-1 カスタム・リソース・ファイル

リソース・タイプ

ファイル・タイプ

目次

HTMLインクルード

HTM

インクルードの定義

文字列

HTM

ローカライズされた文字列の定義

動的表

HDA

頻繁に変化するデータの表

静的表

HTM

めったに変化しないデータの表

問合せ

HTM

問合せを定義する表

サービス

HTM

サービス・スクリプトを定義する表

テンプレート

HDA

テンプレート・ページの場所とファイル名を定義する表

環境

CFG

構成変数の名前と値のペア

これらのファイルの詳細は、第9.4項「Webページをアセンブルするためのリソース」を参照してください。

また、Webページをアセンブルするために、コンテンツ・サーバーによってtemplate.htmページが使用されます。template.hdmファイルの詳細は、第15.2.8項「テンプレート」を参照してください。

ResultSet HTM表ファイルが、その他のリソースによって使用されます。HTMファイルのResultSet表は、データのレイアウトにHTML表のタグを使用することを除き、HDAファイルのResultSetに似ています。静的表リソース、サービス・リソースおよび問合せリソースはすべて、この表形式を使用しています。

HTMファイルのResultSet表は、先頭が<@table table_name@>で末尾が<@end@>です。開始タグと終了タグの間にあるマークアップがHTML表です。HDAファイル内のResultSetとは異なり、表のタグによって列の数が暗示されています。

データ構造を定義していないHTML構文があれば、表のロード時に無視されます。そのため、HTMファイルの表の中ではHTMLコメントが許可されており、Webブラウザでのデータの表示を向上させるために、HTMLのstyle属性を使用できます。

9.1.3.3 データ・バインダ

コンテンツ・サーバーでは、(変数の値や参照キーなどの)データが、データ・バインダに内部でキャッシュされます。データ・バインダ内のデータはすべて、どこから来たか、またどのように作成されたかに従って分類されます。サービス・リクエストを満たすために値が必要な場合は、データ・バインダ内のデータが、次に示すデフォルトの順序で評価されます。

1. LocalData

2. ResultSet

3. 環境

この優先順位は、Idocスクリプトの関数を使用して変更できます。詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

9.1.3.3.1 LocalData

HDAファイル内の@Properties LocalDataセクションは、データ・バインダのLocalDataカテゴリにマップされます。LocalData情報は、名前と値のペアで構成されています。

LocalData情報が保持されるのは、コンテンツ・サーバーのリクエストとレスポンスが有効になっている期間のみです。めったに変化しないサーバー環境に関する情報と異なり、各リクエストのLocalData情報は動的です。

HTTPリクエストの観点で見ると、LocalDataの初期情報は、REQUEST_METHOD、CONTENT_LENGTH、QUERY_STRINGの各HTTP環境変数から収集されます。サービス・リクエストを処理するときに、LocalDataの名前と値のペアを追加または変更できます。

9.1.3.3.2 ResultSet

HDAファイルの各@ResultSetセクションは、DataBinderオブジェクトにおける名前付き結果にマップされます。いくつかの結果セットがアクティブになって、値検索時に他のResultSetより優先される場合があります。ResultSetは、ページのアセンブリ中にループされたときにアクティブになります。アクティブなResultSetは、DataBinderオブジェクトの値検索時に、他のいずれのResultSetより優先されます。サービス・リクエストにデータが必要で、LocalDataにもアクティブなResultSetにも値が見つからなかった場合は、(アクティブでない)残りのResultSetが次に検索されます。

9.1.3.3.3 環境

環境の値は、名前と値のペアとしてDataBinderオブジェクトに配置されます。このペアは、IntradocDir/config/config.cfg、intradoc.cfg、環境タイプのリソース・ファイルなどの構成ファイルで定義されています。

9.1.3.4 manifestファイル

manifestファイルは、コンテンツ・サーバーにコンポーネントZIPファイルをアップロードまたは展開するために使用されます。このファイルは、コンポーネントZIPファイルに含まれている個別のファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。manifestファイルは、コンポーネント・ウィザードでコンポーネントを構築したとき、または管理サーバーの拡張コンポーネント・マネージャを使用してコンポーネントをダウンロードしたときに、自動的に作成されます。

manifestファイルはすべて、manifest.hdaと呼ぶ必要があります。manifest.hdaファイルは、他のコンポーネント・ファイルとともに、コンポーネントZIPファイルに含まれています。これは、ZIPファイル・ディレクトリ構造の最上位のレベルにある必要があります。

manifest.hdaファイルには、ManifestというResultSet表が含まれており、この表は次の2つの列で構成されています。

- entryType列では、manifestファイルのエントリのタイプを定義しています。

エントリ・タイプ

説明

デフォルトのパス

Classes

Javaクラス・ファイル

DomainHome/ucm/short-product-id/classes

Common

共通ファイル

DomainHome/ucm/short-product-id/weblayout/common

Component

コンポーネント・リソース・ファイル

DomainHome/ucm/short-product-id/custom

ComponentExtra

関連付けられているファイル(readmeなど)

DomainHome/ucm/short-product-id/custom

Help

オンライン・ヘルプ・ファイル

DomainHome/ucm/short-product-id/weblayout/help

Images

グラフィック・ファイル

DomainHome/ucm/short-product-id/weblayout/images

Jsp

JavaServer Pages

DomainHome/ucm/short-product-id/weblayout/jsp

注意:
エントリ・タイプCommon、Help、ImagesおよびJspの使用は避けてください。これらは、WebCenter Content 11gでは非推奨になっているからです。WebCenter Contentには、コンポーネントからweblayoutディレクトリにファイルをプッシュする公開エンジンがあります。以前のリリースと同じ動作を望む場合は、公開エンジンを使用します。そうしないと、公開エンジンによって、カスタム・コンポーネントからweblayoutディレクトリにファイルが直接配置され、既存のファイルが上書きされる場合があります。上書きされたファイルは、永続的に失われる可能性があります。

- location列では、エントリに関連付けられているファイルがインストールされているディレクトリを定義し、一部のエントリ・タイプのファイル名を指定しています。

- Componentエントリ・タイプの場合、場所は定義ファイルのパスとファイル名です。次に定義ファイルは、どのリソース・ファイルがコンポーネントに含まれるかを、コンテンツ・サーバーに伝えます。

- その他のエントリ・タイプの場合、場所は、ファイル名なしのパス(特定のサブディレクトリ内のファイルをすべて指定するとき)、またはファイル名付きのパス(個別のファイルを指定するとき)になります。

- 場所は、DomainHome/ucm/short-product-id/customディレクトリからの相対パスを指定する必要があります。絶対パスを使用することもできますが、その場合は、コンポーネントをインストールできる場所が、インストール・ディレクトリのパスが同じコンテンツ・サーバーのインスタンスのみとなります。

例9-5は、manifest.hdファイルを示しています。

例9-5 manifest.hdaファイル

@ResultSet Manifest
2
entryType
location
component
MyComponent/MyComponent.hda
componentExtra
MyComponent/readme.txt
images
MyComponent/
@end

9.1.3.5 その他のファイル

カスタム・コンポーネントには、機能のために、またはそのルック・アンド・フィールを生成するために、コンテンツ・サーバーが使用する任意のタイプのファイルを含めることができます。

9.1.3.5.1 サイト用にカスタマイズされたファイル

自社サイト用にカスタマイズされたファイルを追加して、コンテンツ・サーバーの外観またはアクションを変更できます。たとえば、カスタム・リソースでは、次のタイプのファイルが頻繁に参照されます。

- グラフィック
標準的なコンテンツ・サーバー・インタフェースを構成するアイコン、背景およびロゴを置換します。

- ヘルプ
コンサルティング・サービスの助けがあれば、コンテンツ管理システム用にヘルプ・ファイルをカスタマイズできます。

- クラス
Javaコードでは、コンテンツ・サーバーの機能を変更または拡張できます。Javaクラス・ファイルは、DomainHome/ucm/short-product-id/classesディレクトリに配置するために、ディレクトリにパッケージ化する必要があります。

注意:
グラフィック・ファイルとヘルプ・ファイルは、weblayoutディレクトリに手動で配置することは避けてください。WebCenter Content 11gの公開エンジンがコンポーネントからweblayoutディレクトリにファイルをプッシュして、ファイルを上書きする場合があるからです。以前のリリースと同じ動作を望む場合は、公開エンジンを使用します。そうしないと、公開エンジンによって、カスタム・コンポーネントからこのディレクトリにファイルが直接配置され、既存のファイルが上書きされる場合があります。上書きされたファイルは、永続的に失われる可能性があります。これらのファイルをweblayoutディレクトリに手動で配置する必要がある場合は、Oracle Consulting Servicesにご連絡ください。

9.1.3.5.2 コンポーネントZIPファイル

コンポーネントZIPファイルには、コンテンツ・サーバーのコンポーネントを定義するファイルがすべて含まれます。これを解凍すると、他のコンテンツ・サーバーのインスタンスにコンポーネントをデプロイできます。

9.1.3.5.3 カスタム・インストール・パラメータ・ファイル

カスタム・インストール・パラメータを1つ以上定義すると、コンポーネント・ファイルの基本構造を構成するファイル以外に、追加のファイルがいくつか作成されます。

コンポーネントのインストール・パラメータが作成された場合は、コンポーネントのインストール・プロセス中に、コンポーネント・インストーラによって、data/componentsディレクトリ内のコンポーネントのディレクトリに、2つのファイルが自動的に配置されます。これらのファイルには、次のようなプリファレンス・データが保持されています。

- config.cfgファイル: インストール後に認識可能となるパラメータが含まれます。

- install.cfgファイル: プリファレンス・データ定義とプロンプトへの応答が含まれます。

- バックアップZIPファイル: コンポーネントが現在インストールされているか、または再インストール中の場合に作成されるバックアップ・ファイル。

9.1.3.6 一般的なディレクトリ構造

コンポーネント・ウィザードを使用してカスタム・コンポーネントを作成した場合は、適切なディレクトリにファイルが格納されます。

カスタム・コンポーネントごとに異なるコンポーネント・ディレクトリが、DomainHome/ucm/short-product-id/customディレクトリに確立されます。各コンポーネント・ディレクトリ内に、レポート、テンプレートおよびリソースの別々のサブディレクトリが確立されます。このとき、それぞれに適切な名前が付けられます(たとえば、component_name/resources)。component_name.hdaファイル(定義ファイル)は、component_nameディレクトリに格納されます。

9.1.4 開発に関する推奨事項

次の各項では、カスタム・コンポーネントの開発を支援するためのガイドラインをいくつか提供します。

- 9.1.4.1項「コンポーネントの作成」

- 第9.1.4.2項「コンポーネント・ファイルでの作業」

- 第9.1.4.3項「開発コンテンツ・サーバーの使用」

- 第9.1.4.4項「コンポーネント・ファイルの編成」

- 第9.1.4.5項「ネーミング規則」

コンポーネントの作成または変更の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』またはオンライン・ヘルプを参照してください。

9.1.4.1 コンポーネントの作成

コンテンツ・サーバーの機能のうち、既存のコンポーネントでは提供されていないものが、自社のサイトで必要になった場合、コンテンツ・サーバーのインスタンスにカスタム・コンポーネントを作成できます。

9.1.4.1.1 カスタム・コンポーネントの作成方法

定義ファイルにカスタム・コンポーネントを作成し、そのコンポーネントを有効にしてコンテンツ・サーバーに適用できます。

カスタム・コンポーネントを作成して有効にする手順は次のとおりです。

1. 定義ファイルを作成します。

2. 定義ファイルへの参照をidcshort-product-id_components.hdaファイルに加えて、このコンポーネントを有効にします。

3. コンテンツ・サーバーを再起動して、このコンポーネントを適用します。

4. リソースなどのファイルを作成して、カスタマイズを定義します。カスタム・リソース・ファイルを作成するには、コンテンツ・サーバーの標準ファイルをコピー、名前変更および変更することをお薦めします。

5. 必要に応じて、カスタマイズをテストして改定します。変更内容を適用するには、コンテンツ・サーバーの再起動が必要になる場合もあります。

6. 後で使用したり他のコンテンツ・サーバーのインスタンスにデプロイできるように、コンポーネントをパッケージ化する場合は、コンポーネントを構築してコンポーネントZIPファイルを作成します。

9.1.4.2 コンポーネント・ファイルでの作業

コンポーネント・ファイルの操作に際しては、次のツールが利用可能です。

- コンポーネント・ウィザード
コンポーネント・ウィザードは、コンテンツ・サーバーのユーティリティの1つで、コンポーネント・ファイルの作成と編集に役立ちます。コンポーネント・ウィザードは、コンポーネントのパッケージ化、解凍、有効化および無効化にも使用できます。このユーティリティの使用の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

- テキスト・エディタ
ほとんどのコンポーネント・ファイルはプレーン・テキスト・ファイルなので、ファイルの作成と編集はお好みのテキスト・エディタでできます。

カスタム・コンポーネントを操作するときは、できるだけコンポーネント・ウィザードを使用してください。

コンポーネント・ウィザードはいくつものタスクをユーザーにかわって行うので、テキスト・エディタでユーザーが行う必要のある作業が最小限に抑えられます。コンポーネント・ウィザードを使用すると、推奨されるファイル構造とネーミング規則を遵守しやすくなります。コンポーネント・ウィザードでは、コンポーネントの構築時にreadmeテキスト・ファイルが自動的に追加され、カスタマイズをドキュメントに残す作業がやりやすくなります。コンポーネント・ファイルにはコメントも含める必要があります。

コンポーネント・ウィザードの使用によるコンポーネント作成の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

9.1.4.3 開発コンテンツ・サーバーの使用

コンテンツ・サーバーをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。本番コンテンツ・サーバーに定義したのと同じカスタム・メタデータ・フィールドを、本番コンテンツ・サーバーに忘れずに含めてください。

開発コンテンツ・サーバーで変更のテストが成功したら、コンポーネント・ウィザードを使用してコンポーネントZIPファイルを構築し、本番システムでコンポーネントを解凍します。

コンポーネントを有効または無効にした後で、コンテンツ・サーバーを忘れずに再起動してください。

カスタム・コンポーネントのインストール後にコンテンツ・サーバーに問題が発生した場合は、そのコンポーネントを無効にしてコンテンツ・サーバーを再起動します。これで問題が解決した場合はおそらく、コンポーネントのトラブルシューティングが必要になります。問題が解決しない場合は、コンポーネント・ウィザードを使用してコンポーネントを完全に除去して、問題がコンポーネントにあるのかコンテンツ・サーバーにあるのかを判別することが必要になると考えられます。

9.1.4.4 コンポーネント・ファイルの編成

カスタム・コンポーネントを整理するには、次のファイル構造ガイドラインを遵守します。詳細は、第9.1.3.6項「一般的なディレクトリ構造」を参照してください。

注意:
コンポーネント・ウィザードを使用した場合は、コンポーネント・ディレクトリが作成され、適切なディレクトリにコンポーネント・ファイルが配置されます。

それぞれのカスタム・コンポーネントは、DomainHome/ucm/short-product-id/customというディレクトリ内の独自のディレクトリに配置してください。リソース・タイプまたはテンプレート・タイプ、あるいはその両方のリソースがカスタム・コンポーネントに含まれている場合、componentディレクトリには、IdcHomeDir/data/resources/coreディレクトリの構造を遵守したサブディレクトリが必要です。

- resources: HTMLインクルードと表リソース・ファイルを保持

- resources/lang: 文字列リソース・ファイルを保持

- templates: テンプレート・ファイルを保持

- reports: レポート・ファイルを保持

ファイルとその編成を検討する際には、次の点を頭に入れてください。

- 各カスタム・コンポーネントの定義ファイルは、コンポーネントのディレクトリの最上位レベルに配置します。

- コンポーネント内の他のファイルを参照するときには、絶対パス名ではなく相対パス名を使用します。相対パス名を使用すると、コンポーネント内のファイルのすべてを編集する必要なしに、コンポーネントを別の場所に移動できます。

- コンテンツ・サーバーはJavaベースのアプリケーションなので、すべてのパス名にスラッシュを使用する必要があります。

- カスタム・コンポーネントをコンテンツ・サーバーと同じコンピュータに格納する必要はありませんが、すべてのコンポーネント・ファイルは、コンテンツ・サーバーのインスタンスからアクセス可能である必要があります。

- イメージなど、コンテンツ・サーバーのWebページによって参照されるオブジェクトは、DomainHome/ucm/short-product-id/weblayoutディレクトリ内のどこかに常駐している必要があります(それによって、Webサーバーからこれらのオブジェクトにアクセスできます)。

9.1.4.5 ネーミング規則

コンポーネント・ファイルを整理して、コンテンツ・サーバーでファイルが適切に動作するようにするには、ディレクトリ、個別ファイルおよびファイルの内容に対して、次のネーミング規則を遵守します。

- コンポーネント・ディレクトリおよびコンポーネント・ファイルのすべてに対して、一意で意味のある名前を指定する必要があります。各コンポーネントがコンテンツ・サーバーにロードされたときに、同じファイル名を持つリソースがあればオーバーライドされるため、重複するファイル名は、特定のコンポーネントを優先させたい場合に限り使用すべきであることを頭に入れてください。

- コンテンツ・サーバーの標準ファイルをコピーする場合、元のファイル名の前に接頭辞としてcustom_を配置することが一般的な手法です。これにより、デフォルトのテンプレートが上書きされることはいっさいなく、カスタマイズは容易に特定できます。

- HTMファイル・タイプの拡張子は.htm、HDAファイル・タイプの拡張子は.hdaとします。

- ワードパッドのようなテキスト・エディタでコンポーネント・ファイルを新規作成した場合には、引用符の内側のファイル名を「保存」ダイアログ・ボックスに配置して、適切なファイル拡張子が割り当てられるようにします(たとえば、myfile.hda)。ファイル名を定義する際に引用符の使用に失敗すると、ファイル名がmyfile.hda.txtのようになる場合があります。

- 大文字と小文字は、ファイル・システムで区別されていなくても、コンテンツ・サーバーでは区別されます。たとえば、ファイル名がMy_Templateの場合、コンテンツ・サーバーでは、my_templateやMY_TEMPLATEのような、大文字と小文字のバリエーションは認識されません。

- ローカライズされた文字列リソースの場合は、コンテンツ・サーバーで文字列が認識されるようにするために、ファイルの標準ネーミング規則を遵守する必要があります。カスタム文字列の名前を付けるときには、標準的な2文字接頭辞(cs、sy、apまたはww)も使用する必要があります。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。

9.2 コンポーネントを管理するためのツール

コンポーネントの管理に使用できるツールは次のとおりです。

- コンポーネント・ウィザード

- コンポーネント・マネージャ

- 拡張コンポーネント・マネージャ

- ComponentTool

9.2.1 コンポーネント・ウィザード

コンポーネント・ウィザード・ユーティリティでは、カスタム・コンポーネントに必要なすべてのファイルの作成や編集など、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、既存のコンポーネントを変更する場合や、コンテンツ・サーバーで使用できるようにコンポーネントのパッケージ化と解凍を行う場合にも使用できます。

図9-1は、コンポーネント・ウィザードへのインタフェースを示しています。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネント・ウィザードの使用に関する項を参照してください。

図9-1 コンポーネント・ウィザードのインタフェース

コンポーネント・ウィザードにアクセスする手順は次のとおりです。

- UNIXオペレーティング・システム: DomainHome/ucm/short-product-id/bin/に格納されているComponentWizardを実行します。
コンポーネント・ウィザードのメイン・ページが表示されます。

- Windowsオペレーティング・システム: 「スタート」メニューからインスタンス名を選択し、「ユーティリティ」、「コンポーネント・ウィザード」の順に選択します。
コンポーネント・ウィザードのメイン・ページが表示されます。

9.2.2 拡張コンポーネント・マネージャ

拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、コンポーネントを有効または無効にしたり、コンテンツ・サーバーに新規コンポーネントを追加することが簡単にできます。

拡張コンポーネント・マネージャを使用する手順は次のとおりです。

1. 「管理」トレイまたはメニューで、「管理サーバー」を選択します。
管理サーバーにコンポーネント・マネージャ・ページが表示されます。

2. コンポーネント・マネージャ・ページの最初の段落で、「拡張コンポーネント・マネージャ」をクリックします。
管理サーバーに、図9-2に示す拡張コンポーネント・マネージャ・ページが表示されます。このページには、有効なコンポーネントと無効なコンポーネントのリストがあります。

図9-2 拡張コンポーネント・マネージャ・ページ

3. 拡張コンポーネント・マネージャ・ページで、次のタスクを実行できます。

- カテゴリなどのフィルタ別に、有効なコンポーネントと無効なコンポーネントのリストを表示する

- コンポーネントを選択して、その詳細を表示する

- コンポーネントを有効化する

- コンポーネントを無効化する

- カスタム・コンポーネントをインストールする

- カスタム・コンポーネントをアンインストールする

詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネント・ウィザードの使用に関する項を参照してください。

9.2.3 ComponentTool

ComponentToolは、Oracle WebCenter Content Serverに、コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ユーティリティです。インストールしたコンポーネントは、ComponentToolによって自動的に有効化されます。ComponentToolは、DomainHome/ucm/cs/binディレクトリにあります。

9.3 コンポーネント・ファイル

idcshort-product-id_components.hdaファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義(glue)ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。11gリリース1(11.1.1)では、このファイルには3つのフォームがあり、idccs_components.hda(Content Server用)、idcibr_components.hda(Inbound Refinery用)、idcurm_components.hda(Records用)というように、WebCenter Contentアプリケーションのそれぞれに1つずつです。このファイルは常に、IntradocDir/data/componentsディレクトリに格納されています。

これらのファイルは、手動で作成しないでください。コンポーネント・ファイルの作成には、必ずコンポーネント・ウィザードを使用します。

9.3.1 idc製品の_components.hdaファイル

idcshort-product-id_components.hdaファイルには常に、各定義ファイルの名前とファイル・パスを定義するComponentsというResultSetが含まれます。コンポーネントのHDAファイルを変更するには、コンポーネント・ウィザードまたはコンポーネント・マネージャを使用できます。詳細は、第10章「コンテンツ・サーバーのコンポーネントの有効化と無効化」を参照してください。

例9-6は、コンテンツ・サーバーで有効にされている2つのコンポーネント、MyComponentとCustomHelpを指定しているidccs_components.hdaファイルを示しています。

例9-6 idccs_components.hdaファイル

<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet Components
2
name
location
MyComponent
custom/MultiCheckin/my_component.hda
CustomHelp
custom/customhelp/customhelp.hda
@end

9.3.2 Components ResultSet

Components ResultSetにコンポーネントがリストされている順序によって、コンテンツ・サーバーの起動時にコンポーネントがロードされる順序が決まります。ResultSetで後にリストされたコンポーネントに、それより前にリストされたコンポーネントと同じ名前のリソースがある場合は、後のコンポーネントのリソースが優先されます。

Components ResultSetには、次の2つの列があります。

- name列には、各コンポーネントの内容を記述した名前が提供されており、この名前は、コンポーネント・ウィザード、コンポーネント・マネージャおよびコンテンツ・サーバーのエラー・メッセージに使用されます。

- location列では、各コンポーネントの定義ファイルの場所を定義しています。この場所は、絶対パス、またはコンテンツ・サーバーのインストール・ディレクトリを基準とした相対パスで指定できます。

注意:
locationパスでは、必ずスラッシュを使用してください。

9.3.3 コンポーネント定義(glue)ファイル

コンポーネント定義ファイル、すなわちglueファイルは、定義したカスタム・リソースを指します。コンポーネントの定義ファイルはcomponent_name.hdaという名前であり、通常はDomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。定義ファイルの作成と変更には、コンポーネント・ウィザードを使用できます。

定義ファイルにはResourceDefinition ResultSetが含まれており、MergeRules ResultSet、Filters ResultSet、ClassAliases ResultSet、またはこれらのResultSetの任意の組合せが含まれる場合もあります。例9-7は、一般的なコンポーネント定義ファイルを示しています。

例9-7 コンポーネント定義ファイル

<?hda jcharset=UTF8 encoding=utf-8?>
@Properties LocalData
classpath=$COMPONENT_DIR/classes.jar
ComponentName=Custom DCL Component
serverVersion=7.3
version=2010_10_22
@end
@ResultSet ResourceDefinition
4
type
filename
tables
loadOrder
template
dcl_templates.hda
DCLCustomTemplates
1
resource
dcl_resource.htm
null
1
resource
dcl_upper_clmns_map.htm
DCLColumnTranslationTable
1
resource
dcl_data_sources.htm
dclDataSources
1
service
dcl_services.htm
CustomServices
1
query
dcl_query.htm
CustomQueryTable
1
resource
dcl_checkin_tables.hda
null
1
@end

@ResultSet MergeRules
3
fromTable
toTable
column
DCLCustomTemplates
IntradocTemplates
name
DCLColumnTranslationTable
ColumnTranslation
alias
DCLDataSources
DataSources
name
CustomDCLServiceQueries
ListBoxServiceQueries
dataSource
@end

@ResultSet Filters
4
type
location
parameter
loadOrder
loadMetaOptionsLists
intradoc.server.ExecuteSubServiceFilter
GET_CHOICE_LIST_SUB
1
@end

9.3.3.1 ResourceDefinition ResultSet

ResourceDefinition ResultSet表では、タイプ、ファイル名、表の名前、およびカスタム・リソースのロード順序が定義されます。例9-8に、ResourceDefinition ResultSetの構造を示します。

例9-8 ResourceDefinition ResultSet

@ResultSet ResourceDefinition
4
type
filename
tables
loadOrder
template
dcl_templates.hda
DCLCustomTemplates
1
resource
dcl_resource.htm
null
1
resource
dcl_upper_clmns_map.htm
DCLColumnTranslationTable
1
resource
dcl_data_sources.htm
dclDataSources
1
service
dcl_services.htm
CustomServices
1
query
dcl_query.htm
CustomQueryTable
1
resource
dcl_checkin_tables.hda
null
1
@end

9.3.3.1.1 ResourceDefinition ResultSetの列

ResourceDefinition ResultSetは、次の4つの列で構成されています。

- type列ではリソース・タイプを定義しており、その値は次のいずれかである必要があります。

- resource: HTMLインクルード(HTM)、文字列(HTM)、動的表(HDA)または静的表(HTM)のリソース・ファイルを指します。

- environment: 環境のリソース(CFG)ファイルを指します。

- template: テンプレートのリソース(HDA)ファイルを指します。

- query: 問合せのリソース(HTM)ファイルを指します。

- service: サービスのリソース(HTM)ファイルを指します。

- filename列では、カスタム・リソース・ファイルのパスとファイル名を定義しています。これには、絶対パスと相対パスのどちらを指定してもかまいません。相対パスは、DomainHome/ucm/short-product-id/custom/component_nameディレクトリを基準にしています。

- tables列では、リソース・ファイルからロードするResultSet表を定義しています。ResultSet名はカンマで区切られています。リソース・ファイルにResultSetが含まれていない場合は、この値はNULLになります。たとえば、HTMLインクルード・リソースには表定義が含まれていないため、HTMLインクルード・ファイルでは、tables列の値は常にNULLとなります。

- loadOrder列では、リソースがロードされる順序を定義しています。リソースは、loadOrderが1のリソースを最初に、昇順でロードされます。loadOrderの同じリソースが複数ある場合、リソースは、ResourceDefinition ResultSetにリストされている順にロードされます。名前の同じリソースが複数ある場合、最後にロードされるリソースは、システムによって使用されるリソースです。通常の場合、あるリソースを常に他のリソースの後にロードする特別な理由がある場合を除き、loadOrderは1に設定してください。

9.3.3.2 MergeRules ResultSet

MergeRules ResultSet表では、カスタム・コンポーネントで定義されている新規の表を特定し、既存の表のうち、新規のデータがいずれの表にロードされるかを指定します。MergeRulesは、カスタム・テンプレートのリソースでは必須ですが、カスタムの動的表および静的表のリソースではオプションです。MergeRulesは、サービス、問合せ、HTMLインクルード、文字列、環境の各リソースでは、必須ではありません。

例9-9に、MergeRules ResultSetを示します。

例9-9 MergeRules ResultSet

@ResultSet MergeRules
4
fromTable
toTable
column
loadOrder
DCLCustomTemplates
IntradocTemplates
name
1
DCLColumnTranslationTable
ColumnTranslation
alias
1
DCLDataSources
DataSources
name
1
CustomDCLServiceQueries
ListBoxServiceQueries
dataSource
1
@end

9.3.3.2.1 MergeRules ResultSetの列

MergeRules ResultSetは、次の3つの列で構成されています。

- fromTable列では、カスタム・リソースによってロードされ、既存のデータとマージされる新規データを含む表を指定します。マージを適切に実行するには、toTable表と同じ数の列および同じ列名が、fromTable表にある必要があります。

- toTable列では、新規データのマージ先となる既存の表の名前を指定します。通常、toTableの値は、IntradocTemplatesやQueryTableなど、コンテンツ・サーバーの標準的な表のいずれかです。

- column列では、データの比較と更新にコンテンツ・サーバーが使用する表の列の名前を指定します。

- コンテンツ・サーバーでは、fromTableとtoTableのcolumnの値を比較します。toTableの現在値と同一のfromTableの値ごとに、toTableの行がfromTableの行に置換されます。toTableの現在値と同一でないfromTableの値ごとに、toTableに新規の行が追加され、fromTableの行のデータが移入されます。

- columnの値は通常、nameです。この値をNULLに設定すると、デフォルトに設定されるのは最初の列であり、それは一般的にname列です。

9.3.3.3 Filters ResultSet

Filters ResultSet表では、新規コンテンツがチェックインされたりサーバーが最初に起動するなど、コンテンツ・サーバーの特定のイベントがトリガされたときにカスタムJavaコードの実行に使用されるフィルタを定義します。例9-10は、標準的なFilters ResultSetを示しています。

例9-10 Filters ResultSet

@ResultSet Filters
4
type
location
parameter
loadOrder
loadMetaOptionsLists
intradoc.server.ExecuteSubServiceFilter
GET_CHOICE_LIST_SUB
1
@end

9.3.3.4 ClassAliases ResultSet

ClassAliases ResultSet表は、コンテンツ・サーバーのJavaクラス全体の機能を拡張するために使用されるカスタムJavaクラス・ファイルを指します。例9-11は、標準的なClassAliases ResultSetを示しています。

例9-11 ClassAliases ResultSet

@ResultSet ClassAliases
2
classname
location
WorkflowDocImplementor
WorkflowCheck.CriteriaWorkflowImplementor
@end

9.4 Webページをアセンブルするためのリソース

リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。リソースには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。

コンポーネントのカスタム・リソース・ファイルは通常、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。コンポーネントに含まれるリソースが多い場合は、コンポーネント・ディレクトリ内のサブディレクトリ(component_name/resourcesやcomponent_name/templatesなど)にファイルを配置すると、維持がしやすくなります。

リソースの作成には、必ずコンポーネント・ウィザードを使用します。リソース・ファイルは手動で作成しないでください。リソース・ファイルの作成後に編集するやり方には、次の2つがあります。

- コンポーネント・ウィザード
リソース・ファイルは、コンポーネント・ウィザードを使用して追加、編集、またはコンポーネントから削除できます。コンポーネント・ウィザードでは、事前定義されたリソースに対して、カスタム・リソースを作成するときの開始ポイントとして使用できるコードが用意されています。リソース・ファイルは、コンポーネント・ウィザード内からテキスト・エディタで開くこともできます。

- テキスト・エディタでの手動編集
リソース・ファイルは、コンポーネント・ウィザードで作成した後に、必要に応じて、テキスト・エディタで開いてコードを手動で編集できます。

詳細は、第15.2項「コンポーネントのリソースの作成」を参照してください。

注意:
リソース・ファイルを変更したら、コンテンツ・サーバーを再起動する必要があります。

10 コンテンツ・サーバーのコンポーネントの有効化と無効化

この章では、Oracle WebCenter Content Serverにインストールされているコンポーネントを有効化する方法と無効化する方法について説明します。

この章では、次の項目について説明します。

- 第10.1項「コンポーネントの有効化と無効化について」

- 第10.2項「コンポーネントの有効化」

- 第10.3項「コンポーネントの無効化」

10.1 コンポーネントの有効化と無効化について

コンポーネントは本来、idcshort-product-id_components.hdaファイルのComponents ResultSetで適切に定義されていれば有効化されます。エントリがないか、またはエントリが正しく書式設定されていなければ、コンポーネントは無効化されます。

10.2 コンポーネントの有効化

次に示すように、コンポーネントを有効化するやり方はいくつかあります。

- ComponentTool: DomainHome/ucm/short-product-id/bin/ComponentToolを実行して、コンポーネントを有効化します。次に例を示します。

ComponentTool -enable component_name

- コンポーネント・ウィザード: 「オプション」メニューから「有効化」を選択します。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

- コンポーネント・マネージャ: コンポーネント名の横にあるチェック・ボックスを選択して、コンポーネント・マネージャ画面で指定されたサーバー・コンポーネントを有効化します。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

- 拡張コンポーネント・マネージャ: 拡張コンポーネント・マネージャ・ページでコンポーネント名を選択し、「有効化」をクリックしてコンポーネントを有効化します。

10.3 コンポーネントの無効化

次に示すように、コンポーネントを無効化するやり方はいくつかあります。

- ComponentTool: DomainHome/ucm/short-product-id/bin/ComponentToolを実行して、コンポーネントを無効化します。次に例を示します。

ComponentTool -disable component_name

- コンポーネント・ウィザード: 「オプション」メニューから「無効化」を選択します。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

- コンポーネント・マネージャ: コンポーネント名の横にあるチェック・ボックスの選択を解除して、コンポーネント・マネージャ画面でサーバー・コンポーネントを無効化します。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

- 拡張コンポーネント・マネージャ: 拡張コンポーネント・マネージャ・ページでコンポーネント名を選択し、「無効化」をクリックしてコンポーネントを無効化します。

11 コンポーネント構成の更新

この章では、Oracle WebCenter Content Serverでのコンポーネントの構成の更新について説明します。

この章では、次の項目について説明します。

- 第11.1項「コンポーネント構成の更新について」

- 第11.2項「拡張コンポーネント・マネージャを使用したコンポーネント構成の更新」

- 第11.3項「「instanceの構成」画面を使用したコンポーネント構成の更新」

11.1 コンポーネント構成の更新について

コンテンツ・サーバーのいくつかのコンポーネントが有効であっても無効であっても、拡張コンポーネント・マネージャまたは「インスタンスの構成」画面を使用して、更新または変更できます。拡張コンポーネント・マネージャには、「コンポーネント構成の更新」フィールドで構成を変更できるコンポーネントのリストがあります。「インスタンスの構成」画面から、指定されたコンポーネントの構成を変更できる場合は、そのコンポーネントの「コンポーネント構成の更新」画面が表示され、変更できない場合はメッセージが表示されます。

コンテンツ・サーバーには、次のコンポーネントに対して「コンポーネント構成の更新」画面があります。

- Folders_g

- PDF Watermark

- Content Tracker

- Content Trackerレポート

- Site Studio

- DesktopIntegrationSuite

- DesktopTag

- EmailMetadata

11.2 拡張コンポーネント・マネージャを使用したコンポーネント構成の更新

拡張コンポーネント・マネージャを使用したコンポーネント構成の更新の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネント構成の変更に関する項を参照してください。

11.3 「instanceの構成」画面を使用したコンポーネント構成の更新

「instanceの構成」画面を使用したコンポーネント構成の更新の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』の「instanceの構成」画面の使用に関する項を参照してください。

12 Content Trackerのカスタマイズ

Content TrackerとContent Trackerレポートは、どちらもOracle WebCenter Content Serverのオプションのコンポーネントで、Oracle WebCenter Contentとともにインストールされます。これらのコンポーネントが有効になっているときには、最もアクセス頻度の高いコンテンツ・アイテムや、ユーザーまたは特定グループにとって最も価値の高いコンテンツなど、システム使用に関する情報が提供されます。これらのコンポーネントをカスタマイズして、組織のコンテンツの消費パターンに関する特定の情報を提供できます。

この章では、次の項目について説明します。

- 12.1項「Content Trackerについて」

- 第12.2項「Content Trackerのコンポーネントおよび機能」

- 第12.3項「構成およびカスタマイズ」

- 第12.4項「サービス・コール構成」

- 第12.5項「Content Trackerのカスタマイズ」

- 第12.6項「Webビーコンの機能」

デフォルト設定でのContent Trackerの使用の詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』を参照してください。

12.1 Content Trackerについて

Content Trackerでは、コンテンツ・サーバーのインスタンスのアクティビティが監視され、それらのアクティビティについて選択した詳細が記録されます。さらに、システムが使用されている方法を示すレポートが生成されます。この項では、Content TrackerおよびContent Trackerレポートの機能について概要を説明します。

Content Trackerには、構成変数で制御される最適化関数がいくつか組み込まれています。これらの変数のデフォルト値によって、大規模な本番環境で可能なかぎり効率的に機能するようにContent Trackerを設定できます。Content Trackerの構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

12.1.1 Content TrackerおよびContent Trackerレポート

Content Trackerでは、様々なアクティビティに関するシステムおよびレコードの情報が監視されます。この情報は様々なソースから収集され、マージされてコンテンツ・サーバー・データベース内の一連の表に書き込まれます。Content Trackerでは、次のアクセスおよびサービスに基づいてアクティビティを監視できます。

- コンテンツ・アイテム・アクセス: コンテンツ・アイテムの使用に関する情報
データは、Webフィルタ・ログ・ファイル、コンテンツ・サーバー・データベース、およびその他の外部アプリケーション(ポータルやWebサイトなど)から取得されます。コンテンツ・アイテム・アクセスのデータには、日付、時刻、コンテンツIDおよび現在のメタデータが含まれます。

- コンテンツ・サーバー・サービス: コンテンツを返すすべてのサービス、および検索リクエストを処理するサービス。デフォルトでは、Content Trackerがログに記録するのは、コンテンツ・アクセス・イベント・タイプを持つサービスのみですが、構成を変更すれば、Content Trackerは、カスタム・サービスまで含め、コンテンツ・サーバーのいかなるサービスでも監視できます。

- ユーザー・アクセス: ユーザー・プロファイルの概要の収集や統合など、コンテンツ・アクセス・イベント以外の他の情報。このデータには、ユーザー名およびユーザー・プロファイル情報が含まれます。

Content Trackerによってデータが抽出され、データベース表に移入された後で、Content Trackerレポートを使用すると、次の処理ができます。

- レポートの生成: Content Trackerレポートを使用すると、表に対して問合せが行われ、アクティビティのサマリー・レポートおよびコンテンツ・アイテムの使用履歴が生成されます。これらのレポートを使用すると、コンテンツまたはユーザーの特定グループを、メタデータ、ファイル拡張子またはユーザー・プロファイルに基づいて分析できます。事前定義されたレポートを使用してカスタマイズするか、または互換性のあるサード・パーティのレポート作成パッケージを使用します。

- コンテンツ管理プラクティスの最適化: レポートされたデータを、コンテンツ保存管理に使用できます。アクセスの頻度によっては、一部のアイテムがアーカイブまたは削除される可能性があります。アプリケーションではこのデータを使用して、特定タイプのユーザーの上位アクセス・コンテンツをポートレットに提供することもできます。

12.2 Content Trackerのコンポーネントおよび機能

Content Trackerにはデバッグ構成変数があり、有効にすると、サービス・ハンドラ・フィルタが構成されてサービスDataBinderオブジェクトがダンプ・ファイル(SctDebugServiceBinderDumpEnable)に書き込まれます。フィールド・マップ画面を開発するときに、これを診断ツールとして使用できます。ダンプ・ファイルを使用すると、特定のサービス・イベントが記録されるときに使用可能なデータを参照できます。

12.2.1 DataBinderダンプ機能

Content Trackerによって特定のサービスがログ・ファイルに記録されると、そのサービスのDataBinderオブジェクトの内容が、シリアル化されたダンプ・ファイルに書き込まれます。これらのファイルの内容は、拡張されたサービス・コール・トラッキング機能を使用するためのフィールド・マップを作成する際に、デバッグ用に役立ちます。これらのダンプ・ファイルを使用して、記録されたサービスに使用可能なLocalDataフィールドを確認できます。

Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトのダンプ・ファイルが作成されるのは、関連付けられたサービスがSctServiceFilter.hdaファイル内に定義されている場合のみです。

注意:
DataBinderオブジェクトのダンプ・ファイルは、手動で削除されるまで蓄積され続けます。必要な場合にかぎり、SctDebugServiceBinderDumpEnabled構成変数を使用します。

12.2.1.1 DataBinderダンプ機能の値

この構成変数の値は、次のとおりです。

- SctDebugServiceBinderDumpEnabled=Falseに設定すると、Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトはダンプ・ファイルに書き出されません。これがデフォルト値になります。

- SctDebugServiceBinderDumpEnabled=Trueに設定すると、DataBinderオブジェクトがダンプ・ファイルに書き出されるようにContent Trackerサービス・ハンドラ・フィルタが構成されます。ダンプ・ファイルは、拡張されたサービス・ロギング用のフィールド・マップを開発する際の診断ツールとして使用します。サービス用のフィールド・マップを作成する場合は、ダンプ・ファイルを使用すると、サービス・イベントの記録時に使用可能なデータを確認できます。

12.2.1.2 DataBinderオブジェクトのダンプ・ファイルの場所

シリアル化されたDataBinderオブジェクトは、次の場所に書き込まれます。

IntradocDir/data/ContentTracker/DEBUG_BINDERDUMP/dump_file_name

12.2.1.3 DataBinderオブジェクトのダンプ・ファイルの名前

DataBinderオブジェクトのダンプ・ファイルはテキスト・ファイルで、その名前は次の3つの部分で構成されます。

service_name_filter_function_serial_number.hda

内容は次のとおりです。

- service_nameは、ログに記録されたサービスの名前(GET_FORM_FILEなど)です。

- filter_functionは次のいずれかです。

- End: フィルタ・イベント「on EndServiceRequestActions」: 正常なサービス終了イベント。

- EndSub: フィルタ・イベント「on EndScriptSubServiceActions」: サブサービスとして呼び出されたサービスの正常なサービス終了。

- Error: フィルタ・イベント「on ServiceRequestError」: エラーが発生したサービスの終了。Endと同時に発生する場合があります。

- serial_numberは、ファイルに割り当てられた一意の識別番号です。これによって、Content Trackerでは、1つの特定のサービスに対してDataBinderオブジェクトのダンプ・ファイルを複数作成できます。

例:

GET_SEARCH_RESULTS_End_1845170235.hda

12.2.2 パフォーマンスの最適化

Content Trackerには、構成変数で制御される最適化関数がいくつか組み込まれています。これらの変数のデフォルト値によって、大規模な本番環境で可能なかぎり効率的に機能するようにContent Trackerを設定できます。

Content Trackerでは、コンテンツ・アクセス・イベントのデータのみが収集および記録されます。この処理では、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルの概要の収集および統合は除外されます。代替値は、インストール時に設定するか、または後で変更できます。

パフォーマンスの変数には、次のものが含まれます。

- SctTrackContentAccessOnly。コンテンツ・アクセスのみ: これにより、収集される情報のタイプが決定します。これを有効(デフォルト)にすると、コンテンツ・アクセス・イベントのみが記録されます。

- SctDoNotPopulateAccessLogColumns。列の除外: これは、Content TrackerでSctAccessLog表に移入されない列のリストです。デフォルトでは、出力表のサイズを削減するために、大規模な情報やほとんど使用しない情報は収集されません。

- SctSimplifyUserAgent。ユーザー・エージェントの簡素化: これによって、SctAccessLog表のcs_userAgent列に格納される情報が最小限になります。

- SctDoNotArchive。アーカイブしない: これによって、データベース表には最近のデータが格納され、期限切れの表行はアーカイブされずに破棄されます。これは、Content Trackerのデータベース表すべてに該当します。デフォルトでは、SctAccessLog表のみ移入され、期限切れの行はアーカイブされません。ただし、SctTrackContentAccessOnlyとSctDoNotArchiveの両方を無効にすると、すべての表が移入され、期限切れデータがアーカイブされます。

12.2.3 インストールの考慮事項

グリニッジ標準時(GMT)を使用するには、SctUseGMT構成パラメータをtrueに設定します。デフォルトではfalseに設定されていて、ローカル時間を使用します。以前のバージョンのContent Trackerをアップグレードする場合、アクセス時間が1回前に戻ります(地域によっては先に進みます)。年2回のサマー・タイム実施に対応するために、記録されるユーザー・アクセス時間に中断が生じます(ローカル時間の使用、および地域によって異なります)。

12.3 構成およびカスタマイズ

Content Trackerのカスタマイズには、構成変数を使用できます。

12.3.1 構成変数

次の表に、現行バージョンのContent Trackerで使用される構成設定のデフォルト値を示します。これらの構成変数は、Content Tracker構成ファイルに含まれています。

cs_root/data/contenttracker/config/sct.cfg

構成設定

デフォルト値

注釈

SctAutoTruncateDataStrings

FALSE

使用: JAVA
削減プロセスでデータ文字列を対応する表列に収まるように切り捨てるかどうかを指定します。

SctComponentDir

cs_root/data/contenttracker/

使用: JAVA
Content Trackerがインストールされているディレクトリへのパス。

SctDebugLogEnabled

FALSE

使用: JAVA
TRUEに設定すると、Javaコード実行トレースが有効化されます。SctDebugLogFilePathとともに使用されます。

SctDebugLogFilePath

cs_root/data/contenttracker/log/SCT_DEBUG_TRACE.log

使用: JAVA
Javaコード実行トレースのディレクトリ。SctDebugLogEnabledとともに使用されます。

SctDebugServiceBinderDumpEnabled

FALSE

使用: JAVA
TRUEに設定すると、サービス・ロギング中にサービスDataBinderオブジェクトの診断出力が有効化されます。

SctExternalUserLogEnabled

TRUE

使用: JAVA
TRUEに設定すると、外部ユーザー・アカウントおよびロールの情報のUserSecurityAttributes表へのレプリケーションが有効化されます。

SctFilterPluginLogDir

cs_root/data/contenttracker/data/

使用: フィルタ・プラグイン
フィルタ・プラグインによってイベント・ログが格納されるディレクトリへのパス。

SctIdcAuthExtraConfigParams

フィルタ・プラグインに渡され、Content Tracker起動フィルタによってidcAuthExtraConfigParamsにプログラムでマージされるContent Tracker構成パラメータのリスト。

SctIgnoreDirectories

DomainHome/ucm/cs/resources/;DomainHome/ucm/cs/common/

使用: フィルタ・プラグイン
リストされたディレクトリ・ルート内に含まれるURLを無視するようにフィルタ・プラグインに指示します。

SctIgnoreFileTypes

gif、jpg、js、css

使用: フィルタ・プラグイン
リストされたファイルタイプを持つURLを無視するようにフィルタ・プラグインに指示します。

SctLogDir

cs_root/data/contenttracker/data/

使用: JAVA
未加工のイベント・ログ(sctLogなど)をContent Trackerが探す1つ以上のディレクトリへのパス。このパラメータは、dir1;dir2;…;dirnとして複数値になる場合があります。

SctLogEnabled

TRUE

使用: フィルタ・プラグイン、JAVA
FALSEの場合、すべてのイベントを無視してログを作成しないようにサービス・ハンドラ・フィルタおよびWebサーバー・フィルタ・プラグインに指示します。これは、Content Trackerマスターのオン/オフのスイッチです。

SctLogSecurity

TRUE

使用: フィルタ・プラグイン、JAVA
TRUEの場合、IMMEDIATE_RESPONSE_PAGEイベントをsctSecurityLogイベント・ログに記録するようにフィルタ・プラグインに指示し、イベント・ログを読み取るように削減プロセスに指示します。

SctMaxRecentCount

5

使用: JAVA
削減済のデータが「最新」状態として保持される最大日数。「最新」からオーバーフローしたデータは「アーカイブ」状態に移行します。

SctMaxRereadTime

3600

使用: JAVA
特定のユーザーが特定のコンテンツ・アイテム(PDFファイルなど)を連続して参照したとき、連続する参照が1つの持続するアクセスとしてみなされる最大の秒間隔。次の参照との時間間隔が大きい場合は、個別のアクセスとしてカウントされます。

SctReductionAvailableDatesLookback

0

使用: JAVA
使用可能な日付範囲を制限するためにSctReductionRequireEventLogsとともに使用されます。単位 = 日数。ゼロ = 無制限。

SctReductionLogDir

cs_root/data/contenttracker/log/

使用: JAVA
Content Tracker削減ログが格納されるディレクトリへのパス。

SctReductionRequireEventLogs

TRUE

使用: JAVA
添付解除された構成で使用されます。FALSEは、イベント・ログが見つからない場合でも削減を続行することを示します。

SctScheduledReductionEnable

TRUE

使用: JAVA
複数JVM構成において、削減を実行するコンテンツ・サーバー・インスタンスを選択するために使用されます。

SctSnapshotEnable

FALSE

使用: JAVA
TRUEに設定すると、スナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。

SctSnapshotLastAccessEnable

FALSE

使用: JAVA
TRUEに設定すると、最終アクセス日付のスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。

SctSnapshotLastAccessField

[なし]

使用: JAVA
最終アクセス日付のメタデータ・フィールド名(xLastAccessDateなど)。データ・エンジン・コントロール・センターから設定します。

SctSnapshotLongCountEnable

FALSE

使用: JAVA
TRUEに設定すると、長期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。

SctSnapshotLongCountField

[なし]

使用: JAVA
長期間隔カウントのメタデータ・フィールド名(xAccessesInLast90Daysなど)。データ・エンジン・コントロール・センターから設定します。

SctSnapshotLongCountInterval

[なし]

使用: JAVA
長期間隔の日数。データ・エンジン・コントロール・センターから設定します。

SctSnapshotShortCountEnable

FALSE

使用: JAVA
TRUEに設定すると、短期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。

SctSnapshotShortCountField

[なし]

使用: JAVA
短期間隔カウントのメタデータ・フィールド名(xAccessesInLast10Daysなど)。データ・エンジン・コントロール・センターから設定します。

SctSnapshotShortCountInterval

[なし]

使用: JAVA
短期間隔の日数。データ・エンジン・コントロール・センターから設定します。

SctUseGMT

FALSE

使用: フィルタ・プラグイン、JAVA
記録されたイベント時間を世界標準時に変換する場合は、TRUEに設定します。FALSEに設定すると、ローカル時間が使用されます。

次の変数は、sct.cfgファイルでは利用できず、コンポーネント・マネージャを使用した場合にのみアクセスできます。

構成設定

デフォルト値

注釈

SctPostReductionExec

[なし]

使用: JAVA
削減後実行可能ファイルへのパス(IntradocDir/custom/ContentTracker/bin/内と想定)。

SctProxyNameMaxLength

50

使用: JAVA
構成内のコンテンツ・サーバー・プロキシ・サーバー名の最大文字数。Content Trackerの表作成でユーザー名フィールドのサイズを増やす場合に使用されます。

SctUrlMaxLength

3000

使用: JAVA
URLフィールドの予測される最大長(文字数)。表の作成時に列幅を決定するために使用されます。1つの特定の表にこのような列が複数存在する場合があります。

SctWebBeaconIDList

[なし]

使用: フィルタ・プラグイン
Webビーコン・オブジェクトのリスト(オブジェクトがゼロの場合もあります)。クライアント側タグを使用してデータをContent Trackerにフィードする機能を追加する場合に必要です。Content Trackerで、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータを収集できるようになります。

12.3.1.1 アクセス制御リストおよびContent Trackerレポートのセキュア・モード

Content Trackerレポートのコンポーネントをインストールすると、セキュリティ・チェック・プリファレンス変数(SctrEnableSecurityChecks)が設定されます。このプリファレンス変数では、2つのセキュリティ・モード(セキュア・モードおよび非セキュア・モード)のいずれかを選択できます。セキュリティ・チェック・プリファレンスには、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限するためのオプションがあります。

これは、生成されるレポートでユーザーに表示されるコンテンツ・アイテム(およびその後のメタデータ)を制御することを意味します。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。セキュア・モードが使用されている場合、生成されるレポートの情報は、ユーザーのロール権限およびアカウント権限に基づいてフィルタ処理されます。

ただし、コンテンツ・サーバーのインスタンスに対してアクセス制御リスト(ACL)が有効化されている場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。インストール時は、セキュリティ・チェック・プリファレンス・チェック・ボックスを空白にしておきます。これは、ACLベースのシステムでは、セキュア・モードが無効になっている必要があることを意味します。この場合、システム管理者以外のユーザーに、本来はアクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。

12.3.1.2 セキュリティ・チェック・プリファレンス変数の値

セキュリティ・チェック・プリファレンス変数の値は、次のとおりです。

- SctrEnableSecurityChecks=Trueに設定すると、セキュリティ・チェック・インストール・プリファレンスが有効化され、Content Trackerレポートがセキュア・モードで動作するように構成されます。
セキュア・モードでは、コンテンツ・サーバーの検索結果を制限するために使用されたのと同じセキュリティ基準(ロールおよびアカウントの制限)が、「Content Trackerレポートの生成」の問合せおよび生成されるレポートにも適用されます。このため、2つの異なるユーザーが「上位アクセス・コンテンツ・アイテム」レポートを実行した場合、異なる結果が表示されることがあります。

- SctrEnableSecurityChecks=Falseに設定すると、セキュリティ・チェック・インストール・プリファレンスが無効化され、Content Trackerレポートが非セキュア・モードで動作するように構成されます。これがデフォルトの設定です。
非セキュア・モードの場合、コンテンツ・サーバーの検索結果を制限するのに使用された追加のロールおよびアカウント基準は、「Content Trackerレポートの生成」の問合せおよび生成されるレポートに適用されません。このため、システム管理者以外のユーザーに、アクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。

12.3.1.3 SctAccessLogのエントリのファイル・タイプ

デフォルトでは、Content TrackerによってGIF、JPG、JS、CSS、CABおよびCLASSファイル・タイプへのアクセスはログに記録されません。したがって、これらのファイル・タイプのエントリは、データ削減後、結合された出力表に挿入されません。

これらのファイル・タイプをログに記録するには、IntradocDir/custom/ContentTracker/resources/ディレクトリにあるsct.cfgファイル内でファイル・タイプを有効化する必要があります。SctIgnoreFileTypes構成変数(gif,jpg,js,css)のデフォルトの設定を変更します。デフォルト設定では、これらのファイル・タイプは除外されます。これらのファイル・タイプの一部のみを含めるには、リストから目的の各ファイル・タイプを削除します。この変更を有効にするには、Webサーバーおよびコンテンツ・サーバーを再起動する必要があります。

12.3.2 Content Tracker構成変数の手動設定

Content Tracker構成変数を設定または編集する手順は、次のとおりです。

1. テキスト・エディタで、sct.cfgファイルを開きます。
cs_root/data/contenttracker/config/sct.cfg

2. 編集する構成ファイルを検索します。

3. 適用可能な値を入力します。

4. sct.cfgファイルを保存して閉じます。

5. コンテンツ・サーバーを再起動して変更内容を適用します。

データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、アクティビティ・メトリック・メタデータ・フィールドの構成変数を追加または編集します。次のような変数があります。

- SctSnapshotEnable

- SctSnapshotLastAccessEnable

- SctSnapshotLastAccessField

- SctSnapshotLongCountEnable

- SctSnapshotLongCountField

- SctSnapshotLongCountInterval

- SctSnapshotShortCountEnable

- SctSnapshotShortCountField

- SctSnapshotShortCountInterval

ユーザー・インタフェースおよびアクティビティ・メトリック機能の詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のデータ・エンジン・コントロール・センターに関する項および「スナップショット」タブに関する項を参照してください。

12.3.3 外部ユーザーおよびコンテンツ・アイテムの追跡

Content Trackerで適用可能レポートに外部ユーザー・アクセスに関するデータを含めるかどうかを制御するオプションがあります。これらの認証済ユーザーは、ユーザー・ロールおよびアカウントに基づいて権限を与えられています。デフォルトでは、構成パラメータSctExternalUserLogEnabledはtrue(有効)に設定されています。これによって、Content Trackerでは、外部ユーザー・ログインが監視され、そのロールおよびアカウント情報がUserSecurityAttributes表に自動的に伝播されます。

SctExternalUserLogEnabled構成変数が有効か無効かに関係なく、外部ユーザーのコンテンツ・アイテム・アクセス情報はすべて追跡されて記録されます。ただし、この構成変数が有効化されている場合は、外部で認証されたユーザー名とそれに関連付けられたユーザー・ロールおよびアカウントとの相関関係を明示的に示すレポートに、このデータが含められます。具体的には、「ユーザー・ロール別上位アクセス・コンテンツ・アイテム」レポートおよび「ユーザー・ロール別ユーザー」レポートに、外部ユーザーによるすべてのコンテンツ・アイテム・アクセス・アクティビティが含められます。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「Content Trackerレポートの生成」メイン・ページに関する項を参照してください。

注意:
SctExternalUserLogEnabled構成変数を手動で無効化する方法は、第12.3.2項「Content Tracker構成変数の手動設定」を参照してください。

12.4 サービス・コール構成

サービス・コール構成ファイルでサービス・コールを構成し、イベントをログに記録するようにContent Trackerロギング・サービスを構成して、サービス・コール情報を管理できます。

12.4.1 サービス・コール構成ファイルについて

Content Trackerサービス・ハンドラ・フィルタを使用すると、コンテンツ・リクエスト以外のコンテンツ・サーバー・アクティビティに関する情報が収集できます。サービス・ハンドラ・フィルタによってサービス・リクエスト詳細が収集され、リアルタイムでSctAccessLog表に格納されます。詳細は、サービス・コールに付随するDataBinderから取得されます。コンテンツ・サーバー・サービス・コールをログに記録するには、サービス・コール構成ファイル(SctServiceFilter.hda)内にそのエントリが存在している必要があります。

SctServiceFilter.hdaファイルはユーザーが変更可能な構成ファイルで、ログに記録されるサービス・コールの数を制限するために使用されます。これによって、ログに記録されるサービスを選択的に管理できます。SctServiceFilter.hdaファイルに含まれている任意のサービス・コールのデータ・ロギング機能を拡張して、特定のサービスに関連する特定のDataBinderフィールドのデータ値を記録および追跡することもできます。詳細は、第12.4.1.2項「拡張されたサービス・コール・トラッキング機能」を参照してください。

サービス・トラッキングは、サーバー・ソケット・ポートを介して呼び出される最上位レベルのサービスに制限されます。サブサービス、または内部で呼び出されるサービスは追跡できません。

SctServiceFilter.hdaファイルの目的は、ユーザーがコンテンツ・サーバーのどの部分に特に関心があるかを定義することです。SctServiceFilter.hdaファイルにリストされていないコンテンツ・サーバー・サービスは、Content Trackerで無視されます。また、このファイルにリストされていないサービスは、Content Trackerロギング・サービスでのみログに記録できます。詳細は、第12.4.2項「Content Trackerロギング・サービスについて」を参照してください。

SctServiceFilter.hdaファイルは、次の2つの方法で変更できます。

- データ・エンジン・コントロール・センターから、新規サービスを追加し、ファイル内の既存のサービス・コール・パラメータを編集します。
詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「サービス」タブに関する項を参照してください。

- SctServiceFilter.hdaファイルを手動で編集します。
詳細は、第12.4.3.1項「SctServiceFilter.hdaファイルの手動編集」を参照してください。

ヒント:
ログに記録するサービスを制御するには、SctServiceFilter.hdaファイルにサービスを追加するか、またはファイルから除外します。この方法は、特定のサービスまたはすべてのサービスに対するロギングを制御する場合に効率的です。また、拡張されたサービス・コール・トラッキング機能を使用すると、特定のサービスに対してログに記録されるデータのタイプをカスタマイズできます。

12.4.1.1 一般的なサービス・コール・ロギング

SctServiceFilter.hdaファイルにリストされたサービスはContent Trackerサービス・ハンドラ・フィルタによって検出され、選択されたデータ・フィールドの値が取得されます。その後に、Content Trackerでは指定されたサービス・コールがログに記録されます。タイムスタンプなどとともに、情報がSctAccessLog表に動的に書き込まれます。

Content Trackerでは、有効になっているサービスごとに、dUserやdDocNameなど、特定の標準のDataBinderフィールドが自動的にログに記録されます。また、拡張されたサービス・コール・トラッキング機能に関連付けられているDataBinderフィールドのログが、SctAccessLog表の汎用の列に記録されます。

データは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定「S」を使用して、SctAccessLog表にリアルタイムで挿入されます。(「W」指定は、静的URLイベント・タイプを示します。)手動またはスケジュール実行(あるいはその両方)での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。

12.4.1.2 拡張されたサービス・コール・トラッキング機能

拡張されたサービス・コール・トラッキング機能を使用すると、コンテンツ・サーバーのサービス・コールをログに記録でき、構成された各サービス・コールでログに記録される標準のDataBinderフィールド以外に1つ以上の追加DataBinderフィールドから関連データ値をログに記録することによって、この情報を補完することもできます。

12.4.1.2.1 サービス・コールResultSetの組合せ

SctServiceFilter.hdaファイルに含まれるServiceExtraInfo ResultSet内に、Content Trackerによってログに記録される各サービスのエントリが存在している必要があります。Content Trackerでは、各種の標準のDataBinderフィールド(dUser、dDocNameなど)が自動的にログに記録されます。ただし、追加のDataBinderフィールドから関連データ値を記録および追跡することによって、Content Trackerで記録されるサービス関連データを拡張できます。

拡張されたサービス・コール・トラッキング機能を実装するには、ServicesExtraInfo ResultSet内のエントリをフィールド・マップResultSetにリンクします。各フィールド・マップResultSetには、データ・フィールド名、ソース格納場所、およびSctAccessLog表内の宛先表列名のセットが1つ以上含まれます。このグループ化によって、関連付けられたサービス・コールに関連するデータ・フィールドを選択し、SctAccessLog表の指定された列にデータ値を記録できます。

拡張されたトラッキング機能を使用すると複数の拡張サービスを記録できるため、記録されるサービスが不明な場合は、SctAccessLog表の汎用列の内容を適切に解釈できません。サービス名は常にsc_scs_idcService列に記録されます。問合せでは、この列と任意のサービス名を一致させてください。

注意:
フィールド・マップResultSetでは、SctAccessLog表の既存の標準列にデータ・フィールドをマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。表の標準の列フィールドは、いずれもオーバーライドできます。
たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名(たとえば、MyUserName=john)が含まれるとします。拡張されたトラッキング機能を使用して、sc_scs_dUser列の内容をオーバーライドできます。この場合は、MyUserNameとsc_scs_dUserを結合して、データ・フィールド、格納場所、およびフィールド・マップResultSet内の表列のセットとして使用します。

ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。

リンクされたサービス・エントリおよびResultSetの例は、第12.4.1.4.2項「リンクされたサービス・エントリとフィールド・マップResultSet」を参照してください。SctAccessLog表の内容、およびデータ・フィールドにマップすることを目的とした汎用列の詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の結合された出力表に関する項を参照してください。サービス・コールのユーザー・インタフェースの詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「サービス」タブに関する項を参照してください。

12.4.1.2.2 出力表の汎用列

拡張されたサービス・トラッキング用のフィールド・マップResultSet内で、DataBinderフィールドをSctAccessLog表の列にマップします。汎用列(extField_1からextField_10)はマッピングに使用できます。これらの列には、特定のサービスに対するロギングおよびトラッキングに適した任意のデータ値を挿入できます。標準の表列がオーバーライドされることを回避するために、これらの列を使用することをお薦めします。

ヒント:
サービスの名前は常にsc_scs_idcService列に記録されます。拡張フィールドのコンテンツを使用する問合せには、修飾子としてこれを含めます。SctAccessLog表の列が関係する具体的なSQL問合せを含むカスタム・レポートの詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のカスタム・レポートの問合せの作成に関する項を参照してください。

12.4.1.3 サービス・コール構成ファイルの内容

最初のサービス・コール構成ファイル(SctServiceFilter.hda)は、共通に使用されてコンテンツ・サーバーに固有のコンテンツ・アクセス、検索およびユーザー認証サービスで構成されます。このファイルには、ログに記録される各サービスに1つずつエントリが存在するResultSet構造が含まれます。拡張されたサービス・コール・トラッキング機能をサポートするために、ServiceExtraInfo ResultSet内のサービス・エントリにリンクされたフィールド・マップResultSetをこのファイルに含めることもできます。

データ・エンジン・コントロール・センターからアクセスする「サービス」ユーザー・インタフェースを使用して、SctServiceFilter.hdaファイルに新規のエントリを追加するか、既存のエントリを編集するか、またはその両方を行います。あるいは、ファイル内のエントリを手動で変更します。詳細は、第12.4.3.1項「SctServiceFilter.hdaファイルの手動編集」、または『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「サービス」タブに関する項を参照してください。

注意:
Content TrackerによってSctAccessLog表に記録される最初のサービスのセットを確認するには、次のSctServiceFilter.hdaファイルを参照してください。
cs_root/data/contenttracker/config/SctServiceFilter.hda

次の表に、サービス・コール構成ファイルの結果セット・スキーマの詳細を示します。値は、SctAccessLog表内の対応する列に直接コピーされます。

ServiceExtraInfo ResultSetの内容:

機能

説明

サービス名(sctServiceName)

ロギングされるサービスの名前。たとえば、GET_FILEです。指定されたサービスについてResultSet内に行が存在しない場合、そのサービスは記録されません。

呼出し元製品(sctCallingProduct)

任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Core Server」に設定されています。

イベント・タイプ(sctEventType)

任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Content Access」に設定されています。

参照(sctReference)

SctAccessLog表のsc_scs_referenceフィールドを設定するために使用します。空白の場合は、内部getReferenceロジックが使用されます。

フィールドの変更(sctFieldMap)

SctServiceFilter.hdaファイルに追加されるフィールド・マップResultSetの名前。このフィールドは、拡張されたサービス・コール・トラッキング機能を使用する場合にのみ必要です。この機能により、DataBinderフィールド情報を、SctAccessLog表の1つ以上の汎用列にロギングできます。

フィールド・マップResultSetの内容:

機能

説明

「フィールドの変更」リンク

フィールド・マップResultSetの名前。
サービスDataBinderオブジェクトを書き出す構成変数を設定できます。これにより、イベントが記録されるときに使用可能なデータを参照できます。

DataBinderフィールド(dataFieldName)

SctAccessLog表の汎用列にデータ値が記録されるDataBinderフィールドの名前。「「フィールドの変更」画面」の「「フィールド名」フィールド」も参照してください。

データの場所(dataLocation)

フィールドが記録されるコンテンツ・サーバー・サービスDataBinder内のセクション。「「フィールドの変更」画面」の「「フィールドの場所」フィールド」も参照してください。

アクセス・ログ列(accessLogColumnName)

指定したDataBinderフィールドのデータ値がロギングされるSctAccessLog表の特定の汎用列。「「フィールドの変更」画面」の「「列名」フィールド」も参照してください。

DataBinderからコピーされてSctAccessLog表に挿入されるフィールドには、dID、dDocName、IdcService、dUser、SctCallingProduct、SctEventTypeおよびSctReferenceが含まれます。最後の3つのフィールドの値がSctServiceFilter.hdaファイル内のサービスのエントリに含まれている場合は、それらの値はデータ・フィールド内の対応する値をオーバーライドします。

サービス・ハンドラ・フィルタを介して記録されるサービスと、Content Trackerロギング・サービスを介して記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。

ヒント:
必要なサービス・コールをSctServiceFilter.hdaファイルに追加し、この方法を使用して特定のアクティビティを記録すると、CallingProduct、EventTypeおよびReferenceフィールドの値を指定できる長所があります。割り当てた値は、SctAccessLog表内の対応する列に直接コピーされます。

12.4.1.4 ResultSetの例

デフォルトのSctServiceFilter.hdaファイルには、各種の共通のサービス・コールが含まれています。

注意:
Content TrackerによってSctAccessLog表に記録される最初のサービスのセット、サービス・エントリおよびフィールド・マップResultSetを確認するには、次のSctServiceFilter.hdaファイルを参照してください。
cs_root/data/contenttracker/config/SctServiceFilter.hda

これらのサービスの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

12.4.1.4.1 ServiceExtraInfo ResultSetのエントリ

次のリストに、SctServiceFilter.hdaファイルのServiceExtraInfo ResultSetに含まれるサービス・エントリの例をいくつか示します。

- GET_FILE_BY_NAME
Core Server

Content Access

- GET_DYNAMIC_URL
Core Server

Content Access

- GET_DYNAMIC_CONVERSION
Core Server

Content Access

- GET_EXTERNAL_DYNAMIC_CONVERSION
Core Server

Content Access

- GET_ARCHIVED_FILE
Core Server

Content Access

- COLLECTION_GET_FILE
Folders

Content Access

12.4.1.4.2 リンクされたサービス・エントリとフィールド・マップResultSet

次の表に、フィールド・マップResultSetにリンクされたサービス・エントリの例をいくつか示します。これらの例やその他の類似する例は、最初のSctServiceFilter.hdaファイルに含まれています。

サービス・エントリ

フィールド・マップResultSet

GET_SEARCH_RESULTS
Core Server
Search

SearchFieldMap

@ResultSet SearchFieldMap
3
dataFieldName 6 255
dataLocation 6 255
accessLogColumnName 6 255
MiniSearchText
LocalData
extField_1
TranslatedQueryText
LocalData
extField_2
IsSavedQuery
LocalData
extField_7
@end

PNE_GET_SEARCH_RESULTS
Core Server
Search

SearchFieldMap

@ResultSet SearchFieldMap
3
dataFieldName 6 255
dataLocation 6 255
accessLogColumnName 6 255
MiniSearchText
LocalData
extField_1
TranslatedQueryText
LocalData
extField_2
IsSavedQuery
LocalData
extField_7
@end

GET_FILE
Core Server
Content Access

GetFileFieldMap

@ResultSet GetFileFieldMap
3
dataFieldName 6 255
dataLocation 6 255
accessLogColumnName 6 255
RevisionSelectionMethod
LocalData
extField_1
Rendition
LocalData
extField_2
@end

12.4.2 Content Trackerロギング・サービスについて

Content Trackerロギング・サービスは、アプリケーションによって1つのイベントをSctAccessLog表に記録できる単一のサービス・コール(SCT_LOG_EVENT)です。このサービスは、URLを介して直接呼び出すか、またはサービス・スクリプト内のアクションとして呼び出すことができます。また、executeService()関数を使用して、Idocスクリプトから呼び出すこともできます。呼出し元アプリケーションによって、記録されるサービスDataBinder内の一部または全部のフィールドが設定され、これには、Content TrackerのSctServiceFilter.hda構成ファイルにリストされている記述フィールドが含まれます。

SCT_LOG_EVENTサービスによって、サービスDataBinderから情報がコピーされます。このデータは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定「S」を使用して、SctAccessLog表にリアルタイムで挿入されます。手動またはスケジュール実行、あるいはその両方での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のWebサーバーのフィルタ・プラグインに関する項を参照してください。

注意:
サービス・ハンドラ・フィルタを介して記録されるサービスと、Content Trackerロギング・サービスを介して記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。ただし、Content Trackerでは、このような重複を回避する処理は行われません。

12.4.3 サービス・コール情報の管理

この項では、コンテンツ・サーバー・サービスからのデータを結合された出力データベース表(SctAccessLog)にマップして記録するための情報およびタスクの手順について説明します。

12.4.3.1 SctServiceFilter.hdaファイルの手動編集

SctServiceFilter.hdaファイルのエントリを追加または変更する手順は、次のとおりです。

1. テキスト・エディタで、SctServiceFilter.hdaファイルを開きます。
cs_root/data/contenttracker/config/.../SctServiceFilter.hd

2. 既存のエントリを編集するか、または新規のサービス・エントリを追加します。たとえば、GET_FILE_FORMサービスを追加する場合は、次のサービス・エントリをファイル内のServiceExtraInfo ResultSetに入力します。

GET_FORM_FILE
Threaded Discussion
Content Access
optional_reference_value
optional_field_map_link_value

optional_field_map_link_valueは、拡張されたサービス・コール・トラッキング機能を実装する場合に使用します。この場合は、対応するフィールド・マップResultSetを追加または編集します。拡張されたサービス・コール・トラッキングを実装する場合は、手順3をスキップします。

3. 拡張されたサービス・トラッキングを使用する場合は、対応するフィールド・マップResultSetを追加または編集します。たとえば、SS_GET_PAGEサービスを追加し、追加のデータ・フィールド値を追跡するには、次のサービス・エントリおよび対応するフィールド・マップResultSetをファイルに入力します。

サービスのエントリ

フィールド・マップResultSet

SS_GET_PAGE
Site Studio
Web Hierarchy Access
web
SSGetPageFieldMap

@ResultSet SSGetPageFieldMap
3
dataFieldName 6 255
dataLocation 6 255
accessLogColumnName 6 255
DataBinder_field_name
data_field_location_name
access_log_column_name
@end

注意:
DataBinderフィールド、格納場所および表列名のセットは、必要な数だけ含めてください。

4. ファイルを保存して閉じます。

5. コンテンツ・サーバーを再起動して、新しい定義を適用します。

注意:
検索リクエスト・イベントはリアルタイムでSctAccessLog表に記録され、削減する必要はありません。データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、サービスを追加または編集します。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のデータ・エンジン・コントロール・センターに関する項および「サービス」タブに関する項を参照してください。

12.4.3.2 Content Trackerロギング・サービスを呼び出すための必要なDataBinderフィールドの設定

次の表に、Content Trackerロギング・サービス(SCT_LOG_EVENT)が呼び出されたときにContent Trackerで検索されるSctAccessLogの列名および対応するDataBinderフィールドを示します。アプリケーションでは、Content Trackerロギング・サービスを呼び出すときに、Content Trackerで検索されるサービスDataBinder内の必要なフィールドを設定します。SctAccessLogフィールドの詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の結合された出力表に関する項を参照してください。

SctAccessLogの列名

サービスDataBinder LocalDataフィールド

SctDateStamp

[計算される]

SctSequence

SctSequence

SctEntryType

S

eventDate

[計算される]

SctParentSequence

SctParentSequence

c_ip

REMOTE_HOST

cs_username

HTTP_INTERNETUSER

cs_method

REQUEST_METHOD

cs_uriStem

HTTP_CGIPATHROOT

cs_uriQuery

QUERY_STRING

cs_host

SERVER_NAME

cs_userAgent

HTTP_USER_AGENT

cs_cookie

HTTP_COOKIE

cs_referer

HTTP_REFERER

sc_scs_dID

dID

sc_scs_dUser

dUser

sc_scs_idcService

IdcService(またはSctIdcService)

sc_scs_dDocName

dDocName

sc_scs_callingProduct

sctCallingProduct

sc_scs_eventType

sctEventType

sc_scs_status

StatusCode

sc_scs_reference

sctReference(...も同様)

comp_username

[計算される - HTTP_INTERNETUSERまたは...]

sc_scs_isPrompt

該当なし

sc_scs_isAccessDenied

該当なし

sc_scs_inetUser

該当なし

sc_scs_authUser

該当なし

sc_scs_inetPassword

該当なし

sc_scs_serviceMsg

StatusMessage

12.4.3.3 アプリケーションからのContent Trackerロギング・サービスの呼出し

SCT_LOG_EVENTサービスをアプリケーションから呼び出すことができます。これは、アプリケーション開発者、またはアプリケーション・サービス・スクリプトを変更するユーザーが実行できます。アプリケーションではJavaからSCT_LOG_EVENTを呼び出すことができます。または、アプリケーションでSCT_LOG_EVENTへのコールをサービス・スクリプトに含めることもできます。

12.4.3.4 IdocスクリプトからのContent Trackerロギング・サービスの呼出し

executeService()関数を使用して、Idocスクリプトから間接的にSCT_LOG_EVENTサービスを呼び出すことができます。これは、アプリケーションからのSCT_LOG_EVENTサービスの呼出しと同じですが、アプリケーションJavaコードではなくIdocスクリプトから呼び出されます。Content Trackerでは、SCT_LOG_EVENTサービスの呼出し元がJavaかIdocスクリプトかは区別できません。

12.4.4 サービス・コール管理およびユーザー・インタフェース

Content Trackerでは、サービス・コールを、関連付けられたサービスに関連するデータ値とともにログに記録できます。ログに記録する各サービスには、サービス・コール構成ファイル(SctServiceFilter.hda)内にサービス・エントリが存在している必要があります。ログに記録するサービスに加えて、対応するフィールド・マップResultSetをSctServiceFilter.hdaに含めることができます。

Content Trackerでは、コンテンツ・アクセスのイベント・タイプを持つサービス、またはDocHistory表への入力が発生するサービスのみがログに記録されます。これにより、パフォーマンスは最大になりますが、一部のサービス・イベントはログに記録されません。

有効化されたサービスによって、一般的なDataBinderフィールド(dUser、dDocNameなど)が自動的に記録されます。フィールド・マップResultSetをサービス・エントリにリンクすると、拡張されたサービス・コール・トラッキング機能を使用できます。

SctAccessLogデータベース表には、拡張されたサービス・コール・トラッキング機能で使用できる追加の列が用意されていて、この列には、関連付けられたサービス・コールに適した任意のデータ値を入力できます。フィールド・マップResultSet内にデータ・フィールド名をリストする場合は、データ・フィールドのソースの格納場所名、およびデータの記録先の表列名もリストします。

注意:
フィールド・マップResultSetでは、SctAccessLog表の既存の標準列にデータ・フィールドをマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。したがって、表の標準の列フィールドは、いずれもオーバーライドできます。
たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名(MyUserName=john)が含まれるとします。拡張されたトラッキング機能を使用して、sc_scs_dUser列の内容を上書きできます。この場合は、MyUserNameとsc_scs_dUserを結合して、データ・フィールド、格納場所、およびフィールド・マップResultSet内の表列のセットとして使用します。

ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。

12.4.4.1 サービス・エントリの追加、編集または削除

サービスを追加または編集するには、次の手順を実行します。

1. 「メイン」メニューで「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センターが開きます。

2. 「サービス」タブをクリックします。

3. 「追加」をクリックしてサービス・エントリを新規作成するか、または、「サービス名」リストから既存のサービス・エントリを選択し、「編集」をクリックします。
「拡張されたサービス・トラッキング」画面が開きます。新規のサービス・エントリを追加したときには、フィールドは空です。既存のサービス・エントリを編集する場合は、編集可能な値がフィールドに移入されます。

4. 適用可能なフィールド値を入力または変更します(「フィールドの変更」フィールドの値を除く)。
このサービス・エントリをフィールド・マップResultSetにリンクするには、適用可能な名前を「フィールドの変更」フィールドに入力して、フィールドをリンクします。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のメタデータ・フィールドへのアクティビティ・メトリックのリンクに関する項を参照してください。

5. 「OK」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

6. 「OK」をクリックします。
「サービス」リストで、「サービス」タブが、新規のサービスまたは新たに編集されたサービスを反映して再表示されます。サービス状態およびContent TrackerのSctServiceFilter.hdaが更新されます。

Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減が実行されるまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。新規のサービスを追加したり、既存のサービスを編集する場合は、サービス・コール名を正確に入力するように注意してください。すべてのフィールド値が正しいスペルおよび大/小文字になるようにします。

エントリを削除するには、前の手順を実行してエントリを選択し、「削除」を選択します。

12.4.4.2 フィールド・マップResultSetの追加、編集または削除

拡張されたサービス・コール・トラッキング機能を実装するには、サービス・エントリをSctServiceFilter.hdaファイル内のフィールド・マップResultSetにリンクする必要があります。

フィールド・マップを追加してリンクするには、次の手順を実行します。

1. 「メイン」メニューで「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センターが開きます。

2. 「サービス」タブをクリックします。

3. 新規のエントリを追加するには、第12.4.4.1項「サービス・エントリの追加、編集または削除」で説明した手順を実行します。「サービス名」リストからサービス・エントリを選択します。

4. 「編集」をクリックします。
「拡張されたサービス・トラッキング」画面が開きます。必要な場合は、フィールド・マップResultSetの追加に加えて、このサービス・エントリの値をここで編集します。

このサービスがすでにフィールド・マップResultSetにリンクされている場合は「フィールドの変更」フィールドに名前がリストされ、データ・フィールド、格納場所および表列の1つ以上のセットが「フィールド」ペインにリストされます。

5. 選択したサービスがセカンダリResultSetにリンクされていない場合、「フィールドの変更」フィールドは空です。フィールド・マップResultSetの名前を入力してください。選択したサービスがすでにリンクされている場合は、この手順をスキップしてください。

6. 「追加」をクリックします。
「フィールドの変更」画面が開きます。

7. 次のフィールドに適切な値を入力します。

- フィールド名: データ値がSctAccessLog表の汎用列にロギングされるサービスDataBinderのデータ・フィールドの名前。

- フィールドの場所: ログに記録されるデータ・フィールドが配置されているOracle WebCenter Content ServerサービスDataBinderのセクション。次の値を使用できます。

- LocalData(デフォルト値)

- 環境

- BinderResultSet。これは、ResultSet内のすべての値を含むカンマ・デリミタを返します。サイズが255文字に制限されているため、この値が役立つのは、ResultSetが小さな場合のみです。サイズは、カンマなどを含め、255文字に制限されます。
より多くの文字に対応するには、標準データベース・ツールを使用してSctAccessLog表の列を拡張/再定義します。たとえば、extField_3を2047に広げると、同量のデータが保持されます。ただし、ほとんどのデータベースには、ページ・サイズの制限があります。また、SQLによって文字列が効率的に解析されないということにも注意してください。

- 列名: 指定したDataBinderフィールドのデータ値がロギングされるSctAccessLog表の列。

8. 「OK」をクリックします。
「フィールドの変更」画面が閉じ、値が「フィールド名」および「列名」フィールドに追加されます。

9. 「OK」をもう一度クリックします。
「確認」ダイアログ・ボックスが表示されます。

「サービス」タブが、更新された情報を反映して再表示されます。

10. 「OK」をクリックします。

Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減が実行されるまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。新規のフィールド・マップResultSetを追加したり、既存のフィールド・マップResultSetを編集する場合は、正確な名前を入力し、フィールドの値がすべて、スペルも大文字/小文字も正しいことを確認してください。

フィールド・マップを編集するには、前の手順を実行し、必要に応じてエントリを編集します。

エントリを削除するには、前の手順を実行してサービス・エントリを選択し、「削除」を選択します。

12.5 Content Trackerのカスタマイズ

この項の内容は次のとおりです。

- 第12.5.1項「アクティビティ・メトリックのSQL問合せ」

- 第12.3.3項「外部ユーザーおよびコンテンツ・アイテムの追跡」

Content Trackerの構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

12.5.1 アクティビティ・メトリックのSQL問合せ

スナップショット機能を使用すると、検索関連カスタム・メタデータ・フィールドをログに記録して追跡できます。Content Trackerでは、特定のコンテンツ・アイテムの人気度を反映するコンテンツ・アイテム使用状況およびアクセス情報がこれらのフィールドに挿入されます。この情報には、2つの異なる時間間隔における最新アクセスの日付およびアクセス数が含まれます。スナップショット機能の詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「スナップショット」タブに関する項を参照してください。

スナップショット機能およびアクティビティ・メトリックが有効化されている場合は、削減処理フェーズに続いて、カスタム・メタデータ・フィールドの値が更新されます。ユーザーがコンテンツ・アイテムにアクセスすると、適用可能な検索関連メタデータ・フィールドの値がそれに応じて変わります。その後、Content Trackerでは、削減処理後の手順として3つのSQL問合せが実行され、レポート作成期間中にアクセスされたコンテンツ・アイテムが特定されます。処理後の削減手順の詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のアクティビティ・メトリックを使用したデータ削減プロセスに関する項を参照してください。

12.5.1.1 アクティビティ・メトリックのSQL問合せのカスタマイズ

SQL問合せは、リソースとして使用可能であり、最終トラッキング・データから情報をフィルタ処理するようにカスタマイズできます。たとえば、表形式の結果から、特定のユーザーによるアクセスを除外できます。

SQL問合せは、sctQuery.htmファイルに含まれています。

IntradocDir/custom/ContentTracker/resources/SctQuery.htm

注意:
通常、SQL問合せ内のWHERE句は変更できます。これ以外は変更しないことをお薦めします。

検索関連カスタム・メタデータ・フィールドには、次のSQL問合せが使用されます。

- qSctLastAccessDate: 最終アクセス機能の場合、この問合せではSctAccessLog表が使用されます。この問合せでは、削減日におけるすべてのコンテンツ・アイテム・アクセスがチェックされ、dIDごとに最新のタイムスタンプが収集されます。この問合せのパラメータは、削減日です。この場合、最終アクセス日付の比較テストによって変更が示されるのは、提示された新しい値よりも既存のDocMeta値が古い場合のみであるため、日付はランダムな順序で削減できます。

- qSctAccessCountShortおよびqSctAccessCountLong: 短期と長期のアクセス・カウント機能の場合、SQL問合せのqSctAccessCountShortおよびqSctAccessCountLongは、カウントの列名以外は同じです。これらでは、SctAccessLog表を使用して、それぞれに指定された時間間隔(日数)にわたる各dIDの全アクセスについて合計が計算されます。パラメータは、適用可能なロールアップの開始日および終了日です。

12.5.2 外部ユーザーおよびコンテンツ・アイテムの追跡

Content Trackerで適用可能レポートに外部ユーザー・アクセスに関するデータを含めるかどうかを制御するオプションがあります。これらの認証済ユーザーは、ユーザー・ロールおよびアカウントに基づいて権限を与えられています。デフォルトでは、構成パラメータSctExternalUserLogEnabledはtrue(有効)に設定されています。これによって、Content Trackerでは、外部ユーザー・ログインが監視され、そのロールおよびアカウント情報がUserSecurityAttributes表に自動的に伝播されます。

SctExternalUserLogEnabled構成変数が有効か無効かに関係なく、外部ユーザーのコンテンツ・アイテム・アクセス情報はすべて追跡されて記録されます。ただし、この構成変数が有効化されている場合は、外部で認証されたユーザー名とそれに関連付けられたユーザー・ロールおよびアカウントとの相関関係を明示的に示すレポートに、このデータが含められます。具体的には、「ユーザー・ロール別上位アクセス・コンテンツ・アイテム」レポートおよび「ユーザー・ロール別ユーザー」レポートに、外部ユーザーによるすべてのコンテンツ・アイテム・アクセス・アクティビティが含められます。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』の「Content Trackerレポートの生成」メイン・ページに関する項を参照してください。

注意:
SctExternalUserLogEnabled構成変数を手動で無効化する方法は、第12.3.2項「Content Tracker構成変数の手動設定」を参照してください。

12.6 Webビーコンの機能

重要:
Webビーコン機能の実装要件は、関連するシステム構成に依存しています。このドキュメントでは対応できない要素もあります。Content Trackerで収集および処理されるアクセス・レコードの情報は、正確なカウントではなく、一般的なユーザー・アクティビティを示すものです。

Webビーコンは、Webページまたは他の管理対象コンテンツへの間接ユーザー・アクセスを容易に追跡するための特別サポートを提供する管理対象オブジェクトです。以前のリリースのContent Trackerでは、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータは収集できませんでした。キャッシュされたWebページやコンテンツ・アイテムにユーザーがアクセスした場合、Oracle WebCenter Content ServerやContent Trackerでは、これらのリクエストが発生したことを認識できません。Webビーコン参照を使用しないと、Content Trackerではこのようなリクエストを記録してカウントできません。

Webビーコンを使用すると、クライアント側では、Oracle WebCenter Content Server内の管理対象ビーコン・オブジェクトへの目にみえない参照として埋込み参照を使用できます。これにより、Content Trackerでは、Oracle WebCenter Content Serverからコンテンツを直接取得せずに、再配布のために外部エンティティによってコピーされた管理対象コンテンツ・アイテムに対するユーザー・アクセス・リクエストを記録してカウントできます。これが使用されるような状況の詳細は、第12.6.1項「Webビーコンのユースケース」を参照してください。

キャッシュされたコンテンツがコンシューマに提供されると、ユーザーは、リクエストされたオブジェクトがOracle WebCenter Content Serverで提供されていたことを認識します。管理対象コンテンツは実際には、動的ではないコンテンツ配信方法を使用して提供されます。この状況では、管理対象コンテンツは、静的Webサイト、リバース・プロキシ・サーバー、またはファイル・システム外からでも提供されます。Webビーコン機能によって、このタイプのアクティビティが確実に追跡されます。

12.6.1 Webビーコンのユースケース

特に、Webビーコン機能を使用するだけの価値があると思われる状況は、リバース・プロキシ・アクティビティとSite Studio使用の2つです。

リバース・プロキシのシナリオでは、リバース・プロキシ・サーバーは、ユーザーとOracle WebCenter Content Serverの間に位置します。リバース・プロキシ・サーバーは、リクエストされたオブジェクトのコピーを作成することにより、管理対象コンテンツ・アイテムをキャッシュします。別のユーザーが次回にドキュメントを要求すると、プライベート・キャッシュ内のコピーが表示されます。リバース・プロキシ・サーバーのキャッシュ内にオブジェクトが存在しない場合は、コピーがリクエストされます。

リバース・プロキシ・サーバーはキャッシュされたコンテンツを配信するため、Oracle WebCenter Content Serverと直接対話することはありません。そのため、Content Trackerではこれらのリクエストを検出できないため、このようなユーザー・アクセス・アクティビティを追跡できません。

リバース・プロキシ・サーバーは、キャッシュしたり、ファイアウォールの内側にあるアプリケーションやサイトへのWebアクセスを管理することによって、Webパフォーマンスを向上させるために使用されることがよくあります。そのような構成では、頻繁にアクセスされるコンテンツのコピーをWebサーバーに移動し、そこでスケジュールに基づいて構成を更新することによってロード・バランシングが実現します。

Webビーコン機能を有効にするために、各ユーザー・アクセスには、Oracle WebCenter Content Serverに存在する管理対象ビーコン・オブジェクトへの追加のリクエストが含まれています。これによって通常のリクエストよりもオーバーヘッドが増加しますが、Webビーコン・オブジェクトは非常に小さいため、リバース・プロキシ・サーバーのパフォーマンスに大きな影響を与えることはありません。必要なのが、特に追跡するオブジェクトにWebビーコン参照を埋め込む操作のみであることに注意してください。

別の使用シナリオに関係するのがSite Studioです。これは、Oracle WebCenter Content Serverで格納および管理されるWebサイトを作成するために使用される製品です。Site StudioとOracle WebCenter Content Serverが同じサーバーに存在する場合、Content Trackerは適用可能なユーザー・アクセスを自動的に追跡するように構成されます。収集されたSite Studioアクティビティ・データは、事前定義済レポートで使用されます。詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のSite Studio Webサイトのアクティビティ・レポートに関する項を参照してください。

注意:
Site StudioとContent Trackerの統合には2つのモードがあります。1つは、Site Studioがインストールされたときに自動的に行われる既存の組込み統合のタイプです。通常、これが使用されるのは、Webサイトが作成中で、WebページがOracle WebCenter Content Serverで管理されている場合です。
もう1つは、Webビーコン機能を使用して、Content TrackerがSite Studioを他のWebサイト・ジェネレータと同様に扱う形式です。通常、これが使用されるのは、Webサイトが本番モードで、コンテンツがOracle WebCenter Content Serverで管理されなくなった場合です。

Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにします。

12.6.2 Webビーコンの概要

Content Trackerでは、Oracle WebCenter Content Serverで管理されているオブジェクトに対するリクエストが記録されカウントされます。Webビーコン機能を使用すると、外部エンティティ(リバース・プロキシ・サーバーや、Oracle WebCenter Content Serverに関与しない他の機能など)でコピーされた管理対象オブジェクトに対するリクエストがカウントされます。

次のリストでは、Webビーコン機能および実装要件の概要を簡単に説明します。

- Webビーコン機能の実装を開始するには、Webビーコン・オブジェクトを作成します。これは通常、小さなオブジェクト(縦横1ピクセルの透明なイメージなど)です。次に、このオブジェクトをチェックインし、Content TrackerのWebビーコン・オブジェクト名リストに追加します。

- 次に、チェックインしたWebビーコン・オブジェクトへのWebビーコン参照を作成して、キャッシュされたHTMLページまたは管理対象コンテンツ・アイテムに埋め込みます。参照の最初の部分はWebビーコン・オブジェクトへのURL参照であり、2番目の部分は疑似問合せパラメータとしてエンコードされている識別情報です。

- Content Trackerでは、ビーコン・オブジェクトに対するWebビーコン参照がログに記録され、Webビーコン参照に対して削減処理が実行されます。データ削減中に、Content Trackerでは、登録されたWebビーコンのリストと照合して各参照先オブジェクトのdDocNameが確認されます。dDocNameがリストに存在する場合、問合せパラメータは、URLリクエストがWebビーコン・オブジェクトではなくタグ付きオブジェクト(Webページや管理対象コンテンツ・アイテム)に対するリクエストとしてログに記録されるように処理されます。

12.6.3 Webビーコン・オブジェクト

1つ以上のコンテンツ・アイテムを作成して、Webビーコン・オブジェクトとして使用する必要があります。これらは通常、縦横1ピクセルの透明なイメージなど、オーバーヘッドが小さくページのレンダリングを妨げないものが適しています。コンテンツがないWebビーコン・オブジェクトが理想的です。複数のWebビーコン・オブジェクトを作成できますが、必要なのは1つのみです。オブジェクトが、SctIgnoreFileType構成変数に含まれるファイル・タイプでないことを確認してください。

完成したオブジェクトをチェックインして、Content TrackerのSctWebBeaconIDList構成変数を更新します。データ削減中に、Content Trackerでは、SctWebBeaconIDList設定が確認され、イベント・ログ内のWebビーコン参照リストの処理方法が決定されます。適用可能なWebビーコン・オブジェクトがリストされている場合、Content Trackerではデータが適切に処理されます。構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

インストール中に、Webビーコン・オブジェクトのdDocNameをSctWebBeaconIDListプリファレンス変数に入力できます。また、後で追加または編集することもできます。IDリストでオブジェクト名を追加または編集するには、次の手順を実行します。

1. 「メイン」メニューで「管理」→「管理サーバー」を選択します。
「コンテンツ管理サーバー」ページが開きます。

2. Webビーコン・プリファレンス設定を変更するインスタンスの名前をクリックします。
「コンテンツ管理サーバー instance_name」ページが開きます。

3. 「コンポーネント・マネージャ」をクリックします。
「コンポーネント・マネージャ」ページが開きます。

4. 「コンポーネント構成の更新」フィールドで、リストから「Content Tracker」を選択します。

5. 「更新」をクリックします。
「コンポーネント構成の更新」ページが開きます。

6. SctWebBeaconIDListプリファレンス・フィールドに、適用可能なWebビーコン・オブジェクトのdDocNameをカンマで区切って入力します。

7. 「更新」をクリックします。

8. Oracle WebCenter Content Serverを再起動して変更内容を適用します。

12.6.4 Webビーコン参照

Webビーコン・オブジェクトを作成してチェックインした後で、対応する参照を作成します。異なる問合せ文字列がWebビーコンの静的URLに付加されることによって各参照が一意になるため、ほとんどのシステムでWebビーコン・オブジェクトは1つで十分です。また、各問合せパラメータ・セットは、キャッシュされた特定のWebページまたは管理対象コンテンツ・アイテムを識別する変数の個別の組合せで構成されます。

12.6.4.1 URL参照のフォーマット構造

WebビーコンURL参照は、Oracle WebCenter Content Serverで管理されるWebビーコン・オブジェクトへのアクセスに使用するWebビーコン静的URL、およびコンテンツ・アイテム変数を指定した擬似問合せ文字列で構成されます。

参照を作成するときは、Oracle WebCenter Content Server内のWebビーコン静的URLに、SctIgnoreDirectories構成変数に含まれるディレクトリ・ルートが使用されていないことを確認してください。URLが、リストされている値のいずれかである場合は、Content Trackerではアクティビティ・データが収集されません。SctIgnoreDirectories構成変数の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

問合せパラメータ・セットは、ユーザーがアクセスした実際の管理対象コンテンツ・アイテムをContent Trackerに通知するコードとして機能します。問合せパラメータの1つがアイテムのdIDです。問合せパラメータ値の一意のセットを含めることによって、コピーおよびキャッシュされた管理対象オブジェクトに対する間接ユーザー・アクセス・アクティビティを監視できます。問合せ文字列が実際に実行されることはありませんが、問合せパラメータ値によって、関連付けられている管理対象オブジェクトをContent Trackerが識別するために十分な情報が提供されます。

次の例では、Webビーコン機能に関連する一般的なフォーマット構造について説明します。これらの例では、異なる問合せ文字列を数に制限なく作成しながら、1つのWebビーコン・オブジェクトを使用する方法について説明します。すべての例で、同じWebビーコン・オブジェクト(dDocName = bcn_2.txt)を使用します。このWebビーコン・オブジェクトに対するリクエストは、問合せパラメータを変えることによって、リポジトリ内のすべての管理対象オブジェクトに対するリクエストをContent Trackerに通知できます。

これらの例では、次のことを想定しています。

- Webビーコン・オブジェクト(bcn_2.txt)はチェックインされ、Webビーコン・リスト(SctWebBeaconIDList)に含まれています。

- 適用可能なWebビーコン参照は、関連付けられた管理対象コンテンツ・アイテム(doc1、doc2およびdoc3)に埋め込まれています。

- Webビーコン参照を解決するために、ブラウザではWebビーコン・オブジェクトのコピーをOracle WebCenter Content Serverからリクエストする必要があります。

- ユーザーが関連するコンテンツ・アイテムを間接的にリクエストするため、Webビーコン・リクエストが発生します。

例12-1 問合せパラメータを使用しないWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt

これは、Webビーコン・オブジェクトへの静的Web参照から始まります。これはWebビーコン・オブジェクトへの正当な直接アクセスですが、問合せパラメータは追加されていません。Content Trackerでは、このアクセス・イベントをWebビーコン・オブジェクト自体に対するリクエストとして処理します。

例12-2 doc1を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc1&sct_dID=1234&...

これも、このビーコン・オブジェクトへの通常の静的Web参照から始まります。これには任意の数の問合せパラメータを含む擬似問合せ文字列が追加されています。これらの問合せパラメータに含まれる値によって、ユーザーがリクエストした特定の管理対象オブジェクト(doc1)に関する情報が通知されます。

例12-3 doc2を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4

これは、例12-4に似ています。パラメータ値によって、ユーザーがリクエストしたコンテンツ・アイテム(doc2)に関する情報が提供されます。この例では、問合せ文字列に、タグ付きアイテムに関する追加情報を通知するための別のパラメータが含まれています。追加されたパラメータではextField列名が使用されます。値WebSite4はSctAccessLog表のextField_2列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。

例12-4 doc3を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4&sct_Ext_8=SubscriptionClass6

この例では、2番目(ただし、シーケンシャルでない)のextField列名を追加することによって、例12-3を変更します。この場合、WebSite4はSctAccessLog表のextField_2列にコピーされ、SubscriptionClass6はextField_8列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。

12.6.4.2 配置および取得スキーム

追跡する管理対象オブジェクトに、特別に作成されたWebビーコン参照を埋め込む必要があります。Webビーコン参照はHTMLページに埋め込むことができます。ユーザーは、変更された管理対象コンテンツ・アイテムへのアクセスを、外部のSite Studio Webサイトまたはリバース・プロキシ・サーバーを介して、間接的にリクエストします。

ブラウザでは、ページのレンダリング中にWebビーコン参照を検出します。管理対象オブジェクトを表示するたびに、オブジェクトの取得方法に関係なく、ブラウザではWebビーコン・オブジェクトのコピーをOracle WebCenter Content Serverから直接リクエストします。ブラウザがWebビーコン参照を解決すると、Content Trackerでは、Webビーコン参照、および管理対象コンテンツ・アイテムを識別するための擬似問合せパラメータを含むデータを取得します。

12.6.4.3 データの取得と格納

通常、静的URL内の問合せパラメータは、Webブラウザに対してなにも機能しません。ただし、Webビーコン静的URLを解決するとき、Webブラウザでは、Content TrackerのWebサーバー・フィルタ・プラグインで記録できる長さの追加問合せパラメータは無視されます。擬似問合せパラメータが実行されることはありませんが、Content Trackerでは、問合せパラメータ値とともに、クライアントIPアドレスや日時スタンプなどの他のデータも取得します。Content Trackerでは、データをWebアクセス・イベント・ログに記録します。

12.6.5 Webビーコン参照の削減処理

データ削減中に、特別に作成されたWebビーコン参照が処理されると、Content Trackerでは、WebビーコンのdDoc NameをSctWebBeaconIDリストのdDocNameのリストと比較して、通常のコンテンツ・アイテムではなくWebビーコン・オブジェクトに対するリクエストであるかどうかを判別します。

一致するものがない場合、または問合せパラメータがWebビーコン参照に追加されていない場合、Content Trackerではアクセス・イベントを通常どおりに処理します。WebビーコンのdDocNameが特定された場合、Content Trackerでは処理を続行し、関連付けられたURLの問合せパラメータを解釈します。また、データ削減プロセスでは、Webビーコン・アクセス・リクエストが、Webページまたはコンテンツ・アイテムへのリクエストとして扱われます。

データ削減中に、Content Trackerでは、問合せパラメータを解析し、最終的にSctAccessLogに書き込まれるフィールドの様々な値の置換を実行します。問合せパラメータ値は次のようにマップされます。

- sct_dIDはWebビーコン・オブジェクトのdIDを置換します。

- sct_dDocNameはWebビーコン・オブジェクトのdDocNameを置換します。

- sct_uriStemはWebビーコン・オブジェクトのURIステム(「?」より前の部分)を置換します。

- sct_uriQueryはWebビーコン・オブジェクトのURI問合せ部分(「?」より後の部分)を置換します。

- sct_Ext_nはSctAccessLogの拡張フィールドnに直接コピーされます。

例12-5 問合せパラメータ値のデータ削減処理

/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=WW_1_21&sct_dID=42&sct_Ext_1=WillowStreetServer&sct_Ext_2=SubscriptionTypeA

データ削減の後、Content Trackerでは、このWebビーコン・タイプのリクエストを、bcn_2.txtではなくWW_1_21へのアクセスとしてSctAccessLog表に記録します。ユーザー名、アクセス時刻、クライアントIPなど、他のデータがHTTPリクエストから導出されます。さらに、WillowStreetServerはSctAccessLog表のextField_1列にコピーされ、SubscriptionTypeAはextField_2列にコピーされます。(最後の2つのフィールド置換はオプションで、アプリケーションに依存しています。)

12.6.6 制限事項とガイドライン

Content TrackerのWebビーコン機能を実装するには、次の手順を実行します。

1. Webビーコン・オブジェクトを作成します。

2. これをチェックインします。

3. SctWebBeaconIDListを更新します。

4. Webビーコン参照を定義します。

5. これらを、追跡対象になるキャッシュ済コンテンツ・アイテムまたはWebサイト(あるいはその両方)に埋め込みます。

12.6.6.1 制限事項

次の制限事項を検討してください。

- 1つの難点は、Webビーコン参照をタグ付きオブジェクトに添付する方法を決定することです。リクエストされたオブジェクトに参照を埋め込むことができない場合があります(PDF文書やWord文書など)。この場合は、実際のコンテンツ・アイテムがリクエストされる前に、Webビーコン・オブジェクトをOracle WebCenter Content Serverから直接リクエストする必要があります。

- Webビーコン機能は、特定のブラウザ構成の場合など、多くの状況で動作しません。ユーザーがブラウザでクロスドメイン参照を無効にしていて、WebページとOracle WebCenter Content Serverのインスタンスが両方とも別々のドメインにある場合は、Webビーコン・オブジェクトはOracle WebCenter Content Serverからリクエストされず、ユーザー・アクセスはカウントされません。 Content ServerContent Server

- リバース・プロキシ・サーバーを経由して最初に管理対象コンテンツ・アイテムにアクセスすると、Oracle WebCenter Content Serverがアイテムをリバース・プロキシ・サーバーに提供したときに1回、ブラウザがWebビーコン・オブジェクトをリクエストしたときに1回の計2回カウントされます。

- 特定の構成によっては、リバース・プロキシ・サーバーおよび外部のSite StudioがWebビーコン・オブジェクト自体をキャッシュしない方法を考案する必要があります。ブラウザでもキャッシュが行われます。この状況では、コンテンツ・サーバーは関連するコンテンツ・アクセスをカウントできません。これを回避するには、この例にあるように、乱数を含む1回かぎりの問合せパラメータをWebビーコン参照に追加します。
dDocName=vvvv_1_21&FoolTheProxyServer=12345654321

各リクエストの数値を変更することによって、キャッシュ、Webサーバーおよびブラウザは、リクエストを新規とみなします。

12.6.6.2 ガイドライン

次のガイドラインを考慮する必要があります。

- Webビーコン参照のsct_dDocNameおよびsct_dIDパラメータ値は、リクエストされたWebビーコン・オブジェクトを提供する同じOracle WebCenter Content Serverのインスタンス内で、実際の管理対象コンテンツ・アイテムに解決される必要があります。

- SctAccssLog表のExtField列の使用はオプションで、アプリケーションに依存しています。

- ExtField_10は、Webビーコン・オブジェクトのdDocName用に使用するために予約されています。これによって、レポート作成者は、実際の管理対象コンテンツ・アイテムへのアクセスを通知するのに使用されたWebビーコン・オブジェクトを判別できます。

- 問合せパラメータ名のスペルおよび大/子文字は正確である必要があります。

- 問合せパラメータ値に、カンマや空白を埋め込むことはできません。

- Webビーコン参照には通常、管理対象オブジェクトのdDocNameおよびdIDが含まれますが、正当なアクセス・リクエストとみなされるには、両方とも含まれる必要はありません。標準フィールドの一部が欠落している場合、Content Trackerでは次のように識別情報パラメータが解決されます。

- dIDを指定すると、Content Trackerではコンテンツ・アイテムのdDocNameを判別できます。

- dDocNameを指定すると、Content Trackerではコンテンツ・アイテムのdIDを判別できます。dIDはコンテンツ・アイテムの最新リビジョンです。コンテンツ・アイテムがキャッシュされた後にリビジョンが変更された場合、ユーザーには古いバージョンが表示されます。ただし、Content Trackerでは、コンテンツ・アイテムの最新リビジョンの表示としてこのアクセス・リクエストがカウントされます。

- 適切なURIステムを指定すると、Content Trackerではコンテンツ・アイテムのdDocNameを判別できますが、最新リビジョンのdIDであるとみなされます。

- Webビーコン・リスト(SctWebBeaconIDList)の変更後に、Oracle WebCenter Content Serverを再起動します。

- ファイル・タイプを使用するWebビーコン・オブジェクトを作成したり、Content Trackerで無視するように構成されているディレクトリ内にWebビーコン・オブジェクトを配置しないでください。

- Content Trackerでは、キャッシュされたコンテンツ・アイテムが配信されたかどうかを確認できません。

- Content Trackerでは、静的URLアクセスの通常の折りたたみ動作が実行されます。ユーザーが同じコンテンツ・アイテムを繰返しリクエストし、別のドキュメントに対するリクエストが途中で介入しない場合、Content Trackerでは連続するリクエストは同じドキュメントであるとみなされます。この場合、これらのアクセス・リクエストはすべて1つのアクセス・リクエストとみなされます。

- 問合せパラメータは任意の管理対象オブジェクトを表すことができ、必ずしもユーザーに実際に表示されている内容である必要はありません。

12.6.7 Webビーコン埋込みの例

Webビーコン機能を実装するには、いくつかの埋込み方法を使用できます。各方法にはそれぞれ長所と短所があり、特定の状況に応じて最適な方法は異なります。システム構成には違いがあるため、最適な1つの方法があるわけではありません。

以降に示す例ではすべて、次の情報を使用しています。

- WebBeacon.bmp Webビーコン・オブジェクト

- Oracle WebCenter Content ServerのインスタンスIFHE.comcast.net/idc/

- dDocName of wb_bmp

すべての例のコード・フラグメント・ファイルは、Content Trackerのドキュメント・ディレクトリに含まれています。これらの例は、一般的なアプローチを示すことを意図したものであり、開始ポイントとして提供されています。使用しているアプリケーションやネットワーク・トポロジで機能するように調整が必要になります。

12.6.7.1 HTMLに埋め込む方法の例

管理対象コンテンツ・アクセスを追跡するWebビーコンを最も簡単かつ直接的に使用するには、ビーコンへの参照を対象のWebページのHTLMソースに直接埋め込みます。リクエスト・ユーザーのブラウザでは、ページをレンダリングするとき、Webビーコン・オブジェクトが存在するインスタンスにリクエストが送信されます。

この例では、追跡対象のWebページにイメージ・タグが配置されます。イメージのsrc attributeは、インスタンスにチェックインされているWebビーコン・オブジェクト(wb_bmp)を参照します。ユーザーのブラウザでインスタンスからイメージをロードすると、追加の問合せ情報が記録され、最終的にdDocName BOPRへの参照として解釈されます。

この方法は簡単ですが、ユーザーのブラウザまたはリバース・プロキシ・サーバーでWebビーコン・オブジェクトのコピーがキャッシュされるという短所があります。このため、インスタンスに直接送信される追加リクエストはなく、このWebビーコンがタグ付けされているコンテンツへの追加アクセスはカウントされません。

この方法のHTMLフラグメントは次のように記述できます。

<!-- WebBeaconEmbeddedHtml.htm - Adjust the Web Beacon web location and managed object identfiers in the img src attribute, then paste into your web page -->
<img src="http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp?sct_dID=1&sct_dDocName=BOPR&sct_uriStem=http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf&sct_Ext_1=Sample_Html_Beacon_Access" width="21" height="21" />

12.6.7.2 JavaScriptに埋め込む方法の例

Webビーコンのキャッシュに関する問題は、HTMLのかわりにJavaScriptを使用することによって解決でき、このJavaScriptを埋め込む方法には、2つのスクリプト・タグが必要です。

- cs_callWebBeacon関数は、実際のWebビーコン・リクエストを発行します。

- 名前の付いていないブロックでは、コンテキスト値を特定のJavaScript変数に割り当ててcs_callWebBeacon関数を呼び出します。

管理対象コンテンツ・オブジェクトに関して識別される情報は変数のリストに定義されるため、読みやすくなります。乱数を擬似問合せパラメータに追加することによって、Webビーコン・リクエストを効率的に一意にすることもできます。

デメリットとしては、管理対象のコードが増えることや、Webビーコン・サーバーのURLが各Webページにハードコードされることなどがあります。また、ユーザーのブラウザで、JavaScriptが有効になっていない場合も考えられます。

この方法のJavaScriptフラグメントは次のように記述できます。

// WebBeaconEmbeddedJavascript.js - Adjust the managed object and Web Beacon descriptors,
then paste this into your web page.
//

<script type="text/javascript" >

var cs_obj_dID = "" ;
var cs_obj_dDocName = "" ;
var cs_obj_uriStem = "" ;
var cs_extField_1 = "" ;
var cs_extField_2 = "" ;
var cs_extField_3 = "" ;
var cs_extField_4 = "" ;
var cs_extField_5 = "" ;
var cs_extField_6 = "" ;
var cs_extField_7 = "" ;
var cs_extField_8 = "" ;
var cs_extField_9 = "" ;
var cs_beaconUrl = "" ;

function cs_void( ) { return ; }

function cs_callWebBeacon( ) {
//
var cs_imgSrc = "" ;
var cs_inQry = false ;

if ( cs_beaconUrl && cs_beaconUrl != "" ) {
cs_imgSrc += cs_beaconUrl ;
}

if ( cs_obj_dID && cs_obj_dID != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_dID=" + cs_obj_dID ;
}

if ( cs_obj_dDocName && cs_obj_dDocName != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_dDocName=" + cs_obj_dDocName ;
}
if ( cs_obj_uriStem && cs_obj_uriStem != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_uriStem=" + cs_obj_uriStem ;
}

if ( cs_extField_1 && cs_extField_1 != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_Ext_1=" + cs_extField_1 ;
}

if ( cs_extField_2 && cs_extField_2 != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_Ext_2=" + cs_extField_2 ;
}

<!-- and so on for the remaining extended fields -->

if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}

var dc = Math.round( Math.random( ) * 2147483647 ) ;
cs_imgSrc += "sct_defeatCache=" + dc ;

var wbImg = new Image( 1, 1 ) ;
wbImg.src = cs_imgSrc ;
wbImg.onload = function( ) { cs_void( ) ; }

}

</script>

<script type="text/javascript">
//
var cs_obj_dID = "1" ;
var cs_obj_dDocName = "BOPR" ;
var cs_obj_uriStem = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf" ;
var cs_extField_1 = "Sample_Javascript_Beacon_Access" ;
var cs_beaconUrl = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp" ;

cs_callWebBeacon( ) ;

</script>

12.6.7.3 JavaScriptを処理する方法の例

「JavaScriptを埋め込む方法の例」で説明したWebビーコン・サーバーのハードコードに関する問題は、コードを2つのフラグメントに分割することによって解決します。

- 管理対象コード・フラグメントには、cs_callWebBeacon関数が含まれています。これは、Oracle WebCenter Content Serverのインスタンス(Webビーコンを管理するインスタンス、または他のインスタンスのいずれか)にチェックインして管理できます。ページ内コード・フラグメントに含まれるsrc属性は管理対象コード・フラグメントを参照し、これによってWebページに動的にロードされます。

- ページ内コード・フラグメントは2つの<script>タグで構成されますが、最初のタグには、コード自体ではなくcs_callWebBeaconコードへの参照のみが含まれます。この方法の長所は、cs_callWebBeacon関数に対する変更を一元管理できるため、すべてのタグ付きWebページをそれぞれ変更する必要がないことです。
このソリューションでは管理対象コードをユーザーのブラウザ上のWebページにロードするため、追加のネットワーク・オーバーヘッドが発生します。ただし、Webビーコンに対する要件は追跡処理の支援であるため、ネットワーク環境には効率的なリバース・プロキシ・サーバーや他のキャッシング・メカニズムが含まれています。また、管理対象オブジェクトへのアクセスに同じキャッシュを使用することによって、コードのダウンロードによる影響を最小限に抑えることもできます。

管理対象コード・フラグメント

// WebBeaconServedJavascript_Checkin.js - Check this in to your Content Server, then fixup
// the JavaScript include src attribute in WebBeaconManagedJavascriptIncludeSample.js
//
var cs_obj_dID = "" ;
var cs_obj_dDocName = "" ;
var cs_obj_uriStem = "" ;
var cs_extField_1 = "" ;
var cs_extField_2 = "" ;
var cs_extField_3 = "" ;
var cs_extField_4 = "" ;
var cs_extField_5 = "" ;
var cs_extField_6 = "" ;
var cs_extField_7 = "" ;
var cs_extField_8 = "" ;
var cs_extField_9 = "" ;
var cs_beaconUrl = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp" ;

function cs_void( ) { return ; }

function cs_callWebBeacon( ) {
//
var cs_imgSrc = "" ;
var cs_inQry = false ;

if ( cs_beaconUrl && cs_beaconUrl != "" ) {
cs_imgSrc += cs_beaconUrl ;
}

if ( cs_obj_dID && cs_obj_dID != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_dID=" + cs_obj_dID ;
}

if ( cs_obj_dDocName && cs_obj_dDocName != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_dDocName=" + cs_obj_dDocName ;
}

if ( cs_obj_uriStem && cs_obj_uriStem != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_uriStem=" + cs_obj_uriStem ;
}

if ( cs_extField_1 && cs_extField_1 != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_Ext_1=" + cs_extField_1 ;
}

if ( cs_extField_2 && cs_extField_2 != "" ) {
if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}
cs_imgSrc += "sct_Ext_2=" + cs_extField_2 ;
}

<!-- and so on for the remaining extended fields -->

if ( cs_inQry ) {
cs_imgSrc += "&" ;
} else {
cs_imgSrc += "?" ;
cs_inQry = true ;
}

var dc = Math.round( Math.random( ) * 2147483647 ) ;
cs_imgSrc += "sct_defeatCache=" + dc ;

var wbImg = new Image( 1, 1 ) ;
wbImg.src = cs_imgSrc ;
wbImg.onload = function( ) { cs_void( ) ; }

}

ページ内コード・フラグメント

<script type="text/javascript" src="http://IFHE.comcast.net/idc/groups/public/documents/adacct/wbmjcs.js" >
</script>

<script type="text/javascript">
//
var cs_obj_dID = "1" ;
var cs_obj_dDocName = "BOPR" ;
var cs_obj_uriStem = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf" ;
var cs_extField_1 = "Sample_Managed_Javascript_Beacon_Access" ;

cs_callWebBeacon( ) ;

</script>

13 Content Categorizerのカスタマイズ

この章では、Oracle WebCenter Content Serverとともに自動的にインストールされるオプションのコンポーネントであるContent Categorizerのカスタマイズについて説明します。Content Categorizerが有効化されているときは、suggestsコンテンツ・サーバーにチェックインされているドキュメントのメタデータ値が提案されます。

- 第13.1項「Content Categorizerについて」

- 第13.2項「Content Categorizerのカスタマイズ

13.1 Content Categorizerについて

Content Categorizerでは、コンテンツ・サーバーにチェックインする新しいドキュメントのメタデータ値と、メタデータ値がすでに存在するかどうかに関係なく、既存のドキュメントのメタデータ値が推奨されます。これらのメタデータ値は、システム管理者が指定した検索ルールに従って決定されます。

Content Categorizerで構造プロパティを認識するためには、コンテンツにXML変換(eXtensible Markup Language)を行う必要があります。

Content Categorizerのバッチ・ユーティリティでは、大量のファイルを検索したり、適切なメタデータ・フィールド値を含むバッチ・ローダー制御ファイルを作成できます。バッチ・ユーティリティは、既存のコンテンツ(リポジトリにチェックイン済)を再分類するために使用することもできます。

13.2 Content Categorizerのカスタマイズ

自社のサイト向けにContent Categorizerをカスタマイズするために、XML変換メソッドを設定したり、メタデータ・フィールドのフィールド・プロパティを定義したり、ファイル・タイプごとの検索ルールを定義することができます。自社のサイトのドキュメント処理ニーズに対応するため、XML変換用に独自のeXtensible Style Sheet Language Transformations(XSLT)を定義することもできます。

Content Categorizerの設定とカスタマイズの詳細は、『Oracle WebCenter Content Content Serverアプリケーション管理者ガイド』のContent Categorizerの使用に関する項およびContent Categorizerのインタフェースに関する項を参照してください。

14 カスタム・コンポーネントのダウンロード

この章では、パッケージ化されているカスタム・コンポーネントをOracle WebCenter Content Serverにダウンロードする方法について説明します。

この章では、次の項目について説明します。

- 第14.1項「カスタム・コンポーネントのダウンロードについて」

- 第14.2項「拡張コンポーネント・マネージャを使用したコンポーネントのダウンロード」

- 第14.3項「Oracle Technology Networkからのコンポーネントのダウンロード」

14.1 カスタム・コンポーネントのダウンロードについて

コンテンツ・サーバーのカスタム・コンポーネントは、拡張コンポーネント・マネージャを使用して、またはOracle Technology Networkからダウンロードできます。

14.2 拡張コンポーネント・マネージャを使用したコンポーネントのダウンロード

拡張コンポーネント・マネージャを使用して、コンテンツ・サーバーのコンポーネントをダウンロードできます。

コンポーネントをダウンロードする手順は次のとおりです。

1. 「管理」トレイまたはメニューで、「管理サーバー」を選択します。
管理サーバーにコンポーネント・マネージャ・ページが表示されます。

2. コンポーネント・マネージャ・ページの最初の段落で、「拡張コンポーネント・マネージャ」をクリックします。
これで拡張コンポーネント・マネージャ・ページが表示され、ダウンロードできるコンポーネントのリストが提示されます。

3. パッケージ化するコンポーネントを、「コンポーネントのダウンロード」リストから選択します。

4. 「ダウンロード」をクリックし、「ファイルのダウンロード」画面を表示します。

5. このファイルをディスクに保存を選択して、「OK」をクリックします。

6. 「別名保存」ダイアログ・ボックスで、ディレクトリに移動して、必要に応じてファイル名を変更し、「保存」をクリックします。

14.3 Oracle Technology Networkからのコンポーネントのダウンロード

コンテンツ・サーバーのコンポーネントは、Oracle Technology Network(OTN)からダウンロードできます。

OTNからコンポーネントをダウンロードする手順は次のとおりです。

1. Webブラウザで、OTNのWebサイト(http://www.oracle.com/technetwork/middleware/downloads/index.html)にアクセスします。

2. Oracle Fusion Middleware 11gソフトウェアのダウンロード・ページで、左側の「WebCenter Content」をクリックします。

3. 「Oracle WebCenter Content」ページで「Core Capabilities」をクリックします。

4. 「Oracle WebCenter Content Core Capabilities」ページで「Download」をクリックします。

5. 「Downloads」ページで「Individual UCM Component Downloads」をクリックして、目的のコンポーネントをダウンロードします。

15 カスタム・コンポーネントの作成

この章では、Oracle WebCenter Content Serverで使用するカスタム・コンポーネントを作成する方法について説明します。

この章では、次の項目について説明します。

- 第15.1項「カスタム・コンポーネントの作成について」

- 第15.2項「コンポーネントのリソースの作成」

- 第15.3項「コンポーネント定義ファイルの作成」

- 第15.4項「コンテンツ・サーバーの再起動によるコンポーネントの適用」

15.1 カスタム・コンポーネントの作成について

カスタム・コンポーネントを使用すると、システムのデフォルトの変更、新機能の追加または反復性の機能の整備ができます。カスタム・コンポーネントを作成および使用して、システムの整合性を失わないでコンテンツ・サーバーのインスタンスを変更できます。

15.2 コンポーネントのリソースの作成

コンテンツ・サーバーをカスタマイズするには、次のタイプのリソースを使用できます。

- HTMLインクルード

- 動的データ表

- 文字列リソース

- 動的表

- 静的表

- 問合せ

- サービス

- テンプレート

- 環境リソース

15.2.1 HTMLインクルード

インクルードは、HTMリソース・ファイルの<@dynamichtml name@>タグと<@end@>タグの中に定義されます。続いてインクルードは、次の構文を使用して呼び出されます。

<$include name$>

インクルードには、Idocスクリプトおよび有効なHTMLコード(JavaScript、Javaアプレット、カスケード・スタイルシート、コメントなど)を含めることができます。インクルードは、呼出し元と同じファイルで定義するか、または別のHTMファイルで定義することができます。標準的なHTMLインクルードは、IdcHomeDir/resources/core/idocファイルで定義されます。

HTMLインクルード、文字列および静的表は、同じHTMファイルにあってもかまいません。HTMLインクルード・リソースには、マージ・ルールは不要です。

15.2.1.1 superタグ

既存のHTMLインクルードに対する例外を定義するには、superタグを使用します。superタグはインクルードに対して、既存のインクルードで始め、指定されたコードを使用して、そのインクルードに追加するか、またはそのインクルードを変更するように指示します。

superタグが特に役立つのは、大規模なインクルードに小規模なカスタマイズを行う場合や、ソフトウェアが次のバージョンになったときに変わる可能性の高い標準コードをカスタマイズする場合です。新しいバージョンのOracle WebCenter Content Serverにアップグレードする場合は、superタグによって、コンポーネントが、最新バージョンのインクルードを使用し、インスタンスのカスタマイズに必要な特定のコードのみを変更するようになります。

superタグでは、次の構文を使用します。

<@dynamichtml my_resource@>
<$include super.my_resource$>
exception code
<@end@>

superタグを使用して、標準的なインクルードまたはカスタム・インクルードを参照できます。superタグには、最後にロードされたインクルードが組み込まれます。

注意:
superタグの配置によって、Idocスクリプトがどのように評価されるかが決まります。

例15-1は、superタグの使用例を示しています。

例15-1 superタグ

この例では、コンポーネントによって、my_resourceインクルードが次のように定義されます。

<@dynamichtml my_resource@>
<$a = 1, b = 2$>
<@end@>

後でロードされた別のコンポーネントでは、superタグを使用して、my_resourceインクルードが拡張されます。次の拡張を行うと、aには値1が割り当てられ、bには値3が割り当てられます。

<@dynamichtml my_resource@>
<$include super.my_resource$>
<!--Change "b" but not "a" -->
<$b = 3$>
<@end@>

15.2.1.2 HTMLインクルード・リソースの編集

コンポーネント・ウィザードを使用して既存のHTMLインクルード・リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「インクルード」タブをクリックします。

4. 「カスタムHTMLインクルード」リストでインクルードを変更します。

- 既存のインクルードを編集するには、インクルードを選択して「編集」をクリックし、コードを変更して「OK」をクリックします。

- リソース・ファイルにインクルードを追加するには、「追加」をクリックします。

- インクルードを削除するには、インクルードを選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.2 動的データ表

動的データ表のリソースはdynamicdata表です。このタイプのリソースを使用すると、HTML表定義、インタフェース・メニュー・アクション、またはメタデータ・フィールドに関する情報をロードするIdocスクリプト内から、あるいは、SharedObjectにロードされた静的表に対する代替としてJavaコード内から、データの表を定義できます。

SharedObjectにロードされる表は静的でめったに変更されませんが、dynamicdata表がユーザーのコンテキストにロードされると、コンテンツ・サーバー内の数多くのコードによって、この表の内容が変更されます。dynamicdataのリソースを使用すると、ユーザーが実行している具体的なアクションに対するセキュリティ属性の任意の要素に応じて、様々なデータをユーザーの画面に表示できます。コンポーネントは、このリソース・タイプで作成された表に、ターゲットを絞ったマージを実行でき、Idocスクリプト・ページは行の選択とソートができます。

例15-2に示すように、dynamichtml構成を含めることのできる任意のリソース・ファイルで、dynamicdataリソースを宣言できます。

例15-2 dynamicdataリソース

<@dynamicdata NameOfTable@>
<?formatoftable properties-of-table?>
table-data
<@end@>

dynamicdata表は、リソース・ファイルの<@dynamicdata name@>タグと<@end@>タグの中に定義されます。dynamicdata表を参照するには、Idocスクリプトの関数を使用する必要がありますが、その関数は、ddLoadResultSetのように、名前の先頭がddで、マージされたdynamicdata表をロードし、現在のデータ・バインダにResultSetを作成するものです。

IdcHomeDir/resources/core/idocファイルでは、標準的なdynamicdataリソースを定義します。

15.2.2.1 表の形式の指定

dynamicdataリソースのformatoftableパラメータでは、次の2つの形式タイプのいずれかを指定できます。

- commatable

- htmltable

デフォルトの形式はcommatableです。

commatable

commatableとは、値に行送りも改行もない表の形式です。例15-3に示すように、この形式では、フィールド名のカンマ区切りのリストを1つの行に入力し、値のカンマ区切りのリストを後続の行に入力できます。この場合、1行の対象が各フィールドになります。

例15-3 commatable形式

<@dynamicdata SampleTable@>
<?commatable?>
col1,   col2
val1_1, val1_2
val2_1, val2_2
<@end@>

値にカンマ(,)を挿入する必要がある場合は、カンマでなく曲折アクセント記号(^)を使用します。例15-4に示すように、曲折アクセント記号を挿入する必要がある場合は、エスケープ・シーケンスのハッシュ-曲折アクセント記号(#^)を入力し、ハッシュまたは曲折アクセント記号が後に続くハッシュ(#)を挿入する必要がある場合は、エスケープ・シーケンスのハッシュ-ハッシュ(##)を入力します。

例15-4 値での特殊文字

<@dynamicdata SampleTable@>
field1, field2
A^B,    C##^D#^E#F^G
<@end@>

このdynamicdataリソースでは、field1の値がA,B、field2の値がC#^D^E#F,Gとなる表の行がロードされます。

行送りも改行もエスケープはできません。これらの文字列のいずれかを含む値を指定する必要がある場合は、htmltable形式を使用してください。

htmltable

例15-5に示すように、htmltable形式は、コンテンツ・サーバーにおける静的なHTML表構成と同じ形式です。

例15-5 htmltable形式

<@dynamicdata SampleTable@>
<?htmltable?>
<table>
<tr>
<td>col1</td>
<td>col2</td>
</tr>
<tr>
<td>val11</td>
<td>val12</td>
</tr>
<tr>
<td>val21</td>
<td>val22</td>
</tr>
</table>
<@end@>

15.2.2.2 動的データ表リソースの編集

コンポーネント・ウィザードを使用して既存のdynamicdataリソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「インクルード」タブをクリックします。

4. カスタム・リソース定義におけるdynamicdata表のいずれかを変更したり、dynamicdata表を追加したり、dynamicdata表を削除することができます。

- 既存のdynamicdata表を編集するには、表を選択して「編集」をクリックし、コードを変更して「OK」をクリックします。

- リソース・ファイルにdynamicdata表を追加するには、「追加」をクリックします。

- dynamicdata表を削除するには、表を選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.2.3 表のプロパティの指定

dynamicdataリソースのproperties-of-tableパラメータの形式は次のとおりです。

field1="value1" field2="value2" . . .

プロパティは、XMLノードに定義された属性に似ています。例15-6は、一般的な表宣言を示しています。

例15-6 表定義における表のプロパティ

<@dynamicdata ExampleTable@>
<?commatable mergeField="fieldA" indexedColumns="fieldA,fieldB"?>
fieldA, fieldB
1,      2
3,      4
<@end@>

値を囲む引用符は、空白のない値では省略可能であり、引用符は一重と二重のどちらでも使用できます。また、プロパティのデフォルト値は"1"であるため、表のプロパティの値が"1"の場合は、値の割当てを省略できます。

この値を省略することは、notrimやmergeBlanksのようなブール型プロパティの場合に役立ちます。例15-7は、値をトリミングしない表を指定する宣言を示しています。

例15-7 notrimプロパティ

<@dynamicdata ExampleTable@>
<?commatable mergeField="fieldA" indexedColumns="fieldA,fieldB" notrim?>
fieldA, fieldB
1, 2
3, 4
<@end@>

この例では、2または4の前に空白があってもトリミングされません。(フィールド名は常にトリミングされます。)

次の種類の表のプロパティを指定できます。

- マージ・プロパティ

- アセンブリ・プロパティ

- ソート・プロパティ

- フィルタとdynamicdata表のプロパティ

15.2.2.3.1 マージ・プロパティ

dynamicdata表は自動的にまとめてマージでき、これは、これらの表を使用することの力の一部です。名前の同じdynamicdata表が2つ、別々のリソース・ファイルにある場合は、自動的にマージされます。mergeOtherDataオプションを使用して、別の既存の表を現在の既存の表にマージできます。この手法を使用すると、他の様々な表からすべてマージされた複雑な表を構築できます。このマージを行うと、データの可読性を向上でき、一部の表を他の表のサブセットにすることができます。

dynamicdataリソースのproperties-of-tableパラメータで、次のマージ・プロパティを1つ以上指定できます。

- mergeKey: マージの実行場所とするフィールドの名前。この値は、オーバーレイを行うときに、この表と既存の表の両方に適用されます。ただし、mergeNewKeyが設定されている場合は、既存の表にのみ適用されます。この値が設定されていない場合は、マージ・キーによって、この表の最初の列がデフォルトに設定されます。mergeKeyが、既存の表に存在していない列を参照している場合は、既存の表にこの表が付加されます。ただし、mergeRuleが、別の結果を指定する値に設定されている場合は除きます。このプロパティにはマージ・スコープが指定されています。

- mergeNewKey: この表の中で、既存の表のmergeKey列と比較するときの基準として使用するフィールドの名前。デフォルトは、mergeKeyの値となります。このプロパティにはマージ・スコープが指定されています。

- mergeRule: 2つの表のマージを実行するときに使用するルール。このプロパティには3つの値を指定でき、そのデフォルトはmergeです。このプロパティにはマージ・スコープが指定されています。

- merge: マージを実行するためにmergeKey(および、指定した場合はmergeNewKey)のプロパティを使用したマージ。

- mergenoappend: マージを実行しますが、新規の行はいっさい付加しません。実行する有効なマージがない(たとえば、mergeKeyが、既存の表の有効な列を参照しない)場合は、マージはいっさい実行されず、表が重なっても最終結果に影響はありません。

- replace: 既存の表をこの表に置換します。このオプションの結果として、先行する表のリソースが抑制されます。これは、dynamichtmlリソースでスーパー・インクルードを使用しないのと同じです。

- mergeBlanks: デフォルトでは、この表から既存の表に値がマージされたときには、この表に空白の値があれば、既存の表で重ね合される値は置換されません。これにより、既存の表にある列の値をターゲットに絞り、この表で置換ができます。ただし、このオプションが有効になっている(値なしで設定されているか、あるいは値を1またはtrueにして設定されている)場合は、この表の空白によって、既存の表の空白でない値が置換されます。デフォルトは0(またはfalse)で、このプロパティにはマージ・スコープが指定されています。

- mergeAppendColumns: これは、この表における列のカンマ区切りのリストです。このリストで言及されている任意の値では、その列に対するこの表における列値は、その列に対する既存の表における値を置換しませんが、そのかわり、(区切り文字としてカンマを使用して)現在の値に新しい値を付加するか、または新しい値を現在の値に置換します。カンマ区切りのリストにあるサブ値のそれぞれは、key=value形式で、=value部分は省略可能と想定されています。この表で、カンマ区切りのリストに同じキーがある場合、そのkey=valueのペアは、既存の表における値を置換します。たとえば、既存の表に形式a=1,b=2の列値があり、この表に値b=3,c=4がある場合、マージ後はa=1,b=3,c=4となります。このプロパティにはマージ・スコープが指定されています。

- cssStyleMergeAppendFormat: これはブール型プロパティで、mergeAppendColumnsプロパティに使用されている区切り文字を変更します。通常の場合、mergeAppendColumnsで言及されているフィールドの値は、名前=値のペアのカンマ区切りのリストで、等号演算子(=)は代入演算子です。このプロパティが有効になっている場合は、リストの区切り文字はセミコロン(;)になり、名前と値のペアは代入にコロン(:)を使用します。そのため、フィールド値の形は、A=1,B=2ではなく、A:1;B:2となります。デフォルトはfalseで、このプロパティにはマージ・スコープが指定されています。

- wildcard: 通常の場合、マージが実行されると、マージ・テストで一致比較を行う際に、大文字と小文字が区別されません。このオプションが有効になっている場合は、比較がコンテンツ・サーバーの標準ワイルドカード一致(* = 0個以上の任意の文字、? = 任意の単一文字)です。一般的にこのオプションは、mergeKey以外の列にmergeNewKeyを設定した状態で使用し、多くの場合、mergeKeyは、この表にある有効な列を参照することさえしません。デフォルトは0(またはfalse)で、このプロパティにはマージ・スコープが指定されています。

- mergeOtherData: このリソースにマージするための、他のdynamicdataリソースのカンマ区切りのリスト。他のdynamicdataリソースのそれぞれは、全面的にマージされた後にこのリソースにマージされます(それらの他のリソースでもmergeOtherDataを使用している場合は、それらのマージが最初に行われます。コードには再帰削除があります)。参照されているdynamicdataリソースの1つで、複数のファイルに複数の定義がある場合は、このリソースにマージするために使用されるマージ・キーは、その他のリソースでマージ順序が最も高い(最後にマージされる)と定義されたマージ・キーです。このdynamicdataリソース(mergeOtherDataプロパティのあるリソース)で、複数のファイルに複数の定義がある場合は、マージ・スタックにあるすべてのリソースから参照された名前付きリソースをすべてマージすることによって、mergeOtherDataパラメータが生成されます。デフォルトはNULLで、グローバルなスコープが指定されています。

15.2.2.3.2 アセンブリ・プロパティ

dynamicdataリソースのproperties-of-tableパラメータで、次のアセンブリ・プロパティを1つ以上指定できます。

- notrim: このオプションは、commatable形式にのみ適用されます。通常の場合は、表のリソースに対して解析されるすべての値がトリミングされます。このオプションを設定すると、値はトリミングされません。これはめったに使用されないオプションと推定されます。デフォルトは0(またはfalse)で、このプロパティにはローカルな表スコープが指定されています。

- indexedColumns: このプロパティは、索引付き参照用に最適化する必要のある列をリストしています。Idocスクリプトの特殊関数は、索引付き列のいずれかを利用するために存在しています。索引付き列に対して参照を行うときには、列名と値を指定する必要があります。索引付き列の値と関数に渡された値が(大文字と小文字を区別して)一致した行のみで構成される、フィルタリング済表が返されます。これらの索引付き列の参照がすべて、ロード時およびマージ時に計算され、すぐに取り出せるようにハッシュ表に格納されることに注意してください。すべての重なり合う表の索引付き列の値のリストがまとめてマージされ、索引計算はマージの終了後に行われます。このプロパティにはグローバルな表スコープが指定されています。

- countColumn: この値は、全面的にマージされた表の中で、行数の値が入力される列を指定します。このカウントは1で始まり、表の中の行ごとに増えていきます。マージされた表のその列に値がある場合は、その値がカウント値に置換されます。このプロパティを使用すると、行ごとに迅速な一意のキーを作成できます。このプロパティのデフォルト値はcountなので、countという名前の列があって、別のcountColumnを指定していない表があれば、その列にカウンタ値が自動的に入力されます。このプロパティの値は、最終的にマージされた表の列名と一致していない場合には無視されます。重ね合せる側の表のリソースで、前の表のリソースで指定されたものとは異なるcountColumnが指定されている場合は、重ね合せる側の表のリソースが使用されます。このプロパティにはグローバルな表スコープが指定されています。

- defaultValues: このプロパティは、表に適用するデフォルト値のカンマ区切りのリストを指定します。このリストにあるそれぞれのデフォルト値は、fieldname:valueという形式です。値が空の文字列の場合は、コロンを省略できます。たとえば、文字列field1:val1,field2:val2,field3では、デフォルト値を、field1にはval1、field2にはval2、field3には空の文字列と指定します。コロンは星印(*)で代用でき、星印は、その前にハッシュ(#)を置くことで避けることができます。ハッシュと星印のいずれかがハッシュに続く場合は、ハッシュをもう1つ追加することでハッシュを避けることができます(カンマのエスケープについて、前に説明したルールと同じ)。最終的にマージされた表に、デフォルト値の構成で指定されたフィールドがない場合は、新規のフィールドとして追加され、その表のすべての行のデフォルト値が指定されます。そのフィールドがある場合は、その表でそのフィールドに空白の値があれば、デフォルト値が優先されます。新しい重ね合せる側の表のdefaultValuesの定義が、既存の表の実際の定義と照合されます。あるデフォルト値の定義に競合があった場合は、新しい重ね合せる側の表が優先されます。このプロパティのデフォルトはNULLで、グローバルな表スコープが指定されています。

- derivedColumns: このプロパティは、他の列の値から構築する列を指定します。一般的な構文は、導出された列定義のカンマ区切りのリストで、そのフォームはderivedColumnDef1,derivedColumnDef2,...であり、それぞれの列定義はfieldName:sourceField1+sourceField2+...というフォームです。fieldNameは、作成されるフィールドの名前を指し、sourceFieldNは、導出された列を作成するときのソースとなる値を持つフィールドを指します。導出された列には、二重コロン(::)で区切られたソース・フィールドの値が保持されます。導出された列があり、そこに空でない値が入っている場合は置換されません。defaultValuesプロパティの場合と同様に、最終的な表がアセンブルされた後に2番目のパスがあり、導出された値のいずれかに入力する必要がまだあるかどうかが判別されます。導出された列の最も代表的な使用法としては、マージ基準を指定するために、1つのdynamicdataリソースで、1つの列だけでなく複数の列を使用できるようにすることです。導出された列は、マージのターゲットとして使用され、既存の表の定義で定義されます。導出された列の定義は、新しい重ね合せる側の表に継承されます。また、ある導出された列の定義に競合があった場合は、新しい重ね合せる側の表の定義が優先されます。そうでない場合は、既存の表と新しい表の、導出された列の定義がまとめて照合されます。このプロパティのデフォルト値はNULLで、グローバルな表スコープが指定されています。

15.2.2.3.3 ソート・プロパティ

dynamicdataリソースのproperties-of-tableパラメータで、次のソート・プロパティを1つ以上指定できます。

- sortColumn: ソートする列を選択します。重ね合せる側の表のリソースで、前の表のリソースで指定されたものとは異なるsortColumnが指定されている場合は、重ね合せる側の表のリソースが使用されます。この列の名前が、最終的にマージされた表の列名と一致していない場合には、ソートは実行されません。デフォルト値はsortOrderです。そのため、この名前の列を作成すると、表が自動的にソートされます。このプロパティにはグローバルな表スコープが指定されています。

- sortType: ソートされる列をどのデータ型と想定するかを指定します。この型は、sortColumnとsortParentColumnの両方に適用されます。この値は、int、stringまたはdateです。このプロパティのデフォルト値はintです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。

- sortOrder: ソートを実行するときに使用するソート順序を指定します。使用可能な値は、asc(昇順の場合)とdesc(降順の場合)です。デフォルトはascです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。

- sortIsTree: ソートが実際に、sortChildColumnとともにsortParentColumnがソートされたツリー・ソートであるかどうかを指定します。その場合は、sortParentColumnにおける子の行の値を使用して、そのsortChildColumnフィールドで値が一致している親の行を見つけることによって、子から親への行マッピング関係が行われると想定されています。最上位レベルの親が最初にソートされ、次に、それぞれの親の子がそれぞれの親のサブグループとしてソートされ、さらに子のすべての子が再帰的にソートされるというようにソートが実行されます。デフォルト値は0(またはfalse)です。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルな表スコープが指定されています。

- sortParentColumn: この値は、sortIsTreeオプションが有効になっている場合に指定する必要があります。このプロパティの値が欠落しているか、または無効な列を指定している場合、sortIsTreeオプションは無視され、効果はありません。その内容の詳細は、sortIsTreeプロパティの前述の説明を参照してください。sortParentColumnプロパティのデフォルトはNULLです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルなスコープが指定されています。

- sortChildColumn: この値は、sortIsTreeオプションが有効になっている場合に指定する必要があります。このプロパティの値が欠落しているか、または無効な列を指定している場合、sortIsTreeオプションは無視され、効果はありません。その内容の詳細は、sortIsTreeプロパティの前述の説明を参照してください。sortChildColumnプロパティのデフォルトはNULLです。このプロパティを指定する両方の、重ね合せる側の表のルールは、sortColumnと同一です。このプロパティにはグローバルなスコープが指定されています。

- sortNestLevelColumn: この値は、sortIsTreeオプションが有効になっている場合にのみ使用できます。このプロパティの値は、無効な列を参照している場合には効果がありません。有効な列が指定されている場合、その列は、そのネスト・レベル(最初の値は0)を指定する整数値を取得します。ネスト・レベルは、自身に親のない親に到達するまでに横断する必要のある、直接の親の数として定義されます。このプロパティのデフォルト値はnestLevelで、グローバルなスコープが指定されています。

15.2.2.3.4 フィルタおよびインクルードのプロパティ

dynamicdataリソースのproperties-of-tableパラメータで、次のフィルタおよびインクルードのプロパティを1つ以上指定できます。

- filterInclude: このプロパティは、表(索引付きの列が副表の選択に使用されている場合は副表)の各行に実行するインクルードを指定します。これは、現在のユーザーのコンテキストに表がロードされたときに実行されます。その主な目的は、副作用を生みだすこと、または行を除外する必要があるかどうかを判別することです。最終的な結果セットに行がロードされないようにするために、変数ddSkipRowを1(<$ddSkipRow=1$>)に設定できます。このインクルードの実行時に表はアクティブにされ、表の値へのアクセスと値の置換を簡単にできます。このプロパティのデフォルト値はnullで、グローバルなスコープが指定されています。

- includeColumns: このプロパティは、実行するリソース・インクルードの名前が行の値になっている列のカンマ区切りのリストを指定します。リソース・インクルードが実行された後で、結果が結果セットにフィードバックされ、その行のその列の新しい値となります。実行のタイミングおよびルールはfilterIncludeと同じですが、includeColumnsでは、行をロードすることを抑制できません。フィルタ・インクルードが指定され、アクティブなインクルード列がある場合は、一時的にアクティブな結果セットをループ処理する際に、インクルード列の値が最初に実行され、次にフィルタ・インクルードが実行されます。最終的にマージされた表に、指定されたインクルード列のいずれかがない場合は、効果はありません。インクルード列にある空の値は無視されます。includeColumns属性は、一般的にはdefaultValues属性と結合され、他の列から値が導出される列が作成されます。このプロパティのデフォルト値はnullで、グローバルなスコープが指定されています。

注意:
includeColumnsは、最初に表示されたときほどには役に立たないことがあります。リソース・インクルードが実行されるのは、表をロードするためにIdocスクリプトの関数が実行されたときですが、出力をカスタマイズするコンポーネントによって列の値が決定されるのが、さらに処理を行った後(この表に他の表がマージされたり、行統計のサマリーが計算されたりなどした後)に限定される場合もあります。

15.2.2.4 Dynamicdata Idocスクリプト関数の使用

動的データ表の場合は、次のdynamicdata Idocスクリプト関数を使用できます。

- ddAppendIndexedColumnResultSet

- ddAppendResultSet

- ddApplyTableSortToResultSet

- ddGetFieldList

- ddIncludePreserveValues

- ddLoadIndexedColumnResultSet

- ddLoadResultSet

- ddMergeIndexedColumnResultSet

- ddMergeResultSet

- ddMergeUsingIndexedKey

- ddSetLocal

- ddSetLocalByColumnsFromFirstRow

- ddSetLocalByColumnsFromFirstRowIndexed

- ddSetLocalEmpty

- ddSetLocalEmptyByColumns

15.2.3 文字列リソース

stringリソースは、エラー・メッセージおよびコンテンツ・サーバーWebページとアプレットで使用される、ロケールに依存するテキスト文字列を定義します。Webページがアセンブルされるか、アプレットが開始されるか、またはエラー・メッセージが表示されるたびに、文字列がコンテンツ・サーバーによって解決されます。

stringは、次の形式を使用して、HTMファイルで定義されます。

<@stringID=Text string@>

stringは、次のIdocスクリプト関数を使用して、HTMテンプレートから呼び出されます。

<$lc("wwStringID")$>

注意:
コンテンツ・サーバーWebページでは、ww_strings.htmファイルには文字列のみを使用してください。

標準的な英語文字列は、IdcHomeDir/resources/core/langディレクトリで定義されます。他にサポートされている言語の文字列は、ローカライゼーション・コンポーネントによって提供されます。

HTMLインクルード、文字列および静的表は、同じHTMファイルにあってもかまいません。stringリソースには、マージ・ルールは不要です。

string値に次の特殊文字を含めるには、HTMLエスケープ・エンコーディングを使用する必要があります。

エスケープ・シーケンス

文字

&at;

@

\&lf;

行送り(ASCII 10)

\&cr;

改行(ASCII 13)

\&tab;

タブ(ASCII 9)

\&eatws;

次の空白以外の文字まで空白を食いつぶします。

\&lt;

<(より小さい)

\&gt;

>(より大きい)

\&sp;

空白(ASCII 32)

\&#xxx;

10進数で表すASCII文字(nnn)

すべての言語にシングルバイト文字がある場合、またはマルチバイト文字がある場合は、言語識別子接頭辞を使用して、同じリソース・ファイルで複数の言語の文字列を指定できます。例15-8は、リソース・ファイルにおける、複数の言語による文字列の接頭辞を示しています。

例15-8 同じリソース・ファイルにおける複数の言語

<@myString=Thank you@>
<@es.myString=Gracias@>
<@fr.myString=Merci@>
<@de.myString=Danke@>

注意:
シングルバイト文字列とマルチバイト文字列は、同じリソース・ファイルで指定しないでください。シングルバイト文字列用とマルチバイト文字列用に、別々のリソース・ファイルを作成してください。

カスタム文字列リソースでマルチバイト文字列を指定する場合は、HTMLページでのキャラクタ・セット指定が、適切なエンコーディングに変更されるようにしてください。リソース・ファイルには正しいhttp-equiv charsetタグを指定して、コンテンツ・サーバーが正しく読み取るようにしてください。

15.2.3.1 文字列パラメータ

テキスト文字列には変数パラメータを含めることができ、そのパラメータは、中カッコ内にパラメータ引数を配置(たとえば、{1})することによって指定されます。文字列がローカライズされると、この引数は、文字列ID、およびロケール情報を含むExecutionContext値とともに渡されます。パラメータ化された文字列の構文は次の表のとおりです。

構文

意味

例

{{}

開始側の中カッコ。(リテラルとして表現する必要があるのは、開始側の中カッコのみです。)

{{}中カッコ内のテキスト}

{n}

n番目の引数を代入します。

コンテンツID {1}が見つかりません

{ni}

n番目の引数を整数形式で代入します。

dID {1i}は存在しません

{nx}

n番目の引数を16進数の整数形式で代入します。

{nd}

n番目の引数を日付形式で代入します。

リリース日は{1d}です

{nD}

n番目の引数を日付形式で代入します。引数はODBC形式にする必要があります。

リリース日は{1D}です

{nt}

n番目の引数を日時形式で代入します。

リリース日は{1t}です

{ne}

n番目の引数を経過時間形式で代入します。

{nT}

n番目の引数を日時形式で代入します。引数はODBC形式にする必要があります。

リリース日は{1T}です

{nfm}

n番目の引数を浮動小数点形式で代入します。

距離は{1f3}マイルです。

{nk}

n番目の引数を使用してローカライズした文字列を文字列IDとして代入します。

{2}の{1k}リビジョンが見つかりません

{nm}

n番目の引数を、文字列スタック・メッセージであるかのようにローカライズします。(たとえば、引数には、連結されたテキスト文字列およびローカライズされた文字列IDを含めることができます。)

索引付けの内部エラー: {1m}

{nl}

n番目の引数をリストとして代入します。数は、カンマ(,)およびカレット(^)を区切り文字とするリストである必要があります。

アドオン: {1l}

{nK}

カンマで区切られたローカライゼーション・キー名のリストを利用し、各キーをリストにローカライズします。

サポートされていないバイト機能: {1K}

{nM}

メッセージ文字列のリストを利用し、各メッセージをリストにローカライズします。

{1q}コンポーネント、バージョン{2q}は、現在有効になっているバージョンより古いバージョンの機能を提供します。{3M}

{nq}

n番目の引数がNULLでなく、長さがゼロでない場合は、引用符で引数を代入します。それ以外の場合は、文字列syUndefinedを代入します。

コンテンツ・アイテム{1q}を正常にチェックインできませんでした。

{no}

n番目の引数に対して、順序を示す代入を実行します。たとえば、1st、2nd、3rdなどです。引数は整数である必要があります。

"I am {1o}."で引数を7とすると、"I am 7th."にローカライズされます。

{n?text}

n番目の引数の値が1でない場合は、テキストを代入します。

{1}ファイル{1?s}が削除されました

{n?text1:text2}

- n番目の引数の値が1でない場合は、text1を代入します。

- n番目の引数の値が1の場合は、text2を代入します。

必要なだけの数の置換変数を使用して(n?)関数を拡張できます。リスト内の最後の変数は常に、値1に対応します。

There {1?are:is} currently {1} active search{1?es}.

{n?text1:text2:text3}

- n番目の引数の値が1でも2でもない場合は、text1を代入します。

- n番目の引数の値が2の場合は、text2を代入します。

- n番目の引数の値が1の場合は、text3を代入します。

必要なだけの数の置換変数を使用して(n?)関数を拡張できます。リスト内の最後の変数は常に、値1に対応します。

Contact {1?their:her:his} supervisor.

15.2.3.2 文字列リソースの編集

コンポーネント・ウィザードを使用して既存の文字列リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. リソース・ファイルに複数のタイプのリソースが含まれている場合は、右側の「文字列」タブをクリックします。

4. 「カスタム・文字列」リストで文字列を変更します。

- 既存の文字列を編集するには、文字列を選択して「編集」をクリックし、文字列テキストを変更して「OK」をクリックします。

- リソース・ファイルに文字列を追加するには、「追加」をクリックします。

- 文字列を削除するには、文字列を選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.4 動的表

動的表のリソースは、HDAファイル形式で定義されます。HDA ResultSet表の詳細と例は、第9.1.3.1.1項「HDAファイル内の要素」を参照してください。

15.2.4.1 動的表のマージ・ルール

カスタム・リソースのデータによって既存の表のデータが置換される場合は、動的表にマージ・ルールが必要です。カスタム・リソースのデータが新規の表に配置される場合は、動的表にマージ・ルールは不要です。

15.2.4.2 動的表リソースの編集

コンポーネント・ウィザードを使用して既存の動的表リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソース・ファイルを選択します。

3. 「エディタの起動」をクリックします。

4. テキスト・エディタで表を変更します。

5. リソース・ファイルを保存して閉じます。
変更内容は、「リソースの定義」タブの右側に反映されます。

15.2.5 静的表

静的表、HTMLインクルードおよび文字列は、同じHTMファイルにあってもかまいません。

15.2.5.1 静的表のマージ・ルール

カスタム・リソースのデータによって既存の表のデータが置換される場合は、静的表にマージ・ルールが必要です。カスタム・リソースのデータが新規の表に配置される場合は、動的表にマージ・ルールは不要です。

15.2.5.2 静的表リソースの編集

コンポーネント・ウィザードで既存の静的表リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソース・ファイルを選択します。

3. 「エディタの起動」をクリックします。

4. テキスト・エディタで表を変更します。

5. リソース・ファイルを保存して閉じます。変更内容は、「リソース表」リストに反映されます。

15.2.6 問合せ

問合せリソースは、コンテンツ・サーバーのデータベース内の情報を管理するために使用されるSQL問合せを定義します。問合せをサービス・スクリプトで使用して、データベースに対するデータの追加、削除、取得などのタスクを実行します。

コンテンツ・サーバーの標準的な問合せは、IdcHomeDir/resources/core/tables/query.htmファイルのQueryTable表に定義されています。特殊目的の問合せは、IdcHomeDir/resources/core/tablesディレクトリに格納されているindexer.htmファイルとworkflow.htmファイルにもあります。問合せリソースにマージ・ルールは不要です。

問合せリソースは、name、queryStr、parametersの3つの列があるResultSet表を使用したHTMファイルで定義されます。

- name列では、各問合せの名前を定義しています。既存の問合せをオーバーライドするには、同じ名前をカスタム問い合わせに使用します。新規の問合せを追加するには、一意の問合せ名を使用します。新規の問い合わせに名前を付けるときには、次の文字のいずれかを名前の先頭に付けて、問合せのタイプを特定します。

先頭文字

問合せのタイプ

D

削除

I

挿入

Q

選択

U

更新

- queryStr列では、問合せ式を定義しています。問合せ式は、SQLの標準構文にします。データベースに渡すパラメータ値がある場合、その場所は、疑問符(?)をエスケープ文字として固定されます。

- parameters列では、サービスから問合せに渡されるパラメータを定義しています。Webブラウザからのリクエストによってサービスが呼び出され、さらにそこから問合せが呼び出されます。HTTPの標準パラメータである問合せパラメータに値を提供するのは、Webブラウザの役割です。ブラウザは、URLから、またはWebページ内のFORM要素から、問合せパラメータを渡すことができます。たとえば、QdocInfo問合せでは、パラメータとしてdID(リビジョンID)を渡す必要があるため、この値は、サービス・リクエストのURLから取得されます。

15.2.6.1 問合せの例

図15-1に示している標準的なQdocInfo問合せは、IntradocDir/core/config/resources/query.htmファイルで定義されています。この問合せでは、DOC_INFOテンプレート・ページに表示するメタデータ情報が取得されます。このテンプレート・ページは、検索結果ページでユーザーが「情報」アイコンをクリックしたときに表示されるページです。

図15-1 標準的なQDocInfo問合せ

WebブラウザのURLから渡されるパラメータはdIDであり、これは、コンテンツ・アイテム・リビジョンの一意のID番号です。リビジョンにDELETEDステータスがない場合、問合せ式では、「リビジョン」、ドキュメント、DocMetaの各データベース表から、プライマリ・リビジョンのdIDと一致するデータを選択します。

例15-9に、query.htmファイルの内容を示します。

例15-9 query.htmファイル

<HTML>
<HEAD>
<META HTTP-EQUIV='Content-Type' content='text/html; charset=iso-8859-1'>
<TITLE>Query Definition Resources</TITLE>
</HEAD>
<BODY>
<@table QueryTable@>
<table border=1><caption><strong>Query Definition Table</strong></caption>
<tr>
<td>name</td>
<td>queryStr</td>
<td>parameters</td>
</tr>
<tr>
<td>QdocInfo</td>
<td>SELECT Revisions.*, Documents.*, DocMeta.*
FROM Revisions, Documents, DocMeta
WHERE Revisions.dID=? AND Revisions.dID=Documents.dID AND DocMeta.dID = Documents.dID AND Revisions.dStatus<>'DELETED' AND Documents.dIsPrimary<>0</td>
<td>dID int</td>
</tr>
</table>
<@end@>
</BODY>
</HTML>

15.2.6.2 問合せリソースの編集

コンポーネント・ウィザードを使用して問合せリソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. リソースに複数の表がある場合は、編集する問合せ表を「表名」リストから選択します。

4. 選択した問合せ表を変更します。

- 表に問合せを追加するには、「追加」をクリックします。

- 既存の問合せを編集するには、問合せを選択して「編集」をクリックし、問合せ式またはパラメータ、あるいはその両方を変更して「OK」をクリックします。

- 問合せを削除するには、問合せを選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.7 サービス

サービス・リソースは、コンテンツ・サーバーで実行される関数またはプロシージャを定義します。クライアントとサーバーどちらの側からもサービス・コールを実行できるため、Webブラウザのクライアントの代理としても、システム自体の内部でもサービスを実行できます。次に例を示します。

- クライアント側のリクエスト: コンテンツ・サーバーのWebページで「検索」リンクをクリックすると、GET_DOC_PAGEサービスによってWebブラウザに標準的な検索ページが表示されます。このとき、次のURLセグメントが使用されます。

IdcService=GET_DOC_PAGE&Action=GetTemplatePage&Page=STANDARD_QUERY_PAGE

- サーバー側のリクエスト: START_SEARCH_INDEXサービスを使用すると、バックグラウンド・スレッドで自動的に、検索索引が更新または再構築されます。

サービスは、クライアントがサーバーと対話したりデータベースにアクセスすることのできる唯一の手段です。いずれのプログラムでもHTMLページでも、コンテンツ・サーバーに情報を要求するサービス、または指定された機能を実行するサービスを実行できます。

コンテンツ・サーバーの標準的なサービスは、IdcHomeDir/resources/core/tables/std_services.htmファイルのStandardServices表に定義されています。特殊目的のサービスは、IdcHomeDir/resources/core/tablesディレクトリに格納されているworkflow.htmファイルにもあります。コンテンツ・サーバーが提供する標準サービスと特殊目的のサービスの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

サービスが機能を実行する際には、他のリソース定義に左右されます。HTMLを返すサービスでは、テンプレートを指定する必要があります。広く知られている例外はPING_SERVERサービスであり、このサービスはブラウザにページを返しません。

ほとんどのサービスでは問合せを使用します。広く知られている例外はSEARCHサービスであり、このサービスは検索コレクションにリクエストを直接送信します。サービス・リソースにマージ・ルールは不要です。

図15-2に、サービス定義の例を示します。

図15-2 サービス定義の例

サービス・リソースは、次の3つの列があるResultSet表を使用したHTMファイルで定義されます。

- Name列では、各サービスの名前を定義しています。クライアント側のリクエストでは、これはURLの中で呼び出される名前です。既存のサービスをオーバーライドするには、同じ名前をカスタム・サービスに使用します。新規のサービスを追加するには、一意のサービス名を使用します。

- Attributes列では、各サービスの次の属性を定義しています。

属性

説明

例(DELETE_DOCサービスの属性)

サービス・クラス

サービスで実行できるアクションの一部を決定します。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

アクセス・レベル

サービスにユーザー・アクセス・レベルを割り当てます。この数値は、使用可能な次のビット・フラグの合計です。
READ_PRIVILEGE = 1

WRITE_PRIVILEGE = 2

DELETE_PRIVILEGE = 4

ADMIN_PRIVILEGE = 8

GLOBAL_PRIVILEGE = 16

SCRIPTABLE_SERVICE=32

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

テンプレート・ページ

サービスの結果を表示するテンプレートを指定します。サービスの結果にページ表示が必要ない場合は、この属性はnullにします。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

サービス・タイプ

サービスを別のサービスの内側で実行する場合は、この属性はSubServiceにします。それ以外の場合はnullにします。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

通知された件名

サービスによって通知される件名(サブシステム)を指定します。件名が通知されない場合は、この属性はnullにします。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

エラー・メッセージ

アクション・エラー・メッセージによってオーバーライドされない場合、サービスによって返されるエラー・メッセージを定義します。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

- Actions列では、各サービスのアクションを定義しています。アクションとは、サービス・スクリプトの一部として実行される操作です。アクションは、SQL文の実行、問合せの実行、コードの実行、問合せの結果のキャッシュまたはオプション・リストのロードを行うことができます。各サービスにはアクションが1つ以上含まれていて、実行時に何が起こるかを指定します。

Actions列の<br>タグは、ブラウザ表示のみを目的としたものなので、省略可能です。ただし、</td>タグは、アクションの直後に置くもので、その間に改行を入れてはなりません。アクションは、次の形式を使用して定義されます。

type:name:parameters:control mask:error message

セクション

説明

例(DELETE_DOCサービスの最初のアクション)

type

アクションのタイプを定義します。
QUERY_TYPE = 1

EXECUTE_TYPE = 2

CODE_TYPE = 3

OPTION_TYPE = 4

CACHE_RESULT_TYPE = 5

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

name

アクションの名前を指定します。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist

parameters

アクションに必須のパラメータを指定します。必須のパラメータがない場合は、この部分を空白にしておきます(1つの行の中の2つの列)。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist

control mask

データベースへの問合せ結果を制御します。この数値は、使用可能な次のビット・フラグの合計です。
制御マスクなし= 0

CONTROL_IGNORE_ERROR = 1

CONTROL_MUST_EXIST = 2

CONTROL_BEGIN_TRAN = 4

CONTROL_COMMIT_TRAN = 8

CONTROL_MUST_NOT_EXIST = 16

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist

Error message

このアクションで表示するエラー・メッセージを定義します。このエラー・メッセージは、サービスの属性として用意されているエラー・メッセージをオーバーライドします。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExist

15.2.7.1 サービスの例

DOC_INFOサービスでは、サービス、問合せおよびテンプレートがまとまってどのように機能しているかの好例が提供されています。図15-3は、DOC_INFOサービスで実行できるアクションを示しています。

図15-3 DOC_INFOサービス

例15-10は、IntradocDir/config/resources/std_services.htmファイル内のDOC_INFOサービスの定義を示しています。

例15-10 std_services.htmファイル内のDOC_INFOサービス定義

<HTML>
<HEAD>
<META HTTP-EQUIV='Content-Type' content='text/html; charset=iso-8859-1'>
<TITLE>Standard Scripted Services</TITLE>
</HEAD>
<BODY>
<@table StandardServices@>
<table border=1><caption><strong>Scripts For Standard Services</strong></caption>
<tr>
<td>Name</td><td>Attributes</td><td>Actions</td>
</tr>
<tr>
<td>DOC_INFO</td>
<td>DocSgervice
33
DOC_INFO
null
null<br>
!csUnableToGetRevInfo</td>
<td>5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2
3:mapNamedResultSetValues:DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null
3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)
3:getDocFormats:QdocFormats:0:null
3:getURLAbsolute::0:null
3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null
3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null
3:getWorkflowInfo:WF_INFO:0:null
3:getDocSubscriptionInfo:QisSubscribed:0:null
5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)</td>
</tr>
</table>
<@end@>
</BODY>
</HTML>

15.2.7.1.1 属性

次の表では、前述のDOC_INFOサービスの属性について説明します。

属性

値

説明

Service class

DocService

このサービスは、コンテンツ・アイテムに関する情報を提供しています。

アクセス・レベル

33

32 =このサービスは、IdocスクリプトのexecuteService関数で実行できます。
1 = サービスをリクエストするユーザーには、コンテンツ・アイテムに対するRead権限が必要です。

テンプレート・ページ

DOC_INFO

このサービスでは、DOC_INFOテンプレート(doc_info.htm ファイル)を使用しています。アクションの結果がこのテンプレートにマージされて、ユーザーの画面に表示されます。

サービス・タイプ

null

このサービスは、サブサービスではありません。

通知された件名

null

このサービスの影響を受ける件名はありません。

エラー・メッセージ

!csUnableToGetRevInfo

このサービスが英語コンテンツ・サーバー・システムで失敗した場合は、「リビジョンに関する情報を取得できません。」というエラー・メッセージ文字列が返されます。

15.2.7.1.2 アクション

DOC_INFOサービスでは、次のアクションを実行します。

- 5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2

アクション定義

説明

5

問合せを使用してデータベースから情報を取得する、キャッシュされた問合せアクション。

QDocInfo

このアクションでは、query.htmファイル内のQDocInfo問合せを使用して、コンテンツ・アイテム情報を取得します。

DOC_INFO

この問合せの結果がパラメータDOC_INFOに割り当てられ、後で使用できるように格納されます。

2

CONTROL_MUST_EXIST制御マスクによって、問合せがレコードを返す必要があるのか、アクションが失敗するのかが指定されます。

!csItemNoLongerExists2

このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、「該当コンテンツ・アイテムはもはや存在しません。」というエラー・メッセージ文字列が返されます。

- 3:mapNamedResultSetValues:DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

mapNamedResultSetValues

このアクションでは、DOC_INFO ResultSetの最初の行からdStatusおよびdDocTitleの値を取得して、ローカル・データに格納します。(これによってスピードが上がり、正しい値が使用されるようになります。)

DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle

mapNamedResultSetValuesアクションに必須のパラメータ。

0

制御マスクが指定されていません。

null

エラー・メッセージが指定されていません。

- 3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

checkSecurity

このアクションでは、DOC_INFOパラメータに割り当てられているデータを取得し、割り当てられているセキュリティ・レベルを評価して、ユーザーがこのアクションを実行する権限があることを確認します。

DOC_INFO

checkSecurityアクションによって評価されるセキュリティ情報を含むパラメータ。

0

制御マスクが指定されていません。

!csUnableToGetRevInfo2(dDocName)

このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、「''{dDocName}"に対する情報を取得できません。」というエラー・メッセージ文字列が返されます。

- 3:getDocFormats:QdocFormats:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getDocFormats

このアクションでは、query.htmファイル内のQdocFormats問合せを使用して、コンテンツ・アイテムのファイル形式を取得します。ファイル形式のカンマ区切りのリストが、dDocFormatsとしてローカル・データに格納されます。

QdocFormats

ファイル形式の取得に使用される問合せを指定します。

0

制御マスクが指定されていません。

null

エラー・メッセージが指定されていません。

- 3:getURLAbsolute::0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getURLAbsolute

このアクションでは、コンテンツ・アイテムのURLを解決し、DocUrlとしてローカル・データに格納します。

空白

このアクションではパラメータを利用しません。

0

制御マスクが指定されていません。

NULL

エラー・メッセージが指定されていません。

- 3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getUserMailAddress

このアクションでは、コンテンツ・アイテムの作者の電子メール・アドレスを解決します。

dDocAuthor,AuthorAddress

このアクションでは、パラメータとしてdDocAuthorとAuthorAddressを渡します。

0

制御マスクが指定されていません。

NULL

エラー・メッセージが指定されていません。

- 3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getUserMailAddress

このアクションでは、コンテンツ・アイテムがチェックアウトされているユーザーの電子メール・アドレスを解決します。

dCheckoutUser,CheckoutUserAddress

このアクションでは、パラメータとしてdCheckoutUserとCheckoutUserAddressを渡します。

0

制御マスクが指定されていません。

NULL

エラー・メッセージが指定されていません。

- 3:getWorkflowInfo:WF_INFO:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getWorkflowInfo

このアクションでは、コンテンツ・アイテムがワークフローの一部かどうかを評価します。WF_INFO ResultSetが存在している場合は、ワークフロー情報がDOC_INFOテンプレートにマージされます。

WF_INFO

このアクションでは、パラメータとしてWF_INFOを渡します。

0

制御マスクが指定されていません。

NULL

エラー・メッセージが指定されていません。

- 3:getDocSubscriptionInfo:QisSubscribed:0:null

アクション定義

説明

3

サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

getDocSubscriptionInfo

このアクションでは、現在のユーザーがコンテンツ・アイテムをサブスクライブしているかどうかを評価します。

- ユーザーがサブスクライブしている場合は、「サブスクライブ解除」ボタンが表示されます。

- ユーザーがサブスクライブしていない場合は、「サブスクライブ」ボタンが表示されます。

QisSubscribed

サブスクリプション情報の取得に使用される問合せを指定します。

0

制御マスクが指定されていません。

NULL

エラー・メッセージが指定されていません。

- 5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)

アクション定義

説明

5

問合せを使用してデータベースから情報を取得する、キャッシュされた問合せアクション。

QrevHistory

このアクションでは、query.htmファイル内のQrevHistory問合せを使用して、リビジョン履歴情報を取得します。

REVISION_HISTORY

この問合せの結果がパラメータREVISION_HISTORYに割り当てられます。DOC_INFOテンプレートでは、このパラメータをループで使用し、各リビジョンに関する情報を表示します。

0

制御マスクが指定されていません。

!csUnableToGetRevHistory(dDocName)

このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。
''{dDocName}''に対するリビジョン履歴を取得できません。

15.2.7.2 サービス・リソースの編集

コンポーネント・ウィザードを使用してサービス・リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. リソースに複数の表がある場合は、編集するサービス表を「表名」リストから選択します。

4. 選択したサービス表を変更します。

- 表にサービスを追加するには、「追加」をクリックします。

- 既存のサービスを編集するには、サービスを選択して「編集」をクリックし、サービス属性またはアクション、あるいはその両方を変更して「OK」をクリックします。

- サービスを削除するには、サービスを選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.8 テンプレート

テンプレート・リソースは、コンポーネント用にロードされるカスタム・テンプレートの名前、タイプおよび場所を定義します。

実際のテンプレート・ページは、テンプレート・リソース・ファイルで参照される別々の.htmファイルです。テンプレートHTMファイルには、Webページをアセンブルするためにコンテンツ・サーバーが使用するコードが含まれています。テンプレート・ファイル内のHTMLマークアップでは、ページの基本レイアウトが定義され、テンプレート・ファイル内のIdocスクリプトでは、ページのリクエスト時にWebページの追加のHTMLコードが生成されます。HTMテンプレート・ファイルには、最終ページがアセンブルされるまでコンテンツ・サーバーによって解決されないスクリプトが大量に含まれているため、これらのファイルは表示できないWebページです。

HTMファイルのテンプレート・タイプは、次のコンポーネント・ファイルの定義に使用されます。

- テンプレート・ページ:標準的なテンプレート・ページは、IdcHomeDir/resources/core/templatesディレクトリの中にあります。

- レポート・ページ:標準的なレポート・ページは、IdcHomeDir/resources/core/reportsディレクトリの中にあります。

テンプレート・リソース(templates.hda)は、HDAファイル形式で定義されます。標準的なテンプレートは、IdcHomeDir/resources/core/templates/templates.hdaファイルで定義されます。HDA ResultSet表の詳細と例は、第9.1.3.1.1項「HDAファイル内の要素」を参照してください。

IntradocTemplates表またはSearchResultTemplates表に新規のテンプレート定義をマージする際には、マージ・ルールが必要です。通常、マージはname列にあります。例15-11に、テンプレートのMergeRules ResultSetを示します。

例15-11 MergeRules ResultSet

@ResultSet MergeRules
4
fromTable
toTable
column
loadOrder
MultiCheckinTemplates
IntradocTemplates
name
1
@end

標準的なtemplates.hdaファイルでは、次の3つのResultSet表を定義しています。

- IntradocTemplates ResultSet表では、コンテンツ・サーバーのすべてのWebページ(検索結果ページは除く)のテンプレート・ページを定義しています。この表は、次の5つの列で構成されています。

- name列では、各テンプレート・ページの名前を定義しています。コンテンツ・サーバーCGI URLおよびコード内では、この名前を使用してテンプレートが参照されます。

- class列では、テンプレートの一般カテゴリを定義しています。最も一般的なclassタイプはDocumentです。

- formtype列では、ページで実現しようとする特定のタイプの機能を定義しています。formtypeは通常、フォームの名前と同じですが、小文字であることが異なります。

- filename列では、テンプレート・ファイルのパスとファイル名を定義しています。この場所は、絶対パスで指定できます。また、テンプレート・ページとテンプレート・リソース・ファイルが同じディレクトリの中にある場合には、テンプレート・リソース・ファイルを基準とした相対パスで指定することもできます。

- description列では、テンプレートの説明を定義しています。

- VerifyTemplates ResultSet表は、コンテンツ・サーバーで使用されなくなりましたが、この表は、下位互換性を維持するために、レガシー・コードとしてtemplates.hdaファイルに残っています。

- SearchResultTemplates表では、検索結果ページのテンプレート・ページを定義しています。テンプレート・ページでは、ライブラリの検索結果ページに問合せ結果がどのように表示されるかを定義しています。問合せ結果ページは、特殊なタイプの検索結果ページです。この表は、次の6つの列で構成されています。

- name列では、各テンプレート・ページの名前を定義しています。コンテンツ・サーバーCGI URL、コードおよびWebレイアウト・エディタ・ユーティリティ内では、この名前を使用してテンプレートが参照されます。

注意:
StandardResultsテンプレート(search_results.htmファイル)は通常、ライブラリの標準的な検索結果ページおよび問合せ結果ページのグローバル・テンプレートとして使用されます。テンプレートを新規作成するか、またはWebレイアウト・エディタを使用してStandardResultsテンプレートのflexdataを変更できます。ただし、それらの変更は、templates.hdaファイルのSearchResultTemplates表でなく、別のファイル(IntradocDir/data/results/custom_results.hda)に保存されます。

- formtype列では、ページで実現しようとする特定のタイプの機能を定義しています。ResultsPageは、検索結果ページに対して現在サポートされている唯一のフォーム・タイプです。

- filename列では、テンプレート・ファイルのパスとファイル名を定義しています。この場所は、絶対パスで指定できます。また、テンプレート・ページとテンプレート・リソース・ファイルが同じディレクトリの中にある場合には、テンプレート・リソース・ファイルを基準とした相対パスで指定することもできます。

- outfilename列は将来使用するためのもので、値は常にNULLです。

- flexdata列では、検索結果ページの各行に表示するメタデータを定義しています。flexdata列のテキストの形式は次のとおりです。

Text1 "text 1 contents"%<Tab>Text2 "text 2 contents"%

この形式では、各検索結果行の最初の行にはText1値が表示され、2番目の行にはText2値が表示されます。<Tab>は、リテラル・タブ文字を表しています。

flexdataフィールドの内容を定義する際には、Idocスクリプトを使用できます。Webレイアウト・エディタを使用してStandardResultsテンプレートのflexdataを変更することもできます。ただし、それらの変更は、templates.hdaファイルのSearchResultTemplates表でなく、別のファイル(IntradocDir/data/results/custom_results.hda)に保存されます。

- description列では、テンプレートの説明を定義しています。

カスタム・コンテンツ管理ページ(multicheckin_doc_man.htm)およびカスタム検索結果ページ(MultiCheckin_search_results.htm)を指すカスタム・テンプレート・リソース・ファイルを、例15-12に示します。

例15-12 カスタム・テンプレート・リソース・ファイル

<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet MultiCheckinTemplates
5
name
class
formtype
filename
description
DOC_MANAGEMENT_LINKS
DocManagement
DocManagementLinks
multicheckin_doc_man.htm
Page containing links to various document management functions
@end
@ResultSet MultiCheckin_2
6
name
formtype
filename
outfilename
flexdata
description
StandardResults
SearchResultsPage
MultiCheckin_search_results.htm
null
Text2 <$dDocTitle$> <$dInDate$>%       Text1 <$dDocName$>%
apStandardResultsDesc
@end

15.2.8.1 テンプレート・ページとレポート・ページ

テンプレート・ページとレポート・ページは、プレゼンテーション・ページとも呼ばれます。コンテンツ・サーバーでは、これらのページが、Webページ・リクエストの結果をアセンブル、書式設定および提示するために使用されるからです。

標準的なテンプレート・ページは、IdcHomeDir/resources/core/templatesディレクトリの中にあります。標準的なレポート・ページは、IdcHomeDir/resource/core/reportsディレクトリの中にあります。

15.2.8.1.1 テンプレート・ページの例

標準「コンテンツ管理」ページのテンプレート・ファイルはdoc_man.htmです。例15-13に、このファイルの内容を示します。

例15-13 doc_man.htmファイル

<$include std_doctype_html_decl$>

<head>
<$defaultPageTitle=lc("wwContentMgmt")$>
<$include std_html_head_declarations$>
</head>

<$include body_def$>

<$include std_page_begin$>

<$include std_header$>

<table border="0" cellpadding="2" cellspacing="2" width="450" summary="">

<$include std_doc_man_pages$>

</table>

<table  cellpadding="7" cellspacing="7" summary="">
<$if showQuickHelp$>
<tr><td><form><INPUT type=Button onClick="QuickHelp('<$getHelpPage("QH_DocMan")$>', 'QH_DocMan')"
value="<$lc("wwQuickHelp")$>"></form></td></tr>
<$endif$>
</table>

<$include std_page_end$>

</body>
</html>

この例では、std_doctype_html_declインクルードは、コンテンツ・サーバーの標準的なドキュメント・タイプを参照しています。<head>要素はページ・タイトルを参照し、headセクションのコードは、std_page.htmリソース・ファイル内のstd_html_head_declarationsインクルード・コードを使用して構築されます。ページ定義におけるその他の要素は次のとおりです。

1. コンテンツ・サーバーのほとんどのWebページに共通するページ要素は、std_page.htmリソース・ファイル内のインクルード・コードであるbody_def、std_page_beginおよびstd_headerを使用して構築されます。

2. 「コンテンツ管理」ページ上のリンクは、std_page.htmリソース・ファイル内のインクルード・コードを使用して構築されます。

3. 例にある<table>要素では、「コンテンツ管理」ページに「クイック・ヘルプ」ボタンを表示するかどうかを定義しています。

4. ページの末尾のコードは、std_page.htmリソース・ファイル内のstd_page_endインクルード・コードを使用して構築されます。

図15-4は、「コンテンツ管理」ページを示しています。

図15-4 「コンテンツ管理」ページ

「15-4 「コンテンツ管理」ページ」の説明

15.2.8.1.2 レポート・ページの例

標準「ドキュメント・タイプ」レポート・ページのテンプレート・ファイルは、doc_types.htmにあります。例15-14に、このファイルの内容を示します。

例15-14 doc_types.htmファイル

<$include std_doctype_html_decl$>

<head>
<$defaultPageTitle=lc("wwDocumentTypes")$>
<$include std_html_head_declarations$>
</head>

<$include body_def$>

<$include std_page_begin$>

<$include std_header$>

<!--Directory Title--->
<table border="0" cellpadding="0" cellspacing="0" summary="">
<tr>
<td width="75"><$if PageParent$><a href="<$PageParent$>">
<$strTrimWs(inc("open_folder_image"))$></a>
<$endif$></td>
<td colspan="2" width="390"><span class=title><$PageTitle$></span></td>
</tr>
</table>

<$if IsSavedQuery$>
<!---Parameters for historical reports-->
<table border="0" cellpadding="0" cellspacing="0" summary="">
<tr>
<td width="75" height="45">&nbsp;</td><!---Indent-->
<td><strong><span class=highlightField><$lc("wwReportCreated")$></span> <$ReportCreationDate$></strong></td>
</tr>
</table>
<$endif$>

<!--Directory Header--->
<table  border="0" cellspacing="0" summary="">
<tr>
<td width="75" height="45">&nbsp;</td><!---Indent-->
<td colspan="2" width="390"><$HeaderText$></td>
</tr>
</table>

<!---Doc types report-->
<table border=0 cellpadding=0 cellspacing=0 summary="">
<tr><td>&nbsp;</td></tr>
<tr>
<td align=center width=<$StdPageWidth$>>
<h1 class="underlinePageTitle"><$lc("wwDocumentTypes")$></h1>
</td>
</tr>
<tr><td>&nbsp;</td></tr>

<$if IsMultiPage$>
<!---Navigation Bar-->
<tr>
<td width=565 align="center"><$include std_page_nav_bar$></td>
</tr>
<$endif$>

<tr>
<td>
<table class="xuiTable" width=<$StdPageWidth$> summary="<$stripXml(lc("wwReportResultsTable"))$>">
<tr class="xuiAltHeader">
<td width=12% class="xuiAltHeader" scope="col"></td>
<td width=29% class="xuiAltHeader" scope="col"><$lc("wwDocumentType")$></td>
<td width=49% class="xuiAltHeader" scope="col"><$lc("wwDescription")$></td>
<td width=12% class="xuiAltHeader" scope="col"><$lc("wwImageFileName")$></td>
</tr>
<$rowCount=0$>

<$loop DocTypes$>
<$if rowCount%2 == 0$>
<$rowClass="xuiRow"$>
<$else$>
<$rowClass="xuiAltRow"$>
<$endif$>
<tr class="<$rowClass$>">
<!--Document types are localized to each instance, so we must use direct path to images directory.-->
<td><img src="<$HttpWebRoot$>images/docgifs/<$dGif$>" alt="<$stripXml(lc("wwDoctypeIcon"))$>" border=0></td>
<td><$dDocType$></td>
<td><$dDescription$></td>
<td><$dGif$></td>
</tr>
<$rowCount=rowCount+1$>
<$endloop$>
</table>
</td>
</tr>
</table>

<$include std_page_end$>

</body>
</html>

この例では、std_doctype_html_declインクルードは、コンテンツ・サーバーの標準的なドキュメント・タイプを参照しています。例にある<head>要素はページ・タイトルとメタデータを参照し、headセクションのコードは、std_page.htmリソース・ファイル内のstd_html_head_declarationsインクルード・コードを使用して構築されます。ページ定義におけるその他の要素は次のとおりです。

1. コンテンツ・サーバーのほとんどのWebページに共通するページ要素は、std_page.htmリソース・ファイル内のインクルード・コードであるbody_def、std_page_beginおよびstd_headerを使用して構築されます。

2. 例にあるDirectory Titleセクションには、開いたフォルダのイメージが表示され、そのイメージが親ページにリンクされて、ページ・タイトルが表示されます。

3. Parameters for historical reportsセクションには、履歴レポートの元の問合せ日付が表示されます。

4. Directory Headerセクションには、レポートの説明が表示されます。

5. Doc types reportセクションには、表のタイトルが表示されます。

6. Navigation Barセクションには、履歴レポートに2ページ以上が必要な場合に、ページのナビゲーション・バーが表示されます。

7. 次の<table>要素では、最初の部分に表の列ヘッダーが表示されます。

8. <table>要素の最後の部分はドキュメント・タイプでループし、レポート表の行が作成されます。

9. ページの末尾のコードは、std_page.htmリソース・ファイル内のstd_page_endインクルード・コードを使用して構築されます。

15.2.8.2 テンプレート・リソースの編集

コンポーネント・ウィザードを使用して既存のテンプレート・リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソースを選択します。

3. テンプレート定義表を削除するか、またはテンプレート定義を手動で編集するには、「カスタム・リソース定義」領域で「エディタの起動」をクリックします。

4. リソースに複数の表がある場合は、編集するテンプレート表を「表名」リストから選択します。

5. 選択したテンプレート表を変更します。

- 表にテンプレート定義を追加するには、「追加」をクリックします。

- 既存のテンプレート定義を編集するには、定義を選択して「編集」をクリックし、パラメータを変更して「OK」をクリックします。

- テンプレート定義を削除するには、定義を選択して「削除」をクリックし、「はい」をクリックして確定します。

15.2.9 環境リソース

環境リソースは、新規変数の値を作成するか既存の値を置換して、構成変数を定義します。カスタム・リソースは、標準的なconfig.cfgファイルがロードされた後でロードされるので、カスタム環境リソースで定義された変数の値が、元の変数の値を置換します。

環境リソースは、次のような名前と値のペア形式を使用して、CFGファイルで定義されます。

variable_name=value

変数の値を定義した後で、次のIdocスクリプト・タグを使用して、テンプレートなどのリソース・ファイル内の変数を参照できます。

<$variable_name$>

環境リソース・ファイルには、次のように#記号で指定されたコメント行を含めることができます。

#Set this variable to true to enable the function.

15.2.9.1 環境リソースの例

例15-15に、環境リソース・ファイルの内容を示します。

例15-15 環境リソース・ファイル

# Use this to turn on or off alternate row coloring
nsUseColoredRows=0

# These are the nested search field definitions.

nsFld1Caption=Document Text
nsFld1Name=
nsFld1Type=FullText
nsFld1OptionKey=
#
nsFld2Caption=Text
nsFld2Name=xtext
nsFld2Type=Text
nsFld2OptionKey=
#
nsFld3Caption=Date
nsFld3Name=xdate
nsFld3Type=Date
nsFld3OptionKey=
#
nsFld4Caption=Integer
nsFld4Name=xinteger
nsFld4Type=Int
nsFld4OptionKey=
#
nsFld5Caption=Option List
nsFld5Name=xoptionlist
nsFld5Type=OptionList
nsFld5OptionKey=optionlistList
#
nsFld6Caption=Info Topic
nsFld6Name=xwfsInfoTopic
nsFld6Type=OptionList
nsFld6OptionKey=wfsInfoTopicList

ネストされた検索コンポーネントにあるcolored_search_resource.htmテンプレート・リソース・ファイルは、次のようにnsUseColoredRows変数を参照します。

<$if isTrue(#active.nsUseColoredRows)$>
<$useColoredRows=1, bkgHighlight=1$>
<$endif$>

標準的な構成変数は、IntradocDir/config/config.cfgファイルで定義されます。構成変数の詳細なリストは、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

15.2.9.2 環境リソースの編集

コンポーネント・ウィザードを使用して既存の環境リソースを編集するには、次の手順を実行します。

1. コンポーネント・ウィザードで、編集対象のリソースが含まれるコンポーネントを開きます。

2. 「カスタム・リソース定義」リストでリソース・ファイルを選択します。

3. 「エディタの起動」をクリックします。

4. テキスト・エディタで構成変数を変更します。

5. リソース・ファイルを保存して閉じます。
変更内容は、「カスタム環境パラメータ」リストに反映されます。

注意:
「カスタム環境パラメータ」リストでの構成設定の表示順は、リソース・ファイルでの実際の表示順とは異なる場合があります。わかりやすく表示するために、テキスト・エディタを起動します。

15.3 コンポーネント定義ファイルの作成

コンポーネント定義ファイルを作成または変更するには、コンポーネント・ウィザードを使用できます。

例15-16は、customhelp_environment.cfgという環境リソース・ファイルを指すコンポーネント定義ファイルを示しています。

例15-16 環境リソースのコンポーネント定義ファイル

<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
@Properties LocalData
blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM
blFieldTypes=
@end
@ResultSet ResourceDefinition
4
type
filename
tables
loadOrder
environment
customhelp_environment.cfg
null
1
@end

15.4 コンテンツ・サーバーの再起動によるコンポーネントの適用

コンテンツ・サーバーは、カスタム・コンポーネントを適用する前に再起動する必要があります。コンテンツ・サーバーを再起動するには、管理コンソール、停止スクリプトと起動スクリプト、またはFusion Middleware Controlを使用して、WebCenter Content管理対象サーバーを再起動します。

次の例では、stopManagedWebLogicおよびstartManagedWebLogicスクリプトでWebCenter Contentを再起動する方法を示します。

詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンテンツ・サーバーの再起動に関する項を参照してください。

WebCenter Content管理対象サーバーをコマンドラインからスクリプトを使用して再起動する手順は、次のとおりです。

1. stopManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを停止します。

- UNIXスクリプト:
DomainHome/bin/stopManagedWebLogic.sh UCM_server1

- Windowsスクリプト:
DomainHome\bin\stopManagedWebLogic.cmd UCM_server1

2. stopWebLogicスクリプトを使用して管理サーバーを停止します。

- UNIXのスクリプト: DomainHome/bin/stopWebLogic.sh

- Windowsのスクリプト: DomainHome\bin\stopWebLogic.cmd

3. startWebLogicスクリプトを使用して管理サーバーを起動します。

- UNIXのスクリプト: DomainHome/bin/startWebLogic.sh

- Windowsのスクリプト: DomainHome\bin\startWebLogic.cmd

4. startManagedWebLogicスクリプトを使用して、WebCenter Content管理対象サーバーを起動します。

- UNIXスクリプト:
DomainHome/bin/startManagedWebLogic.sh UCM_server1

- Windowsスクリプト:
DomainHome\bin\startManagedWebLogic.cmd UCM_server1

16 コンポーネントのインストール

この章では、Oracle WebCenter Content Serverに追加のコンポーネントをインストールする方法について説明します。

この章では、次の項目について説明します。

- 第16.1項「コンポーネントのインストールについて」

- 第16.2項「インストールするコンポーネントのパッケージ化」

- 第16.3項「拡張コンポーネント・マネージャを使用したコンポーネントのインストール」

- 第16.4項「コンポーネント・ウィザードを使用したコンポーネントのインストール」

- 第16.5項「ComponentToolユーティリティを使用したコンポーネントのインストール」

16.1 コンポーネントのインストールについて

コンテンツ・サーバーのサーバー・コンポーネントはデフォルトでインストールされますが、カスタム・コンポーネントおよびOracle Technology Networkからダウンロードされたコンポーネントを使用できるようにするには、それらをインストールして有効にする必要があります。

注意:
インストール済のコンポーネントの有効化または無効化のみが必要な場合は、第10章「コンテンツ・サーバーのコンポーネントの有効化と無効化」を参照してください。

次の各項で説明する方法のいずれかを使用して、コンポーネントをインストールできます。

- 第16.3項「拡張コンポーネント・マネージャを使用したコンポーネントのインストール」

- 第16.4項「コンポーネント・ウィザードを使用したコンポーネントのインストール」

- 第16.5項「ComponentToolユーティリティを使用したコンポーネントのインストール」

コンポーネントをインストールする前に、まず、そのコンポーネントをインスタンスにダウンロードする必要があります。次の要件を満たさないかぎり、コンポーネントをダウンロードできません。

- コンポーネントは、IdcHomeDir/system ディレクトリの外部(つまりDomainHome/ucm/idc/system)に存在する必要があります。これにより、コンポーネントにパッチがアップロードされている場合を除き、パッケージ化されているすべてのコンポーネントが除外されます。

- コンポーネントに適切な名前のZIPファイルがあり、それがカスタム・コンポーネントまたはコア・コンポーネント・ディレクトリ内に存在する必要があります。

16.2 インストールするコンポーネントのパッケージ化

コンポーネント・ウィザードを使用して、複数のコンテンツ・サーバー・インスタンス上にインストールするカスタム・コンポーネントをZIPファイルにパッケージ化することができます。

インストールするコンポーネントをパッケージ化する手順は、次のとおりです。

1. 「管理」トレイまたはメニューで、「管理サーバー」を選択します。
管理サーバーにコンポーネント・マネージャ・ページが表示されます。

2. コンポーネント・マネージャ・ページの最初の段落で、「拡張コンポーネント・マネージャ」をクリックします。
これで拡張コンポーネント・マネージャ・ページが表示され、ダウンロードできるコンポーネントのリストが提示されます。

3. パッケージ化するコンポーネントを、「コンポーネントのダウンロード」リストから選択します。

4. 「ダウンロード」をクリックし、「ファイルのダウンロード」画面を表示します。

5. このファイルをディスクに保存を選択して、「OK」をクリックします。

6. 「別名保存」ダイアログ・ボックスで、ディレクトリに移動して、必要に応じてファイル名を変更し、「保存」をクリックします。
これによって、コンポーネントのインストールに使用できるコンポーネントZIPファイルが作成されます。

16.3 拡張コンポーネント・マネージャを使用したコンポーネントのインストール

拡張コンポーネント・マネージャを使用してコンポーネントをインストールするには、次の手順を実行します。

1. 「管理」トレイまたはメニューで、「管理サーバー」を選択します。
管理サーバーに、コンポーネント・マネージャの画面が表示されます。

2. 「参照」ボタンをクリックし、ダウンロードされて保存されたZIPファイルを見つけます。

3. コンポーネント名を選択し、「開く」をクリックします。

4. 「インストール」をクリックします。何がインストールされるかを詳細に示すメッセージが表示されます。

5. 「続行」をクリックしてインストールを続けるか、「取消」をクリックしてインストールを停止します。

6. 「続行」をクリックした場合、インストールが正常に行われるとメッセージが表示されます。次の2つのオプションのいずれかを選択します。

- コンポーネントを有効にし、コンテンツ・サーバーを再起動します。

- コンポーネント・マネージャに戻ります(コンポーネントの追加を続けることができます)。コンポーネントの追加が完了したら、有効にするコンポーネントを選択し、「有効化」をクリックします。コンポーネントの有効化が完了したら、サーバーを再起動します。

16.4 コンポーネント・ウィザードを使用したコンポーネントのインストール

コンポーネント・ウィザードを使用してコンポーネントをインストールするには、次の手順を実行します。

1. コンポーネント・ウィザードを起動します。

- (Windowsオペレーティング・システム)「スタート」メニューから、「プログラム」→「Oracle WebCenter Content Server」→サーバー名→「ユーティリティ」→「コンポーネント・ウィザード」を選択します。

- (UNIXオペレーティング・システム) DomainHome/ucm/cs/binディレクトリでComponentWizardスクリプトを実行します。

「コンポーネント・ウィザード」のメイン画面および「コンポーネント・リスト」画面が表示されます。

2. 「コンポーネント・リスト」画面で、「インストール」をクリックします。
「インストール」画面が表示されます。

1. 「選択」をクリックします。

2. ダウロードされて保存されたZIPファイルにナビゲートし、それを選択します。

3. 「開く」をクリックします。
ZIPファイルのコンテンツが「インストール」画面のリストに追加されます。

4. 「OK」をクリックします。コンポーネントを有効にするように求められます。

5. 「はい」をクリックします。そのコンポーネントは、「コンポーネント・リスト」画面で、有効なコンポーネントとして表示されます。

6. コンポーネント・ウィザードを終了します。

7. Oracle WebCenter Content Serverを再起動します。

インストールするコンポーネントに応じて、「管理」トレイまたは「管理アプレット」ページに新しいメニュー・オプションが表示されます。コンポーネントのなかには、単に既存の機能を拡張するだけで、別個の新しいオプションとしては表示されないものがあります。詳細は、コンポーネントのドキュメントを参照してください。

16.5 ComponentToolユーティリティを使用したコンポーネントのインストール

ComponentToolユーティリティを実行し、インストールして有効にするコンポーネントのZIPファイルを指定します。

DomainHome/ucm/cs/bin/ComponentTool path_to_file/component.zip

17 コンポーネントのアンインストール

この章では、Oracle WebCenter Content Serverからコンポーネントをアンインストールする方法について説明します。

この章では、次の項目について説明します。

- 第17.1項「コンポーネントのアンインストールについて」

- 第17.2項「コンポーネントのアンインストール方法」

17.1 コンポーネントのアンインストールについて

コンテンツ・サーバーのコンポーネント・ウィザードの「コンポーネント・リスト」画面には、現在インストールされているすべてのコンポーネントが表示されます。コンポーネント・ウィザードを起動すると、この画面が表示されます。この画面で、コンポーネントのアンインストールを実行できます。

17.2 コンポーネントのアンインストール方法

「コンポーネント・リスト」画面で、コンポーネントを選択し、それをアンインストールできます。

1. 第9.2.1項「コンポーネント・ウィザード」の説明に従って、コンポーネント・ウィザードを起動します。

2. 「コンポーネント・リスト」画面で、アンインストールするコンポーネントを選択します。

3. 「アンインストール」ボタンをクリックします。
これにより、選択されたコンポーネントがコンテンツ・サーバー・インスタンスから削除されます。コンポーネント・ファイルはファイル・システムに残りますが、コンポーネントのリストには表示されなくなります。

第V部

環境へのWebCenter Contentの統合

この部では、Oracle WebCenter Contentとエンタープライズ・アプリケーションの統合方法について説明します。

注意:
Content Integration Suite (CIS)は、非推奨になりました。開発者およびシステム統合者は、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)を使用します。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。

第5部の内容は次のとおりです。

- 第18章「環境へのWebCenter Contentの統合の開始」

- 第19章「統合のためのWebCenter Content Webサービスの構成」

- 第20章「コンテンツ・サーバーでのJavaServer Pagesの統合」

- 第21章「IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス」

- 第22章「統合のためのCOM APIの使用」

- 第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」

- 第24章「コンテンツ・サーバーのJCRアダプタの使用」

- 第25章「WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成」

- 第26章「DesktopTagコンポーネントのカスタマイズ」

18 環境へのWebCenter Contentの統合の開始

この章では、Oracle WebCenter Contentとエンタープライズ・アプリケーションの統合方法について説明します。

この章では、次の項目について説明します。

- 第18.1項「統合方法について」

- 第18.2項「Webサービスの概要」

- 第18.3項「仮想フォルダおよびWebDAV統合」

18.1 統合方法について

Oracle WebCenter Contentとエンタープライズ・アプリケーションの統合では、アプリケーション・サーバー、カタログ・ソリューション、パーソナライズ・アプリケーション、エンタープライズ・ポータル、クライアント側ソフトウェアなど、いくつかの方法を使用できます。一般に、これらの統合方法は、既存のOracle WebCenter Content Serverサービスを実行するためのメソッドおよび関連パラメータの変換と受け渡しを行います。

コンテンツ・サーバー・サービスは、Oracle WebCenter Content内のコンテンツおよびコンテンツ管理機能にアクセスするためのウィンドウとしての役割を果たします。たとえば、単純な統合オプションとしては、WebCenter Content内で管理されているコンテンツを永続URLによって参照するオプションがあります。他のいくつかの統合オプションは、Java API、Microsoft Component Object Model (COM)インタフェース、またはActiveXコントロールの使用を可能にします。

この章の主眼は、使用可能な統合オプションを示し、実行の方法(IdcCommand Xか、永続URLか、SOAPかなど)を提示し、その方法についての詳細ドキュメントの入手先に関する情報を提供することです。特に、この章では、様々なプロトコル、インタフェースおよびマッピング・サービスを使用しているネットワーク・システム環境内でのOracle WebCenter Contentの統合に関する基本概念について説明します。

IdcCommandユーティリティを使用して他のアプリケーションからコンテンツ・サーバー・サービスにアクセスする方法については、第21章「IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス」を参照してください。

COMインタフェースについては、第22章「統合のためのCOM APIの使用」を参照してください。

Remote Intradoc Client (RIDC)統合については、第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。

18.2 Webサービスの概要

Webサービスは、アプリケーション・サーバー、.NETサーバー、コンテンツ・サーバーなどの既存のソフトウェア・システムの上のレイヤーとして存在します。通信のためのモデルとしてインターネットに適応したWebサービスは、デフォルトのネットワーク・プロトコルとしてHyperText Transfer Protocol (HTTP)に依存します。Webサービスを、異種オペレーティング・システムまたはプログラミング言語間の架け橋として使用して、コンポーネントを組み合せてアプリケーションを作成できます。

注意:
このドキュメント内のWebサービスに関する情報は、Oracle WebLogic Serverに適用されます。IBM WebSphereのWebサービスについては、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。

WebCenter Contentは、Webサービスを使用してコンテンツ・サーバーと統合されたアプリケーションを作成するための2つの方法をサポートしています。

- WebCenter Content WebサービスとOracle WebLogic Server Webサービスの併用。セキュリティ構成およびSecurity Assertion Markup Language (SAML) (WebCenter Content 11gで導入されました)がサポートされます。
コンテンツ・サーバーは、コア製品に組み込まれたいくつかのWebサービスを提供します。Oracle WebLogic Serverは、SOAP機能を提供し、Oracle WebCenter Content Serverは、Oracle WebLogic Serverを通じて複数のSOAPリクエストをサポートします。詳細は、第19章「統合のためのWebCenter Content Webサービスの構成」を参照してください。

- Web サービス記述言語(WSDL)およびSOAP (Simple Object Access Protocol)ファイル。コンテンツ・サーバーのWSDLジェネレータ・コンポーネント(Oracle Universal Content Management 10gで導入されました)がある場合もない場合もあります。
WSDLジェネレータ・コンポーネントWsdlGeneratorは、コンテンツ・サーバーの機能にアクセスするための統合テクノロジを提供します。このコンテンツ・サーバー・システム・コンポーネントは、デフォルトでインストールされ、有効化されます。WSDLジェネレータは、コンテンツ・サーバーのサービスのためのWSDLを作成できます。または、サービス・コールをSOAPで記述することが可能です。詳細は、第25章「WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成」を参照してください。

Webサービスをいずれの方法で使用した場合でも、セキュリティのためにOracle Web Services Manager (Oracle WSM)を使用することができます。Oracle WSMの詳細は、第19章「統合のためのWebCenter Content Webサービスの構成」およびOracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイドを参照してください。

18.3 仮想フォルダおよびWebDAV統合

フォルダ・コンポーネントおよびWebDAVコンポーネント(Folders_gおよびCoreWebdav)は、WebCenter Contentとともにコンテンツ・サーバーの一部としてインストールされます。システム・コンポーネントであるCoreWebdavは、デフォルトで有効化されます。Folders_gコンポーネントを有効にして、Oracle WebCenter Content Serverへのインタフェースを仮想フォルダの形式で設定できます。仮想フォルダは、マルチレベル・フォルダ構造の作成に使用できます。CoreWebdavコンポーネントにより、WebDAV (Web-Based Distributed Authoring and Versioning)プロトコルをサポートするクライアントを使用して、コンテンツをリモートで作成および管理できます。

- Folders_gコンポーネントは、コンテンツ・サーバー内のコンテンツに対して階層フォルダ・インタフェースを提供します。WebDAV機能およびWebDAVクライアント製品では、このコンポーネントが必要です。

- CoreWebdavコンポーネントにより、WebDAVプロトコルをサポートするクライアントを使用して、コンテンツをリモートで作成および管理するためのWebDAV機能が有効になります。たとえば、Webブラウザ・インタフェースを使用するのではなく、Microsoft Windowsエクスプローラを使用して、リポジトリからコンテンツをチェックアウトし、そのコンテンツを変更して、チェックインすることができます。

18.3.1 仮想フォルダ

フォルダ・コンポーネントは、Oracle WebCenter Content Serverへのインタフェースを仮想フォルダ(階層フォルダとも呼ばれる)の形式で設定します。仮想フォルダを使用すると、マルチレベル・フォルダ階層を作成できます。

仮想フォルダには、次のような2つの主な利点があります。

- ユーザーは、使い慣れたフォルダ・タイプのインタフェースでドリルダウンし、コンテンツを検索できます。

- ユーザーは特定のフォルダからコンテンツ・アイテムをチェックインすることで、デフォルト・メタデータをコンテンツ・アイテムに適用できます。

フォルダ・コンポーネントには、次の構造が使用されます。

- 各Oracle WebCenter Content Serverインスタンスには、仮想フォルダの共通セットがあります。フォルダへの変更はシステム全体に適用されます。

- コントリビューション・フォルダというシステムレベルのデフォルト・フォルダが1つあります。カスタム・フォルダ・インタフェースを使用している場合、それらの製品のフォルダは、システム・レベルのフォルダ階層にも表示される可能性があります。

- システム管理者はシステムレベル・フォルダの名前を変更できますが、システムレベル・フォルダを削除したり、システムレベルのカスタム・フォルダを追加するには、データベースへの変更が必要です。(システムレベルのフォルダを削除すると、そのフォルダは無効になりますが、システムからは除去されていません。)

- 階層内の各フォルダには、フォルダの作成時に自動的に割り当てられた値と同じフォルダ値(数値)のコンテンツ・アイテムが含まれています。コンテンツ・アイテムの「フォルダ」フィールドの値を変更すると、そのコンテンツ・アイテムは別のフォルダに配置されます。

- システム管理者は、仮想フォルダの機能がシステム・パフォーマンスに影響を与えないように、フォルダ数と各フォルダ内のファイル数を制限できます。

WebDAV統合のためのコンテンツ・サーバーの構成の詳細は、『Oracle Fusion Middleware Content Serverアプリケーション管理者ガイド』を参照してください。

18.3.2 WebDAV統合

WebDAV (Web-Based Distributed Authoring and Versioning)は、WebDAVプロトコルをサポートするクライアントを使用してコンテンツをリモートで作成および管理する手段を提供します。たとえば、Webブラウザ・インタフェースを使用するのではなく、Microsoft Windowsエクスプローラを使用して、リポジトリ内のコンテンツをチェックイン、チェックアウトおよび変更できます。

WebDAVはHTTP/1.1プロトコルの拡張機能で、クライアントがリモートWebコンテンツのオーサリング操作を実行できるようにします。WebDAVプロトコルはRFC 2518.0で規定されています。

詳細は、次のURLのWebDAV Resources Webサイトを参照してください。

http://www.webdav.org

WebDAVは、次のオーサリング機能およびバージョニング機能をサポートしています。

- バージョン管理

- 上書き防止用のロック

- Webページのプロパティ

- Webリソースの収集

- ネームスペース管理(Webサーバー上でのページのコピーまたは移動)

- アクセス制御

コンテンツ・サーバーなどのコンテンツ管理システムでWebDAVを使用すると、WebDAVクライアントは、コンテンツ・リポジトリ内のネイティブ・ファイルへの代替ユーザー・インタフェースとして機能します。作成者がコンテンツ・サーバーのWebブラウザ・インタフェースとWebDAVクライアントのいずれを使用しても、同じバージョニングとセキュリティ制御が適用されます。

コンテンツ・サーバーのWebDAVインタフェースは、階層フォルダ・インタフェースに基づいています。詳細は、第18.3.1項「仮想フォルダ」を参照してください。

18.3.2.1 WebDAVクライアント

WebDAVクライアントは、WebDAVプロトコルを使用してリクエストを送信し、レスポンスを受信できるアプリケーションです(Microsoft Windowsエクスプローラ、Word、Excel、PowerPoint)。サポートされているバージョンについては、最新のWebDAVクライアントのドキュメントを確認してください。WebCenter Content WebDAVクライアントは、Oracle WebCenter Content ServerへのWebDAVインタフェースを拡張する別の製品です。

WebDAV以外のクライアントで作成されたファイルを、WindowsエクスプローラでWebDAV仮想フォルダを使用して管理できますが、ネイティブ・アプリケーションを使用して、Oracle WebCenter Content Serverリポジトリとの間でコンテンツのチェックインやチェックアウトを行うことはできません。

デスクトップ・ソフトウェア・パッケージには、WebDAVクライアント・コンポーネントと、チェックアウトおよびオープン・コンポーネントも含まれています。

18.3.2.2 WebDAVサーバー

WebDAVサーバーは、WebDAVプロトコルを使用してリクエストの受信とレスポンスの送信を行うことができ、オーサリング機能およびバージョニング機能を提供するサーバーです。WebDAVリクエストはHTTPプロトコル経由で送信されるため、WebDAVサーバーは通常、標準のWebサーバーに対するアドオン・コンポーネントとして作成されます。コンテンツ・サーバーでは、WebDAVサーバーは、クライアントとコンテンツ・サーバー間のインタプリタとしてのみ使用されます。

18.3.2.3 WebDAVアーキテクチャ

WebDAVは、WebDAVコンポーネントによってOracle WebCenter Content Serverに実装されます。WebDAVリクエストのアーキテクチャは、次のようなものです。

1. Oracle WebCenter Content ServerへのリクエストがWebDAVクライアントで作成されます。

2. メッセージは、(IISのDLLを介して)Webサーバーで処理されます。

3. Oracle WebCenter Content Serverで、WebDAVコンポーネントは次の機能を実行します。

- クライアント・リクエストをWebDAVと認識する。

- クライアント・リクエストをOracle WebCenter Content Serverの該当するWebDAVサービス・コールにマップする。

- WebDAVリクエストから該当するOracle WebCenter Content Serverリクエストにクライアント・リクエストを変換する。

- コアのOracle WebCenter Content Serverに接続し、Oracle WebCenter Content Serverリクエストを実行する。

4. WebDAVコンポーネントによってOracle WebCenter Content ServerレスポンスがWebDAVレスポンスに変換され、WebDAVクライアントに返されます。

19 統合のためのWebCenter Content Webサービスの構成

この章では、Oracle WebCenter Content WebサービスをOracle WebLogic Server Webサービスとともに使用して、クライアント・アプリケーションをOracle WebCenter Content Serverと統合する方法について説明します。

この章では、次の項目について説明します。

- 第19.1項「統合のためのWebCenter Content Webサービスの構成について」

- 第19.2項「Webサービス・ポリシーを使用したWebサービス・セキュリティの構成」

- 第19.3項「SAMLサポートの構成」

コンテンツ・サーバーで使用できるWebサービスの一般的な情報については、第18.2項「Webサービスの概要」を参照してください。

この章で説明されているWebサービスの使用方法は、Oracle Universal Content Management 11gで導入されました。Oracle Universal Content Management 10gで導入された、Web Services Definition Language (WSDL)ファイル、SOAP (Simple Object Access Protocol)ファイルおよびWSDLジェネレータによる方法を使用する場合は、第25章「WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成」を参照してください。

19.1 統合のためのWebCenter Content Webサービスの構成について

WebCenter Content Webサービスは、Oracle WebLogic Server Webサービスと連携して、コンテンツ・サーバーのための管理機能を実行します。Oracle WebLogic Server Webサービスは、SOAP機能を提供し、WebCenter Content Webサービスには、複数の組込みSOAPリクエストが含まれています。WebCenter Content Webサービスは、コンテンツ・サーバーとともに自動的にインストールされますが、セキュリティを設定するには追加の構成が必要です。

WebCenter Content Webサービスのコアとなる実現技術は、次のようなものです。

- SOAP (Simple Object Access Protocol)は、リクエストおよびレスポンス・メッセージをネットワーク経由で送信する前にそれらの中の情報をエンコードするために使用される、軽量のXMLベース・メッセージング・プロトコルです。SOAPリクエストは、実装のためにWebCenter Content WebサービスからOracle WebLogic Server Webサービスに送信されます。SOAPの詳細は、http://www.w3.org/TR/soap12の『Simple Object Access Protocol (SOAP)』を参照してください。

- Webサービス・セキュリティ(WS-Security)は、機密保護、整合性および認証によってWebサービスを保護するための、標準セットのSOAP拡張機能です。WebCenter Content Webサービスでは、特定のユーザーとしてサーバーに接続するクライアントに対して、またはユーザーとして別なサーバーと対話するサーバーに対して、認証のためにWS-Securityが使用されます。詳細は、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wssの『OASIS Web Service Security』のWebページを参照してください。

- Webサービス・ポリシー(WS-Policy)は、Webサービスにポリシーを添付するための標準です。WebCenter Content Webサービスでは、WebサービスにWS-Securityを適用するためにポリシーが使用されます。サポートされている2つのポリシーは、username-tokenセキュリティとSAMLセキュリティです。
これまで、OracleはOracle Web Services Manager (Oracle WSM)をそのWebサービスの保護に使用し、Oracle WebLogic ServerはWeb Services Security Policy (WS-SecurityPolicy)をそのWebサービスの保護に使用していました。Webサービス・セキュリティは部分的に標準化されているため、一部のOracle WSMおよびWS-SecurityPolicyポリシーは相互に機能します。

注意:
可能な場合には必ず、Oracle WebLogic Server Webサービスに対してOracle WSMを使用してください。同じWebサービスで、Oracle WSMとOracle WebLogic Server Webサービスのポリシーを混在させて使用することはできません。

WebCenter Content Webサービス(コンテキスト・ルートはidcws/)はSOAPベースです。一方、WebCenter Content のネイティブWebサービス (コンテキスト・ルートはidcnativews/)はJAX_WSベースです。いずれの種類のWebサービスも、Oracle WebLogic Server管理コンソールからOracle WSMポリシーを割り当てることができます。

一般的なWebCenter Content Webサービスは、JAX-WSベースであり、Oracle WSMポリシーを割り当てて、Oracle WSMによって管理することができます。ネイティブのWebCenter Content Webサービスは、SOAPベースであり、Oracle WebLogic Server管理コンソールを通じて管理されるWS-Policyポリシーのみをサポートできます。

Oracle WSMの詳細は、Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイドを参照してください。

Oracle WebLogic Server Webサービス・ポリシーのサブセットはOracle WSMポリシーと相互運用します。詳細は、Oracle Fusion Middleware Oracle Web Services Managerの相互運用性ガイドの「Oracle WebLogic Server 11gのWebサービス・セキュリティ環境との相互運用性」を参照してください。

Web Services Security Policy (WS-SecurityPolicy)は、WS-Policyフレームワークとともに使用するためのセキュリティ・ポリシー・アサーションのセットです。詳細は、http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.htmlの『Web Services Security Policy (WS-SecurityPolicy)』を参照してください。

- SAMLは、異なるセキュリティ・ドメイン間で認証および認可を交換するためのXML標準です。詳細は、http://docs.oasis-open.org/security/saml/v2.0/の『Security Assertion Markup Language (SAML)』を参照してください。

- WebLogic Scripting Tool (WLST)は、Oracle WebLogic Serverを管理するためのコマンドライン・ツールです。詳細は、Oracle Fusion Middleware WebLogicスクリプト・ツール・コマンド・リファレンスを参照してください。

19.1.1 WebCenter Content Webサービス

WebCenter Contentは、一般的な(汎用)JAX-WSベースのWebサービスと、ネイティブのSOAPベースのWebサービスという2つのタイプのWebサービスを提供します。2つのタイプのWebサービスはそれぞれ、異なるコンテキスト・ルートに存在します。コンテキスト・ルートは、WebサービスにアクセスするためのURL内の1次識別子です。

コンテキスト・ルートは次のとおりです。

- idcws
通常のWebサービス・クライアントからコンテンツ・サーバーへの一般的なアクセスでは、このコンテキスト・ルートを使用します。

- idcnativews
Remote Intradoc Client (RIDC)は、ネイティブのWebサービスを使用します。これらのサービスに対してカスタム・クライアントを開発しないことをお薦めします。RIDCの詳細は、第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。

次の表では、idcwsコンテキスト・ルートのWebCenter Content Webサービスについて説明します。

WebCenter Content Webサービス

説明

GenericSoapService

このサービスでは、そのSOAPフォーマットとしてHDAに類似した汎用フォーマットが使用されます。これは、IsSoap=1が設定されているときにコンテンツ・サーバーに対して実行できる汎用SOAPコールとほぼ同一です。フォーマットの詳細は、idcws/GenericSoapPort?WSDLの公開済WSDLを参照してください。
WS-Policyを通じてWS-SecurityをGenericSoapServiceに適用できます。コンテンツ・サーバーは、SAMLおよびusername-token用のOracle WSMポリシーをサポートしています。

WS-Securityポリシーがこのサービスに適用されることが許可された場合、このサービスでは、ストリーム・メッセージ送信最適化メカニズム(MTOM)を使用することはできません。非常に大きなファイル(クライアントやサーバーのメモリーを超えるサイズのファイル)をアップロードまたはダウンロードすることはできません。

次の表では、idcnativewsコンテキスト・ルートのWebCenter Content Webサービスについて説明します。

WebCenter Content Webサービス

説明

IdcWebRequestService

これは、一般的なWebCenter Contentサービスです。これは基本的に、SOAPリクエストにラップされた、コンテンツ・サーバーへの通常のソケット・リクエストです。大きなファイルをサポートするために、リクエストは、ストリーム・メッセージ送信最適化メカニズム(MTOM)を使用してコンテンツ・サーバーに送信されます。
ストリームMTOMとWS-Securityを混在させることはできません。したがって、このサービスにはWS-Securityを適用しないでください。ストリーム・ファイル・サポートが損なわれます。セキュリティを確保するため、まずIdcWebLoginServiceを使用してログインし、その後、そのサービスから受信した同じJSESSIONIDを、IdcWebRequestServiceへの次のコールでCookieとして使用します。

IdcWebLoginService

このサービスは、IdcWebRequestServiceコールにセキュリティを追加するためにのみ使用されます。このサービスには、パラメータはありません。これは単にセッションを作成するのみです。取得する重要なフィールドは、IdcWebRequestServiceへの以降のコールで使用するJSESSIONID値です。IdcWebRequestServiceでWS-Securityを使用する場合は、ここで適用します。コンテンツ・サーバーは、SAMLおよびusername-token用のOracle WSMポリシーをサポートしています。

19.2 Webサービス・ポリシーを使用したWebサービス・セキュリティの構成

WebCenter Content Webサービスは、WebCenter Content EARとともにインストールされ、デフォルトで使用可能になっています。ただし、いずれかのWebCenter Content WebサービスでWebサービス・セキュリティ(WS-Security)を構成しないかぎり、コンテンツ・サーバーへのすべての接続でanonymousユーザーが使用されます。WebCenter Content Webサービスのためのセキュリティを構成するには、WS-Policyを使用してWS-Securityを構成します。認証の有効化には、追加の構成が必要です。

19.2.1 WS-Policyを使用したWS-Securityの構成

WS-Securityは、Webサービス・ポリシー(WS-Policy)を使用して設定されます。Webサービスに対してセキュリティ・ポリシーを設定して、それらのセキュリティ・プロトコルを定義できます。特に、WebCenter Content Webサービスは、Oracle WSMポリシーをサポートしています。

WebCenter Contentは、2つの一般クラスのポリシーusername-tokenとSAML、および次のOracle WSMポリシーをサポートしています。

- oracle/wss11_saml_token_with_message_protection_service_policy

- oracle/wss11_username_token_with_message_protection_service_policy

WS-Policyを使用してWS-Securityを構成する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにアクセスします。

2. サイド・パネルから「デプロイメント」を選択します。

3. 「デプロイメント」表で、WebCenter Content Native Web ServicesまたはWebCenter Content Web Servicesのいずれかを開きます。

4. Webサービスの名前(GenericSoapServiceなど)をクリックします。

5. Webサービスの「設定」ページの「構成」タブをクリックし、WS-Policyタブをクリックします。

6. メイン・サービスをクリックします。ここで、追加するOracle WSMポリシーを選択できます。

7. Oracle WSMポリシーの追加が終わったら、追加内容を保存するために、WebCenter ContentのネイティブWebサービスまたはWebCenter Contentの汎用Webサービスを更新する必要があります。

19.3 SAMLサポートの構成

クライアント側の証明書認証に対するSAMLサポートも提供できます。クライアントがIDプロバイダであることを可能にする(つまり、資格証明をアサートできる)ようにSAMLサポートを提供するには、キーストアを構成し、そのキーストアを使用するためのJavaプラットフォーム・セキュリティ(JPS)プロバイダを構成し、クライアントの資格証明ストア(CSF)を作成し、キーストアとCSFを使用するためのJavaクライアントを構成する必要があります。

19.3.1 キーストアの構成

サーバーとクライアントの両方でキーストアのコピーが必要です。サーバーは、キーストアを使用して、クライアントから渡された資格証明を認証します。キーストアは共有シークレットとしてのみ使用されるため、この状況では、自己署名証明書が役に立ちます。keytoolユーティリティを使用して、自己署名証明書を生成できます。次の例の値の多くは、ドメインのconfig/fmwconfig/jps-config.xmlファイルのデフォルト値です。これについては、第19.3.2項「キーストアを使用するための、WebCenter Contentに対するJPSの構成」で説明されています。

$ keytool -genkey -alias orakey -keyalg RSA -keystore default-keystore.jks -keypass welcome -storepass welcome

keytoolコマンドには、任意の関連データを入力できます。クライアントが使用するキーストアおよび証明書のパスワードを除いて、詳細は重要ではありません。

19.3.2 キーストアを使用するための、WebCenter Contentに対するJPSの構成

Oracle WebLogic Serverドメインにおけるキーストアの構成には、DomainHome/config/fmwconfig/jps-config.xmlファイルの編集が含まれます。

キーストアを使用するためにWebCenter Contentに対してJPSを構成する手順は次のとおりです。

1. <serviceProviders>要素でプロバイダが定義されていることを確認するか、プロバイダを定義します。
プロバイダは、この要素にデフォルトで定義されている必要があります。そうでない場合、例19-1に示されているように、プロバイダを定義する<serviceProvider>要素を追加する必要があります。

例19-1 jps-config.xmlにおけるサービス・プロバイダ定義

<serviceProviders>
<serviceProvider type="KEY_STORE" name="keystore.provider"
class="oracle.security.jps.internal.keystore.KeyStoreProvider">
<description>PKI Based Keystore Provider</description>
<property name="provider.property.name" value="owsm"/>
</serviceProvider>
</serviceProviders>

2. キーストア・インスタンスが<serviceInstances>に定義されていることを確認します。
キーストア・インスタンスは、デフォルトで定義されている必要があります。

キーストア・インスタンスは、この要素にデフォルトで定義されている必要があります。そうでない場合、例19-2に示されているように、キーストア・インスタンスを定義する<serviceInstance>要素を追加する必要があります。

例19-2 jps-config.xmlにおけるキーストア・インスタンス定義

<serviceInstances>
<serviceInstance name="keystore" provider="keystore.provider"
location="./default-keystore.jks">      <description>Default JPS Keystore Service</description>      <property name="keystore.type" value="JKS"/>      <property name="keystore.csf.map" value="oracle.wsm.security"/>      <property name="keystore.pass.csf.key" value="keystore-csf-key"/>      <property name="keystore.sig.csf.key" value="sign-csf-key"/>      <property name="keystore.enc.csf.key" value="enc-csf-key"/>  </serviceInstance>
</serviceInstances>

キーストア・インスタンスの場所は、キーストアを作成したところと同じ場所に設定する必要があります。

3. キーストアへの参照が<jpsContexts>要素内にあることを確認します。
この設定は、デフォルトでjps-config.xmlファイル内に存在する必要があります。そうでない場合、例19-3に示されているように、設定を追加する必要があります。

例19-3 JPSコンテキストにおけるキーストア

<jpsContext name="default">    <serviceInstanceRef ref="credstore"/>    <serviceInstanceRef ref="keystore"/>    <serviceInstanceRef ref="policystore.xml"/>    <serviceInstanceRef ref="audit"/>    <serviceInstanceRef ref="idstore.ldap"/></jpsContext>

4. jps-config.xmlファイルを保存し、第15.4項「コンテンツ・サーバーの再起動によるコンポーネントの適用」の説明に従って、WebCenter Content管理対象サーバーと管理サーバーを再起動します。

19.3.3 クライアントCSFの作成

クライアントでは、キーストアをロック解除するためのキーを格納する資格証明ストアが必要です。Oracle WebLogic Serverは、資格証明ストア・フレームワーク(CSF)を作成するための様々な方法を提供します。CSFを作成する1つの方法は、Oracle WebLogic Server Scripting Tool (WLST)コマンドを使用することです。

クライアントCSFを作成する手順は次のとおりです。

1. 例19-4に示されているように、Oracle WebLogic Serverドメインに接続します。

例19-4 WLSTコマンドを使用したクライアントCSFの作成

$ ./wlst.sh

$ connect()

$ createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore", password="welcome")
$ createCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password="welcome")
$ createCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password="welcome")

2. 例19-4に示されているように、WLST createCredコマンドを使用して、CSFを定義します。
作成したキーストアの別名およびパスワードに一致するように、この例の値を変更します。

WLSTにより、DomainHome/config/fmwconfig/cwallet.ssoにCSFウォレットが作成されます。このウォレットは、クライアント上でのみ使用可能です。

3. WLSTを終了し、ドメインの管理サーバーを再起動します。

4. ウォレットのコピーをクライアントに送信します。

19.3.4 キーストアおよびCSFを使用するためのJavaクライアントの構成

Javaクライアントを構成してキーストアおよびCSFを使用できるようにするには、クライアントに次のアイテムが存在している必要があります。

- キーストアのコピー

- CSFウォレットのコピー

- jps-config.xmlファイルのクライアント・バージョン

キーストアおよびCSFを使用するためにJavaクライアントを構成する手順は次のとおりです。

1. Javaクライアントのjps-config.xmlファイルを編集します。

2. 例19-5に示されているように、キーストアおよびCSFウォレットの場所を追加し、ファイルを保存します。

例19-5 Javaクライアントのjps-config.xmlファイルにおけるキーストアおよびCSFの場所

<jpsConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="jps-config.xsd">    <serviceProviders>        <serviceProvider name="credstoressp"
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">            <description>SecretStore-based CSF Provider</description>        </serviceProvider>               <serviceProvider type="KEY_STORE" name="keystore.provider"
class="oracle.security.jps.internal.keystore.KeyStoreProvider">            <description>PKI Based Keystore Provider</description>            <property name="provider.property.name" value="owsm"/>        </serviceProvider>    </serviceProviders>    <serviceInstances>        <serviceInstance name="credstore" provider="credstoressp" location="./">
<description>File Based Credential Store Service Instance</description>
</serviceInstance>               <serviceInstance name="keystore" provider="keystore.provider"
location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="sign-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
</serviceInstance>
</serviceInstances>    <jpsContexts default="default">        <jpsContext name="default">            <serviceInstanceRef ref="credstore"/>            <serviceInstanceRef ref="keystore"/>        </jpsContext>    </jpsContexts></jpsConfig>

3. Javaシステム・プロパティoracle.security.jps.configを、jps-config.xmlファイルを指すように設定します。

System.setProperty("oracle.security.jps.config", “jps-config.xml”);

実行時、クライアントでこの場所を設定できます。

20 コンテンツ・サーバーとJavaServer Pagesの統合

この章では、Oracle WebCenter Content ServerとJavaServer Pages (JSP)の統合方法について説明します。

この章では、次の項目について説明します。

- 第20.1項「JSP統合について」

- 第20.2項「JSPサポートの構成」

- 第20.3項「サンプルのページのロード」

20.1 JSP統合について

JavaServer Pages (JSP)からコンテンツ・サーバーのコア機能にアクセスして、組込みのApache Jakarta Tomcat Serverを使用するJSPページ実行機能によってフォームおよびカスタム・ページを配信できます。

注意:
コンテンツ・サーバーとともにSite Studio for External Applications (SSXA)を使用している場合は、コンテンツ・サーバーのJSP機能は有効にしないでください。コンテンツ・サーバーのJSP機能を有効にすると、SSXAテンプレートでの解析エラーが発生します。

20.1.1 JSP実行

JSP実行機能は、組込みのApache Jakarta Tomcat Servlet/JSP Serverを使用して、コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスします。

Apache Jakarta Tomcat Serverは、その機能が有効になっている場合はコンテンツ・サーバーの内部で実行される、Java ServletおよびJavaServer Pagesの無償のオープンソース・サーバーです。Tomcat ServerをWebCenter Contentと統合することにより、コンテンツ配信のパフォーマンスが向上するという利点が得られます。

開発者は、JSP実行機能を使用して、標準のコンポーネント・アーキテクチャではなく、JavaServer Pagesを通じて、コンテンツ・サーバーのコンテンツ、ResultSets、パーソナライズおよびセキュリティ定義、事前定義変数および構成設定にアクセスし、それらを変更できます。サービスおよびIdocスクリプト機能は、コンテンツ・サーバーに実行可能コンテンツとして存在するJSPページから実行することも可能です。

重要:
JSPページがOracle WebCenter Content Server上にJSP実行機能の一部として提供されている場合のみ、JSPページでIdocスクリプト機能を実行できます。別のJSPサーバー上で提供されているJSPページには、この機能がありません。その場合、JSPページをOracle WebCenter Content Serverにチェックインすることで、リビジョン・コントロールが可能になりますが、プレゼンテーション層(JSPサーバー)でIdocスクリプト機能を動的に実行することはできません。

20.1.2 Tomcat

JSPがサービスをコールする機能は、Tomcat 5.025サーバーをコンテンツ・サーバーのコア機能と統合することで提供されます。

- Tomcatは、Java ServerおよびJavaServer Pagesの無償のオープンソース・サーバーです。バージョン5.025は、Servlet 2.4およびJSP 2.0仕様に準拠しています。

- Tomcatをコンテンツ・サーバーに統合することの主な利点は、コンテンツ配信のパフォーマンスが向上することです。直接統合では、ソケットベースのインタフェースは必要なく、Oracle WebCenter Content Serverのコア機能がすべて使用可能になります。

- Tomcatはコンテンツ・サーバーに組み込まれていますが、server.xmlを構成ファイルとして使用して、内部Tomcatエンジンをニーズに合うように変更できます。

注意:
この製品には、Apache Software Foundation (http://www.apache.org/)によって開発されたソフトウェアが含まれています。

20.1.3 機能

JSPサポートが有効な場合、カスタム・コンポーネントには、タイプがjspおよびjspxのJSPページを含めることができます。

- DomainHome/ucm/cs/weblayout/jspディレクトリは、デフォルトでJSPページをホストできます。

- Oracle WebCenter Contentの配布媒体には、最新のJava EE SDKも含まれています。

20.2 JSPサポートの構成

JSPサポートを有効化して構成するには、次の手順を使用します。

1. コンテンツ・サーバーで、JSPページで使用する新しいセキュリティ・グループ(以降の手順ではjspと呼びます)を作成します。このセキュリティ・グループは、開発者に限定する必要があります。この手順は、必須ではありませんが、開発者の便宜のために実行することをお薦めします。JSPに対して有効にするすべてのセキュリティ・グループは、手順5で指定する必要があります。

1. 「ユーザー管理」画面を表示します。

2. 「セキュリティ」メニューで、「グループの権限」を選択します。

3. 「グループの追加」をクリックします。

4. グループ名としてjspを入力し、説明を入力して、「OK」をクリックします。

5. 管理者ロールおよび任意の開発者ロールに管理者権限を割り当てます。

6. 管理者以外のすべてのロールに読取り権限を割り当てます。

7. 「閉じる」をクリックします。

2. AIX、HP-UXまたはLinux s390上で実行している場合、Java 2 SDK(JSP統合で必要です)は、システムに自動的にインストールされることはなく、配布媒体でも提供されません。内部JSPエンジンをこれらのオペレーティング・システムのいずれかで実行するには、1.5 JDKがサーバーに存在しており、intradoc.cfgファイル内のCLASSPATH値がtools.jarファイルへのパスを含むように変更されている必要があります。たとえば、AIX上のデフォルトの1.5インストールの場合、このファイルは、/usr/java15/libに存在している必要があります。

3. 次のオプションのいずれかをクリックします。

- 「管理サーバー」ページで、「一般構成」をクリックします。

- システム・プロパティ・ユーティリティで、「サーバー」タブをクリックします。

4. JSPプロンプトを有効にします。

- 管理サーバーの場合、「Java Server Page(JSP)の有効化」をクリックします。

- システム・プロパティの場合、「Java Server Page(JSP) の実行」をクリックします。

5. JSPに対して有効にするセキュリティ・グループを入力します(手順1で作成したセキュリティ・グループを含みます)。

6. 設定を保存し、コンテンツ・サーバーを再起動します。

20.3 サンプル・ページのロード

次の手順のいずれかを使用して、サンプル・ページをコンテンツ・サーバーにロードします。

- .warファイルをJSPセキュリティ・グループにチェックインします。WARファイルをチェックインする前に、他のコンテンツがJSPセキュリティ・グループにチェックインされていることを確認してください。

- 管理ページから「JSPサーバーWebアプリケーション管理者」を開始します。

21 IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス

この章では、IdcCommandユーティリティを使用して、他のアプリケーションからOracle WebCenter Content Serverサービスにアクセスする方法について説明します。

この章では、次の項目について説明します。

- 第21.1項「IdcCommandユーティリティについて」

- 第21.2項「IdcCommandの設定」

- 第21.3項「IdcCommandの実行」

- 第21.4項「ランチャの使用」

- 第21.5項「リモートでのサービスのコール」

21.1 IdcCommandユーティリティについて

IdcCommandユーティリティは、コンテンツ・サーバー・サービスを実行するスタンドアロンのJavaアプリケーションです。コンテンツ・サーバーのブラウザ・インタフェースまたは管理アプレットから実行可能なほとんどのアクションは、IdcCommandから実行できます。

プログラムは、サービス・コマンドおよびパラメータを含むコマンド・ファイルを読み取り、指定されたサービスをコールします。ログ・ファイルには、コールの実行時間、サービスの実行の成否および実行エラーの有無を記録できます。

注意:
IdcCommandユーティリティは、コマンドの成否に関する情報のみを返します。対話型セッションでOracle WebCenter Content Serverから情報を取得するには、Microsoft Windowsプラットフォームで使用可能なJava COMラッパーIdcCommandXを使用します。

IdcCommandユーティリティを実行するには、コマンドラインまたはintradoc.cfg構成ファイルで次のパラメータを指定する必要があります。

- サービス・コマンドおよびパラメータを含むコマンド・ファイル

- コールされるサービスを実行する権限を持つユーザーのコンテンツ・サーバー・ユーザー名

- ログ・ファイルのパスおよびファイル名

- 接続モード(auto、serverまたはstandalone)

特定のコマンドは、standaloneモードでは実行できません。一般に、サーバーは、これらのコマンドをバックグラウンド・スレッドで非同期に実行します。これは、検索索引の更新または再構築で発生します。

カスタム・コンポーネントにおけるサービスの使用については、第9章「コンテンツ・サーバーのコンポーネントの開始」およびOracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

21.2 IdcCommandの設定

IdcCommandを設定するには、次の2つのものを指定する必要があります。

- コマンド・ファイル。実行するサービスおよびサービス・パラメータを指定します。

- 構成オプション。コマンド・ファイルおよび他のIdcCommand情報を指定します。IdcCommand構成オプションは、次の2か所で設定できます。

- 構成ファイルで、例21-1に示されているように、名前/値のペアを使用します。

例 21-1 構成ファイルにおけるIdcCommandオプション

IdcCommandFile=newfile.hda
IdcCommandUserName=sysadmin
IdcCommandLog=C:/domain/newlog.txt
ConnectionMode=server

- IdcCommandの実行時に、コマンドラインで、次のようなオプション・フラグを指定します。

例 21-2 コマンドラインにおけるIdcCommandオプション

-f newfile.hda -u admin -l C:/domain/newlog.txt -c server

注意:
コマンドライン構成オプションは、構成ファイル内の設定をオーバーライドします。

IdcCommandは、コマンドラインから実行されます。コマンドラインから、または構成ファイルで、構成オプションを指定できます。詳細は、第21.3項「IdcCommandの実行」を参照してください。

21.2.1 コマンド・ファイルの指定

コマンド・ファイルは、IdcCommandユーティリティによって実行されるサービス・コマンドおよびパラメータを定義します。コマンド・ファイルは、構文、優先順位、および特殊タグと特殊文字に関するルールに従う必要があります。

21.2.1.1 コマンド・ファイルの構文

コマンド・ファイルでは、HDA (ハイパーデータ・ファイル)構文を使用してサービス・コマンドを定義します。

- 実行する各サービスは、パラメータとともに@Properties LocalDataセクションに指定します。

- 一部のサービスについては、@ResultSetセクションを使用して追加情報を指定します。

- コマンド・ファイルの1つのセクションのデータは、次のセクションに持ち越されることはありません。セクションごとに、コマンドの完結したデータ・セットが含まれるようにする必要があります。

- サービス名およびパラメータでは、大/小文字が区別されます。

例21-3では、ADD_USERサービスを実行し、2人の新規ユーザーの属性を定義するコマンド・ファイルを示します。

例21-3 ADD_USERサービスのコマンド・ファイル

<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?>
# Add users
@Properties LocalData

IdcService=ADD_USER
dName=jsmith
dUserAuthType=Local
dFullName=Jennifer Smith
dPassword=password
dEmail=email@example.com
@end
@ResultSet UserAttribInfo
2
dUserName
AttributeInfo
jsmith
role,contributor,15
@end
<<EOD>>
@Properties LocalData
IdcService=ADD_USER
dName=pwallek
dUserAuthType=Local
dFullName=Peter Wallek
dPassword=password
dEmail=email@example.com
@end
@ResultSet UserAttribInfo
2
dUserName
AttributeInfo
pwallek
role,contributor,15,account,marketing,7
@end
<<EOD>>

21.2.1.2 優先順位

IdcCommandでは、優先順位を使用して、コマンド・ファイルのLocalDataセクション内の名前/値のペア間の競合を解決します。標準の名前/値のペアが解析される場合、それらは@Properties LocalDataタグ内にあると想定されます。セクションにHDAタグが含まれる場合、標準の名前/値のペアは、@Properties LocalDataタグ内の名前/値のペアに優先します。

たとえば、foo=xが標準の名前/値のペアであり、foo=yが@Properties LocalDataタグ内にある場合、foo=xという名前/値のペアがタグ外にあるため、このペアが優先されます。

21.2.1.3 特殊タグと特殊文字

次の特殊タグと特殊文字は、コマンド・ファイルで使用できます。

特殊文字

説明

IdcService=service_name

コマンド・ファイルの各セクションには、コールするサービスの名前を指定する必要があります。

<<EOD>>

データ終了マーカー。コマンド・ファイルには、1つ以上のセクションを、データ終了マーカーで区切って含めることができます。例については、第21.2.1.1項「コマンド・ファイルの構文」を参照してください。

#

行の先頭にあるシャープ文字は、その行がコメントであることを示します。

\

バックスラッシュは、エスケープ文字です。

@Include filename

このタグを使用すると、@Includeタグがある場所に別のファイルのコンテンツをインクルードできます。このタグは、HDAファイル全体または共有の名前/値のペアのインクルードに使用できます。このインクルードでは、指定されたファイルのコンテンツがそのまま取得され、@Includeタグの場所に配置されます。ファイルは、必要な回数だけインクルードでき、インクルードされるファイルに他のファイルをインクルードすることも可能です。ただし、循環インクルードは許可されていません。

21.2.2 構成オプションの指定

IdcCommandユーティリティを実行するには、コマンドラインまたはDomainHome/ucm/cs/bin/intradoc.cfg構成ファイルで次のパラメータを指定します。

パラメータ

必須かどうか

コマンドラインの構文

構成ファイルの構文

コマンド・ファイル

あり

-f name.txt

IdcCommandFile=name.txt

ユーザー

あり

-u sysadmin

IdcCommandUserName=sysadmin

ログ・ファイル

なし

-l C:/logs/log.txt

IdcCommandLog=C:/logs/log.txt

接続モード

なし

-c auto

ConnectionMode=auto

注意:
コマンドライン構成オプションは、構成ファイル内の設定をオーバーライドします。

21.2.2.1 コマンド・ファイル

サービス・コマンドおよびパラメータを含むコマンド・ファイルの名前を指定する必要があります。コマンド・ファイル・パラメータには、フルパス(C:/command_files/command.txtなど)、または相対パスを指定できます。詳細は、第21.2.1項「コマンド・ファイルの指定」を参照してください。

21.2.2.2 ユーザー

Oracle WebCenter Content Serverのユーザー名を指定する必要があります。このユーザーには、コールされるサービスを実行するための権限が必要です。

21.2.2.3 ログ・ファイル

IdcCommandログ・ファイルのパスおよびファイル名を指定できます。各コマンドが実行されると、メッセージがログ・ファイルに送信されます。ログ・ファイルには、コマンドの実行時間および成功または失敗のステータスが記録されます。ログ・ファイルがすでに存在する場合は、新しいメッセージで上書きされます。ログ・ファイルを使用して、処理に関する情報をユーザーに表示することができます。

- 実行されたアクションが成功した場合は、成功を示すメッセージがログ・ファイルに書き込まれます。

- 実行されたアクションが失敗した場合は、エラー・メッセージがログ・ファイルに書き込まれます。

- ログ・ファイルが指定されていない場合、情報は画面にのみ表示されます。

21.2.2.4 接続モード

IdcCommandサービスを実行するための接続モードを指定できます。

接続モード

説明

auto

IdcCommandは、Oracle WebCenter Content Serverインスタンスへの接続を試行します。これが失敗すると、サービスはスタンドアロン・モードで実行されます。
これは、デフォルトの接続モードです。

server

IdcCommandは、コンテンツ・サーバーを通じてのみサービスを実行します。

standalone

IdcCommandは、スタンドアロン・セッションでサービスを実行します。
スタンドアロン・モードでは実行できない特定のサービスがあります。一般に、これらのサービスは、サーバーによってバックグラウンド・スレッドで非同期に実行されます。これは、たとえば、検索索引の更新または再構築の際に発生します。

21.3 IdcCommandの実行

IdcCommandを実行する手順は次のとおりです。

1. 新しいIdcCommand作業ディレクトリを作成します。
このディレクトリは、コマンド・ファイルおよび構成ファイルに使用します。

2. 作業ディレクトリにコマンド・ファイルを作成して、必要なサービス・コマンドを指定します。

3. intradoc.cfg構成ファイルをDomainHome/ucm/cs/binディレクトリから作業ディレクトリにコピーします。

重要:
IntradocDirまたはWebBrowserPathの情報を削除しないでください。

4. 例21-4に示されているように、IdcCommandオプションを作業ディレクトリ内のintradoc.cfgファイルに追加します。

例21-4 intradoc.cfgファイルにおけるIdcCommandオプション

IdcCommandFile=newfile.hda
IdcCommandUserName=sysadmin
IdcCommandLog=C:/domain/newlog.txt

詳細は、第21.2.2項「構成オプションの指定」を参照してください。

5. DomainHome/ucm/cs/binディレクトリからIdcCommandユーティリティを実行します。

IdcCommand.exe

21.4 ランチャの使用

ランチャは、Windows環境でのサービスの管理やJava VMのコマンドライン引数および環境設定の構成に使用されるネイティブのC++アプリケーションです。

ランチャの主な動作は、構成ファイルを検出して読み取り、特殊な値を計算した後、構成したコマンドラインで実行可能ファイルを起動することです。構成ファイルは、Bourne Shellのような置換をサポートしています。置換はすべてドル記号($)で始まり、英数字の識別子または中カッコ({})で囲まれた式が続きます。

ランチャ実行可能ファイルは、
DomainHome/ucm/native/platform/bin/Launcherにインストールされます。UNIXシステムでは、Launcher.sh(ランチャ実行可能ファイルを実行するBourne Shellラッパー)へのシンボリック・リンクがbinディレクトリに作成されます。このラッパーの目的は、プラットフォームに適したバイナリのランチャ実行可能ファイルを見つけることです。ランチャという用語は、ここでは、ネイティブのランチャ実行可能ファイルまたはBourne ShellスクリプトLauncher.shを指すために使用されます。

ランチャまたはLauncher.shへのシンボリック・リンクは、有効なintradoc.cfg構成ファイルがあるディレクトリ内に存在し、起動されるJavaクラス・ファイルと同じ名前(大/小文字を区別)である必要があります。ランチャは、この名前を使用して環境変数STARTUP_CLASSを設定します。

Windowsでは、この名前は、GetModuleFileName()をコールして計算されます。UNIXシステムでは、argv[0]を調べて計算されます。PLATFORM変数は、プラットフォームのコンテンツ・サーバー識別子に設定されます。BIN_DIR変数は、ランチャがあるディレクトリに設定されます。

ランチャは、BIN_DIRからintradoc.cfgという名前のファイルを読み取ります。このファイルには、IntradocDirの値が含まれています。IntradocDirディレクトリは、相対パスを解決するためのベース・ディレクトリとして使用されます。このドキュメントでの非修飾パスはすべて、IntradocDirに対して相対的であるとみなされます。コンテンツ・サーバーの将来のリリースでは、これらの変数名は変更または削除される可能性があります。

intradoc.cfgファイルにIdcResourcesDirの値が含まれていない場合、ランチャによって、IdcResourcesDirが$IntradocDir/resourcesに設定されます。ランチャがWindowsサービスを起動する場合、IS_SERVICEは1に設定されます。また、設定されていない場合は、PATH_SEPARATORがプラットフォームに適した文字に設定されます。

ランチャは、まずintradoc.cfgファイルを読み取って構成ファイルの場所を検索し、次に使用可能なすべての構成ファイルを次の順番で読み取ります。

1. $IdcResourcesDir/core/config/launcher.cfg

2. $BIN_DIR/../config/config.cfg

3. $IntradocDir/config/config.cfg

4. $IntradocDir/config/config-$PLATFORM.cfg

5. $IntradocDir/config/state.cfg

6. $IdcResourcesDir/core/config/launcher-$PLATFORM.cfg

7. $BIN_DIR/intradoc.cfg

8. $BIN_DIR/intradoc-$PLATFORM.cfg

9. -cfgオプションを使用してコマンドラインに指定されたすべてのファイル

ヒント:
-cfgオプションNAME=VALUEを使用して、コマンドラインで直接、変数値を割り当てることができます。

21.4.1 引用符のルール

ランチャは、Bourne Shellのような引用符のルールを使用します。文字列を二重引用符(")で囲むと、空白をエスケープできます。バックスラッシュ(\)を任意の文字の前に置くと、その文字そのものを指定できます。最終的なコマンドラインが計算されると、ランチャは、そのコマンドラインを引用符なしの空白ごとに区切ります。その後、各文字列は、コマンドのargv配列のエントリとして引用符なしで使用されます。

21.4.2 計算される設定

構成ファイルを読み取った後、ランチャは、変数置換を処理します。一部の変数では、ディレクトリまたはファイルを検証する、コマンドライン引数リストを作成する、PATHのような変数を構成するなどの追加の計算を行うことができます。

これらの特殊な計算は、変数に対してそのタイプに基づいて実行されます。変数のタイプを設定するには、前述のどの構成ファイルでもTYPE_variable_name=typenameを設定します。

ランチャの変数タイプは次のとおりです。

- file
例21-5では、fileタイプの変数を示します。

例21-5 fileランチャ変数

TYPE_PASSWD_FILE=file
PASSWD_FILE_sys5=/etc/passwd
PASSWD_FILE_bsd=/etc/master.passwd

このタイプは、ファイルを検索します。variable_nameの値が既存ファイルへのパスである場合は、その値が保存されます。そうでない場合は、variable_name_で始まるすべての変数がチェックされます。既存ファイルへのパスである最後の値が、variable_nameの新しい値に使用されます。

この例では、PASSWD_FILEは、/etc/master.passwdが存在する場合は/etc/masterに設定され、/etc/passwdが存在する場合は/etc/passwd</span>に設定されます。それ以外の場合、PASSWD_FILEは定義されません。

- directory
例21-6では、directoryタイプの変数を示します。

例21-6 directoryランチャ変数

TYPE_JDK=directory
JDK_java_home=$JAVA_HOME
IdcNativeDir=$IdcHomeDir/native
DEFAULT_JDK_DIR=$OS_DIR/$PLATFORM
JDK_legacy142=$DEFAULT_JDK_DIR/j2sdk1.4.2_04
JDK_default=$DEFAULT_JDK_DIR/jdk1.5.0_07

この例では、JDKは、ディレクトリを示す最後のJDK_変数と同じ値に設定されます。通常これは、Oracle Fusion MiddlewareとともにインストールされたJDKを指します。JDK_java_homeは$JAVA_HOMEを参照することに注意してください。変数がどの構成ファイルにも定義されておらず、環境に定義されている場合は、環境の値が使用されます。

- executable
例21-7では、executableタイプの変数を示します。

例21-7 executableランチャ変数

TYPE_JAVA_EXE=executable
JAVA_EXE_default=java$EXE_SUFFIX
JAVA_EXE_jdk_default=$JDK/bin/java$EXE_SUFFIX

executableタイプは、実行可能ファイルを検索します。これは、fileタイプと非常によく似た動作をしますが、各候補値について$PATH内のすべてのディレクトリを調べます。この例では、JAVA_EXEは、JDK内のJava実行可能ファイルが存在する場合は、そのファイルに設定されます。それ以外の場合は、PATH内の最初のJava実行可能ファイルに設定されます。

- list
例21-8では、listタイプの変数を示します。

例21-8 listランチャ変数

TYPE_JAVA_OPTIONS=list
JAVA_MAX_HEAP_SIZE=384
DEFINE_PREFIX=-D
JAVA_OPTIONS_BIN_DIR=${DEFINE_PREFIX}idc.bin.dir=$BIN_DIR
JAVA_OPTIONS_maxheap=${JAVA_MAX_HEAP_SIZE+-Xmx${JAVA_MAX_HEAP_SIZE\}m}
JAVA_OPTIONS_service=${IS_SERVICE+$JAVA_SERVICE_EXTRA_OPTIONS}

listタイプは、実行可能ファイルのオプションのリストを計算します。variable_name_で始まる各値が引用符付きのオプションになり、variable_nameにはリスト全体が設定されます。この例では、JAVA_OPTIONSは次の文字列に設定されます。

"-Didc.bin.dir=/intradocdir/bin/" "-Xmx384m"

- path
例21-9では、pathタイプの変数を示します。

例21-9 pathランチャ変数

IdcResourcesDir=${IdcResourcesDir-$IdcHomeDir/resources}
BASE_JAVA_CLASSPATH_source=$IdcResourcesDir/classes
BASE_JAVA_CLASSPATH_serverlegacy=$SharedDir/classes/server.zip
BASE_JAVA_CLASSPATH_server=$JLIB_DIR/idcserver.jar

pathタイプは、パスのような値を計算します。variable_name_で始まる各変数の値が、PATH_SEPARATORの値で区切られてvariable_nameに追加されます。この例では、BASE_JAVA_CLASSPATHは、非常に長いクラスパスに設定されます。

- lookupstring
例21-10では、lookupstringタイプの変数を示します。

例21-10 lookupstringランチャ変数

TYPE_VDK_PLATFORM=lookupstring
PARAMETER_VDK_PLATFORM=${PLATFORM}_${UseVdkLegacySearch+vdk27}
VDK_PLATFORM_aix_vdk27=_rs6k41
VDK_PLATFORM_aix_=_rs6k43
VDK_PLATFORM_hpux_vdk27=_hpux11
VDK_PLATFORM_hpux_=_hpux11
VDK_PLATFORM_freebsd_vdk27=_ilnx21
VDK_PLATFORM_freebsd_=_ilnx21
VDK_PLATFORM_linux_vdk27=_ilnx21
VDK_PLATFORM_linux_=_ilnx21
VDK_PLATFORM_solaris_vdk27=_ssol26
VDK_PLATFORM_solaris_=_ssol26
VDK_PLATFORM_win32_vdk27=_nti40
VDK_PLATFORM_win32_=_nti40

lookupstringタイプは、2番目のパラメータを使用して最終的な値の検索キーを構成します。2番目のパラメータとは、$PARAMETER_variable_nameの値です。この値が定義されていない場合は、variable_nameの現在の値が検索キーとして使用されます。この例では、PARAMETER_VDK_PLATFORMは、UseVdkLegacySearchの値に応じて、${PLATFORM}_または${PLATFORM}_vdk27の値となります。

この値はその後、変数VDK_PLATFORM_${PARAMETER_VDK_PLATFORM}の値の検索に使用されます。検索された値は、引用符で囲まれてVDK_PLATFORMに割り当てられます。

- lookuplist
例21-11では、lookuplistタイプの変数を示します。

例21-11 lookuplistランチャ変数

TYPE_STARTUP_CLASS=lookuplist
STARTUP_CLASS_version=Installer --version
STARTUP_CLASS_installer=Installer
STARTUP_CLASS_WebLayoutEditor=IntradocApp WebLayout
STARTUP_CLASS_UserAdmin=IntradocApp UserAdmin
STARTUP_CLASS_RepositoryManager=IntradocApp RepositoryManager
STARTUP_CLASS_Archiver=IntradocApp Archiver
STARTUP_CLASS_WorkflowAdmin=IntradocApp Workflow
STARTUP_CLASS_ConfigurationManager=IntradocApp ConfigMan

lookuplistタイプは、2番目のパラメータを使用して最終的な値の検索キーを構成します。2番目のパラメータとは、$PARAMETER_variable_nameの値です。この値が定義されていない場合は、variable_nameの現在の値が検索キーとして使用されます。

lookupstringとは異なり、lookuplistは、最終的な値を引用符で囲みません。この例では、STARTUP_CLASSの現在の値はversionです。STARTUP_CLASSは、Installer --versionという値に置き換えられます。

21.4.3 ランチャの環境変数

計算される設定の処理後、ランチャは、文字列EXPORT_で始まるすべての変数に対して繰り返し適用されます。各変数の値は、環境変数の名前として使用されます。環境変数の名前には、EXPORT_変数の後半の値が割り当てられます。たとえば、EXPORT_IDC_LIBRARY_PATH=LD_LIBRARY_PATHは、IDC_LIBRARY_PATH変数の値をLD_LIBRARY_PATHという名前でエクスポートします。

変数JAVA_COMMAND_LINEは、コマンドラインの取得に使用されます。使用されていないランチャに対するコマンドライン引数はすべて、コマンドラインに追加されます。UNIXシステムでは、コマンドラインが解析され、引用符は付けられず、execvがコールされます。Windowsでは、シャットダウンのミューテックスが作成され、CreateProcessがコマンドラインを使用してコールされます。CreateProcessではバックスラッシュを付ける処理を元に戻すことはできないため、注意する必要があります。

ランチャをデバッグするための主な方法は、最終的なコマンドの引数の前に-debugフラグを追加することです。$BIN_DIR/debug.logというファイルを作成することもできます。このファイルは、デバッグ・モードをトリガーしてデバッグ出力を格納します。

ランチャは、動作を制御するために設定または使用される次の構成エントリを認識します。これらの構成変数は、コンテンツ・サーバーの将来のリリースで変更または削除される可能性があることに注意してください。

- IDC_SERVICE_NAME: サービスの登録、登録解除、起動および停止に使用されるwin32サービスの名前。

- IDC_SERVICE_DISPLAY_NAME: サービスの登録に使用されるwin32の表示名。

- IntradocDir: 相対パス名のベース・ディレクトリ。

- IdcBaseDir: IntradocDirの代替名。

- IdcResourcesDir: 特に定義されていない場合は、$IdcHomeDir/resourcesに設定されます。

- IdcNativeDir: 特に設定されていない場合は、デフォルトで$IdcHomeDir/nativeに設定されます。

- PATH_SEPARATOR: 特に設定されていない場合は、コロン(:)またはセミコロン(;)のいずれかに設定されます。

- STARTUP_CLASS: ランチャ実行可能ファイルの名前に設定されます。

- MUTEX_NAME: win32でシャットダウンのミューテックスを作成するために使用される名前。

- BEFORE_WIN_SERVICE_START_CMD: 設定された場合、win32サービスの起動前に実行されるコマンドラインになります。

- UseRedirectedOutput: 設定された場合、win32上のランチャにJava VMからの出力をファイルにリダイレクトするように指示します。

- ServiceStartupTimeout: Javaプロセスがwin32で正常に起動するのを待機するために使用されるタイムアウト。

ヒント:
Launcher.exeを使用してstatus.datファイルを変更し、JVMコマンドラインの値を変更すると、理論上は、どのJavaプログラムもWindowsサービスとして実行できます。この方法は、通常の使用にはお薦めしませんが、こうすることで、ランチャのいくつかの構成方法が明らかになります。

21.4.4 ユーザー・インタフェース

ランチャのUIは、起動するアプリケーションと同じです。たとえば、ランチャの名前をIntradocAppに変更した場合、Webレイアウト・エディタを起動するには、次のコマンドライン引数を指定します。

IntradocApp WebLayout

これにより、Webレイアウト・エディタは、スタンドアロン・アプリケーションとして起動されます。

デフォルトでは、アプリケーションはコンソール出力なしの状態で起動されます。ただし、IdcServer、IdcAdmin、IdcCommandXまたはInstallerを起動すると、Java出力が画面に表示されます。その他の場合はすべて、出力はクリーナ・インタフェースに対して表示されません。

バッチ・ローダーやリポジトリ・マネージャなど、アプリケーションによっては、アプリケーションからのJava出力を表示するほうが望ましいものがあります。ランチャがJava出力を画面にダンプするようにするには、次のように-consoleフラグを使用します。

IntradocApp RepMan -console

これで、リポジトリ・マネージャの起動元のコンソールに出力が書き込まれます。

ランチャの名前をIdcServer、BatchLoader、SystemProperties、または追加パラメータを必要としないその他の任意のJavaクラスに変更すると、ダブルクリックするだけで起動できます。その他の場合は、ショートカットを使用すると、ダブルクリックで起動できます。

21.4.5 ランチャの構成

ランチャを使用するには、まず、Launcher.exeファイルの名前を変更して、起動するクラス・ファイルと同じ名前の実行可能ファイルにします。一般的な例としては、IdcServer.exeやIntradocApp.exeなどがあります。

注意:
カスタム・アプリケーションを作成する場合、カスタム・ディレクトリを作成し、Launcher.exeファイルの名前を、起動するサービスに変更する必要があります。有効なintradoc.cfgファイルが実行可能ファイルと同じディレクトリに存在している必要があります。必須パラメータはIntradocDirのみです。ただし、他のエントリを追加してJavaアプリケーションの起動方法を変更できます。

21.4.6 構成ファイルの例

実行する必要のあるアプリケーションの構成ファイルを変更できます。例21-12に、ほぼすべてのコンテンツ・サーバー・アプリケーションを起動するのに十分な構成ファイルのエントリを示します。

例21-12 コンテンツ・サーバー・アプリケーションの構成ファイルのエントリ

<?cfg jcharset="Cp1252"?>
#Content Server Directory Variables
IntradocDir=C:/domain/idcm1/
BASE_JAVA_CLASSPATH_source=$IdcResourcesDir/classes
BASE_JAVA_CLASSPATH_serverlegacy=$SharedDir/classes/server.zip
BASE_JAVA_CLASSPATH_server=$JLIB_DIR/idcserver.jar

Oracle WebCenter Content: Inbound Refineryなどの他のアプリケーションでは、クラスパスにクラスを追加する必要があります。このファイルを変更して、別のJava仮想マシンを使用してコンテンツ・サーバーを実行できるようにすることも可能です。

CLASSPATHは、リストされたエントリの順にクラス・ファイルを検索するように設計されています。つまり、ランチャは、DomainHome/ucm/idc/nativeディレクトリ全体を検索してから、resourcesディレクトリまたはserver.zipファイル内を調べます。これは、ZIPファイルにパッチを適用せずにJavaクラスをオーバーロードする場合に適しています。

さらに、Javaアプリケーションがランチャとの通信に適したAPIに準拠している場合は、ランチャを使用して、Javaアプリケーションのインストール、アンインストールおよび実行をWindowsサービスとして行うことができます。ランチャを使用してJavaアプリケーションをWindowsサービスとして実行できるようにする方法の詳細は、IdcServer.javaまたはIdcAdmin.javaのソース・コードを参照してください。

COMPUTEDCLASSPATHは、ランチャが使用するCLASSPATHにクラス・ファイルを追加するために使用されます。クラス・ファイルを追加するには、このフラグをオーバーライドします。

注意:
intradoc.cfgファイルは通常、インストール時に、特定のデータベースに対するJDBCドライバの場所を含むように変更されます。別のJDBCドライバを使用する場合は、ドライバをコンテンツ・サーバーのIdcHomeDirディレクトリの外部(IntradocDir)に配置し、intradoc.cfgファイル内のJDBC_JAVA_CLASSPATH_customjdbcエントリをドライバの場所に変更します。

例21-13では、Windowsオペレーティング・システム上でIBM仮想マシンを使用してコンテンツ・サーバーを実行するコマンドを示します。

例21-13 カスタムJVMを使用してコンテンツ・サーバーを実行するためのコマンド

#customized for running the IBM VM
JAVA_EXE=full path

カスタムJVMを使用する場合は、使用するJava実行可能ファイルへのフルパスを指定します。

注意:
JVMコマンドラインのオーバーライドは避けてください。カスタム・クラス・ローダーのため、カスタマイズはより複雑なものになります。JVMコマンドラインをオーバーライドする場合は、$IdcHomeDir/resources/core/config/launcher.cfgファイルから始めます。

構成ファイル内のJAVA_COMMAND_LINE_SELECTIONエントリは、idcclassloaderまたはtraditionalに設定できます。

使用しているJVMを変更するとき、そのJVMにすべての標準Sun SDK JARファイルがある場合は、J2SDK構成エントリを使用してSDKディレクトリのルート・ディレクトリを再配置する方が、JAVA_EXEを使用してJava実行可能ファイルの場所を指定する(この方法はIBM VMには適用できません)よりも適切です。

J2SDK変数は、Sun SDKライブラリ(tools.jarなど)があるディレクトリを変更します。JAVA_EXEエントリを設定せずにこのエントリを変更すると、Java実行可能ファイルはJ2SDKのパスのbinディレクトリ内にあるとみなされます。J2SDKのデフォルト値は、...\shared\os\win32\j2sdk1.4.2_04です。

JAVA_OPTIONSに値を追加するには、JAVA_OPTIONS_server=-serverまたは別の同様の値を使用します。

次の表に、一般に使用されるコマンドライン・オプションを示します。アスタリスク(*)が付けられたオプションは、Windows オペレーティング・システムでのみ使用できます。マークが付けられていないオプションは、WindowsまたはUNIXオペレーティング・システムで使用できます。

オプション

説明

-console

*   Java出力およびエラー・ストリームがコンソールに表示されるように、Windowsコンソール・ウィンドウを開いたままにするようランチャに指示します。

-debug

起動時に使用されたパスと変数、および起動時のエラーを表示します。また、これが繰り返された場合は、コンテンツ・サーバーでのJavaデバッグを可能にします。これにより、詳細レベルが上がります。

-fileDebug

-debugオプションと似ていますが、このオプションは、デバッグ・データをデバッグ・ログ・ファイルにダンプします。これは通常、Windowsサービスをデバッグするために、intradoc.cfgファイルのJAVA_OPTIONSまたはJAVA_SERVICE_EXTRA_OPTIONSでのみ設定されます。

-install

*   ランチャによってWindowsサービスとしてみなされるJavaアプリケーションをインストールするために使用されます。

-install_autostart

*    -installオプションと似ていますが、このオプションは、サーバーの起動時に起動するアプリケーションをインストールします。

-uninstall

*   ランチャによってWindowsサービスとしてみなされるJavaアプリケーションをアンインストールするために使用されます。

-remove

*   -uninstallと同じです。

-dependent service-name

*   Windowsサービスが、service-nameサービスも実行されているかどうかに依存するようにします。
このコマンドは、サービスごとに依存コールを行う場合に便利です。

たとえば、コンテンツ・サーバーの起動前にデータベースが起動されるようにする場合、コンテンツ・サーバーの起動がデータベースの起動に依存するように指定できます。

-dependent user password

*   -installとともに使用され、userによって指定されたユーザーの資格証明とパスワードpasswordを使用してサービスをインストールします。
このコマンドは、資格証明に関係なくユーザーをチェックしますが、サービスをインストールしないことがあります。自動起動によってサービスが自動的に実行されるように、ユーザーの資格証明をサービスにまで拡張する必要があります。

Inbound Refineryなどの特定のサービスには、サービスがより高い権限で実行されるようにするために最後のフラグが必要です。ユーザー名は、一般的なMicrosoft形式であるDOMAIN\Userにする必要があります。ユーザーがパスワードを変更すると、サービスは、ログインできなくなるため、実行されません。

-help

ランチャの使用に関する詳細な情報を表示します。

-version

ランチャのバージョン番号を表示して終了します。

-asuser user password

*   インストール時に、指定されたpasswordを持つ指定されたuserとしてサービスをインストールするために使用されます。

-exec path _name

argv[0]の設定をオーバーライドします。シンボリック・リンクのターゲットはソースを認識しないため、ターゲットのpath_nameを指定するためにLauncher.shによって使用されます。

-cfg configfilename

計算される設定を特定する前に読み取る、追加の構成ファイルを指定します。

-idcServiceName servicename

*   Windowsサービスの名前を指定します。これは、(たとえば、インストール・ディレクトリ全体が削除された場合に)-removeとともに使用して、コンテンツ・サーバーのランチャを使用せずに別のコンテンツ・サーバー・サービスをアンインストールできます。

ヒント:
クラスパスをカスタマイズして、Oracle .dllファイルをロードするようにシステム・パスを変更するには、次のようにパスを設定します。

IDC_LIBRARY_PATH_customfiles=/path-to-customfiles

カスタムの共有オブジェクトおよび.dllファイルは、IdcHomeDirにインストールしないでください。

カスタムの.dllファイルをロードする場合は、それらをIdcHomeDir/native/win32/libディレクトリに配置します。

21.5 リモートでのサービスのコール

リモートでサービスを使用するには、リモート・システムに次のファイルが必要です。

- DomainHome/ucm/cs/bin/IdcCommand.exe

- DomainHome/ucm/cs/bin/intradoc.cfg (Oracle WebCenter Content Server上のファイルと同じ)

- IntradocDir/config/config.cfg

さらに、リモート・システム上のconfig.cfgファイルの#Additional Variablesセクションに、次の構成エントリを定義する必要があります。

- IntradocServerPort=4444

- IntradocServerHostName=IP or DNS

22 統合のためのCOM APIの使用

この章では、Microsoft Component Object Model (COM)統合について説明します。Oracle WebCenter Content Serverは、COM環境内から機能をコールする機能を提供する、COMベースのAPIを使用します。

この章では、次の項目について説明します。

- 第22.1項「COM APIについて」

- 第22.2項「IntradocClient OCXコンポーネントを使用したコンテンツ・サーバー・サービスのコール」

- 第22.3項「ODMA APIを使用した、デスクトップ・アプリケーションからコンテンツ・サーバーへのアクセス」

22.1 COM APIについて

COMインタフェースを使用して、コンテンツ管理をMicrosoft環境およびアプリケーションと統合できます。コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスするためのインタフェース・オプションとして、ActiveXコントロールおよびOCXコンポーネントが提供されています。さらに、COMインタフェースを通じてODMA対応アプリケーションと通信できます。

22.2 IntradocClient OCXコンポーネントを使用したコンテンツ・サーバー・サービスのコール

リモートのOracle WebCenter Content Serverインスタンスに接続し、コンテンツ・サーバー・サービスを実行するために、Object Linking and Embedding Control Extension (OCX)コントロールが提供されています。IdcClient OCXコントロールは、コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスするために、Windows Visual Basic開発環境内で使用されます。

IdcClient OCXコントロールを使用してコンテンツ・サーバー・サービスをコールすることができます。IdcClient.ocxコントロールは、リモートのOracle WebCenter Content Serverインスタンスに接続し、標準的なサーバー機能を実行するために使用されます。

注意:
IdcClient OCXコンポーネントを使用するには、Visual BasicまたはVisual C++開発環境が必要です。

22.2.1 OCXインタフェース

IntradocClient OCXコンポーネントは、コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスするために、Windows Visual Basic開発環境内で使用されます。OCX統合は、ビジュアル開発環境でサービスをコールするように、またはリモートのOracle WebCenter Content Serverインスタンスに接続するように設計されています。

IntradocClient OCXコンポーネントは、メソッド・コールを使用してアクセス可能な機能を提供します。メソッドはアクションを実行し、多くの場合、結果を返します。情報は、パラメータを使用してメソッドに渡されます。関数には、パラメータをとらないもの、パラメータを1つとるもの、複数のパラメータをとるものがあります。

IntradocClient OCXコンポーネントでは、コマンドの実行にユーザー名とパスワードが必要です。ユーザーには、コマンドを実行するための適切な権限が必要です。管理者アクセス・レベルを必要とするコマンドもあれば、書込み権限のみを必要とするコマンドもあります。

initおよびconnection管理メソッドを除き、すべてのメソッドは、通信のために、シリアル化されたHDAフォーマットを使用します。返された、シリアル化されたHDAフォーマットの文字列には、コマンドの成否に関する情報が含まれています。障害が発生した場合、StatusCodeは負の値になり、StatusMessageにエラーが示されます。

詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。このガイドには、IntradocClient OCX API仕様に関する情報も含まれており、プロパティ、メソッドおよびイベントの説明が記載されています。

22.2.2 IdcClient OCXの説明

IdcClientは、サービスの実行やファイル・パス情報の取得などのアクションをプログラムで実行できるようにするActiveXコントロールです。IdcClientコントロールは、Microsoft Internet Explorerブラウザのラッパーでもあります。

IdcClient OCXコントロールは、Unicode規格を使用するように設計されており、ほとんどの場合、UTF-8形式でOracle WebCenter Content Serverとデータを交換します。Unicodeは、1文字当たり2バイト(16ビット)のストレージを使用し、様々な言語(英語、日本語、アラビア語など)で使用される文字を表すことができます。英語のASCII(情報交換用米国標準コード)文字は1バイト(8ビット)しか必要としないため、ASCII文字では、各Unicode文字の上位バイトがゼロで表されます。

Unicode規格の詳細は、WebでUnicode Consortium(http://www.unicode.org)を参照してください。

重要:
IdcClient OCXは、Microsoft Layer for Unicodeの上に構築されており、Microsoft Layer for Unicodeによって、UnicodeアプリケーションをWin9xプラットフォームで実行することが可能になります。9xプラットフォーム上でIdcClient OCXコントロールを配布するときは、unicows.dllも配布する必要があります。このコンパニオンDLLは、Windowsベースのシステム上には配布できません。

ほとんどの場合、メソッドは、通信のために、シリアル化されたHDAフォーマットを使用します。シリアル化されたHDAフォーマットは、通信のために使用されるJavaメソッドです。返された、シリアル化されたHDAフォーマットの文字列には、コマンドの成否に関する情報が含まれています。

IdcClient OCXコントロールは、メソッド・コールを使用して実行可能な機能を提供します。メソッドはアクションを実行し、多くの場合、結果を返します。情報は、パラメータを使用してメソッドに渡されます。関数には、パラメータをとらないもの、パラメータを1つとるもの、複数のパラメータをとるものがあります。たとえば、文字列として渡される2つのパラメータを持つ関数は、次のフォーマットを使用します。

Function(Parameter As String, Parameter As String) As String

- ユーザーは、IdcClient OCXを使用して、サービスを実行するクライアント・アプリケーションを作成できます。OCXコントロールは、コマンドおよびパラメータを含む名前/値のペアを取得し、指定されたサービスをコールします。実行結果は、コール側プログラムに渡されます。

- IdcClient OCXでは、コマンドの実行にユーザー名とパスワードが必要です。ユーザーには、コマンドを実行するための適切な権限が必要です。管理者アクセス・レベルを必要とするコマンドもあれば、書込み権限のみを必要とするコマンドもあります。

詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

22.2.2.1 OCXイベント

イベントは、ユーザーまたはサーバーがアクションを実行すると実行されます。次に例を示します。

- IntradocBrowserPostイベントは、ユーザーがフォームをブラウザ内から送信するたびに実行されます。

- IntradocServerResponseイベントは、サーバーがリクエストされたアクションを完了すると実行されます。

22.2.2.2 OCXメソッド

Visual Basic標準コントロールは、すべてのVisual Basic開発環境に共通のメソッドを提供します。また、IdcClient OCXコントロールは、この特定のコントロールに固有のプライベート・メソッドを提供します。これらのメソッドは、特性の設定ではなく、アクションの実行または開始に使用されます。

次に例を示します。

- AboutBox()メソッドは、製品のバージョン情報を示す「バージョン情報」ボックスを起動します。

- GoCheckinPageメソッドは、新しいコンテンツ・アイテムまたはコンテンツ・アイテムのリビジョンをチェックインします。

22.2.2.3 OCXプロパティ

プロパティは、オブジェクトを記述またはフォーマットし、コードによって、またはVisual Basic開発環境でプロパティ・ウィンドウを使用して変更できます。プロパティは、オブジェクトの基本的な特性を記述します。

次に例を示します。

- UserNameプロパティは、割り当てられたユーザー名を指定します。

- WorkingDirプロパティは、ダウンロードされたファイルが格納される場所を指定します。

22.2.2.4 IdcClient OCXインタフェース

IdcClient OCXコントロールは、コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスするために、Windows Visual Basic開発環境内で使用されます。OCX統合は、ビジュアル開発環境でサービスをコールするように、またはリモートのコンテンツ・サーバー・インスタンスに接続するように設計されています。

ほとんどの場合、メソッドは、通信のために、シリアル化されたHDAフォーマットを使用します。返された、シリアル化されたHDAフォーマットの文字列には、コマンドの成否に関する情報が含まれています。障害が発生した場合、StatusCodeは負の値になり、StatusMessageにエラーが示されます。返されたHDAにStatusCodeパラメータが含まれていない場合、サービス・コールが成功したことを示しています。

22.2.3 IdcClient OCXコントロールの設定

Microsoft Visual Basic開発環境で、IdcClient OCXコンポーネントを設定し、ビジュアル・インタフェースを作成できます。

22.2.3.1 IdcClient OCXコンポーネントの設定

Microsoft Visual Basic開発環境で、IdcClient OCXコンポーネントを設定するには、次の手順を実行します。

1. 新規プロジェクトを作成します。

2. 「プロジェクト」を選択し、「コンポーネント」を選択します。

3. システムでIdcClient.ocxファイルを参照し、「開く」をクリックします。
IdcClientモジュールがコンポーネント・コントロール・リストに追加されます。

4. IdcClient ActiveX Controlモジュールのチェック・ボックスが選択されていることを確認し、「OK」をクリックします。
IdcClient OCXコントロールが、コントロールのリストに入ります。

5. (オプション) Visual Basic開発環境を使用してユーザー独自のビジュアル・インタフェースを構築できます。または、第22.2.3.2項「ビジュアル・インタフェースの作成」に記載されている手順に従って基本的なビジュアル・インタフェースを構築できます。

22.2.3.2 ビジュアル・インタフェースの作成

ビジュアル・インタフェースを作成するための次の手順は、Visual Basicプロジェクトが作成されており、IdcClient OCXコントロールがコントロールのリストに入っていることを前提としています。詳細は、第22.2.3.1項「IdcClient OCXコンポーネントの設定」を参照してください。

基本的なビジュアル・インタフェースを構築するには、次の手順を実行します。

1. コントロールを選択し、それをVisual Basicフォーム上に描画します。
図22-1は、IdcClient OCXコントロールを示しています。

図22-1 Visual Basicフォーム上に描画されたOCXコントロール

2. 「プロパティ」ウィンドウのドロップダウン・リストから、IdcClient OCXを選択します。
「プロパティ」ウィンドウが表示されていない場合は、メイン・メニューから「表示」→プロパティ・ウィンドウを選択します。

3. IdcClient OCXコントロールの名前をIdcClientCtrlに変更します。

4. 特定のインスタンスのiss_idc_cgi.dllを参照するようにHostCgiUrlを定義します。
次に例を示します。

http://testserver/intradoc-cgi/iss_idc_cgi.dll

図22-2では、HostCgiUrlの値としてこのURLが示されています。

図22-2 編集後のIdcClientのプロパティ

5. フォームで、テキスト・ボックスを描画し、CgiUrlという名前を付けます。

6. 「テキスト」フィールドに、表示されるテキストとしてHostCgiUrlの値(http://testserver/intradoc-cgi/iss_idc_cgi.dllなど)を入力します。
図22-3では、「テキスト」の値としてこのURLが示されています。

図22-3 編集後のCgiUrlテキスト・ボックスのプロパティ

7. フォームで、テキスト・ボックスを描画し、コマンドという名前を付けます。

8. 「テキスト」フィールドのエントリを消去(空白のままに)し、MultiLineをTrueに設定します。
図22-4では、MultiLineの値を示しています。

図22-4 編集後のコマンド・テキスト・ボックスのプロパティ

9. フォームで、テキスト・ボックスを描画し、レスポンスという名前を付けます。

10. 「テキスト」フィールドのエントリを消去(空白のままに)します。
図22-5は、レスポンス・テキスト・ボックスのフィールド値を示しています。

図22-5 編集後のレスポンス・テキスト・ボックスのプロパティ

11. フォームで、ボタンを描画し、SendPostCommandという名前を付けます。

12. 「キャプション」フィールドに、表示されるテキストとして「Postコマンドの送信」と入力します。
図22-6は、SendPostCommandボタンに表示される「キャプション」の値を示しています。

図22-6 編集後のSendPostCommand CommandButtonのプロパティ

13. フォームで、「表示」→コードを選択します。

14. ドロップダウン・リストから「SendPostCommand」→クリックを選択して、次のアクションを実行するようにコードを変更します。

- Host Cgi URLの値を設定する。

- コマンドを発行する。

- (オプション) LFをCRLFに置換して、編集コントロールでの表示が読みやすくなるようにする。

- レスポンスを表示する。

次のようにコードを変更します。

Dim R As String
IdcClientCtrl.HostCgiUrl = CgiUrl.Text
R = IdcClientCtrl.1.SendPostCommand(Command.Text)
R = Replace(R, vbLf, vbCrLf
Response.Text = R

図22-7は、コードの変更内容を示しています。

図22-7 編集後のSendPostCommand_Clickコード

15. ドロップダウン・リストから「フォーム」→「ロード」を選択し、次の行を追加してOracle WebCenter Content Serverインスタンスのログイン・プロンプトを設定します。

IdcClientCtrl.UseBrowserLoginPrompt = True
IdcClientCtrl.UseProgressDialog = True

図22-8は、変更後のコードを示しています。

図22-8 編集後のForm_Loadコード

16. (オプション) Cgi Url、「コマンド」、「レスポンス」など、適切な説明ラベルを追加します。
図22-9は、説明ラベルのあるフォームを示しています。

図22-9 説明ラベルのあるビジュアル・インタフェース

17. 「実行」→「起動」を選択して、ビジュアル・インタフェースをテストします。
図22-10は、テストが成功した場合の結果を示しています。

図22-10 完成したビジュアル・インタフェース

18. 「コマンド」フィールドに、書式設定済のコマンドを入力します。
図22-11は、ユーザーを追加するADD_USERコマンドを示しています。

ADD_USERサービスの詳細は、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

図22-11 コマンドが定義されたビジュアル・インタフェース

19. 「Postコマンドの送信」ボタンをクリックして、コマンドを実行します。返された結果が「レスポンス」フィールドに表示されます。
図22-12は、返された結果の一部を示しています。

図22-12 結果が返されたビジュアル・インタフェース

コマンドを検証する手順は次のとおりです。

1. Webブラウザで、Oracle WebCenter Content Serverに管理者としてログインします。

2. 「管理」トレイで、「管理アプレット」を選択します。

3. 「ユーザー管理」をクリックします。アプレットが起動し、追加されたユーザー(user99など)が表示されます。

22.2.4 IdcClientのイベント

イベントは、ユーザーまたはサーバーがアクションを実行すると実行されます。次のIdcClient OCXイベントを使用できます。

- IntradocBeforeDownload

- IntradocBrowserPost

- IntradocBrowserStateChange

- IntradocRequestProgress

- IntradocServerResponse

22.2.4.1 IntradocBeforeDownload

ファイルのダウンロード前に実行されます。

- ダウンロード前に必要なサーバーのアクションおよび更新を開始します。

パラメータ

このイベントは、次のパラメータを渡します。

- ByVal params As String

- cancelDownload As Boolean

22.2.4.2 IntradocBrowserPost

フォームがブラウザ内から送信されるたびに実行されます。

パラメータ

このイベントは、次のパラメータを渡します。

- ByVal url As String

- ByVal params As String

- cancelPost As Boolean

22.2.4.3 IntradocBrowserStateChange

ブラウザの状態が変わるたびに実行されます。

パラメータ

このイベントは、次のパラメータを渡します。

- ByVal browserStateItem As String

- ByVal enabled As Boolean

22.2.4.4 IntradocRequestProgress

サーバーからの進行状況レポートの送信リクエストを実行します。このイベントが発生するのは、メソッドのコール後のみです。

パラメータ

このイベントは、次のパラメータを渡します。

- ByVal statusData As String

- ByVal isDone As Boolean

22.2.4.5 IntradocServerResponse

サーバーがリクエストされたアクションを完了した後に実行されます。たとえば、ファイルのダウンロード後などです。このイベントは、サーバーからのレスポンスであるHDAエンコード・データを処理します。このイベントが発生するのは、アクションがブラウザで実行される場合のみです。

パラメータ

このイベントは、次のパラメータを渡します。

- ByVal response As String

22.2.5 IdcClient OCXのメソッド

次のIdcClient OCXメソッドを使用できます。

- AboutBox

- Back

- CancelRequest*

- DoCheckoutLatestRev

- DownloadFile

- DownloadNativeFile

- Drag

- EditDocInfoLatestRev

- Forward

- GoCheckinPage

- Home

- InitiateFileDownload*

- InitiatePostCommand*

- Move

- Navigate

- NavigateCgiPage

- Refresh Browser

- SendCommand*

- SendPostCommand*

- SetFocus

- ShowDMS

- ShowDocInfoLatestRev

- ShowWhatsThis

- StartSearch

- Stop

- UndoCheckout

- ViewDocInfo

- ViewDocInfoLatestRev

- ZOrder

アスタリスク(*)が付けられたメソッドは、ブラウザ・アクティビティとは関係なく、値を返すメソッドです。

重要:
特に示されていないかぎり、すべてのパラメータは必須です。

22.2.5.1 AboutBox

Sub AboutBox()

説明

製品のバージョン情報を示す「バージョン情報」ボックスを起動します。

- このメソッドは、製品の「バージョン情報」ボックスを表示します。

- コールを実行できない場合、メソッドは、FALSEを返します。

パラメータ

なし

22.2.5.2 Back

Sub Back()

説明

前のHTMLページを表示します。

- 前の画面に戻ります。

- このメソッドは、ユーザーに表示する、前のHTMLページをキャッシュされた情報から取得します。

パラメータ

なし

22.2.5.3 CancelRequest

Function CancelRequest() As Boolean

説明

このメソッドは、現在アクティブなリクエストを取り消します。リクエストを取り消すことができない場合、または現在アクティブなリクエストがない場合は、FALSEを返します。

パラメータ

なし

出力

次のブール値を返します。

- リクエストが取り消された場合は、TRUEを返します。

- 取消しリクエストを実行できない場合は、FALSEを返します。

22.2.5.4 DoCheckoutLatestRev

Sub DoCheckoutLatestRev(docName As String, curID As String)

説明

コンテンツ・アイテムの最新のリビジョンをチェックアウトまたはロックします。

- コンテンツ・アイテム名およびバージョン・ラベルが指定されると、このメソッドは、コンテンツ・アイテムの最新のリビジョンをチェックアウトします。

- IntradocServerResponseイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

注意:
curID値は、コンテンツ・アイテムのバージョン・ラベルです。生成されたコンテンツ・アイテムのリビジョンIDではありません。

この関数は、次の値を返します。

- dIDおよびdDocNameを含むシリアル化されたHDA。

- 最新のリビジョンがチェックアウトできない場合、またはシステムに見つからない場合、FALSE。

- パラメータとして渡されたデータ。

パラメータ

- docName: ユーザーが割り当てたコンテンツ・アイテム名。

- curID: 最新のリビジョンに対する一意の識別子。オプションです。

22.2.5.5 DownloadFile

Function DownloadFile(command As String, filename As String) As String

説明

定義されたファイルをダウンロードします。

- 現在関連付けられているコマンドおよびファイル・タイプが指定されると、このメソッドは、変換後のファイルのファイル・ダウンロードを実行します(DownloadNativeFileと比較)。

- IntradocBeforeDownloadイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

この関数では、次のように値が返されます。

- ステータス・コードおよびステータス・メソッドを含むシリアル化されたHDA。

- パラメータとして渡されたデータ。

- 指定されたファイルをダウンロードできない場合、FALSE。

パラメータ

- command: 現在関連付けられているコマンド。

- filename: ファイル形式。これは、PDFやHTMなど、サポートされる形式のファイル・タイプです。

22.2.5.6 DownloadNativeFile

Function DownloadNativeFile(id As String, docName As String, filename As String) As String

説明

定義されたネイティブ・ファイルをダウンロードします。

- コンテンツ・アイテムのリビジョンID、コンテンツ・アイテム名およびファイル・タイプが指定されると、このメソッドは、ネイティブ・ファイルのファイル・ダウンロードを実行します(DownloadFileと比較)。

- IntradocBeforeDownloadイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

注意:
id値は、生成されたコンテンツ・アイテムのリビジョンIDです。コンテンツ・アイテムのバージョン・ラベルではありません。

この関数では、次のように値が返されます。

- dIDおよびdDocNameを含むシリアル化されたHDA。

- パラメータとして渡されたデータ。

- 指定されたファイルをダウンロードできない場合、FALSE。

パラメータ

- id: 最新のリビジョンに対する一意の識別子。

- docName: ユーザーが割り当てたコンテンツ・アイテム名。

- filename: ファイル形式。これは、DOCやRTFなど、サポートされる任意の形式のファイル・タイプです。

22.2.5.7 Drag

Sub Drag([nAction])

説明

ドラッグ操作を開始、終了または取り消します。

- Dragメソッドは、標準コントロールの実装と同様に処理されます。

- 詳細は、Visual BasicのAPIリファレンスを参照してください。

パラメータ

- nAction: 実行するアクションを指定します。nActionを省略すると、nActionは1に設定されます。

Dragメソッドの設定は次のとおりです。

- 0: ドラッグ操作を取り消し、コントロールの元の位置を復元します。

- 1: (デフォルト)コントロールのドラッグを開始します。

- 2: ドラッグを終了します。つまり、コントロールをドロップします。

22.2.5.8 EditDocInfoLatestRev

Sub EditDocInfoLatestRev(docName As String, curID As String, activateAction As String)

説明

最新のリビジョンに関するコンテンツ・アイテム情報を編集します。

- ODMA関連です。

- コンテンツ・アイテム名、バージョン・ラベルおよび現在アクティブなリクエストされたアクションが指定されると、このメソッドは、最新のリビジョンに関するコンテンツ・アイテム情報を編集します。

- 最新のリビジョンに関するコンテンツ・アイテム情報を編集できない場合、またはその情報がシステムに見つからない場合、この関数はFALSEを返します。

注意:
curID値は、コンテンツ・アイテムのバージョン・ラベルです。生成されたコンテンツ・アイテムのリビジョンIDではありません。

パラメータ

- curID: 最新のリビジョンに対する一意の識別子。

- activateAction: ODMActivateに渡されます。これは、Idocスクリプトとして使用できます。オプションです。

- docName: ユーザーが割り当てたコンテンツ・アイテム名。オプションです。

22.2.5.9 Forward

Sub Forward()

説明

次のHTMLページを表示します。

- 次の画面に移動します。

- このメソッドは、ユーザーに表示する、次のHTMLページに関するキャッシュされた情報を取得します。

パラメータ

なし

22.2.5.10 GoCheckinPage

Sub GoCheckinPage(id As String, docName As String, isNew As Boolean, params As String)

説明

新しいコンテンツ・アイテムまたはコンテンツ・アイテムのリビジョンをチェックインします。

- コンテンツ・アイテムのリビジョンIDおよびコンテンツ・アイテム名が指定されると、この関数は、新しいコンテンツ・アイテムまたはコンテンツ・アイテムのリビジョンをチェックインします。

- このメソッドは、コンテンツ・アイテムのチェックイン・ページを開き、一意のコンテンツ・アイテム識別子、ユーザーが割り当てたコンテンツ・アイテム名および割り当てられたコンテンツ・アイテムの任意のパラメータを関連するテキスト・フィールドに入力します。また、新しいコンテンツ・アイテムなのか、リビジョンなのかも指定します。

注意:
id値は、生成されたコンテンツ・アイテムのリビジョンIDです。コンテンツ・アイテムのバージョン・ラベルではありません。

出力

この関数では、次のように値が返されます。

- 指定されたファイルをチェックインできない場合、FALSE。

- dIDおよびdDocNameを含むシリアル化されたHDA。

- パラメータとして渡されたデータ。

パラメータ(すべてオプション)

- id: 最新のリビジョンに対する一意の識別子。

- docName: ユーザーが割り当てたコンテンツ・アイテム名。

- IsNew: チェックインされるコンテンツ・アイテムが新しいコンテンツ・アイテムなのか、リビジョンなのかを定義します。

- TRUEの場合、新しい一意のコンテンツ・アイテムのバージョン・ラベルが割り当てられます。

- デフォルトはTRUEです。

- params: 「チェックイン」ページを事前入力するパラメータ。

22.2.5.11 Home

Sub Home()

説明

定義されたホームページに戻ります。

- ホーム画面に移動します。

- HTMLページ・リクエストを実行し、定義されたホームページをユーザーに表示します。

パラメータ

なし

22.2.5.12 InitiateFileDownload

Function InitiateFileDownload(command As String, filename As String) As String

説明

ファイル・ダウンロードを開始します。

- 現在関連付けられているコマンドおよびファイル・タイプが指定されると、この関数は、ファイル・ダウンロードを開始します。このメソッドは、コンテンツ・アイテムの特定のレンディション、最新のリビジョンまたは最新リリースのリビジョンのファイル・ダウンロードを開始します。

- IntradocServerResponseイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

パラメータ

- command: 現在関連付けられているコマンド。

- filename: ファイル形式。これは、PDFやHTMなど、サポートされる形式のファイル・タイプです。

出力

- リクエストされた情報を含む、シリアル化されたHDAを返します。

- パラメータとして渡されたデータを返します。

22.2.5.13 InitiatePostCommand

Function InitiatePostCommand(postData As String) As String

説明

postコマンドを開始します。

- サービス・コールを開始します。割り当てられたpostデータが指定されると、このメソッドは、postコマンドを開始します。

- IntradocServerResponseイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

パラメータ

- postData: サービス・コマンドおよび必要なサービス・パラメータを含む、シリアル化されたHDA。

出力

- リクエストされた情報を含む、シリアル化されたHDAを返します。

- StatusCodeおよびStatusMessageを返します。

- 障害が発生した場合、StatusCodeは負の値になり、StatusMessageにエラーが示されます。

- 返されたHDAにStatusCodeパラメータが含まれていない場合、サービス・コールが成功したことを示しています。

22.2.5.14 Move

Sub Move(Left As Single, [Top], [Width], [Height])

説明

オブジェクトを移動します。

- Moveメソッドは、標準コントロールの実装と同様に処理されます。

- 詳細は、Visual BasicのAPIリファレンスを参照してください。

パラメータ

- nLeft: オブジェクトの左端の水平座標を指定します。これは、単精度値です。

- nTop: オブジェクトの上端の垂直座標を指定します。これは、単精度値です。

- nWidth: オブジェクトの新しい幅を指定します。これは、単精度値です。

- nHeight: オブジェクトの新しい高さを指定します。これは、単精度値です。

22.2.5.15 Navigate

Sub Navigate(url As String

説明

URLパスを計算します。

- 完全なURLが指定されると、このメソッドは、シリアル化されたHDAからURLを計算し、文字列として値を返します。

この関数は、次の値を返します。

- リクエストされた情報を含む、シリアル化されたHDA。

- パラメータとして渡されたデータ。

パラメータ

- url: 完全なURLパス。

22.2.5.16 NavigateCgiPage

Sub NavigateCgiPage(params As String)

説明

CGIパスを計算します。

- 定義されたコンテンツ・アイテムのパラメータが指定されると、このメソッドは、シリアル化されたHDAからCGIパスを計算し、文字列として値を返します。

パラメータ

- params: 割り当てられたコンテンツ・アイテムのパラメータ。

22.2.5.17 Refresh Browser

説明

ブラウザをリフレッシュします。

- このメソッドは、Web ブラウザをリフレッシュし、動的情報を更新します。

パラメータ

なし

22.2.5.18 SendCommand

Function SendCommand(params As String) As String

説明

サービス・リクエストをOracle WebCenter Content Serverに発行します。

- 定義されたコンテンツ・アイテムのパラメータが指定されると、この関数は、コンテンツ・アイテムの処理に関連するOracle WebCenter Content Serverからサービスを実行します。

パラメータ

- params: CGI URLエンコードのパラメータ。

出力

- リクエストされた情報を含む、シリアル化されたHDAを返します。

- パラメータとして渡されたデータを返します。

22.2.5.19 SendPostCommand

Function SendPostCommand(postData As String) As String

説明

postコマンドを送信します。

- サービス・コールを実行します。

- IntradocBrowserPostイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

パラメータ

- postData: サービス・コマンドおよび必要なサービス・パラメータを含む、シリアル化されたHDA。

出力

- リクエストされた情報を含む、シリアル化されたHDAを返します。

- StatusCodeおよびStatusMessageを返します。

- 障害が発生した場合、StatusCodeは負の値になり、StatusMessageにエラーが示されます。

- 返されたHDAにStatusCodeパラメータが含まれていない場合、サービス・コールが成功したことを示しています。

22.2.5.20 SetFocus

Sub SetFocus()

説明

コントロールにフォーカスを割り当てます。

- SetFocusメソッドは、標準コントロールの実装と同様に処理されます。

- 詳細は、Visual BasicのAPIリファレンスを参照してください。

パラメータ

なし

22.2.5.21 ShowDMS

Sub ShowDMS()

説明

コンテンツ・マネージャに関連付けられているHTMLページを開きます。

- ODMA関連です。

- コンテンツ・マネージャのアクセス・ページをブラウザに表示します。

パラメータ

なし

22.2.5.22 ShowDocInfoLatestRev

Sub ShowDocInfoLatestRev(docName As String, curID As String, activateAction As String)

説明

最新のリビジョンに関するコンテンツ・アイテム情報を表示します。

注意:
curID値は、コンテンツ・アイテムのバージョン・ラベルです。生成されたコンテンツ・アイテムのリビジョンIDではありません。

パラメータ

- docName: ユーザーが割り当てたコンテンツ・アイテム名。

- curID: 最新のリビジョンに対する一意の識別子。オプションです。

- activateAction: 現在アクティブな、リクエストされたアクション。オプションです。

22.2.5.23 ShowWhatsThis

Sub ShowWhatsThis()

説明

WhatsThisHelpIDプロパティを持つオブジェクトに対して指定された「説明の表示」ヘルプ・トピックを表示します。

- ShowWhatsThisメソッドは、標準コントロールの実装と同様に処理されます。

- 詳細は、Visual BasicのAPIリファレンスを参照してください。

パラメータ

- Object: 「説明の表示」ヘルプ・トピックを表示するオブジェクトを指定します。

22.2.5.24 StartSearch

Sub StartSearch()

説明

問合せページをブラウザ・コントロールに表示します。

- ブラウザ操作を実行します。

パラメータ

なし

22.2.5.25 Stop

Sub Stop()

説明

ブラウザを停止します。

- このメソッドは、ブラウザでの情報のロードを停止または取り消します。

パラメータ

なし

22.2.5.26 UndoCheckout

Sub UndoCheckout(docName As String, curID As String)

説明

このサービスは、コンテンツ・アイテムのチェックアウトを元に戻します。

- コンテンツ・アイテム名およびバージョン・ラベルが指定されると、このサービスは、コンテンツ・アイテムをシステムで検索し、チェックアウトを元に戻そうとします。コンテンツ・アイテムがシステムに存在しない場合、コンテンツ・アイテムがチェックアウトされていない場合、またはチェックアウトを元に戻すのに十分な権限がユーザーにない場合、サービスは失敗します。

- IntradocServerResponseイベントを実行します。イベントは、メソッドの発生前に実行されます。詳細は、第22.2.4項「IdcClientのイベント」を参照してください。

注意:
curID値は、コンテンツ・アイテムのバージョン・ラベルです。生成されたコンテンツ・アイテムのリビジョンIDではありません。

パラメータ

- curID: 最新のリビジョンに対する一意の識別子。

- docName: ユーザーが割り当てたコンテンツ・アイテム名。オプションです。

22.2.5.27 ViewDocInfo

Sub ViewDocInfo(id As String)

説明

コンテンツ・アイテム情報ページに移動し、コンテンツ・アイテム情報をブラウザに表示します。

- ブラウザ操作を実行します。

- コンテンツ・アイテムのリビジョンIDが指定されると、このメソッドは、コンテンツ・アイテム情報をブラウザに表示します。

注意:
id値は、生成されたコンテンツ・アイテムのリビジョンIDです。コンテンツ・アイテムのバージョン・ラベルではありません。

パラメータ

- id: 最新のリビジョンに対する一意の識別子。

22.2.5.28 ViewDocInfoLatestRev

Sub ViewDocInfoLatestRev(docName As String, curID As String)

説明

コンテンツ・アイテム情報ページに移動し、最新のリビジョンに関するコンテンツ・アイテム情報を表示します。

- コンテンツ・アイテム名およびバージョン・ラベルが指定されると、このメソッドは、最新のリビジョンに関するコンテンツ・アイテム情報を表示します。

注意:
curID値は、コンテンツ・アイテムのバージョン・ラベルです。生成されたコンテンツ・アイテムのリビジョンIDではありません。

この関数は、次の値を返します。

- dIDおよびdDocNameを含むシリアル化されたHDA。

- パラメータとして渡されたデータ。

パラメータ

- docName: ユーザーが割り当てたコンテンツ・アイテム名。

- curID: 最新のリビジョンに対する一意の識別子。

22.2.5.29 ZOrder

Sub ZOrder([Position])

説明

グラフィカル・レベル内で、指定したフォームまたはコントロールをz-orderの前または後に配置します。

- ZOrderメソッドは、標準コントロールの実装と同様に処理されます。

- 詳細は、Visual BasicのAPIリファレンスを参照してください。

パラメータ

- nOrder: 他のオブジェクトに対する相対的なオブジェクトの位置を示す整数を指定します。nOrderを省略すると、設定は0になります。

ZOrderメソッドの設定は次のとおりです。

- 0: (デフォルト)オブジェクトはz-orderの前に配置されます。

- 1: オブジェクトはz-orderの後に配置されます。

22.2.6 IdcClientのプロパティ

各データ・アイテムまたは属性は、Visual Basicではプロパティとして実装されます。プロパティは、Visual Basic開発環境内ではオブジェクトのパブリック・インタフェースを通じて公開されます。これらの属性を使用すると、要素をさらに詳しく記述できます。

IdcClient OCXプロパティは次のとおりです。

- ClientControlledContextValue

- HostCgiUrl

- Password

- UseBrowserLoginPrompt

- UseProgressDialog

- UserName

- Working Directory

22.2.6.1 ClientControlledContextValue

ユーザー指定のコンテキスト値を指定します。この値は、Oracle WebCenter Content Serverによって配信されるWebページで、変数ClientControlledとしてIdocスクリプトで使用できるようになります。

- 値を文字列として返します。

- パラメータは取りません。

22.2.6.2 HostCgiUrl

ホストCGI binの完全なURLパスを指定します。

- 値を文字列として返します。

- パラメータは取りません。

22.2.6.3 Password

割り当てられたユーザー・パスワードを指定します。

- 値を文字列として返します。

- パラメータは取りません。

22.2.6.4 UseBrowserLoginPrompt

ブラウザのログイン・プロンプトを使用できるようにします。ユーザー認証のダイアログ・ボックスを表示するかどうかを定義します。

- TRUEに設定すると、ユーザー認証のダイアログ・ボックスが開きます。

- デフォルト値はTRUEです。

次のブール値を返します。

- ログインが成功した場合は、TRUE

- ログインが拒否された場合は、FALSE

22.2.6.5 UseProgressDialog

ユーザー進行状況ダイアログを使用できるようにします。ユーザー認証のダイアログ・ボックスを表示するかどうかを定義します。

- TRUEに設定すると、ユーザー進行状況のダイアログ・ボックスが開きます。

- デフォルトはTRUEです。

次のブール値を返します。

- アクションが完了した場合は、TRUEを返します。

- アクションが失敗した場合は、FALSEを返します。

22.2.6.6 UserName

割り当てられたユーザー名を指定します。

値を文字列として返します。

パラメータは取りません。

22.2.6.7 Working Directory

作業ディレクトリをフルパスとして指定します。これは、ダウンロードされたファイルが格納される場所です。

- 値を文字列として返します。

- パラメータは取りません。

22.3 ODMA APIを使用した、デスクトップ・アプリケーションからコンテンツ・サーバーへのアクセス

Open Document Management Application (ODMA)は、デスクトップ・アプリケーションとファイル管理ソフトウェアをつなぐために使用される標準的なAPIです。コンテンツ・サーバーのためのODMA統合は、別な製品であるDesktopで使用可能です。ODMA統合製品を使用して、(ODMA準拠デスクトップ・アプリケーションのために)コンテンツ・サーバー内のコンテンツおよびコンテンツ管理機能にアクセスできます。

Microsoft Word、Corel WordPerfect、Adobe FrameMakerなどの任意のODMA準拠アプリケーションからWebリポジトリに直接ファイルを公開できます。ODMAをWeb中心に導入することで、情報をWebに直接チェックインおよび公開することができます。これは、従来のODMAクライアント/サーバー実装に対する大きな進歩です。従来の実装では、情報は、まずサーバーに公開され、直ちにWebで使用できるようにはなりません。

詳細は、ODMAまたはODMA/FrameMakerのオンライン・ヘルプを参照してください。

22.3.1 ODMAクライアント

ODMAクライアントは、別な製品であり、コア製品とともには出荷されません。これは、情報をデスクトップ・アプリケーションからWebに直接チェックインまたは公開するために使用されます。ODMAクライアントは、従来のODMAクライアント/サーバー・モデルより優れています。従来のモデルでは、情報はサーバーに公開され、直ちにWebで使用できるようにはなりません。デスクトップ・アプリケーション内からODMAクライアントを使用して、たとえば次のような、Oracle WebCenter Content Serverと対話する多数のタスクを実行できます。

- ファイルを保存し、それを直ちにOracle WebCenter Content Serverにチェックインする。

- ファイルを保存して、後でチェックインする。

- Oracle WebCenter Content Serverからファイルをチェックアウトする。

- ファイルのメタデータ(コンテンツ情報)を更新する。

- ファイルをローカルのファイル・システムに保存し、ODMAクライアント・システムを迂回する。

22.3.2 ODMAインタフェース

次のODMAインタフェースを使用できます。

- ODMAクライアント・インタフェース: 最近使用したファイル・オプションが選択されているドキュメントの選択画面には、ODMAを通じて最近使用されたファイルのリストが表示されます。この画面は、通常の「開く」ダイアログ・ボックスの代わりに表示されます。この画面にファイルが表示されていない場合は、コンテンツ・サーバー内かローカルのファイル・システムでファイルを検索できます。

- ODMAデスクトップ・シェル・インタフェース: クライアント・デスクトップ・シェルは、ドラッグ・アンド・ドロップのチェックイン機能を提供し、デスクトップ・アプリケーションの外部からODMAクライアントのドキュメントの選択画面にアクセスできるようにします。デスクトップ・シェルを通じて、次のことを実行できます。

- デスクトップまたはWindowsエクスプローラ・ウィンドウからファイルを選択し、それをデスクトップ・シェルにドラッグしてコンテンツ・サーバーにチェックインする。

- 最近使用したファイルのリストまたはコンテンツ・サーバーからからファイルを選択して開く。

- ODMAが有効なコンテンツ・サーバー・インタフェース: コンテンツ・サーバーの「コンテンツ情報」ページからODMAファイルを直接開いてチェックアウトすることができます。コンテンツ・サーバーからファイルを開くと、ファイルを編集したり、コンテンツ・サーバーに迅速にチェックインしたりできるように、ファイルはそのネイティブのアプリケーション内で開かれます。

注意:
ODMA準拠アプリケーション内からファイルを開いてチェックアウトすることや、ファイルをチェックアウトせずにそのコピーを開くことも可能です。詳細は、ODMAのオンライン・ヘルプを参照してください。

23 RIDCを使用したコンテンツ・サーバーへのアクセス

この章では、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)の初期化および使用方法について説明します。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

Remote Intradoc Client (RIDC)は、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。

注意:
Remote Intradoc Client (RIDC)バージョン11.1.1.6 (11gR1 PS5)では、Java Runtime Environment (JRE) 1.6以上が必要です。最新のJava JRE/JDKは、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。

この章では、次の項目について説明します。

- 第23.1項「Remote Intradoc Client (RIDC)について」

- 第23.2項「接続の初期化」

- 第23.3項「クライアントの構成」

- 第23.4項「ユーザーの認証」

- 第23.5項「サービスの使用」

- 第23.6項「接続プーリングについて」

- 第23.7項「ストリームについて」

- 第23.8項「バインダについて」

- 第23.9項「コンビニエンス・クラスについて」

- 第23.10項「RIDCフィルタについて」

- 第23.11項「RIDC JDeveloper拡張機能の使用」

23.1 Remote Intradoc Client (RIDC)について

Remote Intradoc Client (RIDC)は、コンテンツ・サーバーとの通信を行うためのシン通信APIです。その主な機能は、コンテンツ・サーバー・サービスをリモートで実行できるようにすることです。さらに、RIDCは、接続プーリング、セキュリティ、プロトコルの固有情報などを処理します。

主な機能

Remote Intradoc Client (RIDC)には次のような機能があります。

- Intradocソケットベース通信、およびHTTPプロトコルとJAX-WSプロトコルをサポートします。

- コンテンツ・サーバーとのSecure Socket Layer (SSL)通信をサポートします。

- ソケットのタイムアウトや接続プールのサイズなどの設定を含むクライアント構成を提供します。

- RIDCオブジェクトは、標準のJava Collectionパラダイムに従います。

サポートされているプロトコル

Remote Intradoc Client (RIDC)バージョン11.1.1.6.0は、idc、idcs、http、httpsおよびjax-wsプロトコルをサポートしています。

Intradoc: Intradocプロトコルは、Intradocソケット・ポート(通常は4444)経由でコンテンツ・サーバーと通信します。このプロトコルは、クライアントとコンテンツ・サーバー間の信頼できる接続を必要とし、パスワード検証は行いません。このプロトコルを使用するクライアントには、RIDCコールを行う前に、必要な認証を自身で実行することが求められます。Intradoc通信は、SSL経由で実行するように構成することもできます。

HTTP: RIDCは、Apache HttpClientパッケージを使用して、コンテンツ・サーバーに接続されたWebサーバーと通信します。Intradocとは異なり、このプロトコルでは、各リクエストについて認証資格証明が必要です。HttpClientバージョン3がデフォルトです。ただし、httpClientライブラリのバージョン4も使用できます。詳細は、第23.1.1項「HttpClientライブラリ・バージョン4の使用」を参照してください。また、追加情報については、Apache HttpClient WebサイトのHttpClientホームページで、Jakarta Commons HttpClientのドキュメントを参照してください。

http://hc.apache.org/

JAX-WS: JAX-WSプロトコルは、適切に構成されたコンテンツ・サーバー・インスタンスとRIDCクライアントがインストールされているOracle WebCenter Content 11gでのみサポートされます。JAX-WSは、この環境の外部ではサポートされません。

JAX-WSの詳細は、Oracle Technology Network (OTN)で、『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』および『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング』を参照してください。また、次のJava Community Process Webサイトで、Java API for XML Web Services (JAX-WS)のドキュメントも参照してください。

http://www.jcp.org/

サポートされているURLフォーマット

次の表に、サポートされているURLフォーマットを示します。

URL

説明

idc://localhost:4444

Intradocポートを使用します。ホスト名とポート番号のみが必要です。

idcs://localhost:4443

Intradocポート経由でSSLを使用します。SSL証明書をロードするための追加の構成が必要です。

http://localhost:16200/cs/idcplg

コンテンツ・サーバーCGIパスへのURLを指定します。

https://localhost:16200/cs/idcplg

SSL over HTTPを使用します。SSL証明書をロードするための追加の構成が必要です。

http://wlsserver:16200/idcnativews

JAX-WSプロトコルを使用してコンテンツ・サーバーに接続します。

必要な環境

次の表は、RIDCが各接続タイプをサポートするために必要な環境についてまとめたものです。

URL

説明

idc://

- oracle.ucm.ridc-11.1.1.jar

idcs:/

- oracle.ucm.ridc-11.1.1.jar

- SSL証明書の構成

http:/

- oracle.ucm.ridc-11.1.1.jar

- HttpClientライブラリ。これらは、httpclient-3.*.jarおよびhttpclient-4.*.jarに含まれています。

https:/

- oracle.ucm.ridc-11.1.1.jar

- HttpClientライブラリ。これらは、httpclient-3.*.jarおよびhttpclient-4.*.jarに含まれています。

- SSL証明書の構成

jax-ws

- WLSおよびJRFスタックを持つOracle shiphome

23.1.1 HttpClientライブラリ・バージョン4の使用

RIDCは、Apache HttpClientパッケージを使用して、コンテンツ・サーバーに接続されたWebサーバーと通信します。Intradocとは異なり、このプロトコルでは、各リクエストについて認証資格証明が必要です。Remote Intradoc Client (RIDC)バージョン11.1.1.6.0は、HttpClientバージョン3をデフォルトとして使用します。ただし、HttpClientライブラリのバージョン4も使用できます。

また、追加情報については、Apache HttpClient WebサイトのHttpClientホームページで、Jakarta Commons HttpClientのドキュメントを参照してください。

http://hc.apache.org/

JavaコードでHttpClientバージョン4を要求するには、次のコマンドを使用します。

IdcClient idcClient = manager.createClient("http://localhost/idc/idcplg");
idcClient.getConfig ().setProperty ("http.library", "apache4");

JDeveloper拡張機能を使用して新しいRIDCアプリケーションを作成する場合、Configuration Parametersセクションで、接続にapache4という値のhttp.libraryパラメータを追加することができます。RIDC JDeveloper拡張機能の詳細は、第23.11項「RIDC JDeveloper拡張機能の使用」を参照してください。

JDeveloperでSite Studio for External Applications (SSXA)アプリケーションを使用している場合、UIがないため、まず接続を作成し、その接続をテストせずに保存する必要があります。そして、「接続」→ディスクリプタ→ADF META-INFノードのconnections.xmlファイルを開きます。connections.xmlファイルに次のStringRefAddrセクションを追加し(例23-1に示されています)、ファイルを保存します。

例23-1 connections.xmlにおける接続の例

<Reference name="sample"
className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns="">
<Factory className=
"oracle.stellent.ridc.convenience.adf.mbeans.IdcConnectionFactory"/>
<RefAddresses>
<StringRefAddr addrType="oracle.stellent.idc.connectionUrl">
<Contents>idc://localhost:4444</Contents>
</StringRefAddr>
<StringRefAddr addrType="oracle.stellent.idc.idcServerURL">
<Contents>http://localhost/cs/idcplg</Contents>
</StringRefAddr>

<StringRefAddr addrType="oracle.stellent.idc.http.library">
<Contents>apache4</Contents>
</StringRefAddr>

</RefAddresses>
</Reference>

SSXAとRIDCの接続タイプは類似していることに注意してください。

- JDeveloperでSSXA接続を使用する場合、connections.xmlファイルのaddrType値はoracle.stellent.idc.http.libraryです。

- JDeveloperでRIDC接続を使用する場合、connections.xmlファイルのaddrType値はoracle.stellent.ridc.http.libraryです。

23.2 接続の初期化

この項では、Intradoc接続とHTTP接続を初期化するサンプル・コード、およびJAX-WSクライアントを初期化するコードを示します。

例23-2のコードは、Intradoc接続を初期化します。

例23-2 Intradoc接続の初期化

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the intradoc protocol
IdcClient idcClient = manager.createClient("idc://localhost:4444");

例23-3のコードは、HTTP接続を初期化します。Intradoc接続との唯一の違いはURLです。

例23-3 HTTP接続の初期化

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the HTTP protocol
IdcClient idcClient = manager.createClient("http://localhost:16200/idc/idcplg");

例23-4のコードは、JAX-WSクライアントを初期化します。URLにはidcnativews Webコンテキスト・ルートが含まれることに注意してください。このWebコンテキスト・ルートは(デフォルトで)、コンテンツ・サーバーによって公開される2つのWebサービス(loginサービスとrequestサービス)で使用されます。

例23-4 JAX-WSクライアントの初期化

// create the manager
IdcClientManager manager = new IdcClientManager();

// build a client that will communicate using the JAXWS protocol
IdcClient idcClient = manager.createClient
("http://wlsserver:16200/idcnativews");

23.3 クライアントの構成

クライアントの構成は、クライアントの作成後に実行できます。構成パラメータには、ソケットのタイムアウトや接続プールのサイズなどの設定が含まれます。構成はプロトコル固有のものです。つまり、IdcClientオブジェクトを特定のタイプにキャストする場合、そのタイプのプロトコル構成オブジェクトを取得できます。

Intradoc接続のためのクライアント構成

例23-5のコードは、Intradoc接続のためのソケット・タイムアウトおよび待機時間を設定します。

例23-5 Intradoc接続のためのクライアント構成

// build a client as cast to specific type
IntradocClient idcClient =
(IntradocClient)manager.createClient("http://localhost/idc/idcplg");

// get the config object and set properties
idcClient.getConfig().setSocketTimeout(30000);  // 30 seconds
idcClient.getConfig().setConnectionSize(20);    // 20 connections

SSLの構成

Remote Intradoc Client (RIDC)では、Intradoc通信プロトコルを使用してコンテンツ・サーバーとSecure Socket Layer (SSL)通信を行うことが可能です。使用される通常のポートは4444です。SSLの構成およびポートの有効化に関する詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

SSL通信の場合、アクセス先のコンテンツ・サーバー・インスタンスにSecurityProvidersコンポーネントをインストールして有効化する必要があります。新しい受信プロバイダとのSSL通信のためにコンテンツ・サーバーを構成し、トラストストアまたはキーストアに関する情報を指定する必要があります。クライアントとコンテンツ・サーバーの両方で、署名付きの信頼できる証明書のある有効なキーストアまたはトラスト・マネージャが必要です。

Oracleでは、署名付き証明書を提供していません。ほとんどの実装では、広く認められている認証局による署名付きの証明書を求めることになります。

コンテンツ・サーバーとのSSL通信を構成するには、次のタスクを実行する必要があります。

1. SecurityProvidersコンポーネントをインストールして、有効にします。SecurityProvidersコンポーネントは、SSL通信でアクセスするコンテンツ・サーバー・インスタンスにインストールし、有効にする必要があります。
このコンポーネントは、Oracle WebCenter Content Server 11gR1ではデフォルトでインストールされ、有効化されます。

2. SSL通信のための受信プロバイダを構成します。
SSLの構成に関する詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。

3. 自己署名付きのキー・ペアおよび証明書を作成します。

例23-6のコードは、セキュア・ソケット(SSL)経由のIDCプロトコルを使用します。

例23-6 SSL経由のIDCプロトコル

// build a secure IDC client as cast to specific type
IntradocClient idcClient = (IntradocClient)
manager.createClient("idcs://localhost:4443");

// set the SSL socket options
config.setKeystoreFile("ketstore/client_keystore");  //location of keystore file
config.setKeystorePassword ("password");      // keystore password
config.setKeystoreAlias("SecureClient");  //keystore alias
config.setKeystoreAliasPassword("password");  //password for keystore alias

JAX-WSの構成

クライアントの作成後に実行可能な、JAX-WS固有の構成がいくつかあります。ただし、ほとんどの場合、デフォルト設定を使用する必要があります。

このコードは、クライアントをJAX-WSタイプのキャストとしてビルドします。

JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient
("http://wlsserver:7044/idcnativews");
JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();

接続先のコンテンツ・サーバーのインスタンス名を設定できます。これは、デフォルトで/cs/(UCMインストールのWebコンテキスト)に設定されます。サーバーのWebコンテキストがデフォルトと異なる場合は、次のように設定できます。

// set the property
jaxwsConfig.setServerInstanceName("/mywebcontext/");

JPS構成ファイルの場所を設定します。JPS構成ファイルは、SAMLやメッセージ・トークンなど、ほとんどのポリシーで必要です。

jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");

次のように、セキュリティ・ポリシーを設定します。

jaxwsConfig.setClientSecurityPolicy("policy:oracle/wss11_username_token_with_message_protection_client_policy");

ログイン・ポートのWSDL URLの変更

RIDCは、インストール済のWebサービスに対してデフォルト値を使用します。何らかの理由で、Webサービスが変更されており、デフォルトのURI/URLと一致しない場合は、デフォルト値を変更する必要がある可能性があります。

次のように、ログイン・ポートのWSDL URLを変更します。

jaxwsConfig.setLoginServiceWSDLUrl
(new URL("http://server:7044/webservices/loginPort?WSDL"));

次のように、リクエスト・サービスURLを変更します。

jaxwsConfig.setRequestServiceWSDLUrl
(new URL("http://server:7044/anotherservice/myrequestport?WSDL"));

デフォルトのストリーム・チャンク・サイズは8192です。次の例では、チャンク・サイズを変更します。

jaxwsConfig.setStreamingChunkSize(8190);

JAX-WSポリシーの構成

UCMに対して設定されているサービス側のポリシーを特定するには、管理コンソールから、「デプロイメント」→Oracle UCM Native Web Services→IdcWebLoginService→「構成」→WS-Policy→IdcWebLoginPort→OWSMを選択します。

LPAが明示的に設定されていない場合にJAX-WS経由でRIDCによって活用されるWSクライアントに対するGPAポリシーを特定するには、WebLogic Scripting Tool (WLST)を初期化し、WebLogic Server Administration Scripting Shellを使用します。

例23-7のコードは、その一例を示しています。

例23-7 WebLogic Scripting Toolを使用したGPAポリシーの特定

(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh

...

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect('weblogic','welcome1','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.

wls:/base_domain/serverConfig> help('wsmManage')

Operations that provide support to manage the global policy attachments and
Oracle MDS repository.

help('abortRepositorySession')
Abort the current repository session,
discarding the changes made to repository.
help('attachPolicySet')
Attach a policy set to the specified resource scope.
help('attachPolicySetPolicy')
Attach a policy to a policy set using the policy's URI.
help('beginRepositorySession')
Begin a session to modify the repository.
help('clonePolicySet')
Clone a new policy set from an existing policy set.
help('commitRepositorySession')
Write the contents of the current session to the repository.
help('createPolicySet')
Create a new, empty policy set.
help('deletePolicySet')
Delete a specified policy set.
help('describeRepositorySession')
Describe the contents of the current repository session.
help('detachPolicySetPolicy')
Detach a policy from a policy set using the policy's URI.
help('displayPolicySet')
Display the configuration of a specified policy set.
help('enablePolicySet')
Enable or disable a policy set.
help('enablePolicySetPolicy')
Enable or disable a policy attachment
for a policy set using the policy's URI.
help('exportRepository')
Export a set of documents from the repository into a supported ZIP archive.
help('importRepository')
Import a set of documents from a supported ZIP archive into the repository.
help('listPolicySets')
Lists the policy sets in the repository.
help('migrateAttachments')
Migrates direct policy attachments to global policy attachments
if they are identical.
help('modifyPolicySet')
Specify an existing policy set for modification in the current session.
help('resetWSMPolicyRepository')
Clean the Oracle MDS repository and re-seed with the current set
of WSM policies.
help('setPolicySetDescription')
Specify a description for the policy set selected within a session.
help('upgradeWSMPolicyRepository')
Add newly introduced WSM policies to the Oracle MDS repository.
help('validatePolicySet')
Validate an existing policy set in the repository or in a session.

wls:/base_domain/serverConfig> listPolicySets()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Global Policy Sets in Repository:
base-domain-ws-client

wls:/base_domain/serverConfig> displayPolicySet('base-domain-ws-client')

Policy Set Details:
-------------------
Name: base-domain-ws-client
Type of Resources: Web Service Client
Scope of Resources: Domain("base_domain")
Description: Global policy attachments for Web Service Client resources.
Enabled: true
Policy Reference: security : oracle/wss10_saml_token_client_policy, enabled=true

GPAポリシーの設定

例23-8のコードは、WSクライアントのGPAポリシーを設定します。

例23-8 Webサービス・クライアントに対するGPAの追加

# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')

# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()

# confirm policy set created
listPolicySets()

# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')

# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()

# confirm policy set created
listPolicySets()

23.4 ユーザーの認証

Remote Intradoc Client (RIDC)へのすべてのコールで、認証のための何らかのユーザーIDが必要です。オプションで、このID資格証明に、プロトコルで必要なパスワードなど、他のパラメータを添付することができます。ユーザーIDは、IdcContextオブジェクトに保持されます。いったん作成されると、以降のすべてのコールでそれを再利用できます。コンテキストを作成するには、ユーザー名と、オプションで何らかの資格証明を渡します。

次のように、(idc:// urlsに対して)パスワードなしの単純なコンテキストを作成します。

IdcContext userContext = new IdcContext("weblogic");

次のように、パスワード付きのコンテキストを作成します。

IdcContext userPasswordContext = new IdcContext("weblogic", "welcome1");

Intradoc URLの場合、リクエストがコンテンツ・サーバーとクライアントの間で信頼されているため、資格証明でパスワードは必要ありません。

JAX-WS URLの場合、資格証明の要件は、サーバーによってWebサービスが使用するように構成されているサービス・ポリシーによって異なります。

23.5 サービスの使用

サービスを起動するには、IdcClientクラス・メソッドを使用します。

public ServiceResponse sendRequest (IdcContext userContext, DataBinder dataBinder) throws IdcClientException

詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

例23-9のコードは、サービス・リクエストを実行し、結果のデータ・バインダを戻します。

例23-9 サービス・リクエストの実行

// get the binder
DataBinder binder = idcClient.createBinder();

// populate the binder with the parameters
binder.putLocal ("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal ("QueryText", "");
binder.putLocal ("ResultCount", "20");

// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);

ServiceResponseには、コンテンツ・サーバーからのレスポンスが含まれます。このレスポンスから、コンテンツ・サーバーのストリームに直接アクセスできます。または、それをDataBinderに解析し、結果を問い合せることができます。

例23-10のコードは、ServiceResponseを取得し、検索結果を取得して、タイトルと作成者の値を出力します。

例23-10 バインダの取得と結果のループ・オーバー

// get the binder
DataBinder binder = response.getResponseAsBinder ();
DataResultSet resultSet = binder.getResultSet ("SearchResults");

// loop over the results
for (DataObject dataObject : resultSet.getRows ()) {
System.out.println ("Title is: " + dataObject.get ("dDocTitle"));
System.out.println ("Author is: " + dataObject.get ("dDocAuthor"));
}

ストリームを使用する場合、ストリームのクローズはコードで行います。例23-11のコードは、ストリームのクローズの例を示しています。

例23-11 ストリームのクローズ

IdcContext user = new IdcContext ("weblogic", "welcome1");
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.getClient ("some url");
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);

InputStream stream = null;
try {
stream = response.getResponseStream ();
int read = 0;
int total = 0;
byte[] buf = new byte[256];
while ((read = stream.read (buf)) != -1) {
total += read;
}
} finally {
if (stream != null) {
stream.close ();
}
}

ストリームを通じた接続プーリングとクローズについては、第23.6項「接続プーリングについて」を参照してください。

23.6 接続プーリングについて

IdcClientConfig#getConnectionPoolプロパティは、RIDCが接続のプーリングをどのように処理するかを決定します。simpleとpoolの2つのオプションがあります。

- simpleオプションがデフォルトです。simpleオプションでは、接続の最大数の制限は適用されず、すべての接続がブロックされることなく処理されます。ほとんどの場合、このオプションを使用する必要があります。

- poolオプションでは、一度にアクティブにする接続数を構成可能な内部プールを使用することが指定されます(IdcClientConfig#getConnectionSizeプロパティを通じて構成可能で、デフォルトのアクティブ・サイズは20に設定されます)。

通常、RIDCライブラリが、それ自体がアプリケーション・コンテナ内に存在するアプリケーション(Webアプリケーションなど)からの通信に使用される場合、インバウンド・リクエストはすでに調整されています。そのため、simpleオプションを使用することが適切です。poolオプションを使用する唯一のシナリオは、スタンドアロン・サーバーを作成しており、かつコンテンツ・サーバーの過負荷を生じさせる可能性がある大量の同時コールをコンテンツ・サーバーに対して行う場合です。

IdcClientManager#getConnectionPoolManager()#registerPool()メソッドによって別のプール実装を登録できます。このメソッドは、名前をConnectionPoolインタフェースの実装にマップします。マップされた名前は、IdcClientConfigオブジェクトで使用されて、特定のクライアントに対してそのプールが選択されます。

23.7 ストリームについて

ストリームは、TransferFileクラスを通じてコンテンツ・サーバーに送信されます。このクラスは、実際のストリームを、ストリームに関するメタデータ(長さや名前など)とともにラップします。ファイルおよびストリームのチェックインを可能にするメソッドについては、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

例23-12のコードは、コンテンツ・サーバーへのチェックインを実行します。

例23-12 コンテンツ・サーバーへのチェックイン

// create request
DataBinder binder = idcClient.createBinder();
binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL");

// get the binder
binder.putLocal ("dDocTitle", "Test File");
binder.putLocal ("dDocName", "test-checkin-6");
binder.putLocal ("dDocType", "ADACCT");
binder.putLocal ("dSecurityGroup", "Public");

// add a file
binder.addFile ("primaryFile", new TransferFile ("test.doc"));

// check in the file
idcClient.sendRequest (userContext, binder);

コンテンツ・サーバーからのレスポンス

コンテンツ・サーバーからのストリームは、ServiceResponseオブジェクトを通じて受信されます。使用可能なメソッドの概要については、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

特に要求されないかぎり、レスポンスは、DataBinderに変換されません。単に未加工のHDAデータが必要な場合は、それを直接取得し、レスポンスをStringまたはDataBinderに変換できます。

例23-13のコードは、サービスを実行し、レスポンスを文字列として取得して、それをデータ・バインダに解析します。

例23-13 DataBinderへのStringの解析

// create request
DataBinder binder = idcClient.createBinder ();

// execute the service
ServiceResponse response = idcClient.sendRequest (userContext, binder);

// get the response stream
InputStream stream = response.getResponseStream ();

// get the response as a string
String responseString = response.getResponseAsString ();

// parse into data binder
DataBinder dataBinder = response.getResponseAsBinder ();

23.8 バインダについて

バインダは、複数のリクエスト間で再利用できます。あるリクエストからのバインダを別のリクエストに送信できます。あるコールからのバインダを次のコールで再利用する場合、次のコールに影響する可能性のあるものがバインダに残っていないように、細心の注意を払う必要があります。RIDCは、各コールの後にバインダをクリーンアップしません。

例23-14のコードは、コンテンツ・サーバーへの複数のコールで同じバインダを再利用することで、検索結果をページングする例を示しています。

例23-14 バインダの再利用

// create the user context
IdcContext idcContext = new IdcContext ("sysadmin", "idc");

// build the search request binder
DataBinder binder = idcClient.createBinder();
binder.putLocal("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal("QueryText", "");
binder.putLocal("ResultCount", "20");

// send the initial request
ServiceResponse response = idcClient.sendRequest (binder, idcContext);
DataBinder responseBinder = response.getResponseAsBinder();

// get the next page
binder.putLocal("StartRow", "21");
response = idcConnection.executeRequest(idcContext, binder);
responseBinder = response.getResponseAsBinder();

// get the next page
binder.putLocal("StartRow", "41");
response = idcConnection.executeRequest(binder, idcContext);
responseBinder = response.getResponseAsBinder();

23.9 コンビニエンス・クラスについて

多数のアプリケーションがRIDCを使用して実行するアクションのパターンがいくつかあります。コンビニエンス・パッケージで、それらのパターンの一部が再利用のために提供されています。コンビニエンス・パッケージ領域内のクラスは、RIDCコードのコンシューマであり、そのため、新しい機能を追加することはありません。それらは、RIDCの上の新たなレイヤーと考えることができます。

23.9.1 ユーザー・セキュリティの設定

コンテンツ・サーバーには、コンテンツ・サーバー上の設定によって制御されるいくつかのセキュリティ・モデルがあります。特定のユーザーがあるドキュメントへのアクセス権を持っているかどうかを判断するには、ユーザーの権限コントロール、ドキュメントの権限コントロール、コンテンツ・サーバーのセキュリティ環境設定という3つのものが必要です。

UserSecurityモジュールをコールするアプリケーション・プログラムは、スーパーユーザーとして(ドキュメントのバインダ、通常は検索結果で)ドキュメントおよびDOC_INFOメタデータをフェッチし、その情報をキャッシュすると想定されます。アプリケーションで、特定のユーザーがドキュメントへのアクセス権を持っているかどうかを把握する必要がある場合、そのユーザーの権限をフェッチするために、そのユーザーとしてコンテンツ・サーバーへのコールが行なわれます。いったんユーザーの権限コントロールが把握されると、それらをドキュメントのメタデータ内の情報と照合してそのユーザーのアクセス・レベルを判断することができます。(アクセス・レベルは、READ、READ/WRITEまたはREAD/WRITE/DELETEです)。したがって、必要なのは、(キャッシュによって)コンテンツ・サーバーへのコール数を減らし、ユーザーの権限情報とドキュメントの権限情報を照合するデフォルトの実装を用意することです。さらに複雑化させる1つの要因は、コンテンツ・サーバーが一部のサーバー環境プロパティ(UseAccounts=trueおよびUseCollaboration=trueまたはUseEntitySecurity=1)でどのセキュリティのタイプが使用されるかを制御することです。さらに、メソッドによって、そのドキュメントのセキュリティ・タイプに管理者権限が割り当てられているかどうかをテストすることができます。

ユーザー・セキュリティ・コンビニエンスには、IUserSecurityCacheインタフェースを通じてアクセスできます。それらのクラスは、オプションのコンテンツ・サーバー・セキュリティを実装します。

- UserSGAcctAclCacheクラスは、常にコールする必要があります。このクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。

- UserSecurityGroupsCacheクラスは、ユーザー権限のキャッシュを保持し、セキュリティ・グループ情報のみを考慮してドキュメントを照合します。このクラスを直接コールしないでください。UserSGAcctAclCacheクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。

- コンテンツ・サーバーにUseAccounts=true設定がある場合、UserSGAccountsCacheクラスは、アカウント情報も考慮するためのリゾルバを追加します。このクラスを直接コールしないでください。UserSGAcctAclCacheクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。

詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

例23-15のコードは、ユーザー・セキュリティの設定の例を示しています。

例23-15 ユーザー・セキュリティの設定

IdcClientManager m_clientManager = new IdcClientManager ();
IdcClient m_client = m_clientManager.createClient
("http://localhost/scs/idcplg");

//RIDC superuser context
IdcContext m_superuser = new IdcContext("sysadmin", "idc");

//This class will self-adjust (downwards) to match the security model
// on the content server
IUserSecurityCache m_userSecurityCache = new UserSGAcctAclCache
(m_client, 20, 1000, 20000, m_superuser);
ITrace trace = null;

//Example test
testDocPermission () {
//If you don't want to do any logging, you can leave trace as null
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
trace = new Trace ();
}
DataBinder m_doc1 = getDataBinder ("TEST");
//Get the document information (typically in the first row of DOC_INFO)
DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0);
//Get the cache id for this user
//This makes a live call to content server to get the user ID for "Acme1"
//CacheId acme1 = m_userSecurityCache.getCacheIdForUser
//  (new IdcContext("Acme1", "idc"), trace);
IdcContext context = new IdcContext("Acme1", "idc");
CacheId acme1 = new CacheId (context.getUser (), context);
//Get the access level for this document by this user
int access = m_userSecurityCache.getAccessLevelForDocument
(acme1, docInfo, trace);
//Check if user has ACL admin permissions
boolean aclAdmin = m_userSecurityCache.isAdmin
(acme1, docInfo, IUserSecurityCache.AdminType.ACL, trace);
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
m_log.log (trace.formatTrace (), ILog.Level.TRACE);
}
}
//Example code to get a Document's DOC_INFO databinder
DataBinder getDataBinder (String dDocName) throws IdcClientException {
DataBinder dataBinder = m_client.createBinder ();
dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME");
dataBinder.putLocal ("dDocName", dDocName);
ServiceResponse response = m_client.sendRequest (m_superuser, dataBinder);
return response.getResponseAsBinder ();
}
//Example code to create a DataObject
DataObject dataObject = m_client.getDataFactory ().createDataObject ();
dataObject.put ("dSecurityGroup", "public");
dataObject.put ("dDocAccount", "Eng/Acme");

内部的に、ドキュメントからのこれらのフィールドは、getAccessLevelForDocument()の間に調査されます。

- AccessResolverSecurityGroupsクラスの場合: dSecurityGroup

- AccessResolverAccountsクラスの場合: dDocAccount

- AccessResolverSecurityGroupsクラスの場合: xClbraUserList、xClbraAliasListおよびxClbraRoleList

IAccessResolverクラスは、コンテンツ・サーバーからキャッシュされた情報に基づいて参加するかどうかを決定します。参加する場合、複数のアクセス・レベルは論理積(AND)になります。hasAdmin()メソッドを使用して、管理アクセス権があるかどうかを判断できます。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。

23.9.2 ADF接続ファサードの設定

Remote Intradoc Client (RIDC)バージョン11.1.1.6.0には、AdfConnectionFacadeコンビニエンス・クラスが含まれています。このクラスは、接続の詳細を格納し、idcClientオブジェクトを取得し、ユーザー資格証明オブジェクトを作成するための簡単な方法を提供します。また、JDeveloper拡張機能において接続UIも提供します。

注意:
この機能は、RIDCアプリケーションが適切なADFライブラリでプロビジョニングされたshiphomeにデプロイされている場合のみ使用可能です。

例23-16のコードは、example1という名前の接続に対するファサードをフェッチし、接続できるかどうかを確認するテストを実行します。

例23-16 ファサードのフェッチとテストの実行

AdfConnectionFacade facade = new AdfConnectionFacade ("example1");
boolean ok = facade.testConnection ("user").isSuccess()
//or
AdfConnectionFacade.ResultTestConnection testResult =
facade.testConnection ("user");
if (!testResult.isSuccess ()) {
throw new IdcClientException (testResult.getMessage ());
}

パラメータ名に対して<Credentials Label>.<Credentials Type>.<Field Name>というネーミング・パターンに従うことで、Jdeveloper UIにユーザー資格証明を追加できます。

次に例を示します。

admin1.basic.name
admin1.basic.password

facade.getUserCredentials("admin1")を使用すると、移入されたBasicCredentialsクラスが返されます。

public.nameonly.name

facade.getUserCredentials("public")を使用すると、移入されたUserNameOnlyCredentialsクラスが返されます。<default>の値を使用して、内部のデフォルト・ユーザー名を取得します。

myuser.adf.name

facade.getUserCredentials("myuser")を使用すると、AdfUserCredentialsクラスが返されます。

RIDCコールが行なわれると、ログイン・ユーザーが次のコードでフェッチされます。

ADFContext.getCurrent ().getSecurityContext().getUserName()

次の追加パラメータは、RIDCによって自動的に把握されます。

- connectionSize

- connectionWaitTime

- connectionPool

- socketTimeout

- useSystemProxy

- http.proxyHost

- http.proxyPort

- http.nonProxyHosts

- http.proxyUserName

- http.proxyPassword

- http.library

- sslKeystoreFile

- sslKeystorePassword

- sslAlgorithm

- sslKeystoreAlias

- sslKeystoreAliasPassword

- sslTrustManagerFile

- sslTrustManagerPassword

- clientSecurityPolicy

- jaxWsStack

- streamingChunkSiz

23.10 RIDCフィルタについて

Remote Intradoc Client (RIDC)バージョン11.1.1.4.0以上では、DataBinderが処理され、コンテンツ・サーバーに送信される前に、アプリケーション・コードでフィルタを追加することが可能です。IdcFilterAdapterクラスのいずれかを拡張してフィルタを作成し、そのフィルタを登録してIdcFilterManagerクラスで実行できます。フィルタは、登録時に指定された順番で実行されます。すでに登録済のフィルタを取得したり、削除したりすることもできます。

例23-17のコードは、アダプタを拡張し、アクションを実行するメソッドをオーバーライドします。

例23-17 サービス・リクエストの前のRIDCフィルタのコール

public class IdcFilterAddComment extends BeforeServiceRequestFilter {
@Override
public void beforeServiceRequest
(IdcClient client, IdcContext context, DataBinder binder)
throws IdcClientException {
String existingComments = binder.getLocal("xComments");
if (existingComments != null) {
binder.putLocal("xComments", String.format
("%s %s", existingComments, "--DGT WAS HERE--"));
} else {
binder.putLocal("xComments", "--DGT WAS HERE--");
}
}
}

Remote Intradoc Client (RIDC)バージョン11.1.1.5.0以降では、JAX-WS処理領域にさらに2つのフィルタの場所が提供されます。それらのフィルタを使用するには、BeforeJaxwsServiceFilterクラスを拡張します。

例23-18のコードは、BeforeJaxwsServiceFilterクラスを拡張します。

例23-18 JAX-WSコールの前のRIDCフィルタのコール

/**
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerLogin () in authenticateUser ()
**/
public void beforeJaxwsAuthenticateUser (IdcContext context, DataBinder binder,
Map<String, Object> requestContext) throws IdcClientException {
requestContext.put(oracle.wsm.security.util.SecurityConstants.
ClientConstants.WSM_SUBJECT_PRECEDENCE, “false”);
}

/**
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerRequest () in performServiceRequest ()
**/
public void beforeJaxwsServiceRequest (IdcContext context, DataBinder binder,
Map<String, Object> requestContext) throws IdcClientException {
//Override this class and implement your filter here
}

例23-19のコードは、フィルタ・クラス(複数可)を登録します。

例23-19 フィルタ・クラスの登録

// If you are at the start of a pure RIDC application, you typically
// will create a ClientManager, for example:
IdcClientManager m_clientManager = new IdcClientManager();

// New method added to IdcClient to get the ClientManager
// if you do not have the ClientManager instance:
IdcClient client = myClient;
client.getClientManager();

// From the ClientManager, you can get the FilterManager:
IdcFilterManager fmanager = m_clientManager.getFilterManager();

// Then register your filter:
IIdcFilter addCommentFilter = new IdcFilterAddComment();
int slot = fmanager.registerFilter(100, addCommentFilter);

// Optionally, you can deregister. However, it might not be in the slot you
// assigned because there might have already been a filter in that slot.
// When registering, the next available higher slot will be used. You also need
// to pass in the instance currently in the slot you want to remove:
fmanager.deRegisterFilter(slot, addCommentFilter);

// Here is an example to remove all the filters,
// including the ones you did not register
for (Integer slot:fmanager.getUsedSlots()) {
fmanager.deRegisterFilter(slot, fmanager.getFilter (slot));
}

23.11 RIDC JDeveloper拡張機能の使用

Remote Intradoc Client (RIDC)通信APIは、Oracle JDeveloperのデプロイ可能な拡張機能として提供されています。RIDC JDeveloper拡張機能は、JDeveloper環境にRIDCライブラリのコピーを配置します。

必要なバージョンと拡張機能

次のJDeveloperバージョンとRIDC拡張機能が必要です。

- Oracle Remote Intradoc Client (RIDC)拡張機能11.1.1.6 (11gR1 PS5)

- Oracle JDeveloperバージョン11.1.1.6 (11gR1 PS5)

Oracle Remote Intradoc Client (RIDC)拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)は、Remote Intradoc Client (RIDC)スイート・ディストリビューション(ridc-suite-11.1.1.6.zip)の/modules/jdevディレクトリにあります。RIDCスイート・ディストリビューションは、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。

23.11.1 RIDC拡張機能のデプロイ

Oracle JDeveloperにRIDC拡張機能をデプロイするには、次の手順を実行します。

1. Oracle Technology Network (OTN)からRemote Intradoc Client (RIDC)スイート・ディストリビューションをダウンロードします。

2. RIDCスイート・ディストリビューション(ridc-suite-11.1.1.6.zip)を、Oracle JDeveloperインスタンスをホストしているシステムの場所にアンバンドルします。

3. JDeveloperのメイン・メニューから、「ヘルプ」→「更新の確認」を選択します。

4. 「ローカル・ファイルからインストール」オプションを有効にします。

5. 「参照」をクリックして、アンバンドルされたRIDCスイート・ディストリビューション(ridc-suite-11.1.1.6.zip)にナビゲートします。

6. /modules/jdevディレクトリにあるRIDC拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)を選択し、「開く」をクリックします。

7. 「次へ」をクリックして、拡張機能をデプロイします。

8. 「終了」をクリックします。

JDeveloperにより拡張機能がインストールされたら、「ツール」→「プリファレンス」→「拡張機能」を選択して、RIDCライブラリからJDeveloperにアクセスできることを確認し、RIDCエントリにスクロールします。RIDCライブラリがディスク上に存在することを確認するには、<JDeveloper Home>/jdeveloper/ucm/Distribution/RIDCディレクトリをチェックし、次のファイルが存在することを確認します。

+-- lib
¦ +-- commons-codec-1.2.jar
¦ +-- commons-httpclient-3.1.jar
¦ +-- commons-logging-1.0.4.jar
¦ +-- httpclient-4.1.1.jar
¦ +-- httpcore-4.1.jar
¦ +-- httpmime-4.1.1.jar
+-- oracle.ucm.ridc-11.1.1.jar
+-- oracle.ucm.ridc.app-lib-11.1.1.ear

23.11.2 RIDCテクノロジが備わった新しいアプリケーションとプロジェクトの作成

この項では、新しいアプリケーションとプロジェクトを作成し、RIDCテクノロジを追加して、共有ライブラリ参照を検証する手順について説明します。RIDCテクノロジを既存のプロジェクトに追加するのではなく、新しいRIDC対応プロジェクトを作成することをお薦めします。

RIDCテクノロジが備わった新しいアプリケーションとプロジェクトを作成する手順は次のとおりです。

1. メイン・メニューから、「ファイル」→「新規」を選択します。
「新規ギャラリ」ダイアログが開きます。

2. 「カテゴリ」で、「一般」→「アプリケーション」を選択します。

3. 「アイテム」で、「汎用アプリケーション」を選択します。

4. 「OK」をクリックします。
汎用アプリケーションの作成ウィザードが表示されます。

5. アプリケーション名を指定します。

6. デフォルト・ディレクトリを受け入れるか、別のディレクトリを指定します。

7. 「次へ」をクリックします。

8. これがRIDC対応プロジェクトであることがわかるようなプロジェクト名を指定します。

注意:
プロジェクト名には、アポストロフィ( ' )やアスタリスク( * )などの特殊文字を使用しないでください。

9. 「プロジェクト・テクノロジ」タブで、リストからRIDC、「HTML」および「JSPとサーブレット」を選択し、シャトル・ボタンをクリックして、選択したものをそれぞれ「選択済」リストに転送します。

10. 「次へ」をクリックします。

11. 設定を確認して「終了」をクリックします。

共有ライブラリ参照を検証する手順は次のとおりです。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。

3. 「ディスクリプタ」→META-INFを開きます。

4. weblogic-application.xmlを右クリックしし、「開く」を選択します。

5. エディタで、「概要」タブを選択します。

6. 「ライブラリ」を選択し、「共有ライブラリ参照」を開きます。

7. ライブラリ名oracle.ucm.ridc.app-libがリストされていることを確認します。

23.11.3 接続の処理

この項では、接続を処理するための様々な手順について説明します。接続の処理の詳細は、JDeveloperオンライン・ヘルプのRIDCに関する項を参照してください。

JDeveloper 11gでは、接続を作成して管理するための2つの方法があります。アプリケーションのコンテキストで使用される接続(アプリケーション・リソース接続と呼ばれます)を定義することも、IDE全体としての接続(IDE接続と呼ばれます)を定義することもできます。同じダイアログを使用してこれらの接続の両方を定義できますが、JDeveloper内でのそれらの有効範囲は異なります。

アプリケーション・リソース: これらの接続の有効範囲はローカルで、そのアプリケーション内でのみ使用可能です。接続情報は、アプリケーション自体に格納され、アプリケーションとともにデプロイできます。これらのタイプの接続は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「接続」ノードの下にリストされます。

IDE接続: これらの接続は、グローバルに定義され、再利用可能です。これらのタイプの接続は、リソース・パレットの「IDE接続」パネルにリストされます。アプリケーション・ナビゲータにIDE接続をコピーして、アプリケーション内でそれらを使用することができます。

新しいコンテンツ・サーバー接続を作成する手順は次のとおりです。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。

3. 「接続」を右クリックし、「接続の作成」→RIDCを選択します。

4. 「コンテンツ・サーバー接続の作成」ダイアログを使用して、新しい接続を作成します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。

5. 「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。

6. 「OK」をクリックします。

アプリケーション・リソース接続を編集または更新します。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。

3. 「接続」→RIDCを開きます。

4. 接続を右クリックし、「プロパティ」を選択します。

5. 「コンテンツ・サーバー接続の編集」ダイアログを使用して、接続の詳細を編集または更新します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。

6. 「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。

7. 「OK」をクリックします。

IDE接続を編集または更新します。

1. メイン・メニューから、「表示」→「リソース・パレット」を選択します。

2. 「リソース・パレット」で、「IDE接続」パネルを選択します。

3. RIDCノードを開きます。

4. 接続を右クリックし、「プロパティ」を選択します。

5. 「コンテンツ・サーバー接続の編集」ダイアログを使用して、接続の詳細を編集または更新します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。

6. 「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。

7. 「OK」をクリックします。

RIDCテクノロジが備わったアプリケーションにIDE接続を追加する手順は次のとおりです。

1. メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。

2. ドロップダウン・リストから、RIDCテクノロジが備わったアプリケーションを選択します。

3. メイン・メニューから、「表示」→「リソース・パレット」を選択します。

4. 「リソース・パレット」で、「IDE接続」パネルを選択します。

5. RIDCノードを開きます。

6. 接続を右クリックし、「アプリケーションに追加」を選択します。
注意: 接続は、JDeveloperで現在開かれているアプリケーションに追加されます。接続は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「接続」ノードの下にリストされます。

23.11.4 サービス・コールの例

この項では、JSPページ上のサービス・コールのサンプル・コードを示します。これらの手順は、RIDC対応のプロジェクトに対してJSPページが作成済であることを前提としています。詳細は、JDeveloperオンライン・ヘルプのRIDCに関する項を参照してください。

JSPページへの次のJSPディレクティブを使用して、必要なJavaパッケージおよびクラスをインポートします。

<%@ page import="oracle.stellent.ridc.*"%>

<%@ page import="oracle.stellent.ridc.model.*"%>

<%@ page import="oracle.stellent.ridc.model.impl.*"%>

<%@ page import="oracle.stellent.ridc.convenience.adf.connection.*"%>

例23-20のコードは、JSPページのボディに追加されるサービス・コールの例を示しています。

例23-20 サービス・コールのサンプル・コード

<h1>Example of service call</h1>
<%
AdfConnectionFacade facade = new AdfConnectionFacade("demo");
AdfConnectionFacade.ResultTestConnection rtest; rtest =
facade.testConnection("user");

if (!rtest.isSuccess()) {
%>
<h3>Content server not available because</h3>
<p><%=rtest.getmessaage()%></p>
<%
} else {
IdcClient client = facead.getIdcClient();
IdcContext ctx = new IdcContext(facade.gtUserCredentials("user"));

DataBinder binder = client.createBinder();
binder.putLocal("IdcService", "GET_USER_PERMISSIONS");
DataBinder r = client.sendRequest(ctx, binder).getResponseAsBinder();
%>
<pre><%=(DataBinderImpl)r%></pre>
<% } %>

24 コンテンツ・サーバーのJCRアダプタの使用

この章では、Oracle WebCenter Content ServerのJava Content Repository (JCR)アダプタの使用方法について説明します。

この章では、次の項目について説明します。

- 第24.1項「Java Content Repositoryアダプタについて」

- 第24.2項「必要なAPIおよびランタイム・ライブラリのインストール」

- 第24.3項「JCRアダプタのデプロイ」

- 第24.4項「コンテンツ・サーバーとの通信の構成」

- 第24.5項「コンテンツ・アイテムに関する情報の検索」

- 第24.6項「検索索引の使用」

- 第24.7項「ファイル・ストア・プロバイダの使用」

24.1 Java Content Repositoryアダプタについて

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仕様を通じてコンテンツ・サーバーと通信することを可能にします。

24.1.1 JCRデータ・モデル

JCR標準は、拡張可能なノード・タイプおよびコンテンツ・プロパティに基づいた階層型のデータ・モデルを使用します。このデータ・モデルは、リポジトリの、基礎となるストレージ・サブシステムによって使用されます。詳細は、JCRおよびJSR-170標準を参照してください。

- nt:folderノード・タイプは、構造化されたノード・コレクションを表します。これは、多数のファイル・システムで採用されているディレクトリまたはフォルダのコンセプトに密接に関連しており、通常、ファイル・システム・ディレクトリをコンテンツ・リポジトリにマップするときに使用されるノード・タイプです。

- nt:resource子ノードは通常、追加のリソース・メタデータが必要な場合にプレーン・バイナリ・プロパティの代わりに使用されます。

- nt:fileノード・タイプは、何らかのコンテンツのあるファイルを表します。

- nt:unstructuredノード・タイプは、すべての種類のプロパティおよび子ノードをノードに追加することを許容します。これは通常、ノード内に格納されるコンテンツについて何も情報がないときに使用されます。

24.1.2 コンテンツ・サーバーのJCRアダプタ・データ・モデル

これは、次のような、コンテンツ・サーバーの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>

24.2 必要なAPIおよびランタイム・ライブラリのインストール

JCRアダプタは、JSR-170仕様をサポートするどのアプリケーションでも使用できますが、このアダプタでは、カスタム統合が必要です。このカスタム統合では、いくつかのAPIとランタイム・ライブラリで構成されている、基礎となるフレームワークがインストールされている必要があります。

注意:
JCRアダプタとRemote Intradoc Client (RIDC)を除いて、これらのAPIとランライム・ライブラリはすべて、Oracle JDeveloperおよびWebCenterで提供されています。

24.2.1 ADFラインタイム・ライブラリのインストール

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ディレクトリを作成する必要があります。)

24.2.2 Remote Intradoc Client (RIDC)のデプロイ

アプリケーションにRemote Intradoc Clientがデプロイされている必要があります。RIDCは、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供します。このAPIは、Oracle WebCenter Content Serverインスタンスへのデータ抽象化を除去する一方で、接続のプーリング、セキュリティおよびプロトコルの固有情報を処理するためのラッパーを引き続き提供します。RIDCは、JCRアダプタの配布ファイルに含まれており、Oracle Technology Network (OTN)で入手できます。

第23章「RIDCを使用したコンテンツ・サーバーへのアクセス」を参照してください。

24.2.3 JCR APIのデプロイ

アプリケーションにJava Content Repository (JCR) APIがデプロイされている必要があります。JCR APIは、Oracle JDeveloperに含まれています。または、The Apache Software FoundationのWebサイト(http://www.apache.org/)からダウンロードすることもできます。

JCR APIは、JSR-170仕様の一部でもあり、次のJava Community ProcessのWebサイトからダウンロードできます。

http://www.jcp.org/

24.2.4 JCR統合ライブラリのインストール

次のJCR統合ライブラリは必須であり、アプリケーションにデプロイされている必要があります。

- jcr-common-runtime.jar

- ojcr.jar

- ojdbc5.jar

これらのファイルは、Oracle JDeveloperインスタンスにあります。

24.2.5 XML統合ファイルのインストール

次のXML統合ライブラリは必須であり、アプリケーションにデプロイされている必要があります。

- xmlparserv2.jar

- xquery.jar

これらのファイルは、Oracle JDeveloperインスタンスにあります。

24.3 JCRアダプタのデプロイ

コンテンツ・サーバーとの通信を可能にするには、アプリケーションにJCRアダプタがデプロイされている必要があります。JCRアダプタは、基礎となるフレームワークの一部としてRemote Intradoc Client (RIDC)を利用し、一般的なJSR-170アーキテクチャと連携して機能します。

JCRアダプタのデプロイでは、それぞれのJSR-170準拠アプリケーションの一般的な指示に従ってください。JCRアダプタは、埋込みのデプロイメント・ディスクリプタ(rep_descriptor.xml)を使用します。デプロイメントでは、多くのアプリケーションがデプロイメント・ディスクリプタを使用して、管理インタフェースまたはデプロイメント・ウィザードの一部として構成エントリを移入します。アプリケーションで管理インタフェースまたはデプロイメント・ウィザードを使用していない場合、デプロイメント・ディスクリプタを直接編集し、必要な値を指定する必要があります。

24.4 コンテンツ・サーバーとの通信の構成

JCRアダプタとコンテンツ・サーバー間の通信を可能にするには、次の項目を構成します。

- 通信方法

- ソケット通信(リスナー・ポート)

- セキュア・ソケット通信(SSL)

- Web通信(Webサーブレット・フィルタ)

- ユーザー・エージェント

- キャッシュ設定

24.4.1 通信方法の指定

この構成設定では、プロバイダ名と通信方法を指定する必要があります。

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を使用する場合は、必須の構成値を指定する必要があります。

24.4.2 ソケット通信(リスナー・ポート)の構成

通信プロトコルとしてセキュア・ソケット通信(SSL)を使用する場合は、次の構成設定の値を指定する必要があります。

- SERVER_HOST_CONFIG: コンテンツ・サーバーが実行されているマシンのホスト名。デフォルト値はlocalhostです。

oracle.stellent.jcr.configuration.server.host

- SERVER_PORT_CONFIG: コンテンツ・サーバーがリスニングしているポート。デフォルト値は16200です。

oracle.stellent.jcr.configuration.server.port

24.4.3 セキュア・ソケット通信(SSL)の構成

通信プロトコルとしてセキュア・ソケット通信(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

ソケット通信の値については、第24.4.2項「ソケット通信(リスナー・ポート)の構成」を参照してください。

24.4.4 Web通信(Webサーバー・フィルタ)の構成

アプリケーションが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

24.4.5 ユーザー・エージェントの構成

オプションで、次の構成設定の値を指定して、JCRリクエストを識別することができます。

- CIS_USER_AGENT_CONFIG: RIDCユーザー・エージェントに添付する文字列。この値を設定すると、JCRアダプタによって行われるリクエストの識別に役立ちます。

oracle.stellent.jcr.configuration.cis.config.userAgent

24.4.6 キャッシュ設定の指定

オプションで、次のキャッシュ設定の値を指定できます。

- 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

24.5 コンテンツ・アイテムに関する情報の検索

コンテンツ・サーバーによって管理されるコンテンツは、主に次の4つの表によって追跡されます。

- Revisions

- Documents

- DocMeta

- RevClasses

これらの表は、コンテンツのメタデータ、状態およびアクションに加えて、各ファイルに関連付けられている情報も追跡します。

Revisions

この表は、コンテンツの各リビジョンに関する主要な情報を追跡します。

- リビジョンごとに1行

- 同じコンテンツIDおよびRevClass IDを共有し、同じコンテンツを持つ異なるリビジョン

- 各リビジョンのシステム・メタデータ

- リビジョンのメタデータ: コンテンツID、タイトル、作成者、チェックイン日など

- カテゴリ化およびセキュリティのメタデータ: タイプ、セキュリティ・グループ、ドキュメント・アカウント

- 様々なアクションの状態情報

- 索引の作成

- ワークフロー

- ドキュメント変換

- リビジョンの追跡と取得に役立つ数値IDとテキスト・ラベル

- 各リビジョンの一意のdID値(表内の主キー)

- コンテンツの一意のdRevClassID値

- 各リビジョンのリビジョン番号をマークするためのリビジョンID

Documents

この表は、各コンテンツ・リビジョンに関連付けられているファイルの情報を追跡します。

- リビジョンごとに1行

- リビジョンごとに複数行、次のファイルそれぞれに1行

- プライマリ

- 代替

- Web表示可能

- ファイル情報: 元の名前、場所、言語、サイズなど

DocMeta

この表には、拡張メタデータ・フィールドが含まれます。

- リビジョンごとに1行

- メタデータ・フィールドごとに1列

- DocMetaDefinition表に格納されている各フィールドの定義

RevClasses

この表は、各コンテンツ・リビジョンの情報を追跡します。

- コンテンツ・アイテムごとに1行

- コンテンツの変更がロックされた行

- 一意のdDocNameおよびRevClassId値

- 現在の索引付きリビジョン

- 日付およびユーザー

- 作成日および作成者

- 最終変更日およびユーザー

- 所有者

24.6 検索索引の使用

コンテンツ・サーバーは、リポジトリを検索するための様々な方法を提供します。メタデータの検索は、Revisions、Documents、DocMetaおよびRevClasses表に基づいて行うことができます。テキスト検索を効率的に実行するには、Oracle Databaseの全文検索機能を利用し、検索索引を保持するためのIdcText表を作成します。

IdcText

この表には、Revisions、Documents、DocMetaおよびRevClasses表から選択された列に加えて、他のデータの列も含まれます。

- Revisions、RevClassesおよびDocuments表からの事前定義リストが含まれます。

- DocMeta表からの、検索可能と示されているカスタム・メタデータが含まれます。

- OtsMeta列(CLOBフィールド)には、SDATAセクション、および他の列に存在しない追加の索引付け可能フィールドが含まれます。ただし、SDATAには大きな制限があります。

- OtsContent列には、索引付け可能なドキュメントが含まれます。

- ResultSetInterface列は、ソートやカウント予測、またはドリルダウンに使用できます。

24.7 ファイル・ストア・プロバイダの使用

ファイル・ストア・プロバイダを使用して、ファイル・システム、データベース、他のデバイス、またはこれら3つの任意の組合せで、コンテンツ・サーバーによって管理されるファイルを配布できます。ファイルは、Oracle WebCenter Content Server 11gのSecureFilesに格納されます。データベース支援のファイル・ストレージの場合、FileStorageおよびFileCache表に、各ファイルに関連した情報が格納されます。

FileStorage

この表には、ファイル情報と一部の追加情報が格納されます。

- BLOBフィールドに格納されるファイル(Oracle WebCenter Content Server 11gのSecureFiles)
データベース管理者は、追加のBLOB最適化を有効にすることができます。たとえば、SecureFilesによる重複排除、圧縮、暗号化などです。

- コンテンツ・サーバーによって管理される特定のファイルを指すdIDおよびdRenditionID

- 少数のフィールドの追跡情報: 最終変更日およびファイル・サイズ

FileCache

この表には、ファイル・システムにキャッシュされているファイル、特定のタイプの処理(抽出、変換など)およびWebサーバーによるクイック・アクセスのためのポインタが格納されます。このポインタは、クリーンアップの実行にも使用されます。

25 WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成

この章では、WSDLおよびSOAPファイル(これらを使用してOracle WebCenter Content Severを管理します)を使用して、Oracle WebCenter Contentをクライアント・アプリケーションに統合する方法について説明します。また、コンテンツ・サーバーの機能にアクセスするための統合テクノロジを提供するWSDLジェネレータ・コンポーネントの使用方法についても説明します。

この章では、次の項目について説明します。

- 第25.1項「WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成について」

- 第25.2項「SOAPクライアントを使用したコンテンツ・サーバーへのアクセス」

- 第25.3項「SOAPを使用したコンテンツ・サーバー・サービスのコール」

- 第25.4項「Active Server PageにおけるSOAPパケットの使用」

- 第25.5項「WebCenter ContentにアクセスするためのWSDLファイルの生成」

- 第25.6項「WSDLファイルのカスタマイズ」

コンテンツ・サーバーで使用できるWebサービスの一般的な情報については、第18.2項「Webサービスの概要」を参照してください。この章で説明されているWebサービスの使用方法は、Oracle Universal Content Management 10gで導入されました。WebCenter Content Webサービスを、セキュリティが構成され、Security Assertion Markup Language (SAML) (Oracle Universal Content Management 11gで導入されました)がサポートされている状態で使用する場合は、第19章「統合のためのWebCenter Content Webサービスの構成」を参照してください。

Webサービスをいずれの方法で使用した場合でも、セキュリティのためにOracle Web Services Manager (Oracle WSM)を使用することができます。Oracle WSMの詳細は、Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイドを参照してください。

25.1 WSDL、SOAPおよびWSDLジェネレータを使用したWebサービスの構成について

Web Services Definition Language (WSDL)およびSOAP (Simple Object Access Protocol)ファイルを使用して、クライアント・アプリケーションからコンテンツ・サーバーを管理できます。SOAPは、Webサービス・リクエストおよびレスポンス・メッセージをネットワーク経由で送信する前にそれらの中の情報をエンコードするための、軽量のXMLベース・メッセージング・プロトコルです。

WSDLジェネレータ・コンポーネントWsdlGenerator(これは、コンテンツ・サーバーにデフォルトでインストールされ有効化されます)は、コンテンツ・サーバーのサービスのためのWSDLを生成します。WSDLを取得し、それをAPIにプラグインして、コンテンツ・サーバーで使用するためのWebサービスを作成できます。

一部のSOAP機能は、コアのコンテンツ・サーバーに組み込まれています。SOAPの使用にWSDLジェネレータ・コンポーネントが不可欠というわけではありません。管理者は、必要に応じて、SOAPでコンテンツ・サーバーへのサービス・コールを記述することができます。WSDLジェネレータを使用すると、既存のクライアント・アプリケーションを柔軟に変更できるようになります。

WebCenter Contentには、WebCenter Content IDCService (Internet Distributed Content Service)を公開するWSDL 1.1実装があり、WebCenter Content IDCServiceは、コンテンツ・サーバーのすべての機能を拡張します。IDCServiceを使用して、次のいずれのタスクも実行できます。

- コンテンツをチェックインまたはチェックアウトする

- ワークフローを作成、実行または承認する

- コンテンツを公開できるようにする

- コンテンツを、カテゴリ(メタデータ)、コンテンツ(全文)またはそれらの組合せによって検索する

WSDLファイルを使用してWebCenter ContentおよびSOAPにマップし、WebCenter Content内のコンテンツおよびコンテンツ管理機能にアクセスし、コンテンツ管理機能をWebサービスとしてデプロイすることができます。または、SOAPでコンテンツ・サーバーへのサービス・コールを記述することができます。

25.1.1 Webサービス・フレームワーク

Webサービスのコアとなる実現技術は、次のようなものです。

- XMLデータ

- WSDLインタフェース

- SOAP通信

- UDDIレジストリ

25.1.1.1 XMLデータ

eXtensible Markup Language (XML)は、すべてのWebサービス・テクノロジの基礎を提供する一まとまりの仕様です。XML構造および構文を基礎として使用することで、様々なプログラミング言語、ミドルウェアおよびデータベース管理システム間でデータを交換することが可能になります。

XML構文には、インスタンス・データ、型付け、構造、およびデータに関連するセマンティック情報が組み込まれます。XMLでは、データは独立して記述され、データをソフトウェア・システムまたはプログラミング言語にマップするための情報も提供されます。この柔軟性があるため、どのソフトウェア・プログラムでもWebサービスにマップできます。

Webサービスが起動されると、基礎となるXML構文により、交換されたデータのためのデータ・カプセル化および送信フォーマットが提供されます。XML要素および属性は、データの型と構造に関する情報を定義します。XMLは、データをモデリングする機能を提供し、プログラミング言語(Java、C#、Visual Basicなど)、データベース管理システムまたはソフトウェア・アプリケーションに固有の構造を定義します。Webサービスは、XML構文を使用して、データがどのように表現され、データがどのように送信され、サービスがどのように参照アプリケーションと対話するのかを指定します。

25.1.1.2 WSDLインタフェース

Web Services Description Language (WSDL)は、Webサービスに公開されるインタフェースを提供します。WSDLレイヤーにより、Webサービスを、基礎となるプログラムおよびソフトウェア・システムにマップできるようになります。WSDLファイルは、Webサービスへの接続方法とその使用方法が記述されたXMLファイルです。

25.1.1.3 SOAP通信

Simple Object Access Protocol (SOAP)は、Webサービス・インタフェースがネットワーク経由で相互に通信するためのコンテンツ・サーバー通信を提供します。SOAPは、Webサービスへのアクセスに使用されるXMLベースの通信プロトコルです。Webサービスは、XMLドキュメント内にカプセル化されたSOAPパケットを使用して、リクエストを受信し、レスポンスを返します。

25.1.1.4 UDDI レジストリ

Universal Description Discovery and Integration (UDDI)サービスは、Webサービス・インタフェースの格納と取得のためのレジストリおよびリポジトリ・サービスを提供します。UDDIは、Webサービスの登録および検索のためのパブリックまたはプライベートのXMLベース・ディレクトリです。

コンテンツ・サーバーは現在、いずれのパブリックまたはプライベートUDDIソースにも公開されません。ただし、このことにより、コンテンツ・サーバーを、Webサービスを使用する他のアプリケーションと統合できなくなるわけではありません。

25.1.1.5 DIMEメッセージ・フォーマット

DIMEは、任意のタイプとサイズの、アプリケーションで定義された1つ以上のファイル・コンテンツ・グループを単一のメッセージ構成にカプセル化するために使用できる軽量のバイナリ・メッセージ・フォーマットです。コンテンツのアップロードまたはダウンロードで、このフォーマットを使用できます。ペイロードは、SOAPメッセージおよび1つ以上のファイル・コンテンツ・グループで構成されています。

25.1.1.6 実現技術を連携させる方法

XML、WSDL、SOAPおよびUDDIテクノロジは、Webサービス・プロトコル・スタック上のレイヤーとして連携して機能します。図25-1に示すように、Webサービス・プロトコル・スタックは、次のレイヤーで構成されています。

- アプリケーション間のトランスポート・レイヤー(HTTP)

- 一般的な通信方法を提供するメッセージング・レイヤー(XMLおよびSOAP)

- 特定のWebサービスへのパブリック・インタフェースを記述するサービス記述レイヤー(WSDL)

- Webサービス・インタフェースの格納と取得のためのレジストリおよびリポジトリ・サービスを提供するサービス検出レイヤー(UDDI)

図25-1 Webサービス・プロトコル・スタックのレイヤー

注意:
トランスポート・レイヤーでは、いくつかのプロトコル(HTTP、SMTP、FTP、BEEPなど)が使用できますが、HTTPプロトコルがもっとも一般的に使用されています。WSDLジェネレータ・コンポーネントは、トランスポート・レイヤーとしてHTTPプロトコルに依存します。

これらのテクノロジ間の接続を理解しやすくするため、単純な例えで考えてみましょう。つまり、HTTPを電話回線(アプリケーション間のトランスポート)として捉え、UDDIを電話帳(開発者はUDDIレジストリを参照して登録済のサービスを検索できます)として捉えます。この例えでは、SOAPは人々が電話で話す声(情報の交換)、XMLは人々が話す言語(データ交換の基礎となる構造)と見なすことができます。電話の例えで続けるなら、WSDLは、特定のWebサービスをコールするための電話番号になります(もちろん、WSDLには使用可能な機能やデータ型などの情報が含まれているため、WSDLは単なる電話番号以上のものです)。

25.1.1.7 実装のアーキテクチャ

Webサービスは、実行可能ファイルではありませんが、開発環境内でデータを交換します。そのため、Webサービスは、データを交換するプログラム間で通信を実行するアプリケーション・サーバーまたはソフトウェア・パッケージと情報を交換する手段となります。

図25-2は、コンテンツ・サーバー・アプリケーションのためのWebサービス実装アーキテクチャを示しています。このアーキテクチャのプライマリ値は、コンテンツ・サーバーの機能において保持されます。Webサービスは、WSDLジェネレータを通じてコンテンツ・サーバーにアクセスし、公開されたコンテンツ・サーバー・サービスを使用してアクションを実行し、ユーザーが使用するWebサービスとコンテンツ・サーバー間のデータ・トランザクションを提供します。

図25-2 Webサービスの実装アーキテクチャ

25.1.1.8 .NET上の実装

Microsoft .NET製品(.NETプラットフォーム、.NET Framework、Visual Studio .NETなど)はすべて、XMLスキーマ、WSDLおよびSOAP仕様をサポートしています。

- .NETプラットフォームは、開発者がXML Webサービスおよびアプリケーションを構築できるようにするプログラミング・モデルとして設計されています。このプラットフォームは、XML Webサービスおよびアプリケーションを統合、実行および管理する一連のサービスを提供します。

- .NET Framework製品は、開発者がWebサービスおよびアプリケーションを構築してデプロイすることを可能にします。これは、Webサービスを統合するための構造化環境を提供し、一般的な言語ランタイムと統合クラス・ライブラリで構成されています。また、これには、ASP .NETサーバーが組み込まれています。

- Visual Studio .NET製品は、開発者がXMLベースのWebサービス仕様に従ってアプリケーション・ソフトウェアを作成するためのツールを提供します。

.NETアーキテクチャを使用して、Webサービスの開発とデプロイは1つのステップとして統合されます。.NET言語で作成されたすべてのプログラムはWebサービスとして機能するように設計されているため、.NETサーバーは、プログラムをWebサービスとして作成およびデプロイすることが可能です。

25.1.1.9 SOAPプロトコル

SOAPは、次のパーツで構成されている、XMLベースのメッセージング・プロトコルです。

- メッセージの内容とその処理方法を定義するエンベロープ

- アプリケーション・データ型を定義する一連のエンコーディング・ルール

- リモート・プロシージャ・コールおよびレスポンスを表すための規則

SOAP統合を使用すると、Java API (IdcCommand)を使用してコンテンツ・サーバー・サービスを実行するための標準化されたインタフェースが提供され、コンテンツ・サーバーによって管理されるXMLおよび非XMLコンテンツが提供されます。

SOAPは、データ送信にHypertext Transfer Protocol (HTTP)を使用するため、Web経由で起動でき、プラットフォームと言語に依存しない方法でネットワーク経由でコンテンツにアクセスできるようにします。

25.2 SOAPクライアントを使用したコンテンツ・サーバーへのアクセス

SOAPを使用してコンテンツ管理機能にWebサービスとしてアクセスすることで、アプリケーション間でリアルタイムにプログラムによる対話を行うことができ、ビジネス・プロセスの統合が可能になり、情報交換を容易に行えます。

注意:
SOAPクライアント実装を開発する場合は、クライアントAPIコードでチャンクを無効にしてください。

Webサービスは、XMLラッパーに含まれており、かつWSDL仕様で定義されているモジュラ・コンポーネントです。UDDI Webベース・レジストリ・システムは、それらのサービスの検索に使用されます。

ヒント:
.NETサーバーは、WSDLをサポートし、SOAP Toolkitと統合できますが、SOAPパケットがリモート・プロシージャ・コール(RPC)を送信するように指定する必要があります。デフォルトでは、SOAPメッセージは、RPCスタイルのSOAPメッセージとしてではなく、ドキュメント・スタイルのSOAPメッセージとして評価されます。SOAP Toolkitクライアントを.NETで開発されたWebサービスとともに使用すると、WSDLドキュメントの読取りエラーが返されます。SOAP Toolkitで、生成されたWSDLを読み取り、.NET Webサービスをコールできるようにするには、Webサービス・クラスでSoapRpcService()属性を指定する必要があります。

25.2.1 Java SOAPクライアントの使用

Java SOAPクライアントでは、表25-1に示されているコマンドライン・パラメータを使用できます。

表25-1 Java SOAPクライアントのコマンドライン・パラメータ

パラメータ

説明

-c config file

サーバー設定(ホストやポートなど)を含む構成ファイル

-x xml file

コンテンツ・サーバーに渡すSOAPリクエストを含むXMLファイル

-p primary file

アップロードするプライマリ・ファイルのファイル名

-a alternate file

アップロードする代替ファイルのファイル名(オプション)

-l log file

リクエストおよびレスポンス・データを含むファイルのファイル名(オプション)

25.3 SOAPを使用したコンテンツ・サーバー・サービスのコール

SOAPインタフェースを使用して、様々なコンテンツ・サーバーのIdcCommandサービスを実行できます。ユーザーIDには、コマンドを実行するための適切な権限が必要です。管理者アクセスを必要とするコマンドもあれば、書込み権限のみを必要とするコマンドもあります。

WSDLジェネレータ・コンポーネントは、コンテンツ・サーバーにデフォルトでインストールされ有効化されます。サービスをコールするには、これを有効な状態にしておく必要があります。使用可能なサービスと必須パラメータのリストについては、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

25.3.1 SOAPパケットのフォーマット

SOAPリクエストは、HTTPトランスポート・プロトコルを使用して送信されるXMLベースのリモート・プロシージャ・コール(RPC)です。SOAPパケットのペイロードは、実行されるコールと渡されるパラメータを指定するXMLドキュメントです。

25.3.1.1 HTTPヘッダー

SOAPリクエストのHTTPヘッダーでは、次のエントリが必要です。

Content-Type: text/xml; charset="utf-8"

次のSOAPActionヘッダーが推奨されますが、必須ではありません。

SOAPAction: "http://www.oracle.com/IdcService"

25.3.1.2 ネームスペース

SOAPメッセージのボディ内では、ドキュメントの各部分の要素および属性名を修飾するためにXMLネームスペースが使用されます。要素名は、グローバルとする(SOAPメッセージ全体で参照されます)ことも、ローカルとすることもできます。ローカルの要素名は、ネームスペースによって提供され、その名前は、それが存在するメッセージの特定部分で使用されます。そのため、SOAPメッセージは、ネームスペースを使用して、メッセージの別の部分の要素名を修飾します。アプリケーション固有のネームスペースは、アプリケーション固有の要素名を修飾します。ネームスペースはまた、エンベロープのバージョンとエンコーディング・スタイルも識別します。

コンテンツ・サーバーは、SOAPコンテンツのスキーマと許容されるタグを説明する、idcと呼ばれるネームスペースを定義します。

25.3.1.3 ノード

SOAPノードは、SOAPバインディングを通じて基礎となるプロトコルによって提供されるサービスにアクセスするためのルールに従ってSOAPメッセージを処理するエンティティです。したがって、メッセージの処理には、基礎となるサービスへのマッピングが含まれます。SOAP仕様は、SOAPメッセージの部分と、メッセージの各部分を処理するソフトウェア・ハンドラ間の相関関係を定義します。

次のノードは、サービス・リクエストで必要になったり、レスポンスで返されたりする可能性があります。

- serviceノード

- documentノード

- userノード

- optionlistノード

- IDC optionlistノード内のoptionサブノード

- resultsetサブノード

- rowサブノード

- fieldサブノード

注意:
コンテンツ・サーバー・サービスは、リクエストにおいてデータが指定されている場所については柔軟に対応します。fieldノードにデータ・フィールドを指定し、かつそれがdocument属性と想定される(またはその逆の)場合でも、サービスは、データを正しく処理します。レスポンスは、データを正しいノードに配置します。

25.3.1.3.1 serviceノード

IDCネームスペース内のメイン・ノードである<idc:service>ノードには、次の要件があります。

- リクエストが処理されるためには、このノードが存在している必要があります。

- 必須属性IdcServiceは、リクエストしているサービスを定義します。

- <idc:service>のサブノードでは、そのタグ内にネームスペースが含まれている必要はありません。
たとえば、<idc:document>ではなく、<document>を使用できます。ただし、子ノードでネームスペース識別子を定義する場合、serviceタグ内に指定されている識別子と一致させる必要があります。

例25-1は、PING_SERVERサービス・リクエストが指定された<idc:service>ノードを示しています。

例25-1 IDCネームスペースにおけるserviceノード

<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="PING_SERVER">
</idc:service>

25.3.1.3.2 documentノード

<document>ノードには、すべてのコンテンツ・アイテム情報が含まれており、このノードは、すべてのデータ・ノードの親になります。

コンテンツ・アイテムに対して有効な属性は、特定のコンテンツ・サーバーによって定義されます。たとえば、dID、dDocTitleおよびdDocTypeは、共通属性です。<document>ノードには、次のルールが適用されます。

- カスタムのコンテンツ・アイテム情報(xSpecなど)は、それがメタデータとして定義されている場合は有効です。

- すべての既知のdocumentフィールドは、属性として使用できます。

例25-2は、CHECKOUT_BY_NAMEサービスを使用する<document>ノードを示しています。

例25-2 IDC serviceノード内のdocumentノード

<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKOUT_BY_NAME">
<idc:document dDocName="soap_sample">
</idc:document>
</idc:service>

25.3.1.3.3 userノード

<user>ノードには、すべてのユーザー情報が含まれます。<user>ノードには、次のルールが適用されます。

- ユーザーに対して有効な属性は、特定のコンテンツ・サーバーによって定義されます。たとえば、dName、dFullNameおよびdEmailは、共通属性です。

- カスタムのユーザー情報は、それがメタデータとして定義されている場合は有効です。

- すべての既知のuserフィールドは、属性として使用できます。

例25-3は、GET_USER_INFOサービス・リクエストのユーザーを指定する<user>ノードを示しています。

例25-3 IDC serviceノード内のuserノード

<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_USER_INFO">
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>

25.3.1.3.4 optionlistノード

<optionlist>ノードには、任意のオプション・リストが含まれます。name属性は、オプション・リストの名前を指定します。各<option>サブノードには、<optionlist>ノード内の値が含まれます。

例25-4は、ロケール値を持つ<option>サブノードがある<optionlist>ノードを示しています。

例25-4 ロケールのoptionlistノード

<idc:optionlist name="Users_UserLocaleList">
<idc:option>
English-US
</idc:option>
</idc:optionlist>

25.3.1.3.5 IDC optionlistノード内のoptionサブノード

<option>サブノードは、<optionlist>ノード内に指定されます。option属性は、オプション・リストのオプションの名前を指定します。

例25-5は、dDocType値が指定された<option>ノードを示しています。

例25-5 optionlistノードのoptionサブノード

<idc:optionlist name="dDocType">
<idc:option>ADACCT</idc:option>
<idc:option>ADHR</idc:option>
<idc:option>ADSALES</idc:option>
</idc:optionlist>

25.3.1.3.6 resultsetサブノード

<resultset>サブノードは、<document>または<user>ノード内に指定することができます。このサブノードには、リクエストまたはレスポンス内の結果セットの情報が含まれます。name属性は、結果セットの名前を指定します。

例25-6では、リビジョン履歴を含む結果セットの<resultset>サブノードを指定します。

例25-6 リビジョン履歴のresultsetサブノード

<idc:resultset name="REVISION_HISTORY">
<idc:row dFormat="text/plain" dInDate="4/12/02 1:27 PM" dOutDate="" dStatus="RELEASED" dProcessingState="Y" dRevLabel="1" dID="6" dDocName="stellent" dRevisionID="1">
</idc:row>
</idc:resultset>

25.3.1.3.7 rowサブノード

<row>サブノードは、<resultset>サブノード内で指定されます。<resultset>サブノードは、複数の<row>サブノードを持つことができます。各<row>サブノードは、結果セット内の行を指定します。

有効な属性は、特定のコンテンツ・サーバーによって定義されます。有効な属性は、<document>または<user>ノード内の属性として表示できるものと同じフィールドです。

例25-7では、user属性の結果セット内の行を指定します。

例25-7 resultsetサブノードのrowサブノード

<idc:resultset name="UserAttribInfo">
<idc:row dUserName="jsmith" AttributeInfo="role,contributor,15">
</idc:row>
</idc:resultset>

25.3.1.3.8 fieldサブノード

<field>サブノードは、<document>、<user>または<row>ノード内に指定することができます。name属性は、フィールドの名前を指定します。<field>サブノードは多くの場合、refreshSubjectsやdSubscriptionIDなどのデータを表します。

<field>サブノードは、ユーザーが構成できるドキュメントまたはユーザー・メタデータを表すことができます。または、xCommentsなどのカスタム・メタデータを表すこともできます。例25-8では、サブスクリプションIDデータを表すfieldサブノードを指定します。

例25-8 メタデータを表すfieldノード

<idc:field name="dSubscriptionID">
stellent
</idc:field>

<field>サブノードの別の使用法としては、例25-9に示されているように、QueryTextやOriginalQueryTextなどのフィールドの検索結果値を渡すことがあります。

例25-9 値を渡すためのfieldサブノード

- <idc:field name="QueryText">
dDocType <Substring> "ADSALES&"
</idc:field>

25.3.2 特殊文字

左山カッコ(<)や右山カッコ(>)などの特殊文字をWebCenter Contentに渡すときは、表25-1に示すXMLエンコーディング・フォーマットを使用する必要があります。

表25-2 特殊文字のフォーマット

標準フォーマット

XMLエンコーディング・フォーマット

<

&lt;

>

&gt;

"

&quot;

` (汎用的な問合せ構文を使用している場合は、バック・クォーテーション・マークを使用してください)

&

&amp;

\

&#39;

注意:
QueryTextやOriginalQueryTextなどの一部の検索結果値は、レスポンス内でURLエンコードされます。

(汎用的な問合せ構文を使用した)コンテンツ・アイテム問合せの場合は、いずれのフォーマットでもコンテンツ・サーバーに文字列を渡すことができます。次の例では、文字列は標準フォーマットで指定されています。

例25-10 標準フォーマットの文字列が指定されたパラメータ

QueryText=dDocType <Substring> "ADSALES"

次の例では、文字列はXMLエンコード・フォーマットで指定されています。

例25-11 XMLエンコードの文字列が指定されたパラメータ

<idc:field name="QueryText">
dDocType &lt;Substring&gt; `ADSALES`
</idc:field>

25.3.3 SOAPレスポンス/リクエストを使用したサンプルのサービス・コール

SOAPレスポンス/リクエストを使用したサービス・コールによって、SOAPリクエストでコンテンツ・サーバー・サービスを実行できます。使用可能なサービスと必須パラメータのリストについては、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

次のIdcCommandサービスは、SOAPリクエストの例です。

IdcCommand

説明

PING_SERVER

このサービスは、サーバーへの接続が存在するかどうかを評価します。第25.3.3.1項「サーバーのPing」を参照してください。

ADD_USER

このサービスは、システムに新しいユーザーを追加します。「新しいユーザーの追加」を参照してください。

EDIT_USER

このサービスは、既存のユーザーを編集します。「既存のユーザーの編集」を参照してください。

GET_USER_INFO

このサービスは、ユーザー・リストを取得します。「ユーザー情報の取得」を参照してください。

DELETE_USER

このサービスは、既存のユーザーを削除します。「ユーザーの削除」を参照してください。

CHECKIN_UNIVERSAL

このサービスは、コンテンツ・サーバーによって制御されるチェックインを実行します。「コンテンツ・アイテムのチェックイン」を参照してください。

CHECKOUT_BY_NAME

このサービスは、指定されたコンテンツ・アイテムの最新バージョンをロック済としてマークします。「コンテンツ・アイテムのチェックアウト」を参照してください。

UNDO_CHECKOUT_BY_NAME

このサービスは、コンテンツIDを使用してコンテンツ・アイテムのチェックアウトを元に戻します。「コンテンツ・アイテムのチェックアウトを元に戻す」を参照してください。

DOC_INFO

このサービスは、コンテンツ・アイテムのリビジョン情報を取得します。「コンテンツ・アイテム情報の取得」を参照してください。

GET_FILE

このサービスは、チェックアウトを実行せずにコンテンツ・アイテムのコピーを取得します。「ファイルの取得」を参照してください。

GET_SEARCH_RESULTS

このサービスは、渡された問合せテキストに対する検索結果を取得します。「検索結果の取得」を参照してください。

GET_TABLE

このサービスは、WebCenter Contentデータベースから、指定された表をエクスポートします。「表のデータの取得」を参照してください。

GET_CRITERIA_WORKFLOWS_FOR_GROUP

このサービスは、基準ワークフローの情報を返します。「基準ワークフロー情報の取得」を参照してください。

25.3.3.1 サーバーのPing

PING_SERVERサービスは、サーバーへの接続が存在するかどうかを評価します。

- このサービスは、コンテンツ・サーバーのステータス情報を返します。

- このサービスを実行できない場合、サーバーへの接続を確立できません。というメッセージがユーザーに表示されます。

ヒント:
コンテンツ・サーバーへの接続が確立されており、コマンドの実行権限を持つユーザーとしてログインしていることを確認するために、他のサービスをコールする前にPING_SERVERリクエストを実行します。

25.3.3.1.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

IdcService

PING_SERVERに設定する必要があります。

25.3.3.1.2 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="PING_SERVER">
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope

25.3.3.1.3 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="PING_SERVER">
<idc:document>
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="StatusMessage">
You are logged in as &#39;sysadmin&#39;.
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.2 新しいユーザーの追加

ADD_USERサービスは、システムに新しいユーザーを追加します。

- ユーザー名が指定されると、サービスは、そのユーザーがシステム内に存在するかどうかを判断します。存在しない場合、サービスは、そのユーザーを追加します。

- 最も発生しがちなエラーは、ユーザー名が一意でないことです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

25.3.3.2.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dName

一意の名前。

dUserAuthType

ユーザーの認可タイプ。この値は、LOCALまたはGLOBALのいずれかに設定する必要があります。

IdcService

ADD_USERに設定する必要があります。

25.3.3.2.2 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

dEmail

ユーザーの電子メール・アドレス。

dFullName

ユーザーのフルネーム。

dPassword

ユーザーのパスワード。

25.3.3.2.3 オプションの属性情報

このオプション・データは、ユーザーの属性情報、ユーザーが属するロール、およびユーザーがアクセス権を持つアカウントを定義します。属性情報は、3つのカンマ区切りの文字列のリストで構成されます。最初の文字列は属性のタイプを、2番目の文字列は属性の名前を、3番目の文字列はアクセス番号を示します。

重要:
ユーザー属性情報は、事前定義されていません。デフォルトでは、ユーザーはどのロールまたはアカウントにも属しておらず、システムではゲストになります。

属性情報

説明

アクセス番号

アクセス番号は、そのユーザーに割り当てられるアクセスまたは権限のレベルを決定します。

属性名

属性名は、割り当てられるroleまたはaccountの名前です。たとえば、admin、contributor、editorなどを割り当てることができます。

属性タイプ

属性タイプは、roleまたはaccountで構成されます。

アクセス番号

ユーザーに次のアクセス番号を割り当てることができます。

アクセス・レベルのフラグ

説明

1

読取り専用。

3

読取りと書込み。

7

読取り、書込みおよび削除。

15

管理権限。

属性名

ユーザーは、複数のロールおよびアカウントに属することができます。そのため、属性情報列に、カンマで区切られた複数のロールおよびアカウント情報文字列が存在する可能性があります。

- ユーザーが管理ロールを持つようにする場合、ユーザー属性情報は次のとおり定義します。

<idc:resultset name="UserAttribInfo">
<idc:row dUserName="jsmith" AttributeInfo="role,contributor,15">

- ユーザーがコントリビュータとエディタの両方のロールに属し、かつ会計帳簿の読取り権限を持つようにする場合、ユーザー属性情報は次のように定義します。

<idc:resultset name="UserAttribInfo">
<idc:row dUserName="jsmith" AttributeInfo="role,contributor,15,role,editor,15,account,books,1">

属性タイプ

ロールを定義するとき、最初の文字列ではこれがrole属性であることを指定し、2番目の文字列はロールの名前、3番目の文字列はデフォルト・エントリの15になります。

アカウントを定義するとき、最初の文字列ではこれがaccount属性であることを指定し、2番目の文字列はアカウントの名前、3番目の文字列はアクセス・レベルになります。

- role属性の場合、情報は次のようなフォームになります。

role,contributor,15

- アクセス・レベルによって指定アカウントへのユーザーの権限が決定されるaccount属性の場合、情報は次のようなフォームになります。

account,books,1

25.3.3.2.4 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="ADD_USER">
<idc:user dName="Jennifer" dFullName="Jennifer Anton" dPassword="password" dEmail="email@example.com" dUserAuthType="local">
<idc:resultset name="UserAttribInfo">
<idc:row dUserName="Jennifer" AttributeInfo="role,contributor,3">
</idc:row>
</idc:resultset>
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.2.5 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="ADD_USER">
<idc:document>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="isAdd">
1
</idc:field>
<idc:field name="copyAll">
1
</idc:field>
<idc:field name="alwaysSave">
1
</idc:field>
<idc:field name="dAttributeName">
contributor
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="doAdminFields">
1
</idc:field>
<idc:field name="dAttributePrivilege">
3
</idc:field>
<idc:field name="dAttributeType">
role
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="changedSubjects">
userlist,1018884022874
</idc:field>
</idc:document>
<idc:user dUserAuthType="local" dEmail="email@example.com" dFullName="Jennifer Anton" dUser="sysadmin" dPassword="password" dName="Jennifer">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.3 既存のユーザーの編集

EDIT_USERサービスは、既存のユーザーの情報を編集します。

- ユーザー名とユーザーの認可タイプが指定されると、サービスは、そのユーザーがシステム内に存在するかどうかを判断します。存在しない場合、サービスは失敗します。それ以外の場合、ユーザー情報は、更新され置き換えられます。

- 最も発生しがちなエラーは、ユーザーがこのアクションを実行するためのセキュリティ・レベルを持っていないことです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

注意:
ユーザー属性情報は、現在の属性を置き換えます。リストに追加されるわけではありません。そのため、ユーザー属性情報が定義されていない場合、ユーザーは、システムではゲストになります。

25.3.3.3.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dName

一意の名前。

dUserAuthType

ユーザーの認可タイプ。この値は、LOCALまたはGLOBALのいずれかに設定する必要があります。

IdcService

EDIT_USERに設定する必要があります。

25.3.3.3.2 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

dEmail

ユーザーの電子メール・アドレス。

dFullName

ユーザーのフルネーム。

dPassword

ユーザーのパスワード。

dUserLocale

ロケールの指定(English-US、English-UK、Deutsch、Français、Españolなど)。

dUserType

定義済のユーザー・タイプ。

25.3.3.3.3 オプションの属性情報

ユーザーの属性情報を含み、ユーザーが属するロールおよびユーザーがアクセス権を持つアカウントを参照する結果セット。属性情報は、3つのカンマ区切りの文字列のリストで構成されます。最初の文字列は属性のタイプを、2番目の文字列は属性の名前を、3番目の文字列はアクセス番号を示します。

重要:
ユーザー属性情報は、事前定義されていません。デフォルトでは、ユーザーはどのロールまたはアカウントにも属しておらず、システムではゲストになります。

属性情報

説明

アクセス番号

アクセス番号は、そのユーザーに割り当てられるアクセスまたは権限のレベルを決定します。

属性名

属性名は、割り当てられるroleまたはaccountの名前です。たとえば、admin、contributor、editorなどを割り当てることができます。

属性タイプ

属性タイプは、roleまたはaccountで構成されます。

アクセス番号

ユーザーに次のアクセス番号を割り当てることができます。

アクセス・レベルのフラグ

説明

1

読取り専用。

3

読取りと書込み。

7

読取り、書込みおよび削除。

15

管理権限。

ユーザーは、複数のロールおよびアカウントに属することができます。そのため、属性情報列に、カンマで区切られた複数のロールおよびアカウント情報文字列が存在する可能性があります。

- ユーザーが管理ロールを持つようにする場合、ユーザー属性情報は次のとおり定義します。

<idc:resultset name="UserAttribInfo">
<idc:row dUserName="jsmith" AttributeInfo="role,contribut
or,15">

- ユーザーがコントリビュータとエディタの両方のロールに属し、かつ会計帳簿の読取り権限を持つようにする場合、ユーザー属性情報は次のように定義します。

<idc:resultset name="UserAttribInfo">
<idc:row dUserName="jsmith" AttributeInfo="role,contributor,15,role,editor,15,account,books,1">

属性タイプ

ロールの定義では、最初の文字列ではこれがrole属性であることを指定し、2番目の文字列はロールの名前、3番目の文字列はデフォルト・エントリの15になります。

アカウントの定義では、最初の文字列ではこれがaccount属性であることを指定し、2番目の文字列はアカウントの名前、3番目の文字列はアクセス・レベルになります。

- role属性の場合、情報は次のようなフォームになります。

role,contributor,15

- アクセス・レベルによって指定アカウントへのユーザーの権限が決定されるaccount属性の場合、情報は次のようなフォームになります。

account,books,1

25.3.3.3.4 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="EDIT_USER">
<idc:user dName="Jennifer" dFullName="Jennifer Anton" dPassword="password" dEmail="jennifer@example.com" dUserAuthType="local">
<idc:resultset name="UserAttribInfo">
<idc:row dUserName="Jennifer" AttributeInfo="role,guest,1">
</idc:row>
</idc:resultset>
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.3.5 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="EDIT_USER">
<idc:document>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="alwaysSave">
1
</idc:field>
<idc:field name="dAttributeName">
guest
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="doAdminFields">
1
</idc:field>
<idc:field name="dAttributePrivilege">
1
</idc:field>
<idc:field name="dAttributeType">
role
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="changedSubjects">
userlist,1018884022877
</idc:field>
</idc:document>
<idc:user dUserAuthType="local" dEmail="jennifer@example.com" dFullName="Jennifer Anton" dUser="sysadmin" dPassword="password" dName="Jennifer">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.4 ユーザー情報の取得

GET_USER_INFOサービスは、ユーザー・リストを取得します。

- 定義済のユーザーが指定されると、サービスは、ユーザー・リストを取得します。

- このサービスを実行できない場合、「ユーザー・リストを取得できません。」というメッセージがユーザーに表示されます。

25.3.3.4.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dUser

定義済のユーザー。

IdcService

GET_USER_INFOに設定する必要があります。

25.3.3.4.2 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_USER_INFO">
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.4.3 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_USER_INFO">
<idc:document>
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:optionlist name="Users_UserLocaleList">
<idc:option>
English-US
</idc:option>
</idc:optionlist>
</idc:document>
<idc:user dUser="sysadmin" dName="sysadmin">
<idc:resultset name="UserMetaDefinition">
<idc:row umdName="dFullName" umdType="BigText" umdCaption="apTitleFullName" umdIsOptionList="0" umdOptionListType="0" umdOptionListKey="" umdIsAdminEdit="0" umdOverrideBitFlag="1">
</idc:row>
<idc:row umdName="dEmail" umdType="BigText" umdCaption="apTitleEmailAddress" umdIsOptionList="0" umdOptionListType="" umdOptionListKey="" umdIsAdminEdit="0" umdOverrideBitFlag="2">
</idc:row>
<idc:row umdName="dUserType" umdType="Text" umdCaption="apTitleUserType" umdIsOptionList="1" umdOptionListType="combo" umdOptionListKey="Users_UserTypeList" umdIsAdminEdit="0" umdOverrideBitFlag="4">
</idc:row>
<idc:row umdName="dUserLocale" umdType="Text" umdCaption="apTitleUserLocale" umdIsOptionList="1" umdOptionListType="choice,locale" umdOptionListKey="Users_UserLocaleList" umdIsAdminEdit="0" umdOverrideBitFlag="8">
</idc:row>
</idc:resultset>
<idc:resultset name="USER_INFO">
<idc:row dName="sysadmin" dFullName="System Administrator" dEmail="" dPasswordEncoding="" dPassword="-----" dUserType="" dUserAuthType="LOCAL" dUserOrgPath="" dUserSourceOrgPath="" dUserSourceFlags="0" dUserArriveDate="" dUserChangeDate="" dUserLocale="" dUserTimeZone="">
</idc:row>
</idc:resultset>
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.5 ユーザーの削除

DELETE_USERサービスは、既存のユーザーを削除します。

- ユーザー名が指定されると、サービスは、システムからそのユーザーを削除します。

- 最も発生しがちなエラーは、ユーザーに別名が割り当てられていることです。このサービスが実行できない場合、エラー・メッセージが返されます。

25.3.3.5.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dName

一意の名前。

IdcService

DELETE_USERに設定する必要があります。

25.3.3.5.2 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="DELETE_USER">
<idc:user dName="Jennifer" >
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.5.3 レスポンス

<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="DELETE_USER">
<idc:document>
<idc:field name="changedSubjects">
userlist,1018884022876
</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="dUserName">
Jennifer
</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
</idc:document>
<idc:user dUser="sysadmin" dName="Jennifer">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.6 コンテンツ・アイテムのチェックイン

CHECKIN_UNIVERSALサービスは、コンテンツ・サーバーへの制御されたチェックインを実行します。

- このサービスは、コンテンツID (dDocName)をキーとして使用してデータベースに問合せを行うことにより、コンテンツ・アイテムが新規のものであるか、システムにすでに存在しているものであるかを判断します。

- コンテンツ・アイテムがシステムに存在している場合、パブリッシュ状態(dPublishState)は空である必要があります。

- リビジョン・ラベル(dRevLabel)が指定された場合、このサービスは、そのコンテンツ・リビジョンがシステムに存在しているかどうかをチェックします。そのリビジョンが存在する場合は、例外がスローされます。

- このサービスは、次のサブサービスのいずれかにこのリクエストをディスパッチします。

- CHECKIN_NEW_SUB - コンテンツ・アイテムがサーバーに存在しない場合。

- CHECKIN_SEL_SUB - コンテンツ・アイテムがシステムに存在し、有効なリビジョンが指定されておらず、コンテンツ・アイテムがチェックアウトされている場合。

- WORKFLOW_CHECKIN_SUB - コンテンツ・アイテムが存在し、ワークフローの一部である場合。

- 最も発生しがちなエラーは、パラメータの不一致、またはコンテンツ・アイテムが正常にチェックインされなかったことです。このサービスを実行できない場合、「コンテンツ・アイテム{dDocName}を正常にチェックインできませんでした。」というメッセージがユーザーに表示されます。

CHECKIN_UNIVERSALサービスは、コンテンツ・サーバーへの制御されたチェックインです。チェックインは、新規、選択済またはワークフロー・チェックイン・プロセスのいずれかに分類され、ブラウザまたはリポジトリ・マネージャ・アプリケーションを介したチェックインと同じロジックに従います。チェックイン対象のコンテンツ・アイテムがすでにシステムに存在している場合、チェックインを正常に行うためには、そのコンテンツ・アイテムをチェックアウトする必要があります。

これらは、本質的に、コンテンツ・サーバーへの制御されたチェックインで使用されるサブサービスと同じです。ただし、これらのサブサービスは、BatchLoadまたはアーカイブのインポート中にはコールされません。このサービスは、セキュリティをチェックして、ユーザーがコンテンツ・アイテムのチェックインを実行するための十分な権限を持っているかどうか、およびコンテンツ・アイテムが存在する場合は、それがチェックアウトされているかどうかを判断します。さらに、コンテンツ・アイテムがワークフローの基準に一致しているかどうか、またはアクティブな基本ワークフローに属しているかどうかも判断します。

コンテンツ・アイテムが見つからない場合、コンテンツ・アイテムは、CHECKIN_NEW_SUBサブサービスを使用してチェックインされます。このサブサービスは、チェックイン・データを検証し、このコンテンツ・アイテムが基準ワークフローに属しているかどうかを判断します。コンテンツ・アイテムがすでにシステムに存在しており、それがワークフローに属していない場合、CHECKIN_SEL_SUBが使用されます。それ以外の場合、つまり、コンテンツ・アイテムが存在しており、それがワークフローに属している場合は、WORKFLOW_CHECKIN_SUBが使用されます。

注意:
バックスラッシュ(\)はエスケープ文字であるため、すべてのパスで、ファイルの区切り文字としてスラッシュ(/)が使用されます。たとえば、primaryFile=d:/temp/myfile.txtは、チェックインするプライマリ・ファイルを指します。

25.3.3.6.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dDocAuthor

コンテンツ・アイテムの作成者(コントリビュータ)。

dDocName

コンテンツ・アイテムの識別子(コンテンツID)。

- システムの構成でIsAutoNumberがTRUEに設定されている場合は、このフィールドはオプションです。このシナリオでは、dDocNameが指定されていない場合、チェックインは常に新規になり、システムはコンテンツ・アイテムの新しい名前を生成します。

- それ以外の場合、つまりdDocNameが指定された場合は、サービスはこのキーを使用して検索を行い、どのタイプのチェックインを実行するかを判断します。

dDocTitle

コンテンツ・アイテムのタイトル。

dDocType

コンテンツ・アイテムのタイプ。

doFileCopy

このフラグはTRUE (1)に設定してください。そうしないと、ファイルがハード・ドライブから削除されます。

dSecurityGroup

PUBLICやSECUREなどのセキュリティ・グループ。

IdcService

CHECKIN_UNIVERSALに設定する必要があります。

primaryFile

サーバーから見た、ファイルの場所への絶対パス。ファイルの区切り文字としてスラッシュを使用します。
プライマリ・ファイルは、メタデータのみをチェックインするのではないかぎり、指定する必要があります。プライマリ・ファイルとともに代替ファイルが指定された場合、Oracle WebCenter Content: Inbound Refineryは、代替ファイルを変換します。それ以外の場合、プライマリ・ファイルが変換されます。

- プライマリ・ファイルが指定されない場合、その代わりにメタファイルを使用できます。ただし、各コンテンツ・アイテムに対して存在できるメタファイルは1つだけです(つまり、プライマリのメタファイルと代替のメタファイルは共存できません)。

- プライマリと代替の両方のファイルを指定する場合、それらの拡張子は異なっている必要があります。

重要:
定義するカスタムのメタデータ・フィールドも指定する必要があります。

25.3.3.6.2 追加のパラメータ

次のパラメータが必要な場合もあります。

パラメータ

説明

dDocAccount

コンテンツ・アイテムのセキュリティ・アカウント。
アカウントを有効にした場合は、このパラメータを渡す必要があります。

25.3.3.6.3 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

alternateFile

変換のための代替ファイル。

- ただし、各コンテンツ・アイテムに対して存在できるメタファイルは1つだけです(プライマリのメタファイルと代替のメタファイルは共存できません)。

- プライマリ・ファイルとともに代替ファイルが指定された場合、Inbound Refineryは、代替ファイルを変換します。それ以外の場合、プライマリ・ファイルが変換されます。

dCreateDate

コンテンツ・アイテムが作成された日付。デフォルトでは、これは現在の日付です。

dInDate

コンテンツのリリース日。コンテンツ・アイテムがWebにリリースされる日付。デフォルトでは、これは現在の日付です。
コンテンツのリリース日(dInDate)が指定されない場合、作成日(dCreateDate)が使用されます。この値が指定されない場合、自動的に生成されます。

dOutDate

コンテンツの有効期限。デフォルトでは、これはブランクであり、有効期限は指定されません。
コンテンツの有効期限(dOutDate)が入力されない場合、値は空のままになります。これは有効な状態です。

dRevLabel

コンテンツ・アイテムのリビジョン・ラベル。設定された場合、このラベルを使用して、指定されたリビジョンを検索します。

isFinished

これがワークフロー・チェックインであり、その編集が完了している場合は、TRUE (1)に設定します。
詳細は、WORKFLOW_CHECKINを参照してください。

注意:
コンテンツID (dDocName)と内部のコンテンツ・アイテム・リビジョン識別子(dID)を混同しないでください。dID値は、コンテンツ・アイテムの特定のレンディションへの、生成済の参照です。

25.3.3.6.4 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKIN_UNIVERSAL">
<idc:document dDocName="SoapUpload2" dDocAuthor="sysadmin" dDocTitle="Soap Upload 2 Document" dDocType="ADACCT" dSecurityGroup="Public" dDocAccount="">
<idc:file name="primaryFile" href="C:/stellent/custom/Soap/JavaSamples/SoapClientUpload/soaptest.doc">
</idc:file>
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.6.5 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKIN_UNIVERSAL">
<idc:document dDocAuthor="sysadmin" dDocName="SoapUpload2" dExtension="doc" dDocAccount="" dIsPrimary="1" dRevisionID="1" dPublishType="" dInDate="4/22/02 1:31PM" dReleaseState="N" dRevClassID="12" dCreateDate="4/22/02 1:31 PM" dIsWebFormat="0" dPublishState="" dLocation="" dStatus="DONE" dOriginalName="12.doc" dOutDate="" dDocID="24" dRevLabel="1" dProcessingState="Y" dDocTitle="Soap Upload 2 Document" dID="12" dDocType="ADACCT" dSecurityGroup="Public" dFileSize="19456" dFormat="application/msword">
<idc:field name="primaryFile:path">
c:/stellent/vault/~temp/1230750423.doc
</idc:field>
<idc:field name="dRawDocID">
23
</idc:field>
<idc:field name="changedSubjects">
documents,1019482656706
</idc:field>
<idc:field name="StatusCode">
0
</idc:field>
<idc:field name="soapFile:path">
c:/stellent/vault/~temp/1230750422.xml
</idc:field>
<idc:field name="xComments">

</idc:field>
<idc:field name="soapStartContentID">
SoapContent
</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="dActionDate">
4/22/02 1:31 PM
</idc:field>
<idc:field name="dActionMillis">
30263
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="WebfilePath">
c:/stellent/weblayout/groups/public/documents/adacct/soapupload2~1.doc
</idc:field>
<idc:field name="StatusMessage">
Successfully checked in content item &#39;SoapUpload2&#39;.
</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="dConversion">
PASSTHRU
</idc:field>
<idc:field name="primaryFile">
C:/stellent/custom/Soap/JavaSamples/SoapClientUpload/soaptest.doc
</idc:field>
<idc:field name="dAction">
Checkin
</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="VaultfilePath">
c:/stellent/vault/adacct/12.doc
</idc:field>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.7 コンテンツ・アイテムのチェックアウト

CHECKOUT_BY_NAMEは、指定されたコンテンツ・アイテムの最新リビジョンをチェックアウトします。

- コンテンツ・アイテムのリビジョンIDが指定されると、このサービスは、コンテンツ・アイテムをシステムで検索し、チェックアウトを元に戻そうとします。

- コンテンツ・アイテムがシステムに存在しない場合、コンテンツ・アイテムがチェックアウトされていない場合、またはチェックアウトを元に戻すのに十分な権限がユーザーにない場合、サービスは失敗します。

- 最も発生しがちなエラーは、コンテンツ・アイテム名が存在しないことです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

注意:
このサービスは、コンテンツ・アイテムをロック済としてマークするだけです。ダウンロードは実行しません。

25.3.3.7.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dDocName

コンテンツ・アイテムの識別子(コンテンツID)。

IdcService

CHECKOUT_BY_NAMEに設定する必要があります。

注意:
コンテンツID (dDocName)と内部のコンテンツ・アイテム・リビジョン識別子(dID)を混同しないでください。dID値は、コンテンツ・アイテムの特定のレンディションへの、生成済の参照です。

25.3.3.7.2 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

dDocTitle

コンテンツ・アイテムのタイトル。

25.3.3.7.3 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKOUT_BY_NAME">
<idc:document dDocName="soap_sample">
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.7.4 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="CHECKOUT_BY_NAME">
<idc:document dDocTitle="soap_sample" dID="10" dRevLabel="1" dDocAccount="" dRevClassID="10" dDocName="soap_sample" dOriginalName="soap_sample.txt" dSecurityGroup="Public">
<idc:field name="dActionMillis">
39964
</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="dActionDate">
4/22/02 12:20 PM
</idc:field>
<idc:field name="latestID">
10
</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="CurRevID">
10
</idc:field>
<idc:field name="CurRevIsCheckedOut">
0
</idc:field>
<idc:field name="dAction">
Check out
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="CurRevCheckoutUser">
sysadmin
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="changedSubjects">
documents,1019482656687
</idc:field>
<idc:resultset name="DOC_INFO">
<idc:row dID="10" dDocName="soap_sample" dDocType="ADACCT" dDocTitle="soap_sample" dDocAuthor="sysadmin" dRevClassID="10" dRevisionID="1" dRevLabel="1" dIsCheckedOut="1" dCheckoutUser="sysadmin" dSecurityGroup="Public" dCreateDate="4/22/02 12:18 PM" dInDate="4/22/02 12:18 PM" dOutDate="" dStatus="RELEASED" dReleaseState="Y" dFlag1="" dWebExtension="txt" dProcessingState="Y" dMessage="" dDocAccount="" dReleaseDate="4/22/02 12:19 PM" dRendition1="" dRendition2="" dIndexerState="" dPublishType="" dPublishState="" dDocID="19" dIsPrimary="1" dIsWebFormat="0" dLocation="" dOriginalName="soap_sample.txt" dFormat="text/plain" dExtension="txt" dFileSize="12">
<idc:field name="xComments">

</idc:field>
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.8 コンテンツ・アイテムのチェックアウトを元に戻す

UNDO_CHECKOUT_BY_NAMEサービスは、コンテンツIDを使用してコンテンツ・アイテムのチェックアウトを元に戻します。

- コンテンツ・アイテムの名前が指定されると、このサービスは、コンテンツ・アイテムをシステムで検索し、チェックアウトを元に戻そうとします。

- コンテンツ・アイテムがシステムに存在しない場合、コンテンツ・アイテムがチェックアウトされていない場合、またはチェックアウトを元に戻すのに十分な権限がユーザーにない場合、サービスは失敗します。

- このサービスは、アプレットまたはアプリケーションによって使用されます。

- このサービスを実行できない場合、「{dDocName}に対するチェックアウトを元に戻せません。」というメッセージがユーザーに表示されます。

25.3.3.8.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dDocName

コンテンツ・アイテムの識別子(コンテンツID)。

IdcService

UNDO_CHECKOUT_BY_NAMEに設定する必要があります。

注意:
コンテンツID (dDocName)と内部のコンテンツ・アイテム・リビジョン識別子(dID)を混同しないでください。dID値は、コンテンツ・アイテムの特定のレンディションへの、生成済の参照です。

25.3.3.8.2 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

dDocTitle

コンテンツ・アイテムのタイトル。

25.3.3.8.3 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="UNDO_CHECKOUT_BY_NAME">
<idc:document dDocName="soap_sample">
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.8.4 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="UNDO_CHECKOUT_BY_NAME">
<idc:document dCheckoutUser="sysadmin" dPublishState="" dDocTitle="soap_sample" dID="10" dRevLabel="1" dDocAccount="" dDocName="soap_sample" dRevClassID="10" dOriginalName="soap_sample.txt" dSecurityGroup="Public">
<idc:field name="dActionMillis">
5317
</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="dActionDate">
4/22/02 12:23 PM
</idc:field>
<idc:field name="latestID">
10
</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="CurRevID">
10
</idc:field>
<idc:field name="CurRevIsCheckedOut">
1
</idc:field>
<idc:field name="dAction">
Undo Checkout
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="CurRevCheckoutUser">
sysadmin
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="changedSubjects">
documents,1019482656689
</idc:field>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.9 コンテンツ・アイテム情報の取得

DOC_INFOサービスは、コンテンツ・アイテムのリビジョン情報を取得します。

- コンテンツ・アイテムのリビジョンIDが指定されると、このサービスは、コンテンツ・アイテムのリビジョン情報を取得します。

- 最も発生しがちなエラーは、そのコンテンツ・アイテムがすでにシステムに存在していないか、ユーザーがこのアクションを実行するためのセキュリティ・レベルを持っていないことです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

25.3.3.9.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dID

生成済のコンテンツ・アイテムのリビジョンID。

IdcService

DOC_INFOに設定する必要があります。

25.3.3.9.2 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="DOC_INFO">
<idc:document dID="6">
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.9.3 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="DOC_INFO">
<idc:document dStatus="RELEASED" dDocFormats="text/plain" dID="6" DocUrl="HTTP://wharristest/stellent/groups/public/documents/adacct/stellent.txt" dDocTitle="stellent">
<idc:field name="dSubscriptionAlias">
sysadmin
</idc:field>
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="dSubscriptionID">
stellent
</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="dSubscriptionType">
Basic
</idc:field>
<idc:resultset name="REVISION_HISTORY">
<idc:row dFormat="text/plain" dInDate="4/12/02 1:27 PM" dOutDate="" dStatus="RELEASED" dProcessingState="Y" dRevLabel="1" dID="6" dDocName="stellent" dRevisionID="1">
</idc:row>
</idc:resultset>
<idc:resultset name="WF_INFO">
</idc:resultset>
<idc:resultset name="DOC_INFO">
<idc:row dID="6" dDocName="stellent" dDocType="ADACCT" dDocTitle="stellent" dDocAuthor="sysadmin" dRevClassID="6" dRevisionID="1" dRevLabel="1" dIsCheckedOut="0" dCheckoutUser="" dSecurityGroup="Public" dCreateDate="4/12/02 1:27 PM" dInDate="4/12/02 1:27 PM" dOutDate="" dStatus="RELEASED" dReleaseState="Y" dFlag1="" dWebExtension="txt" dProcessingState="Y" dMessage="" dDocAccount="" dReleaseDate="4/12/02 1:27 PM" dRendition1="" dRendition2="" dIndexerState="" dPublishType="" dPublishState="" dDocID="11" dIsPrimary="1" dIsWebFormat="0" dLocation="" dOriginalName="stellent.txt" dFormat="text/plain" dExtension="txt" dFileSize="8">
<idc:field name="xComments">
stellent
</idc:field>
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.10 ファイルの取得

GET_FILEサービスは、コンテンツ・アイテムの特定のレンディション、最新のリビジョンまたは最新リリースのリビジョンを返します。チェックアウトを実行せずにコンテンツ・アイテムのコピーを取得します。

- このコマンドは、リビジョンのdID (コンテンツ・アイテムのリビジョンID)を計算し、計算されたdIDを持つリビジョンの特定のレンディションのファイル名を特定します。指定されたdID、またはdDocName (コンテンツ・アイテム名)とRevisionSelectionMethodパラメータを使用できます。

- dID、またはdDocNameとRevisionSelectionMethodパラメータが指定されると、このサービスは、そのリビジョンの特定のレンディションのファイル名を特定し、そのファイルをクライアントに返します。

- 最も発生しがちなエラーは、パラメータに何らかの不整合があるか、存在しないリビジョンまたはレンディションに対するリクエストであることです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

注意:
リクエスタがdDocName値を認識しているコンテンツ・アイテムに対するすべてのリクエストで、dDocNameを使用してください。コンテンツ・サーバーのエラー・メッセージは、フォームなど、他の機能と同様に、dDocName値が存在しているという想定に基づいています。

25.3.3.10.1 必須パラメータ

重要:
コンテンツ・アイテムのリビジョンID (dID)が指定されているか、コンテンツ・アイテム名(dDocName)とRevisionSelectionMethodパラメータが定義されている必要があります。

パラメータ

説明

dDocName

コンテンツ・アイテムの識別子(コンテンツID)。

- dDocNameが存在しない場合は、dIDが存在しなければならず、RevisionSelectionMethodが存在してはなりません。

- RevisionSelectionMethodが指定された場合、その名前を持つコンテンツ・アイテムのリビジョンのレンディションが返されます(存在する場合)。

- RevisionSelectionMethodが指定されない場合、エラー・メッセージにdDocNameが示される可能性があります。

dID

生成済のコンテンツ・アイテムのリビジョンID。

- dIDが指定されない場合、dDocNameおよびRevisionSelectionMethodを指定する必要があります。

- このIDを持つコンテンツ・アイテムのリビジョンのレンディションが存在し、かつRevisionSelectionMethodパラメータが存在しないか、その値がSpecificである場合は、そのレンディションが返されます。

RevisionSelectionMethod

リビジョン選択メソッド。
これが指定された場合は、dDocNameも指定する必要があります。この変数の値は、指定されたdDocNameからdIDを計算するために使用されるメソッドです。このパラメータで設定可能な値は、Specific、LatestまたはLatestReleasedです。

- 値がSpecificである場合、dDocNameは無視され、dIDが要求され、これを使用してレンディションが取得されます。

- 値がLatestである場合、コンテンツ・アイテムの最新リビジョンを使用してdIDが計算されます。

- 値がLatestReleasedである場合、コンテンツ・アイテムの最新リリースのリビジョンを使用してdIDが計算されます。

IdcService

GET_FILEに設定する必要があります。

25.3.3.10.2 オプション・パラメータ

次のオプション・パラメータを指定することができます。

パラメータ

説明

Rendition

コンテンツ・アイテムのレンディション。このパラメータは、コンテンツ・アイテムのレンディションを指定するもので、Primary、WebまたはAlternateに設定できます。Renditionが指定されない場合、デフォルトでPrimaryが設定されます。

- 値がPrimaryである場合、選択されたリビジョンのプライマリ・レンディションが返されます。

- 値がWebである場合、選択されたリビジョンのWeb表示可能レンディションが返されます。

- 値がAlternateである場合、選択されたリビジョンの代替レンディションが返されます。

注意:
コンテンツID (dDocName)と内部のコンテンツ・アイテム・リビジョン識別子(dID)を混同しないでください。dID値は、コンテンツ・アイテムの特定のレンディションへの、生成済の参照です。

25.3.3.10.3 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_FILE">
<idc:document dID="10">
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.10.4 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_FILE">
<idc:document dID="10">
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Receving response...
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Connection: keep-alive
Date: Mon, 29 Apr 2002 16:09:42 GMT
Content-type: Multipart/Related; boundary=-----------------4002588859573015789;
type=text/xml; start="<SoapContent>"
Content-Length: 1717

-------------------4002588859573015789
Content-Type: text/xml; charset=utf-8
Content-ID:  <SoapContent>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_FILE">
<idc:document dID="10" dExtension="txt">
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:resultset name="FILE_DOC_INFO">
<idc:row dID="10" dDocName="soap_sample" dDocType="ADACCT" dDocTitle="soap_sample" dDocAuthor="sysadmin" dRevClassID="10" dRevisionID="1" dRevLabel="1" dIsCheckedOut="0" dCheckoutUser="" dSecurityGroup="Public" dCreateDate="4/22/02 12:18PM" dInDate="4/22/02 12:18 PM" dOutDate="" dStatus="RELEASED" dReleaseState="Y" dFlag1="" dWebExtension="txt" dProcessingState="Y" dMessage="" dDocAccount="" dReleaseDate="4/22/02 12:19 PM" dRendition1="" dRendition2="" dIndexerState="" dPublishType="" dPublishState="" dDocID="19" dIsPrimary="1" dIsWebFormat="0" dLocation="" dOriginalName="soap_sample.txt" dFormat="text/plain" dExtension="txt" dFileSize="12">
<idc:field name="xComments">

</idc:field>
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

-------------------4002588859573015789
Content-Type: text/html
Content-ID: <soap_sample.txt>

...File content...
-------------------4002588859573015789--

25.3.3.11 検索結果の取得

GET_SEARCH_RESULTSサービスは、渡された問合せテキストに対する検索結果を取得します。

- コンテンツ・アイテムの問合せを行ったユーザーに検索結果を表示するために使用されます。

- QueryTextパラメータにTitleやContent IDなどの値を添付して、このサービスで返される結果を絞り込むことができます。
QueryTextパラメータは、問合せを定義します。SOAPメッセージで使用するためには、この問合せはXMLエンコードである必要があります。次の例では、コンテンツ・アイテムの問合せのために送信される文字列を標準フォーマットで渡す場合と、XMLエンコード・フォーマットで渡す場合の両方を示します。

- 標準フォーマットの文字列が指定されたパラメータは次のとおりです。

QueryText=dDocType <Substring> "ADSALES"

- XMLエンコードの文字列が指定されたパラメータは次のとおりです。

<idc:field name="QueryText">
dDocType &lt;Substring&gt; `ADSALES`
</idc:field>

XMLエンコードの文字列のフォーマットの詳細は、第25.3.2項「特殊文字」を参照してください。

- このサービスを実行できない場合、「検索結果を取得できません」というメッセージが表示されます。

25.3.3.11.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

IdcService

GET_SEARCH_RESULTSに設定する必要があります。

QueryText

コンテンツ・アイテムの問合せのために送信される、ユーザーが指定したテキスト。

25.3.3.11.2 オプション・パラメータ

次のパラメータを指定することができます。

パラメータ

説明

resultCount

返される結果の数。デフォルトは25です。

sortField

ソートの基準となるメタデータ・フィールドの名前。

- 例: dInDate、dDocTitle、Score。

- デフォルトはdInDateです。

sortOrder

ソート順序。使用できる値は、ASC (昇順)およびDES (降順)です。

startRow

次の検索結果として取得される最初の行。たとえば、結果として200行が返され、resultCountが25である場合、2番目の結果セットを取得するには、startRowを26に設定します。

25.3.3.11.3 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_SEARCH_RESULTS">
<idc:document>
<idc:field name="QueryText">
dDocType <Substring> "ADSALES"
</idc:field>
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.11.4 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_SEARCH_RESULTS">
<idc:document StartRow="1" TotalDocsProcessed="6" TotalRows="0" QueryText="dDocType+%3cSubstring%3e+%22ADSALES%22" EndRow="25" SearchProviders="Master_on_wharristest" NumPages="0" PageNumber="1">
<idc:field name="refreshMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="EnterpriseSearchMaxRows">
4
</idc:field>
<idc:field name="FullRequest">
&QueryText=dDocType+%3cSubstring%3e+%22ADSALES%22
</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="Text2">
&lt;$dDocTitle$&gt;
</idc:field>
<idc:field name="Text1">
<$dDocName$>
</idc:field>
<idc:field name="OriginalQueryText">
dDocType+%3cSubstring%3e+%22ADSALES%22
</idc:field>
<idc:resultset name="SearchResults">
</idc:resultset>
<idc:resultset name="NavigationPages">
</idc:resultset>
<idc:resultset name="Master_on_wharristest">
</idc:resultset>
<idc:resultset name="EnterpriseSearchResults">
<idc:row ProviderName="Master_on_wharristest" IDC_Name="Master_on_wharristest" TotalRows="0" TotalDocsProcessed="6">
<idc:field name="ProviderDescription">
!csProviderLocalContentServerLabel
</idc:field>
<idc:field name="InstanceMenuLabel">
Master_on_wharristest
</idc:field>
<idc:field name="InstanceDescription">
Master_on_wharristest
</idc:field>
<idc:field name="IntradocServerHostName">
wharristest
</idc:field>
<idc:field name="HttpRelativeWebRoot">
/stellent/
</idc:field>
<idc:field name="IsImplicitlySearched">

</idc:field>
<idc:field name="UserAccounts">
#all
</idc:field>
<idc:field name="IsLocalCollection">
true
</idc:field>
<idc:field name="Selected">

</idc:field>
<idc:field name="StatusMessage">
Success
</idc:field>
<idc:field name="ResultSetName">
Master_on_wharristest
</idc:field>
<idc:field name="SearchCgiWebUrl">
/idcplg/idc_cgi_isapi.dll/stellent/pxs
</idc:field>
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.12 表のデータの取得

GET_TABLEサービスは、WebCenter Contentデータベースから、指定された表をエクスポートします。

- 結果セットを作成し、シリアル化されたHDAファイルにそれを追加することにより、指定された表をエクスポートします。表が見つからない場合、サービスは失敗します。シリアル化されたHDAファイルを受信して、後で使用するためにこの結果セットを格納するのは、コール元プログラムです。

- 最も発生しがちなエラーは、表名が存在しないことです。このサービスを実行できない場合、エラー・メッセージがユーザーに表示されます。

25.3.3.12.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

IdcService

GET_TABLEに設定する必要があります。

tableName

エクスポートする表の名前。

25.3.3.12.2 SOAPリクエスト

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_TABLE">
<idc:document>
<idc:field name="tableName">
DocTypes
</idc:field>
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.12.3 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_TABLE">
<idc:document>
<idc:field name="tableName">
DocTypes
</idc:field>
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:resultset name="DocTypes">
<idc:row dDocType="ADACCT" dDescription="Acme Accounting Department" dGif="adacct.gif">
</idc:row>
<idc:row dDocType="ADCORP" dDescription="Acme Corporate Department" dGif="adcorp.gif">
</idc:row>
<idc:row dDocType="ADENG" dDescription="Acme Engineering Department" dGif="adeng.gif">
</idc:row>
<idc:row dDocType="ADHR" dDescription="Acme Human Resources Department" dGif="adhr.gif">
</idc:row>
<idc:row dDocType="ADMFG" dDescription="Acme Manufacturing Department" dGif="admfg.gif">
</idc:row>
<idc:row dDocType="ADMKT" dDescription="Acme Marketing Department" dGif="admkt.gif">
</idc:row>
<idc:row dDocType="ADSALES" dDescription="Acme Sales Department" dGif="adsales.gif">
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.13 基準ワークフロー情報の取得

GET_CRITERIA_WORKFLOWS_FOR_GROUPサービスは、基準ワークフロー情報を返します。

- セキュリティ・グループが指定されると、このサービスは、ワークフローおよび関連ステップのリストを返します。

- 結果セットWorkflowsForGroupおよびWorkflowStepsForGroupを返します。

- WorkflowsForGroupでは、このグループに対するすべてのワークフローがリストされます(dWfID、dWfName)。

- WorkflowStepsForGroupでは、このグループに対するすべてのワークフローのすべてのステップがリストされます(dWfID、dWfName、dWfStepID、dWfStepName)。

- 「ワークフロー管理」管理アプレットの「条件」タブから、基準ワークフローおよびサブワークフローを追加、編集、有効化、無効化および削除できます。

- 最も発生しがちなエラーは、指定のセキュリティ・グループが存在しないか、ユーザーがセキュリティ・チェックに失敗することです。そのような状況では、サービスは、ユーザーに表示するための適切な例外をスローします

25.3.3.13.1 必須パラメータ

次のパラメータを指定する必要があります。

パラメータ

説明

dSecurityGroup

PUBLICやSECUREなどのセキュリティ・グループ。

IdcService

GET_CRITERIA_WORKFLOWS_FOR_GROUPに設定する必要があります。

25.3.3.13.2 SOAPリクエスト

<?xml version="1.0" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_CRITERIA_WORKFLOWS_FOR_GROUP">
<idc:document dSecurityGroup="Public" />
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.3.3.13.3 レスポンス

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_CRITERIA_WORKFLOWS_FOR_GROUP">
<idc:document dSecurityGroup="Public">
<idc:field name="changedSubjects">

</idc:field>
<idc:field name="refreshSubjects">

</idc:field>
<idc:field name="loadedUserAttributes">
1
</idc:field>
<idc:field name="changedMonikers">

</idc:field>
<idc:field name="refreshSubMonikers">

</idc:field>
<idc:field name="refreshMonikers">

</idc:field>
<idc:resultset name="WorkflowStepsForGroup">
<idc:row>
<idc:field name="dWfID">
1
</idc:field>
<idc:field name="dWfName">
TestWorkflow
</idc:field>
<idc:field name="dWfStepID">
1
</idc:field>
<idc:field name="dWfStepName">
contribution
</idc:field>
</idc:row>
<idc:row>
<idc:field name="dWfID">
1
</idc:field>
<idc:field name="dWfName">
TestWorkflow
</idc:field>
<idc:field name="dWfStepID">
2
</idc:field>
<idc:field name="dWfStepName">
StepOne
</idc:field>
</idc:row>
</idc:resultset>
<idc:resultset name="WorkflowsForGroup">
<idc:row>
<idc:field name="dWfID">
1
</idc:field>
<idc:field name="dWfName">
TestWorkflow
</idc:field>
</idc:row>
</idc:resultset>
</idc:document>
<idc:user dUser="sysadmin">
</idc:user>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.4 Active Server PageにおけるSOAPパケットの使用

実行するサービスと必須パラメータを定義するSOAPパケットをカプセル化することで、Active Server Pageからコンテンツ・サーバーのIdcCommandサービスを実行できます。コマンドを実行するための適切な権限が必要です。管理者アクセスを必要とするコマンドもあれば、書込み権限のみを必要とするコマンドもあります。

25.4.1 サンプルのSOAPリクエスト

Active Server Pageは、コンテンツ・サーバーからサービスをコールできます。サンプル・サービスの次の説明には、必須パラメータとオプション・パラメータが含まれています。また、埋込みSOAPリクエストのXMLフォーマット・バージョンも提供されます。

必須パラメータとオプション・パラメータを含め、サービス・コールの詳細は、第25.3.3項「SOAPレスポンス/リクエストを使用したサンプルのサービス・コール」を参照してください。

次の例では、XMLフォーマットSOAPリクエストは、GET_SEARCH_RESULTSサービスを使用して、渡された問合せテキストに対する検索結果を取得します。

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<idc:service xmlns:idc="http://www.oracle.com/IdcService/" IdcService="GET_SEARCH_RESULTS">
<idc:document>
<idc:field name="QueryText">
dDocType <Substring> "ADSALES"
</idc:field>
</idc:document>
</idc:service>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

25.4.2 サンプルのActive Server Page

埋込みSOAPリクエストは、Active Server Pageの基礎を形成します。次のサンプルは、GET_SEARCH_RESULTSを実行します。

サービス・コールの詳細およびSOAPレスポンス/リクエスト・メッセージの例は、第25.3.3項「SOAPレスポンス/リクエストを使用したサンプルのサービス・コール」を参照してください。

<%

' Sample ASP page of sending a DOC_INFO Soap request.

Option Explicit

Response.Write("Search Results")

%>
<br><br>
<%

' Construct the Soap request.
Dim strSoapRequest, strQueryText

strQueryText = Request.Form("QueryText")
strQueryText = Server.HtmlEncode(strQueryText)

strSoapRequest = "<?xml version='1.0' ?>" _
& "<SOAP-ENV:Envelope xmlns:SOAP-ENV=""http://schemas.xmlsoap.org/soap/envelope/"">" _
& "<SOAP-ENV:Body>" _
& "<idc:service xmlns:idc=""http://www.oracle.com/IdcService/"" IdcService=""GET_SEARCH_RESULTS"">" _
& "<idc:document>" _
& "<idc:field name=""QueryText"">" & strQueryText & "</idc:field>" _
& "<idc:field name=""SortField"">" & Request.Form("SortField") & "</idc:field>" _
& "<idc:field name=""SortOrder"">" & Request.Form("SortOrder") & "</idc:field>" _
& "<idc:field name=""ResultCount"">" & Request.Form("ResultCount") & "</idc:field>" _
& "<idc:field name=""Auth"">Internet</idc:field>" _
& "</idc:document>" _
& "</idc:service>" _
& "</SOAP-ENV:Body>" _
& "</SOAP-ENV:Envelope>"

' Send the Soap request.
Dim objXmlHttp
Set objXmlHttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
objXmlHttp.open "POST", "http://localhost/stellent/idcplg", False, "sysadmin", "idc"
objXmlHttp.setRequestHeader "Content-Type", "text/xml; charset=utf-8"
objXmlHttp.send(strSoapRequest)

' Parse the Soap response.
Dim objXmlDoc
Set objXmlDoc = Server.CreateObject("Msxml2.DOMDocument")
objXmlDoc.async = False
objXmlDoc.Load objXmlHttp.responseXml

' Check for errors.
Dim strResponseError
strResponseError = objXmlDoc.parseError.reason
If strResponseError <> "" Then
Response.Write(objXmlHttp.ResponseText)
DisplayBackButton()
Response.End
End If

' Check for a fault string.
Dim objXmlFaultNode
Set objXmlFaultNode = objXmlDoc.documentElement.selectSingleNode("//SOAP-ENV:Fault/faultstring")
If (Not (objXmlFaultNode Is Nothing)) Then
Response.Write(objXmlFaultNode.Text)
DisplayBackButton()
Response.End
End If

' Check the status code.
Dim objXmlStatusCodeNode, objXmlStatusMessageNode, strStatusCode, nStatusCode, strStatusMessage
Set objXmlStatusCodeNode = objXmlDoc.documentElement.selectSingleNode("//idc:field[@name='StatusCode']")
If (Not objXmlStatusCodeNode Is Nothing) Then
nStatusCode = CInt(objXmlStatusCodeNode.Text)
If (nStatusCode < 0) Then
Response.Write(objXmlDoc.documentElement.selectSingleNode("//idc:field[@name='StatusMessage']").Text)
DisplayBackButton()
Response.End
End If
End If

' Display search results
Dim strDocName, strDocTitle, strDocType, strInDate, strComments, nCurRow, nTotalRows
Dim objXmlResultNodeList, objXmlCommentNode

Set objXmlResultNodeList = objXmlDoc.documentElement.selectNodes("//idc:resultset[@name='SearchResults']/idc:row")
nTotalRows = objXmlResultNodeList.Length

%>
<table>
<tr>
<td><b>Content ID</b></td>
<td>&nbsp;</td>
<td><b>Title</b></td>
<td>&nbsp;</td>
<td><b>Type</b></td>
<td>&nbsp;</td>
<td><b>Release Date</b></td>
<td>&nbsp;</td>
<td><b>Comments</b></td>
</tr>

<%
For nCurRow = 0 To (nTotalRows - 1)
strDocName = GetXmlNodeValue(objXmlResultNodeList.Item(nCurRow), "dDocName")
strDocTitle = GetXmlNodeValue(objXmlResultNodeList.Item(nCurRow), "dDocTitle")
strDocType = GetXmlNodeValue(objXmlResultNodeList.Item(nCurRow), "dDocType")
strInDate = GetXmlNodeValue(objXmlResultNodeList.Item(nCurRow), "dInDate")
strComments = GetXmlNodeValue(objXmlResultNodeList.Item(nCurRow), "xComments")

%>

<tr>
<td><%=strDocName%></td>
<td>&nbsp;</td>
<td><%=strDocTitle%></td>
<td>&nbsp;</td>
<td><%=strDocType%></td>
<td>&nbsp;</td>
<td><%=strInDate%></td>
<td>&nbsp;</td>
<td><%=strComments%></td>
</tr>
<%
Next
%>

</table>

<%

DisplayBackButton()
'----------------------------
Function GetXmlNodeValue(objXmlRowNode, strNodeName)
'----------------------------
Dim objXmlNode, objXmlNodeValue

Set objXmlNode = objXmlRowNode.selectSingleNode("@" & strNodeName)
If (objXmlNode Is Nothing) Then
Set objXmlNode = objXmlRowNode.selectSingleNode("idc:field[@name='" & strNodeName & "']")
End If

If (Not (objXmlNode Is Nothing)) Then
GetXmlNodeValue = objXmlNode.Text
End If
'----------------------------
End Function
'----------------------------

'----------------------------
Sub DisplayBackButton()
'----------------------------
%>
<form method=POST action="request.asp">
<table>
<tr>
<td><input type=submit value="Back"></td>
</tr>
</table>
</form>
<%
'----------------------------
End Sub
'---------------------------
%>

25.5 WebCenter ContentにアクセスするためのWSDLファイルの生成

WebCenter Contentサービスとの接続のためにWSDLファイルを生成できます。

25.5.1 WSDLファイルについて

WSDLファイルは、コンテンツ・サーバー・サービスによって認識可能なデータを渡せるようにします。コンテンツ・サーバー・サービスにより、WebCenter Content内のコンテンツおよびコンテンツ管理機能へのアクセスが可能になります。コンポーネントとともに提供されているWSDLファイルは、IntradocDir/weblayout/groups/secure/wsdl/customディレクトリに格納されます。

WSDLジェネレータ・コンポーネントとともに次のWSDLファイルが提供されます。

- CheckIn.wsdl

- DocInfo.wsdl

- GetFile.wsdl

- MetaData.wsdl

- PortalInfo.wsdl

- Search.wsdl

- Subscription.wsdl

- Workflow.wsdl

SoapカスタムWSDL管理ページを使用して、追加のWSDLファイルを生成できます。詳細は、第25.5.2項「サンプルのWSDLファイル」を参照してください。

25.5.1.1 WSDLファイル構造

WSDLファイルは、形式上、Webサービスに渡されるデータの説明を含む要素で構造化されます。この構造は、交換されるデータを解析するために、アプリケーションの送信とアプリケーションの受信を可能にします。

WSDL要素には、データ上で実行される操作の説明およびプロトコルまたはトランスポートへのバインディングが含まれます。これにより、データの処理と、応答する方法やデータを返す方法の解釈の両方のために、アプリケーションを受信できるようになります。各WSDL要素内に、追加のサブ要素が含まれる場合もあります。

WSDLファイル構造には、次の主要素が含まれます。

- データ型: 一般的には、メッセージで使用されるXMLスキーマの形式です。

- メッセージ: 完全なドキュメント、またはメソッドの起動にマップされた引数のいずれかとしての、メッセージの形式でのデータの定義。

- ポート・タイプ: アドレスにマップされた操作のセット。これは、バインディングのための操作のコレクションを定義します。

- バインディング: 特定のポート・タイプに対して定義されている操作およびメッセージの実際のプロトコルおよびデータ・フォーマット。

- サービスとポート: サービスは、バインディングをポートにマップし、ポートは、バインディングと、通信交換のためのネットワーク・アドレスの組合せです。

注意:
次のコード・フラグメントは、WSDLジェネレータ・コンポーネントとともに提供されるDocInfo.wsdlファイルにあるものです。完全なWSDLファイルについては、第25.5.2項「サンプルのWSDLファイル」を参照してください。

25.5.1.1.1 データ型

データ型<types>は、複雑なタイプと、関連付けられている要素を定義します。Webサービスは、単純なデータ型(文字列、整数、ブールなど)と複雑なデータ型の両方をサポートします。複雑な型は、複数の単純な型またはサブ要素の配列を含む構造化されたXMLドキュメントです。

ContentInfoセットに対する次のコード・フラグメントでは、名前、タイトル、作成者およびグループの各要素を定義し、それらが文字列であることを指定します。

<s:complexType name="ContentInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dDocName" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="dDocTitle" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="dDocType" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="dDocAuthor" type="s:string"/>
<s:element minOccurs="0" maxOccurs="1" name="dSecurityGroup" type="s:string"/>
</s:sequence>
</s:complexType>

25.5.1.1.2 メッセージ

メッセージ<message>は、メソッドの起動にマップされるデータを引数として定義します。

<message name="DocInfoByIDSoapIn">
<part name="parameters" element="s0:DocInfoByID" />
</message>
<message name="DocInfoByIDSoapOut">
<part name="parameters" element="s0:DocInfobyIDResponse" />
</message>

25.5.1.1.3 ポート・タイプ

ポート・タイプ<portType>は、バインディングのための操作のコレクションを定義します。DocInfo.wsdlファイルは、メッセージを処理するためのI/O情報とともにDocInfoSoapおよびDocInfo操作名(メソッド名)を提供します。

<portType name="DocInfoSoap">
<operation name="DocInfoByID">
<input message="s0:DocInfoByIDSoapIn" />
<output message="s0:DocInfoByIDSoapOut" />
</operation>
</portType>

注意:
ポート・タイプは、(Javaにおけるクラスと同様に)操作のコレクションです。一方、WSDLは、.NET、EJBまたはCORBAオブジェクトへの単なるマッピングよりも多くの機能を提供する、独立したデータ抽象化です。

25.5.1.1.4 バインディング

バインディング<binding>は、特定のポート・タイプに対する操作およびメッセージの実際のプロトコルおよびデータ・フォーマットを定義します。

<binding name="DocInfoSoap" type="s0:DocInfoSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="DocInfoByID">
<soap:operation soapAction="http://wwww.oracle.com/Soap/DocInfo/" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>

25.5.1.1.5 サービスとポート

サービス<service>は、バインディングをポートにマップします。ポートは、バインディングと、通信交換のためのネットワーク・アドレスの組合せです。ポートは、定義されたトランスポート上でポート・タイプ(操作)のセットを公開するために使用されます。

<service name="DocInfo">
<port name="DocInfoSoap" binding="s0:DocInfoSoap">
<soap:address location="http://myhost.example.com:16200/_dav/cs/idcplg" />
</port>
</service>

ヒント:
&IsSoap=1をコンテンツ・サーバーのブラウザ・ウィンドウのURLに追加して、そのページの基礎となるSOAPコードを表示できます。

25.5.2 サンプルのWSDLファイル

次のサンプル・コードは、完全なDocInfo.wsdlファイルを示しています。このファイルと、CheckIn.wsdl、GetFile.wsdlおよびSearch.wsdlファイルは、コンテンツ・サーバー・インスタンスのIntradocDir/weblayout/groups/secure/wsdl/customディレクトリにあります。

<?xml version='1.0' encoding='utf-8' ?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://wwww.oracle.com/DocInfo/"
targetNamespace="http://wwww.oracle.com/DocInfo/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified" targetNamespace="http://www.oracle.com/DocInfo/">
<s:element name="DocInfoByID">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="extraProps" type="s0:IdcPropertyList" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="DocInfoByIDResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="DocInfoByIDResult" type="s0:DocInfoByIDResult" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="DocInfoByIDResult">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="ContentInfo" type="s0:ContentInfo" />
<s:element minOccurs="0" maxOccurs="unbounded" name="Revisions" type="s0:Revisions" />
<s:element minOccurs="0" maxOccurs="unbounded" name="WorkflowInfo" type="s0:WorkflowInfo" />
<s:element minOccurs="0" maxOccurs="1" name="StatusInfo" type="s0:StatusInfo" />
</s:sequence>
</s:complexType>
<s:element name="DocInfoByName">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dDocName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="extraProps" type="s0:IdcPropertyList" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="DocInfoByNameResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="DocInfoByNameResult" type="s0:DocInfoByNameResult" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="DocInfoByNameResult">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="ContentInfo" type="s0:ContentInfo" />
<s:element minOccurs="0" maxOccurs="unbounded" name="Revisions" type="s0:Revisions" />
<s:element minOccurs="0" maxOccurs="unbounded" name="WorkflowInfo" type="s0:WorkflowInfo" />
<s:element minOccurs="0" maxOccurs="1" name="StatusInfo" type="s0:StatusInfo" />
</s:sequence>
</s:complexType>
<s:complexType name="ContentInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dDocName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dDocTitle" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dDocType" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dDocAuthor" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dSecurityGroup" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dDocAccount" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dRevClassID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dRevisionID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dRevLabel" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dIsCheckedOut" type="s:boolean" />
<s:element minOccurs="0" maxOccurs="1" name="dCheckoutUser" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dCreateDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dInDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dOutDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dStatus" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dReleaseState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dFlag1" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWebExtension" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dProcessingState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dMessage" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dReleaseDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dRendition1" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dRendition2" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dIndexerState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dPublishType" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dPublishState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dDocID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dIsPrimary" type="s:boolean" />
<s:element minOccurs="0" maxOccurs="1" name="dIsWebFormat" type="s:boolean" />
<s:element minOccurs="0" maxOccurs="1" name="dLocation" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dOriginalName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dFormat" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dExtension" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dFileSize" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="CustomDocMetaData" type="s0:IdcPropertyList" />
</s:sequence>
</s:complexType>
<s:complexType name="Revisions">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dFormat" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dInDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dOutDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dStatus" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dProcessingState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dRevLabel" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dDocName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dRevisionID" type="s:int" />
</s:sequence>
</s:complexType>
<s:complexType name="WorkflowInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dWfID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dDocName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfDocState" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfComputed" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfCurrentStepID" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="dWfDirectory" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dClbraName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfName" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfDescription" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dCompletionDate" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dSecurityGroup" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfStatus" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dWfType" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dProjectID" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dIsCollaboration" type="s:boolean" />
</s:sequence>
</s:complexType>
<s:complexType name="StatusInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="statusCode" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="statusMessage" type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="IdcPropertyList">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="property" type="s0:IdcProperty" />
</s:sequence>
</s:complexType>
<s:complexType name="IdcProperty">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="name" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="value" type="s:string" />
</s:sequence>
</s:complexType>
</s:schema>
</types>
<message name="DocInfoByIDSoapIn">
<part name="parameters" element="s0:DocInfoByID" />
</message>
<message name="DocInfoByIDSoapOut">
<part name="parameters" element="s0:DocInfoByIDResponse" />
</message>
<message name="DocInfoByNameSoapIn">
<part name="parameters" element="s0:DocInfoByName" />
</message>
<message name="DocInfoByNameSoapOut">
<part name="parameters" element="s0:DocInfoByNameResponse" />
</message>
<portType name="DocInfoSoap">
<operation name="DocInfoByID">
<input message="s0:DocInfoByIDSoapIn" />
<output message="s0:DocInfoByIDSoapOut" />
</operation>
<operation name="DocInfoByName">
<input message="s0:DocInfoByNameSoapIn" />
<output message="s0:DocInfoByNameSoapOut" />
</operation>
</portType>
<binding name="DocInfoSoap" type="s0:DocInfoSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="DocInfoByID">
<soap:operation soapAction="http://www.oracle.com/DocInfo/" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="DocInfoByName">
<soap:operation soapAction="http://www.oracle.com/DocInfo/" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="DocInfo">
<port name="DocInfoSoap" binding="s0:DocInfoSoap">
<soap:address location="http://myhost.example.com:16200/_dav/cs/idcplg/idc_cgi_isapi.dll" />
</port>
</service>
</definitions>

25.5.3 WSDLファイルの生成

Oracle WebCenter Contentのインストール時に、WSDLジェネレータ・コンポーネントがインストールされて有効化されると、一部のサービスをWebサービスとして公開する、いくつかのフォルダおよび関連するHDAファイルが生成されます。IntradocDir/data/soapディレクトリに、2つのディレクトリが作成されます。genericディレクトリにはgeneric.hdaファイルが含まれ、customディレクトリにはwsdl_custom.hdaファイルが含まれます。管理者は、Soap Wsdl管理ページを使用して、WSDLファイルをカスタマイズしたり追加したりできます。それらのページにアクセスするには、「管理アプレット」ページの「管理」セクションで「Soap WSDL」リンクをクリックします。

注意:
WSDLファイルを生成するには、WSDLジェネレータ・コンポーネントを有効にする必要があります。

SoapカスタムWSDL管理ページを使用したカスタムWSDLの作成および編集に関するステップバイステップの手順については、第25.6項「WSDLファイルのカスタマイズ」を参照してください。

25.5.4 WSDLファイルからのプロキシ・クラスの生成

開発者は、WSDLファイルを使用して、開発ツールにプラグインするためのプロキシ・クラスを作成できます。WSDLファイルをJava、Visual Basic、C#などの言語のプログラミング・クラス・ファイルに変換するための、多数のソフトウェア製品およびツールキットがあります。たとえば、Apache AXISは、SOAPからJavaへの変換のためのツールキットを提供し、Microsoft .NET開発環境は、WSDLファイルをC#に変換する機能を提供しています。

Microsoft .NETを使用している場合は、utilitywsdl.exeを使用してプロキシ・クラスを生成できます。

wsdl /l:CS DocInfo.wsdl

このユーティリティは、DocInfoServiceクラスおよびパラメータが指定されたDocInfo関数を含むDocInfoService.csファイル(C#クラス)を生成します。戻り値は、すべてのレスポンス・パラメータが指定されたDocInfoSetクラスと、ErrorCodeおよびErrorMessageの値です。ErrorCodeがゼロ未満の場合、サービス・コールでエラーが発生したことを示しています。その詳細は、ErrorMessage値で確認できます。

注意:
WSDLジェネレータ・コンポーネントで提供されるWSDLファイルに加えて、任意のWebCenter Contentサービス用のWSDLファイルを生成することもできます。詳細は、第25.5.3項「WSDLファイルの生成」を参照してください。

25.6 WSDLファイルのカスタマイズ

SoapカスタムWSDL管理ぺージには、管理者がWSDLファイルを編集およびカスタマイズできる機能があります。この項では、カスタムWSDLの作成および編集に関するステップバイステップの手順を説明する管理のチュートリアルを提供します。

WSDLファイルを生成するには、WSDLジェネレータ・コンポーネントを有効にする必要があります。WSDLジェネレータ・コンポーネントで提供されるWSDLファイルに加えて、任意のWebCenter Contentサービス用の追加のWSDLファイルを生成することもできます。詳細は、第25.5.3項「WSDLファイルの生成」を参照してください。

使用可能なサービスと必須パラメータのリストについては、Oracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。

SoapカスタムWSDL管理ページを使用してカスタムWSDLファイルを作成および編集する手順は次のとおりです。

1. Webブラウザで、Oracle WebCenter Content Serverに管理者としてログインします。

2. 「管理」トレイまたはメニューから、「Soap WSDL」を選択します。
このオプションにより、図25-3に示す「WSDLリスト」ページが開きます。

図25-3 「WSDLリスト」ページ

3. 「アクション」メニューから、「データ・リスト」を選択します。
このオプションにより、図25-4に示す「データ・リスト」ページが開きます。

図25-4 「データ・リスト」ページ

注意:
システム固有のWSDLは削除できません。ただし、WSDLを編集し、そのWSDLに対して複合型の要素を有効化または無効化することができます。

データ・リストは、複合型、サービス・パラメータまたは他のデータ・リストとともに使用できる、データのグローバルなリストです。データ・リストがパラメータまたは複合型のサブタイプとして指定されている場合、そのデータ・リストのすべてのサブタイプがデータ型として表示されます。データ・リストは、いったん定義されると、様々なWSDLおよびサービスで複数回参照できます。データ型のリストでは、すべてのデータ・リストにd:という接頭辞が付いています。

4. 「アクション」メニューから「データ・リストの追加」を選択します。
「データ・リストの追加」ページが表示されます。

5. 次の情報を入力します。
名前: UserMetaFields

説明: ユーザー・メタデータ・フィールド

6. 「追加」をクリックします。

7. データ・リストの要素の「名前」列に、ユーザー・メタデータ・フィールドの次の名前を入力します。

- dName

- dFullName

- dPassword

- dEmail

- dUserAuthType

図25-5に示すように、それぞれの名前で、「タイプ」列のメニューから「field:string」を選択し、必ず「有効」を選択します。

図25-5 データ・リストの要素

8. 「更新」をクリックします。
更新された「データ・リスト」ページに戻ります。UserMetaFieldsがリストの下部に表示されていることに注意してください。

9. 「アクション」メニューから「WSDLリスト」を選択します。
図25-6に示す「WSDLリスト」ページが再表示されます。

図25-6 再表示された「WSDLリスト」ページ

10. 「アクション」メニューから「WSDLの追加」を選択します。
「WSDLの追加」ページが表示されます。

11. 次の情報を入力します。
名前: UserInfo

説明: ユーザー・サービス

12. 「追加」をクリックします。
図25-7に示す「WSDL情報」ページが表示されます。

図25-7 「WSDL情報」ページ

13. 「アクション」メニューから「複合型の追加」を選択します。
「複合型の追加」ページが表示されます。

注意:
複合型には、他のデータ型がサブタイプとして含まれています。それらが作成されると、WSDL内の任意のサービスで、これらの複合型をパラメータとして使用できます。

14. 複合型に関する次の情報を入力します。
名前: UserAttribInfo

タイプ: メニューからresultsetを選択

15. 「追加」をクリックします。
図25-8に示す「WSDL情報」ページが再表示されます。

図25-8 再表示された「WSDL情報」ページ

16. 「UserAttribInfo」行から「編集」を選択します。
「複合型の情報」/「複合型の要素」ページが表示されます。

17. 次の複合型の要素を入力し、メニューからそれぞれの「タイプ」値を選択します。

名前

タイプ

Idc名

dUserName

field:string

AttributeInfo

field:string

18. 「複合型の要素」セクションで「更新」をクリックします。
更新された「WSDL情報」ページに戻ります。User AttribInfoが複合型として表示されていることに注意してください。

19. 「アクション」メニューから「サービスの追加」を選択します。
「サービスの追加」ページが表示されます。

20. 次の情報を入力します。
名前: AddUser

IdcService: ADD_USER

21. 「追加」をクリックします。
「WSDL情報」ページが表示されます。

22. 「AddUser」サービス行から「編集」を選択します。
このオプションにより、図25-9に示す「サービス情報」ページが開きます。

図25-9 「サービス情報」ページ

注意:
WSDLを作成する際、コンテンツ・サーバーのIdcServices機能に対応するサービスを作成します。サービスがWebサービス・コールとの間でやり取りするリクエストおよびレスポンス・パラメータも指定します。

23. 「アクション」メニューから「リクエスト・パラメータの更新」を選択します。
「リクエスト・パラメータ」ページが表示されます。

24. 次の情報を入力し、メニューからタイプを選択します。

名前

タイプ

Idc名

DataList

d:UserMetaFields

CustomUserData

propertylist:CustomUserMeta

25. 「更新」をクリックします。
更新された「サービス情報」ページに戻ります。「リクエスト・パラメータ」セクションにDataListおよびCustomUserDataが表示されていることに注意してください。

26. 「更新」をクリックします。
更新された「WSDL情報」ページに戻ります。このページには、今追加したサービスが表示されています。

27. 「更新」を再度クリックします。
更新された「WSDLリスト」ページに戻ります。UserInfoがリストの下部に表示されています。

28. 「アクション」メニューから「WSDLの生成」を選択します。
WSDLが正常に生成されると、確認メッセージが表示されます。

29. 「戻る」をクリックします。
「WSDLリスト」ページに戻ります。

30. 「名前」列の「UserInfo」リンクをクリックします。
生成されたWSDLファイルのソース・コードが表示されます(例25-12にその一部を示します)。

例25-12 ソース・コードの一部、WSDLファイル

<?xml version="1.0" encoding="utf-8" ?>
- <definitions xmins:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.smlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://www.example.com/UserInfo/"
targetNamespace="http://www.example.com/UserInfo/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
- <types>
- <s:schema elementFormDefault="qualified"
targetNamespace="http://www.example.com/UserInfo/">
- <s:element name="AddUser">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="dName"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dFullName"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dPassword"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dEmail"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="dUserAuthType"
type="s:string: />
<s:element minOccurs="0" maxOccurs="1" name="CustomUserData"
type="s0:IdcPropertyList" />
<s:element minOccurs="0" maxOccurs="1" name="extraProps"
type="s0:IdcPropertyList" />
</s:sequence>
</s:complexType>
</s:element>

31. ブラウザの「戻る」ボタンをクリックします。
SoapカスタムWSDLページに戻ります。

ヒント:
「表示」を右クリックし、デスクトップにWSDLファイルを保存できます(.NETで使用するなどの目的で)。ただし、デフォルトの.xmlファイル拡張子ではなく、.wsdlファイル拡張子でファイルを保存してください。

26 DesktopTagコンポーネントのカスタマイズ

この章では、Oracle WebCenter Content ServerのDesktopTagコンポーネントをカスタマイズして、Microsoft Word、ExcelおよびPowerPointファイルのチェックアウト済バージョンのプロパティを指定する方法について説明します。

この章では、次の項目について説明します。

- 第26.1項「DesktopTagコンポーネントについて」

- 第26.2項「DesktopTagおよびOracleCleanContentコンポーネントの有効化」

- 第26.3項「DesktopTagを使用したコンテンツ・アイテムのチェックアウトとチェックイン」

- 第26.4項「チェックアウト済コンテンツ・アイテムへのプロパティの追加」

- 第26.5項「DesktopTagコンポーネントの構成」

26.1 DesktopTagコンポーネントについて

DesktopTagは、Microsoft Officeアプリケーション(2002以降のバージョン)のデフォルト・フォーマットを使用して作成されたファイルのカスタム・プロパティを管理するコンテンツ・サーバー・コンポーネントです。このコンポーネントは、Wordドキュメント(DOC、DOCXおよびDOTファイル)、Excelスプレッドシート(XLS、XLSXおよびXLTファイル)およびPowerPointプレゼンテーション(PPTおよびPPTXファイル)がコンテンツ・サーバーからチェックアウトされたときにそれらにカスタム・プロパティを追加し、それらが再びチェックインされるときにその情報を削除します。

Microsoft Officeファイルに追加されるプロパティは、DesktopTag構成ファイルに指定されています。詳細は、第26.5項「DesktopTagコンポーネントの構成」を参照してください。

カスタム・プロパティは、コンテンツ・サーバー内でコンテンツ・アイテムが存在している場所に関する情報を提供し、ファイルが正しい場所に正しいコンテンツ管理パラメータでチェックインされるようにします。これは、コンテンツ・アイテムが、チェックアウト後に、外部ワークフロー(つまり、コンテンツ・サーバーによって管理されていないもの)など、コンテンツ・サーバーの外部で処理される場合に特に役立ちます。また、この情報をユーザーに公開することも可能です(たとえば、Microsoft Officeアプリケーションのタスク領域などで)。

DesktopTagは、Oracle Clean Contentテクノロジを使用して、Microsoft Officeファイルにカスタム・プロパティを追加し、Microsoft Officeファイルからカスタム・プロパティを削除します。

26.2 DesktopTagおよびOracleCleanContentコンポーネントの有効化

DesktopTagコンポーネントは、Content Server 11gR1に含まれています。これは、デフォルトでは有効化されていないため、コンテンツ・サーバーで有効にする必要があります。DesktopTagコンポーネントは、OracleCleanContentも有効にすることを必要とします。OracleCleanContentコンポーネントは、標準的なコンテンツ・サーバー・インストールでは有効になっています。

これらのコンポーネントは、コンポーネント・マネージャを使用して有効化できます。コンポーネント・マネージャは、「コンテンツ管理サーバー」ページから起動します。コンポーネントの有効化に関する詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネントの有効化と無効化に関する項を参照してください。

DesktopTagは、次のMicrosoft Officeアプリケーションにカスタム・プロパティを追加できます。

- Microsoft Word 2002 (XP)以降のバージョン

- Microsoft Excel 2002 (XP)以降のバージョン

- Microsoft PowerPoint 2002 (XP)以降のバージョン

26.3 DesktopTagを使用したコンテンツ・アイテムのチェックアウトとチェックイン

DesktopTagコンポーネントは、コンテンツ・サーバーに対するチェックアウト(file get)およびチェックイン操作を変更します。

26.3.1 File Get操作

DesktopTagコンポーネントは、createFileNameメソッドに対するサービス・ハンドラのオーバーライドをインストールします。このメソッドは、サーバーに対するすべてのfile get操作でコールされる必要があります(ネイティブのURLリクエストは、このメソッドをコールしません)。ファイル・タイプが構成でサポートされている場合、カスタム・プロパティのセットがファイルに追加されます。それらのカスタム・プロパティは、DesktopIntegrationSuiteによって様々な方法で使用され、他のコンポーネントで使用可能になります。

26.3.2 ファイルのチェックイン操作

DesktopTagコンポーネントにより、DesktopIntegrationSuiteコンポーネントの一部であるvalidateCheckinDataフィルタをフックする拡張フィルタがインストールされます。これは、データがサーバーにチェックインされる前に、file get操作によって追加されたカスタム・プロパティを削除します。

この操作に対して返される結果セットには、以降のfile get操作でMicrosoft Officeファイルに追加されるプロパティが含まれます。これは、クライアントが、新しいコピーを取得することを必要とせずにファイルを変更できるようにするために提供されています。このメソッドは、file get操作と同様に、desktopTagGetFilter拡張フィルタをコールします。

26.4 チェックアウト済コンテンツ・アイテムへのプロパティの追加

DesktopTagコンポーネントによって提供される機能は、完全にバックグラウンドで提供されます。直接のユーザー・インタラクションはありません。情報はユーザーに公開可能ですが、これは通常、コンテンツ・トラッキングの目的で使用されます。

Microsoft Officeファイルに追加されるプロパティは、DesktopTag構成ファイル内の設定によって異なります(第26.5項「DesktopTagコンポーネントの構成」を参照してください)。図26-2では、コンテンツID (dDocName)、ユーザー名(dUser)および一意のコンテンツ・アイテムID (dID)がWordドキュメントに追加されます。DISPropertiesカスタム・プロパティは、常に追加されます。これにより、DesktopTagによって(構成ファイルに指定されているとおりに)追加されたすべてのカスタム・プロパティがリストされます。これは、ファイルが再びコンテンツ・サーバーにチェックインされるときに適切なカスタム・プロパティが確実に削除されるようにするために使用されます。

図26-1は、DesktopTagによって追加されたカスタム・プロパティがないWord 2003ドキュメントの例を示しています。

図26-1 DesktopTagによって追加されたカスタム・プロパティがないWord 2003ドキュメント

図26-2は、Word 2003ドキュメントに追加されたいくつかのカスタム・プロパティを示しています。

図26-2 DesktopTagによって追加されたカスタム・プロパティがあるWord 2003ドキュメント

26.4.1 カスタム・プロパティの表示

Microsoft Officeファイルのカスタム・プロパティを、次のように表示できます。

- Microsoft Office XP (2002)および2003: 「ファイル」を選択し、「プロパティ」を選択し、「カスタム」タブをクリックします。

- Microsoft Office 2007: アプリケーション内にあるOfficeボタンをクリックし、準備→「プロパティ→ドキュメント・プロパティ→「詳細プロパティ」を選択し、「カスタム」タブをクリックします。

- Microsoft Office 2010: 「ファイル」パネルを開き、「情報」→「プロパティ」→「詳細プロパティ」→「カスタム」タブをクリックします。

図26-3は、DesktopTagによってWord 2003ドキュメントに追加されたカスタム・プロパティを示しています。

図26-3 カスタム・ドキュメント・プロパティ(Microsoft Word 2003)

「図26-3 カスタム・ドキュメント・プロパティ(Microsoft Word 2003)」の説明

26.4.2 コンテンツ・サーバーの外部からのドキュメントのチェックイン

これらのカスタム・ドキュメント・プロパティを使用すると、Oracle Webcenter Content: Desktopでコンテンツ・サーバーにある管理対象ファイルの場所を把握できます。ユーザーは、コンテンツ管理統合のコンテキスト外からでもMicrosoft Officeドキュメントをコンテンツ・サーバーにチェックインできます。

ドキュメントをチェックインするには、サーバー設定に接続する必要があります。Officeアドインは、CGI URL、ServerおよびIDCNAMEプロパティを調べて、ドキュメントをサーバーと照合しようとします。そのため、ユーザーは、同じネットワーク上に存在し、サーバーへのアクセス権を持っている必要があります。

この機能は、次のような多くの状況で役立ちます。

- 管理対象Wordドキュメントを他の人から電子メールの添付ファイルとして受け取った場合

- 管理対象Wordドキュメントを統合階層内のサーバーからその階層外のフォルダにコピーした場合

いずれの場合も、ファイルをMicrosoft Wordで開き、変更し、WordのOracle WebCenter Contentのメニューやリボンを使用してサーバーにチェックインできます。Desktopは、Wordドキュメントに埋め込まれているカスタム・プロパティをチェックして、ファイルのアップロード先を確認します。

26.5 DesktopTagコンポーネントの構成

DesktopTagコンポーネントは、コンポーネント・インストール・ディレクトリにある構成ファイルdesktoptag_environment.cfgを使用して構成されます。これは、任意のテキスト・エディタで編集できるプレーン・テキスト・ファイルです。コンポーネント・インストール・ディレクトリは、MW_HOME/ECM_ORACLE_HOME/ucm/idc/components/DesktopTagです。

注意:
DesktopTag構成ファイルを変更したら、コンテンツ・サーバーを再起動してください。

構成ファイルでは、次のプロパティを設定できます。

- DesktopTagFormats

- DesktopTagPrefix

- DesktopTagFields

- DesktopTagPrefixCustom

- DesktopTagFieldsCustom

- DesktopTagPrefixExtended

- DesktopTagFieldsExtended

- DefaultTaskPaneUrl

- DesktopTagLog

- DesktopTagFormatsExclude

26.5.1 DesktopTagFormatsプロパティ

DesktopTagFormatsプロパティの値は、タグ付けのために処理されるMIMEデータ型のカンマ区切りリストです。このリストにないデータ型は処理されません。このパラメータが(#を使用して)コメントアウトされているか、空であるか、または構成ファイルにまったく含まれていない場合、サポートされているデータ型がすべて処理されます。

例: DesktopTagFormats=application/msword,application/ms-excel

サポートされていないMIMEデータ型がリストに含まれている場合、DesktopTagはファイルの処理を試行し、ロギングが有効な場合は、ログ・ファイルにエラー・イベントが記録されます。

26.5.2 DesktopTagPrefixプロパティ

DesktopTagPrefixプロパティの値は、標準DesktopTagフィールドのリスト内にあるすべての標準コンテンツ・サーバー・メタデータ・フィールドの名前に追加される接頭辞です(第26.5.3項「DesktopTagFieldsプロパティ」を参照してください)。特定のプロパティ名が定義されている場合、この接頭辞は追加されません。このパラメータが(#を使用して)コメントアウトされているか、空であるか、または構成ファイルにまったく含まれていない場合、DISがデフォルトとして使用されます。

例: DesktopTagPrefix=STD

26.5.3 DesktopTagFieldsプロパティ

DesktopTagFieldsプロパティの値は、Microsoft Officeファイルにカスタム・プロパティとして追加されるすべての標準コンテンツ・サーバー・メタデータ・フィールドのカンマ区切りリストです。サーバー内部フィールド名(たとえば、コンテンツIDの場合はdDocName)を使用してください。標準メタデータ・フィールドの内部フィールド名については、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

フィールド名の後にカッコで囲んで追加することにより、メタデータ・フィールドの特定のプロパティ名を設定できます。これは、プロパティ名が(たとえば、Microsoft Office 2007アプリケーションのタスク領域で)エンド・ユーザーに公開される場合は、特に役に立ちます。

例: DesktopTagFields=dID,dDocName,dUser(User Name)

図26-4は、前述のDesktopTagFields定義の結果を示しています(デフォルトのDIS接頭辞が使用されたと仮定しています)。

図26-4 プロパティ名の例

注意:
DISPropertiesカスタム・プロパティは、常に追加されます。その値は、DesktopTagによって追加されたすべてのプロパティのリストです。

26.5.4 DesktopTagPrefixCustomプロパティ

DesktopTagPrefixCustomプロパティの値は、カスタムDesktopTagフィールドのリスト内にあるすべてのカスタム・コンテンツ・サーバー・メタデータ・フィールドの名前に追加される接頭辞です(第26.5.4項「DesktopTagPrefixCustomプロパティ」を参照してください)。特定のプロパティ名が定義されている場合、この接頭辞は追加されません。

このパラメータが(#を使用して)コメントアウトされているか、空であるか、または構成ファイルにまったく含まれていない場合、DISCがデフォルトとして使用されます。

例: DesktopTagPrefixCustom=CST

26.5.5 DesktopTagFieldsCustomプロパティ

DesktopTagFieldsCustomプロパティの値は、Microsoft Officeファイルにカスタム・プロパティとして追加されるすべてのカスタム・コンテンツ・サーバー・メタデータ・フィールドのカンマ区切りリストです。標準メタデータ・フィールドとまったく同じ方法でこれらのフィールドを定義します(第26.5.3項「DesktopTagFieldsプロパティ」を参照してください)。

例: DesktopTagFieldsCustom=xComments(Extra Info),xArchiveStatus

注意:
標準コンテンツ・サーバー・メタデータ・フィールドとカスタム・コンテンツ・サーバー・メタデータ・フィールドは、DesktopTagによってまったく同じように処理されます。別々の構成エントリがあるのは、単にそれらのフィールドを区別しやすくするためです。

26.5.6 DesktopTagPrefixExtendedプロパティ

DesktopTagPrefixExtendedプロパティの値は、拡張DesktopTagフィールドのリスト内にあるすべてのカスタム・コンテンツ・サーバー・メタデータ・フィールドの名前に追加される接頭辞です(第26.5.7項「DesktopTagFieldsExtendedプロパティ」を参照してください)。特定のプロパティ名が定義されている場合、この接頭辞は追加されません。

このパラメータが(#を使用して)コメントアウトされているか、空であるか、または構成ファイルにまったく含まれていない場合、DISXがデフォルトとして使用されます。

例: DesktopTagPrefixExtended=EXT

26.5.7 DesktopTagFieldsExtendedプロパティ

DesktopTagFieldsExtendedプロパティの値は、ExtendedUserAttributesコンポーネントのプロパティ定義のカンマ区切りリストです。プロパティ定義の一般形式は、タイプ/キー/サブキー(名前)です。タイプ、キーおよびサブキーの値は、EC_GET_PROPERTYサービスによって使用されるパラメータです。これらの値のいずれかが@文字で始まっている場合、パラメータ値は、指定されたコンテンツ・サーバー・メタデータ・フィールドから取得されます(次の例を参照してください)。

フィールド名の後にカッコで囲んで追加することにより、メタデータ・フィールドの特定のプロパティ名を設定できます。

例: DesktopTagFieldsExtended=account/@dSecurityGroup/WCTPUrl (DIS_Task_Pane_Url)

この例では、プロパティの名前はDIS_Task_Pane_Urlになり、その値は、タイプがaccount、キー値がdSecurityGroupメタデータ・フィールド(コンテンツ・アイテムのセキュリティ・グループ)によって指定された値、およびサブキーがWCTPUrlのExtendedUserAttributesアイテムであることを指定しています。

26.5.8 DefaultTaskPaneUrlプロパティ

DefaultTaskPaneUrlプロパティの値は、Microsoft Officeアプリケーションのタスク領域でファイルのWebページを表示するために必要なDISTaskPaneUrlプロパティの設定で使用されるデフォルトURLを定義する文字列です。@文字で始まるすべての単語は、バインダからの値に置き換えられるか、または他の方法によって置き換えられます(これは現在、@cgiUrlにのみ適用されます)。

例: DefaultTaskPaneUrl=@cgiUrl?IdcService=GET_TASK_PANE &dID=@dID

この例では、@cgiUrlはコンテンツ・サーバーのCgi URL値に置き換えられ、@dIDはサーバー内部の一意のコンテンツ・アイテムID (dID)の値に置き換えられます。

別な例として、WebCenterUrlという拡張ユーザー属性がある場合、"WebCenterUrl(DISTaskPaneUrl)"という文字列が追加されると、DISTaskPaneUrlプロパティがWebCenterUrlという拡張ユーザー属性の値に設定されます。

26.5.9 DesktopTagLogプロパティ

DesktopTagLogプロパティの値は、DesktopTagコンポーネントの操作および結果をログに記録するかどうかを示すブール値です(1 = yes、0 = no)。

このパラメータが(#を使用して)コメントアウトされているか、空であるか、または構成ファイルにまったく含まれていない場合、コンポーネントの操作および結果はログに記録されません。DesktopTagのログ情報は、図26-5に示されているとおり、標準コンテンツ・サーバー・ログ・ファイル(サーバーの管理ページからアクセス可能)に含まれています。

図26-5 コンテンツ・サーバー・ログ・ファイルのDesktopTagイベント

26.5.10 DesktopTagFormatsExcludeプロパティ

DesktopTagFormatsExcludeプロパティの値は、タグ付けのために処理されないMIMEデータ型のカンマ区切りリストです。このリストにないデータ型は処理されます。

例: DesktopTagFormatsExclude=application/ms-excel

DesktopTagFormatsとDesktopTagFormatsExcludeの両方を使用する理由はありません。

第VI部

付録

この部には、追加情報を提供する付録が含まれます。

第VI部には、次の付録が含まれています。

- 付録A「トラブルシューティング」

A トラブルシューティング

この付録では、Oracle WebCenter Content Serverのカスタマイズに関する問題を解決するためのトラブルシューティング機能の使用方法について説明します。

この付録には、次の項が含まれます。

- A.1項「トラブルシューティング機能について」

- A.2項「サーバー・エラーの表示」

- A.3項「ページ・データの表示」

- A.4項「リソースのロードの監視」

A.1 トラブルシューティング機能について

使用時にコンテンツ・サーバー・ページを評価する場合に使用可能ないくつかのトラブルシューティング機能があります。

A.2 サーバー・エラーの表示

コンポーネント・ファイルや動的サーバー・ページに構文エラーなどの記述ミスがあると、コンテンツ・サーバーでエラーが発生する可能性があります。コンテンツ・サーバー・インスタンスでエラーが発生すると、次の場所にエラーが報告されます。

- コマンド・プロンプトからコンテンツ・サーバーを実行した場合は、コンソール・ウィンドウにエラーが表示されます。

- コンテンツ・サーバーにログインして管理サーバー・ページを表示できる場合は、コンテンツ・サーバー・インスタンスを選択して「サーバー出力の表示」リンクをクリックすると、コンテンツ・サーバーのログを表示できます。

- DomainHome/ucm/cs/weblayout/groups/secure/logsディレクトリにあるコンテンツ・サーバーのログ・ファイルを表示できます。

A.3 ページ・データの表示

IsJavaを設定すると、コンテンツ・サーバーWebページのローカル・データが表示されます。

- Webブラウザのアドレス・ボックスで、ページのURLの最後に次のコードを追加します。

&IsJava=1

- テンプレート・ページまたはインクルードで、次のコードを使用します。

<$IsJava=1$>

IsPageDebugを設定すると、コンテンツ・サーバーWebページで呼び出されるすべてのインクルードのツリー構造ビューが表示されます。Webページの下部にデバッグ・トレースが表示されます。

- Webブラウザのアドレス・ボックスで、ページのURLの最後に次のコードを追加します。

&IsPageDebug=1

- テンプレート・ページまたはインクルードで、次のコードを使用します。

<$IsPageDebug=1$>

ヒント:
サーバー全体に対して設定を適用する場合は、config.cfgファイルでIsPageDebug変数を設定することもできます。

- スクリプト・デバッグ・トレースにマーカーを配置するには、値を表示する箇所、またはステップを実行する箇所に次のコードを配置します。

<$trace("marker code")$>

たとえば、次のコードを使用して、現在のユーザー名をデバッグ・トレースに挿入できます(Idocスクリプトを評価するには、eval関数を使用する必要があります)。

<$trace(eval("The user name is <$UserName$>"))$>

IsJavaおよびIsPageDebugの詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

A.4 リソースのロードの監視

コマンドラインからコンテンツ・サーバーを実行すると、3つの構成設定を使用して、リソースのロード状況を表示できます。IntradocDir/config/config.cfgファイルで、次の変数のうち必要なものを1に設定します。

- TraceResourceLoadを1に設定すると、リソースのすべてのロード、上書き、競合およびマージがログに記録されます。

- TraceResourceOverrideを1に設定すると、システム・リソースがコンポーネント・リソースによって上書きされたり、コンポーネント・リソースが2回ロードされたりした場合に、そのイベントがログに記録されます。

- TraceResourceConflictを1に設定すると、システム・リソースがコンポーネント・リソースによって2回上書きされた場合に、そのイベントがログに記録されます。

これらの構成設定の詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。

索引

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  Q  R  S  T  U  V  W  X  Z

A

AboutBoxメソッド, IdcClient OCX, 22.2.5.1

アクセス・レベル属性, 15.2.7

アクセス番号, 25.3.3.2.3

サービスへのアクセス, 21

アクション形式, 15.2.7

アクション・メニュー

カスタマイズ, 8.3

生成, 8.1

「アクション」列のアイコン, 8.3

概要, 8.1

アクション

制御マスク, 15.2.7

エラー・メッセージ, 15.2.7

名前, 15.2.7

パラメータ, 15.2.7

サービス・リソース, 15.2.7.1.2

タイプ, 15.2.7

「アクション」列

アクション・メニュー・アイコン, 8.3

サービスResultSet, 15.2.7

Active Server Pages

埋込みのSOAPリクエスト, 25.4.1

サービスの実行, 25.4

ActiveXコントロール

IdcClient OCX, 22.2.3.1

アクティビティ・メトリック

SQL問合せのカスタマイズ, 12.5.1.1

削減後の手順でのSQL問合せ, 12.5.1

ADD_USERサービス, 25.3.3.2 ADFランタイム・ライブラリ, JCRアダプタのインストール, 24.2.1 拡張コンポーネント・マネージャ

概要, 9.2.2

ページ, 9.2.2

匿名ユーザー・インタフェース

カスタマイズ, 3.5

外部の顧客がログインなしで利用, 3.5

変更のためのExtranetLookコンポーネント, 3.5

Apache Jakarta Tomcat Server, 20.1 API, JCRアダプタのインストール, 24.2 アプレット, 1.1.1.2 アーキテクチャ

Oracle WebCenter Content, 1.1, 2

WebDAV, 18.3.2.3

アジアの言語, 9.1.3.1.1 ページのアセンブル, 1.5.3 アセンブリのプロパティ, 15.2.2.3.2 属性

ClientControlledContextValue, 22.2.6.1

HostCgiUrl, 22.2.6.2

名前, 25.3.3.2.3

パスワード, 22.2.6.3

サービス・リソース, 15.2.7.1.1

タイプ, 25.3.3.2.3, 25.3.3.3.3

UseBrowserLoginPrompt, 22.2.6.4

UseProgressDialog, 22.2.6.5

UserName, 22.2.6.6

WorkingDir, 22.2.6.7

対象読者, はじめに

B

Backメソッド, IdcClient OCX, 22.2.5.2

バッチ・ローダー・ユーティリティ, 1.1.1.2

バッチ・モード, 13, 13.1

開始フォーム・セクション, 4.2.4.3.1

動作, コンテンツ・サーバー, 2

binディレクトリ, 1.1.1.2

複数のリクエスト用のバインダ, 再利用, RIDC, 23.8

バインディング要素, WSDLファイル構造, 25.5.1.1

ブラウザ

複数, 1.4

ファイルのバンドル, 3.8.1

フィルタの順序, 3.8.1

概要, 3.8

PublishedBundles表, 3.8.1

ボタン, フォーム, 4.2.4.3.4

C

-c connection_mode

自動, 21.2.2.4

サーバー, 21.2.2.4

スタンドアロン, 21.2.2.4

C#クラス・ファイル, 25.5.4 キャッシュ設定, JCRアダプタ, 24.4.6 リソースのキャッシング, 1.5.2 リモートでのサービスのコール, 21.4 CancelRequestメソッド, IdcClient OCX, 22.2.5.3 カスケード・スタイル・シート, 1.4 「分類」ボタン, 13, 13.1 CFGファイル, 15.2.9 CgiUrlテキスト・ボックスのプロパティ, 編集後, 22.2.3.2 文字, 特殊, コマンド・ファイルの構文, 21.2.1.3 CHECKIN_UNIVERSALサービス, WSDL, 25.3.3.6 CheckIn.wsdlファイル, 25.5.1 CHECKOUT_BY_NAMEサービス, WSDL, 25.3.3.7 CIS

非推奨, はじめに

CIS。「Remote Intradoc Client (RIDC)」を参照 ClassAliases ResultSet, 9.3.3.4 ClientControlledContextValueプロパティ, 22.2.6.1 クライアント

構成, 23.3

WebDAV, 18.3.2.1

COM統合

API, 22

概要, 22.1

COMインタフェース, 22.1 結合された出力表

ファイル・タイプのロギング・ステータスの変更, 12.3.1.3

ログに記録されないファイル・タイプ, 12.3.1.3

SctIgnoreFileTypesによるファイル・タイプの設定, 12.3.1.3

コマンド・ファイル

IdcCommandパラメータ, 21.2.1

IdcCommandサービス・コマンド, 21.2.1

IdcCommandユーティリティ・オプション, 21.2.2.1

構文

優先順位, 21.2.1.2

サービス・コマンド, 21.2.1.1

特殊文字, 21.2.1.3, 21.2.1.3

コマンド・ファイルの構文, 特殊タグ, 21.2.1.3 コマンド・テキスト・ボックスのプロパティ, 編集後, 22.2.3.2 コマンド・ファイル

構文

特殊文字, 21.2.1.3

コマンドライン・ユーティリティ

ComponentTool

説明, 9.2.3

コンポーネントのインストール, 16.5

オプション, 21.2.1 コマンド, 検証, 22.2.3.2 フォームの共通コード, 4.6.1 通信

JCRアダプタの構成, 24.4

メソッド, JCRアダプタ, 24.4.1

比較演算子, 動的サーバー・ページ, 4.2.1, 4.2.1.2 コンポーネント定義ファイル, 9.1.3.1.3, 9.1.3.1.3, 9.3.3 コンポーネント・マネージャ

拡張, 9.1.2, 9.2.2, 9.2.2

カスタム・コンポーネント, 9.1.2

コンポーネントの無効化, 10.3

コンポーネントの有効化, 10.3

コンポーネントのインストール, 16.3

コンポーネント・ウィザード

動的表の作成, 15.2.4

カスタム・コンポーネント, 9.1.2, 9.1.4.2

説明, 9.2.1

コンポーネントの無効化, 10.3

動的表の編集, 15.2.4.2

環境リソースの編集, 15.2.9.2

HTMLインクルードの編集, 15.2.1.2, 15.2.2.2, 15.2.3.2

サービス・リソースの編集, 15.2.7.2

静的表の編集, 15.2.5.2

テンプレート・リソースの編集, 15.2.8.2

コンポーネントの有効化, 10.3

コンポーネントのインストール, 16.4

インタフェース, 9.2.1

概要, 9.2.1

コンポーネント・ファイルの操作用のツール, 9.1.4.2

WebCenter Contentユーティリティ, 1.1.1.2

リソースの使用, 9.4

コンポーネント

操作のサマリー, 12

コンポーネント

拡張コンポーネント・マネージャ, 9.2.2

コンポーネント・マネージャ, 9.2.2

ComponentToolコマンドライン・ユーティリティ, 9.2.3

作成, 9.1.4.1, 9.1.4.1

カスタム

コンポーネント・ウィザード, 9.1.2, 9.1.4.2

開発に関する推奨事項, 9.1.4

管理, 9.1.2

操作, 9

ディレクトリ, 9.1.3, 9.1.4 無効化, 10.1 有効化, 10.1 ファイル

変更, 1.5.2

コンポーネントの作成, 9.1.3

コンポーネント・ウィザード, 9.1.4.2

開発に関する推奨事項, 9.1.4

組織, 9.1.4.4

概要, 9.1.1

テキスト・エディタ, 9.1.4.2

操作, 9.1.4.2

機能, 9.1.2 HDAファイル, 9.1.3.5, 9.3, 9.3 IdcClient OCX, 22.2.3.1 インストール

ComponentToolユーティリティ, 16.5

概要, 16.1

制限, 9.1.2 ロード, 1.5.1.1 ネーミング規則, 9.1.4.5 概要, 9.1 標準, 9 システム, 9 使用, 9.1.2 操作, 9 ファイルの操作, 9.1.4.2 デプロイメント用のZIPファイル, 9.1.3.5.2 componentsディレクトリ, 1.1.1.4 Components ResultSet, 9.1.3.1.1, 9.3.2 コンポーネント, カスタム

ディレクトリとファイル, 9.1.3

ComponentToolコマンドライン・ユーティリティ

説明, 9.2.3

コンポーネントのインストール, 16.5, 16.5

計算される設定, ランチャ, 21.4.2 configディレクトリ, 1.1.1.3, 1.1.1.5 config.cfg構成ファイル, 3.3 構成

情報の変更, 6.1

クライアント, 23.3

config.cfgファイル, 3.3

構成ファイル内のエントリ, 3.3

JCRアダプタの通信, 24.4

JSPサポート, 20.2

ランチャ, 21.4.5

オプション, idcCommandユーティリティ, 21.2.2

構成ファイル

環境リソース, 15.2.9

例, 21.4.6

ロード順序, 1.5.1.2

構成設定

Content Trackerに対するデフォルト値, 12.3.1

SctAutoTruncateDataStrings, 12.3.1

SctComponentDir, 12.3.1

SctDebugLogEnabled, 12.3.1

SctDebugLogFilePath, 12.3.1

SctDebugServiceBinderDumpEnabled, 12.3.1

SctFilterPluginLogDir, 12.3.1

SctIdcAuthExtraConfigParams, 12.3.1

SctIgnoreDirectories, 12.3.1

SctIgnoreFileTypes, 12.3.1

SctLogDir, 12.3.1

SctLogEnabled, 12.3.1

SctLogSecurity, 12.3.1

SctMaxRecentCount, 12.3.1

SctMaxRereadTime, 12.3.1

SctPostReductionExec, 12.3.1

SctProxyNameMaxLength, 12.3.1

SctReductionAvailableDatesLockback, 12.3.1

SctReductionLogDir, 12.3.1

SctReductionRequireEventLogs, 12.3.1

SctScheduledReductionEnable, 12.3.1

SctSnapshotEnable, 12.3.1

SctSnapshotLastAccessEnable, 12.3.1

SctSnapshotLastAccessField, 12.3.1

SctSnapshotLongCountEnable, 12.3.1

SctSnapshotLongCountField, 12.3.1

SctSnapshotLongCountInterval, 12.3.1

SctSnapshotShortCountEnable, 12.3.1

SctSnapshotShortCountField, 12.3.1

SctSnapshotShortCountInterval, 12.3.1

SctUrlMaxLength, 12.3.1

SctUseGMT, 12.3.1

Content Trackerに対する値の設定, 12.3.2

構成変数, ロード, 1.5.1.1 接続

RIDCによる処理, 23.6

モード, IdcCommandユーティリティ・オプション, 21.2.2.4

コンテンツ属性, メタデータ・タグ, 4.2.4.2.3 Content Categorizer, 13, 13.1

概要, 13.1

コンテンツ・チェックイン・フォーム, 13.1 Content Integration Suite (CIS)

非推奨, はじめに

Content Integration Suite (CIS)。「Remote Intradoc Client (RIDC)」を参照 コンテンツ・アイテム

例, Webブラウザに表示されるHelloWorld, 4.7

情報の検索

JCR, 24.5

表

JCR, 24.5

Content Publisher, 4.2.3.1, 13.1, 13.1

動的サーバー・ページ, 4.2

ネストされたタグ, 4.2.4.2.4

繰り返されたResultSetタグ, 4.2.4.2.7

コンテンツ・サーバー, 13.1

動作, 2

構成変数, ロード, 1.5.1.1

JCRアダプタ通信の構成, 24.4

カスタム・コンポーネント, ロード, 1.5.1.1

開発モード, 9.1.4.3

インタフェース, 22.3.2

ルック・アンド・フィールの変更, 3

ナビゲーションの変更, 3

カスタマイズ, 3.4

ODMAファイル, 22.3.2

インタフェース, コンテンツ・サーバー

匿名ユーザー・インタフェース, 変更, 3.5

変更, 3

内部初期化, 1.5.1.1 JCRアダプタのデータ・モデル, 24.1.2 システム機能の変更, 5 レポート, ロード, 1.5.1.1 リソース, ロード, 1.5.1.1 起動動作, 1.5.1 起動手順, 1.5.1.1 テンプレート, ロード, 1.5.1.1 Content Tracker

デフォルトの構成設定値, 12.3.1

構成変数の設定, 12.3.2

Content Trackerロギング・サービス

アプリケーションからのコール, 12.4.3.3

Idoc Scriptからの呼び出し, 12.4.3.4

サービス・コールの概要, 12.4.2

コンテキスト・ルート, 19.1.1 コントリビューション・フォルダ, システムレベルのデフォルト・フォルダ, 18.3.1 制御マスク, 15.2.7 コントロール, IdcClient OCX, 22.2.2 表記規則

名前付け, 4.2.3.1, 9.1.4.5

core/configディレクトリ, 1.1.1.5 IdcCommandパラメータの作成および実行, 21.3, 21.3 CSS, 1.4 カスタム・コンポーネント

拡張コンポーネント・マネージャ, 9.1.2

コンポーネント・ウィザード, 9.1.2, 9.1.4.2

開発に関する推奨事項, 9.1.4

ディレクトリとファイル, 9.1.3

ロード, 1.5.1.1

理解, 9.1.3, 9.1.4

操作, 9

カスタム・インクルード

例, 4.3

HCSPファイル参照, 4.5

HCSTファイル参照, 4.4

IDOCファイル, 4.6

カスタム・インストール・パラメータ・ファイル, 9.1.3.5.3 カスタム・リソース・ファイル, 9.1.3.2, 9.1.3.5 カスタマイズ

コンテンツ・サーバー・インタフェース, 3, 3.4

コンテンツ・サーバー・ナビゲーション, 3

ポップアップ・メニュー, 8.3

サービス, 7.1

サイト用のファイル, 9.1.3.5.1

推奨されるスキル, 1.4

ステージ, 1.3

システム設定, 5.1

ヒント, 1.3

推奨されるツール, 1.4

タイプ, 1.2

WebCenter Contentインスタンス, 1

D

データ・バインダ, 9.1.3.3

データ収集

データ削減でのファイル・タイプのロギング・ステータスの変更

ファイル・タイプのロギング・ステータスの変更, 12.3.1.3

ログに記録されないファイル・タイプ, 12.3.1.3 SctIgnoreFileTypesによるファイル・タイプの設定, 12.3.1.3 データ削減

ログに記録されないファイル・タイプ, 12.3.1.3

SctIgnoreFileTypesによるファイル・タイプの設定, 12.3.1.3

データ・セクション

概要, 4.2.4.2

構造, 4.2.4.2.1

データ型要素, WSDLファイル構造, 25.5.1.1 データベースとの対話, 1.5.4 dDocNameパラメータ, 4.2.2.1.2 デバッグ・トレース, A.3 デフォルト接尾辞, 4.2.4.2.5 DefaultTaskPaneUrlプロパティ, DesktopTag, 26.5.8 定義

フォーム・フィールド, 4.6.1.4

フォーム情報, 4.6.1.3

非表示フィールド, 4.6.1.5

定義ファイル, 9.1.3.1.3 DELETE_USERサービス, 25.3.3.5 デプロイメント

JCRアダプタ, 24.3

JCRアダプタ用のJCR API, 24.2.3

JCRアダプタ用のJCR統合ライブラリ, 24.2.4, 24.2.5

JCRアダプタ用のRIDC, 24.2.2

DesktopTag

チェックイン, 26.3.2

チェックアウト, 26.3

構成ファイル、26.1、26.5

構成, 26.5

カスタム・フィールド, 26.5.4

ExtendedUserAttributesコンポーネント, 26.5.7

フィールド, 26.5.2

ファイルのチェックイン操作, 26.3.2

File Get操作, 26.3.1

ログ, 26.5.9

メタデータ・フィールド

MicroSoft Officeファイルのプロパティ, 26.5.3

処理, 26.5.5

プロパティ

DefaultTaskPaneUrl, 26.5.8

DesktopTagFields, 26.5.3

DesktopTagFieldsCustom, 26.5.5

DesktopTagFieldsExtended, 26.5.7

DesktopTagFormats, 26.5.1

DesktopTagFormatsExclude, 26.5.10

DesktopTagLog, 26.5.9

DesktopTagPrefix, 26.5.2

DesktopTagPrefixCustom, 26.5.4

DesktopTagPrefixExtended, 26.5.6

DISProperties, 26.5.3

DISTaskPaneUrlプロパティ, 26.5.8

DesktopTagFieldsプロパティ, 26.5.3 DesktopTagFieldsCustomプロパティ, 26.5.5 DesktopTagFieldsExtendedプロパティ, 26.5.7 DesktopTagFormatsプロパティ

説明, 26.5.1

DesktopTagFormatsExclude, 26.5.10

DesktopTagFormatsExcludeプロパティ

説明, 26.5.10

DesktopTagFormats, 26.5.10

DesktopTagLogプロパティ, 26.5.9 DesktopTagPrefixプロパティ, 26.5.2 DesktopTagPrefixCustomプロパティ, 26.5.4 DesktopTagPrefixExtendedプロパティ, 26.5.6 開発

コンテンツ・サーバー, 9.1.4.3

動的サーバー・ページ, 4.2.3

HCSFページ, 4.2.3.2

dIDパラメータ, 4.2.2.1.2 DIMEメッセージのフォーマット, 25.1.1.5 ディレクトリ, 1.1.1

bin, 1.1.1.2

components, 1.1.1.4

config, 1.1.1.3

core/config, 1.1.1.5

groups, 1.1.1.6

idoc, 1.1.1.5

images, 1.1.1.6

install, 1.1.1.5

javascript, 1.1.1.5

jspserver, 1.1.1.5

lang, 1.1.1.5

ネーミング規則, 9.1.4.5

組織, 9.1.4.4

reports, 1.1.1.5

resources, 1.1.1.5, 1.1.1.6

structure, 9.1.3.6

templates, 1.1.1.5, 1.1.1.5, 1.1.1.5

terminology, 1.1.1.1

WebCenter Content, 1.1.1

weblayout, 1.1.1.6

コンポーネントの無効化, 10.1 表示表, 作成, 8.2 DISPropertiesカスタム・プロパティ, 26.5.3 DISTaskPaneUrlプロパティおよびDesktopTag, 26.5.8 DOC_INFOサービス

コンテンツ・アイテム情報の取得, 25.3.3.9

例, 15.2.7.1

DOC_INFO_SIMPLEサービス, 4.6.1.1 DoCheckoutLatestRevメソッド, IdcClient OCX, 22.2.5.4 DocInfo.wsdlファイル, 25.5.1 docLoadResourceIncludes関数

説明, 4.2.2.1

HCSFページ, 4.2.4.1.2

パラメータ, 4.2.2.1.2

コールの要件, 4.2.2.1.1

documentノード, 25.3.1.3.2 documentノード, SOAP, 25.3.1.3.2 ダブルバイト文字, 9.1.3.1.1 DownloadFileメソッド, IdcClient OCX, 22.2.5.5 DownloadNativeFileメソッド, IdcClient OCX, 22.2.5.6 Dragメソッド, IdcClient OCX, 22.2.5.7 動的データ表リソース, 1.1.2, 15.2.2 動的サーバー・ページ

Webページのナビゲーションの変更, 4

比較演算子, 4.2.1, 4.2.1.2

Content Publisher, 4.2

作成, 4.2, 4.2

開発に関する推奨事項, 4.2.3

docLoadResourceIncludes関数, 4.2.2.1

例, 4.3, 4.4, 4.5, 4.7

Idocスクリプト

機能, 4.2.2

タグ, 4.2.1, 4.2.1.1

ネーミング規則, 4.2.3.1 概要, 4.1 ページ・タイプ, 4.1.1 プロセス, 4.1 メタデータの参照, 4.2.1, 4.2.1.4 特殊文字, 4.2.1, 4.2.1.3 構文, 4.2.1 ヒント, 4.2.3.1 タイプ, 4.1.1 動的表リソース

作成, 15.2.4, 15.2.4

編集, 15.2.4.2

HDAファイル形式, 15.2.4

マージ・ルール, 15.2.4.1

概要, 1.1.2

動的Webページ, アセンブリ, 1.5.3 Dynamicdata Idocスクリプトの関数, 15.2.2.4 dynamicdataインクルード, 1.1.2

E

EDIT_USERサービス, 25.3.3.3

EditDocInfoLatestRevメソッド, IdcClient OCX, 22.2.5.8

編集

動的データ表リソース, 15.2.2.2

動的表リソース, 15.2.4.2

環境リソース, 15.2.9.2

HTMLインクルード・リソース, 15.2.1.2

ResultSet, 4.2.4.2.7

サービス・リソース, 15.2.7.2

静的表, 15.2.5.2

文字列リソース, 15.2.3.2

テンプレート・リソース, 15.2.8.2

HDAファイル内の要素, 9.1.3.1.1 埋込みのSOAPリクエスト, 25.4.1 コンポーネントの有効化, 10.1 フォームの最後, 4.2.4.3.5 エンタープライズ・アプリケーションの統合, 18 環境, 9.1.3.3, 9.1.3.3.3 環境リソース

説明, 15.2.9

編集, 15.2.9.2

例, 15.2.9.1

ファイルの内容, 15.2.9.1

概要, 1.1.2

環境変数, ランチャ, 21.4.3 EOD

コマンド・ファイル・タグ, 21.2.1.3

データ終了マーカー, 21.2.1.3

エラー・メッセージ・セクション, サービス・リソース, 15.2.7 エラー・メッセージ・サービス属性, 15.2.7 エラー, サーバー, A.2 イベント

IdcClient OCX, 22.2.2.1

IntradocBeforeDownload, 22.2.4.1

IntradocBrowserPost, 22.2.4.2

IntradocBrowserStateChange, 22.2.4.3

IntradocRequestProgress, 22.2.4.4

IntradocServerResponse, 22.2.4.5

例

外部キー値の変更, 4.2.4.3.3

ClassAliases ResultSet, 9.3.3.4

HCSFページのコード, 4.6.1

コンポーネント定義ファイル, 9.3.3, 15.3

コンポーネントのHDAファイル, 9.3.1

構成ファイル, 21.4.6

Webブラウザに表示されるコンテンツ・アイテム, 4.7

動的サーバー・ページ, 4.3, 4.4, 4.5, 4.7

環境リソース, 15.2.9.1

Filters ResultSet, 9.3.3.3

フォーム・フィールド, 4.6.1.4

Form_Loadコード, 編集後, 22.2.3.2

glueファイル, 9.3.3, 15.3

HCSFページ, 4.6

HCSPページ, 4.4

HCSTページ, 4.4

HDAファイル, 1.1.1.4, 9.1.3.1

Webブラウザに表示されるHelloWorld, 4.7

HTMLインクルード, 15.2.1.1

IdcClient OCXコンポーネント

メソッド, 22.2.2.2

プロパティ, 22.2.2.3

IDOCページ, 4.4, 4.5, 4.6, 4.7 JSPページ, ロード, 20.3 LocalDataセクション, 9.1.3.1.1 MergeRules ResultSet, 9.3.3.2, 15.2.8 OCXメソッド, 22.2.2.2 OCXプロパティ, 22.2.2.3 プロパティ・セクション, 9.1.3.1.1 問合せリソース, 15.2.6.1 レポート・ページ, 15.2.8.1.2, 15.2.8.1.2 ResourceDefinition ResultSet, 9.3.3.1 ResultSetセクション, 9.1.3.1.1 SendPostCommand_Clickコード, 編集後, 22.2.3.2 サービス

アクション, 15.2.7.1.2

属性, 15.2.7.1.1

定義, 15.2.7

リソース, 15.2.7, 15.2.7.1

スーパー・タグ, 15.2.1.1 テンプレート・ページ, 15.2.8.1.1, 15.2.8.1.1, 15.2.8.1.1 拡張されたサービス・ロギング

概要, 12.4.1.2

ExtendedUserAttributesコンポーネントおよびDesktopTag, 26.5.7 eXtensible Markup Language, 13.1 ExtranetLookコンポーネント

匿名ユーザー・インタフェースの変更, 3.5

概要, 3.5

ExtraRootNodesフォーム要素, 4.2.4.2.5, 4.2.4.2.6

F

機能

JSP, 20.1.3

fieldサブノード, SOAP, 25.3.1.3.8 フィールド, 入力フォーム, 4.2.4.3.3 ファイル拡張子, 参照, 4.6.1.2 ファイル・ストア・プロバイダ, 使用

JCR, 24.7

ファイル・ストア表

JCR, 24.5

ファイル

バンドル, 3.8.1

コマンド, 21.2.2.1

コマンド・ファイル, IdcCommandユーティリティ, 21.2.1.1

コンポーネント定義, 9.1.3.1.3, 9.3.3

コンポーネントZIP, 9.1.3.5.2

コンポーネントのHDA, 9.1.3.5, 9.3

config.cfg, 3.3

構成, 15.2.9

カスタム・インストール・パラメータ, 9.1.3.5.3

カスタム・リソース, 9.1.3.2, 9.1.3.5

サイト用にカスタマイズ, 9.1.3.5.1

環境, 15.2.9

glue, 9.1.3.1.3

HCSF

説明, 4.1.1.4

製品の説明フォーム, 4.6

HCSP

カスタム・インクルードの参照, 4.5

説明, 4.1.1.3

HCST

カスタム・インクルードの参照, 4.4

説明, 4.1.1.2

HDA

説明, 9.1.3.1

IDOC

カスタム・インクルード, 4.6

説明, 4.1.1.1

情報の取得, 4.6.1.1 ログ, IdcCommandユーティリティ・オプション, 21.2.2.3 マニフェスト, 9.1.3.4 ネーミング規則, 9.1.4.5 パブリッシュされたファイルの最適化, 3.8 組織, 9.1.4.4 パブリッシュされたページの参照, 3.8.2 search_results.htm, 15.2.8 タイプ, 9.1.1 使用方法, 3.8.2 WebCenter Content, 1.1.1 コンポーネントの操作, 9.1.4.2 フィルタのプロパティ, 15.2.2.3.4 Filters ResultSet, 9.3.3.3 Flexiondoc, 13, 13.1 フォルダ・コンポーネント

仮想フォルダの利点, 18.3.1

構造, 18.3.1

仮想フォルダ・インタフェース, 18.3.1

外部キー, 値の変更, 4.2.4.3.3 フォーム・プロパティ, 4.2.4.3.2 フォーム・セクション, 4.2.4.3

開始, 4.2.4.3.1

フォーム・ボタン, 4.2.4.3.4

フォームの最後, 4.2.4.3.5

プロパティ, 4.2.4.3.2

Form_Loadコード, 編集後, 22.2.3.2 形式

アクション, 15.2.7

表の指定, 15.2.2.1

フォーム

ボタン, 4.2.4.3.4

共通コード, 4.6.1

フォーム情報の定義, 4.6.1.3

要素, 4.2.4.2.6

フォーム・セクションの終了, 4.2.4.3.5

フィールド

定義, 4.6.1.4

入力用, 4.2.4.3.3

プロパティ、4.6.1.3 送信, 4.6.1.6 Forwardメソッド, IdcClient OCX, 22.2.5.9 機能, 変更, 5 関数

docLoadResourceIncludes, 4.2.2.1

Dynamicdata Idocスクリプト, 15.2.2.4

Idocスクリプト, 4.2.2

Fusion Order Demoアプリケーション

説明, 2.1

設定, 2.2

G

アクション・メニューの生成, 8.1

WSDLファイルからのプロキシ・クラスの生成, 25.5.4

WSDLファイルの生成, 25.5.3

GenericSoapService, 19.1.1

GET_CRITERIA_WORKFLOWS_FOR_GROUPサービス, 25.3.3.13

GET_FILEサービス, 25.3.3.10

GET_SEARCH_RESULTSサービス, 25.3.3.11

GET_TABLEサービス, 25.3.3.12

GET_USER_INFOサービス, 25.3.3.4

GetFile.wsdlファイル, 25.5.1

glueファイル, 9.1.3.1.3

GoCheckinPageメソッド, IdcClient OCX, 22.2.5.10

groupsディレクトリ, 1.1.1.6

H

HCSFファイル

説明, 4.1.1.4

製品の説明フォーム, 4.6

構文, 4.2.1

.hcsfファイル。「HCSFファイル」を参照 HCSFページ

共通コード, 4.6.1

作成, 4.6

データ・セクション, 4.2.4.2, 4.2.4.2.1

フォーム・フィールドの定義, 4.6.1.4

フォーム情報の定義, 4.6.1.3

非表示フィールドの定義, 4.6.1.5

説明, 4.2.4

docLoadResourceIncludes関数, 4.2.4.1.2

例, 4.6

フォーム・ボタン, 4.2.4.3.4

フォーム要素, 4.2.4.2.6

フォームの最後, 4.2.4.3.5

フォーム・プロパティ, 4.2.4.3.2

フォーム・セクション, 4.2.4.3

Webブラウザで作成するフォーム, 4.6

HTML宣言, 4.2.4.1.1

HTMLインクルード, 4.2.4.1.4

isFormFinished属性, 4.2.4.2.2

ロード・セクション, 4.2.4.1

metaタグ, 4.2.4.1.3

メタデータ・タグ, 4.2.4.2.3

ネストされたタグ, 4.2.4.2.4

ファイル拡張子の参照, 4.6.1.2

XMLタグの参照, 4.2.4.2.5

ResultSets, 4.2.4.2.7

resultsets属性, 4.2.4.2.2

ファイル情報の取得, 4.6.1.1

フォームの送信, 4.6.1.6

ヒント, 4.2.3.2

変数, 4.2.4.1.4

HCSPファイル

カスタム・インクルードの参照, 4.5

説明, 4.1.1.3

構文, 4.2.1

.hcspファイル。「HCSPファイル」を参照 HCSPページ

作成, 4.4, 4.5, 4.7

例, 4.4

表示するリンク, 4.6

HCSTファイル

カスタム・インクルードの参照, 4.4

説明, 4.1.1.2

構文, 4.2.1

.hcstファイル。「HCSTファイル」を参照 HCSTページ

作成, 4.4, 4.5, 4.7

例, 4.4

HDAファイル

コンポーネント定義, 9.3

説明, 9.1.3.1

要素, 9.1.3.1.1

例, 1.1.1.4, 9.1.3.1

コンポーネント用のidcファイル, 9.1.3.1.2

コンポーネント用のidc, 9.3

idc_components.hda, 9.3.1

ResultSetセクション, 9.1.3.1.1

.hdaファイル。「HDAファイル」を参照 HEADセクション, HCSFページ, 4.2.4.1.4 「ヘッドライン表示」表, 8.2.1 Webブラウザに表示されるHelloWorldコンテンツ・アイテム, 4.7 非表示フィール, 定義, 4.6.1.5 階層フォルダ, 18.3.1 Homeメソッド, IdcClient OCX, 22.2.5.11 HostCgiUrlプロパティ, IdcClient, 22.2.6.2 HTML宣言, HCSFページ, 4.2.4.1.1 HTMLエディタ, 1.4 テンプレートのHTML, 1.4 HTMLインクルード, 15.2.1

作成, 15.2.3.2, 15.2.3.2

編集, 15.2.1.2, 15.2.2.2, 15.2.3.2

例, 15.2.1.1

HCSFページ, 4.2.4.1.4

概要, 1.1.2

標準, 15.2.1, 15.2.2, 15.2.3

スーパー・タグ, 15.2.1.1, 15.2.1.1

HTTPヘッダー, 25.3.1.1

I

コンポーネント用のidc HDAファイル, 1.1.1.4, 9.1.3.1.2

idcネームスペース, 25.3.1.2

idc_components.hdaファイル, 9.3.1, 9.3.1

IdcAnalyze WebCenter Contentユーティリティ, 1.1.1.2

idcbegindataタグ, 4.2.4.2.1

IdcClient ActiveX Controlモジュール, 22.2.3.1

IdcClientイベント, 22.2.4

IdcClient OCXコンポーネント

コンテンツ・サーバーの機能, 22.2.2.1

コントロールの設定, 22.2.3

説明, 22.2.2

インタフェース, 22.2.2.4

メソッド, 22.2.2.2

AboutBox, 22.2.5.1

Back, 22.2.5.2

CancelRequest, 22.2.5.3

DoCheckoutLatestRev, 22.2.5.4

DownloadFile, 22.2.5.5

DownloadNativeFile, 22.2.5.6

Drag, 22.2.5.7

EditDocInfoLatestRev, 22.2.5.8

Forward, 22.2.5.9

GoCheckinPage, 22.2.5.10

Home, 22.2.5.11

InitiateFileDownload, 22.2.5.12

InitiatePostCommand, 22.2.5.13

Move, 22.2.5.14

Navigate, 22.2.5.15

NavigateCgiPage, 22.2.5.16

RefreshBrowser, 22.2.5.17

SendCommand, 22.2.5.18

SendPostCommand, 22.2.5.19

SetFocus, 22.2.5.20

ShowDMS, 22.2.5.21

ShowDocInfoLatestRev, 22.2.5.22

ShowWhatsThis, 22.2.5.23

StartSearch, 22.2.5.24

Stop, 22.2.5.25

UndoCheckout, 22.2.5.26

ViewDocInfo, 22.2.5.27

ViewDocInfoLatestRev, 22.2.5.28

ZOrder, 22.2.5.29

プロパティ

例, 22.2.2.3

概要, 22.2.2.3

設定, 22.2.3.1 IdcClient OCXコントロール

説明, 22.2.2

イベント, 22.2.2.1

IdcClient OCXメソッド, 22.2.5 IdcClientのプロパティ

編集後, 22.2.3.2

概要, 22.2.6

IdcCommandユーティリティ

サービスへのアクセス, 21

リモートでのサービスのコール, 21.4

コマンド・ファイルの構文, 21.2.1, 21.2.1.1

コマンドライン・オプション, 21.2.1

構成オプション, 21.2.2

実行, 21.2

オプション

コマンド・ファイル, 21.2.2.1

接続モード, 21.2.2.4

ログ・ファイル, 21.2.2.3

ユーザー, 21.2.2.2

概要, 21.1 リポジトリ・サーバー, 21.3 設定, 21.2 ランチャの使用, 21.5 WebCenter Content, 1.1.1.2 idccs_components.hdaファイル, 9.1.3.5 idcenddataタグ, 4.2.4.2.1 idcformrulesタグ, 4.2.4.2.2 idcibr_components.hdaファイル, 9.1.3.5 IdcServerサービス, 1.1.1.2, 1.1.1.2 IdcServerNTサービス, 1.1.1.2, 1.1.1.2 IdcServiceコマンド・ファイルの構文のタグ, 21.2.1.3 idcurm_components.hdaファイル, 9.1.3.5 IdcWebLoginService Webサービス, 19.1.1 IdcWebRequestService Webサービス, 19.1.1 IDE, 1.4 idocディレクトリ, 1.1.1.5 IDOCファイル

カスタム・インクルード, 4.6

説明, 4.1.1.1

構文, 4.2.1

.idocファイル。「IDOCファイル」を参照 IDOCページ

作成, 4.4, 4.5, 4.6, 4.7

例, 4.4, 4.5, 4.6, 4.7

idocリソース・タイプ, 1.1.1.5 Idocスクリプト

定義, 1.4

機能, 動的サーバー・ページ, 4.2.2

タグ, 動的サーバー・ページ, 4.2.1, 4.2.1.1

imagesディレクトリ, 1.1.1.6 実装アーキテクチャ, コンテンツ・サーバーにマップされたWebサービス, 25.1.1.7 インクルード

カスタム

例, 4.3

IDOCファイル, 4.6

プロパティ, 15.2.2.3.4 初期化

RIDC, 23.2

InitiateFileDownloadメソッド, IdcClient OCX, 22.2.5.12 InitiatePostCommandメソッド, IdcClient OCX, 22.2.5.13 インストール・ディレクトリ, 1.1.1.5 インストール

コンポーネント・マネージャ, 16.3

コンポーネント・ウィザード, 16.4

コンポーネント

ComponentToolユーティリティ, 16.5, 16.5

概要, 16.1

JCRアダプタ

ADFランタイム・ライブラリ, 24.2.1

必要なAPI, 24.2

必要なランタイム・ライブラリ, 24.2

インストーラ, 1.1.1.2 統合開発環境, 1.4 統合

COM API, 22

WebCenter Contentとエンタープライズ・アプリケーション, 18

JSP, 20.1

メソッド, 概要, 18.1

ODMA, 22.3

エンタープライズ・アプリケーションとWebCenter Content, 18

WebDAV, 18.3.2

対話方式モード, 13.1 インタフェース, コンテンツ・サーバー

匿名ユーザー・インタフェース, 変更, 3.5

ルック・アンド・フィールの変更, 3

ナビゲーションの変更, 3

カスタマイズ

レイアウトおよびスキン, 3.4

概要, 3

変更, 3 内部初期化, 1.5.1.1 IntradocAppアプレット, 1.1.1.2 IntradocBeforeDownloadイベント, IdcClient, 22.2.4.1 IntradocBrowserPostイベント, IdcClient, 22.2.4.2 IntradocBrowserStateChangeイベント, IdcClient, 22.2.4.3 IntradocClient OCXコンポーネント, 22.2.1 IntradocReports ResultSet, 9.1.3.1.1 IntradocRequestProgressイベント, IdcClient, 22.2.4.4 IntradocServerResponseイベント, IdcClient, 22.2.4.5 IntradocTemplates ResultSet, 9.1.3.1.1 isEditMode変数, 4.6.1.3 isFormFinished属性, 4.2.4.2.2 isFormSubmit変数, 4.6.1.3 IsJava設定, A.3 IsPageDebug設定, A.3

J

Java Content Repositoryアダプタ

概要, 24.1

使用, 24

Java SOAPクライアント, 25.2.1 JavaScript

コンテンツ・サーバーの使用, 1.4

デバッガ, 1.4

javascriptディレクトリ, 1.1.1.5 JavaServer Pages。「JSP」を参照 JCR

コンテンツ・アイテム

情報の検索, 24.5

表, 24.5

ファイル・ストア・プロバイダ, 使用, 24.7 ファイル・ストア表, 24.5 検索索引

表, 24.5

使用, 24.6

表

コンテンツ・アイテム, 24.5

ファイル・ストア, 24.5

検索索引, 24.5

JCRアダプタ

通信

構成, 24.4

ソケット通信の構成, 24.4.2

SSLの構成, 24.4.3

リスナー・ポート, 24.4.2, 24.4.3

メソッド, 24.4.1

プロバイダ, 24.4.1

構成, 24.4.4

キャッシュの設定, 24.4.6

ユーザー・エージェント, 24.4.5

データ・モデル

コード, 24.1.2

コンテンツ・サーバー, 24.1.2

デプロイ, 24.3 JCR APIのデプロイ, 24.2.3 RIDCのデプロイ, 24.2.2 ADFランタイム・ライブラリのインストール, 24.2.1 必要なAPIおよびランタイム・ライブラリのインストール, 24.2 JCR統合ライブラリ, 24.2.4, 24.2.5 Web通信, 24.4.4 JCR API, JCRアダプタ用のデプロイ, 24.2.3 JCRデータ・モデル, 24.1.1 JCR統合ライブラリ, JCRアダプタ用のデプロイ, 24.2.4, 24.2.5 JSP

コンテンツ・サーバーへのアクセス, 20.1

実行, 20.1, 20.1.1

機能, 20.1.3

統合

JSPサポートの構成, 20.2

サンプルのページのロード, 20.3

概要, 20.1

サポート, 構成, 20.2 jspserverディレクトリ, 1.1.1.5

L

ラベル, ビジュアル・インタフェース, 22.2.3.2

langディレクトリ, 1.1.1.5

ランチャ

計算される設定, 21.4.2

構成, 21.4.5

環境変数, 21.4.3

引用符のルール, 21.4.1

ユーザー・インタフェース, 21.4.4

使用, 21.5

レイアウト

新規作成, 3.7

説明, 3.1.3

概要, 3.1

選択, 3.2

トップ・メニュー, 3.1.3

トレイ, 3.1.3

タイプ, 3.1.1

リンク, HCSPページ表示, 4.6 リスナー・ポート, JCRアダプタ通信, 24.4.2, 24.4.3 ロード・セクション, 4.2.4.1 ロード

構成変数, 1.5.1.1

カスタム・コンポーネント, 1.5.1.1

リソースの監視, A.4

標準レポート, 1.5.1.1

標準リソース, 1.5.1.1

標準テンプレート, 1.5.1.1

LocalData, 9.1.3.3.1

データ・バインダ評価, 9.1.3.3

プロパティ・セクション名, 9.1.3.1.1

ローカライゼーション, 文字列の解決, 1.5.5 ログ・ファイル, IdcCommandユーティリティ・オプション, 21.2.2.3 ルック・アンド・フィール, コンテンツ・サーバーのカスタマイズ, 3

M

manifestファイル, 9.1.3.4

Manifest ResultSet, 9.1.3.4

manifest.hdaファイル, 9.1.3.4

マーカー, トレース, A.3

メニュー, アクション, 生成, 8.1

マージ・プロパティ, 15.2.2.3.1

マージ・ルール

動的表リソース, 15.2.4.1

静的表, 15.2.5.1

MergeRules ResultSet, 9.3.3.2

列, 9.3.3.2.1

例, 9.3.3.2

テンプレート・リソース, 15.2.8

toTable列, 9.3.3.2.1

メッセージ要素, WSDLファイル構造, 25.5.1.1 メッセージング・プロトコル, 25.1.1.9 metaタグ, 4.2.4.1.3 メタデータ, 13.1

参照, 4.2.1, 4.2.1.4

タグ

コンテンツ属性, 4.2.4.2.3

フォーム・フィールドの値, 4.2.4.2.3

MetaData.wsdlファイル, 25.5.1 メソッド

CancelRequest, 22.2.5.3

DoCheckoutLatestRev, 22.2.5.4

DownloadFile, 22.2.5.5

DownloadNativeFile, 22.2.5.6

Drag, 22.2.5.7

EditDocInfoLatestRev, 22.2.5.8

Forward, 22.2.5.9

GoCheckinPage, 22.2.5.10

IdcClient OCX

AboutBox, 22.2.5.1

Back, 22.2.5.2, 22.2.5.2

CancelRequest, 22.2.5.3

DoCheckoutLatestRev, 22.2.5.4

DownloadFile, 22.2.5.5

DownloadNativeFile, 22.2.5.6

Drag, 22.2.5.7

EditDocInfoLatestRev, 22.2.5.8

Forward, 22.2.5.9

GoCheckinPage, 22.2.5.10

Home, 22.2.5.11

InitiateFileDownload, 22.2.5.12

InitiatePostCommand, 22.2.5.13

Move, 22.2.5.14

Navigate, 22.2.5.15

NavigateCgiPage, 22.2.5.16

RefreshBrowser, 22.2.5.17

SendCommand, 22.2.5.18

SendPostCommand, 22.2.5.19

SetFocus, 22.2.5.20

ShowDMS, 22.2.5.21

ShowDocInfoLatestRev, 22.2.5.22

ShowWhatsThis, 22.2.5.23

StartSearch, 22.2.5.24

Stop, 22.2.5.25

UndoCheckout, 22.2.5.26

ViewDocInfo, 22.2.5.27

ViewDocInfoLatestRev, 22.2.5.28

ZOrder, 22.2.5.29

InitiateFileDownload, 22.2.5.12 InitiatePostCommand, 22.2.5.13 Move, 22.2.5.14 Navigate, 22.2.5.15 NavigateCgiPage, 22.2.5.16 RefreshBrowser, 22.2.5.17 SendCommand, 22.2.5.18 SendPostCommand, 22.2.5.19 SetFocus, 22.2.5.20 ShowDocInfoLatestRev, 22.2.5.22 ShowWhatsThis, 22.2.5.23 StartSearch, 22.2.5.24 Stop, 22.2.5.25 UndoCheckout, 22.2.5.26 ViewDocInfo, 22.2.5.27 ViewDocInfoLatestRev, 22.2.5.28 Zorder, 22.2.5.29 Microsoft .NET, 25.1.1.8, 25.1.1.8 Microsoft Visual Basic, 22.2.3, 22.2.3.1 モード, 13.1 リソースのロードの監視, A.4 Moveメソッド, IdcClient OCX, 22.2.5.14

N

ネームスペース, 25.3.1.2

名前/値のペア, 15.2.9

ネーミング規則

ディレクトリ, 9.1.4.5, 9.1.4.5

動的サーバー・ページ, 4.2.3.1

ファイル, 9.1.4.5

Navigateメソッド, IdcClient OCX, 22.2.5.15 NavigateCgiPageメソッド, IdcClient OCX, 22.2.5.16 ナビゲーション

コンテンツ・サーバーのカスタマイズ, 3

動的サーバー・ページ, 4

ネストされたタグ

ResultSets, 4.2.4.2.7

XMLノード, 4.2.4.2.4

.NETアーキテクチャ, 25.1.1.8 .NET Framework, 25.1.1.8 .NETプラットフォーム, 25.1.1.8 新規リンクSOAP, 25.1.1.3 新規リンクUDDI, 25.1.1.4 ノード, SOAP

パケットの形式, 25.3.1.3

サービス, 25.3.1.3.1

非アクティブResultSets, 9.1.3.3 非セキュア・モードのレポート

プリファレンス変数の値, 12.3.1.2

O

OCXコンポーネント。「IdcClient OCXコンポーネント」を参照

OCXコントロール, Visual Basicフォーム, 22.2.3.2

OCXイベント, 22.2.2.1

OCXの例

メソッド, 22.2.2.2

プロパティ, 22.2.2.3

OCXインタフェース, 22.2.1 ODMAクライアント, 22.3.1 ODMAクライアント・インタフェース, 22.3.2, 22.3.2 ODMAデスクトップ・シェル・インタフェース, 22.3.2, 22.3.2 ODMA統合, 22.3 ODMAインタフェース, 22.3.2 操作モード, 13.1 操作のサマリー

Content Trackerのコンポーネント, 12

演算子, 動的サーバー・ページ, 4.2.1 最適化, パブリッシュされたファイル, 3.8 optionサブノード, SOAP, 25.3.1.3.5 optionlistノード, 25.3.1.3.4

SOAP, 25.3.1.3.4

Oracle Web Services Manager, 18.2, 19.1, 25 Oracle WebCenter Content

アーキテクチャ, 1.1, 2

カスタマイズ, 1

ディレクトリ, 1.1.1

components, 1.1.1.4

terminology, 1.1.1.1

ファイル, 1.1.1 エンタープライズ・アプリケーションとの統合, 18 Oracle WebCenter Content Server。「コンテンツ・サーバー」を参照 編成, コンポーネント・ファイル, 9.1.4.4 概要, 13.1

Content Categorizer, 13.1

P

ページ

動的サーバー, タイプ, 4.1.1

動的Web, アセンブリ, 1.5.3

HCSF

説明, 4.2.4

Webブラウザで作成するフォーム, 4.6

HCSP, 表示するリンク, 4.6 レポート, 15.2.8, 15.2.8.1 テンプレート, 15.2.8, 15.2.8.1 パラメータ

アクション, 15.2.7

docLoadResourceIncludes関数, 4.2.2.1.2

文字列, 15.2.3.1

パスワード, 22.2.6.3 PING_SERVERサービス, 25.3.3.1 ポップアップ・メニュー。「アクション・メニュー」を参照 ポート要素, WSDLファイル構造, 25.5.1.1 ポート・タイプ要素, WSDLファイル構造, 25.5.1.1 PortalInfo.wsdl, 25.5.1 削減後の処理

アクティビティ・メトリックのSQL問合せ, 12.5.1

優先順位, 21.2.1.2 事前定義されたResultSets, 9.1.3.1.1 プレゼンテーション・ページ, 15.2.8.1 製品説明フォーム, HCSFファイル, 4.6 プログラミング

Java, 1.4

その他, 1.4

プロパティ

アセンブリ, 15.2.2.3.2

CgiUrlテキスト・ボックス, 編集後, 22.2.3.2

コマンド・テキスト・ボックス, 編集後, 22.2.3.2

フィルタ, 15.2.2.3.4

フォーム, 4.2.4.3.2, 4.6.1.3

IdcClient OCXコンポーネント, 22.2.2.3

idcClient, 編集後, 22.2.3.2

インクルード, 15.2.2.3.4

マージ, 15.2.2.3.1

レスポンス・テキスト・ボックス, 編集後, 22.2.3.2

SendPostCommand CommandButton, 編集後, 22.2.3.2

ソート, 15.2.2.3.3

表, 指定, 15.2.2.3

プロバイダ

JCRアダプタの通信, 24.4.1

パブリック・ファイル, 最適化のためのバンドル, 3.8 パブリッシュされたファイル

使用の最適化, 3.8

参照, 3.8.2

PublishedBundles表, 3.8.1, 3.8.1 PublishedResources, 3.8.2

Q

QDocInfo問合せ, 標準, 15.2.6.1

問合せ, QDocInfo, 標準, 15.2.6.1

問合せリソース, 15.2.6

編集, 15.2.6.2

例, 15.2.6.1

概要, 1.1.2

引用符のルール, ランチャ, 21.4.1

R

推奨されるスキル, 1.4

ref接頭辞

ファイル拡張子の参照, 4.6.1.2, 4.6.1.2

メタデータの参照, 4.2.1.4

メタデータの参照

動的サーバー・ページ, 4.2.1, 4.2.1.4

ref接頭辞, 4.2.1.4

XMLタグの参照, 4.2.4.2.5 RefreshBrowserメソッド, IdcClient OCX, 22.2.5.17 Remote Intradoc Client (RIDC)

ADF接続ファサード, 23.9.2

複数のリクエスト用のバインダ, 再利用, 23.8

コンビニエンス・クラス, 23.9

JCRアダプタ用のデプロイ, 24.2.2

接続の処理, 23.6

初期化, 23.2

概要, 23.1

サービス, 23.5

ストリーム

受信, 23.7

送信, 23.7

ユーザー認証, 23.4, 23.4 ユーザー・セキュリティ, 提供, 23.9.1 使用, 23 リモート・プロシージャ・コール, 25.2 レンディション・パラメータ, 4.2.2.1.2 ResultSetsの繰り返されたタグ, 4.2.4.2.7 レポート・ページ

例, 15.2.8.1.2, 15.2.8.1.2

場所, 15.2.8

プレゼンテーション・ページ, 15.2.8.1

Webページ・リクエストの結果, 15.2.8.1

レポート

ディレクトリ, 1.1.1.5

ロード, 1.5.1.1, 1.5.1.1

リソース・カテゴリ, 15.2 リソースのロード, 監視, A.4 リソース・タイプ

idoc, 1.1.1.5

表, 1.1.1.5

テンプレート, 1.1.1.5

ResourceDefinition ResultSet

列, 9.3.3.1.1

説明, 9.3.3.1

例, 9.3.3.1

場所, 9.1.3.1.1

目的, 9.1.3.1.1

リソース, 9.4

キャッシュ, 1.5.2

変更, 1.5.2

カスタム

その他のファイル, 9.1.3.5

ディレクトリ, 1.1.1.5 動的表, 15.2.4 環境, 15.2.9 概要, 1.1.2 問合せ

編集, 15.2.6.2

概要, 15.2.6

サービス, 15.2.7 標準, 1.1.2 静的表, 15.2.5 文字列, 15.2.3 resourcesディレクトリ, 1.1.1.6 レスポンス・テキスト・ボックスのプロパティ, 編集後, 22.2.3.2 ResultSetセクション, HDAファイル, 9.1.3.1.1 resultsetサブノード, SOAP, 25.3.1.3.6, 25.3.1.3.6 ResultSet, 9.1.3.3.2

ClassAliases, 9.3.3.4

コンポーネント, 9.1.3.1.1, 9.3.2

XMLタグによる定義, 4.2.4.2.7

編集, 4.2.4.2.7

フィルタ, 9.3.3.3

IntradocReports, 9.1.3.1.1

IntradocTemplates, 9.1.3.1.1

Manifest, 9.1.3.4

MergeRules, 9.3.3.2

ネストされたタグ, 4.2.4.2.7

非アクティブ, 9.1.3.3

事前定義, 9.1.3.1.1

繰り返されたタグ, 4.2.4.2.7

ResourceDefinition, 9.1.3.1.1, 9.3.3.1

SearchResultTemplates, 9.1.3.1.1

XMLタグ, 4.2.4.2.7

resultsets属性, 4.2.4.2.2 resultsetsフォーム要素, 4.2.4.2.5, 4.2.4.2.6 ファイル情報の取得, 4.6.1.1 リバース・プロキシ・サーバー

Webビーコン機能, 12.6.1

RevisionSelectionMethodパラメータ, 4.2.2.1.2 RIDC。「Remote Intradoc Client (RIDC)」を参照 rowサブノード, SOAP, 25.3.1.3.7 RPC, 25.2 ランタイム・ライブラリ

ADF, JCRアダプタ用のインストール, 24.2.1

JCRアダプタ用のインストール, 24.2

S

SAML, 19.1

サンプルのサービス・コール, GET_USER_INFO, 25.3.3.4

サンプルのWSDLファイル, 25.5.2

スクリプト可能なサービス, 4.2.2.2

SctAutoTruncateDataStrings

Content Tracker構成設定, 12.3.1

SctComponentDir

Content Tracker構成設定, 12.3.1

SctDebugLogEnabled

Content Tracker構成設定, 12.3.1

SctDebugLogFilePath

Content Tracker構成設定, 12.3.1

SctDebugServiceBinderDumpEnabled

Content Tracker構成設定, 12.3.1

SctFilterPluginLogDir

Content Tracker構成設定, 12.3.1

SctIdcAuthExtraConfigParams

Content Tracker構成設定, 12.3.1

SctIgnoreDirectories

Content Tracker構成設定, 12.3.1

SctIgnoreFileTypes

Content Tracker構成設定, 12.3.1

SctLogDir

Content Tracker構成設定, 12.3.1

SctLogEnabled

Content Tracker構成設定, 12.3.1

SctLogSecurity

Content Tracker構成設定, 12.3.1

SctMaxRecentCount

Content Tracker構成設定, 12.3.1

SctMaxRereadTime

Content Tracker構成設定, 12.3.1

SctPostReductionExec

Content Tracker構成設定, 12.3.1

SctProxyNameMaxLength

Content Tracker構成設定, 12.3.1

SctReductionAvailableDatesLookback

Content Tracker構成設定, 12.3.1

SctReductionLogDir

Content Tracker構成設定, 12.3.1

SctReductionRequireEventLogs

Content Tracker構成設定, 12.3.1

SctScheduledReductionEnable

Content Tracker構成設定, 12.3.1

SctServiceFilter

構成ファイル, 12.4.1

コンテンツ, 12.4.1.3

エントリの編集, 12.4.3.1

SctSnapshotEnable

Content Tracker構成設定, 12.3.1

SctSnapshotLastAccessEnable

Content Tracker構成設定, 12.3.1

SctSnapshotlastAccessField

Content Tracker構成設定, 12.3.1

SctSnapshotLongCountEnable

Content Tracker構成設定, 12.3.1

SctSnapshotLongCountField

Content Tracker構成設定, 12.3.1

SctSnapshotLongCountInterval

Content Tracker構成設定, 12.3.1

SctSnapshotShortCountEnable

Content Tracker構成設定, 12.3.1

SctSnapshotShortCountField

Content Tracker構成設定, 12.3.1

SctSnapshotShortCountInterval

Content Tracker構成設定, 12.3.1

SctUrlMaxLength

Content Tracker構成設定, 12.3.1

SctUseGMT

Content Tracker構成設定, 12.3.1

SctWebBeaconIDList

Content Tracker構成設定, 12.3.1

検索索引

表

JCR, 24.5

使用

JCR, 24.6

search_results.htmファイル, 15.2.8 SearchML, 13.1 SearchResultTemplates ResultSet, 9.1.3.1.1 Search.wsdl, 25.5.1 Search.wsdlファイル, 25.5.1 セクション

データ, 4.2.4.2, 4.2.4.2.1

フォーム, 4.2.4.3

HEAD, HCSFページ, 4.2.4.1.4

ロード, 4.2.4.1

LocalData, 9.1.3.1.1

ResultSet, 9.1.3.1.1

セキュア・モードのレポート

プリファレンス変数の値, 12.3.1.2

セキュア・ソケット通信(SSL)

JCRアダプタ, 24.4.3

セキュア・ソケット通信(SSL), JCRアダプタ, 24.4.2 Security Assertion Markup Language, 19.1 セキュリティ・チェック

プリファレンス変数の値, 12.3.1.2

SendCommandメソッド, IdcClient OCX, 22.2.5.18 SendPostCommand CommandButtonプロパティ, 編集後, 22.2.3.2 SendPostCommandメソッド, IdcClient OCX, 22.2.5.19 SendPostCommand_Clickコード, 編集後, 22.2.3.2 サーバー・エラー, 表示, A.2 サーバー, WebDAV, 18.3.2.2 サービス属性

アクセス・レベル, 15.2.7

エラー・メッセージ, 15.2.7

サービス・クラス, 15.2.7

サービス・タイプ, 15.2.7

通知された件名, 15.2.7

テンプレート・ページ, 15.2.7

サービス・コール

ADD_USER, 25.3.3.2

CHECKIN_UNIVERSAL, 25.3.3.6

CHECKOUT_BY_NAME, 25.3.3.7

DELETE_USER, 25.3.3.5

DOC_INFO, 25.3.3.9

EDIT_USER, 25.3.3.3

GET_CRITERIA_WORKFLOWS_FOR_GROUP, 25.3.3.13

GET_FILE, 25.3.3.10

GET_SEARCH_RESULTS, 25.3.3.11

GET_TABLE, 25.3.3.12

UNDO_CHECKOUT_BY_NAME, 25.3.3.8

サービス・コール

ロギング, 12.4.1.1

サービス・コール

PING_SERVER, 25.3.3.1

サンプル, 25.3.3

SOAPレスポンス/リクエスト, 25.3.3

サービス・クラス属性, 15.2.7 サービス定義表, 15.2.7 サービス要素, WSDLファイル構造, 25.5.1.1 サービス・ハンドラ・フィルタ

構成ファイルの内容, 12.4.1.3

構成ファイルの概要, 12.4.1

エントリの編集, 12.4.3.1

serviceノード, 25.3.1.3.1 serviceノード, SOAP, 25.3.1.3.1 サービス・リソース属性, 15.2.7.1.1 サービス・リソース, 15.2.7

アクション, 15.2.7.1.2

編集, 15.2.7.2

例, 15.2.7, 15.2.7.1

概要, 1.1.2

サービスResultSet, 「アクション」列, 15.2.7 サービス・タイプ属性, 15.2.7 サービス

アクセス, IdcCommandユーティリティ, 21

アクション, 15.2.7

ユーザーの追加, 25.3.3.2

カスタマイズ, 7.1

DOC_INFO, 15.2.7.1, 25.3.3.9

DOC_INFO_SIMPLE, 4.6.1.1

例

アクション, 15.2.7.1.2

属性, 15.2.7.1.1

定義, 15.2.7

リソース, 15.2.7

実行可能ファイル, 1.1.1.2 RIDC, 23.5 スクリプト可能, 4.2.2.2 起動エラー, 1.1.1.2 「サービス」タブ

サービス・エントリの追加および編集, 12.4.4.1

フィールド・マップResultSetの追加, 12.4.4.2

SetFocusメソッド, IdcClient OCX, 22.2.5.20 設定,

IsJava, A.3

TraceResourceConflict, A.4

TraceResourceOverride, A.4

ShowDMSメソッド, IdcClient OCX, 22.2.5.21 ShowDocInfoLatestRevメソッド, IdcClient OCX, 22.2.5.22 ShowWhatsThisメソッド, IdcClient OCX, 22.2.5.23 Simple Object Access Protocol, 19.1 Simple Object Access Protocol。「SOAP」を参照 サイト・ビルダー, 13.1, 13.1 Site Studio

Webビーコン機能, 12.6.1

カスタマイズのスキル, 1.4 スキン

説明, 3.1.2

概要, 3.1

選択, 3.2

タイプ, 3.1.1

SOAP

通信, 25.1.1.3, 25.1.1.3

「データ・リストの要素」ページ, 25.6

定義, 25.1

メッセージ, 25.2

ノード

パケットの形式, 25.3.1.3

サービス, 25.3.1.3.1

パケットの形式

ドキュメント, 25.3.1.3.2

フィールド, 25.3.1.3.8

HTTPヘッダー, 25.3.1.1

idcネームスペース, 25.3.1.2

ネームスペース, 25.3.1.2

ノード, 25.3.1.3

optionlist, 25.3.1.3.4

概要,25.3.1

resultset, 25.3.1.3.6

サービス, 25.3.1.3.1

ユーザー, 25.3.1.3.3

リクエスト, 25.3.1 Webサービス、アクセス、特殊文字, 25.3.2 ソート・プロパティ, 15.2.2.3.3 特殊文字, 25.3.2 特殊文字

コマンド・ファイルの構文

#, 21.2.1.3

コマンド・ファイルの構文

\;, 21.2.1.3

説明, 21.2.1.3

EOD, 21.2.1.3

動的サーバー・ページ, 4.2.1, 4.2.1.3 EODコマンド・ファイル・タグ, 21.2.1.3 IdcServiceコマンド・ファイルのタグ, 21.2.1.3 文字列, 15.2.3 SOAP

XMLフォーマットで渡す, 25.3.2

Webサービス, アクセス, 25.3.2

特殊タグ, コマンド・ファイルの構文, 21.2.1.3 SQL問合せ

アクティビティ・メトリック用のカスタマイズ, 12.5.1.1

アクティビティ・メトリック用の削減後の手順, 12.5.1

標準コンポーネント, 9 ページの標準的な先頭, 1.5.3 ページの標準的な末尾, 1.5.3 ページの標準的なヘッダー, 1.5.3 標準レポート・ページstandard report pages, 15.2.8.1 標準リソース

例, 1.1.2

ロード, 1.5.1.1

標準テンプレート・ページ, 15.2.8.1 StandardResultsテンプレート, 15.2.8 StartSearchメソッド, IdcClient OCX, 22.2.5.24 起動動作, コンテンツ・サーバー, 1.5.1, 1.5.1 起動手順, コンテンツ・サーバー, 1.5.1.1 静的表リソース, 1.1.2 静的表, 15.2.5

編集, 15.2.5.2

マージ・ルール, 15.2.5.1

Stopメソッド, IdcClient OCX, 22.2.5.25 ストリーム

受信, RIDC, 23.7

送信, RIDC, 23.7

文字列パラメータ, 15.2.3.1 文字列

概要, 1.1.2

解決, 1.5.5

リソース・ファイル, 15.2.3

特殊文字, 15.2.3

構造, 15.2.3

構造, ファイルおよびディレクトリ, 9.1.4.4 通知された件名属性, 15.2.7 フォームの送信, 4.6.1.6 サブノード, SOAP

フィールド, 25.3.1.3.8

オプション, 25.3.1.3.5

resultset, 25.3.1.3.6

行, 25.3.1.3.7

スーパー・タグ, 15.2.1.1 Suppliersモジュール

説明, 2.1

構文

動的サーバー・ページ, 4.2.1

HCSFファイル, 4.2.1

HCSPファイル, 4.2.1

HCSTファイル, 4.2.1

IDOCファイル, 4.2.1

サービス・アクション, 15.2.7

システム・コンポーネント, 9 システム機能, 変更, 5 システム・プロパティ・ユーティリティ, 1.1.1.2, 5.1 システム設定, 変更, 5.1

T

表

コンテンツ・アイテム

JCR, 24.5

表示, 作成, 8.2 動的データ, 15.2.2 ファイル・ストア

JCR, 24.5

フォーマット, 指定, 15.2.2.1 ヘッドライン表示, 8.2.1 プロパティ, 指定, 15.2.2.3 リソース・タイプ, 1.1.1.5 検索索引

JCR, 24.5

サムネイル表示, 8.2.2 tablesディレクトリ, 1.1.1.5 タグ

idcformrules, 4.2.4.2.2

Idocスクリプト, 4.2.1

ResultSets

ネストされた, 4.2.4.2.7

繰り返された, 4.2.4.2.7

特殊, コマンド・ファイルの構文, 21.2.1.3 ResultSetsのXML定義, 4.2.4.2.7 テンプレート・ページ

属性, 15.2.7

例, 15.2.8.1.1, 15.2.8.1.1

標準の場所, 15.2.8

プレゼンテーション・ページ, 15.2.8.1

Webページ・リクエストの結果, 15.2.8.1

テンプレート・リソース, 15.2.8

編集, 15.2.8.2

MergeRules ResultSet, 15.2.8

概要, 1.1.2

テンプレート

ロード, 1.5.1.1

ページ, 例, 15.2.8.1.1

リソース・タイプ, 1.1.1.5

templatesディレクトリ, 1.1.1.5 用語, WebCenter Contentディレクトリ, 1.1.1.1 テキスト・エディタ, 1.4 テキスト・エディタ, コンポーネント・ファイルの編集, 9.1.4.2 サムネイル表示の表, 8.2.2 ヒント

動的サーバー・ページ, 4.2.3.1

HCSFページ, 4.2.3.2

Tomcatサーバー, 20.1, 20.1.2 ツール, カスタマイズ, 1.4 toTable列, 9.3.3.2.1 トレース・マーカー, A.3 TraceResourceConflict設定, A.4 TraceResourceOverride設定, A.4 トラブルシューティング, A.1 タイプ

カスタマイズ, 1.2

動的サーバー・ページ, 4.1.1

レイアウト, 3.1.1

スキン, 3.1.1

U

UDDIサービス・レジストリ, 25.1.1.4, 25.2

UNDO_CHECKOUT_BY_NAMEサービス, 25.3.3.8

UndoCheckoutメソッド, IdcClient OCX, 22.2.5.26

URLエンコーディング

, XMLフォーマット, 25.3.2

UseBrowserLoginPromptプロパティ, 22.2.6.4 ユーザー管理, 5.1 ユーザー・エージェント, JCRアダプタの構成, 24.4.5 ユーザー認証, RIDC, 23.4, 23.4 ユーザー・インタフェース, ランチャ, 21.4.4 userノード

SOAP, 25.3.1.3.3

userノード, SOAP, 25.3.1.3.3 ユーザー・パーソナライズ設定, 3.2 ユーザー・プロファイル・パーソナライズ設定, 3.2.1 ユーザー・セキュリティ, 提供, RIDC, 23.9.1 ユーザー, IdcCommandユーティリティ・オプション, 21.2.2.2 UserNameプロパティ, IdcClient OCX, 22.2.6.6 ユーティリティ, 1.1.1.2

IdcCommand

サービスへのアクセス, 21

V

変数

構成, 15.2.9

環境, 15.2.9

HCSFページ, 4.2.4.1.4

verifyコマンド, 22.2.3.2 ViewDocInfoメソッド, IdcClient OCX, 22.2.5.27 ViewDocInfoLatestRevメソッド, IdcClient OCX, 22.2.5.28 仮想フォルダ, 18.3.1 Visual Basic, 22.2.3.1 Visual Basic環境

開発用のビジュアル・インタフェース, 22.2.3

Visual Basicフォーム, OCXコントロール, 22.2.3.2 ビジュアル・インタフェース

コマンドの定義, 22.2.3.2

作成, 22.2.3.2

説明ラベル, 22.2.3.2

返された結果, 22.2.3.2

テスト, 22.2.3.2

Visual Studio .NET, 25.1.1.8

W

Webビーコン

設計のガイドライン, 12.6.6.2

設計に関する制限事項, 12.6.6.1

埋込みHTMLの例, 12.6.7.1

埋込みJavaScriptの例, 12.6.7.2

埋込みの例, 12.6.7

実装に関する考慮事項, 12.6.6

操作の概要, 12.6.2

概要, 12.6

参照 - 概要, 12.6.4

JavaScriptを処理する方法の例, 12.6.7.3

リバース・プロキシ・サーバー, 12.6.1

Site Studio, 12.6.1

Webビーコン参照

データ取得, 12.6.4.3

埋込み, 12.6.4.2

フォーマット構造, 12.6.4.1

フォーマットの例, 12.6.4.1

概要, 12.6.4

Webレイアウト・エディタ, 15.2.8 Webページ

動的サーバー・ページでのナビゲーションの変更, 4

Webページ, 動的アセンブリ, 1.5.3 Webリソースの公開, 3.4.1 Webサービス・ポリシー標準, 19.1 Webサービス

コンテキスト・ルート, 19.1.1

GenericSoapService, 19.1.1

IdcWebLoginService, 19.1.1

IdcWebRequestService, 19.1.1

.NET, 実装, 25.1.1.8

Oracle WebLogic Server

WebCenter Content Webサービス, 併用, 19

Oracle WSM, 18.2, 19.1, 25 概要, 18.2 SAML, 19.1 セキュリティ, 19.1 SOAP, アクセス

概要, 19.1

特殊文字, 25.3.2

WebCenter ContentとOracle WebLogic Server Webサービスの併用, 19 WS-Policy標準, 19.1 WS-Security標準, 19.1 Web Services Definition Language。「WSDL」を参照 Webサービスのフレームワーク, 18.2

SOAP通信, 25.1.1.3, 25.1.1.3

UDDIサービス・レジストリ, 25.1.1.4

WSDLインタフェース, 25.1.1.2

XMLデータ, 25.1.1.1, 25.1.1.1

WebCenter Content Webサービス, Oracle WebLogic Server Webサービスとの併用, 19 WebDAV

アーキテクチャ, 18.3.2.3, 18.3.2.3

クライアント, 18.3.2.1

ファンクション, 18.3.2

統合, 18.3, 18.3.2

サーバー, 18.3.2.2

WebDAVクライアント, 18.3.2.1 WebDAVクライアント, 18.3.2.1 WebDAVコンポーネント, 18.3 weblayoutディレクトリ, 1.1.1.6 Workflow.wsdlファイル, 25.5.1 コンポーネント・ファイルの操作, 9.1.4.2 WSDL

定義, 25.1

インタフェース, 25.1.1.2

仕様, 25.2

WSDL要素

バインディング, 25.5.1.1

データ型, 25.5.1.1

メッセージ, 25.5.1.1

ポート, 25.5.1.1

ポート・タイプ, 25.5.1.1

サービス, 25.5.1.1

WSDLファイル構造, 25.5.1.1

バインディング要素, 25.5.1.1.4

データ型要素, 25.5.1.1.1

メッセージ要素, 25.5.1.1.2

ポート・タイプ, 25.5.1.1.3

サービスおよびポート要素, 25.5.1.1.5

WSDLファイル

CheckIn.wsdl, 25.5.1

DocInfo.wsdl, 25.5.1

GetFile.wsdl, 25.5.1

MetaData.wsdl, 25.5.1

PortalInfo.wsdl, 25.5.1

Search.wsdl, 25.5.1, 25.5.1

Workflow.wsdl, 25.5.1

wsdl.hdaファイル, 25.5.3

X

XML, 13.1

変換, 13.1

XMLデータ, 25.1.1.1, 25.1.1.1 XMLタグ, 4.2.4.2.1, 4.2.4.2.3

ResultSetsの定義, 4.2.4.2.7

参照, 4.2.4.2.5

XMLベース・メッセージング・プロトコル, 25.1.1.9 XMLベースのリモート・プロシージャ・コール, 25.3.1 特殊文字のXMLエンコーディング, SOAP, 25.3.2

Z

ZIPファイル, 9.1.3.5.2

ZOrderメソッド, IdcClient OCX, 22.2.5.29

Copyright © 1994, 2011, Oracle and/or its affiliates. All rights reserved.