Oracle® Fusion Middleware

Oracle WebCenter Sitesの管理

12c (12.2.1)

E72541-01(原本部品番号:E49195-02)

2016年3月

このガイドは、Oracle WebCenter Sites AdminおよびWEM Adminインタフェースを使用して、コンテンツ・コントリビュータがWebサイトのコンテンツを提供できるようにする方法について説明しています。また、アセットに対する宛先のパブリッシュの構成、管理システムから配信システムへのアセットのパブリッシュ(この後でサイト・ビジターはそのアセットをWebサイトで表示できます)、そしてWebCenter Sites環境の管理および構成方法に関する情報も提供します。

Oracle Fusion Middleware Oracle WebCenter Sitesの管理 12c (12.2.1)

E72541-01

Copyright ©2012, 2016, Oracle and/or its affiliates All rights reserved.

原本主著者: Melinda Rubenau

原本協力著者: Promila Chitkara、Martin Wykes

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

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

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

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

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

目次

表一覧

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

はじめに

- 対象読者

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

- 製品のアクセシビリティ

- Oracle Supportへのアクセス

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

第I部 Oracle WebCenter Sitesの管理の理解

1 Oracle WebCenter Sitesの概要

- 1.1 Oracle WebCenter Sitesについて

- 1.2 WebCenter Sites管理者とは

- 1.3 管理者の前提条件

- 1.4 管理者が実行するWebサイト管理タスク

- 1.4.1 コンテンツ管理チームとのコラボレーション

- 1.4.2 ユーザーの管理

- 1.4.3 アクセス制御リスト(ACL)とロールの管理

- 1.4.4 アセット・タイプとアセットの管理

- 1.4.5 アプリケーションへのユーザー・アクセスの管理

- 1.4.6 ワークフローの管理

- 1.4.7 パブリッシュ・システムの管理

- 1.4.8 WebCenter Sitesとそのコンポーネントのパフォーマンスの管理

- 1.4.9 WebCenter ContentのWebCenter Sitesとの統合

- 1.5 このガイドで使用するサンプル・サイト

2 コンテンツ管理の概念について

- 2.1 Oracle WebCenter Sitesの概念の概要

- 2.2 Webサイト

- 2.3 コンテンツ管理サイト

- 2.4 構成コンポーネント

- 2.4.1 コンテンツ管理サイト定義

- 2.4.2 データ・モデル

- 2.4.3 ユーザーとその表レベルの権限

- 2.4.4 ユーザーおよびロール

- 2.4.5 スタート・メニュー

- 2.4.6 ワークフロー・プロセス

- 2.4.7 パブリッシュ・システム

- 2.4.8 ユーザー・インタフェース・オプション

- 2.5 コンテンツ管理モデル

- 2.5.1 1:1モデル

- 2.5.2 1:nモデル

- 2.5.3 x:nモデル

- 2.6 Oracle WebCenter Sites環境

3 ログインと開始

- 3.1 Oracle WebCenter Sitesへのログイン

- 3.1.1 Adminアイコンを選択した場合

- 3.1.2 WEM Adminインタフェースを選択した場合

- 3.2 WebCenter Sitesパスワードのリセット方法

- 3.3 Oracle WebCenter Sitesプロファイルの編集方法

- 3.4 WebCenter Sitesからのログアウト

4 WebCenter Sitesの管理のロードマップ

- 4.1 構成前の決定

- 4.2 各WebCenter Sitesシステム上のジョブの理解

- 4.2.1 開発システムの構成

- 4.2.2 管理システムの構成

- 4.2.3 配信システムの構成

- 4.2.4 テスト・システムの構成

- 4.3 テスト環境から本番環境への移行

- 4.4 WebCenter Sites管理者の共通タスク

第II部 サイト基盤の管理

5 コンテンツ管理サイトのアセンブル

- 5.1 サイトの使用

- 5.1.1 管理者インタフェースからのサイトの作成

- 5.1.2 サイトの構成情報の取得

- 5.1.3 Adminインタフェースでのサイトの編集

- 5.1.4 Adminインタフェースでのサイトの削除

- 5.2 サイト・ユーザーの割当てと管理

- 5.2.1 ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)

- 5.2.2 サイト・ユーザーの表示とロールの再割当て

- 5.2.3 サイトからのユーザーの削除

- 5.3 アセット・タイプの有効化と管理

- 5.3.1 サイトに対するアセット・タイプの有効化

- 5.3.2 サイトからのアセット・タイプの削除

6 ACLおよびロールの使用

- 6.1 ACLとロールの概要

- 6.2 アクセス制御リスト(ACL)

- 6.2.1 ユーザー・アカウントのACL

- 6.2.2 データベース表のACL

- 6.2.3 SiteCatalog表のページ・エントリのACL

- 6.2.4 システムACL

- 6.2.5 カスタムACL

- 6.3 ACLの使用

- 6.3.1 ACLの作成

- 6.3.2 カスタムACLの編集

- 6.3.3 カスタムACLの削除

- 6.3.4 カスタム表へのACLの割当て

- 6.3.5 WebCenter SitesページへのACLの割当て

- 6.4 ロール

- 6.5 ロールの使用

- 6.5.1 Adminインタフェースからのロールの作成

- 6.5.2 Adminインタフェースからのロールの編集

- 6.5.3 Adminインタフェースでのロールの削除

第III部 ユーザー・インタフェースとアセットの管理

7 ユーザー・インタフェースの構成

- 7.1 WebCenter Sitesインタフェースのロケールの設定

- 7.1.1 WebCenter Sitesユーザーのシステムのデフォルト・ロケールの使用

- 7.1.2 システムのロケール・プロパティ

- 7.1.3 単一言語の制限

- 7.1.4 ロケールとアセット・タイプ

- 7.1.5 ロケールと記事アセット・タイプ

- 7.2 Webモードの使用

- 7.3 プレビューに対する個別のブラウザ・セッションの維持

- 7.4 Contributorインタフェースのキーボード・ショートカットの変更

- 7.4.1 デフォルト・キーボード・ショートカット

- 7.4.2 Contributorインタフェースのキーボード・ショートカットのカスタマイズ

- 7.5 ユーザー・インタフェースのRight-to-Left (RTL)方向への設定

8 ユーザーの作成および認可

- 8.1 ユーザーの作成

- 8.2 アプリケーション使用のユーザーへの認可

- 8.3 事前定義済ユーザーの認可

- 8.4 アプリケーション登録の開発者への認可

- 8.5 使用できるアプリケーションに関する開発者への確認

9 コンテンツ管理サイト・コンポーネントへのアクセスの管理

- 9.1 概要

- 9.2 スタート・メニューを使用したアセット・タイプへのアクセスの管理

- 9.2.1 スタート・メニュー・アイテムの使用

- 9.2.1.1 異なる種類のユーザーのスタート・メニュー・アイテム

- 9.2.1.2 フレックス・アセットのスタート・メニュー・アイテム

- 9.2.2 スタート・メニュー・アイテムの管理

- 9.2.2.1 スタート・メニュー・アイテムについて

- 9.2.2.2 スタート・メニュー・アイテムの作成

- 9.2.2.3 「検索」スタート・メニュー・アイテムの作成

- 9.2.2.4 スタート・メニュー・アイテムの編集

- 9.2.2.5 すべてのスタート・メニュー・アイテムのリストの表示

- 9.3 アセットへのアクセス権限の設定方法

- 9.3.1 権限構造の理解

- 9.3.2 認可タイプの使用

- 9.3.3 アクセス権限の設定

- 9.3.3.1 アセット・ツールバー

- 9.3.3.2 管理者インタフェースでのアクセス権限の設定

- 9.3.3.3 プロパティ・ファイルからのアクセス権限の設定

- 9.4 アセット・タイプのその他のオプション

- 9.5 ツリーへのアクセスを管理するためのオプション(Adminインタフェースのみ)

- 9.5.1 ツリーの表示と非表示

- 9.5.2 ツリー・タブの作成について

- 9.5.2.1 ツリー・タブの作成

- 9.5.2.2 「ワークフロー・グループ」タブの作成

- 9.5.3 ツリーとノードの編集

- 9.5.4 ツリー・タブの削除

- 9.5.5 ツリー・タブの順序の変更

- 9.5.6 タブのノードに表示するアイテムの数の構成

10 管理者インタフェースの使用

- 10.1 管理ウィンドウについて

- 10.2 管理者固有のツリーとノード

- 10.2.1 「一般的な管理」ツリーの管理ノード

- 10.2.2 サイト・ツリーのサイト管理ノードについて

- 10.3 開発者関連のツリーとノード

- 10.3.1 一般管理ツリーの開発者ノードについて

- 10.3.2 コンテンツ・ツリーの開発者ノードについて

- 10.4 各種のツリーとノード

- 10.5 システム・デフォルトについて

11 Webエクスペリエンス管理フレームワークの使用

- 11.1 WEM 管理ウィンドウについて

- 11.2 Webエクスペリエンス管理フレームワークの概要

- 11.3 管理ロールおよび権限

- 11.3.1 一般管理者

- 11.3.2 サイト管理者

- 11.4 WebCenter Sitesアプリケーション

- 11.5 WEMフレームワークでのWebCenter Sites CMサイトの管理

- 11.6 ツリー・タブの有効化

- 11.7 WEMフレームワークの管理 - 簡単なヒントとロードマップ

- 11.8 WebCenter Sites管理者の共通WEMタスク

- 11.8.1 WEM Adminインタフェースでのサイトの管理

- 11.8.1.1 WEM Adminインタフェースでのサイトの作成

- 11.8.1.2 WEM Adminインタフェースでのサイトの編集

- 11.8.1.3 WEM Adminインタフェースでのサイトの削除

- 11.8.1.4 WEM Adminインタフェースのサイト・リストからサイトへのアプリケーションの追加

- 11.8.1.5 WEM Adminインタフェースのサイト・リストのサイトへのユーザーの割当て

- 11.8.1.6 WEM Adminインタフェースのサイト・リストからユーザーへのロールの再割当て

- 11.8.1.7 WEM Adminインタフェースのサイト・リストからアプリケーションへのロールの再割当て

- 11.8.1.8 WEM Adminインタフェースのサイト・リストのサイトからのユーザーの削除

- 11.8.1.9 WEM Adminインタフェースのサイト・リストのサイトからのアプリケーションの削除

- 11.8.2 アプリケーションの管理

- 11.8.2.1 アプリケーションの変更

- 11.8.2.2 WEM Adminインタフェースでのアプリケーションのサイトへの割当て

- 11.8.2.3 WEM Adminインタフェースのアプリケーション・リストからアプリケーションへのロールの再割当て

- 11.8.2.4 WEM Adminインタフェースのアプリケーション・リストのサイトからのアプリケーションの削除

- 11.8.3 WEM Adminインタフェースでのユーザーの管理

- 11.8.3.1 WEM Adminインタフェースのユーザー・リストからのユーザーの作成

- 11.8.3.2 WEM Adminインタフェースでのユーザー・リストからのユーザーの有効化

- 11.8.3.3 WEM Adminインタフェースでのユーザー・リストからサイトへのユーザーの割当て

- 11.8.3.4 WEM Adminインタフェースでのユーザー・リストからのユーザーの編集

- 11.8.3.5 WEM Adminインタフェースでのユーザー・リストからユーザーへのロールの再割当て

- 11.8.3.6 WEM Adminインタフェースからのユーザーのグループへの割当て

- 11.8.3.7 WEM Adminインタフェースのユーザー・リストでのサイトからのユーザーの削除

- 11.8.3.8 WEM Adminインタフェースでのユーザー・リストからのWebCenter Sitesユーザーの削除

- 11.8.4 WEM Adminインタフェースからのロールの管理

- 11.8.4.1 WEM AdminインタフェースからのWebCenter Sitesシステムへのロールの追加

- 11.8.4.2 WEM Adminインタフェースでのロール・リストからのロールの編集

- 11.8.4.3 WEM Adminインタフェースでのロール・リストからのロールの削除

- 11.8.5 WEM Adminインタフェースからのプロファイルの管理

- 11.8.5.1 ユーザー・プロファイルの変更

- 11.8.5.2 自身のプロファイルの変更

第IV部 ユーザーおよびセキュリティの管理

12 ユーザー、プロファイルおよび属性の構成

- 12.1 WebCenter Sitesユーザーの作成について

- 12.2 ユーザー管理オプションの理解

- 12.2.1 ネイティブのWebCenter Sitesユーザー・マネージャの理解

- 12.2.2 LDAPプラグインの理解

- 12.3 WebCenter Sitesでのユーザーの構成

- 12.4 ユーザー・アカウントの使用

- 12.4.1 Adminインタフェースでのユーザーの作成

- 12.4.2 一般的なユーザー・タイプの作成

- 12.4.2.1 ユーザーを一般管理者にする

- 12.4.2.2 ユーザーをサイト管理者にする

- 12.4.2.3 ユーザーをワークフロー管理者にする

- 12.4.2.4 ユーザーをコンテンツ・コントリビュータにする

- 12.4.3 Adminインタフェースからのユーザーの編集

- 12.4.4 Adminインタフェースを使用したシステムからのユーザーの削除

- 12.5 ユーザー・プロファイルとユーザー属性の使用

- 12.5.1 ユーザー・プロファイルの作成および編集

- 12.5.2 Adminインタフェースでのユーザー・プロファイルの削除

- 12.5.3 ユーザー属性の修正、追加および削除

13 外部セキュリティの設定

- 13.1 外部セキュリティの設定

- 13.1.1 WebCenter Sitesのセキュリティの概要

- 13.1.1.1 ACLとセキュリティの理解

- 13.1.1.2 DefaultReader、secure.CatalogManagerおよびsecure.TreeManagerの理解

- 13.1.1.3 BlobServerとセキュリティの理解

- 13.1.1.4 セキュリティの目的の実装

- 13.1.1.4.1 開発システムのセキュリティの目的の実装

- 13.1.1.4.2 管理システムのセキュリティの目的の実装

- 13.1.1.4.3 配信システムのセキュリティの目的の実装

- 13.1.2 セキュリティの実装

- 13.1.2.1 プロパティを使用したセキュリティ設定の構成

- 13.1.2.2 ユーザーとパスワードの使用

- 13.1.2.3 SSLとデジタル証明の使用

- 13.1.2.4 URLとWebサーバーの使用(配信システムのみ)

- 13.1.2.5 WebCenter Sitesフォームとページの使用(配信システムのみ)

- 13.1.3 セキュリティのテスト

- 13.2 暗号化および暗号化キー・セキュリティの実装

- 13.2.1 WebCenter Sitesのセキュリティの概要

- 13.2.2 WebCenter Sitesのセキュリティ構成について

- 13.2.3 SitesSecurityContext.xml構成ファイルについて

- 13.2.4 WebCenter Sitesセキュリティ・ユーティリティの使用

- 13.2.5 ESAPIセキュリティ検証の使用

- 13.3 RESTセキュリティの使用

- 13.3.1 REST認可

- 13.3.1.1 セキュリティ・モデル

- 13.3.1.2 権限解決アルゴリズム

- 13.3.2 アプリケーション・リソースへのアクセスのユーザーへの認可

- 13.3.2.1 RESTセキュリティ構成の表示

- 13.3.2.2 グループの作成

- 13.3.2.3 グループへのユーザーの追加

- 13.3.2.4 RESTリソースのセキュリティの構成

- 13.3.3 RESTセキュリティ構成リファレンス

- 13.3.3.1 ACLリソースのRESTセキュリティの構成

- 13.3.3.2 アプリケーション・リソースのRESTセキュリティの構成

- 13.3.3.3 アセット・リソースのRESTセキュリティの構成

- 13.3.3.4 アセット・タイプ・リソースのRESTセキュリティの構成

- 13.3.3.5 EngageリソースのRESTセキュリティの構成

- 13.3.3.6 グループ・リソースのRESTセキュリティの構成

- 13.3.3.7 索引付きアセット・タイプ・リソースのRESTセキュリティの構成

- 13.3.3.8 ロール・リソースのRESTセキュリティの構成

- 13.3.3.9 サイト・リソースのRESTセキュリティの構成

- 13.3.3.10 ユーザー・リソースのRESTセキュリティの構成

- 13.3.3.11 UserDefリソースのRESTセキュリティの構成

- 13.3.3.12 UserLocaleリソースのRESTセキュリティの構成

- 13.3.3.13 訪問者リソースのRESTセキュリティの構成

第V部 パブリッシュの管理

14 パブリッシュの理解

- 14.1 アセットのパブリッシュの前提条件

- 14.2 パブリッシュの宛先

- 14.3 ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可

- 14.4 承認システムの理解

- 14.5 スケジュール済パブリッシュ・セッションについて

- 14.6 パブリッシュ・セッションの理解

- 14.7 パブリッシュ・セッションに関する情報の取得

15 リアルタイム・パブリッシュの使用

- 15.1 リアルタイム・パブリッシュの概要

- 15.1.1 ソース・システムのパブリッシュ用構成

- 15.1.2 宛先システムのパブリッシュ用構成

- 15.2 リアルタイム・パブリッシュの使用

- 15.3 リアルタイム・パブリッシュに対するシステムの構成

- 15.3.1 バッチ・ユーザー・アカウントの作成(存在しない場合)

- 15.3.2 宛先システムの設定

- 15.3.3 ソース・システムのプロキシ・サーバーの識別

- 15.3.3.1 すべての宛先についてのソース・システムでのローカル・プロキシ・サーバーの識別

- 15.3.3.2 ローカル・プロキシ・サーバーをソース・システムで宛先ごとに識別する

- 15.3.4 ソース・システムでのリアルタイム宛先定義の作成

- 15.3.5 宛先データベースの初期化

- 15.3.6 宛先データベースへのサイト構成データのミラーリング

- 15.3.7 パブリッシュ・プロセスのテスト

- 15.3.7.1 アセットの承認

- 15.3.7.2 アセットのパブリッシュ

- 15.3.8 パブリッシュされたサイトのテスト

- 15.3.9 スケジュールの設定

- 15.3.10 配信システムでのアセットの無効化の解除

- 15.4 新規リアルタイム宛先定義の追加

- 15.5 サイト構成データの同期について

- 15.6 完了および遅延パブリッシュの区別

- 15.7 パブリッシュ・コンソールについて

- 15.8 アクティブなパブリッシュ・セッションの使用

- 15.8.1 パブリッシュ・セッションの監視

- 15.8.2 遅延パブリッシュ・セッションの再開

- 15.8.3 パブリッシュ・セッションの取消し

- 15.8.3.1 「パブリッシュ・コンソール」からのパブリッシュ・セッションの取消し

- 15.8.3.2 「ステータスのパブリッシュ」フォームからのパブリッシュ・セッションの取消し

- 15.9 スケジュール済パブリッシュ・セッションの使用

- 15.10 以前のパブリッシュ・セッションの使用

- 15.10.1 以前のパブリッシュ・セッションの表示

- 15.10.2 パブリッシュ・セッションの再実行

- 15.11 パブリッシュ・ログの使用

- 15.11.1 ログの表示と検索

- 15.11.2 ログのダウンロード

- 15.11.3 パブリッシュ履歴の削除

16 パブリッシュ・イベントのスケジュール

- 16.1 パブリッシュ・イベントのスケジュール

- 16.2 スケジュールの略称の読取り

- 16.3 パブリッシュ・イベントの編集

- 16.4 スケジュールのオーバーライド

- 16.5 承認テンプレートまたはプレビュー・テンプレートの割当て

- 16.6 「パブリッシュ・コンソール」でのセッションの監視

- 16.7 パブリッシュの準備状況の検証

- 16.8 パブリッシュ履歴について

- 16.9 セッション履歴について

- 16.10 すべての承認済アセットのパブリッシュについて

- 16.11 トラブルシューティング

- 16.11.1 パブリッシュ・システムのエラー・メッセージの理解

- 16.11.2 数値メッセージの理解

- 16.11.3 他のシステムまたは構成上の問題点の兆候

第VI部 承認およびワークフローの管理

17 承認システムの理解

- 17.1 承認システムについて

- 17.2 依存性分析の理解

- 17.3 パブリッシュの用語と定義の理解

- 17.3.1 承認: パブリッシュする意図とパブリッシュする権限の対比の理解

- 17.3.2 承認依存性の理解

- 17.3.2.1 承認依存性の例

- 17.3.2.2 承認依存性についての注意

- 17.3.3 承認状態の使用

- 17.4 依存性分析のルールの使用

- 17.5 承認依存性と親子関係の理解

- 17.6 ディスクへのエクスポートのパブリッシュの使用

- 17.6.1 承認依存性の評価

- 17.6.2 テスト・レンダリングの理解

- 17.7 サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの使用

- 17.8 コンテンツのバージョンの一致の保証

- 17.9 サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

- 17.10 ディスクへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

- 17.11 Exists/Exact依存性ルールの使用

- 17.11.1 ベーシック・アセット・タイプの依存性ルールの理解

- 17.11.2 CSElementおよびSiteEntryアセットの依存性ルールの理解

- 17.11.3 フレックス・ファミリの依存性ルールの理解

- 17.11.4 Engage訪問者データ・アセットの依存性ルールの理解

- 17.12 パブリッシュされたコンテンツの評価

- 17.13 承認システムの例

- 17.14 承認状態の使用: リファレンス

18 ワークフロー・プロセスの作成と管理

- 18.1 ワークフロー機能について

- 18.1.1 ワークフローの参加者の理解

- 18.1.2 ワークフロー状態の理解

- 18.1.3 状態から状態へのアセットの移動

- 18.1.4 アセットに対する複数のパスの使用

- 18.1.5 デッドロックの管理

- 18.1.6 ワークフロー・グループの理解

- 18.1.7 割当ての委任と消去

- 18.1.8 ワークフローへのアセットの配置

- 18.1.9 ワークフロー内にあるアセットへのアクセスの制限

- 18.1.10 期限の使用

- 18.1.11 期限計算のスケジュール

- 18.1.12 ワークフロー・プロセスの終了

- 18.2 ワークフロー・プロセスの計画

- 18.2.1 スケッチからの開始

- 18.2.2 ロールと参加者の決定

- 18.2.3 電子メール・オブジェクト、アクションおよび条件の決定

- 18.2.3.1 電子メール・オブジェクトの理解

- 18.2.3.2 時間指定アクションの理解

- 18.2.3.3 委任アクションの理解

- 18.2.3.4 ステップ・アクションの理解

- 18.2.3.5 ステップ条件の理解

- 18.2.3.6 デッドロック・アクションの理解

- 18.2.3.7 グループ・デッドロック・アクションの理解

- 18.2.4 状態の決定

- 18.2.5 ステップの決定

- 18.2.6 機能権限の決定

- 18.2.7 単純化されたアクセス制御の実装

- 18.2.8 追加のワークフロー・プロセスの詳細の決定

- 18.3 ワークフロー・プロセスの構成

- 18.4 電子メール・オブジェクトの設定

- 18.4.1 電子メール・オブジェクトの作成

- 18.4.2 電子メール・オブジェクトの編集

- 18.4.3 電子メール・オブジェクトの削除

- 18.5 アクションと条件の設定

- 18.5.1 アクションと条件の作成

- 18.5.2 アクションと条件の編集

- 18.5.3 アクションと条件の削除

- 18.6 パブリッシュの承認ステップ・アクションの構成

- 18.7 時間指定アクション・イベントの設定

- 18.8 状態の設定

- 18.8.1 ワークフロー状態の作成

- 18.8.2 ワークフロー状態の編集

- 18.8.3 ワークフロー状態の削除

- 18.9 ワークフロー・プロセスの設定

- 18.9.1 ワークフロー・プロセスの編集

- 18.9.2 ワークフロー・ステップの編集

- 18.9.3 機能権限の編集

- 18.9.4 ワークフロー・プロセスのコピー

- 18.9.5 ワークフロー・プロセスの削除

- 18.9.6 ワークフロー・ステップの削除

- 18.9.7 機能権限の削除

- 18.10 ワークフロー・プロセスの作成

- 18.10.1 プロセスの名前付けおよびグローバル設定の設定

- 18.10.2 ワークフロー・プロセスの開始ステップの作成

- 18.10.3 後続のワークフロー・ステップの作成

- 18.10.4 (オプション)ワークフロー・プロセスの終了ステップの作成

- 18.10.5 (オプション)ワークフロー・プロセスの機能権限の構成

- 18.11 ワークフロー・プロセスのテスト

- 18.12 作業の移動

- 18.13 ワークフローの割当ての消去

- 18.14 ワークフロー・レポートの作成および表示

- 18.15 ワークフロー・グループの作成

Part VII ブログ・コンポーネントの有効化

19 ブログ・アセット・タイプの有効化

20 ブログ・ツリー・タブの作成

21 ブログ・アセットの共有

22 ブログ作成者の使用

- 22.1 作成者アセットの作成

- 22.2 ブログ作成者アセットへのアクセス権限の設定方法

- 22.2.1 ブログ作成者用の一意のロールの作成

- 22.2.2 ブログ作成者へのロールの割当て

- 22.2.3 ブログ作成者アセットへのアクセス権限の設定

23 ブログ・アセットのワークフロー作成とパブリッシュについて

- 23.1 ブログ・アセット用ワークフローの作成

- 23.2 ブログ・アセットのパブリッシュについて

第VIII部 A/B Testingの有効化

24 A/B Testingの管理

- 24.1 A/B Testingの有効化

- 24.2 A/B Testingの依存性の考慮

- 24.3 A/Bテストのパブリッシュについて

第IX部 キャッシュの管理と調整

25 inCacheフレームワークの使用

- 25.1 概要

- 25.1.1 Caching Frameworkの概要

- 25.1.2 ページ・キャッシングの概要

- 25.1.3 アセットのキャッシングの概要

- 25.2 inCacheの仕組みの理解

- 25.3 ノードの再起動

- 25.4 リアルタイム・パブリッシュ時のページの再生成

- 25.5 ダブルバッファ・キャッシング

- 25.6 inCacheによるページ・キャッシングのためのシステムの構成

- 25.7 チューニング・オプション

- 25.7.1 ディスク・キャッシュのストライプ化

- 25.7.2 リアルタイム・パブリッシュ時のページの再生成の構成

- 25.7.3 ページ伝播の設定

- 25.7.3.1 ページ伝播の有効化

- 25.7.3.2 再起動時のページ伝播の設定

- 25.7.4 バックグラウンドでページレットを再生成するための構成

- 25.8 AssetCacheコンテナの使用

- 25.9 アセットのキャッシング操作の使用

- 25.9.1 アセット・ローディングの使用

- 25.9.2 アセットのキャッシングとinCacheのページ・キャッシングの比較

- 25.9.3 AssetCacheのフラッシュ

- 25.10 アセットのキャッシングのタイプ

- 25.11 アセットのキャッシングのカスタマイズ

- 25.12 アセットのキャッシングの無効化

- 25.13 キャッシュ管理ツールの使用

- 25.14 リモートのSatellite ServerのinCache機能の使用

第X部 WebCenter Sitesのモニターおよび保守

26 システム・ツールによるトラブルシューティング

- 26.1 ログODLの構成ツールの使用

- 26.1.1 ログ出力の表示

- 26.1.2 ログ出力レベルの変更

- 26.1.3 新しいログ出力の追加

- 26.2 システム情報ツールの使用

- 26.2.1 WebCenter Sites情報の表示

- 26.2.2 データベース情報の表示

- 26.2.3 スレッド情報の表示

- 26.3 キャッシュ管理ツールの使用について

- 26.4 キャッシュ管理の使用 - CASキャッシュ

- 26.4.1 CASキャッシュ概要フォームの概要

- 26.4.2 クラスタ情報の使用

- 26.5 キャッシュ管理の使用 - 結果セットのキャッシュ

- 26.5.1 inCacheを使用した結果セットのキャッシングの有効化と構成

- 26.5.2 サマリー・ビュー

- 26.5.3 クラスタ情報の表示

- 26.6 キャッシュ管理の使用 - Sitesキャッシュ

- 26.6.1 Sitesキャッシュ概要フォームの概要

- 26.6.2 ページ・キャッシュの使用

- 26.6.3 依存性キャッシュの使用

- 26.6.4 アセット・キャッシュの使用

- 26.6.5 URLキャッシュの使用

- 26.6.6 クラスタ情報の表示

- 26.7 キャッシュ管理の使用 - Co-Resキャッシュ

- 26.7.1 Co-Res SSキャッシュ概要フォームの概要

- 26.7.2 ページ・キャッシュの使用

- 26.7.3 依存性キャッシュの使用

- 26.7.4 URLキャッシュの使用

- 26.7.5 クラスタ情報の表示

- 26.8 ログ・ビューアの使用

- 26.8.1 ログの表示

- 26.8.2 ログの末尾の表示

- 26.8.3 ログのダウンロード

- 26.8.4 ログの検索

- 26.9 ファイル・システム・テスト・ツールの使用

- 26.10 スロット・アセットの使用

- 26.11 URLノードの使用

- 26.12 無効アセット・ノードのパージの使用

27 コンテンツ管理サイトのレプリケート

- 27.1 サイト・ランチャの概要

- 27.2 レプリケーションの準備

- 27.2.1 ソース・サイトのレプリケーション要件

- 27.2.2 新規サイトの計画

- 27.2.2.1 コピーと共有

- 27.2.2.2 アセット名の接頭辞

- 27.2.2.3 ユーザーの計画

- 27.2.2.4 レプリケーション・スケジュール

- 27.3 サイト・レプリケーションの有効化

- 27.3.1 サイト・ランチャに対するソース・サイトの構成

- 27.3.2 ソース・サイトのレプリケート

- 27.4 ポストレプリケーション・タスクの実行

28 リビジョン追跡の管理

- 28.1 リビジョン追跡の概要

- 28.1.1 トラッカ表とストレージ・ディレクトリ

- 28.1.2 RTInfo表

- 28.1.3 リビジョン追跡と2つのアセット・モデル

- 28.1.4 暗黙的チェックインと明示的チェックイン、および明示的チェックアウト

- 28.1.5 リビジョン追跡とアセット以外の表

- 28.1.6 バージョンの数

- 28.2 リビジョン追跡の有効化

- 28.2.1 アセットに対するリビジョン追跡の有効化

- 28.2.2 アセット以外の表に対するリビジョン追跡の有効化

- 28.2.3 リビジョン追跡設定の編集

- 28.2.3.1 ルート・ストレージ・ディレクトリの変更

- 28.2.3.2 リビジョンの数の変更

- 28.3 リビジョン追跡の無効化

- 28.4 リビジョンのロック解除

29 バニティURLの構成

- 29.1 WebRootsの使用

- 29.1.1 URLに必要なWebRootsの様々なタイプ: 例

- 29.1.2 新しいWebRootの作成

- 29.1.3 WebRootの表示

- 29.1.4 既存のWebRootの編集

- 29.1.5 WebRootの承認とパブリッシュ

- 29.2 バニティURLの生成

- 29.2.1 自動生成URLの構成

- 29.2.2 URLパターンの使用

- 29.2.2.1 関数の使用

- 29.2.2.2 パターンの使用

- 29.2.2.3 パターンの削除

- 29.2.3 URLパターンのパブリッシュについて

- 29.2.4 バニティURLへのリダイレクトの無効化

- 29.3 システム・ツールによるバニティURLの使用

- 29.3.1 すべてのバニティURLの表示

- 29.3.2 バニティURL競合の解決

- 29.4 リライタ・フィルタによるバニティURLの解決

- 29.5 モバイル・サイトのバニティURLの使用

- 29.6 WebサーバーによるバニティURLの処理

- 29.7 mod_rewriteによるバニティURLの処理

- 29.7.1 mod_rewriteの設定

- 29.7.1.1 用意されている例の設定

- 29.7.2 mod_rewriteによる変換について

- 29.7.3 mod_rewriteによるWebCenter Sitesフィルタの使用

- 29.7.4 mod_rewriteによるリライタ・フィルタの使用

- 29.7.5 mod_rewriteによる静的コンテンツの使用

30 Lucene検索エンジンの構成

- 30.1 WebCenter Sitesの検索機能の概要

- 30.1.1 検索のための索引付け機能

- 30.1.2 WebCenter Sitesの検索機能の使用

- 30.2 検索索引の設定

- 30.2.1 Lucene検索エンジンの有効化

- 30.2.2 検索索引へのアセット・タイプの追加

- 30.2.3 アセット・タイプ索引の属性の構成

- 30.2.4 バイナリ・ファイルの索引付け

- 30.2.4.1 バイナリ・ファイルの索引付けの有効化

- 30.2.4.2 バイナリ・ファイルの索引付けの無効化

- 30.3 Lucene検索エンジンの無効化

- 30.4 検索索引の維持

- 30.4.1 索引付けの一時停止と再開

- 30.4.1.1 グローバルおよびアセット・タイプの索引付けの一時停止

- 30.4.1.2 グローバルおよびアセット・タイプの索引付けの再開

- 30.4.2 索引の再作成

- 30.4.3 索引データの削除

- 30.5 検索索引の問合せコードの記述

31 サイト・キャプチャ・アプリケーションの使用

- 31.1 サイト・キャプチャ・モデル

- 31.1.1 キャプチャ・モード

- 31.1.2 クローラ

- 31.2 サイト・キャプチャ・アプリケーションへのログイン

- 31.3 デフォルト・クローラの使用

- 31.3.1 Sampleクローラ

- 31.3.2 FirstSiteIIクローラ

- 31.3.3 デフォルト・クローラの実行

- 31.4 サイト・キャプチャの操作の設定

- 31.4.1 初期クローラ構成ファイルの作成

- 31.4.2 クローラの定義

- 31.4.3 クローラ構成ファイルの編集

- 31.4.4 クロールの開始

- 31.4.4.1 静的モードでのクローラの手動実行

- 31.4.4.2 アーカイブ・モードでのクローラの手動実行

- 31.4.4.3 クローラのアーカイブ・キャプチャのスケジュール

- 31.4.4.4 リアルタイム・モードでのサイトのパブリッシュについて

- 31.4.5 キャプチャ・データの管理について

- 31.5 パブリッシュによってトリガーされるサイト・キャプチャの有効化

- 31.5.1 サイト・キャプチャ・アプリケーションとOracle WebCenter Sitesの統合について

- 31.5.2 サイト・キャプチャ用のリアルタイム・パブリッシュの宛先定義の構成

- 31.5.3 クローラの一致

- 31.5.4 サイト・キャプチャの管理

- 31.6 静的にキャプチャされたサイトの管理

- 31.7 アーカイブされたサイトの管理について

- 31.8 クローラおよびキャプチャされたデータを管理するための注意事項とヒント

- 31.8.1 クローラを作成および編集する際のヒント

- 31.8.2 クローラ削除の注意

- 31.8.3 クローラのスケジュールの注意

- 31.8.4 静的クロールの監視について

- 31.8.5 クロールの停止について

- 31.8.6 アーカイブのダウンロードについて

- 31.8.7 サイトのプレビューについての注意

- 31.8.8 パブリッシュの宛先定義の構成のヒント

- 31.8.9 ログ・ファイルへのアクセスについて

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

- 31.10 カスタム・フォルダ

32 Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理

- 32.1 WebLogic ServerコンソールでのWebCenter Sitesとそのコンポーネントの起動

- 32.2 Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動

- 32.3 WebCenter Sitesとそのコンポーネントのホームページの表示

- 32.4 WebCenter Sitesとそのコンポーネントのログ・ファイルの管理

- 32.4.1 WebCenter Sitesとそのコンポーネントのログ・ファイル設定の構成

- 32.4.2 WebCenter Sitesとそのコンポーネントのログ・ファイルの表示

- 32.5 WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの監視

- 32.5.1 WebCenter Sitesとそのコンポーネントのステータスの表示

- 32.5.2 WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの表示

- 32.5.2.1 WebCenter Sitesのパフォーマンス・メトリック

- 32.5.2.1.1 BlobServerサーブレットの詳細、ContentServerサーブレットの詳細およびSatelliteサーブレットの詳細

- 32.5.2.1.2 キャッシュ詳細

- 32.5.2.1.3 JDBC Info

- 32.5.2.1.4 ThreadPool Info

- 32.5.2.1.5 OS詳細

- 32.5.2.1.6 エラーの数

- 32.5.2.1.7 NIOの詳細

- 32.5.2.1.8 接続メトリック

- 32.5.2.1.9 メモリーの詳細メトリック

- 32.5.2.1.10 ServerStateメトリック

- 32.5.2.2 Visitor Servicesのパフォーマンス・メトリック

- 32.5.2.2.1 ThreadPool Info

- 32.5.2.2.2 OS詳細

- 32.5.2.2.3 エラー数

- 32.5.2.2.4 NIOの詳細

- 32.5.2.2.5 接続メトリック

- 32.5.2.2.6 メモリーの詳細メトリック

- 32.5.2.2.7 ServerStateメトリック

第XI部 Oracle WebCenter Contentとの統合

33 WebCenter Content統合の理解

- 33.1 WCC統合の管理の前提条件

- 33.2 WebCenter Contentの統合の基本

- 33.3 WebCenter Contentのデータ・モデル

- 33.4 アセット・タイプのマッピングとコネクタ・ルール

- 33.4.1 アセット・タイプのマッピング

- 33.4.1.1 コンテンツ識別子属性

- 33.4.1.2 コンテンツ記憶域属性

- 33.4.1.3 テンプレート属性

- 33.4.1.4 管理者定義の仕様

- 33.4.2 コネクタ・ルール

- 33.5 WebCenter Contentの統合とその要素

- 33.6 SitesIntegrationコンポーネントの有効化

- 33.7 「コネクタ管理者」タブへのアクセスの有効化

34 コンテンツ同期の設定

- 34.1 コンテンツ・アイテムの同期の有効化

- 34.2 同期するレンディションの決定

- 34.3 ターゲット・アセット・タイプの選択または作成

- 34.4 WebCenter Contentへの接続

- 34.5 アクティブ・ルールの作成

- 34.6 アクティブ・ルールの優先順位の設定とルールの管理

- 34.7 コネクタの手動実行

- 34.8 コネクタの監視

- 34.9 コネクタ履歴の表示

- 34.9.1 コネクタ履歴全体の表示

- 34.9.2 単一バッチのコネクタ履歴の表示

- 34.10 インポートされたコンテンツの検証

- 34.11 設定を変更するには

- 34.12 コネクタのスケジュール

- 34.13 同期されたアセットの管理

- 34.13.1 マップ済属性

- 34.13.2 親がないコンテンツ

- 34.14 同期ポイントのロールバック

- 34.14.1 元の開始ポイントへのロールバック

- 34.14.2 特定の更新へのロールバック

- 34.15 生成されたトークン値について

35 WCCコネクタ構成ファイルの使用

- 35.1 WCCコネクタの構成ファイルについて

- 35.2 ユーザー構成可能なパラメータ

第XII部 リファレンス

36 システム・デフォルト

- 36.1 ACL

- 36.1.1 権限

- 36.1.2 ACLへのアクセス

- 36.2 システムACLとその権限

- 36.3 デフォルト・ユーザーのACL

- 36.4 カスタム・ユーザー用の必須のACL

- 36.5 システム・ロール

- 36.6 システム・アセット・タイプ

- 36.7 デフォルトのツリー・ノード

37 WebCenter Sitesのデータベース表

- 37.1 キャッシュ管理の表

- 37.2 承認システムの表

- 37.3 パブリッシュ・システムの表

- 37.4 ワークフローの表

- 37.5 ベーシック・アセットの表

- 37.6 フレックス・アセットの表

- 37.7 訪問者の表(Engage)

- 37.7.1 属性の表の管理

- 37.7.2 セッション・オブジェクト(Scratch)表の管理

- 37.7.3 不要な.classファイルの削除

38 LDAP統合Sitesシステムでのユーザー、サイト、およびロール

- 38.1 LDAP統合WebCenter Sitesのシステム

- 38.1.1 LDAPスキーマ

- 38.1.2 サイトおよびロール管理に対するLDAPの接続性

- 38.1.3 LDAPユーザーとLDAPサーバーに対する彼らの権限

- 38.1.4 LDAP統合操作

- 38.2 ユーザー管理操作

- 38.2.1 ACLを作成するためのLDAPサーバー・レスポンス

- 38.2.2 ACLを編集するためのLDAPサーバー・レスポンス

- 38.2.3 ACLを削除するためのLDAPサーバー・レスポンス

- 38.2.4 ACLを表に割り当てるためのLDAPサーバー・レスポンス

- 38.2.5 ACLをWebCenter Sitesページ(サイト・カタログ・ページ・エントリ)に割り当てるためのLDAPサーバー・レスポンス

- 38.2.6 ユーザーを作成する(アクセス権のためにACLを付与する)ためのLDAPサーバー・レスポンス

- 38.2.7 ユーザーを編集するためのLDAPサーバー・レスポンス

- 38.2.8 ユーザーを削除するためのLDAPサーバー・レスポンス

- 38.2.9 ユーザー・プロファイルを作成/編集するためのLDAPサーバー・レスポンス

- 38.2.10 ユーザー・プロファイルを削除するためのLDAPサーバー・レスポンス

- 38.2.11 ユーザー属性を作成するためのLDAPサーバー・レスポンス

- 38.2.12 ユーザー属性を編集/削除するためのLDAPサーバー・レスポンス

- 38.3 サイトおよびロールの管理操作

- 38.3.1 フラットスキーマLDAPサーバーでの操作

- 38.3.2 階層スキーマLDAPサーバーでの操作

- 38.3.3 サイトを作成するためのLDAPサーバー・レスポンス

- 38.3.4 サイトを編集するためのLDAPサーバー・レスポンス

- 38.3.5 サイトを削除するためのLDAPサーバー・レスポンス

- 38.3.6 サイトへのユーザー・アクセスを付与するためのLDAPサーバー・レスポンス

- 38.3.7 サイトへのユーザーのアクセス権を削除するためのLDAPサーバー・レスポンス

- 38.3.8 ロールを作成するためのLDAPサーバー・レスポンス

- 38.3.9 ロールを編集するためのLDAPサーバー・レスポンス

- 38.3.10 ロールを削除するためのLDAPサーバー・レスポンス

39 代替パブリッシュ方法

- 39.1 代替パブリッシュ方法について

- 39.2 オンデマンド・パブリッシュの使用方法

- 39.3 選択したアセットをパブリッシュ・セッションに対して非承認にする

- 39.4 ディスクへのエクスポートのパブリッシュの用語の詳細

- 39.4.1 ページ

- 39.4.2 パブリッシュ・キー

- 39.4.3 パブリッシュ・キュー

- 39.4.4 プライマリ・アセット

- 39.5 承認およびディスクへのエクスポートのパブリッシュの使用

- 39.5.1 承認テンプレートの使用

- 39.5.2 承認キューの使用

- 39.5.3 承認依存性の使用

- 39.6 ディスクへのエクスポートのパブリッシュの使用

- 39.6.1 パブリッシュ時テンプレートの使用

- 39.6.2 開始ポイントの使用

- 39.6.3 構成依存性の使用

- 39.7 パブリッシュ・ディスクへのエクスポートのプロセスに関するよくある質問

- 39.8 パブリッシュの動作と機能の調査

- 39.8.1 テンプレート依存性の調査

- 39.8.2 参照依存性の調査

- 39.9 承認テンプレートとパブリッシュ時テンプレートが異なる場合

- 39.9.1 テンプレートの区別: 例1

- 39.9.2 テンプレートの区別: 例2

- 39.9.3 テンプレートの区別: 例3

- 39.10 サンプル・テンプレートの使用

- 39.11 ディスクへのエクスポートのページのレンダリング

- 39.12 ディスクへのエクスポートのパブリッシュの理解

- 39.13 パスの命名規則の使用

- 39.13.1 エクスポート・パス変数とSIMPLEDIRの使用

- 39.13.2 エクスポート・パスの構成の使用

- 39.13.2.1 エクスポート・パスの強制指定の使用

- 39.13.2.2 ページ・アセットのエクスポート・パスの使用

- 39.13.2.3 ページ以外のアセットのエクスポート・パスの使用

- 39.13.2.4 サンプルのエクスポート・パスの使用

- 39.13.3 エクスポートされたファイル内のリンクのパスの使用

- 39.13.4 ファイルの命名規則の使用

- 39.13.5 エクスポート開始ポイントの使用

- 39.14 ディスクへのエクスポートのパブリッシュに対するシステム構成

- 39.14.1 エクスポート・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- 39.14.2 ルート・エクスポート・ディレクトリの指定

- 39.14.3 エクスポート先の構成

- 39.14.4 WebサーバーのURL接頭辞のマッピング

- 39.14.5 エクスポート開始ポイントの作成

- 39.14.6 ディスクへのエクスポートのパブリッシュのためのアセットの承認

- 39.14.7 結果のパブリッシュとテスト

- 39.14.8 スケジュールの設定

- 39.15 サーバーへのミラーリングのパブリッシュの理解

- 39.16 サーバーへのミラーリングのパブリッシュを構成する前に

- 39.16.1 ユーザーとサーバーへのミラーリングのパブリッシュの使用

- 39.16.2 CacheManagerの使用

- 39.16.3 ミラーリング先の構成

- 39.16.4 ミラーリング先の構成を使用する場合の決定

- 39.17 サーバーへのミラーリングのパブリッシュに対するシステム構成

- 39.17.1 ミラーリング・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- 39.17.2 宛先システムの設定

- 39.17.3 ソース・システムでのミラー・ユーザーの識別

- 39.17.4 ソース・システムでのローカル・プロキシ・サーバーの識別(存在する場合)

- 39.17.5 ミラーリング先の作成

- 39.17.6 宛先の初期化

- 39.17.7 ミラーリング先の構成

- 39.17.8 アセットの承認

- 39.17.9 アセットのパブリッシュ

- 39.17.10 結果のテスト

- 39.17.11 スケジュールの設定

- 39.17.12 配信システムでのアセットの無効化の解除

- 39.18 配信WebCenter Sitesシステムからのログの取得

- 39.19 XMLへのアセットのエクスポートのパブリッシュ方法

- 39.19.1 XML出力の理解

- 39.19.2 XMLへのアセットのエクスポートに対するファイルの命名規則の理解

- 39.20 XMLへのアセットのエクスポートに対するシステムの構成

- 39.20.1 XMLパブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- 39.20.2 ルート・エクスポート・ディレクトリの指定

- 39.20.3 XMLへのアセットのエクスポートの宛先の構成

- 39.20.4 XMLパブリッシュのためのアセットの承認

- 39.20.5 結果のパブリッシュとテスト

- 39.20.6 スケジュールの設定

- 39.21 あるシステムから別のシステムへのサイトの移行

- 39.21.1 開発システムから管理システムへのサイトの移動

- 39.21.2 配信システムへのサイトの移動

- 39.22 複数アセットの承認

- 39.23 宛先の作成

- 39.24 宛先の編集

- 39.25 宛先の削除

- 39.26 エクスポート開始ポイントの作成

表一覧

- 2-1 サイト・コンポーネント

- 7-1 システムのロケール・プロパティ

- 9-1 権限の構造

- 10-1 タブの権限とロール

- 10-2 ツリーの権限とロール

- 13-1 使用できるアクション(セキュリティ権限)

- 13-2 可能なセキュリティ構成オプションの概要

- 13-3 「新規セキュリティ構成の追加」のフィールド名

- 13-4 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-5 「新規セキュリティ構成の追加」のフィールド名

- 13-6 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-7 「新規セキュリティ構成の追加」のフィールド名

- 13-8 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-9 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-10 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-11 「新規セキュリティ定義の追加」のフィールド名

- 13-12 「新規セキュリティ構成の追加」フォームのフィールド名

- 13-13 「新規セキュリティ構成の追加」のフィールド名

- 13-14 「新規セキュリティ構成の追加」のフィールド名

- 16-1 数値エラー・メッセージ

- 17-1 アセットの関係と依存性

- 17-2 フレックス・ファミリの依存性ルール

- 17-3 Engage訪問者データ・アセットの承認依存性

- 17-4 承認システムにより割り当てられる承認状態

- 18-1 ワークフロー・エレメントの名前と期待される変数

- 18-2 デフォルト・ワークフロー変数

- 18-3 機能および許容されるユーザー処理

- 25-1 キャッシュ構成プロパティ

- 25-2 アセットとページのキャッシングで使用されるキャッシュ・コンテナ

- 26-1 概要表の列の説明

- 26-2 キャッシュ詳細表の列の説明

- 26-3 テストされるファイル・システム

- 27-1 コンポーネントとレプリケーション

- 28-1 RTInfo表

- 29-1 WebRootの各タイプの利点と欠点

- 29-2 共通のアセット・タイプ変数

- 30-1 検索機能

- 31-1 静的キャプチャ・モードとアーカイブ・モード

- 31-2 <crawlerName>フォルダとそのコンテンツ

- 31-3 サイト・キャプチャの頻繁にアクセスされるフォルダ

- 32-1 WebCenter Sites : <コンポーネント>メニュー・オプション

- 33-1 WccConversionPreview.jspの属性

- 33-2 アクティブ・コネクタ・ルールの順序により決定されるコンテンツの配布方法

- 34-1 属性マップ・エントリ

- 34-2 SystemEvents表の時間パターンのフィールド

- 36-1 WebCenter Sitesによってサポートされる権限

- 36-2 システムACLとその権限

- 36-3 システムACLとその説明

- 36-4 デフォルト・ユーザーとそのACL

- 36-5 ユーザーに必要とされるシステムACL

- 36-6 システム・ロール

- 36-7 システム・アセット・タイプ

- 36-8 WebCenter Sites Adminインタフェースのデフォルトのツリー・ノード

- 37-1 キャッシュ管理の表

- 37-2 承認システムの表

- 37-3 パブリッシュ・システムの表

- 37-4 ワークフローの表

- 37-5 フレックス・アセットの表

- 37-6 Engageの訪問者の表

- 38-1 LDAPの統合シナリオ

- 38-2 WebCenter Sitesでのユーザー管理操作に対するシステム・レスポンス

- 38-3 フラットスキーマLDAPでのサイトおよびロールの管理操作に対するシステム・レスポンス

- 38-4 階層スキーマLDAP (WebCenter Sites Webアプリケーション)でのサイトおよびロールの管理操作に対するシステム・レスポンス

- 39-1 テンプレート依存

- 39-2 参照依存性

- 39-3 設定可能なfile_dirの値

- 39-4 SIMPLEDIR=falseの場合のページ・アセットのサンプルのエクスポート・パス

- 39-5 SIMPLEDIR=falseの場合のページ以外のアセットのサンプルのエクスポート・パス

- 39-6 ファイル・ネーミング規則

- 39-7 エクスポート・ファイルの命名規則

はじめに

このガイドでは、Oracle WebCenter Sitesを管理する手順について説明します。

対象読者

このドキュメントは、エンタープライズレベルのソフトウェアをインストールおよび構成した経験のあるWebCenter Sitesの一般管理者を対象としています。また、WebCenter Sitesのフレックス・アセット・モデルとリアルタイム・パブリッシュに対する十分な理解が必要になります。

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

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

製品のアクセシビリティ

Oracle WebCenter Sites: Contributorインタフェースでは、サポートされているオペレーティング・システムで高コントラスト・モードが選択されている場合はこのオプションを使用します。

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 WebCenter Sitesリリース12c (12.2.1)ドキュメント・セットにある次のドキュメントを参照してください。

- Oracle WebCenter Sitesリリース・ノート

- Oracle WebCenter Sitesの使用

- Oracle WebCenter Sitesでの開発

- Oracle WebCenter Sitesプロパティ・ファイル・リファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

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

イタリック

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

monospace

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

このガイドで説明する新機能

ここではWebCenter Sites 12c (12.2.1)の新しい機能について説明し、詳細情報の参照先を示します。また、非推奨の機能についてもリストします。

Oracle WebCenter Sites 12c (12.2.1)には、次の新機能が含まれます。

機能

説明

次の項を参照

Visitor Services

Visitor Servicesを使用すると、WebCenter Sitesのページで、Google、Facebook、主なCRMシステム、およびカスタム・データ・ソースなどの複数の外部プラットフォームにわたって取得された訪問者データを活用できるようになります。取得された訪問者のアクティビティ・データは、複数のリポジトリから統合訪問者プロファイルに集計できます(固有の訪問者IDに結び付けられたテンプレート・ベースの集計を介して)。WebCenter Sitesのマーケティング担当者はこのプロファイルを使用して、訪問者のセグメント化作業やセグメント単位でのコンテンツのターゲット設定作業を改善できます。

革新的なプロファイリングにより、以前に取得した訪問者データが新しいデータを使用して継続的に改善されるため、訪問者がサイトで費やす時間が長くなるほどターゲット設定の精度が高まります。組込みのREST APIにより、キャプチャ済の豊かな訪問者データを外部アプリケーションと共有でき、電子メール・マーケティング・システム、CRMシステムや、その他多くのものと統合することができます。

- WebCenter Sites: Visitor Servicesの理解

- Visitor Servicesの開発

A/B Testing

A/B Testingを使用すると、マーケティング担当者は、コンテンツの各部を互いに実地試験することにより、どの部分が訪問者の好みに最も合っているかを確認できます。Contributorインタフェースから直接アクセス可能なA/B Testingを使用すると、マーケティング担当者はテストを完全に制御できます。また、テスト・バリアントとしてコンテンツ、プレゼンテーション、またはこれら両方の混成のいずれを使用するかを選択することもできます。マーケティング担当者は、テストの開始、テストが成功したかどうかの判断、およびテストの終了に関する基準を選択できます。

テストが開始されたら、マーケティング担当者は、コンテキストに対応した対話式のレポートを使用して、ターゲット・ページで各テストのパフォーマンスをリアルタイムで直接追跡したり、特定のテスト・バリアントを停止またはプロモーションしたり、テストのレポート・インタフェースに進んでより包括的なパフォーマンス・メトリックを参照できます。A/B TestingはWebCenter Sitesに完全に統合されているため、別個のサードパーティのテスト・ツールに関するライセンス供与やトレーニングは必要なく、オーサリング、構築、テスト、配信が統合された単一のソリューションを提供します。

- A/B Testingの使用

- A/B Testingの管理

- A/B Testing用の開発

Enterprise Manager

WebCenter SitesとVisitor Servicesを、Oracle Enterprise Managerを使用して管理および監視できるようになりました。インスタンスの起動と停止、コンポーネント・ホームページの表示、ログの管理およびパフォーマンス・メトリックの確認がサポートされています。

Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理

セキュリティの強化

セキュリティ向上のため、WebCenter Sitesが、Oracle Platform Security Services (OPSS)資格証明ストアをサポートするようになりました。資格証明ストアとの通信は暗号化され(HTTPS)、個々のWebCenter Sitesインスタンスは一意に認証されます。

- 外部セキュリティの設定

- 資格証明ストアのプロパティ

- Oracle WebCenter Sitesのインストールと構成

新しいWebCenter Sitesデプロイメント・プロセス

WebCenter Sitesとそのコンポーネント・アプリケーションは、Oracle Universal Installerの一部になりました。以前の手動デプロイメント・タスクは自動化され、インストール後の構成はWebベースのConfiguratorsを介して行われるようになりました。一部のデプロイメント・タスクは、ターゲット環境の個別事情に基づいて、まだ手動で完了する必要があります。

Oracle WebCenter Sitesのインストールと構成

共有ファイル・システムをデータベースに格納可能

WebCenter Sitesは、共有ファイル・システムの、ローカルまたはネットワークにあるディスク・ボリュームでなく、データベースへの格納をサポートするようになりました。提供された変換ツールは、デフォルトのディスクベースの共有ファイル・システムを、WebCenter Sitesリポジトリ・データベースまたは別個のデータベースに移動します。このツールは、ディスクベースの共有ファイル・システムへの復帰もサポートします。

データベースへの共有ファイル・システムの移動

Adminインタフェース・ツリーの更新

Adminツリーの使いやすさと汎用性が改善されました。タブは除去され、「一般的な管理」、「ワーク」、「コンテンツ」、「サイト」の4つの別々のツリーを使用できるようになりました。ツリーはJavaアプレットを利用しなくなりました。かわりにDojoテクノロジを使用します。

- 管理者固有のツリーとノード

- 開発者関連のツリーとノード

- 各種のツリーとノード

コントリビュータ・パブリッシュ

現在、パブリッシャ・ロールを持つユーザーは、Contributorインタフェースからページとアセットを直接パブリッシュできます。これにより、規模が小さいパブリッシュ・ジョブにWebCenter Sites管理者が関与しなくてもすむようになります。

- Contributorインタフェースのパブリッシュ機能の使用

- ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可

- アプリケーション使用のユーザーへの認可

- アセットのパブリッシュの前提条件

アクセシビリティの拡張

現在、WebCenter Sitesは、Oracle Accessibility Guidelines 2.0に準拠した構成可能なアクセシビリティ機能をサポートしています。これには、Contributorインタフェースと管理インタフェース向けのスクリーン・リーダーのサポート、カスタマイズ可能なキーボード・ショートカット、シームレスなキーボードベースのナビゲーション、および高コントラスト・モードが含まれます。

- Contributorインタフェースのキーボード・ショートカット

- 製品のアクセシビリティ(ユーザー)

- Contributorインタフェースのキーボード・ショートカットの変更

- はじめに

log4jからODLへ

レガシーのlog4jロギング・メカニズムは、より頑強なOracle Diagnostic Loggingソリューションに置き換えられました。

- ログODLの構成ツールの使用

- Oracle Diagnostic Logging (ODL)プロパティ・ファイル

XMLPostのコマンドライン・サポート

XMLPostユーティリティは、.iniファイルからの読取りに代えて、コマンドラインで、引数としてユーザー資格証明を受け入れるようになりました。

コマンドラインからのXMLPostの実行

構成インポート/エクスポート・ユーティリティ

WebCenter Sitesに、構成インポート/エクスポート・ユーティリティが付属するようになりました。これを使用すると、WebCenter SitesとSatellite Serverのwcs_properties.jsonファイルにあるプロパティ値を一括エクスポートおよび一括インポートできます。

インポート・エクスポート・ユーティリティの使用

RTL (Right-to-Left)方向

現在、Contributorインタフェースは、アラビア語などのRTL (Right-to-Left)ベースの言語用としてRTL方向をサポートしています。

ユーザー・インタフェースのRight-to-Left (RTL)方向への設定

新しいプロパティ管理ツール/プロパティはJSON形式に移行

WebCenter Sitesとそのコンポーネント・アプリケーションの動作を左右するプロパティはJSON形式で格納され、Adminインタフェースで、新しいプロパティ管理ツールを使用して管理されるようになりました。

- プロパティ管理ツールの使用

- JSONファイルのプロパティの管理

Test-to-Productionのサポート

WebCenter Sitesは、標準Oracle Fusion Middlewareのtest-to-productionスイッチオーバー・プロセスをサポートするようになりました。

テスト・モードから本番モードへの切替え

IPv6のサポート

WebCenter Sitesとそのコンポーネント・アプリケーションは、IPv6プロトコル(IPv6/IPv4のハイブリッド運用を含む)をサポートするようになりました。

Oracle WebCenter Sitesのインストールと構成

次の機能は、このリリースでは非推奨になりました。

- WebCenter Sites GadgetsおよびGadget Server

- Community/GadgetsでのWebCenter Sitesのネイティブ認証

- WebCenter Sites Analytics 2.5

- WebCenter Sites Content Integration Platform - EMC Documentum

- WebCenter Sites Content Integration Platform Filesystem

- WebCenter Sites Content Integration Platform Sharepoint

- WebCenter Sites Janrain Integration

- WebCenter Sites Netomat Mobility Server

- SOAPベースのWebサービス

- ページ・デバッガ

注意:
JSPデバッグ機能のIDE統合を使用してください。DebugServletはデプロイされません。

- サイト・デスクトップ

- サイトDocLink

第I部 Oracle WebCenter Sitesの管理の理解

次の各トピックでは、作成から配信まで、Webサイトの管理のすべての側面について説明します。これらのトピックでは、ユーザー・ロール、アセットおよびパブリッシュされたコンテンツの作成と保守など、Webサイトの保守について、概要を説明します。

- Oracle WebCenter Sitesの概要

- コンテンツ管理の概念について

- ログインと開始

- WebCenter Sitesの管理のロードマップ

1 Oracle WebCenter Sitesの概要

Oracle WebCenter Sitesの管理者には、一般管理者、サイト管理者およびワークフロー管理者の3種類があります。次の各トピックでは、Oracle WebCenter Sitesの概要を説明します。これは前述のタイプの管理者にも当てはまります。

- Oracle WebCenter Sitesについて

- WebCenter Sites管理者とは

- 管理者の前提条件

- 管理者が実行するWebサイト管理タスク

- このガイドで使用するサンプル・サイト

1.1 Oracle WebCenter Sitesについて

Oracle WebCenter Sitesは、ユーザーがデスクトップでモバイルWebサイトを作成、管理できるようにするWebエクスペリエンス管理(WEM)システムです。管理者は、コンテンツ管理サイトの作成、サイトへのユーザーの割当て、サイトのOracle WebCenter Sites: Contributorインタフェースの有効化、およびインタフェースの範囲内のコンテンツ管理機能へのユーザー・アクセスの管理を行います。また、ワークフロー、リビジョン追跡、パブリッシュおよびマーケティングの管理も行います。

Oracle WebCenter Sitesには、管理者向けに、AdminインタフェースおよびWEM Adminインタフェースが用意されており、連携して、コンテンツ管理サイトのすべての側面を管理するために必要なツールを提供します。また、Oracle WebCenter Sites: A/B Testingや変換といった機能を有効化して、コンテンツ・コントリビュータやマーケティング担当者がWebサイトを強化するために成功度を測定する助けにできるようにできます。

1.2 WebCenter Sites管理者とは

Oracle WebCenter Sitesでは、3種類の管理者を定義しています。

- 一般管理者。WebCenter Sites環境内のすべてのシステムを管理し、各システムのインタフェースに無制限でアクセスできます。各システムの一般管理者のジョブの概要は、コンテンツ管理の概念についてで説明します。

- サイト管理者。管理システムの特定のサイトのみを管理します。

- ワークフロー管理者。管理システムでワークフロー・プロセスを作成します。

各管理者には、WebCenter Sites管理者およびWEM Adminインタフェースの、関連する部分の権限が与えられます。

このガイドの概念のいくつかは特定のタイプの管理者に固有ですが、一般管理者はすべての概念を把握している必要があります。

つまり、このガイドはWebCenter Sitesの環境の特定のシステムに制限されるものではありません。ここに含まれる概念および手順は、WebCenter Sites環境内のすべてのシステムで有効です。

1.3 管理者の前提条件

WebCenter Sites管理者として働くには、ある程度の情報を持っている必要があります。次のリストに、把握しておく、また精通しておく必要のある情報をまとめます。

- Oracle WebCenter Sitesの管理インタフェースおよびシステムのデフォルト
WebCenter Sites Adminインタフェースにはサイト構成ツールがあり、ACL、ロールおよびアセット・タイプなどのシステム・デフォルトにアクセスできます。Adminインタフェースの詳細は、Adminインタフェースの使用を参照してください。システム・デフォルトの詳細は、システム・デフォルトおよびWebCenter Sitesのデータベース表を参照してください。

- Oracle WebCenter Sites WEM Adminインタフェース
WebCenter Sites WEM Adminインタフェースには、サイト、ユーザー、ロールおよびアプリケーションの作成と管理を可能にするサイト構成ツールが用意されています。WEM管理者の詳細は、Webエクスペリエンス管理フレームワークの使用を参照してください。

- コンテンツ管理の技術面
プログラミングやシステム・アーキテクチャの特殊な技術的知識は必要ありませんが、基本的な次の知識があることが望まれます。

- Java

- JSP

- パブリッシュ

- データベースとデータベースの管理

- ブラウザ

- コラボレータ
詳細は、コンテンツ管理チームとのコラボレーションおよび『Oracle WebCenter Sitesでの開発』を参照してください。

- オンライン・サイトの仕様
オンライン・サイトの仕様は、一般的にサイト・デザイナまたは企業通信部門により準備され、サイトの対象読者、サイトのサイズ、そのメッセージと目的、コンテンツの性質およびプレゼンテーション・スタイルを定義します。オンライン・サイトについて理解すると、オンライン・サイトのモデル化、サイトの計画および開発者との効果的なコラボレーションに役立ちます。

- Oracle WebCenter Sites環境
Oracle WebCenter Sites管理者は、開発、管理、配信およびテストの最大4種類のシステムを使用する可能性があります。システムと、各システムでの管理者の役割をよく理解しておいてください。詳細は、Oracle WebCenter Sites環境、WebCenter Sitesの管理のロードマップおよび『Oracle WebCenter Sitesでの開発』を参照してください。

1.4 管理者が実行するWebサイト管理タスク

WebCenter Sites管理者は、パブリッシュ・システムの構成、ユーザーの設定、ユーザーのセキュリティ・ロールの作成と保守を行います。

管理者は、ユーザーと基本エレメント(アセットおよびアセット・タイプ)を定義して、Webサイトの基盤を作成します。Webサイトが維持されているかぎり、管理者は継続してユーザーおよびロールを保守し、また、ワークフロー、ブログおよびWebサイト更新の定期パブリッシュを設定および保守します。

WebCenter Sitesでは、管理者の責務は、インストールによって異なります。一般的に、管理者は次のタスクを実行します。

- コンテンツ管理チームとのコラボレーション

- ユーザーの管理

- アクセス制御リスト(ACL)とロールの管理

- アセット・タイプとアセットの管理

- アプリケーションへのユーザー・アクセスの管理

- ワークフローの管理

- パブリッシュ・システムの管理

- WebCenter Sitesとそのコンポーネントのパフォーマンスの管理

- WebCenter ContentのWebCenter Sitesとの統合

1.4.1 コンテンツ管理チームとのコラボレーション

開発を開始する前に、管理者は一般に、たとえば次のような様々な多くの専門家で構成されるチームとコラボレートします。

- サイト・デザイナ

- XMLおよびJSP開発者

- Javaアプリケーション開発者

- データベース管理者

- システム・ネットワーク管理者

- マーケティング担当者

- ビジネス・マネージャ

- 製品マネージャ(商用サイトを開発している場合)

- コンテンツ・プロバイダ

チームのジョブは、ページ設計、キャッシュ戦略、セキュリティ戦略、データ・モデル、ページのレイアウトとコンテンツおよびコンテンツ管理モデルといった、管理および配信システムの機能要件と設計仕様の確立です。

1.4.2 ユーザーの管理

WebCenter Sites管理者は、ユーザーの作成と、適切なコンテンツ管理サイトおよびインタフェース機能へのユーザー・アクセスの有効化を行います。管理者は、各ユーザーについてユーザー・アカウント、ユーザー・プロファイル、ユーザー属性、ロールおよびアクセス制御リスト(ACL)を定義する必要があります。

ユーザー・アカウントは、ユーザーにWebCenter Sitesシステムとそのデータベース表へのアクセスを付与します。ユーザー・プロファイルは、WebCenter Sitesアプリケーション、言語パックおよびワークフロー・プロセスを使用するユーザーが必要とします。ユーザー属性は、ワークフローの枠外でアクションおよびイベントが必要とされるケースで使用されます。ロールは、ユーザーをサイトに関連付けるために使用され、それによりそのユーザーはサイトへのログインが可能になります。ユーザーに割り当てられたロールがアプリケーションに割り当てられたロールに一致した場合、ユーザーは、そのロールに関連付けられたインタフェース機能へのアクセスを獲得します。ACLは、WebCenter Sitesデータベース表へのアクセスを管理するために使用されます。

ユーザーを作成する場合、ロールを使用してそのユーザーをコンテンツ管理サイトおよび関連アプリケーション(ユーザー・インタフェース)に関連付ける必要があります。これにより、ユーザーがサイトにログインして、適切なインタフェースおよびそのサイトに関連付けられたインタフェース機能にアクセスできるようになります。

ユーザーの管理に関する詳細は、ユーザー、プロファイルおよび属性の構成を参照してください。

1.4.3 アクセス制御リスト(ACL)とロールの管理

ユーザーの管理で説明したとおり、WebCenter Sites管理者は、ユーザーにアクセス制御リスト(ACL)およびロールを割り当てて、コンテンツ管理サイトへのアクセスや、WebCenter Sitesインタフェース(管理者、コミュニティおよびContributor)内のコンテンツ管理機能を実行できるようにします。WebCenter Sitesは、ACLとロールの両方を使用して、企業のWebサイトを作成するために必要な部分(記事の作成からページ・レイアウトの開発まで)で作業する、業務説明に明確に定義されている様々なユーザーをサポートします。

ACLは、インタフェース機能を表し、ユーザー定義(ユーザーのアカウント)で定義されるデータベース表へのユーザー・アクセスを制御します。ACLは、許可機能を提供することによって、Sitesシステムにおけるセキュリティおよびユーザー管理モデルの基盤として機能します。作成されたサイト数に関係なく、各WebCenter Sitesユーザーには1つのユーザー定義(アカウント)があります。ただし、ユーザーのロールはサイトごとに異なる場合があります。ロールは、データベース表によって表されるインタフェース機能へのユーザー・アクセスを制御します。業務の説明、または類似機能へのアクセスを付与された個々の役職(たとえば、コンテンツ・コントリビュータ、エディタ、デザイナなど)を表します。管理者は、インタフェース機能を試みるユーザーに、それに関連付けられているデータベース表と同じACLが割り当てられていることを確認する必要があります。

ACLトロールの管理の詳細は、ACLおよびロールの使用を参照してください。

1.4.4 アセット・タイプとアセットの管理

ユーザーをサイトに割り当てたら、続いて、それらのユーザーが使用するアセット・タイプ(コンテンツ・タイプ)を有効化する必要があります。開発者は、システムで使用できるアセット・タイプを作成します。適切なサイト上でアセット・タイプを有効化してください。サイト上でアセット・タイプを有効化する場合、アセット・タイプは、ユーザーの割り当てられたロールが付与するインタフェース機能(たとえばContributorインタフェースのメニュー・バー)を介してサイト・ユーザーから使用可能になります。

WebCenter Sitesは、アセット・タイプの有効化とロールの使用によりインタフェース機能にユーザー権限を付与するだけでなく、権限をアセットごとに設定するのを可能にする、アクセス権限と呼ばれる追加のセキュリティ・レベルを提供します。アクセス権限を使用すると、アセットに対してどのロールがどの機能を実行する権限を持つかを定義できます。たとえば、アセットに対してどのロールがコピー機能を実行でき、どのロールに対してアセットをコピーする能力を拒否するかを指定できます。

サイト上でのアセット・タイプの有効化の詳細は、アセット・タイプの有効化と管理を参照してください。アセットへのユーザー権限の設定と、アセットに対するユーザー権限の管理の詳細は、コンテンツ管理サイト・コンポーネントへのアクセスの管理を参照してください。

1.4.5 アプリケーションへのユーザー・アクセスの管理

サイトおよびユーザーを作成し、ユーザーがそれらのサイト上で使用できるようにアセット・タイプを有効化したら、WebCenter Sitesユーザーを割り当てたサイトでアクセスできるインタフェース(Contributorなど)やその他のアプリケーションを有効化する必要があります。このタスクには、WEM Adminインタフェースを使用します。WEM Adminインタフェースは、アプリケーションへのアクセスを制御するためにサイトおよびロールの用途を拡張します。ロールはアプリケーション内で使用されてインタフェース機能を保護し、アプリケーション・コンテンツへのアクセスを制限します。WEM Adminインタフェースから、ロールを使用して、サイトにアプリケーションおよびユーザーを割り当てます。ユーザーおよびアプリケーションが同じロールを割り当てられた場合、そのサイトのアプリケーションへのアクセスがユーザーに付与されます。

WEM Adminインタフェースを使用してサイトおよびアプリケーションへのアクセスを管理する場合の詳細は、Webエクスペリエンス管理フレームワークの使用を参照してください。

1.4.6 ワークフローの管理

ワークフロー・プロセスを作成する場合、コンテンツ管理サイトのその作成ポイントから配信システム上のパブリッシュの宛先にアセットを移動するのに含まれるタスクを決定します。ワークフロー・プロセスに含める各タスクには、ユーザーがそれを完了するために必要なロールまたはロールのグループを割り当てる必要があります。個々のアセットがワークフロー・プロセスを通過していく際に、適切なロールを持つユーザーのみがそのタスクの実行を許可されます。これらのタスクをワークフロー状態と呼びます。状態とはその時点でのアセットのステータスを表すワークフロー・プロセス内のポイントで、たとえば、記事の執筆、イメージのレビュー、法的レビューなどです。状態間のアセットの移動はステップと呼ばれます。

ワークフローの管理の詳細は、ワークフロー・プロセスの作成と管理を参照してください。

1.4.7 パブリッシュ・システムの管理

WebCenter Sites管理者としての主要な目標の1つは、サイト・コンテンツ(管理システム上に作成)を、Webサイトの訪問者から(配信システム上で)アクセスできるようにすることです。これを実現するために、WebCenter Sites Adminインタフェースには、パブリッシュ・システムを構成、監視できる、様々なパブリッシュ機能があります。

注意:

コンテンツ・コントリビュータにパブリッシャ・ロールを割り当てる場合、そのユーザーは、Contributorインタフェースから直接、個々のアセットをパブリッシュできます。詳細は、『Oracle WebCenter Sitesの使用』を参照してください。

管理者は、システムに対してパブリッシュの宛先を構成し、パブリッシュ・イベントをスケジュールします。さらに、WebCenter Sitesには承認システムがあり、Webサイトへのコンテンツのパブリッシュを承認するために使用されます。ユーザーがコンテンツのパブリッシュを承認すると、そのコンテンツは次のパブリッシュ・イベントで使用できるようになります。パブリッシュ・イベントが実行されると、管理システム上のすべての承認されたコンテンツがWebサイト上で使用可能になります。

デフォルトで、WebCenter Sitesは、Webサイトにコンテンツをパブリッシュする動的なメソッドであるリアルタイム・パブリッシュ・メソッドをサポートします。動的パブリッシュは、WebCenter Sitesシステム間で、アセットおよびそれらの基礎となるスキーマをコピーするプロセスです。RealTimeパブリッシュの構成の詳細は、リアルタイム・パブリッシュの使用を参照してください。

1.4.8 WebCenter Sitesとそのコンポーネントのパフォーマンスの管理

WebCenter Sites管理者は、Enterprise ManagerでWebCenter Sitesのログ・ファイルを構成して、構成、デバッグおよびトレース・メッセージのロギングを有効化します。管理者は、Enterprise ManagerでVisitor Servicesを開始および停止し、これらのコンポーネントのステータスを確認し、パフォーマンス・メトリックを監視します。

ログ・ファイルの構成と表示、Visitor Servicesの開始と停止、およびこれらのコンポーネントのパフォーマンスの監視の詳細は、Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理を参照してください。

1.4.9 WebCenter ContentのWebCenter Sitesとの統合

WebCenter ContentとWebCenter Sitesの間のコンテンツ統合を有効化する場合、SitesIntegrationコンポーネントおよびConnectorAdminツリー・ノードを先に有効化する必要があります。完了すると、続いてWebCenter ContentとWebCenter Sitesとのコンテンツ同期を設定できます。これにより、WebCenter SitesにあるWebCenter Contentのコンテンツ・アイテムを同期できるようになり、その後それらはコンテンツ・コントリビュータによってWebCenter Sitesのネイティブ・アセットとして管理されます。このアセットは、WebCenter Sitesで直接作成された他のアセットと同様に編集、削除、プレビュー、リビジョン追跡、およびパブリッシュできます。

WebCenter Content統合の詳細は、Oracle WebCenter Contentとの統合を参照してください。

1.5 このガイドで使用するサンプル・サイト

このガイドの手順説明では、avisportsとFirstSite IIというサンプル・サイトを使用して、WebCenter SitesのContributor、Admin、WEM AdminおよびCommunityインタフェースのコンテンツ管理機能を使用する方法を詳しく示しています。これらのサンプル・サイトにアクセスできるのは、JSKを使用しているか、これらのサンプル・サイトがWebCenter Sitesシステムとともにインストールされている場合のみです。サンプル・サイトがインストールされていない場合は、WebCenter Sites管理者に問い合せてください。

このガイドで使用するサンプル・サイトは、次のとおりです。

- avisports: スポーツを中心とするサンプル・サイトで、イメージを添えたスポーツ記事が掲載されています。このガイドでは、avisportsは、アセットの作成や編集、アセットのリンク、アセットのパブリッシュの承認、アセットの検索と整理、リビジョン追跡を使用したアセットの追跡およびサイトのナビゲーションの作成など、Contributorインタフェースでの機能を示します。

- FirstSite II:: 電子機器のオンライン小売サイトで、記事、イメージ、いくつかの製品エントリが記載された製品カタログ、ドキュメント、サンプル・ユーザー・アカウントなどが含まれます。このガイドでは、FirstSite IIは、Contributorインタフェースのワークフロー、多言語およびプレビューの各機能を説明しています。また、FirstSite IIは、Oracle WebCenter Sites: Engageの説明と、Contributorインタフェースにおけるセグメント、推奨およびプロモーションの作成手順と操作手順の説明にも使用されます。

2 コンテンツ管理の概念について

一般管理者は、サイトの構成とレプリケート、日々の使用の管理など、業務全体にわたってコンテンツ管理(CM)サイトを使用します。これらは業務の重要な部分であるため、CMサイトとは何か、およびオンライン・サイトとどのように関連するのかを理解する必要があります。

次の各トピックでは、コンテンツ管理の概念に関する概要情報を提供します。

- Oracle WebCenter Sitesの概念の概要

- Webサイト

- コンテンツ管理サイト

- 構成コンポーネント

- コンテンツ管理モデル

- Oracle WebCenter Sites環境

2.1 Oracle WebCenter Sitesの概念の概要

Oracle WebCenter Sites管理者の業務は、Webサイトの基盤(特にバックエンド)の構築です。バックエンド自体は、Oracle WebCenter Sitesのインストール先にあるサイト(またはサイト群)で、そこでビジネス・ユーザーが作業して電子アセットを作成、管理して、利用者に対してデプロイします。バックエンドの構築には、ビジネス・ユーザーを構成して、コンテンツ・エントリ・フォームやその他のオーサリング・ツールにリンクし、オンライン・サイトのサービスをブラウザに表示するためのパブリッシュ・システムと配信システムをユーザーに提供することが含まれます。

バックエンドが構成されると、ユーザーはOracle WebCenter Sitesにログインし、コンテンツを作成および管理できます。入力したコンテンツは、Oracle WebCenter Sitesデータベース内の表に保存されます。配信の準備が整うと、コンテンツがデータベース表から取得され、書式設定されて、Webサイトとしてブラウザに表示されます。

Oracle WebCenter Sitesは、CMサイト、バックエンドとして機能できる最小単位として定義されます。CMサイトでは、WebCenter Sitesユーザーがデータベースに保存されるコンテンツを作成し、パブリッシュ-配信システムを起動します。WebCenter Sitesでは、オンライン・サイトのバックエンドに構成できるCMサイトの数またはサイトを構成する方法の数に制限はありません。

WebCenter Sites管理者は、CMサイトの構成とレプリケート、および日々の使用の管理など、業務全体でCMサイトを使用します。これらは業務における重要な部分であるため、CMサイトの定義方法、これらの構成方法、およびWebサイトとどのように関連するのかを理解する必要があります。

2.2 Webサイト

ほとんどのインターネット・ユーザーは、「Webサイト」の定義を必要としませんが、Oracle WebCenter Sitesによって支えられているオンライン・サイトがどのようなものであるかを説明することは重要です。コンテンツ管理サイトでは、オンライン・サイトがCMサイトによってどのようにモデル化されるかを説明します。

WebCenter Sitesによって支えられているオンライン・サイトは、WebCenter Sitesを介して組織がターゲット読者である顧客、クライアントおよび一時的な訪問者に表示するページのセットです。オンライン・サイトは、だれでもアクセスできるようにすることも、パスワードで保護されたサイトにすることもできます。プライベート・ドメイン内で厳密に運用し、企業ネットワークや部門内ネットワークなどのように完全に排他的なサイトにすることもできます。

その性質に関係なく、オンライン・サイトは、選択するモデルに応じて、単一のCMサイトまたは多数のCMサイトに由来します。すべての製品ガイドで使用されているオンライン・サイトという用語は、総称的にWebサイトを指します。

2.3 コンテンツ管理サイト

CMサイトは、Oracle WebCenter Sites内のコンテンツ管理単位です。これは、オンライン・サイトのコンテンツのソースで、オンライン・サイト全体を表すことも、そのセクションのいずれかを表すこともできます。

注意:

今後、サイトという用語が修飾語句なしで使用される場合、これはCMサイトを意味します。

サイトは、まずオンライン・サイトの作成者および管理者を定義し、次に両者に権限と必要なコンテンツ管理ツール(コンテンツ・エントリ・フォーム、コンテンツ・レンダリング・テンプレート、ワークフロー・プロセス、スタート・メニュー・アイテム、パブリッシュ方法および配信システム)を提供するために構成する必要があるオブジェクトです。サイトの構成プロセスには、サイト・コンポーネントの作成のみでなく、コンポーネント同士のアソシエーションも含まれます。アソシエーションを作成することによって、図2-1 に示すようなサイトが定義されます。

図2-1 ユーザー・ロールとACL

サイトは名前(これも管理者によって構成されます)で識別され、WebCenter Sitesのデータベースに格納され、権限のあるユーザーのインタフェースにリストされます。適切なロールを持つユーザーは、サイトにアクセスできます。サイト内で、ロールはOracle WebCenter Sitesインタフェースの特定の機能(スタート・メニュー・アイテムなど)に対するユーザーのアクセスを管理します。ACLはコンテンツ(データベース表)に対するユーザーの権限を管理します。(ロールによってアクセス可能となった)インタフェース機能を介して、ユーザーは(ACLで定義された)権限を作動させることができ、特定のタイプのコンテンツを作成および管理するためのデータベース表での処理が可能です。

一般に、Oracle WebCenter Sitesシステムには、それぞれが機能および構成において固有の数多くのサイトがあります。ユーザーは、WebCenter Sitesにログインする際に、作業するサイトを選択することも必要です。サイトは他のサイトから独立していることもあれば、共通のユーザー・セットがある場合には他のサイトとアセットを共有することもあります。

注意:

このリリースで、WebCenter Sitesは、サイト作成プロセスを高速化する、サイト・ランチャと呼ばれるサイト・レプリケーション・ユーティリティを提供します。サイトを最初から作成するのではなく、必要に応じて構築済のサイトをレプリケートし、そのレプリケートを修正して、WebCenter Sites環境内で新しいサイトとしてスピンオフさせることができます。

サイトのコンポーネントがサイト固有なのではなく、これらのコンポーネントのアソシエーションがサイト固有であることを理解することが重要です。

サイト・コンポーネントは、システム規模のプールに存在するか、作成する必要のある構成です。このプールから、サイトを作成するために相互にやり取りする必要のあるコンポーネントを選択し、これらのコンポーネントを互いに関連付け、サイト名を割り当てます。コンポーネントはシステム全体であるため、再利用が可能です。つまり、あるサイトの形成に使用されるコンポーネントを別のサイトの形成に使用できます。

コンテンツ・プロバイダには、サイト・コンポーネントはサイト固有に見えることに注意してください。ただし、サイト上でコンテンツ・プロバイダが作成するアセットは、確かにそのサイトに固有です。アセットは他のサイトにコピーしたり、他のサイトと共有できます。

サイト・コンポーネントの共有およびコピーのオプションは、オンライン・サイトのモデリングおよびレプリケーションにおいて重要な役割を果します。これについては、コンテンツ管理モデルで説明します。

2.4 構成コンポーネント

サイトの構成では、Oracle WebCenter Sites Adminインタフェースを使用して、システム全体の構成プールにアクセスし、サイトを構成するコンポーネントを選択(または作成)して、コンポーネント同士を関連付け、それらが一緒に機能してWebサイトまたはそのいずれかのセクションを生成できるようにします。

表2-1に、サイト・コンポーネントをリストします。そのほとんどが必須です。オプションのコンポーネントは、ビジネス・ニーズやユーザーの好みによって異なります。開発者がコードベースのコンポーネントを担当し、管理者がその他すべてのコンポーネントを担当します。

サイト・コンポーネントは一般に複雑な構造で、特にデータ・モデルは複雑です。これについては、後続の項で説明します。データ・モデリングの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

表2-1 サイト・コンポーネント

コンポーネント

必須

作成者

参照先

CMサイト定義

はい

WebCenter Sites管理者

コンテンツ管理サイト定義

データ・モデル

はい

開発者

データ・モデル

ユーザー

はい

WebCenter Sites

ユーザーとその表レベルの権限

ロール

はい

WebCenter Sites管理者

ユーザーおよびロール

スタート・メニュー・アイテム

はい

WebCenter Sites

スタート・メニュー

ワークフロー・プロセス

いいえ

WebCenter Sites管理者

ワークフロー・プロセス

パブリッシュ・システム

はい

WebCenter Sites

パブリッシュ・システム

ユーザー・インタフェース・オプション

いいえ

WebCenter Sites

ユーザー・インタフェース・オプション

2.4.1 コンテンツ管理サイト定義

CMサイト定義は、CMサイトのコンポーネントです。これは、サイト名とオプションの説明で構成され、どちらも管理者によって指定されます。サイト名は、オンライン・サイト、ビジネス・トピック、部門の業務またはその他のタイプのコンテンツを表すことができます。いずれの場合でも、サイト名によって、サイト内のユーザーが開発および保守を担当するビジネス・テーマが設定されます。

サイト名を指定すると、WebCenter Sitesは、Adminインタフェース内のサイトを表すノードを作成します。さらに、サイトにコンポーネントをリンクするため、デフォルト・サブ・ノードを追加します。アセット・タイプ・サブ・ノードはサイトへのデータ・モデルのリンク用、ユーザー・サブ・ノードはサイトへのユーザーのリンク用です。

コンテンツ・プロバイダにとって、サイトは表示制御メカニズムです。サイトによって、権限のあるユーザーは、WebCenter Sitesインストール内の特定のコンテンツにアクセスできます。サイトが適切に構成されている場合、その名前はコンテンツ・プロバイダのインタフェースに表示され、コンテンツ・プロバイダはそのサイトを選択し、ロールおよび権限に従ってサイト内を移動できます。

2.4.2 データ・モデル

データ・モデルはサイトのコンポーネントです。これは、アセット・タイプ(データベース表)と、コンテンツ・プロバイダが使用するため開発者によりコード化されたアセット・タイプ定義のセットで構成されます。開発者がコンテンツ・プロバイダに可能なかぎり幅広いコンテンツ管理オプションを備えられるように、WebCenter Sitesでは3種類のアセット・タイプをサポートしています。

- コンテンツ・アセット・タイプ: コンテンツ用にデザインごとに構造化されたリポジトリで、サイト定義で設定されたビジネス・テーマを反映しています。たとえば、「社会的な出来事」というサイトを定義した場合、適したコンテンツ・アセット・タイプは、サイト名が意味するテーマにふさわしいものであるため、「厳選された歴史上の瞬間」、「20世紀最大の出来事」などになります。
開発者は、アセット・タイプからアセット・タイプ定義をコード化します。これらはコンテンツ・エントリ・フォームとしてWebCenter Sitesインタフェースで表示され、そのフィールドで、オンライン・サイトに配信する情報(または、必要に応じて内部で使用するために保存する情報)を入力するようにユーザーに要求します。フィールドのセットはアセット・タイプを定義し、ユーザーのフィールド・エントリはアセット(アセット・タイプのインスタンス)を定義します。

- デザイン・アセット・タイプ: テンプレート・アセットをコード化するために開発者によって使用され、コンテンツ・アセットをレンダリングします。(プレゼンテーション・コードをコンテンツと区別するため、テンプレート・アセットはコンテンツ・アセットと区別します。)

- 管理アセット・タイプ: コンテンツ・プロバイダがそのコンテンツを管理するために役立つ簡単な検索やデータベース問合せなどのツールを作成するため、開発者によって使用されます。

通常、開発者は作成したアセット・タイプをテストしてから管理者に渡し、管理者が(アセット・タイプ・ノードから)これらをサイト定義にリンクして、サイト構成プロセスの別の手順を実行できるようにします。

注意:

Oracle WebCenter Sitesは多くのデフォルト・アセット・タイプを提供し、開発者が独自のアセット・タイプを作成できるようにします。アセット・タイプ、その定義およびアセット自体は、WebCenter Sitesデータベースに表または表エントリとして格納され、このガイドでは大まかにコンテンツと呼ばれます。

データ・モデリングの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。管理者はこのガイドを読んで、アセット・タイプの基本を理解することをお薦めします。

2.4.3 ユーザーとその表レベルの権限

ユーザーはサイト・コンポーネントです。このガイドでは、しばしばコンテンツ・プロバイダと呼ばれ、開発者のデータ・モデルを使用してコンテンツを作成および管理します。

コンテンツ・プロバイダは対象分野の専門家です。次のような場合があります。

- オンライン・コンテンツの作成者。コピーライターやデザイナがこのグループに入ります。

- レビューア。他のユーザーが送信してきたコンテンツを確認して編集し、その品質を保証します。コンテンツ・レビューアには、送られてきたコピーやデザインをレビューおよび修正するアート・ディレクタやエディタなどが含まれます。

- コンテンツ・パブリッシャ。コンテンツがオンライン・サイトに配信される準備が整っていることを確認し、コンテンツの配信を承認します。チーフ・エディタがコンテンツ・パブリッシャとなる場合もあります。これらのユーザーは、Contributorインタフェースからアセットを、オンデマンドでパブリッシュする権限を持っていることがあります。

- コンテンツ・マネージャ。作成、レビューおよびパブリッシュ・プロセスを監督します。

各コンテンツ・プロバイダは、ユーザー・アカウントによりWebCenter Sitesに識別される必要があります。ユーザー・アカウントは、ユーザー名、パスワードおよびOracle WebCenter Sitesのセキュリティ・システムの基盤であるアクセス制御リスト(ACL)で構成されます。

ACLはデータベース表に対する権限のセットです。同じACLが表とユーザーの両方に割り当てられると、権限(読取り、書込みなど)が付与されます。ACLが表とユーザーで共通ではない場合、表に対する権限はユーザーに付与されません。

たとえば、SystemUsersというシステム表には、ユーザー・アカウント情報が含まれています。表には、SiteGod、UserReaderおよびUserEditorの3つのACLが割り当てられています。ユーザーにACL (この例ではUserReader)が割り当てられていると、ユーザーは表を読み取ることができます。同じユーザーに2つ目のACL、UserEditorが割り当てられていると、そのユーザーは表を編集することもできます。ユーザーにどのACLも割り当てられていない場合、そのユーザーに表に対する権限は付与されません。

ACLはユーザーに表を操作する権限を与えますが、ユーザーに表を操作する手段を与えるわけではないことに注意してください。たとえば、前のシナリオで、ユーザーの表の読取りおよび編集の権限は、Oracle WebCenter Sitesインタフェースの表示および編集の機能を使用する権限に変換されます。ただし、同じロールがユーザーと機能の両方に割り当てられていなければ、その機能はユーザーに表示されません。ロールの詳細は、ユーザーとロールを参照してください。

図2-2 ユーザーACL

一般に、WebCenter Sitesは次の2つのレベルでACLを使用します。

- システム・セキュリティ・レベル: 認証機能を提供し、ハッカーがWebCenter Sites環境に入れないようにします。

- インタフェース・レベル: データベース表に対するユーザー権限を制御し、権限を作動させるインタフェース機能を(表示ではなく)使用できるかどうかを制御します。

WebCenter Sitesは多くのデフォルトのシステムACLを用意しており、これらを事前にシステム表に割り当てます。必要に応じて、ACLを再利用することも、独自に構成してカスタム表に割り当てることもできます。ACLの詳細は、ACLおよびロールの使用とシステム・デフォルトを参照してください。

2.4.4 ユーザーおよびロール

ACLがユーザーにデータベース表での操作権限を与える一方で、ロールはユーザーにデータベース表での操作手段を提供します。ロールは、ユーザーがサイトへのアクセス権を持つかどうか、および「編集」、「削除」、「ワークフローの開始」などのインタフェース機能をユーザーのインタフェースに表示するかどうかを決定します。これらの機能が表示されない場合、(ACLで指定された)データベース表に対するユーザーの権限を作動させることはできず、ユーザーは表での操作ができないままです。ロールは、作成者や編集者などのユーザー・グループも定義します。これらは、サイト、サイトのコンテンツ、付随アイテム(コンテンツを作成および検索するためのスタート・メニューなど)およびワークフロー・プロセスに対するグループの権限(したがってユーザーの権限)を記述するために使用されます。

ロールはACLと同様に実装されます。つまり、ユーザーのインタフェースに機能が表示されるようにするには、機能とユーザーに同じロールを割り当てる必要があります。説明のため、前のシナリオをもう一度使用します。ここでユーザーは、UserReaderおよびUserEditorのACLにより、SystemUser表への編集権限を与えられています。これらの権限を実行するには、ユーザーはOracle WebCenter Sitesインタフェースの「編集」機能へのアクセス権が必要です。「編集」は、「一般的な管理」ツリーの、「管理」ノードの下にあります。ただし、「Admin」ノードを表示するには、ユーザーにそのタブと同じロールが割り当てられている必要があります。デフォルトでは、このタブにはGeneralAdminロールが割り当てられています。同じロールをユーザーにも割り当てる必要があります。

図2-3 ユーザー・ロール

要約すると、ユーザーは、表のACLと「Admin」ノードのロールの両方が割り当てられている場合にのみ、データベース表へのフル・アクセス権を取得します。実際には、このシナリオのように、ロールとACLが互換的に割り当てられる必要があります。ロールの割当ては、ACL割当てにより付与される権限をサポートする必要があります。

図2-4 ユーザー・ロールとACL

サイト・ユーザーへのインタフェース機能の表示のほかに、ロールは、サイトでの役割に応じてユーザーをグループ化する方法を提供します。類似した役割を持つユーザーには、同じロールを割り当てることができます。たとえば、管理ユーザーは、「管理」ノードへのアクセス権を持っている必要があります。すべての管理者にGeneralAdminロールを割り当てて、「管理」タブへのアクセス権を付与することができます。

WebCenter Sitesはいくつかのデフォルトのシステム・ロールを定義し、これらはすべて、Oracle WebCenter Sitesインタフェース内の様々な機能に事前に割り当てられます。WebCenter Sitesでは、独自のロールを構成し、割り当てることもできます。ロール名を選択する際は、サイトにおけるユーザーの役割を考慮し、それに従ってロール名を選択します。(データベース表にマップされている) ACLと異なり、ロールはサイトおよびサイト上の機能にマップされる(つまり、ロールはユーザーごと、サイトごとに割り当てる必要がある)ことに注意してください。

注意:

ACLとは異なり、ロールは、別のコンテンツ・プロバイダをワークフロー・プロセスに参加させるため、コンテンツ・プロバイダに公開されます。

2.4.5 スタート・メニュー

スタート・メニューはサイト・コンポーネントです。メニュー上のアイテムは、サイトで使用するアセット・タイプをユーザーと結び付ける方法を提供します。この結合はロールによって行われます。

WebCenter Sitesは2つのスタート・メニューを定義します。「新規」は、サイト上でアセットを作成できます。「検索」は、サイト上でアセットを検索し、編集できます。

スタート・メニュー・アイテムは、次を指定します。

- スタート・メニュー・アイテムが適用されるサイト

- サイト上のユーザーが使用できるアセット・タイプ

- これらのタイプのアセットの作成または検索が可能なロール

- ロールが参加できるワークフロー・プロセス(ある場合)

つまり、スタート・メニュー・アイテムは、サイトで特定のタイプのアセットを作成および検索できるロールや、そのロールが参加できるワークフロー・プロセスを決定します。

WebCenter Sitesは自動的にスタート・メニュー・アイテムを作成しますが、管理者が独自に構成することも可能です。

2.4.6 ワークフロー・プロセス

ワークフロー・プロセスはオプションの構成で、ビジネス・ニーズがある場合のみ必要とされ、コンテンツ・プロバイダ間のコラボレーションを規制するために使用されます。

ワークフロー・プロセスは、権限のあるユーザーが専門知識を補完し合うようにして、コンテンツ・アセットの作成から始まる一連の処理を実行し、アセットのレビューを推進して、最終的にアセットの承認に至らせます。承認されると、アセットはユーザーにより配信システムにパブリッシュされ、コンテンツとしてオンライン・サイトに配信されます。

ワークフローが構成されると、これらを、新しく作成されたアセットが保存されたときに自動的に開始されるプロセスとして、スタート・メニュー・アイテムに指定できます。ワークフロー・プロセスは、スタート・メニュー・アイテムから外し、必要に応じてユーザーにより起動されるようにすることもできます。ワークフロー・プロセスの詳細は、ワークフロー・プロセスの作成と管理を参照してください。

2.4.7 パブリッシュ・システム

パブリッシュ・システムはサイト・コンポーネントです。パブリッシュ・システムは、ユーザーに、サイトおよびそのコンテンツをシステムから別のシステムに移行する手段を提供します。構成できるパブリッシュ方法には、リアルタイム、サーバーへのミラーリング、ディスクへのエクスポート、およびXMLへのエクスポートがあります。サイトの構造(つまり、データベース・スキーマ)は、サーバーへのミラーリングまたはリアルタイムのいずれかのパブリッシュ方法で移行されます。コンテンツ自体は、管理者の裁量でパブリッシュできます。

2.4.8 ユーザー・インタフェース・オプション

WebCenter Sitesは、ユーザーがコンテンツを操作できるオプションのインタフェースをサポートしています。

このオプションのインタフェースはOracle WebCenter Sites: ContributorインタフェースのWebモードで、レンダリングされたページでのコンテンツの直接編集をサポートします。Webモードが有効の場合、ユーザーは、パブリッシュ後にWebサイト上でコンテンツがどのように表示されるかを参照しながら、コンテンツを迅速に編集できます。

2.5 コンテンツ管理モデル

管理者として(単独で決定するか、コラボレータとともに決定するかによらず)最も大きな決定の1つが、Oracle WebCenter Sitesインタフェースでオンライン・サイトをモデル化する方法(単一のサイトとしてモデル化するか、サイトのセットとしてモデル化するか)です。どのコンテンツ管理モデルを選択するかは、オンライン・サイトのサイズとそのコンテンツの性質に大きく依存します。

次の各トピックではコンテンツ管理モデルについて説明します。コンテンツ管理モデルは次から選択できます。

- 1:1 モデル

- 1:nモデル

- x:nモデル

2.5.1 1:1モデル

1:1モデルは、オンライン・サイトを直接単一のCMサイトにマップします。CMサイトはオンライン・サイトの唯一のソースです。

図2-5 1:1モデル

1:1モデルは、コンテンツが限定的かつ均一で数人のユーザーによって管理される小さなオンライン・サイトで効果的に機能します。ただし、エンタープライズレベルのサイトの場合は、ページがしばしば数百万に達し、対象分野、コンテンツ、プレゼンテーションおよびスコープが大きく異なります。大きなサイトを編成するには、タスクの複雑さに対応できるモデルが必要となります。

2.5.2 1:nモデル

1:nモデルは、オンライン・サイトを複数のCMサイトにマップします。オンライン・サイトの各セクションは、論理セクションか物理セクションかに関係なく、そのソースとして特定のCMサイトにマップします。CMサイトは、互いに独立して機能させることも、コンポーネントおよびコンテンツを共有することにより互いに重複させることもできます。

図2-6 1:nモデル

たとえば、あるカタログ・サイトで、家庭用品に関するデータを入力するコンテンツ・コントリビュータは、園芸用品に関するデータを入力することはありません。したがって、家庭用品と園芸用品を表すには、2つの別個のサイトが使用されます。同様に、ライターが互いに独立して作業を行うパブリケーション・サイトでは、スポーツ・ライターはスポーツ・ニュース・セクションを表示するサイトを持ち、ファイナンシャル・ライターは金融関係のニュース・セクションを表示する別のサイトを持ちます。各デザインにおいて、2つのサイトが1つのオンライン・サイトに寄与します。

1:nモデルでは、各サイトが固有で、独自のコンテンツ・タイプ、テンプレート、コンテンツ・プロバイダ、ロール、ワークフロー・プロセスおよびパブリッシュ・メカニズムを持っています。各サイトは、対応するオンライン・セクションのコンテンツのソースです。

1:nモデルを使用する場合、管理者はサイトを互いに独立するように構成することも、コンポーネントやコンテンツを共有することで互いに重複するように構成することもできます。独立モデルは、特定のコンテンツを他のコンテンツから分離する必要がある場合に役立ちます。たとえば、コンテンツの機密性が高く、特定のコンテンツ・プロバイダのみが処理する必要がある場合や、コンテンツが異質であるため、別の専門家が処理する必要がある場合などがこれに当たります。

一方、サイトの重複は、関連の薄いコンテンツ・プロバイダ(異なる部署または事業部門など)間でのコラボレーションをサポートするために使用されます。

たとえば、次の使用例を考えてみます。成長しつつある登山専門のE-Businessでは、登山関連のニュースを発信し、写真アルバムを公開しています。用具一式の販売やFAQの回答も行っています。そのオンライン・サイトは、ニュース、写真、用具およびFAQの4つのセクションに明確に分割されています。しかし、多くの場合、ニュースと写真のセクションは写真のコンテンツを共有します。このシナリオでは、選択肢の1つとして、ニュース、写真、用具およびFAQの4つのサイトを、ニュースと写真がコンテンツを共有するように作成する方法があります。(別の選択肢として、ニュースと写真、用具、FAQの3つの独立したサイトを作成する方法もあります。)

2.5.3 x:nモデル

x:nモデルは、複数のオンライン・サイトを複数のCMサイトにマップします。3つのモデルの中では、このモデルが最も複雑ですが、エンタープライズレベルのE-Businessでは、最もメリットが大きくなります。

このモデルでは、コンテンツ・アセットは特定のサイトでローカライズされ、デザイン・アセットと管理アセットはそれらが共有されるその他すべてのサイトとは別のサイトで構成されます。このタイプのデザインでは、管理者がコンテンツをプレゼンテーションおよびビジネス・ロジックから分離できます。

注意:

管理者やその他のユーザーがサイトおよびそのオンライン・サイトとの関係を理解できるように、Oracle WebCenter Sitesでは、avisportsおよびFirstSiteIIという名前のサンプル・サイトを用意しています。各サンプル・サイトは、そのオンライン・サイトに1:1でマップしています。サンプル・サイトがインストールされている場合、Oracle WebCenter Sitesへのログインのログイン手順に従って、このサイトにログインできます。

図2-7 x:nモデル

2.6 Oracle WebCenter Sites環境

サイト構成は、分離されたWebCenter Sitesシステムではなく、WebCenter Sites環境で行われる協調的なプロセスです。エンタープライズレベルの環境は通常、図2-8に示すように、WebCenter Sitesによって支えられている、開発、管理、配信およびテストの4種類のシステムで構成されています。各システムは、独自のデータベースで実行され、ある点において別のシステムとやり取りをします。システムの1つであるテストは、一般的に大規模な組織が品質の向上のためにインストールするオプションのシステムです。

管理者は、これらのシステムすべてを必要に応じて使用します。コラボレータは、開発者です。開発者は、開発システムのみで管理者や管理者がコラボレータとして指名するユーザーともに作業します。この項では、考えられるシステムとそれぞれのシステムでの管理者の役割をまとめます。

図2-8 Oracle WebCenter Sites環境

注意:

WebCenter Sites環境でのシステムの名前は、このガイドで使用している名前とは異なる場合があります。一般に、管理システムはステージング、配信システムは本番、テスト・システムはQAまたはQAテストとも呼ばれます。

- 開発システムは、オンライン・サイトのフレームワーク(CMサイトで使用されるデータ・モデルおよびデータ・プレゼンテーション・テンプレート)の計画および作成を担当します。

- 管理システムはステージング領域であり、サイト・コンポーネント(データ・モデル以外)の構成、コンポーネント(データ・モデルを含む)のサイトへのアセンブル、ユーザーに対するサイトの有効化、およびサイトにおけるユーザーの日々のアクティビティの管理を処理します。ユーザーの担当は、オンライン・サイトへの配信に向けたコンテンツの開発と管理です。

- 配信システムは本番領域で、オンライン・サイトのコンテンツを管理システムから受け取り、対象読者にこれを提供します。

- テスト・システムでは、運用を開始する前に、QAが管理システムおよび配信システムとオンライン・サイト自体をテストします。テスト・システムがない場合は、開発システムがテスト・システムの役割も果たします。

3 ログインと開始

次の各トピックでは、一般管理者としてWebCenter Sitesにログインし、サイトを選択し、WebCenter Sites管理者およびWEM Adminインタフェースを使用する方法を示します。ユーザー・パスワードをリセットし、自分のWebCenter Sitesプロファイルを編集し、およびWebCenter Sitesからログアウトする手順も含まれます。

- Oracle WebCenter Sitesへのログイン

- WebCenter Sitesパスワードのリセット方法

- Oracle WebCenter Sitesプロファイルの編集方法

- WebCenter Sitesからのログアウト

3.1 Oracle WebCenter Sitesへのログイン

次の説明は、一般管理者としてOracle WebCenter Sites AdminおよびWEM Adminインタフェースにログインする方法を示しています。

注意:

一般管理者以外で、サイト管理者またはワークフロー管理者としてログインする必要がある場合には、次の手順を実行する前に、一般管理者からユーザー名とパスワードを入手してください。Oracle WebCenter Sitesインタフェースへの権限がロールによって制限されることにも注意してください。

1. ブラウザを開きます。

2. ページを訪れるたびに、格納されているページの新しいバージョンを確認するようにブラウザを設定します。

3. 次のURLにナビゲートします。

http://<server>:<port>/<context>/login

ここで、<server>はWebCenter Sitesを実行しているシステムのホスト名またはIPアドレス、<port>はサーバーのポート番号、<context>はWebCenter Sites Webアプリケーションのコンテキスト・パスです。システムの設定によっては、ポート番号を含めることが必要になる場合もあります。WebCenter Sites環境のシステムには、開発システム、管理システム、配信システム、テスト・システムまたは別のシステムがあります。

WebCenter Sitesログイン・フォームが開きます。

4. ログイン・フォームにユーザー名とパスワードを入力します。

注意:

以前に管理者のいない新規インストールの一般管理者の場合には、デフォルトのシステム・ユーザー(ユーザー名fwadminおよびpassword xceladmin)としてログインし、すぐにパスワードを変更してください。パスワードの変更手順は、Adminインタフェースでのユーザーの作成の手順に従ってください。

デフォルトの管理者としてログオンしたため、REST_Adminセキュリティ・グループの一員であることに加えて、ユーザー名にxceladmin ACL (アクセス制御リスト)が割り当てられています。ユーザー・アカウントとACLの詳細は、ユーザー、プロファイルと属性の構成を参照してください。

一般管理者を作成した場合、その一般管理者は、xceladmin ACLが割り当てられ、REST_Adminセキュリティ・グループの一員である必要があります。

5. WebCenter Sitesで資格証明を保存して、次回のログイン時に情報が自動的に入力されるようにするには、「ユーザー情報の保存」を選択します。

6. 「ログイン」をクリックします。

初めてログインすると、サイト選択のフォームが開きます(手順7を参照)、それ以外の場合は、最後に訪問したサイトとアプリケーションにログインします。

7. 「サイト」ドロップダウン・リストで、使用するアプリケーションをホストしているサイトを選択します。この例では、「AdminSite」を選択します。

サイトを選択する場合、そのサイトに割り当てられているアプリケーションが「サイト」フィールドの下に、アイコンとして表示されます。

8. 使用するアプリケーションを表すアイコンを選択します。

- AdminSiteにログインする一般管理者の場合、WEM Admin およびAdmin の各アイコンが表示されます。WEM Adminインタフェースにアクセスするには、WEM Adminを選択します。Adminインタフェースにアクセスするには、Adminを選択します。

- AdminSite以外のサイトにログインする一般管理者またはサイト管理者の場合、AdminおよびContributorの各アイコンが表示されます。(サイトで有効化されているアプリケーションに応じて、他のインタフェース・アイコンが表示される場合もあります。)

9. これで、選択したサイトとアプリケーションにログインできました。

- Adminインタフェースを選択した場合は、Adminアイコンを選択した場合を参照してください。

- WEM Adminインタフェースを選択した場合は、WEM Adminインタフェースを選択した場合を参照してください。

3.1.1 Adminアイコンを選択した場合

Adminアイコンを選択すると、Adminインタフェースがロードされます(図3-1参照)。管理者は、このインタフェースからすべての管理タスクを実行できます。

図3-1 Adminインタフェース

図3-1は、Adminインタフェースの主要な部分を示しています。

- ウィンドウ最上部のメニュー・バーには、次のコンテンツ管理オプションが含まれます。

- 新規: 選択したサイトで有効化されているアセット・タイプのアセットを作成できます。Adminインタフェースでは、TemplatesやCSElementsなど、上位レベルのアセットの作成のみがサポートされています。他のタイプのアセットはすべて、Contributorインタフェースで作成されます。『Oracle WebCenter Sitesの使用』を参照してください。

- 検索: 現在のサイトに作成されたすべての上位レベル・アセットを検索できます。コンテンツ・アセットを検索するには、Contributorインタフェースにアクセスする必要があります。

- ワーク: ワークフロー割当て、チェックアウトおよびブックマークされたアセットに関する情報を提供します。

- ワークフロー: ワークフロー・レポートの作成、ワークフロー・グループの作成、既存のワークフロー・グループの表示、保存されたワークフロー・レポートの表示ができます。ワークフローの詳細は、ワークフロー・プロセスの作成と管理を参照してください。

- サイト・ナビゲーション: サイトにサイト・ナビゲーションが含まれる場合のみ使用できます。このオプションを使用すると、管理者はサイト・ナビゲーションの名前の変更、サイト・ナビゲーションの並べ替え(Contributorインタフェースの「サイト・ツリー」に表示されます)およびサイト・ナビゲーションでのページの配置と配置解除ができます。

- パブリッシュ: 管理者はパブリッシュ宛先の選択、アクティブなパブリッシュ、スケジュールされたパブリッシュおよびパブリッシュ履歴の表示ができます。

- ナビゲーション・ペインはウィンドウの左側にあり、表示されるタブから管理機能を実行できます。ツリーを選択するには、ペインの最下部にあるバーを選択します。大部分の管理タスクは、「一般的な管理」ツリーから実行できます。「一般的な管理」ツリーには、(ログイン中のサイトだけでなく)システムにあるすべてのサイトのデータが含まれます。

- Adminインタフェースのメイン・ウィンドウでは、管理機能を実行します。メニュー・バーまたはサイト・ナビゲーション・ペインから選択するオプションはすべて、Adminインタフェースのメイン・ウィンドウに表示されます。たとえば、メニュー・バーから「検索」を選択した場合、メイン・ウィンドウに「検索」フォームが開きます。詳細は、管理者固有のツリーとノードを参照してください。

- アプリケーション・バー(インタフェースの最上部にあります)には、現在のサイト上で使用できるアプリケーションのアイコン、プロファイルへのリンク、アクセスできるサイトのメニュー、「ログアウト」ボタンおよびアプリケーション・バーを開き、折りたたむために使用する「上」/「下」の矢印が表示されます。
6つ以上のアプリケーションを実行する場合、追加のアプリケーションを選択するために、「アプリケーションの切替え」ドロップダウン・メニューが表示されます。「アプリケーションの切替え」メニューからアプリケーションを選択すると、現在表示されるうちで最も使用されていないアプリケーションのアイコンが、選択したアプリケーションのアイコンに置き換わります。

3.1.2 WEM Adminインタフェースを選択した場合

一般管理者がWEM Adminアイコンを選択した場合、WEM Adminインタフェースがロードされます。WEMフレームワークによってステータスが一般管理者またはサイト管理者に決定され、操作する必要があるフォームおよびインタフェース機能のみが使用可能になります。

図3-2に、WEM Adminインタフェースの「サイト」フォームを示しています。

図3-2 WEMの管理者インタフェースの「サイト」フォーム

図3-2に表示されたメニュー・バーには、システムのサイト、アプリケーション、ユーザーおよびロールを管理するために使用できる、次のオプションが含まれます。

- サイト: システムのすべてのサイトがリストされている「サイト」フォームを開きます。サイト管理者に表示されるのは、SiteAdminロールが割り当てられているサイトのみです。一般管理者としてログインしている場合、「アプリケーション」、「ユーザー」および「ロール」の各フォームにもアクセスできます。

- アプリケーション: 一般管理者のみアクセスできます。「アプリケーション」フォームが開き、そこから、アプリケーション情報(ツールチップと説明)の編集や、アプリケーションをサイトに割り当てるために割り当てられたロールを管理できます。

- ユーザー: 一般管理者のみアクセスできます。「ユーザー」フォームが開き、そこから、サイトへのユーザーの割当てなど、ユーザーの作成および管理ができます。

- ロール: 一般管理者のみアクセスできます。「ロール」フォームが開き、そこから、コンテンツ管理システムのロールを作成および管理できます。

詳細は、Webエクスペリエンス管理フレームワークの使用を参照してください。

3.2 WebCenter Sitesパスワードのリセット方法

管理者は、ユーザーから忘れたパスワードに関する電子メールを受け取る場合があります。ユーザーのパスワードをリセットするには、次の手順を実行します。

1. WebCenter Sitesにログインし、AdminSiteを選択して、続いてWEM Adminアイコンを選択します。

2. WEM Adminインタフェースで、メニュー・バーから「ユーザー」を選択します。

3. 「ユーザー」フォームで、パスワードをリセットするユーザーの名前を選択し、「編集」を選択します。

4. 「ユーザーの編集」フォームで、次のフィールドに値を入力します。

- 新規パスワード: ユーザーのパスワードを入力します。

- 確認パスワード: 「新規パスワード」フィールドに入力したパスワードをもう一度入力します。

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

ユーザーのWebCenter Sitesパスワードが正常に変更されました。

6. ユーザーに新規パスワードを通知します。セキュリティ目的のため、新しいパスワードでのユーザー・ログインでは、ただちにパスワードを変更することをお薦めします。手順は、『Oracle WebCenter Sitesの使用』を参照するようユーザーに求めてください。

3.3 Oracle WebCenter Sitesプロファイルの編集方法

各WebCenter SitesユーザーはWebCenter Sitesプロファイルを持っており、ユーザー名、電子メール、ロケール、タイムゾーン、優先デバイスおよびパスワードに関する情報が含まれます。

1. WebCenter Sitesにログインして、サイトとアプリケーション・アイコンを選択します。

2. メニュー・バーで、下向き矢印をクリックしてアプリケーション・バーを開きます。

3. アプリケーション・バーで、ユーザー名をクリックします。

4. 「プロファイルの編集」フォームで、次の変更を行うことができます。

- プロファイル・イメージを変更するには、「イメージ・プレビュー」フィールドで「参照」をクリックし、プロファイルに割り当てるイメージを選択します。

- 電子メール・アドレスを追加または変更するには、「電子メール」フィールドを使用します。

- 割り当てられているロケールを変更するには、「ロケール」ドロップダウン・フィールドを使用します。

- 割り当てられているタイムゾーンを変更するには、「タイム・ゾーン」ドロップダウン・フィールドを使用します。

- パスワードを変更するには、次の操作を行います。

a. 「旧パスワード」フィールドに、現在のパスワードを入力します。

b. 「新パスワード」フィールドに、新しいパスワードを入力します。

c. 「パスワードの確認」フィールドに、新しいパスワードを入力します。

5. 「保存して閉じる」をクリックします。
「プロファイルの編集」フォームが閉じ、プロファイルのアクセス元のインタフェースが再表示されます。

3.4 WebCenter Sitesからのログアウト

WebCenter Sitesからログアウトして、セッションを終了します。次を実行します。

1. アプリケーション・バーを開いていない場合は、メニュー・バーの右側にある下矢印をクリックして開きます。

2. 「ログアウト」をクリックします。

これで、WebCenter Sitesからログアウトできました。

4 WebCenter Sitesの管理のロードマップ

サイトの構成プロセスでは、特定のサイト・コンポーネントが他のコンポーネントから要求されるため、さかのぼって実施する手順をできるだけ少なくする場合は、そのコンポーネントを先に作成する必要があります。たとえば、ユーザーを作成するには、それらのACLが先に存在する必要があります。

一般にサイト構成プロセスの手順の順番は入れ替え可能です。1つの有効な手順を次に示します(構成前の決定以降)。重要なサイト・コンポーネントを先に作成し、サイトにアセンブルして、使用可能にします。オプションのコンポーネント(ワークフローを除く)は、パブリッシュ・プロセスを構成した後、最後に検討します。

初めて管理者となる場合、構成プロセスの基本概念の理解とすべての必要な情報の収集のために、次の手順について理解しておくことをお薦めします。サイトの構成方法を理解すれば、要求にあわせて手順を変更できます。

また、次の手順をコピーして、サイトの構成時にすぐに参照できるようにすることをお薦めします。各手順は、このガイド(または『Oracle WebCenter Sitesでの開発』)の項を参照しているため、ここで特定の手順について詳細情報を確認できます。

次の各トピックでは、すべてのWebCenter Sitesシステムを構成する場合に管理者が従う必要があるある手順に関する情報を提供します。

- 構成前の決定

- 各WebCenter Sitesシステム上のジョブの理解

- テスト環境から本番環境への移行

- WebCenter Sites管理者の共通タスク

4.1 構成前の決定

ここでは、管理者と開発者が、開発システムでデータ・モデルをコード化し、テストが正常に終了した後に、データ・モデルを管理システムに移行する予定であることを前提としています。管理システムでは、管理者がサイトの構成タスクを完了し、管理システムをテストし、最後にシステムをデプロイします。

構成を始める前の決定は、特定の順序で処理することをお薦めします。

- コンテンツ管理モデルを決定します。

- どのモデル(1:1、n:1およびx:n)が処理に最も適しているかを決定します。

- どのコンテンツ・アセットを共有し、どのコンテンツ・アセットをコピーする必要があるかを決定します。テンプレート・アセットに対しても同じように決定します。

- 構成するサイトをレプリケートするかどうかを決定します。
構成するサイトをレプリケートする予定がある場合、ソース・サイト(現在構成中のサイト)のテンプレート・コーディングおよびその他の要件を満足しているか確認してください。サイト・レプリケーションの概要およびレプリケーションのオプションと要件は、コンテンツ管理サイトのレプリケートを参照してください。

- データ・モデリングを決定します。

- 作成する必要のあるアセットのタイプ

- リビジョン追跡を使用する必要があるアセット・タイプ

- どのユーザーがどのサイトのどのアセット・タイプへのアクセス権を持つ必要があるか

- 開発者が作成する必要のあるテンプレートのタイプ

- ユーザー管理方法の決定:
WebCenter Sitesのネイティブ・ユーザー・マネージャ、LDAPプラグインまたは外部のマネージャから選択できます。

このガイドは、ネイティブのWebCenter Sitesユーザー・マネージャに基づきつつ、LDAP統合されたシステムのシステム動作について説明しています。詳細は、LDAP統合Sitesシステムでのユーザー、サイト、およびロールを参照してください。LDAPでのユーザーの構成の詳細は、LDAP製品のドキュメントを参照してください。

- ユーザー管理モデルを決定します。

- 必要なユーザー数。

- ユーザーはだれか

- データベース表に対するどの権限をユーザーに付与する必要があるか。
実装しているユーザー管理方法に関係なく、WebCenter SitesでACLを定義しておく必要があります。システムACL(作成した場合はカスタムACLも)のリストを調べて、どのACLをユーザーに割り当てるかと、追加のACLを作成する必要があるかどうかを判断します。通常は、システムACLで十分です。ACLに関する一般的な情報は、ACLおよびロールの使用を参照してください。仕様の詳細は、システム・デフォルトを参照してください。

- ユーザーにはどのシステムACLを割り当てる必要があるか(ACLがない場合、ユーザー・アカウントは作成できません)。

- カスタムACLを作成する必要があるかどうか。
(特定のデータベース表へのアクセスを制限するため、Webサイトの訪問者に割り当てるACLを作成する必要がある場合もあることに注意してください。)

- 必要なロール数:
WebCenter Sitesでは、いくつかのシステム・ロールとサンプル・サイト用の追加ロールが定義されています。これらのロールを実際に使用するサイトで再利用するか、独自のロールを作成できます。通常は、特定のサイトに対するユーザーの役割をすべて包含するロールを作成する必要があります。

ロールについての一般的な情報はコンテンツ管理の概念についておよびロールの使用を、システム・ロールとその仕様の一覧はシステム・デフォルトを、それぞれ参照してください。

- 必要なロールのタイプ(ライター、エディタ、イラストレータ)。ロールはユーザーのACLと互換性があるようにしてください。

- そのロールを割り当てる必要のあるユーザー。

- 追加のシステム設定を決定します。
開発者がオンライン・サイトの設計や管理システムのユーザー・インタフェースの変更の検討を開始する前に、管理者はセキュリティ・プロトコルを決定し、実装する必要があります。セキュリティに関する決定は、開発者によるオンライン・サイトのコード化や実装の方法に影響します。セキュリティの詳細は、外部セキュリティの設定を参照してください。

- ワークフロー・プロセスを決定します。
新しく作成されたそのタイプのアセットが自動的にワークフローに加わるように、オプションで、ワークフロー・プロセスをアセット・タイプに添付できます。

- ワークフローを実装する必要があるかどうか

- 実装する必要がある場合、どのアセット・タイプがワークフロー・プロセスを必要とするか

- どのようにワークフロー・プロセスを設計する必要があるか

- ワークフロー・プロセスに参加する必要のあるユーザーおよびロール

- パブリッシュ・システムのオプションを決定します。

- 構成する必要のあるパブリッシュのタイプ

- パブリッシュ・スケジュールを承認する必要があるかどうか

- ユーザー・インタフェース・オプション。ユーザーに必要なインタフェースを決定します。

- Contributor (フォーム・モードおよびWebモード)

- Admin

- WEM Admin

構成タスクを始める前に、WebCenter Sitesの概念、コンポーネントおよびコンテンツの管理モデルの基本概念を理解するために、コンテンツ管理の概念についてを通読してください。

4.2 各WebCenter Sitesシステム上のジョブの理解

Webサイトとコンテンツ管理サイトの仕様が確立されたら、作業を開始できます。管理者は、開発ステージにおいて、WebCenter Sites環境内のすべてのシステムを扱います。ただし、Webサイトが運営されると、管理者はほとんどの時間を管理システムおよび、配信システムの一部に費やし、開発システムに費やす時間はありません。

管理者には各システムで特定の業務があります。開発者がデータ・モデルとその他のコードベースのコンポーネントを担当する一方で、管理者はその他すべての面を担当します。

次の各トピックで、WebCenter Sitesシステム上で実行するジョブについて説明します。

- 開発システムの構成

- 管理システムの構成

- 配信システムの構成

- テスト・システムの構成

4.2.1 開発システムの構成

開発システムでは、コーディングが行われます。開発システムにおける構成手順は、『Oracle WebCenter Sitesでの開発』でも詳細に説明しています。

開発システムでのコーディングが完了すると、データ・モデルは管理システムに移行され、そこでサイト構成が完了します。

管理者の業務は、開発者に管理システムの仕様を提供し、サイトの作成など、コンテンツ管理処理を支援することです。

開発者の業務は次のとおりです。

- 管理システムで使用される名前と同じ名前でサイトを作成する。サイト作成の情報と手順は、コンテンツ管理サイトのアセンブルを参照してください。

- データ・モデル(アセット・タイプとその定義):を作成する
開発者が、データ・モデルまたは管理システム上で使用されるなんらかのサイトを作成するには、開発者を(望ましくは開発システムの管理ユーザーとして)作成して構成する必要があります。この詳細は、管理システムの構成を参照した上で、開発者のシステム上に管理者を作成してください。

- コンテンツのアセット・タイプを作成する:
まず、再利用性を最大限にするために、最も広い用途のアセットを作成します。

1. デザイン・アセット・タイプ(テンプレート)を作成します。サイト・レプリケーション要件がある場合はそれらに留意します。

2. 管理アセット・タイプを作成します。

3. 各タイプのサンプル・アセットを作成します。

アセット・タイプの作成の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- 企業のQA要件に従ってデータ・モデルをテストします。

- データ・モデルが完成し、テストしてすべてのコラボレータの満足が得られると、開発者はこのコードを管理システムに移行します。
データ・モデルを移行するには、管理システムにこれをパブリッシュします。手順は、次のトピックを参照してください。

- パブリッシュの理解

- リアルタイム・パブリッシュの使用

- パブリッシュ・イベントのスケジュール

注意:

WebCenter Sites環境で、開発者はデータ・モデルを移行するのではなく、管理システムでデータ・モデルを再作成することを選択する場合もあります。

一度開発が完了すると、開発システムは処理を継続します。継続される機能の1つは、サイト訪問者、コンテンツ・プロバイダ、マーケティング担当者および管理者からの変化する要求に応じたデータ・モデルの修正です。

4.2.2 管理システムの構成

開発システムの環境を整えた後は、管理システムを構成できます。コーディングを必要としない構成タスクは、一般的に管理システムで行われます。ここでは、管理作業は意図的に協調しないかぎり協調的ではありません。たとえば、管理システムではデータ・モデリングやコーディングが行われないため、開発者からの支援が必要ありません。ただし、システムの特定のサイトまたはワークフロー・プロセスを管理するため、開発者(またはその他ユーザー)をサイト管理者またはワークフロー管理者に指名できます。

管理システム上で、次の順序で構成を完了します。

- サイトを作成する

注意:

このリリースのWebCenter Sitesでは、サイト・ランチャ機能を使用してソース・サイトをレプリケートすることにより、新しいサイトを迅速にスピンオフできます。その後、必要に応じてそのレプリケートを変更できます。サイト・レプリケーションおよび適切なソース・サイトの選択または作成の詳細は、コンテンツ管理サイトのレプリケートを参照してください。

- ユーザー(コンテンツ・プロバイダとマーケティング担当者)をする:

- 必要に応じて、ACLを作成します。ACLの作成手順は、ACLおよびロールの使用を参照してください。

注意:

システムACLはどのような状況でも、変更または削除しないでください。

データベース表。データ・モデルを管理システムに移行するときは、必要に応じてカスタム・データベース表(アセット・タイプ)にACLを割り当てます。ACLをデータべース表に割り当てる手順は、ACLおよびロールの使用を参照してください。

- WebCenter Sitesか、LDAPプラグインなどの外部ユーザー・マネージャにより、ユーザー・アカウントを作成します。WebCenter Sitesでのユーザー・アカウントの作成手順は、Adminインタフェースでのユーザーの作成を参照してください。

- 必要に応じてWebCenter Sitesでロールを作成します。ロールの作成手順は、ACLおよびロールの使用を参照してください。

- ユーザー・プロファイルを作成する(必要時):
次を使用するユーザーにはユーザー・プロファイルが必要です。

- WebCenter Sitesコンテンツ・アプリケーション(Oracle WebCenter Sites: Engage)。

- 言語パックとデフォルトの言語の設定

- ワークフロー参加者に割当てを通知するために電子メール・メッセージを送信するワークフロー・プロセス。ユーザー・プロファイルは、電子メール・アドレスにユーザー名をマップすることで、ワークフロー・アクションをサポートします。

ユーザー・プロファイルは、WebCenter Sitesで作成する必要があります。手順は、ユーザー・プロファイルとユーザー属性の使用を参照してください。

- ユーザー属性を設定する(必要時):
ユーザーの属性として、ユーザー・プロファイルに指定されているロケールや電子メール属性以外のものが必要な場合、属性を作成できます。手順は、ユーザー属性の修正、追加および削除を参照してください。

- アセット・タイプのワークフロー・プロセスを作成する(必要時):
ワークフロー・プロセスの実装は、業務上の判断であり、WebCenter Sitesの要件ではありません。ワークフロー・プロセスを作成する必要がある場合は、次の手順を実行します。

1. サイトの「ワークフロー」ツリー・ノードが存在しない場合、作成します。手順については、ツリー・タブの作成を参照してください。

2. ワークフロー・プロセスを図に描いて計画します。この手順のヘルプは、ワークフロー・プロセスの作成と管理を参照してください。描いた図やメモは、この項を通して参照してください。

3. そうしない場合は、ワークフロー・プロセスに必要なロールを作成します。詳細は、Adminインタフェースからのロールの作成を参照してください。

4. ユーザーがワークフローに効果的に参加できるように設定します。

a. ワークフローに参加するユーザーに、ユーザー・プロファイルが作成されていることを確認します。作成されていない場合、ワークフロー・プロセスからの電子メール・メッセージを受信できません。

b. 共有アセットについて、アセットを共有するすべてのサイトのユーザーをワークフロー候補のプールに含める場合、サイト間割当て機能を有効にします。詳細は、ロールと参加者の決定を参照してください。

5. アクションに必要な電子メール・オブジェクトを作成し、wcs_properties.jsonファイルのxcelerate.emailnotificationプロパティを有効化します。詳細は、コンテンツ管理の概念についてを参照してください。

6. 必要なステップ・アクション、時間指定アクション、デッドロック・アクション、グループ・デッドロック・アクションおよび委任アクションを作成します。手順については、アクションと条件の設定を参照してください。

7. 状態に期限がある場合は、アセットの期限を定期的に計算して、適切な時間指定アクションがあれば、これをタイムリに起動するように、時間指定アクション・イベントを構成します。手順については、時間指定アクション・イベントの設定を参照してください。

8. 状態を作成します。手順については、状態の設定を参照してください。

9. プロセスを作成します。ワークフロー・プロセスを作成しながら、そのプロセスの手順を作成します。状態が適切な順序で発生するように、手順でこれらの状態を結合します。さらに、プロセスの作成の際、必要な機能の権限も構成します。手順については、ワークフロー・プロセスの設定を参照してください。

10. ワークフロー・プロセスをテストします。手順については、ワークフロー・プロセスのテストを参照してください。

作成したワークフロー・プロセスが自動的にアセットに割り当てられるように、スタート・メニュー・ショートカットを設定します。スタート・メニュー・アイテムの詳細は、スタート・メニュー・アイテムの管理を参照してください。

- 開発システムで作成されたサイトを再作成する:
サイト作成の情報と手順は、コンテンツ管理サイトのアセンブルを参照してください。

- データ・モデルを移行する(行っていない場合):
ここで、残りの大半の手順を完了するためにデータ・モデルが必要です。リアルタイム・パブリッシュに関する章の手順を使用して、リアルタイムにデータ・モデルを開発システムから管理システムへとパブリッシュします。

- サイトをアセンブルする:

1. サイトへのアクセス権限をユーザーへ付与します。手順については、ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)を参照してください。

2. アセット・タイプをサイトに関連付けることにより、サイトでアセット・タイプを有効化します。手順については、サイトに対するアセット・タイプの有効化を参照してください。

注意:

この手順によって、有効化するアセット・タイプのスタート・メニュー・アイテムをWebCenter Sitesが自動的に作成できるようにするオプションを選択できます。サイト・ユーザーは、「新規」および「検索」のスタート・メニュー・アイテムを使用して、該当するタイプのアセットを作成および検索できます。独自のスタート・メニュー・アイテムを作成することもできます。

- サイト・コンポーネントをユーザーに対して使用可能にする:

1. 各種アセット・タイプに対して独自のスタート・メニュー・アイテムを作成する場合は、スタート・メニューを使用したアセット・タイプへのアクセスの管理の手順を参照してください。

2. アセットにアクセス権限を設定します。手順については、アセットへのアクセス権限の設定方法を参照してください。

3. WebCenter Sitesのツリー内のタブへのアクセス権限をユーザーに付与します。詳細は、ツリーへのアクセスを管理するためのオプション(Adminインタフェースのみ)を参照してください。

- WebCenter Sitesのパブリッシュ・プロセスを構成する:

1. 管理システムで実行するパブリッシュのタイプを決定します。

- RealTime

- ディスクへのエクスポート

- サーバーへのミラーリング

- XMLへのアセットのエクスポート

2. コンテンツ・プロバイダが作成する情報が配信システムで利用できるように、パブリッシュ・プロセスを構成します。

パブリッシュ・プロセスの構成に関する一般的な情報と手順は、エクスポートおよびミラーリングのパブリッシュに関する章を参照してください。リアルタイム・パブリッシュ・プロセスの詳細は、リアルタイム・パブリッシュに関する章を参照してください。

- ユーザー・インタフェースを構成する:
ユーザー・インタフェース・オプションは、Oracle WebCenter Sites: Contributor、AdminおよびWEM Adminです。これらのインタフェースをコンテンツ・プロバイダが利用できるようにする手順は、ユーザー・インタフェースの構成を参照してください。

- 検索エンジンのアセット・タイプを有効化する:
アップグレードなど、特定のケースでは、アセット・タイプを検索するように構成し、正しく索引付けして、使用している検索エンジンから検出可能にすることが必要になる場合があります。アセット・タイプの構成手順は、Lucene検索エンジンの構成を参照してください。

- リビジョン追跡を設定する:
リビジョン追跡は、アセットが複数のユーザーから一度に編集されることを防止します。データベース表のリビジョン追跡を有効化すると、WebCenter Sitesではその表の複数のバージョンのアセットが維持されます。リビジョン追跡の設定手順は、リビジョン追跡の管理を参照してください。

- 配信システムを設定する詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- 企業のQA要件に従ってすべてのシステムをテストします。

- WebCenter SitesインストールのURLとログイン情報をユーザーに提供します。ユーザーはログインすると、管理者による構成に従ってコンテンツを制御および管理できます。

4.2.3 配信システムの構成

配信システムは開発者によって構成され、一般的にはシステムが使用できるようになるまで管理者は関与しません。サーバーへのミラーリングおよびリアルタイムの配信の場合、配信システムはWebCenter Sitesインストール全体となります。ディスクへのエクスポートおよびXMLへのエクスポートの配信の場合、配信システムはWebCenter SitesインストールのWebサーバー・コンポーネントのみとなります。

4.2.4 テスト・システムの構成

テスト・システムでは、運用を開始する前に、QAアナリストが管理システムおよび配信システムとオンライン・サイト自体のパフォーマンスをテストします。テスト・システムがない場合は、開発システムがテスト・システムの役割も果たします。通常、管理者はテストには関与しません。

4.3 テスト環境から本番環境への移行

組織は、テスト環境などのソース環境から、本番環境などのターゲット環境へ、WebCenter Sitesの1つ以上のインスタンスまたはそのコンポーネント・アプリケーション(Visitor Services、Satellite Serverまたはサイト・キャプチャ)を切り替えることができます。そうする場合は、『Oracle Fusion Middlewareの管理』のテスト環境から本番環境への移行に関する項を参照してください。

4.4 WebCenter Sites管理者の共通タスク

テストから本番環境にWebCenter Sitesを移動したら、テスト環境から本番環境への移行に記載されているように、管理システム上で、次のような作業をほぼ独占的に実行できます。

- ユーザーを管理する

- ユーザーの権限をデータベース表に合わせる

- ユーザーを追加、削除および再編成する

- ワークフローを作成する

- ユーザーのインタフェースを構成する

- パブリッシュ・システムを管理する

- その他、オンライン・サイト訪問者、コンテンツ・プロバイダおよびE-Businessの要件に応じる。

第II部 サイト基盤の管理

次の各トピックでは、コンテンツ管理サイト基盤のアセンブルと管理について説明します。

- コンテンツ管理サイトのアセンブル

- ACLおよびロールの使用

5 コンテンツ管理サイトのアセンブル

管理者の主要な目標はサイトの操作(サイトの作成、編集および削除)で、サイト・ユーザーの管理(ユーザーの追加、編集および削除)と、サイトのアセット・タイプの管理(アセット・タイプの有効化と除去)が含まれます。コンテンツ管理サイトは、基本的なコンポーネントを作成すれば、アセンブルできます。基本コンポーネントは、ユーザーとデータ・モデルです。

次の各トピックでは、コンテンツ管理サイトのアセンブルについて詳しく説明します。

- サイトの使用

- サイト・ユーザーの割当てと管理

- アセット・タイプの有効化と管理

5.1 サイトの使用

サイトをアセンブルするには、ユーザーをサイトに割り当て、そのサイトにコンテンツ(アセット・タイプ)を割り当てる必要があります。次の各トピックでは、サイトの作成、サイトへのユーザーの関連付け、およびそのサイトへのアセット・タイプの割当てについて説明します。

- 管理者インタフェースからのサイトの作成

- サイトの構成情報の取得

- Adminインタフェースでのサイトの編集

- Adminインタフェースでのサイトの削除

5.1.1 管理者インタフェースからのサイトの作成

サイトを作成するためには、サイト名、説明、およびサイト・コンテンツのプレビュー方法を指定します。次を参照してください。

1. 「一般的な管理」ツリーで、「管理」、続いて、「サイト」を開き、続いて、「新規追加」をダブルクリックします。

「新規サイトの追加」フォームが開きます。

2. 「名前」フィールドに、新規サイトの名前を入力します。サイトに名前を付ける際は、次の規則に注意してください。

- 1から255文字で指定する必要があります。

- 次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、疑問符(?)、アンパサンド記号(&)、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュは使用できません。

- 名前に空白を含めることはできません。

3. 「説明」フィールドに、WebCenter Sitesのインタフェースに表示するサイト名を入力します(最大64文字)。このサイト名は、ユーザー・インタフェース全体でサイトのリストに使用されます。

4. 「プレビュー方法」フィールドでは、サイトのコンテンツをプレビューする方法を選択します。

5. 「サイトの追加」をクリックします。

「サイト」フォームが開きます。

図5-1 「サイト」フォーム

このフォームは、いくつかの操作を実行するために使用されます。このフォームでは、サイトの調査、編集または削除、ユーザーの管理、サイトをレプリケートするためのサイト・ランチャの構成など、様々な操作を実行できます。

「サイト」ノードに新しいサイトを追加すると、WebCenter Sitesにより、サイト名の下に、サイト・コンポーネントを要求する一連のサブ・ノードが作成されます。

- サイト・ユーザーを管理するには、「このサイトのユーザーの管理」をクリックします。

- Webサイトのアセット・タイプを選択するには「アセット・タイプの有効化...」をクリックします。アセット・タイプを削除するには、「アセット・タイプの無効化...」をクリックします。アセット・タイプは開発者が作成します。

- サイトに作成されたスタート・メニュー・アイテムを表示するには、「このサイトのすべてのスタート・メニュー・アイテムのリスト」をクリックします。

- サイトのワークフローを管理するには、「このサイトのすべてのワークフロー・プロセスのリスト」をクリックします。

- サイト・ランチャを構成および有効化するには、「このサイトのサイト・ランチャの構成」をクリックします。

各サブノードにはリンク・メカニズムが備えられており、これによりサブノードおよびサイトを構成プールのデータと関連付けることができます。このリンク・メカニズムにより、サブノードを削除したり、サブノードにカスタム・サブノードを補充することはできません。サブノードを選択すると、次に説明するとおり、構成プールに入れる必要がある、サブノードに必要なすべてのデータを作成できます。

前述の手順は、新規サイトの追加のみです。

- サイトを使用可能にするには、ユーザーとアセット・タイプ(開発者が作成)をサイトに関連付ける必要があります。ワークフロー・プロセスを使用するように計画している場合は、そのプロセスも作成する必要があります。

- サイトを他のWebCenter Sitesシステムにコピーまたは移行するには、リアルタイム・パブリッシュの方法を使用します。リアルタイム・パブリッシュに関する章を参照してください。

5.1.2 サイトの構成情報の取得

特定の状況では、サイトが構成された方法を把握する必要があります。たとえば、どのアセット・タイプとワークフロー・プロセスが有効化されているかや、どのようなサイト・ユーザーがいるかなどです。

サイトの構成情報を取得するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いて、構成を表示するサイトをダブルクリックします。

「サイト」フォームが開きます。

2. 「サイト」フォームで、確認する情報を提供するオプションを選択します。次に例を示します。

- 「ワークフロー・プロセス」フィールドで、「このサイトのすべてのワークフロー・プロセスのリスト」をクリックすると、このサイトに関連付けられているワークフロー・プロセスが表示されます。
「ワークフロー・プロセス」リストで「新規ワークフロー・プロセスの追加」をクリックして、サイトの追加のワークフロー・プロセスを構成します。

- 「サイト・ナビゲーション」フィールドで、次のオプションの1つをクリックします。

- 「サイト・ナビゲーションの管理」をクリックすると、サイトに関連付けられたサイト・ナビゲーションが表示されます。「サイト・ナビゲーションの追加」をクリックすると、サイトに対して新しいサイト・ナビゲーションが作成されます。

- ContributorインタフェースのSite Treeに表示されるサイト・ナビゲーションの順序を並べ替えるには、「サイト・ナビゲーションの順序」をクリックします。

- 「パブリッシュの宛先」フィールドで、「配信用のミラー・サイト構成」をクリックすると、コンテンツ管理サイトが配信システムにパブリッシュされます。

- 「サイト・ランチャ」フィールドで、「このサイトのサイト・ランチャの構成」をクリックすると、すべてのサイト・コンポーネントが新しいサイトと共有されます。

5.1.3 Adminインタフェースでのサイトの編集

サイトの編集は、サイトの説明やプレビュー方法を変更することを意味します。サイトの名前を変更する必要がある場合、サイトを削除して、正しい名前でサイトを作成する必要があります。

サイトの説明を編集するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「サイト」を開き、続いて変更するサイトをダブルクリックします。
「サイト」フォームが開きます。

2. 「サイト」フォームで、「編集」をクリックします。
「編集」フォームが開きます。

3. 「編集」フォームで、次の手順を実行します。

a. 「説明」フィールドに、適当な変更を加えます。

b. 「プレビュー方法」フィールドで、必要に応じて、別のプレビュー方法を選択します。

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

5.1.4 Adminインタフェースでのサイトの削除

サイトを削除すると、そのサイトのすべての構成情報が削除されるか、共有が解除(サイトがデータを他のサイトと共有していた場合)されます。次の構成情報は、サイトの削除の影響を受けます。

- サイトに対して有効にされていたスタート・メニュー・アイテムは削除されるか共有が解除されます。

- SmartListsは削除されるか共有が解除されます。

- パブリッシュの宛先は共有が解除されます。

- ユーザーはサイトから削除されます。

- 共有されていたワークフローは、共有が解除されるか削除されます。

- 共有されていたテンプレート・アセットでは、SiteEntryが削除されます。

- サイトとツリー・タブに対して有効化されていたアセット・サブタイプは、削除されるか共有が解除されます。

このため、サイトを削除する前に、維持する必要があるアセットが共有されていることを確認してください。

サイトを削除するには::

1. 「一般的な管理」ツリーで、「管理」を開き、続いて「サイト」をダブルクリックします。

2. サイトのリストで、削除するサイトに移動し、その「削除」アイコンをクリックします。

サイト・コンポーネントが削除されることを通知する警告が表示されます。警告では、該当するコンポーネントが示され、そのサイトを削除する意思があるか確認を求められます。

3. 「サイトの削除」をクリックします。

5.2 サイト・ユーザーの割当てと管理

次の各トピックでは、WebCenter Sitesユーザーにサイトへのアクセス権限を与える方法、サイト・ユーザーの表示方法、サイトでのユーザーのロール割当てを変更する方法およびサイトからのユーザーの削除方法を示します。

- ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)

- サイト・ユーザーの表示とロールの再割当て

- サイトからのユーザーの削除

5.2.1 ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)

ユーザーがサイトへのアクセス権限を取得するには、そのサイトでユーザーにロールが少なくとも1つ割り当てられている必要があります。割り当てられたロールによって、ユーザーがサイトに関連付けられ、そのユーザーはサイトへログインが可能になります。ユーザーに割り当てられたロールの1つが、サイトのインタフェース機能にも指定されている場合は、ユーザーにインタフェース機能へのアクセス権限が付与されます。

注意:

1人以上のユーザーと1つのロールおよび1つのサイトが作成済であると仮定します。いずれかの作成が必要な場合は、Adminインタフェースでのユーザーの作成、Adminインタフェースからのロールの作成およびAdminインタフェースからのサイトの作成の手順に従います。

サイトへのアクセス権限をユーザーに付与するには:

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてサイトを開きます。

2. 「ユーザー」をダブルクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

3. ユーザー名を入力して、「選択」をクリックします。

「ユーザー・ロールの管理」フォームにユーザー名が表示されます。ユーザー名の下にロールは表示されません。

注意:

システム全体のユーザーのリストが必要な場合は、次の方法でリストを開きます。

「ユーザー・アクセス管理」を開き、「ユーザー」をダブルクリックします。「ユーザー名の入力」フィールドを空白のままにして、「ユーザーの修正」を選択し、「OK」をクリックします。

4. ユーザー名の横の「編集」アイコンをクリックします。

「ロールの編集」フォームが開きます。

図5-2 「ロールの編集」フォーム

5. リストから1つ以上のロールを選択します。複数のロールを選択するには、各ロールを[Ctrl]キーを押しながらクリックします。特定の範囲のロールを選択するには、その範囲の最初と最後のロールを[Shift]キーを押しながらクリックします。

注意:

ユーザーのタイプを考慮してください。一般管理者、サイト管理者および通常のユーザーには、異なるシステム定義ロールが必要です。たとえば、通常のユーザーには、Oracle WebCenter Sites: Contributorインタフェースへのアクセス権が必要です。この場合は、SitesUserロールを選択します。システム定義ロールの選択方法の詳細は、システム・ロールを参照してください。

ロール(1つまたは複数)を選択すると、ユーザーは、手順1で使用するよう選択したサイトのメンバーになります。必ずしもユーザーがサイトのコンテンツを管理できるようになるわけではありません。コンテンツを管理するために、ユーザーはサイト上のインタフェース機能(たとえば検索)にアクセスする必要があります。

ユーザーのサイトで、どのロールがどのインタフェース機能を起動可能であるかがわかっている場合は、この手順で該当するロールを選択します。不明な場合は、ここで選択したロールを、ユーザーが必要とするインタフェース機能にも(以降の章で)指定します。この機能には、スタート・メニュー・アイテム、ツリー・タブ、ワークフロー・プロセス、アセットの承認とパブリッシュ機能などがあります。

ユーザー・ロールの割当ての詳細は、ロールの使用を参照してください。

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

7. コンテンツ管理サイト・コンポーネントへのアクセスの管理の手順に従って、サイト・コンポーネントへのユーザー・アクセスを付与します。

注意:

ユーザーのロールで使用可能な機能があっても、ユーザーにデータベース表を操作する適切なACL権限がなければ、その機能を操作できません。(ロールがインタフェース機能へのアクセスを可能にする一方で、ACLがデータベース表へのアクセスを許可することでその機能が有効になります。)ロールとそれらのACLとの関係の詳細は、ユーザーとロールを参照してください。

5.2.2 サイト・ユーザーの表示とロールの再割当て

特定のサイトのユーザーとそれらのロールのリストを表示し、ロールを再割当てするには::

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてサイトを開きます。

2. サイトで「ユーザー」をダブルクリックします。
「ユーザー・ロールの管理」フォームが表示されます。

3. 「ユーザー・ロールの管理」フォームで、ユーザー名のフィールドを空白のままにし、「選択」をクリックします。
「ユーザー・ロールの管理」フォームに、選択したサイトで現在ロールを割り当てられているすべてのユーザーのリストが表示されます。

図5-3 「ユーザー・ロールの管理」フォーム

4. (オプション)ユーザーのロールを再割当てする場合には:

a. ユーザー名に移動し、その「編集」アイコンをクリックします。
「ロールの編集」フォームが開きます。

b. 「ロールの編集」フォームで、リストから1つ以上のロールの選択(または選択解除、あるいはそれら両方)を行って、「保存」をクリックします。

c. 必要に応じて、各ユーザーについてaとbを繰り返します。

5.2.3 サイトからのユーザーの削除

ユーザーは、システムから削除することなく、サイトから削除できます。

ユーザーをサイトから削除するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いて削除するユーザーが割り当てられているサイトを開きます。

2. サイトで「ユーザー」をダブルクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

3. 「ユーザー・ロールの管理」フォームで、目的のユーザー名を入力し、「選択」をクリックします。

4. 開いたフォームで、ユーザーの横の「削除」アイコンをクリックします。

警告メッセージが表示されます。

5. 「サイトからのユーザーの削除」をクリックします。

5.3 アセット・タイプの有効化と管理

次の各トピックでは、サイトにアセット・タイプを追加(アセット・タイプを有効化)する方法と、サイトからこれらを削除する方法を示します。

- サイトに対するアセット・タイプの有効化

- サイトからのアセット・タイプの削除

5.3.1 サイトに対するアセット・タイプの有効化

アセット・タイプの有効化は、アセット・タイプを選択された1つ以上のサイトに関連付けることを意味します。この割当てを一度行えば、コンテンツ管理サイト・コンポーネントへのアクセスの管理に示すように、スタート・メニュー・アイテムやツリー・ノードなどのインタフェース機能によってアセット・タイプ自体をユーザーが使用できます。

サイトに対してアセット・タイプを有効化するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてアセット・タイプを有効化するサイトを開きます。

注意:

SiteAdmin roleロールはあるが、GeneralAdminロールはない場合、「サイト」ツリーを選択し、続いて「サイト管理者」を開きます。

2. サイトで、「アセット・タイプ」を開いて、「有効化」をダブルクリックします。

「アセット・タイプの有効化」フォームが表示されます。

図5-4 「アセット・タイプの有効化」フォーム

リストされたアセット・タイプは、選択したサイトではまだ有効化されていません。

3. このサイトに対して有効化するアセット・タイプを選択します。

注意:

コンテンツ問合せアセットは、管理インタフェース内ではサポートされていません。

4. 「アセット・タイプの有効化」をクリックします。

「アセット・タイプの有効化 - スタート・メニューの選択」フォームが表示されます。

5. (オプション)「アセット・タイプの有効化 - スタート・メニューの選択」フォームで、WebCenter Sitesで作成する各スタート・メニュー・アイテムの横にあるボックスを選択します。スタート・メニュー・アイテムの詳細は、スタート・メニューを使用したアセット・タイプへのアクセスの管理を参照してください。

図5-5 「タイプ・アセットの有効化」フォーム - 「スタート・メニューの選択」

この時点で、スタート・メニュー・アイテムを生成しないように選択した場合は、後から、手動で作成する必要があります。有効化したばかりのアセット・タイプのアセットは、対応するスタート・メニュー・アイテムが作成されるまで作成できません。

6. 「アセット・タイプの有効化」をクリックします。

7. アセット・タイプが、サイトに対して有効になります。それらのスタート・メニュー・アイテムを作成する必要がある場合は、続けてスタート・メニューを使用したアセット・タイプへのアクセスの管理の手順を実行してください。

注意:

Contributorインタフェースのツリー(「サイト・ツリー」、「コンテンツ・ツリー」および「ワーク」ツリー)でアセットを表示するには、アセットのツリー・タブも手動で作成する必要があります。

5.3.2 サイトからのアセット・タイプの削除

Adminインタフェースを介して、サイトからアセット・タイプを削除できます。

サイトからアセット・タイプを削除するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてアセット・タイプを削除するサイトを開きます。

注意:

SiteAdmin roleロールはあるが、GeneralAdminロールはない場合、「サイト」ツリーを選択し、続いて「サイト管理者」を開きます。

2. サイトで、「アセット・タイプ」を開いて、「無効化」をダブルクリックします。

「アセット・タイプの無効化」フォームが表示されます。

図5-6 「アセット・タイプの無効化」フォーム

選択したサイトで有効化されているアセット・タイプがフォームに表示されます。

3. サイトから削除するアセット・タイプを選択します。

4. 「アセット・タイプの無効化」をクリックします。

注意:

サイトで無効にしたアセット・タイプのスタート・メニュー・アイテムまたはワークフロー・プロセスが存在する場合は、それらに変更が反映されるようにスタート・メニュー・アイテムまたはワークフロー・プロセスを編集します。

6 ACLおよびロールの使用

アクセス制御は、アクセス制御リスト(ACL)、ユーザー・アカウント、ユーザー・プロファイル、ロールおよびサイトといったユーザー管理コンポーネントを介して処理されます。サイト構成は、ACL、ユーザー・アカウントおよびロールの作成から開始します。

ACLは、管理システムと配信システムの両方で使用されます。ただし、次のトピックの主要な焦点は、管理システムのユーザー管理です。配信システムのユーザー管理の詳細は、『Oracle WebCenter Sitesでの開発』の、WebCenter Sitesの開発プロセスに関する項を参照してください。

- ACLとロールの概要

- アクセス制御リスト(ACL)

- ACLの使用

- ロール

- ロールの使用

6.1 ACLとロールの概要

ACLは、WebCenter Sitesシステムへのアクセスを制御するために使用されます。ユーザー、データベース表およびWebCenter SitesページへのACLの割当てによって、WebCenter Sitesのデータベース表でのユーザーの操作権限が決まります。ユーザーのACLがデータベースのACLと一致すると、ユーザーにはデータベース表での操作権限(ACLにより定義されます)が与えられます。そのため、ACLはセキュリティおよびユーザー管理モデルの基盤としての役割を果たします。ACLがない場合、ユーザー・アカウントは作成できません。

ロールは、サイトおよびそのコンポーネントへのアクセスを管理します。指定のサイトで、ロールをユーザーとインタフェース機能に割り当てて、インタフェース機能を有効化したり、非表示にしたりします。ユーザーのロールがインタフェース機能に割り当てられたロールと一致すると、その機能がそのユーザーに対して有効になります。一致しないと、その機能は無効となります。

ユーザーを設定する前に、ユーザーのACLおよびロールを決定する必要があります。LDAPプラグインを使用してユーザー・アカウントを作成する予定であっても、ACLおよびロールが存在しない場合には、WebCenter Sitesでこれらを作成する必要があります。

6.2 アクセス制御リスト(ACL)

アクセス制御リスト(略称ACL)は、読取り、書込み、作成、取得などの指定された一連のデータベース操作権限です。WebCenter Sites (およびWebCenter Sitesのコンテンツ・アプリケーション)のすべてが、1つ以上のデータベース表に、1つ以上の行で表されるため、すべてのWebCenter Sitesシステムのユーザー管理はACLから始まります。

ACLにより、次のアイテムへのアクセスを制限できます。

- 個々のデータベース表

- 個々のWebCenter Sitesページ

WebCenter SitesおよびWebCenter Sitesコンテンツ・アプリケーションは、これらの機能を表すデータベース表へのユーザーのアクセス権をACLを介して制御します。WebCenter Sitesは、機能の実行を試みるユーザーのユーザー・アカウントに、データベース表に割り当てられたものと同じACLが割り当てられていることを確認します。

たとえば、ユーザー・アカウント情報は、SystemUsersとSystemUserAttrsというシステム表に含まれています。特定のACLがこれらのシステム表に割り当てられているため、ユーザー・アカウントに同じACLが割り当てられているユーザーのみが、ユーザーを作成したり、既存のユーザー情報を編集できます。

ACLは、許可機能を提供することによって、WebCenter Sitesシステムにおけるセキュリティおよびユーザー管理モデルの基盤として機能します。ユーザー情報の格納にLDAPなどの外部のユーザー・マネージャを使用している場合でも、WebCenter SitesのACLを使用する必要があります。

WebCenter Sitesページを表示するには、ユーザーは必ず、少なくともBrowser ACLを持っている必要があります。ただし、追加のACLの制限が適用されるのは、wcs_properties.jsonファイル内のcc.securityプロパティ(「コア」カテゴリ)がtrueに設定されている場合のみです。cc.securityプロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』のコア・プロパティに関する項を参照してください。WebCenter Sitesシステムでのセキュリティの構成については、外部セキュリティの設定を参照してください。

ACLは、ユーザー・アカウント、データベース表、およびSiteCatalog表のページ・エントリ(つまり、WebCenter Sitesページ)の3つに割り当てられます。

注意:

配信システムでのユーザー管理もACLに基づきます。訪問者がそのサイトの領域にアクセスするには登録またはログインが必要となるようにオンライン・サイトを設計している場合は、配信システムで必要となるACLを作成し、それらを該当するデータベース表に割り当てます。

一般的には、サイト・デザイナがWebCenter SitesページへのACLの割当てを行います。『Oracle WebCenter Sitesでの開発』では、配信システムでのユーザー管理プロセスの設計方法について説明し、訪問者をサイトにログインさせたり、訪問者のIDを検証するページのコード・サンプルを提供しています。

ACLの詳細は、次の各トピックを参照してください。

- ユーザー・アカウントのACL

- データベース表のACL

- SiteCatalog表のページ・エントリのACL

- システムACL

- カスタムACL

6.2.1 ユーザー・アカウントのACL

各ユーザーには、少なくとも1つのACLが割り当てられる必要があります。ユーザーに割り当てられたACLにより、そのユーザーのWebCenter Sitesシステムへのアクセス権が定義されます。

ユーザーにユーザー・アカウントが1つとACLが1セットあれば、アクセスするサイトがいくつあっても、ユーザーは、サイトごとに異なるロール・セットを持つことができます。したがって、ユーザーには、サイト固有のすべてのロールを実行するために必要な権限を与えるために必要となるすべてのACLが割り当てられる必要があります。

たとえば、そのロールを持つユーザーがテンプレート・アセットを作成できるようにするロールを作成する場合、テンプレートの作成ではElementCatalog表にデータを書き込むため、そのロールを割り当てられたユーザーには、ElementEditor ACLも割り当てる必要があります。

Oracle WebCenter SitesとWebCenter Sitesコンテンツ・アプリケーションでは、いくつかのシステムACLを使用して、機能へのユーザー・アクセスを制御します。これらのACLの様々な組合せをユーザーに割り当てる必要があります。システムACLとその権限については、システム・デフォルトを参照してください。

6.2.2 データベース表のACL

表内のデータへのアクセスを制限するには、「管理」ツリー・ノード(「一般的な管理」ツリー配下)を介して使用できるWebCenter Sitesデータベース・フォームを介して、それにACLを割り当てます。これで、同じACLを持つユーザーのみが、この表のデータにアクセスできるようになります。

表に複数のACLを割り当てる場合、ユーザーが表にアクセスするためには、それらのACLのうち1つのみ必要です。ユーザーのその表に対するアクセス権(読取り、書込み、作成など)は、そのACLで定義されているものとなります。

WebCenter Sitesシステムのすべての表(およびWebCenter Sitesのコンテンツ・アプリケーションのいくつかの表)には、ACLの制限があります。SystemInfo表には、WebCenter Sitesデータベース内のすべての表とそれらに割り当てられているACLがリストされています。

注意:

Oracle WebCenter Sites Explorerアプリケーションを使用して、ACLをデータベース表に追加しないでください。「管理」ノードのWebCenter Sitesデータベース・オプションを使用してください。

WebCenter Sitesデータベースで外部の表を登録する場合を除き、たとえ変更が可能なACLを持つユーザー・アカウントであっても、SystemInfo表の情報は変更しないでください。

詳細は、次を参照してください。

- データベース表へのACLの割当てについては、カスタム表へのACLの割当てを参照してください

- 外部表の登録については、『Oracle WebCenter Sitesでの開発』の、外部表に関する項を参照してください。

6.2.3 SiteCatalog表のページ・エントリのACL

SiteCatalog表には、オンライン・サイト(つまり、配信システムから配信しているサイト)に表示されるページおよび、WebCenter Sitesのコンテンツ・アプリケーションに表示されるすべてのページのページ・エントリが含まれます。ページへのアクセスを制限するには、これにACLを割り当てます。

一般的には、サイト開発者が配信システムでのページ制限の構成方法を決定します。ただし、管理システムでユーザー・インタフェースをカスタマイズしている場合は、管理者がACLを使用してカスタム・ページへのアクセスを制限する必要が生じることがあります。

6.2.4 システムACL

新たにインストールしたWebCenter Sitesシステムには、システムACLのみが含まれています。WebCenter Sitesとともにパッケージ化されているサンプル・サイトに対して追加のACLは作成されていません。

6.2.5 カスタムACL

WebCenter Sitesでは、包括的なACLのセットを提供しているので、独自に作成する必要が生じることはほとんどありません。ただし、管理システムまたは配信システムでのユーザー管理ニーズによりACLを作成する必要が生じる場合もあります。例:

- サイトでユーザー登録が必要な場合、サイト訪問者のACLのセットを作成する必要が生じることがあります。

- 開発者が機能を作成し、これらを新しいタブに配置して管理システムをカスタマイズする場合、その新しい機能とタブをサポートするには、追加のACL (またはロール)を作成する必要が生じることがあります。

ACLの作成と適用は管理タスクですが、まずは、サイト・デザイナや開発者とともに、必要となるACLとそれらの適用方法を決定する必要があります。

6.3 ACLの使用

次の各トピックでは、ACLの作成、カスタムACLの編集と削除、データベース表およびWebCenter SitesページへのACLの適用、およびアクセス制限メッセージのカスタマイズの方法を示します。

注意:

LDAP統合オプションを使用している場合、ユーザーおよびサイト管理操作に対するシステム・レスポンスに注意してください。システム・レスポンスについては、LDAP統合Sitesシステムでのユーザー、サイト、およびロールを参照してください。

- ACLの作成

- カスタムACLの編集

- カスタムACLの削除

- カスタム表へのACLの割当て

- WebCenter SitesページへのACLの割当て

6.3.1 ACLの作成

注意:

ACLを作成する際、ACLがロールと釣り合うように、使用するロールを考慮してください。たとえば、ユーザーがテンプレート・アセットを作成できるようにするロールを作成する場合、テンプレートの作成ではElementCatalog表にデータを書き込むため、そのロールを割り当てられたユーザーには、ElementEditor ACLも割り当てる必要があります。

新規ACLを作成するには、次のようにします。

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ACL」をダブルクリックします。

「ACL」フォームが開きます。

2. 「ACLの追加」を選択し、「OK」をクリックします。「ACLを選択してください」フィールドの値は、この時点では関係ありません。

「ACLの追加」フォームが表示されます。

図6-1 「ACLの追加」フォーム

3. 「ACL名」フィールドに、一意の名前を入力します。

4. このACLに割り当てるアクセス権限を選択します。各権限については、権限を参照してください。

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

WebCenter SitesはACLを作成し、SystemACL表にこれを書き込みます。手順1で説明したフォームのドロップダウン・リストに、新しいACLが開きます。

6. LDAPを使用している場合、作成したACLに一致するグループを(LDAPサーバーで)作成します。グループを作成したら、適切なユーザーにこれを割り当てます。

6.3.2 カスタムACLの編集

注意:

システムACLは変更できません。これらのACLのリストは、システムACLとその権限を参照してください。

カスタムACLを編集するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ACL」をダブルクリックします。

「ACL」フォームが開きます。

2. 「ACLを選択してください」フィールドで、編集するACLを選択します。

3. 「ACLの修正」を選択し、「OK」をクリックします。

選択したACLがシステムACLの場合、アラートが表示されます。システムACLは変更しないでください。

4. 「ACLの修正」フォームで、「説明」と「アクセス権限」に変更を加えます。オプションの詳細は、権限を参照してください。

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

WebCenter Sitesは、変更をSystemACL表に書き込みます。

6.3.3 カスタムACLの削除

注意:

システムACLは削除できません。これらのACLのリストは、システムACLとその権限を参照してください。

カスタムACLを削除するには::

1. LDAPを使用している場合、削除するACLに対応するグループを(LDAPサーバーから)削除します。

2. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ACL」をダブルクリックします。

「ACL」フォームが開きます。

3. 「ACLを選択してください」フィールドで、削除するACLを選択します。

4. ドロップダウン・リストからACLを選択し、「OK」をクリックします。

警告メッセージが開きます。

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

ACLが削除されます。

6.3.4 カスタム表へのACLの割当て

管理者またはサイト・デザイナが表を作成する場合、管理者はACLをこれらの表に割り当てることによってこれらの表へのアクセスを制限する必要が生じることがあります。一般的には、新しい表を作成するときに、これらにACLを割り当てます。(詳細は、『Oracle WebCenter Sitesでの開発』の、ユーザー・アクセスの制御に関する項を参照してください。)

注意:

追加ACL (デフォルトで割り当てられている以外のACL)を、システムやコア製品の表に割り当てないでください。

ACLを既存の表に割り当てるには::

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「サイト・データベース」をダブルクリックします。

「サイト・データベース」フォームが開きます。

2. ACLを割り当てる表の名前を入力します。使用する表の名前がわからない場合は、次を行います。

- フィールドを空のままにします。WebCenter Sitesはデータベース内のすべての表のリストを返します。

- 名前の一部を入力し、最後にワイルドカード文字(%)を付けます。WebCenter Sitesは、条件に近い名前の表のリストを返します。

3. 「表の修正」を選択し、「OK」をクリックします。

4. 表のリストで、表を選択します。

「カタログの変更」フォームが開きます。

5. 「ACL」フィールドで、選択した表に割り当てるACLを選択します。複数のACLを選択するには、各ACLを[Ctrl]キーを押しながらクリックします。範囲内の最初と最後のACLを[Shift]キーを押しながらクリックすることにより、ACLの範囲を選択することもできます。

注意:

「ファイル・ストレージ・ディレクトリ」フィールドの値は変更しないでください。このフィールドの詳細は、『Oracle WebCenter Sitesでの開発』でdefdirプロパティを検索してください。

6. 「修正」をクリックします。

6.3.5 WebCenter SitesページへのACLの割当て

ACLは、ほとんど常に、Oracle WebCenter Sites Explorerツールを使用して設定します。ただし、管理者は、「作成」または「編集」フォームのフィールドを介して、SiteEntryまたはテンプレート・アセットに対して作成されたページ・エントリにACLを割り当てることができます。

SiteEntryアセットにACLを割り当てるには:

1. 変更するSiteEntryアセットを検索して開きます。

2. 「アクセス制御リスト」フィールドで、このアセットに割り当てるACLを選択します。

3. アセットを保存します。

新しいSiteEntryアセットを作成する場合にも、「アクセス制御リスト」フィールドを使用できます。SiteEntryアセットを作成する場合は、同じ方法でACLを割り当てます。

ACLをテンプレート・アセットに割り当てるには:

1. 変更するテンプレート・アセットを検索して開きます。

2. 「エレメント」セクションを選択します。

3. 「アクセス制御リスト」フィールドで、このアセットに割り当てるACLを選択します。

4. アセットを保存します。

新しいテンプレート・アセットを作成する場合にも、「アクセス制御リスト」フィールドを使用できます。テンプレート・アセットを作成する場合は、同じ方法でACLを割り当てます。

SiteEntryアセットまたはテンプレート・アセットに関連付けられていないページにACLを割り当てるには、Oracle WebCenter Sites Explorerツールを使用します。

6.4 ロール

ユーザー管理には、ロールの概念が含まれます。ロールは、次のようにしてユーザーを補完します。

- ロールは、WebCenter Sitesのインタフェース機能へのサイト固有のアクセスを管理します。対照的にACLは、基礎となるWebCenter Sites機能(データベース表)への個人のアクセスを記述しています。

- ロールは、業務の説明または、コンテンツ・プロバイダ、エディタ、サイト・デザイナ、管理者など、類似機能を持つ個々の役職を表します。

- 作成されたサイト数に関係なく、各WebCenter Sitesユーザーには1つのユーザー定義(アカウント)があります。ただし、ユーザーのロールはサイトごとに異なる場合があります。

- サイトに対してユーザーを有効にすると、そのユーザーは、そのサイトに対して実行するジョブのコンテキスト内で有効になります。

サイトに対してユーザーに割り当てられるロールにより、次のことが決定されます。

- そのサイトでユーザーが作成できるアセット。

- そのサイトでユーザーが検索できるアセット。

- ユーザーがサイトにログインしたときにツリーで開いているタブ。

- ユーザーがワークフロー・プロセスに加わることが可能かどうか、および可能な場合、それはワークフロー・プロセスのどのステップか。

- ワークフロー・プロセスを進める際に、ユーザーがアセットで実行できる機能と実行できない機能。

- ユーザーがワークフロー・プロセスを管理できるかどうか、あるいはそのサイトでワークフロー・グループを作成または変更できるかどうか。

システム・ロールの理解

いくつかのシステム・ロールはWebCenter Sitesによりインストールされます。WebCenter Sitesのコンテンツ・アプリケーションを機能させるには1つのロールが必要となり、WebCenter Sites管理者を機能させるには3つのロールが必要となります。詳細は、システム・ロールを参照してください。

カスタム・ロールの理解

ACLとは異なり、ロールは通常、サイトにおける全範囲のユーザーの役割に対応するために作成する必要があるオブジェクトです。ロールを作成するには、次のロールの使用の手順に従ってください。

サンプル・ロールの理解

1つ以上のサンプル・サイトをインストールした場合、そのサイトに含まれる多くのサンプル・ロールにアクセスできます。ロールによって、サンプル・サイトのユーザーは様々なツリー・タブへのアクセスが許可されます。独自のサイトでアクセス制御を構成する方法の例として、サンプル・ロールを使用できます。

6.5 ロールの使用

次の各トピックでは、ロールを作成、編集、削除する方法を示します。

注意:

LDAPを使用している場合、ユーザーおよびサイト管理操作に対するシステム・レスポンスに注意してください。システム・レスポンスについては、LDAP統合Sitesシステムでのユーザー、サイト、およびロールを参照してください。

- Adminインタフェースからのロールの作成

- Adminインタフェースからのロールの編集

- Adminインタフェースでのロールの削除

6.5.1 Adminインタフェースからのロールの作成

新しいロールを作成するには:

1. 「一般的な管理」ツリーで、「管理」を開き、続いて、「ユーザー・アクセス管理」、「ロール」の順に開き、続いて「新規追加」をダブルクリックします。

「新規ロールの追加」フォームが開きます。

2. 「名前」フィールドに、最大32文字の一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)。さらに、「名前」フィールドの末尾にバックスラッシュ(\)は使用できません。

3. 「説明」フィールドに、255文字以下の短い説明を入力します。

4. 「新規ロールの追加」をクリックします。

5. 必要に応じて、デフォルトのツリー・タブ(「ワークフロー」、「ブックマーク」、「サイト管理者」、「管理」、「サイト・プラン」および「アクティブ・リスト」)にロールを追加します。手順は、ツリーとノードの編集を参照してください。

6.5.2 Adminインタフェースからのロールの編集

ロールを作成した後にそのロールの名前を変更することはできませんが、ロールの説明は編集できます。

ロールの説明を編集するには::

1. 「一般的な管理」ツリーで、「管理」を開き、続いて「ユーザー・アクセス管理」を開き、続いて「ロール」をダブルクリックします。

すべてのロールのリストがメイン・ウィンドウに開きます。

2. ロールのリストで、編集するロールに移動し、その「編集」アイコンをクリックします。

3. 「ロールの編集」フォームで変更を行い、「保存」をクリックします。

6.5.3 Adminインタフェースでのロールの削除

注意:

システムのデフォルト・ロール、GeneralAdmin、SiteAdmin、WorkflowAdmin、AdvancedUserおよびWebCenter Sites Userは削除しないでください。

ロールを削除するには:

1. 「一般的な管理」ツリーで、「管理」を開き、続いて「ユーザー・アクセス管理」を開き、続いて「ロール」をダブルクリックします。

すべてのロールのリストがメイン・ウィンドウに開きます。

2. ロールのリストで、削除するロールに移動し、その「削除」(ゴミ箱)アイコンをクリックします。

確認メッセージが表示されます。

3. 「ロールの削除」をクリックします。

ロールが削除されます。

第III部 ユーザー・インタフェースとアセットの管理

次の各トピックでは、WebCenter Sitesのユーザー・インタフェース、ユーザーおよびその他のサイト・コンポーネントの管理について説明します。

- ユーザー・インタフェースの構成

- ユーザーの作成および認可

- コンテンツ管理サイト・コンポーネントへのアクセスの管理

- 管理者インタフェースの使用

- Webエクスペリエンス管理フレームワークの使用

- Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理

7 ユーザー・インタフェースの構成

コンテンツ・プロバイダが使用可能になるために構成される必要があるWebCenter Sitesユーザー・インタフェース機能がいくつかあります。これらの機能のいくつかは、ContributorインタフェースのWebモードなどのWebCenter Sitesインタフェースの代替インタフェースです。その他は、WebCenter Sitesインタフェース(ロケール設定)、プレビュー機能の動作、およびContributorインタフェースの使用時に使用するキーボード・コマンドを変更します。

次の各トピックでは、ユーザー・インタフェースを構成する手順を説明します。

- WebCenter Sitesインタフェースのロケールの設定

- Webモードの使用

- プレビューに対する個別のブラウザ・セッションの維持

- Contributorインタフェースのキーボード・ショートカットの変更

- ユーザー・インタフェースのRight-to-Left (RTL)方向への設定

7.1 WebCenter Sitesインタフェースのロケールの設定

WebCenter Sitesをインストールすると、システムのデフォルト・ロケールとして英語が設定されます。管理者は、WebCenter Sitesのデフォルト・ロケールを構成できます。

ロケールの設定に使用するオプションおよびプロパティはいくつかあります。

- 「管理」ノード(「一般的な管理」ツリー配下)の「ロケール」アイテムで、WebCenter Sitesインタフェースのデフォルト・ロケールを設定します。個々のユーザーは、プリファレンスの設定により、デフォルトをオーバーライドすることも、別のロケールがあればそれを使用することも可能です。

- wcs_properties.jsonファイルのcs.emailcharsetプロパティおよびcs.emailcontenttypeプロパティ(「コア」カテゴリ)によって、ワークフロー・システムが送信する電子メール・メッセージで使用する文字セットが決定されます。これらのプロパティは通常インストール中に設定され、コンテンツ・プロバイダが選択できるすべてのロケールで適切に文字を表すことができる文字セットに設定される必要があります。

- システムがUTF-8の文字セットを使用し、かつサーバーへのミラーリングのパブリッシュ配信タイプが使用されている場合、wcs_properties.jsonファイルのcs.mirrorrowsperpostプロパティ(「パブリッシュ」カテゴリ)に、4以下の値を設定する必要があります。

次の各トピックでは、WebCenter Sitesインタフェースのロケールの設定について説明します。

- WebCenter Sitesユーザーのシステムのデフォルト・ロケールの使用

- システムのロケール・プロパティ

- 単一言語の制限

- ロケールとアセット・タイプ

- ロケールと記事アセット・タイプ

7.1.1 WebCenter Sitesユーザーのシステムのデフォルト・ロケールの使用

言語パックがインストールされるとき、インストーラは、言語パックのロケールの言語と国コードを、LocaleMapデータベース表に書き込みます。たとえば、ブラジルのポルトガル語は、pt_BRとなります。LocaleMap表に表示されるロケールが複数ある場合、管理者がデフォルトのロケールを指定する必要があります。これは次の手順で実行できます。

- 新しいグローバル・デフォルト言語を設定します。WebCenter Sitesの「ローカル・マネージャ」を使用して、WebCenter Sitesシステムの現在のデフォルト言語を別の言語パックに置き換えることができます。この言語は、WebCenter Sitesシステムでグローバルに新しいデフォルト言語になります。個々のユーザーに異なるデフォルト言語を設定するオプションもありますが、「ロケール・マネージャ」からは使用できません。

- ユーザーごとに新しいデフォルト言語を設定します。このオプションを使用すると、個々のユーザーのデフォルト言語として、「ロケール・マネージャ」で選択したグローバルなデフォルト言語とは別の言語を選択できます。ユーザー・ロケールの設定方法の詳細は、ユーザー・プロファイルとユーザー属性の使用を参照してください。

WebCenter Sitesは、汎用的なセッション変数localeによって個々のユーザーが使用する言語を決定します。この変数には、ログインしているユーザーに関連する言語と国コードが格納されています。

ユーザーがWebCenter Sitesにログインすると、WebCenter Sitesは、次のようにlocale変数の値を取得します。

- ユーザー・プロファイルにlocaleユーザー属性の値が格納されている場合、WebCenter Sitesはこの値を取得し、使用します。

- ユーザー・プロファイルにプリファレンスが指定されていない場合、WebCenter Sitesは、ユーザーのブラウザのロケール設定とLocaleMap表のロケールとの一致を試みます。

- ユーザー・プロファイルにプリファレンスが設定されておらず、かつWebCenter Sitesがユーザーのブラウザのロケールを一致させることができない場合、WebCenter Sitesは、システムに設定されているデフォルト・ロケールを使用します。

- ユーザー・プロファイルにlocaleユーザー属性の値があるが、ブラウザにその言語をサポートするために必要なファイルとスタイルシートがない場合、WebCenter Sitesはシステムに設定されているデフォルト・ロケールを使用します。ロケールのファイルとスタイルシートがCSSフォルダ(/Xcelerate/data/CSS)の下のアプリケーション・サーバー・ディレクトリにあることを確認します。

- システムに設定されたデフォルト・ロケールが、デフォルト・ロケールをサポートするために必要なファイルとスタイルシートを持たない場合、管理ページはスタイルシートと書式なしで表示されます。デフォルト・ロケールのファイルとスタイルシートがCSSフォルダ(/Xcelerate/data/CSS)の下のアプリケーション・サーバー・ディレクトリにあることを確認します。

注意:

サイトを選択して、そのサイトから新しいシステム・デフォルト言語を設定する場合、この言語は自動的に、WebCenter Sitesシステム上のすべてのサイトのグローバルなデフォルト言語として設定されます。

システムのデフォルト・ロケールを設定するには::

1. 「一般的な管理」ツリーで、「管理」を開き、続いて「ロケール」をダブルクリックします。

「ロケール・マネージャ」フォームが表示されます。

図7-1 「ロケール・マネージャ」フォーム

2. ロケールの横にある「編集」アイコンをクリックします。

ラジオ・ボタンがフォームの「デフォルト」列に表示されます。

3. ロケールの横にある「デフォルト」ラジオ・ボタンを選択します。

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

次回ユーザーがWebCenter Sitesにログインしたときは、システムは新しいデフォルト言語で表示されます。

注意:

個々のユーザーの言語設定(「ユーザー・プロファイル」オプションで設定)は、WebCenter Sitesシステムの言語設定(「ロケール・マネージャ」で設定)より優先されます。ユーザー・ロケールの設定方法の詳細は、ユーザー・プロファイルとユーザー属性の使用を参照してください。

7.1.2 システムのロケール・プロパティ

表7-1のプロパティは、言語パックをWebCenter Sitesにインストールする際に構成されているはずです。これは、トラブルシューティングのために記載されたリストです。たとえば、ワークフローの電子メールで異常な文字が表示されている場合、この電子メールのプロパティが適切に設定されなかった可能性があります。

Adminインタフェースのプロパティ管理ツールにアクセスし、それを使用してプロパティ値を確認または変更する方法の詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』の、プロパティ管理ツールの使用に関する項を参照してください。

表7-1 システムのロケール・プロパティ

プロパティ

カテゴリ

説明

cs.contenttype

コア

すべてのWebCenter Sitesページとその他のHTTP対話(Oracle WebCenter Sites Explorer、CatalogMoverなど)用に、HTTPヘッダーの文字セットを決定します。この値はデフォルトでtext/html; charset=UTF-8に設定されています。この値には、WebCenter Sitesシステムが配信しているサイトに適した値を設定する必要があります。

cs.emailcharset

コア

WebCenter Sitesによって送信される電子メール・メッセージの件名の行で使用される文字セットを決定します。(通常、これらはワークフローの電子メールです。)

cs.emailcontenttype

コア

WebCenter Sitesによって送信される電子メール・メッセージの本文で使用される文字セットを決定します。

cs.mirrorrowsperpost

パブリッシュ

ミラー・パブリッシュ・セッションが実行されている間に、各HTTPのPOSTでミラーリングが可能な表の行数を指定します。UTF-8を使用していて、データベースが非ASCII文字を処理する場合、この値を4以下に設定する必要があります。

xcelerate.charset

コア

すべてのWebCenter Sitesのページに使用されるHTTPヘッダーの文字セットを決定します。この値はUTF-8に設定する必要があります。

7.1.3 単一言語の制限

多言語管理システムを構成できますが、ユーザー・インタフェースの一部は1つの言語でのみ表示できます。

たとえば、WebCenter Sitesデータベースの表や列の名前、およびカテゴリやソース・コードなどの個々のアイテムは、1つの名前のみを持つことができます。個々のWebCenter Sitesフォーム上のテキストのほとんどはWebCenter Sitesシステムにインストールした任意の言語で表示できますが、フィールド名やアセット・タイプ名などのアイテムは1つの言語でのみ表示できます。

1つの名前のみを持つことができるWebCenter Sitesのアイテムを次にリストします。これらのアイテムは、1つの言語でのみ表示できます。

- アセット・タイプ名

- フィールド名

- アセット名

- カテゴリ

- ソース・コード

- ツリー・ノード名

- サイト名

- ワークフローの構成要素の名前(アクション、電子メール・オブジェクト、条件、状態、ステップ、プロセス)

- ロール名

- スタート・メニュー・アイテム(「検索」と「新規」の両方)

複数の言語を提供するシステムでは、大部分のコンテンツ・プロバイダが使用する言語を判断してから、その言語を使用してサイト、タブ、アセット・タイプなどの名前を指定する必要があります。

7.1.4 ロケールとアセット・タイプ

サイト開発者がアセット・タイプ(ベーシックかフレックスいずれかの)を作成するとき、WebCenter Sitesシステムで利用できるようにしたどの言語でもアセット・タイプのフィールド名を指定できます。ただし、WebCenter Sitesがデフォルトですべてのアセット・タイプに作成するコアな列やフィールドがいくつかあります。

- id

- name

- description

- status

- createdby

- createddate

- updatedby

- updateddate

- startdate

- enddate

- subtype

- filename

- path

- template

- category

これらの列名は、デフォルトでは英語で作成されます。これらがインタフェースのフィールドとしてWebCenter Sitesで表示される場合は、システムのデフォルト言語として設定されている言語が使用されます。

注意:

SQL Serverを使用している場合、大文字/小文字の区別のみが異なるカテゴリ名を付けることはできません。MyCategoryという名前のカテゴリと、mycategoryという名前の別のカテゴリを持つことはできません。SQL Serverでは、属性カテゴリの大文字/小文字は区別されません。

アセット・タイプのデフォルト列の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

7.1.5 ロケールと記事アセット・タイプ

サイト開発者がArticleという名前のサンプル・サイトのアセット・タイプを使用することを決定した場合、futuretense_xcel.iniファイルにあるxcelerate.body.lengthプロパティの値も変更する必要があります。このプロパティによって、Article表のurlbody列に格納される文字数が決定されます。

urlbodyはURLの列であるため、ここに入力されるデータは、実際にはWebCenter Sitesデータベース以外のファイルとして格納されます。しかし、始めからn個(nはxcelerate.body.lengthプロパティで指定される値に等しい)の文字もまた、管理者のインタフェースの検索機能で記事アセットの本文テキストを検索できるように、urlbody列に格納されます。

この列に非ASCIIテキストが格納されている場合、このプロパティの値を500に設定する必要があります。

7.2 Webモードの使用

WebモードはWebCenter Sitesの機能であり、これを使用すると、制限されたロールを実行する使用頻度の低いユーザーが、アセットのレンダリングされた(プレビュー)バージョンから直接コンテンツを検索、編集および送信できます。

この機能を有効にするには通常、次の3つの手順が必要です。

- 管理者は、WebCenter Sites管理システム上で、Adminインタフェースのプロパティ管理ツールを使用して、wcs_properties.jsonファイルのxcelerate.enableinsiteプロパティをtrueに設定します。

- 開発者は、コンテンツ・プロバイダがこのように編集できるようにするフィールドに対して、Webモード機能を起動するテンプレートをコード化します。同じテンプレートでも、xcelerate.enableinsiteがWebCenter Sites配信システムでfalseに設定されていると、そのシステム上ではWebモードが表示されないことに注意してください。

- 適切なURLを決定し、Webモードを使用する必要があるWebCenter Sitesユーザーがこれを使用できるようにします。

Webモードを有効にするには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「名前」フィールドに、xcelerate.enableinsiteと入力します。

3. 「検索」をクリックします。

4. プロパティの名前を選択します。「値」フィールドで、値をtrueに設定します。

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

Webモードとプレビューで使用されるサーブレットとホストの名前を構成するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「カテゴリ」ドロップダウン・メニューで、「UI」を選択します。

3. 「検索」をクリックします。

4. 以下のいずれか、または両方を実行します。

a. xcelerate.previewhostを選択します。「値」フィールドで、値をhttp://<server>:<port>/servlet/に設定し、続いて「保存」をクリックします。

b. xcelerate.previewservletを選択します。「値」フィールドで、値をContentServerからSatelliteに変更し、続いて「保存」をクリックします。例:
コンテンツ・プロバイダがWebCenter Sitesのログインに使用するURLにポート番号を含める必要がない場合、ポート番号はxcelerate.previewhost プロパティの値に含めます。

コンテンツ・プロバイダがポート番号を含める必要がある場合、そのプロパティに異なるポート番号を指定します。Webサーバーのポート番号またはWebサーバーにリダイレクトを要求するポート番号のいずれかを使用します。

別名を作成し、xcelerate.previewhostプロパティにのみ、これを使用します。

xcelerate.previewservletプロパティを使用して、WebCenter Sitesサーブレットではなく、Satellite Serverサーブレットを指定します。

7.3 プレビューに対する個別のブラウザ・セッションの維持

WebCenter Sites配信システムと管理システムにログインする場合に、ユーザーが異なるユーザー名を使用する場合、プレビューには別々のブラウザ・セッションが必要です。プレビューに対して新しい個別のブラウザ・セッションがない場合は、プレビュー・セッションが開始すると、WebCenter Sitesのセッションは終了します。これは、コンテンツ・プロバイダが未保存の作業を失う可能性があることを意味します。

プレビュー・セッションによってWebCenter Sitesセッションが終了しないようにするために、次を実行することが可能です。

- コンテンツ・プロバイダがWebCenter Sitesユーザーのアカウントでプレビューしているサイトにログインするように、サイト・デザイナがオンライン・サイトを構成するようにします。

- Webサーバーが、WebCenter Sitesウィンドウで、現行セッションを閉じずに、新しいブラウザ・セッションをプレビュー・ウィンドウに対して開くように、WebCenter Sites管理システムを構成します。

Webサーバーが新しいブラウザ・セッションをプレビューされるアセットに対して開くようにWebCenter Sites管理システムを構成するには、wcs_properties.jsonファイルのプロパティ(xcelerate.previewhostおよびxcelerate.previewservlet)を構成します。これらのプロパティを使用して、WebCenter Sites管理システムのURLを指定しますが、このURLは、コンテンツ・プロバイダが管理システムへのログインに使用するURLとは、なんらかの点で異なっている必要があります。例:

- コンテンツ・プロバイダがWebCenter Sitesのログインに使用するURLにポート番号を含める必要がない場合、ポート番号はxcelerate.previewhost プロパティの値に含めます。

- コンテンツ・プロバイダがポート番号を含める必要がある場合、プロパティに対して異なるポート番号(Webサーバーのポート番号またはWebサーバーにリダイレクトを要求するポート番号)を指定します。

- 別名を作成し、xcelerate.previewhostプロパティにのみ、これを使用します。

- xcelerate.previewservletプロパティを使用して、WebCenter Sitesサーブレットではなく、Satellite Serverサーブレットを指定します。

Adminインタフェースで、プロパティ管理ツールを開いて、「カテゴリ」ドロップダウン・メニューから「UI」を選択し、「検索」をクリックして、次のいずれかまたは両方を実行します。

- 大部分のアプリケーション・サーバーの場合(Sun JES Application Serverなど)、xcelerate.previewhostプロパティを次のとおりに設定します。

http://<server>:<port>/servlet/

- xcelerate.previewservletプロパティの値をContentServerからSatelliteに変更します。

プロパティ管理ツールを使用したプロパティ地の設定手順の詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

7.4 Contributorインタフェースのキーボード・ショートカットの変更

次の各トピックでは、Contributorインタフェースのデフォルト・キーボード・ショートカットと、これらのショートカットの再構成手順について説明します。

- デフォルト・キーボード・ショートカット

- Contributorインタフェースのキーボード・ショートカットのカスタマイズ

7.4.1 デフォルト・キーボード・ショートカット

Contributorインタフェースを使用すると、様々なキーボード・ショートカットを使用することでコンテンツ管理プロセスを迅速化し、全面的にアクセス可能なインタフェースを提供できます。Contributorインタフェースの現在のキーボード・ショートカットを表示するには、Contributorインタフェースから[Ctrl] + [Alt] + [L]を押して、ブラウザのWebコンソールで現在のキーボード・ショートカットを記録します。

デフォルト・キーボード・ショートカットのリストは、『Oracle WebCenter Sitesの使用』の、キーボード・ショートカットに関する項を参照してください。

7.4.2 Contributorインタフェースのキーボード・ショートカットのカスタマイズ

Contributorインタフェースのデフォルト・キーボード・ショートカットをカスタマイズするには、次の手順を完了します。

1. <shared-install-location>\elements\UI\Config\GlobalHtml.jspファイルを編集用に開きます。

2. shortcutsプロパティを持つconfig JavaScriptオブジェクトを、適切なJSON書式(config.properties)でGlobalHtml.jspファイルに追加します。configオブジェクトで、再構成する各キーボード・ショートカットごとに1行追加し、そのショートカットに関連付けるキーを、次の構文で指定します。

config.shortcuts = {
"ShortCutName" [Keystrokes]
"ShortCutName2" [Keystrokes]
}

キー・コマンドを有効にするには、1つ以上の修飾キーまたは特殊キーを使用する必要があります。

- 有効な修飾キー:

- ALT

- CTRL

- SHIFT

- META

- 有効な特殊キー:

- ALT

- BACKSPACE

- CAPS_LOCK

- CLEAR

- CTRL

- DELETE

- DOWN_ARROW

- DOWB_DPAD

- END

- ENTER

- ESCAPE

- F1からF15

- HELP

- HOME

- INSERT

- LEFT_ARROW

- LEFT_DPAD

- LEFT_WINDOW

- META

- NUMPAD_0からNUMPAD_9

- NUMPAD_DIVIDE

- NUMPAD_ENTER

- NUMPAD_MINUS

- NUMPAD_MULTIPLY

- NUMPAD_PERIOD

- NUMPAD_PLUS

- NUM_LOCK

- PAGE_DOWN

- PAGE_UP

- PAUSE

- RIGHT_ARROW

- RIGHT_DPAD

- RIGHT_WINDOW

- SCROLL_LOCK

- SELECT

- SHIFT

- SPACE

- TAB

- UP_ARROW

- UP_DPAD

たとえば、ブラウザのWebコンソール(logShortcutConfiguration)に現在のショートカット構成が表示されるようにキーボード・ショートカットを変更するには、GlobalHtml.jspファイルに次を追加します。

config.shortcuts = {
"logShortcutConfiguration": ["CTRL", "ALT", "SHIFT", "L"]
}

3. GlobalHtml.jspファイルを保存して閉じます。

4. サーバーを再起動して、変更を有効にします。

7.5 ユーザー・インタフェースのRight-to-Left (RTL)方向への設定

Right-to-Left (RTL)サポートは、ユーザーのロケールを「アラビア語」に構成した場合の、ナビゲーション・ペイン、検索結果およびアセット・タブの位置など、Contributorインタフェースの方向を構成します。

RTLサポートを実装するには:

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「ユーザー・アクセス管理」を開き、続いて「ユーザー・プロファイル」をダブルクリックします。
「ユーザー・プロファイル管理」フォームが開きます。

2. フォームで、ロケールを「アラビア語」に変更するユーザーのユーザー名を入力して、「選択」をクリックします。
「ユーザー・プロファイル」リストが開きます。

3. ユーザー名を選択します。
「ユーザー・プロファイル管理」フォームが開きます。

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

5. 「ローカルのプリファレンス」フィールドで、「ロケール設定」ドロップダウン・リストから「アラビア語(サウジアラビア)」を選択します。

図7-2 ユーザー・プロファイルの編集: アラビア語の選択

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

7. 変更をすべてのWebCenter Sites全体に反映するには、WebCenter Sitesを再起動します。

8 ユーザーの作成および認可

次の各トピックでは、WEM Adminインタフェースでユーザーを作成し、サイトおよびそのサイトで使用可能なアプリケーションを管理するためにユーザーを認可するための情報を説明します。

- ユーザーの作成

- アプリケーション使用のユーザーへの認可

- 事前定義済ユーザーの認可

- アプリケーション登録の開発者への認可

- 使用できるアプリケーションに関する開発者への確認

8.1 ユーザーの作成

作成できるユーザーのタイプには一般管理者、サイト管理者およびコントリビュータがあります。

注意:

ユーザーを作成できるのは一般管理者のみです。事前定義済ユーザーの詳細は、事前定義済ユーザーの認可を参照してください。

ユーザーを作成するには::

1. WebCenter Sitesのインストール・プロセスで使用した一般管理者資格証明を使用してWEM Adminインタフェースにログインします。

2. Adminメニュー・バーで、「ユーザー」をクリックします。
「ユーザー」フォームが開きます。

3. 「ユーザー」フォームで、「ユーザーの追加」をクリックします。
「ユーザーの追加」フォームが開きます。

図8-1 「ユーザーの追加」フォーム

次の各フィールドに値を入力します。

- イメージ・プレビュー: (オプション)「参照」ボタンを使用して、新しいユーザーに写真を関連付けます。

- 名前: ユーザーがログインするときに使用する名前を入力します。

- 電子メール: (オプション)有効な一意の電子メール・アドレスを入力します。

- ロケール: (オプション)ユーザーの言語設定を選択します。言語設定を指定しない場合、WEMフレームワークは、ブラウザに設定されているデフォルト・ロケールを使用します。

- タイムゾーン: (オプション)ユーザーのタイムゾーン設定をメニューから選択します。タイムゾーン設定を指定しない場合、ブラウザからユーザーのタイムゾーンが自動的に検出されます。

- ACL: ACLは、ユーザーのデータベース表に対するアクセスを制限します。すべてのユーザーに、Browser、ElementReader、PageReader、UserReaderおよびxceleditorが必要です。一般管理者とサイト管理者にはxceladminも必要です。一般管理者にはさらに、TableEditorとUserEditorも必要です(Oracle WebCenter Sites: Engageを使用する場合はVisitorAdminも必要)。

- グループ: グループは、RESTに対するアクセスを提供します。これらはアプリケーションのリソースへのアクセスの制御に使用されます。

- 一般ユーザーを作成している場合は、とりあえずこの手順を省略します。ユーザーのグループへの割当ては、認可プロセス(アプリケーション使用のユーザーへの認可)の一環として手順4で実行します。

- 一般管理者を作成している場合は、ユーザーをRestAdminグループ(WebCenter Sites Adminインタフェースで構成されるデフォルト・グループ)に割り当てます。このグループにはRESTリソースに対する無制限の権限があります。

- サイト管理者を作成している場合は、ユーザーをSiteAdmin_AdminSiteグループ(WebCenter Sites Adminインタフェースで構成されるデフォルト・グループ)に割り当てます。

注意:

グループのセキュリティ構成は、WebCenter Sites Adminインタフェースで実行できます。RESTセキュリティ構成の表示を参照してください。

- 新規パスワード: パスワードを6文字以上で入力します。

- 確認パスワード: 上で入力したパスワードを再入力します。

4. 「保存して閉じる」をクリックします。
この時点で、ユーザーはログインできますが、どのサイトにもアクセスできないことを示すメッセージが表示されます。

ユーザーを管理者または一般ユーザーとして有効にするには::

1. ユーザーをサイトに割り当てます。

a. 「ユーザー」フォームで、ユーザーの上にカーソルを移動して「ユーザーの管理」を選択し、「サイトへの割当て」をクリックします。

- 一般管理者を作成している場合は、ユーザーをAdminSiteに割り当てます。

- サイト管理者または一般ユーザーを作成している場合は、ユーザーをAdminSite以外のサイトに割り当てます。

b. 割り当てたサイトでロールをユーザーに割り当てます。

- 一般管理者を作成している場合は、GeneralAdminロールを割り当てます。このロールは、システムへのアクセス権をユーザーに付与します。
これで、ユーザーは、AdminSiteでWEM Adminアプリケーションを使用できます。

- サイト管理者を作成している場合は、SiteAdminロールを割り当てます。
AdminSite以外のサイトでSiteAdminロールを割り当てられたユーザーは、暗黙的にAdminSiteに割り当てられ、AdminSiteのWEM Adminアプリケーションにアクセスできるようになります。ユーザーがWEM Adminアプリケーションでアクセスできるのは「サイト」フォームのみです。この画面には、ユーザーにSiteAdminロールが割り当てられているサイトのみがリストされます。

- 一般ユーザーを作成している場合は、ユーザーにGeneralAdminでもSiteAdminでもないロールを割り当てます。
これでユーザーは(メニューにリストされている)サイトにアクセスできるようになりますが、ユーザーに割り当てられているロールでそのサイトのアプリケーションへのアクセスが認可されない場合は、メニューの下にアプリケーション・アイコンは表示されません。

2. アプリケーションの使用をユーザーに認可するには、次のアプリケーション使用のユーザーへの認可に進みます。

8.2 アプリケーション使用のユーザーへの認可

ユーザーは、Oracle WebCenter Sites: Contributorインタフェースなどのアプリケーションを使用するために認可を必要とします。

ユーザーを認可するには::

1. サイトを選択または作成します。

2. アプリケーションをサイトに割り当てます。

3. その同じサイトにユーザーを割り当て、ユーザーとアプリケーションを結合します。

4. グループにユーザーを割り当て、RESTアプリケーションのリソースに対するユーザー権限を付与します。

注意:

一般管理者とサイト管理者はどちらもユーザーを認可できます。

特定のサイト上のアプリケーションへのアクセスが必要な場合は、そのサイト上のアプリケーションへのアクセスを自身に認可します。

以降の手順では、複数のアプリケーションおよび複数のユーザーを選択できます。わかりやすくするために、手順では1つのアプリケーションおよび1人のユーザーを指定します。

この手順では、認可対象のユーザーは、事前定義済ユーザーが指定されていないアプリケーションを使用するものと想定しています。事前定義済ユーザーの詳細は、事前定義済ユーザーの認可を参照してください。

ユーザーを認可するには::

1. サイトを選択または作成します。
WEM AdminインタフェースのAdminメニュー・バーで「サイト」をクリックします。

WEM Adminの「サイト」フォームが開きます。

一般管理者は、サイトを選択するか、(「サイトの追加」をクリックして)サイトを追加できます。サイト管理者はサイトを選択できます。「サイト」フォームには、管理することを許可されているサイトのみがリストされます。

2. アプリケーションをサイトに割り当てます。

a. 「サイト」フォームで、サイト名の上にマウスを移動して「サイト・アプリケーションの管理」をクリックします。

b. 「アプリケーションの割当て」をクリックします。
「サイトのアプリケーションの選択」フォームが表示されます。

注意:

WEMフレームワークにアプリケーションが登録されていない場合、「アプリケーションの割当て」ボタンは淡色で表示されます。

図8-2 「サイトのアプリケーションの選択」フォーム

c. サイトに割り当てるアプリケーションを選択し、「選択済」リストに移動します。
アプリケーションを検索するには、その名前を「フィルタ・リスト」フィールドに入力します。結果は、「選択可能」リストに表示されます。

d. 「続行」をクリックして、ロールをアプリケーションに割り当てます。

e. 「アプリケーションへのロールの割当て」フォームで、アプリケーションに割り当てるロールを選択し、「選択済」リストに移動します。

注意:

アプリケーションがAdminインタフェースである場合は、AdvancedUserロールを割り当てます。アプリケーションがContributorインタフェースである場合は、SitesUserロールを割り当てます。

割り当てているロールを書き留めます。このサイトで、これらのロールのうち少なくとも1つをユーザーに割り当てて、ユーザーにこのアプリケーションへのアクセス権を付与する必要があります。

f. 「保存して閉じる」をクリックします。

3. ユーザーをサイトに割り当てます。

a. Adminメニュー・バーで、「サイト」をクリックします。

b. 新しいサイト名を選択し、「サイト・ユーザーの管理」をクリックします。

c. 「ユーザーの割当て」をクリックします。
「サイトのユーザーの選択」ダイアログが開きます。

図8-3 ユーザーの割当てフォーム

d. 「サイトのユーザーの選択」フォームでサイトに割り当てるユーザーを選択し、「選択済」リスト・ボックスに移動します。

e. 「続行」をクリックして、ロールをユーザーに割り当てます。

f. ユーザーをアプリケーションに結合します(アプリケーション・レベルの認可)。
「ユーザーへのロールの割当て」フォームで、手順eでアプリケーションに割り当てたロールのうち少なくとも1つをユーザーに割り当てます。

注意:

すべてのアプリケーションの場合: サイトのユーザーおよびアプリケーションでロールを共有すると、そのサイトの当該アプリケーションへのアクセス権がユーザーに付与されます。アプリケーションがAdminインタフェースである場合は、ユーザーにAdvancedUserロールを割り当てる必要があります。アプリケーションがContributorインタフェースである場合は、ユーザーにSitesUserロールを割り当てる必要があります。

WebCenter Sites以外のアプリケーションの場合: アプリケーションにロールによって保護されているインタフェース機能(「編集」など)がある場合、機能のロール(仕様はアプリケーション開発者から入手可能)のうち少なくとも1つをユーザーに割り当てることによって、各機能に対するアクセスを構成します。それによって、ユーザーがアプリケーション・レベルで完全に認可されます。ただし、ユーザーはRESTレベルで認可されないかぎり、アプリケーションのリソースを使用することはできません。「保存して閉じる」をクリックして、手順5に進みます。

WebCenter Sitesのアプリケーションおよびユーザーの場合: WebCenter Sitesには、ロールによって保護されているインタフェース機能があります。WebCenter Sitesで直接構成されているユーザーの場合、そのロールはWEMフレームワークで維持されます。それらは、WEM Adminインタフェースでサイト別にリストされます。たとえば、ユーザーにContributorインタフェースからアセットをパブリッシュする権限を付与するには、そのユーザーに、SitesUserロールに加えて、パブリッシャ・ロールを割り当てる必要があります(詳細は、ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可を参照してください)。また、application RESTサービスによって、RESTレベルでWebCenter Sitesユーザーが認可されます(管理者が手順4を実行する必要がなくなります)。「保存して閉じる」をクリックして、手順5に進みます。

4. ユーザーをRESTレベルで認可します。
この手順では、(手順2で選択した)アプリケーションで使用されているリソースを操作する権限をユーザーに付与します。

注意:

前述したように、WEMフレームワークからWebCenter SitesアプリケーションへのアクセスをWebCenter Sites専用ユーザーに認可している場合は、この手順を省略します。手順5に進みます。

a. Adminメニュー・バーで、「ユーザー」をクリックします。

b. 「ユーザー」フォームで、認可するユーザーを選択して「編集」をクリックします。

c. 「ユーザーの編集」フォームで、ユーザーのグループを選択します。各グループは、特定のオブジェクト(アセット・タイプ、アセットなど)を操作する特定の権限で構成されています。オブジェクトはアプリケーションで使用されるRESTリソースにマップされます。リストされているRESTグループの権限を決定するか、またはグループを作成してその権限を構成するには、アプリケーション・リソースへのアクセスのユーザーへの認可を参照してください。

d. 「保存して閉じる」をクリックします。

5. ユーザーが新しいアプリケーションにアクセスできることを検証します。
ログイン・ダイアログの「サイト」メニューに新しいサイトがリストされ、メニューの下にアプリケーション・アイコンが表示されます。

新しいサイトは、ログイン・ユーザーの名前の横にあるメニューにもリストされます。アプリケーション・アイコンは左上隅に開きます。

6. まだRESTに対する権限をユーザーに付与していない場合は、RESTセキュリティの使用の手順を完了してください。

8.3 事前定義済ユーザーの認可

開発者は、認可プロセスの管理を単純化するために、アプリケーションで事前定義済ユーザーを指定します。各ユーザーを個別にRESTレベルで認可するかわりに、事前定義済ユーザーを認可します。アプリケーションへのアクセス権を持つログイン・ユーザーは、事前定義済ユーザーがRESTグループに属することを通じて、アプリケーションのリソースにアクセスできます。

アプリケーションに事前定義済ユーザーが構成されている場合は、WEM Adminアプリケーションで次の手順を完了して、事前定義済ユーザーを使用可能かつ認可済にします。

1. 事前定義済ユーザーを作成します。次の情報を準備します。

- ログイン名: この名前は、アプリケーションで指定されている事前定義済ユーザーの名前と正確に一致する必要があります。

- パスワード: このパスワードは、アプリケーションで指定されている事前定義済ユーザーのパスワードと正確に一致する必要があります。

- ACL: ACLは、データベース表に対するアクセスを制限します。事前定義済ユーザーに、アプリケーションにアクセスするログイン済ユーザーのACLを割り当てる必要があります。すべてのユーザーに、Browser、ElementReader、PageReader、UserReaderおよびxceleditorが必要です。一般管理者とサイト管理者にはxceladminも必要です。一般管理者にはさらに、TableEditorとUserEditorも必要です(Engageを使用する場合はVisitorAdminも必要)。

- グループ割当て: (アプリケーション・リソースを管理するために)RESTレベルでユーザーを認可するグループ。事前定義済ユーザーを使用しない場合にアプリケーション・ユーザーに付与していたセキュリティ権限を持つグループに、事前定義済ユーザーを割り当てる必要があります。RESTセキュリティの構成の詳細は、RESTセキュリティの使用を参照してください。

ユーザーを作成する手順の詳細は、ユーザーの作成を参照してください。

2. 事前定義済ユーザーをアプリケーションに割り当てます。手順は、アプリケーション使用のユーザーへの認可を参照してください。

3. (アプリケーション使用のユーザーへの認可の手順を使用して)ユーザーをアプリケーションに割り当てます。ただし、グループへの割当て(手順4)は省略してください。

8.4 アプリケーション登録の開発者への認可

アプリケーションをWEMフレームワークで公開するには、アプリケーションを登録する必要があります。つまりそれらをアセットとして作成して、WEM Adminインタフェースの「アプリケーション」ページにRESTサービスを介して表示されるようにします。これによって管理者は、ユーザーによるアプリケーションの使用を認可できるようになります。

通常は開発者が自身の作成したアプリケーションをプログラムによって登録します。開発者がアプリケーションを手動で登録する場合は、WebCenter Sites Adminインタフェースを使用して、FW_ApplicationタイプおよびFW_Viewタイプのアセットを作成する必要があります。アセット・タイプは、AdminSiteで有効になります。(アプリケーションの登録の詳細は、『Oracle WebCenter Sitesでの開発』の、WEMフレームワークにおけるアプリケーションの手動登録に関する項を参照してください。)

開発者を認可するには、開発者が一般管理者であること(すなわち、RESTサービスも含めて、システムに対する全権限を持っていること)を確認します。一般管理者を作成する手順の詳細は、ユーザーの作成を参照してください。

8.5 使用できるアプリケーションに関する開発者への確認

アプリケーションとユーザーを管理するには、開発者がWEMフレームワーク用に作成したアプリケーションについて、開発者から情報を得ておく必要があります。

- リソース: カスタム構築アプリケーションで使用されているリソースについて、その開発者に確認します。ユーザーが使用するアセット・タイプ、アセットおよび他のリソースが判明したら、それらのリソースに対してユーザーに付与する必要がある権限(作成、更新など)を決定し、それらの権限を持つグループにユーザーを割り当てることができます。グループの構成およびユーザーの割当ての詳細は、RESTセキュリティの使用を参照してください。

- ロール: 編集などのインタフェース機能がロールで保護されているかどうか、開発者に確認します。WEMでは、ロールはアプリケーションへのアクセスを管理するために使用されます。同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。アプリケーション・コードでロールを使用すると、Editなどの、インタフェース機能を保護することもできます。アプリケーションがロールによって保護された機能を指定している場合、アプリケーション・ユーザーは、少なくとも1つのロールを各インタフェース機能と共有する必要があります。正しい認可を確実にするには、アプリケーション使用のユーザーへの認可を参照してください。

- ユーザー: アプリケーションで事前定義済ユーザーが構成されているかどうかを開発者に確認します。アプリケーションで事前定義済ユーザーが指定されている場合、アプリケーションのすべてのユーザーを個別に認可するのではなく、RESTレベルで事前定義済ユーザーを認可する必要があります。グループに属していることによって事前定義済ユーザーに付与されているセキュリティ権限は、ログイン・ユーザーがアプリケーションにアクセスする際に、ログイン・ユーザーに付与されます。事前定義済ユーザーの認可手順は、事前定義済ユーザーの認可を参照してください。

9 コンテンツ管理サイト・コンポーネントへのアクセスの管理

サイト・コンポーネントには、スタート・メニュー、アセット・アクセス・ポリシーおよびWebCenter Sitesツリーに対するユーザー権限が含まれます。

次の各トピックでは、サイト・コンポーネントへのアクセスを管理する方法について説明します。

- 概要

- スタート・メニューを使用したアセット・タイプへのアクセスの管理

- アセットへのアクセス権限の設定方法

- アセット・タイプのその他のオプション

- ツリーへのアクセスを管理するためのオプション(Adminインタフェースのみ)

9.1 概要

ユーザーにサイトへアクセスする権限を付与したら(コンテンツ管理サイトのアセンブルを参照)、サイトのコンテンツを使用できるかどうかを次の項目によって管理します。

- スタート・メニュー。ユーザーが割り当てられたサイトで、特定のタイプのアセットの作成、検索および編集を可能にするかどうかを決定します。

- (ワークフロー・プロセスには含まれていない)アセットへの権限。このようなアセットには、アセットでどのロールにどの機能を実行する権限があるかを定義するポリシーを作成できます。

- WebCenter Sitesにおけるツリーへの権限。ツリー、ツリー内のタブ、タブ内のノードおよびノード内のアイテムへのユーザー権限を制御できます。

ロールは、インタフェース機能およびユーザーが管理する必要があるコンテンツに、ユーザーを関連付けるためにコールするコンポーネントです。

9.2 スタート・メニューを使用したアセット・タイプへのアクセスの管理

スタート・メニューは、図9-1および図9-2に示すように、リンク付きアセット・タイプのリストです。

図9-1 Adminインタフェースの「新規」メニュー

図9-2 Adminインタフェースの「検索」メニュー

アセット・タイプ名をクリックすることで、選択したタイプのアセットの作成または検索のフォームが開きます。たとえば、「新規」スタート・メニューでアセット・タイプをクリックすると、選択したタイプのアセットを作成するフォームが開きます。「検索」スタート・メニューでアセット・タイプをクリックすると、選択したタイプのアセットを検索および編集するために使用するフォームが開きます。

図9-1および図9-2に示すスタート・メニューは、管理者インタフェースで、ユーザーがインタフェース左上にある「新規」ボタンおよび「検索」ボタンをクリックすることでアクセスできます。管理者は、ユーザーとスタート・メニュー・アイテムに同じロールを割り当てることで、ユーザーにスタート・メニュー・アイテムへの権限を付与します。

この項の内容は次のとおりです。

- スタート・メニュー・アイテムの使用

- スタート・メニュー・アイテムの管理

9.2.1 スタート・メニュー・アイテムの使用

スタート・メニューの各オプションがスタート・メニュー・アイテムです。スタート・メニュー・アイテムは、ユーザーが作成、コピーまたは検索可能なアセットのタイプを指定します。たとえば、図9-1に示す「新規」スタート・メニューは、管理者インタフェースに属し、ユーザーに使用が許可された16のスタート・メニュー・アイテムを表示します。ユーザーは、メニューに示されたタイプのアセットを作成できます。

管理者インタフェースでは、ユーザーがボタン・バーの「新規」または「検索」をクリックすると、リストにスタート・メニュー・アイテムが表示されます。

スタート・メニュー・アイテムを構成し、これらを使用して作成されるアセットについて次の項目を決定します。

- どのサイトのどのロールにスタート・メニュー・アイテムへのアクセス権限を付与するか。ロールの指定により、指定されたサイトで、どのコンテンツ・プロバイダが特定のタイプのアセットを作成または検索できるかを制御します。

- フィールド/値のペア。特定のフィールドに値を入力することで、コンテンツ・プロバイダがショートカットからアセットを作成するたびに、そのフィールドに自動的に値が入力されます。
たとえば、ベーシック・アセットの場合、スタート・メニュー・アイテムを、「ディメンション」、「説明」、「終了日」、「開始日」、「サブタイプ」、「テンプレート」または「ユーザー」フィールド(またはいくつかの組合せ)の、あらかじめ定められた値に設定しておくと便利です。ベーシック・アセットのアソシエーションが、アセットのサブタイプに基づいて異なる可能性がある場合、「新規」フォームに適切なアソシエーションのみが表示されるように新規アセットのサブタイプを設定するスタート・メニュー・アイテムを作成してください。

フレックス・アセットの場合、新規フレックス・アセットのフレックス定義を設定するスタート・メニュー・アイテムを用意すると、コンテンツ・プロバイダの手順が減るため便利です。

- スタート・メニュー・アイテムによって作成される新規アセットに、どのワークフロー・プロセスをデフォルトで割り当てるか、およびそのワークフロー・プロセスに参加するユーザー。

スタート・メニュー・アイテムは、ツリー(Adminインタフェース内)に表示されるアセット・タイプで特定の処理を実行可能にするかどうかも決定します。ツリーに表示されるアセット・タイプに、スタート・メニュー・アイテムが作成されていない場合、そのアセット・タイプのコンテキスト・メニューに表示されるオプションは、「リフレッシュ」、「編集」および「調査」のみです。「新規」オプションをコンテキスト・メニューに含めるには、「新規」スタート・メニュー・アイテムをアセット・タイプに対して作成する必要があります。

9.2.1.1 異なる種類のユーザーのスタート・メニュー・アイテム

コンテンツ・プロバイダに、異なる種類のコンテンツを作成する異なるグループが存在する場合、スタート・メニュー・アイテムをタイプごとに作成できます。

たとえば、ビジネス記事を作成するライターのグループが存在すると仮定します。記事を作成し、カテゴリをビジネスに設定して、テンプレートをビジネス・ページの記事用の正しいテンプレートに設定し、ビジネス記事のワークフローに記事を配置するスタート・メニュー・アイテムを作成できます。さらに、ビジネス・ライターのロールを作成する場合、ビジネス・ライターのロールを持つユーザーのみがスタート・メニュー・アイテムを使用できるように、そのスタート・メニュー・アイテムを構成できます。

9.2.1.2 フレックス・アセットのスタート・メニュー・アイテム

フレックス・アセットの場合、スタート・メニュー・アイテムを使用してフレックス・アセットの定義を設定できます。

たとえば、パブリック・サイトが家庭用品のカタログで、フレックス・アセットが製品であるとします。新しいトースター製品には製品定義をtoasterに設定するToasterという名前のスタート・メニュー・アイテムを作成し、新しいガラス製品には該当する製品定義を設定するglasswareという名前のスタート・メニュー・アイテムを作成するなどが可能です。この方法でフレックス定義を設定するスタート・メニュー・アイテムにより、コンテンツ・プロバイダの手順が削減され、間違って正しくないフレックス定義が選択される可能性が減少します。

9.2.2 スタート・メニュー・アイテムの管理

サイトのアセット・タイプへのユーザー・アクセスを管理するには、アセット・タイプのスタート・メニュー・アイテムを作成する必要があります。スタート・メニュー・アイテムは、特定のサイトで、どのユーザーに対して特定のタイプのアセットの作成および検索を可能にするかを決定します。WebCenter Sitesでは、4種類のスタート・メニュー・アイテムがサポートされています。

- 新規: ボタン・バーの「新規」をクリックしたときに表示されるリストのアセット・タイプにリンクを作成します。サイトに対して有効化されているアセット・タイプに「新規」アイテムを作成しなかった場合、いずれのユーザーもそのタイプのアセットを作成できなくなります。「新規」スタート・メニュー・アイテムの作成の詳細は、スタート・メニュー・アイテムについてを参照してください。

- 検索: ボタン・バーの「検索」をクリックしたときに表示されるリストのアセット・タイプにリンクを作成します。サイトに対して有効化されているアセットに「検索」アイテムを作成しなかった場合、いずれのユーザーもそのタイプのアセットをどのWebCenter Sitesインタフェースでも検索および編集できなくなります。「検索」スタート・メニュー・アイテムの作成方法の詳細は、検索スタート・メニュー・アイテムの作成を参照してください。

次の各トピックでは、スタート・メニュー・アイテムについて説明します。

- スタート・メニュー・アイテムについて

- 「検索」スタート・メニュー・アイテムの作成

- スタート・メニュー・アイテムの編集

- すべてのスタート・メニュー・アイテムのリストの表示

9.2.2.1 スタート・メニュー・アイテムについて

スタート・メニュー・アイテムの作成を開始する前に、次の点を考慮してください。

- スタート・メニュー・アイテムは、サイトに対して有効化されたアセット・タイプのみに作成します。アセットが有効化されていない場合は、コンテンツ管理サイトのアセンブルに戻り、サイトに対するアセット・タイプの有効化の手順を完了してください。

- デフォルトのワークフロー・プロセスを指定するには、先にワークフロー・プロセスを作成します。ワークフローの詳細は、ワークフロー・プロセスの作成と管理を参照してください。

- 開発者に依頼して、オンライン・サイトの問合せ、コレクション、その他の設計エレメントで使用されるフィールドを確認します。この方法により、それらのフィールドの実用的なデフォルト値を指定できます。

注意:

コンテンツ問合せアセットは、管理インタフェース内ではサポートされていません。

- 開発者にサイトが変更される特定の日付を確認し、サイト・プレビューに適したデフォルトの開始および終了日によってスタート・メニュー・アイテムを作成できるようにします。また、パブリッシュ済アセットでは、終了日によってWebサイトで自動的にアセットが失効する日付が決定されることにも注意してください。終了日のデフォルトを指定するとき、開発者に開発側の要件を確認してください。

- 開発者に確認し、スタート・メニュー・アイテムを作成するアセット・タイプの様々なサブタイプに適したテンプレートを見つけます。

- 次の種類のフィールドに値を設定することはできません。

- アップロード・フィールドやデータをURL列に書き込むフィールド。

- 複数の値を受け入れるフィールド。

- アソシエーション・フィールド。

- フレックス・アセットおよびフレックス親アセットのフレックス属性フィールド。

たとえば、次のアセット・タイプは、スタート・メニューに値を設定できません。

- 訪問者属性

- CSエレメント

- ディメンション

- ディメンション・セット

- フレックス属性

- フレックス子定義

- フレックス・フィルタ

- フレックス親定義

- 履歴属性

- 履歴定義

- ページ属性

- ページ定義

- ページ・フィルタ

- SiteEntry

- テンプレート

- 属性エディタ

9.2.2.2 スタート・メニュー・アイテムの作成

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「スタート・メニュー」を開き、続いて「新規追加」をダブルクリックします。
「スタート・メニュー」フォームが開きます。

図9-3 「スタート・メニュー」フォーム(1)

2. 「名前」フィールドに、最大64文字のアイテムの名前を入力します。必須ではありませんが、名前をNewの単語で始めることをお薦めします(たとえば、New ArticleやNew Template)。これは、ユーザーが後から、そのスタート・メニュー・アイテムを新規アセット用であると認識するのに役立ちます。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

「説明」フィールドが空白のままの場合、「新規」フィールドで使用されている名前が「新規」フォームおよび「検索」フォームに表示されます。

3. 「アセット・タイプ」フィールドで、スタート・メニュー・アイテムを作成しているアセットのタイプを選択します。

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

5. フレックス・アセット・タイプを選択した場合、「フレックス定義」フィールドが表示されます。フレックス・アセット・タイプを選択していない場合は、6に進みます。

a. 「フレックス定義」フィールドで、アセット・サブタイプを選択します。

b. フォームが自動的にリロードされない場合は、「続行」をクリックします。

「スタート・メニュー」フォームに、新しいフィールドが表示されます。

図9-4 「スタート・メニュー」フォーム(2)

6. 「説明」フィールドに、最大255文字で短い説明を入力します。「説明」フィールドに入力された名前は、「新規」フォームおよび「検索」フォームに表示されます。

7. 「タイプ」フィールドで、「新規」を選択します。
「アセット・タイプ」フィールドは、前のフォームでのアセット・タイプの選択を表示する情報のみのフィールドです。

8. (オプション)コンテンツ・プロバイダがこのスタート・メニュー・アイテムによってアセットを作成するとき、フィールド値が自動的に設定されるようにする場合は、「デフォルト値」セクションで次の手順を実行します。

a. 「フィールド」ドロップダウン・リストからフィールドを選択します。このリストには、このタイプのアセットのすべてのフィールドが表示されます(カテゴリ、ソース、テンプレートなど)。

b. 「値」フィールドで値を入力または選択します。

注意:

すべての値は大文字と小文字が区別されます。WebCenter Sitesでは、値を設定したフィールドに対して、その値を検証しません。したがって、適切な値が入力されていることを確認する必要があります。

c. 「追加」矢印をクリックし、フィールドに値を追加します。

d. 必要に応じて、前の3つの手順を繰り返します。

注意:

スタート・メニュー・アイテムによりフィールド値を設定するとき、そのフィールドは読取り専用フィールドにはなりません。つまり、「スタート・メニュー」フォームにどのような値を設定しても、その値は、スタート・メニュー・アイテムを使用してアセットを作成するコンテンツ・プロバイダによりオーバーライドされる可能性があります。値は便宜上設定されるのみです。

9. 「サイト」フィールドで、このスタート・メニュー・アイテムを使用できるサイトを選択します。複数のサイトを選択する場合、[Ctrl]キーを押しながらクリックします。

10. 「ロール」フィールドで、スタート・メニュー・アイテムにアクセスできるロールを選択します。複数のロールを選択する場合、[Ctrl]キーを押しながらクリックします。

注意:

デフォルトのワークフローにこのスタート・メニュー・アイテムを割り当てている場合、この手順で選択するロールは、ワークフロー・プロセスの開始手順に対して許可されている(または許可される予定の)ロールと一致する必要があります。

11. (オプション)このスタート・メニュー・アイテムで作成されたアセットのワークフロー・プロセスの詳細を構成するには、次の手順を実行します。

a. 「ワークフローの選択」を.クリックします。

b. 「ワークフローの選択」フォームで、ドロップダウン・リストから適切なワークフロー・プロセスを選択し、「ワークフローの選択」をクリックします。

c. 「参加者の設定」フォームで、開かれるロールごとに1つ以上のユーザーを選択し、「参加者の設定」をクリックします。

d. 「続行」をクリックします。
ワークフロー情報が保存され、「スタート・メニュー」フォームが再表示されます。

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

9.2.2.3 「検索」スタート・メニュー・アイテムの作成

「検索」スタート・メニュー・アイテムを作成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「スタート・メニュー」を開き、続いて「新規追加」をダブルクリックします。
「スタート・メニュー」フォームが開きます。

2. 「名前」フィールドに、最大64文字のアイテムの名前を入力します。必須ではありませんが、名前をFindの単語で始めることをお薦めします(たとえば、Find ArticleやFind Template)。この名前は、「検索」リストに表示されます。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

3. 「アセット・タイプ」フィールドで、スタート・メニュー・アイテムを作成しているアセットのタイプを選択します。

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

5. フレックス・アセット・タイプを選択した場合、「フレックス定義」フィールドが表示されます。フレックス・アセット・タイプを選択していない場合は、7に進みます。

a. 「フレックス定義」フィールドで、アセット・サブタイプを選択します。

b. フォームが自動的にリロードされない場合は、「続行」をクリックします。

新しいフィールドを持つ「スタート・メニュー」フォームが開きます。

6. 図9-5 スタート・メニュー(「新規検索」の場合)

7. 「説明」フィールドに、最大255文字で短い説明を入力します。

8. 「タイプ」フィールドで、「検索」を選択します。
「アセット・タイプ」フィールドは、アセット・タイプの選択を表示する情報のみのフィールドです。

9. 「サイト」フィールドで、このスタート・メニュー・アイテムを使用できるサイトを選択します。複数のサイトを選択する場合、[Ctrl]キーを押しながらクリックします。

10. 「ロール」フィールドで、スタート・メニュー・アイテムにアクセスできるロールを選択します。複数のロールを選択する場合、[Ctrl]キーを押しながらクリックします。

注意:

デフォルトのワークフローにこのスタート・メニュー・アイテムを割り当てている場合、この手順で選択するロールは、ワークフロー・プロセスの開始手順に対して許可されている(または許可される予定の)ロールと一致する必要があります。

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

9.2.2.4 スタート・メニュー・アイテムの編集

スタート・メニュー・アイテムを編集するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「スタート・メニュー」を開き、続いてスタート・メニュー・アイテムがあるノードを開きます。スタート・メニュー・アイテムをダブルクリックします。

「スタート・メニュー・アイテム」フォームが表示されます。

2. 「編集」をクリックします。

アイテムの情報が格納された「スタート・メニュー」フォームが開きます。

3. アイテムへ変更を加えます。

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

9.2.2.5 すべてのスタート・メニュー・アイテムのリストの表示

WebCenter Sitesシステムに存在するアセット・タイプごとに表示される個別のスタート・メニュー・ノードの他に、「管理」ツリーには、最上位の「スタート・メニュー」ノードが存在します。

すべてのスタート・メニュー・アイテムのリストを表示するには、次のいずれかを実行します。

- 「管理」ツリーの「スタート・メニュー」ノードを使用して、システム内のすべてのスタート・メニュー・アイテムのリストを表示します。

- 個々のスタート・メニュー・アイテムの「調査」フォームには、クリックすると、システム内のすべてのスタート・メニュー・アイテムがリストされるリンクがあります。

9.3 アセットへのアクセス権限の設定方法

WebCenter Sitesには、ワークフロー・プロセスの一部ではないアセットに対するアクセス権限を設定するためのシステムが用意されています。このようなアセットには、アセットでどのロールにどの機能を実行する権限があるかを定義するポリシーを作成できます。たとえば、コピー機能に関するポリシーにより、どのロールにアセットのコピーを許可するかを指定できます。また、コピー機能に関する別のポリシーでは、どのロールにアセットのコピー機能を拒否するかを指定できます。フレックス・アセットの場合、継承可能なポリシーを親に対して設定できます。つまり、ポリシーは子によって継承されます。

アセットに対してデフォルトで実行できる機能は、チェックアウト、コピー、編集、削除、ロールバック、共有、承認および作成です。(機能の定義は、機能権限の決定を参照してください)。

前述の機能はすべて、wcs_properties.jsonファイルのxcelerate.authorizefunctionプロパティ(プロパティ管理ツールを使用している場合は「セキュリティ」カテゴリ)の値として定義されています。

アクセス権限は、次の3つの目的に使用します。

- ワークフロー機能権限システムを拡張し、アセットがワークフローにない場合に、そのアセットに権限を設定できるようにします。

- ワークフローにないアセットのコンテンツを表示する機能(認可、調査およびプレビュー)を導入します。

- ワークフローにないアセットに階層化された権限の継承モデルを導入します。

注意:

アクセス権限機能は、ページレットなどの他のエンティティには適用されません。

この項の内容は次のとおりです。

- 権限構造の理解

- 認可タイプの使用

- アクセス権限の設定

9.3.1 権限構造の理解

権限の構造は、ロールが実行可能な機能(編集や表示など)を決定します。ユーザーの権限は、機能を実行できるロールをユーザーに割り当てることで管理されます。WebCenter Sitesでは、付与、拒否および継承の3レベルの権限構造が実装されています。付与と拒否は明示的な権限を意味し、機能を実行する権限を付与または拒否します。継承は、権限が付与も拒否もされていないことを意味します。かわりに、権限は、親アセットのポリシーが存在する場合、そこから継承されます。親のポリシーが存在しない場合は、アセットの権限が親の親のポリシーから継承され、親の親にポリシーが存在しない場合もさらにその親からというように処理されます。

権限にあいまいさがある場合は、次の考慮事項によってあいまいさを解決できる場合があります。

- ユーザーのロールの少なくとも1つが権限を付与する場合、権限が付与されます。

- 付与は拒否より優先されます。あるロールが権限を付与し、他のロールが同じ権限を拒否する場合、その権限は付与されます。

- ユーザーのロールの少なくとも1つが権限を拒否し、そのユーザーのロールのいずれも権限を付与しない場合、権限は拒否されます。
前述のシナリオを次の表にまとめます。

表9-1 権限の構造

ロール1

ロール2

結果

付与

該当なし

付与

付与

拒否

付与

拒否

該当なし

拒否

- アセットは、権限を親アセットから継承できます。
たとえば、Money Market Fundsという名前の親アセットが削除権限をEditorという名前のロールに付与し、Bobというユーザーにそのロールが割り当てられている場合、BobはMoney Market Fundsアセットとすべての子アセットを削除できます。

- アセットの権限は、親アセットの権限をオーバーライドできます。
Prime Money Market semi-annual reportアセットは特定のロールに対して削除権限を拒否しています。同じロールには、Prime Money Market親アセットで削除権限が付与されています。親アセットが削除権限を付与しても、Bobはレポートを削除できません。

- 特定のアセットに適用可能な権限がない場合、管理者はAdminインタフェースのプロパティ管理ツールを使用して、この権限のwcs_properties.jsonファイルを調べる必要があります。wcs_properties.jsonファイルでは、特定の機能への権限が1つのアセットではなく、すべてのアセットに設定されています。
wcs_properties.jsonにおける権限の設定の詳細は、プロパティ・ファイルからのアクセス権限の設定を参照してください。

- アセット権限は、wcs_properties.jsonファイルのプロパティ設定をオーバーライドします。
たとえば、wcs_properties.jsonファイルに権限xcelerate.copy.grantが存在し、アセットAを削除する権限が取り消された場合、アセットAの削除権限は拒否されます。

9.3.2 認可タイプの使用

特定の機能および特定のアセットには、wcs_properties.jsonで、ワークフロー機能権限、アクセス権限および認可プロパティの3種類の認可を互いに独立して定義できます。(ワークフロー機能権限の詳細は、ワークフロー・プロセスの作成と管理を参照してください。)

ユーザーがアセットで機能の実行を試みると、その機能についての一連の認可チェックが次の順序で実行されます。

ワークフロー内のアセットの場合:

アセットが投入されたワークフロー・プロセスの機能に対するワークフロー機能権限がチェックされます。

1. 機能権限が、その機能に定義されていない場合は、アセットのアクセス権限インタフェースで定義されたとおり、その機能に対してアクセス権限ポリシーがチェックされます。

2. アクセス権限(親のポリシーの継承を含む)が機能に対して設定されていない場合、wcs_properties.jsonで認可のプロパティがチェックされます。

3. 認可のタイプが定義されていない場合、デフォルトでアセットに機能を実行するための権限が付与されます。

注意:

前述のタイプの認可は、記載されている順番でチェックされます。複数の許可のタイプが拒否されている場合、最初に検出された認可が他のすべてのタイプの認可をオーバーライドします。たとえば、編集などの特定の機能に対して、ワークフロー機能の権限とアクセス権限の両方がアセットに定義されている場合、編集への機能権限が編集へのアクセス権限より優先されます。

ワークフローに含まれていないアセットの場合:

a. アセットのアクセス権限インタフェースに定義された、機能のアクセス権限ポリシーがチェックされます。

b. アクセス権限(親のポリシーの継承を含む)が機能に対して設定されていない場合、wcs_properties.jsonで認可のプロパティがチェックされます。

c. 認可のレベルが定義されていない場合、デフォルトでアセットに機能を実行するための権限が付与されます。

異なる認可タイプは、互いに独立しています。1つのアセットに、任意のタイミングで任意の機能に対して適用できるのは、1つの認可タイプのみです。次のガイドラインが、どのタイプの認可を使用するかを判断する助けになります。

1. 機能に認可が必要ない場合、いずれの認可のタイプも使用しないでください。すべてのロールにその機能を実行する権限が付与されます。

2. 複数アセットにわたる単純な認可ポリシーが必要な場合は、プロパティ管理ツールを使用して、wcs_properties.jsonファイルに認可プロパティを設定します。

3. 特定のアセットで単純な認可ポリシーが必要な場合は、アクセス権限を設定します。

4. ワークフローがアセットの権限を制御可能な、より複雑な認可タイプが必要な場合、ワークフロー機能権限を設定します。

9.3.3 アクセス権限の設定

アクセス権限を設定するということは、アセットに実行できる機能とロールを指定することによりアセットのポリシーを作成するということです。

アセットにアクセス権限を設定する方法はいくつかあります。

- 管理インタフェースを使用して個々のアセットに権限を設定する。

- プロパティ管理ツールを使用した、すべてのアセットに対するwcs_properties.jsonファイル内の権限の一括設定。

- Oracle WebCenter Sites: Contributorインタフェースを使用した、個々のアセットに対する権限の設定。手順は、『Oracle WebCenter Sitesの使用』を参照してください。

注意:

アセットが、機能権限が定義されたワークフローに投入された場合、機能権限はアセットのアクセス権限より優先されます。機能権限の詳細は、ワークフロー・プロセスの作成と管理を参照してください。

この項の内容は次のとおりです。

- アセット・ツールバー

- 管理者インタフェースでのアクセス権限の設定

- プロパティ・ファイルからのアクセス権限の設定

9.3.3.1 アセット・ツールバー

アセットが表示される場合、最上部のツールバー(図9-6)がアセットの使用を支援します。ここでは、各アセットに特定の機能を実行できます。

図9-6 アセット・ツールバー

ツールバー内のアイコンが実行するアクションを左から順に説明します。

- 編集: アセットの「編集」フォームが開きます。

- 削除: クリックするとアセットが削除されます。

- パブリッシュの承認: クリックすると、次回このアセットにパブリッシュが発生したときにアセットのパブリッシュが承認されます。

- コンテンツの共有: クリックすると、システム管理者によって有効化されたコンテンツを他のサイトと共有できます。

- ブックマークに追加: クリックすると、「ワーク」ツリーの「ブックマーク」ノードにこのアセットのブックマークを追加します。

- ステータス: クリックすると、アセットのワークフローの承認状態の詳細を表示するフォームが開きます。

- アクセス権限: クリックすると、アセットの「アクセス権限」フォームが開きます。詳細は、管理者インタフェースでのアクセス権限の設定を参照してください。

- ドロップダウン・メニュー: このメニューでは、コピーや新規アセットの作成にアセットを使用したり、アセットを作成したり、他のアセットを検索するなど、アセットをその他の方法で操作できます。

9.3.3.2 管理者インタフェースでのアクセス権限の設定

Adminインタフェースでアクセス権限を設定するには:

1. アクセス権限を設定するアセットを検索します。

2. アセットの「調査」フォームで、アセット・ツールバーから「アクセス権限」を選択します。

「属性エディタ」フォームが開きます。

図9-7 「属性エディタ」フォーム

3. ラジオ・ボックスを選択し、「ロール別に表示」または「機能別に表示」をクリックします。この例では、「機能別に表示」を使用します。

注意:

この手順では「機能別に表示」を使用するため、機能を選択してから、それを実行する権限を付与または拒否するロールを指定することができます。「機能別に表示」を選択すると、順序が逆になります。この場合、ロールを最初に選択し、付与または拒否する機能を指定する必要があります。

4. 機能を1つ選択します。

その機能を実行可能なロールが、デフォルトで「継承」リスト・ボックスに表示されるようになります。「継承」は、アセットが親、親の親またはそれら以上の親(階層内のポリシーが存在するアセットによって異なる)から継承した権限ポリシーを参照します。

5. 機能を実行する権限を拒否または付与する1つ以上のロールを選択します。(ロールを範囲で選択するには、範囲の最初と最後を[Shift]キーを押しながらクリックします。隣接しないロールを選択するには、それぞれのロールを[Ctrl]キーを押しながらクリック します)。

6. 「付与」または「拒否」のいずれかを選択し、ロールでの機能の実行を許可または禁止します。

- 「付与」は、選択したロールが特定のアセットで選択した機能を実行することを明示的に許可します。その他すべてのロールは、明示的に権限を付与しないかぎり、そのアセットで選択された機能を実行する権限が拒否されます。

- 「拒否」は、選択したロールが特定のアセットで選択した機能を実行することを明示的に禁止します。その他すべてのロールは、明示的に権限を付与しないかぎり、そのアセットで選択された機能を実行する権限が拒否されます。

- 「付与」と「拒否」のどちらも選択しない場合、「継承」リスト・ボックス内のロールで、アクセス権限が継承されたことを示す表示が維持されます。

7. 権限を付与または拒否する必要がある、あるいは必要と思われる機能とロールごとに、4から 6の手順を繰り返します。

8. 完了したら、「保存」をクリックします。

このアセットへ現在アクセスしているユーザーは、ロールで許可されている機能を実行できるようになります。

9.3.3.3 プロパティ・ファイルからのアクセス権限の設定

プロパティ管理ツールを使用して、wcs_properties.jsonファイルの次のプロパティを設定することによって、権限を付与または拒否します。

- xcelerate.grant.functionname = rolelist

- xcelerate.deny.functionname = rolelist
ここで

functionnameは機能の名前であり、wcs_properties.json fileファイルに示されています。プロパティ管理ツールを使用している場合は、「セキュリティ」カテゴリにあります。

rolelistは、権限を付与または拒否するロールのカンマ区切りリストです。

wcs_properties.jsonで付与または拒否されている権限は、すべてのアセットに対して付与または拒否されます。これらの権限は、WebCenter Sitesのアクセス権限機能を使用してアセット単位で明確にアクセス権限を設定することによってオーバーライド可能です。

9.4 アセット・タイプのその他のオプション

「一般的な管理」ツリーの「管理」ノードの下には、アセット・タイプを構成するいくつかの他のアイテムがあります。これらのアイテムは、アセット・タイプのデザインと実装に関するもので、通常は開発者によって使用されます。管理者は、このアイテムを通常は管理しません。

ただし、アセット・タイプの設計およびインストール後は、次のアイテムを管理するように依頼される可能性があります。

- ソース

- カテゴリ

- サブタイプ

- アソシエーション

- MIMEタイプ

これらのアイテムの詳細とそれらの作成および編集の手順は、『Oracle WebCenter Sitesでの開発』を参照してください。

9.5 ツリーへのアクセスを管理するためのオプション(Adminインタフェースのみ)

管理者用インタフェースの左側のパネルに表示されるツリーは、いくつかの方法で構成できます。

- ツリーをデフォルトでメイン・ウィンドウに表示するか、またはデフォルトで非表示にするかを構成できます。

- ツリーを非表示にしたユーザーが、ツリーを表示するように切り替えることを許可するかどうかを制御できます。

- ツリー内では、ノードを構成して、タブにアイテムまたは機能を追加したり、ユーザーのロールに基づいてタブへのアクセス権限を与えるユーザーを決定できます。

- ツリー・ノードのサブ・ノードを構成して、指定のノードの下に表示されるアイテムの数を指定できます。

WebCenter Sitesでは、ツリーとノードの2つの一般カテゴリがサポートされています。

- システム・デフォルトのツリーおよびノードでは、管理機能(たとえば「管理」、「サイト管理者」および「ワークフロー」)が提供され、さらに個々のアセット(「履歴」、「ブックマーク」、「サイト・プラン」)へのアクセスが可能です。
アセットおよびアセット・タイプは、開発者による使用が意図されており(例、テンプレート)、Contributorインタフェースでは、調査にのみ使用できるか、またはアクセスできません。逆に、すべてのフレックス・アセットとそれらの親アセット、すべてのベーシック・アセット、Oracle WebCenter Sites: Engageアセット(推奨、セグメント、プロモーションなど)、問合せ、コレクションおよびページ・アセットなどは、Contributorインタフェースのみでしか使用できません。

- カスタム・ツリー:

- 様々なロールのユーザーが頻繁に使用するアセット・タイプをより簡単に作成できるように、管理者が作成するツリー。

- カスタマイズされた動作や機能を提供するために、開発者が作成するツリー。

注意:

「ワークフロー・グループ」ノードは、システム・デフォルト・タブとカスタム・タブが混成されたものです。「ワークフロー・グループ」はデフォルトではインストールされず、使用するには作成する必要がありますが、そのロジックを提供するエレメントはインストールされます。つまり、このノードは手動で作成する必要がありますが、開発者がエレメントをコード化する必要はありません。

次の各トピックでは、ルールをシステム・デフォルトのツリーとノードに追加する方法、アセット・タイプへアクセスできるベーシック・ツリー・ノードの作成方法、およびデフォルトでツリーを表示するかどうかを構成する方法について説明します。機能を実装するカスタム・ツリー・タブの作成の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- ツリーの表示と非表示

- ツリー・タブの作成について

- ツリーとノードの編集

- ツリー・タブの削除

- ツリー・タブの順序の変更

- タブのノードに表示するアイテムの数の構成

9.5.1 ツリーの表示と非表示

メイン・ウィンドウで作業中のアセットの表示にさらにスペースが必要な場合やさほどスペースが必要ない場合には、いつでもすべてのユーザーがツリーの表示と非表示を切り替えることができます。

デフォルトでツリーが非表示になるようにWebCenter Sitesシステムを構成できます。また、ユーザーがツリーを表示するように切り替えることを許可するかどうかを制御できます。

アセットを使用するためのWebCenter Sitesの機能は、タブ上のコンテキスト・メニュー、ウィンドウ上部のアイコンおよびAdminインタフェースのみで管理される個々のアセットの「新規」、「編集」および「調査」フォームに表示されるアクション・バーで利用できます。したがって、コンテンツ・プロバイダにツリーを表示することは必須ではありません。ただし、管理機能は「管理」、「サイト・プラン」および「ワークフロー」タブでしか使用できないため、管理ユーザーは常にツリーへアクセスできる必要があります。

ツリーおよび表示切替えの権限を構成するには:

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「カテゴリ」ドロップダウン・メニューで、「UI」を選択します。

3. 「検索」をクリックします。

4. ユーザーが初めてAdminインタフェースにログインしたときに、ツリーがデフォルトで表示されないようにするには、次を実行します。

a. xcelerate.showSiteTreeプロパティを選択します。

b. 「値」フィールドで、値をfalseに設定します。

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

5. (オプション)管理ユーザー(ユーザー・アカウントにxceladmin ACLが割り当てられたユーザー)のみに、ツリーの表示への切り替えを許可するようにシステムを構成するには、次のようにします。

a. xcelerate.restrictSiteTreeプロパティを選択します。

b. 「値」フィールドで、値をtrueに設定します。

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

6. アプリケーション・サーバーを再起動します。

9.5.2 ツリー・タブの作成について

ツリー・ノードは、Adminインタフェースの左側パネルに表示されるノードです(「管理」など)。ツリー・ノードへのアクセスは、ロールによって制御します。

ツリー・ノードのいくつかは、WebCenter Sitesの中核となるものです。ツリー・ノードを作成する前に、デフォルト・ノードを確認して、WebCenter Sitesの既存の機能を理解してください。デフォルト・ツリー・ノードは次のとおりです。

- ブックマーク: ブックマークに選択して追加したアセットが表示されます。「ブックマークに追加」ボタンを使用してブックマークにアセットを追加すると、すべてのユーザーに即座にこのタブが表示されます。

- 管理: システム内のすべてのサイトに影響する管理機能が表示されます。デフォルトでは、GeneralAdminというデフォルトのシステム・ロールのあるユーザーのみが、このノードにアクセスできます。

- モビリティ: 開発者がモバイル機能を構成できます。デフォルトでは、GeneralAdminというデフォルトのシステム・ロールのあるユーザーのみが、このノードにアクセスできます。

- コネクタ管理者: WebCenter Contentを管理するための管理機能を表示します。

- Dev: サイトでページを作成するためのソースとして使用できます。これらのソースには、テンプレート、製品定義、コンテンツ定義、およびページ作成のためのその他のソースがあります。

- 履歴: 現在のセッションで使用したアセットが表示されます。このタブは、すべてのユーザーに対して、最初のアセットの作成、調査、編集またはコピー直後に表示されます。このタブは構成できません。

- サイト管理者: 管理機能の一部分が含まれ、それらの機能は現在ログインしているサイトのみに適用されます。デフォルトでは、SiteAdminというデフォルトのシステム・ロールのあるユーザーのみが、このタブにアクセスできます。このタブは、既存ユーザーの個々のサイトへのアクセス権限は管理するが、ユーザーまたはサイトを作成する必要のない管理ユーザーが存在する場合に役立ちます。

- 訪問者の管理: 開発者は、WebCenter SitesのAdminインタフェースを介してVisitor Servicesを構成、管理できます。

- サイト・ナビゲーション: 配信システムで利用可能にしているオンライン・サイトを構成するページ、コレクション、問合せおよびコンテンツ・アセットをグラフィカルおよび階層的に表示します。デフォルトでは、このタブへのアクセス権限はすべてのFirstSiteIIサンプル・サイト・ロールおよびシステム・デフォルト・ロールによって付与されます。

- ワークフロー: ワークフロー構成機能が含まれています。デフォルトでは、Workflow Adminロールのあるユーザーのみが、このタブにアクセスできます。

- ブックマーク: ブックマークされたページのリストを保持しています。

- 履歴: 現在のセッションで使用したアセットが表示されます。

この項の内容は次のとおりです。

- ツリー・タブの作成

- 「ワークフロー・グループ」タブの作成

9.5.2.1 ツリー・タブの作成

注意:

ツリー・タブを作成する前に、デフォルトのツリー・タブをよく理解して、機能が重複しないようにしてください。

ツリー・タブを作成するには:

1. 「管理」 タブで、「ツリー」をダブルクリックします。

「ツリー・タブ」フォームが開きます。

図9-8 「ツリー・タブ」フォーム

2. 「ツリー・タブ」フォームで、「新規ツリー・タブの追加」をクリックします。

「新規ツリー・タブの追加」フォームが開きます。

図9-9 「新規ツリー・タブの追加」フォーム

3. 「タイトル」フィールドに、最大64文字で短い説明的な名前を入力します。

4. 「ツールチップ」フィールドに、最大255文字で短くわかりやすいタブの説明を入力します。この説明は、マウス・カーソルをタブの上に重ねたときに表示されます。

5. 「サイト」フィールドで、このタブを表示するサイトを選択します。

6. 「必須ロール」フィールドで、このタブにアクセスできるロールを選択します。

7. タブ・コンテンツフィールドで、アセット・タイプを選択し、「選択したアイテムの追加」をクリックします。

8. (オプション)このタブにカスタム機能を追加するには、フォームの下部にある「セクション名」および「エレメント名」フィールドを使用します。この手順には開発者の支援が必要です。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

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

ツリーにタブが表示されます(必要に応じてリフレッシュしてください)。

9.5.2.2 「ワークフロー・グループ」タブの作成

「ワークフロー・グループ」タブには、サイトに存在するワークフロー・グループと、それらのグループに含まれるアセットが表示されます。ワークフロー・グループの詳細は、ワークフロー・グループの理解を参照してください。このタブは、デフォルトで表示されません。それを使用するには、作成する必要があります。

「ワークフロー・グループ」タブを作成するには::

1. 「管理」タブで、「ツリー」をダブルクリックします。

「ツリー・タブ」フォームが開きます(図9-8)。

2. フォームで、「新規ツリー・タブの追加」をクリックします。

「新規ツリー・タブの追加」フォームが開きます(図9-9)。

3. 「タイトル」フィールドに、最大64文字で短い説明的な名前を入力します。

例: ワークフロー・グループ

4. 「ツールチップ」フィールドに、最大255文字で短くわかりやすいタブの説明を入力します。

例: ワークフロー・グループ

5. 「サイト」フィールドで、このタブを表示するサイトを選択します。

6. 「必須ロール」フィールドで、このタブにアクセスできるロールを選択します。

7. 「タブ・コンテンツ」領域で、セクション領域まで下へスクロールします。「セクション名」フィールドで、「グループ」を入力します。

8. 「エレメント名」フィールドで、OpenMarket/Gator/UIFramework/LoadWorkflowGroupsを入力します。

9. 「新規セクションの追加」をクリックします。

Groupsという単語が「選択済」列に表示されます。

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

9.5.3 ツリーとノードの編集

ツリーまたはノードを編集するということは、次の操作が可能であることを意味します。

- 名前の変更。

- ツールチップの編集。

- 別の一連のサイトに対する有効化。

- 別の一連のロールに対する表示。

- 対応する別の一連のコンテンツの選択、コンテンツの順番の並替え、またはこれら両方の実行。

注意:

ツリー・ノードがユーザーのサイトで有効化されていて、ツリー・ノードとユーザーに、少なくとも1つのロールを共通に持っている、この2つの条件が満たされると、ツリー・ノードがContributorインタフェースに表示されます。

サイト・ユーザーをロールで作成する場合、デフォルトのツリー・ノードでロールを選択して、ユーザーにアクセス権限が付与されるようにする必要があります。(デフォルトのツリー・ノードは、ロールに対して自動的に有効化されません。)デフォルト・ツリーとノードのリストは、ツリー・タブの作成についてを参照してください。

ツリーまたはノードを編集するには:

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「ツリー」をダブルクリックします。

「ツリー・タブ」フォームが開きます(図9-8)。

2. タブに移動し、その「編集」アイコンをクリックします。

「ツリー・タブの編集」フォームが開きます。

3. 「ツリー・タブの編集」フォームで必要な変更を行います。

例:

- ツリー・タブを新規サイトに対して有効化する場合は、「サイト」リストからサイトを選択します。

- 新規サイトに、新規ロールを持つユーザーがあり、それらのユーザーに対してツリー・タブを有効化する場合、「ロール」リストでユーザーのロールを選択します。

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

9.5.4 ツリー・タブの削除

ツリー・タブを削除するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「ツリー」をダブルクリックします。

「ツリー・タブ」フォームが開きます(図9-8)。

2. 「ツリー・タブ」フォームで、目的のタブに移動し、「削除」アイコンをクリックします。

警告メッセージが開きます。

3. 「ツリー・タブの削除」をクリックします。

ツリー・タブが削除されます。

9.5.5 ツリー・タブの順序の変更

ツリー・タブ(ノード)の表示順序は変更できます。

ツリー・タブの順序を変更するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「ツリー」をダブルクリックします。

「ツリー・タブ」フォームが開きます(図9-8)。

2. 「ツリー・タブ」フォームの下部で、「ツリー・タブの順序」をクリックします。

「ツリー・タブの順序」フォームが開きます。

図9-10 「ツリー・タブの順序」フォーム

このフォームには、ツリーに表示される順序でタブが示されます。

ツリーではタブが横方向に整列されます。横1列で対応可能な数よりもタブが多い場合、背後に追加の列が形成されます。各列のタブは、左から右の順序で並べられます。各列は手前から後ろに並べられます。

3. タブをツリーに移動するには、リストでタブを選択し、矢印ボタンを使用してタブを正しい位置に移動します。位置を変更する各タブについて、この手順を繰り返します。

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

ツリーにタブが新しい順序で表示されます(必要に応じてリフレッシュしてください)。

9.5.6 タブのノードに表示するアイテムの数の構成

WebCenter Sitesの応答時間を最適化するために、ツリー・タブの該当するノードに表示されるアセットの数を制限できます。特に、WebCenter Sitesデータベースにいずれか1つのタイプのアセットが多数格納されている場合、WebCenter Sitesがすべてのアセットをロードして、タブのノードにそれらを表示するために時間がかかる場合があります。ロード時間を最小限に抑えるために、しきい値を設定してノードに表示されるアイテムの数を制限します。ノードに対するアセット(またはその他のアイテム)の数がしきい値を超え、ユーザーがそのアセットにアクセスしようとすると、管理者のインタフェースで、返されるアイテムの数を制限する検索条件の入力を求められます。

たとえば、ノードに300を超える記事が含まれており、しきい値が100に設定されているとします。ユーザーが記事を表すノード・アイコンを開くと、WebCenter Sitesにより小さな検索条件のフォームが表示され、返す記事の数を制限するために使用する値の入力を求められます。

ツリー・タブのノードに表示されるアイテムの数を構成するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「名前」フィールドに、xcelerate.treeMaxNodesと入力します。

3. 「検索」をクリックします。

4. プロパティの名前を選択します。「値」フィールドで、値を指定します。デフォルトでは、このプロパティは100に設定されています。100までのアイテムをノードの下に表示できることを意味します。

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

6. アプリケーション・サーバーを再起動します。

10 管理者インタフェースの使用

次の各トピックでは、3つのタイプの管理者について説明し、サイトの管理を可能にするAdminインタフェース、そのツリーとノード(タブ)、およびAdminインタフェースまたはバックエンドからアクセスできるシステム・デフォルトについて説明します。

- 管理ウィンドウについて

- 管理者固有のツリーとノード

- 各種のツリーとノード

- システム・デフォルトについて

10.1 管理ウィンドウについて

WebCenter Sites Adminインタフェースは、管理者と開発者が、WebCenter Sitesコンテンツ管理サイト、アセット・タイプ、ユーザーおよび機能(たとえばパブリッシュ、ワークフローおよびセキュリティ)を管理するために使用されます。

管理者は、WebCenter Sites Adminを使用して次のことを行います。

- ユーザー・アカウントとプロファイルの作成と構成(ACLやロールの作成と、ユーザーへの割当てなど)。

- WebCenter Sitesのセキュリティの構成と実装(RESTセキュリティ、暗号化キー・セキュリティおよび外部セキュリティなど)。

- セッションのパブリッシュの構成とスケジュール。

- ワークフロー・プロセスの作成と管理。

- アセット・タイプに対するリビジョン追跡の有効化。

- コンテンツ管理サイトでのアセット・タイプの有効化とスタート・メニュー・アイテムの作成。ユーザーがそれらのアセット・タイプをContributorインタフェースで使用できるようになります。

- WebRootsの作成とURLパターンの定義による、アセット・タイプごとのバニティURLの構成。

- WebCenter Sitesキャッシング・システム(inCacheフレームワーク)の管理。

- 診断ユーティリティを使用したWebCenter Sitesシステムのトラブルシューティング。

- WebCenter ContentのWebCenter Sitesとの統合と管理。

- Lucene検索エンジンのContributorインタフェース用構成。

開発者は、WebCenter Sites Adminを使用して次のことを行います。

- アセット・タイプの作成と定義による、データ・モデルの構築。例:

- フレックス・ファミリ(フレックス属性、フレックス親、フレックス親定義、フレックス定義、フレックス・アセットおよびフレックス・フィルタなど)の作成。

- ベーシック・アセット・タイプとベーシック・アセットのデータベース表の作成。

- プロキシ・アセットの作成

- コンテンツ管理サイトのデザイン・アセット(たとえばTemplate、CSElement、SiteEntry、Wrapper、Filterなど)の作成。

- 属性エディタのデザインと、バンドルされる属性エディタの構成。

- 多言語サポートのサイトの構成。

- Mobility機能の構成。たとえば、デバイス・リポジトリ、デバイス・グループと接尾辞、デバイス・アセット、サイト・ナビゲーションおよびモバイル・テンプレートを作成します。

Adminインタフェースの詳細は、次のトピックを参照してください。

- 管理者固有のツリーとノード

- 各種のツリーとノード

- システム・デフォルトについて

10.2 管理者固有のツリーとノード

管理者固有の機能は、「一般的な管理」および「サイト」ツリーのノードとサブ・ノードから制御します。

管理者固有のツリー・ノードは、ユーザー権限に基づいて表示されます。表10-1に示すように、適切なACLとロールを持つユーザーは、ツリーを表示できます。ACLとロールの詳細は、ACLおよびロールの使用、ユーザー、プロファイルと属性の構成およびシステム・デフォルトを参照してください。Mobility(モバイル・デバイス用)の管理の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

表10-1 タブの権限とロール

ツリー

ノード

サブ・ノード

ACL

ロール

一般的な管理

管理

- サイト

- アセット・タイプ

- パブリッシュ

- 検索

- ユーザー・アクセス管理

- WebRoots

- スタート・メニュー

- ツリー

- ロケール

- システム・ツール

- チェックアウトのクリア

- ファンクション

xceladmin

GeneralAdmin

一般的な管理

コネクタ管理者

- コンソール

- 履歴

- 親がないコンテンツ

- 構成

- ルール

xceladmin

ConnectorAdmin

一般的な管理

ワークフロー

- 状態

- プロセス

- アクション

- 時間指定アクション・イベント

- 電子メール

- 割当てのクリア

xceladmin

WorkflowAdmin

サイト

サイト管理者

ログインしているサイトについて、次を変更します。

- ユーザー

- アセット・タイプ

- サイト・ナビゲーション

xceladmin

SiteAdmin

サイト

サイト・ナビゲーション

ログインしているサイトに関連付けられている各サイト・ナビゲーションのノードを含みます。

xceladmin

SiteAdmin

ログインしているサイトのタイプに基づいて次の管理ツリーが表示されます。

- カスタム・サイトにログインしている場合、「一般的な管理」および「サイト」ツリーが表示されます。「一般的な管理」ツリーは、システム全体のままです。「サイト」ツリーは、ログインしているサイトに固有です。このため、「一般的な管理」ツリーの「管理」ノードのサブセットです。

- なんらかのサイト(デフォルト・サイト以外)のワークフロー・プロセスが作成されると、「ワークフロー」ノードが「一般的な管理」ツリーに表示されます。「ワークフロー」ノードには、システム内のすべてのサイトのために構成されたすべてのワークフロー・プロセスが一覧表示されます。

10.2.1 「一般的な管理」ツリーの管理ノード

「一般的な管理」ツリーは、サイトを作成、構成、管理するために使用される主要なツリーです。

「一般的な管理」ツリーには、次の管理者固有のノードとサブ・ノードが表示されます。

- 管理: WebCenter Sitesインストールのすべてのコンテンツ管理コンポーネントを占めています。管理機能に固有の次のサブ・ノードが含まれます。

- サイト :WebCenter Sitesシステム上のすべてのコンテンツ管理サイトを管理できます。詳細は、コンテンツ管理の概念についてを参照してください。
「サイト」ノードには次の機能があります。

- システムに作成されたサイトのリスト。

- サイトを定義し、システム全体の構成プールのコンポーネントをサイトに関連付け、「サイト」ノード下に配置できます。WebCenter Sitesには、学習ツールとしていくつかのサンプル・サイトが用意されています。

構成プールを構成するノードは次のとおりです。

- アセット・タイプ: 次の目的のためにアセット・タイプを構成します。

- ベーシック・アセット・タイプ用のサブタイプまたはアセットのアソシエーションを追加するため。

- 「新規」メニューおよび「検索」メニューに表示されるアセット・タイプ用のスタート・メニュー・アイテムを作成するため。

- 特定のアセット・タイプのリビジョン追跡を有効化または無効化するため。詳細は、リビジョン追跡の管理を参照してください。

- パブリッシュ: 開発システムおよび管理システムにパブリッシュ・システムを設定する際に使用します。パブリッシュに関する一般的な詳細は、パブリッシュの理解を参照してください。静的および動的パブリッシュの詳細は、ディスクへのエクスポートのパブリッシュの用語の詳細とサーバーへのミラーリングのパブリッシュの理解を参照してください。インタラクティブな動的パブリッシュの詳細は、リアルタイム・パブリッシュの使用を参照してください。

- 検索: アセット・タイプを構成し、サポートされているサードパーティの検索エンジン・モジュールを使用している場合に、そのアセット・タイプに索引が正しく付けられるようにします。詳細は、Lucene検索エンジンの構成を参照してください。

- ユーザー・アクセス管理: ACLおよびユーザーの作成、アセット以外の表のリビジョン追跡の有効化または無効化、およびWebCenter Sitesのデータベースに対する他の様々な操作を実行します。このノードには、次が含まれます。

- ユーザー: WebCenter Sitesユーザーおよび各ユーザーIDに関連付けられているロールの管理に使用します。詳細は、ユーザー、プロファイルと属性の構成を参照してください。

- ロール: ワークフロー割当ての受信者の決定、およびOracle WebCenter Sitesのインタフェースの機能へのユーザーのアクセス制御のために使用します。詳細は、ACLおよびロールの使用を参照してください。

- ACL: 個々の表とサイトへのアクセスを可能にします。詳細は、ACLおよびロールの使用を参照してください。

- ユーザー・プロファイル: ユーザーの電子メール・アドレスを指定します。詳細は、ユーザー、プロファイルと属性の構成を参照してください。

- RESTセキュリティ: セキュリティ・グループの構成およびそのグループへのユーザーの割当てを行う際に使用します。セキュリティ・グループへのユーザーの追加は、WebCenter Sitesインタフェースに関連します。詳細は、外部セキュリティの設定と『Oracle WebCenter Sitesでの開発』を参照してください。

- WebRoots: バニティURLを解釈します。「新規追加」をクリックして、WebRootsを作成します。既存のWebRootsを編集できます。詳細は、「WebRootsの操作」を参照してください。

- スタート・メニュー: ユーザーが「新規」ボタンまたは「検索」ボタンをクリックしたときに開くフォームに、リンクを作成します。このリンクは、アセットの作成または既存のアセットの検索のために使用します。

注意:

今回のリリースのWebCenter Sitesでは、スタート・メニュー・アイテムである「新規」および「検索」の自動作成がサポートされています。

- ツリー: 既存のツリー・タブへのアクセスの制御、タブの作成、またはOracle WebCenter Sites: Contributorインタフェースのツリーへのアセット表示を行います。手順については、コンテンツ管理サイト・コンポーネントへのアクセスの管理を参照してください。

- ロケール: WebCenter Sitesシステムのデフォルト・ロケールを設定します。詳細はユーザー・インタフェースの構成を参照してください。

- システム・ツール: 管理者のインタフェースから直接、問題をトラブルシューティングします。log4jロギングの構成、様々なタイプのシステム情報へのアクセス、キャッシュの管理、ログの検索、共有ファイル・システムのパフォーマンスのテストなどの機能があります。詳細は、システム・ツールを使用したトラブルシューティングを参照してください。

- チェックアウトのクリア: 特定のユーザーがチェックアウトしたアセットに対し、ロック解除およびデータベースへの再チェックインを行います。詳細は、リビジョン追跡の管理を参照してください。

- 機能: 管理者がすべてのユーザーまたは選択したユーザーのOracle WebCenter Sitesのインタフェースで有効化または無効化できます。

- コネクタ管理者: WebCenter Contentを管理するための管理機能を表示します。詳細は、WebCenter Content統合の理解を参照してください。
「コネクタ管理者」ノードでは、次のノードを表示できます。

- コンソール: 「最近のアクティビティ」表が表示されます。表には、最近のコネクタ・アクティビティが表示されます。

- 履歴: アーカイブされたコネクタ・セッションが表示されます。処理の詳細な情報を得るために、個々のコンテンツ・アイテムまで絞り込むこともできます。

- 親がないコンテンツ: 対応するコンテンツ・アイテムが、同期から削除済か、期限切れか、無効化されている場合に削除できないアセットが表示されます。詳細は、親がないコンテンツを参照してください。

- 構成: WebCenter Contentに接続するようにWebCenter Sitesを設定します。詳細は、WebCenter Contentへの接続を参照してください。

- ルール: 実行時にコネクタが従うべき一連の指示。詳細は、アクティブ・ルールの作成を参照してください。

- ワークフロー: ワークフローは、このツリー・ノードから構成されます。ワークフローは、「管理」ノードの下のサブ・ノードを使用して作成され、割り当てられたワークフロー構築ブロック(状態、アセット、ユーザー)から作成されます。ワークフローの詳細は、ワークフロー・プロセスの作成と管理を参照してください。

注意:

「ワークフロー」タブはサイト固有ですが、そのコンテンツはサイト固有ではありません。

- タブ: 管理者がサイトにログインすると、そのサイトでユーザーにxceladmin ACLおよびWorkflowAdminロールが割り当てられている場合、「ワークフロー」タブが開きます。この点で、「ワークフロー」タブはサイト固有です。

- タブの内容: 「ワークフロー」タブには、システム全体の情報、つまり、インストールのすべてのサイトの、すべてのワークフロー・プロセスが表示されます。したがって、「ワークフロー」タブのノードのコンテンツはサイト固有ではありません。

- 状態: ワークフローにアセット・ステータス・ポイントを作成します。

- アクション: アクションと呼ばれるワークフロー構築ブロックを作成します。任意のワークフローがこれらのアクションを使用できます。

- 時間指定アクション・イベント: ワークフロー中のアセットの期日を計算する頻度を構成します。

- プロセス: ワークフロー・プロセスを作成するときは、グローバル・プロセス情報を指定し、次にステップを作成し、ステップ・アクションを必要に応じてそれらに割り当てます。プロセス内のステップによって、状態が特定の順序でつなぎ合わされ、プロセスのフローが作成されます。

- 電子メール: ワークフロー電子メール・メッセージを作成します。任意のワークフローがこれらの電子メールを使用できます。

- 割当てのクリア: ワークフロー割当てをクリアします。

10.2.2 サイト・ツリーのサイト管理ノードについて

「サイト」ツリーの「サイト管理者ノードはサイト固有です。それを使用して、選択したサイトを管理します。

「サイト管理者」ノードは、「一般的な管理」ツリーの「サイト」ノードに、管理機能のサブセットを保持します。サイトの既存ユーザーの管理、およびアセット・タイプの有効化または無効化に使用します。ユーザー、アセット・タイプまたはサイトを作成するためには使用できません。このタブを使用するのは、システム全体の管理権限を持っておらず、管理ロールとACLにより数個のサイトを管理するように制限されている場合です。すべてのサイトへのアクセス権がある場合は、このタブと「管理」タブのどちらを使用してもかまいません。

このタブにアクセスする他のユーザーには、xceladmin ACL、およびそのユーザーがログインするサイトのSiteAdminロールを割り当てる必要があります。

10.3 開発者関連のツリーとノード

Adminインタフェースの左のナビゲーション・ペインにある「一般的な管理」および「コンテンツ」ツリーには、開発者固有のノードとサブ・ノードが含まれます。開発者はこれらのノードを使用して、コンテンツ管理サイトとそのコンポーネントのためのフレームワークを作成します。開発者ノードに対する権限は、管理者ロールの権限と同一です。例外は、開発者関連のツリー・ノードが、テンプレートのコーディングやサイトを開発する他のあらゆるアクションの知識を持つユーザーが最適実行できるコンテンツ管理機能を制御するということです。

次の表に、開発者関連のツリー・ノードにアクセスするために必要な権限に関する情報を示します。

表10-2 ツリーの権限とロール

ツリー

ノード

サブ・ノード

ACL

ロール

一般的な管理

管理者

- AssetMaker

- フレックス・ファミリ・メーカー

- プロキシ・アセット・メーカー

xceladmin

GeneralAdmin

一般的な管理

モビリティ

- デバイス・グループ

- デバイス

- デバイス・リポジトリ

- イメージのプロパティ

xceladmin

GeneralAdmin

一般的な管理

訪問者の管理

- アイデンティティ・プロバイダ

- アクセス・プロバイダ

- プロファイル・プロバイダ

- 集計テンプレート

- 一般構成

xceladmin

GeneralAdmin

10.3.1 一般管理ツリーの開発者ノードについて

「一般的な管理」ツリーの開発者固有のノードは、WebCenter Sitesとその機能を構成、統合などの方法で開発するために使用します。

「一般的な管理」ツリーには、次の開発者固有のノードとサブ・ノードが表示されます。

- 管理: 開発者がコンテンツ管理サイトでアセット・タイプを作成、管理できます。開発機能に固有の次のサブ・ノードが含まれます。

- AssetMaker: サイト開発者がベーシック・アセット・データ・モデルを使用してアセット・タイプを作成するためのものです。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- フレックス・ファミリ・メーカー: サイト開発者が、新しいフレックス・ファミリおよびフレックス・アセット・タイプを作成するためのものです。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- プロキシ・アセット・メーカー: サイト開発者がプロキシ・アセット・タイプを作成するためのものです。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- モビリティ: 開発者がモバイル機能を構成できます。次のサブ・ノードが含まれます。

- デバイス・グループ: サイト開発者が、WebCenter Sitesシステム上のすべてのコンテンツ管理サイトに対してデバイス・グループを作成、有効化するためのものです。デバイス・グループの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- デバイス: サイト開発者がデバイス・アセットを作成し、デバイス・グループに関連付けるためのものです。

- デバイス・リポジトリ: 開発者がデバイス・リポジトリ(WebCenter Sitesがモバイル・デバイスを検出するために使用するファイル)をアップロードするために使用します。デバイス・リポジトリには、デバイスのプロパティが含まれ、そのユーザー・エージェントに基づいて各デバイスを一意に識別します。開発者は、デフォルト・デバイス・リポジトリをアクティブ化するか、サードパーティのWURFLファイルをアップロードできます。『Oracle WebCenter Sitesでの開発』を参照してください。

- イメージのプロパティ: 開発者が、デバイス・イメージのプロパティを最適化設定するために使用します。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- 訪問者の管理: 開発者は、WebCenter SitesのAdminインタフェースを介してVisitor Servicesを構成、管理できます。次の各オプションを使用すると、サーバーを再起動せずに、集計テンプレートとプロバイダを追加、削除および変更できます。

- アイデンティティ・プロバイダ: 開発者は、Oracle Access Manager (OAM)を交換するためにカスタム・アイデンティティ・プロバイダを作成、構成できます。

- アクセス・プロバイダ: 開発者は、アクセス・プロバイダを構成できます。アクセス・プロバイダは、Visitor Services APIクライアントを介してVisitor Servicesからのプロファイル情報をリクエストし、コンポーネント(WebCenter SitesおよびEngage)の資格証明を検証します。

- プロファイル・プロバイダ: 開発者は、顧客プロファイル・プロバイダを作成、構成できます。デフォルトで、LDAPおよびEloqua用のプロファイル・プロバイダが用意されています。

- 集計テンプレート: 開発者は、各プロファイル・プロバイダが提供する属性を識別するテンプレートを作成し、類似した属性(属性名が異なっている場合を含む)を、訪問者プロファイルを横断して識別して集計できます。

- 一般構成: 開発者は、Visitor ServicesのインスタンスをWebCenter Sitesに構成でき、それによって、WebCenter SitesがREST API、Java APIおよびJavaScript APIを介してVisitor Servicesからプロファイルをリクエストできるようになります。

10.3.2 コンテンツ・ツリーの開発者ノードについて

「コンテンツ」ツリーは、デザイン・アセット(たとえばWebCenter Sitesシステム上で作成されたTemplate、SiteEntryおよびAttributeアセット)にアクセスするショートカットを開発者に提供します。

開発者に、次の種類のアセットへのアクセスを提供します。

- 属性

- 属性エディタ

- 説明

- 親定義

- ページ属性

- ページ定義

- テンプレート

- CSElement

開発者は、アセット・タイプ・ノードを開いて、そのタイプから作成されたすべてのアセットを表示できます。

10.4 各種のツリーとノード

Adminインタフェースには、デフォルトの非管理ツリーおよびノード、および別の管理者によって構成されている場合はカスタムのツリーとノードが表示されます。必要に応じてその他のツリーとノードを作成できます。ツリーとノードの作成および構成の詳細は、ツリーへのアクセスを管理するためのオプション(Adminインタフェースのみ)を参照してください。

デフォルトの各種ツリーおよびノードは、次のとおりです。

- 「ワーク」ツリー:

- ブックマーク: ブックマークされたページのリストを保持しています。よく使用されるページをマークしておくと、このタブから簡単に見つけてアクセスできます。

- 履歴: 現在のセッションで使用したアセットが表示されます。このタブは、すべてのユーザーに対して、最初のアセットの作成、調査、編集またはコピー直後に表示されます。

- 「サイト」ツリー配下の「サイト・ナビゲーション」ノード: サイトのレイアウトと概要を示します。このタブには、WebCenter Sitesによって制御されている各サイトが表示されます。
「配置済」ページと「未配置」ページのリストが表示されます。配置済ページは、作成され、ライブ・サイトに統合されたページです。未配置ページは、完成しているが、ライブ・サイトに統合されていないページです。

デバイス・グループをナビゲーションに関連付けるときに選択した接尾辞に基づいて、「デフォルト」、「タッチ」またはNonTouchなどのノードが表示されます。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

10.5 システム・デフォルトについて

WebCenter Sitesには、次に示すように、数多くのシステム・デフォルトがあります。

- ツリーおよびツリー・ノード

- ACL

- ロール

- ユーザー

- アセット・タイプ

- システム表

ユーザーおよびサイトを構成するために、デフォルトについて習熟する必要があります。システム・デフォルトの詳細は、システム・デフォルトおよびWebCenter Sitesのデータベース表を参照してください。

11 Webエクスペリエンス管理フレームワークの使用

次の各トピックでは、Webエクスペリエンス管理(WEM)フレームワークとその管理者について説明します。

- WEM 管理ウィンドウについて

- Webエクスペリエンス管理フレームワークの概要

- 管理ロールおよび権限

- WebCenter Sitesアプリケーション

- WEMフレームワークでのWebCenter Sites CMサイトの管理

- ツリー・タブの有効化

- WEMフレームワークの管理 - 簡単なヒントとロードマップ

- WebCenter Sites管理者の共通WEMタスク

11.1 WEM 管理ウィンドウについて

WEMのAdminインタフェースには、Webエクスペリエンス管理(WEM)フレームワークが表示されます。WEMフレームワークはWebCenter Sites上で実行され、開発者がアプリケーションを作成して、WebCenter Sitesと統合するのを可能にします。WEM Adminインタフェースは、管理者がWebCenter Sitesシステムのサイト、アプリケーション、ユーザーおよびロールを管理するために使用します。主要な機能は、ロールを使用して、アプリケーションとユーザーをWebCenter Sitesシステムのサイトに結合することです。

WEM Adminは、一般管理者およびサイト管理者の機能のみをサポートします。このインタフェースにアクセスするには、WEMフレームワークがWebCenter Sites上で実行されており、AdminSiteへのアクセス権を持っていて、GeneralAdminかSiteAdminロールを割り当てられている必要があります。

WEM Adminが開くと、表示される最初の画面は「サイト」リストです。一般管理者には、WebCenter Sitesシステム上で作成されるすべてのサイトが表示されますが、サイト管理者には、SiteAdminロールを割り当てられたサイトのみ表示されます。WEM Adminインタフェースの最上部のメニュー・バーには、次のオプションが表示されます。

- サイト: このオプションをクリックすると、GeneralAdminかSiteAdminロールを割り当てられたWebCenter Sitesシステム上のすべてのサイトのリストが表示されます。一般管理者の場合、サイトのリストより上に「サイトの追加」オプションが表示されます。「サイトの追加」オプションをクリックすると、新しいコンテンツ管理サイトが作成されます。WEM Adminでの「サイト」リストの使用の詳細は、WEM Adminインタフェースでのサイトの管理を参照してください。

- アプリケーション: このオプションをクリックすると、WebCenter Sitesシステム上のサイトに割り当てることができるすべてのアプリケーションのリストが表示されます。「アプリケーション」リストの使用の詳細は、アプリケーションの管理を参照してください。

- ユーザー: このオプションをクリックすると、WebCenter Sitesシステムに作成されたすべてのユーザーのリストが表示されます。一般管理者の場合、ユーザーのリストより上に「ユーザーの追加」オプションが表示されます。このオプションをクリックすると、新しいWebCenter Sitesユーザーが作成されます。WEM Adminでの「サイト」リストの使用の詳細は、WEM Adminインタフェースでのサイトの管理を参照してください。

- ロール: このオプションをクリックすると、WebCenter Sitesシステムに作成されたすべてのロールのリストが表示されます。一般管理者の場合、ロールのリストより上に「ユーザー・ロールの追加」オプションが表示されます。このオプションをクリックすると、WebCenter Sitesシステムに新しいユーザー・ロールを作成できます。「ロール」リストの詳細は、WEM Adminインタフェースからのロールの管理を参照してください。

- 「下」/「上」向きの矢印: メニュー・バーの右上にあります。矢印をクリックすると、アプリケーション・バーが開くか、閉じます。アプリケーション・バーからは、別のサイトまたはアプリケーションに切り替えたり、WebCenter Sitesプロファイルを編集したり、WebCenter Sitesをログアウトしたりできます。アプリケーション・バーからのプロファイルの変更の詳細は、自分のプロファイルの変更を参照してください。

WEM Adminインタフェースの使用と、一般管理者またはサイト管理者としてWEM Adminで実行できる機能に関する詳細は、次のトピックを参照してください。

- Webエクスペリエンス管理フレームワークの概要

- 管理ロールおよび権限

- WebCenter Sitesアプリケーション

- WEMフレームワークでのWebCenter Sites CMサイトの管理

- ツリー・タブの有効化

- WEMフレームワークの管理 - 簡単なヒントとロードマップ

- WebCenter Sites管理者の共通WEMタスク

11.2 Webエクスペリエンス管理フレームワークの概要

Oracle Webエクスペリエンス管理(WEM)フレームワークは、アプリケーションを開発し、そのアプリケーションをOracle WebCenter Sitesと統合するためのテクノロジを備えています。単一の管理インタフェースであるWEM Adminは、アプリケーション管理およびユーザー認可の一元化をサポートします。シングル・サインオンを使用すると、ユーザーは一度ログインするだけで、セッションの継続中は使用可能なすべてのアプリケーションにアクセスできます。

WEMフレームワークを使用するには、コンテンツ管理プラットフォームが必要です。フレームワークは、WebCenter Sites上で動作し、WebCenter Sites Representational State Transfer (REST) APIを備えています。サイト、ユーザーおよびデータ・モデルなど、WebCenter Sitesデータベース内のオブジェクトは、WEMフレームワークでRESTリソースにマッピングされます。

WEMフレームワーク上に実装されたアプリケーションは、RESTサービスを使用してWebCenter Sitesデータベースと通信します(図11-1 )。このアプリケーションは、WEM Adminで「アプリケーション」ページのリスト項目として表示されます。管理者がユーザーを認可する際に、アプリケーションおよびそのリソースへのアクセスが構成されます。

図11-1 WEMフレームワーク

図11-2 に示すようにアイテムを結合することによって、ユーザーにアプリケーションの使用を許可します。

図11-2 認可モデル

- アプリケーションとユーザーは、ロールを介してサイトに割り当てられます。

- 同じサイト上のユーザーとアプリケーションでロールを共有すると、そのサイト上のアプリケーションへのアクセスがユーザーに付与されます。

- ACLはユーザーに割り当てられ、システムへのアクセスを提供します。

WEM Adminを使用して、一般管理者は、サイト、アプリケーション、ユーザーおよびロールを、作成およびその他の方法で管理できます。グループとACLは、WebCenter Sites Adminインタフェースで構成する必要があります。それらは、WEM Adminのユーザー・アカウントに表示されます。

結合が完了すると、ユーザーは、データベース・レベル、RESTレベルおよびアプリケーション・レベルで認可されます。

図11-3 WEMフレームワーク

習熟したWebCenter Sites管理者であれば、WEM Adminインタフェースによって、アプリケーションへのアクセスを制御するためのサイトおよびロールの用途が拡張されることがわかります。ロールをアプリケーション内で使用して、(WebCenter Sitesと同様に)インタフェース機能を保護し、それによってアプリケーションのコンテンツへのアクセスを制限することもできます。

WebCenter Sitesとは異なり、WEM Adminはデータ・モデルを公開しません。REST APIが公開します。この点においてWEM Adminは厳密な意味での認可インタフェースとみなすことができ、(ACLおよびグループの構成用に)WebCenter Sites Adminインタフェースでサポートされます。このガイドの以降の章では、ユーザーの作成と認可手順、およびサイト管理のガイドラインについて説明します。

11.3 管理ロールおよび権限

WEMフレームワークでは、一般管理者とサイト管理者の2つのタイプの管理者をサポートしています。

この項の内容は次のとおりです。

- 一般管理者

- サイト管理者

11.3.1 一般管理者

一般管理者は、システム全体を制御し、WEM Adminインタフェースのサイト、アプリケーション、ユーザーおよびロールに対する完全な権限を持っています。一般管理者は、WEM Adminを使用して、サイト、アプリケーション、ユーザーおよびロールの追加と削除、それらの詳細の変更、および認可タスクの実行を行うことができます。

WEMフレームワークの一般管理者は、WEMフレームワーク向けに特別に構成されているWebCenter Sitesの一般管理者でもあります。デフォルトの一般管理者(fwadmin)は、WebCenter Sitesインストール・プロセスの実行中に、自動的にRestAdminグループに割り当てられてRESTサービスへの無制限アクセスを取得し、デフォルトでWEM Adminアプリケーションが実行されているAdminSite上で有効になっています。デフォルトの一般管理者は削除しないでください。

同等の一般管理者を必要な数だけ作成し、RestAdminグループとAdminSiteに追加することによって(GeneralAdminロールを使用)、既存の一般管理者を変更する必要があります。手順は、ユーザーの作成と認可を参照してください。

11.3.2 サイト管理者

一般管理者は選択したサイトに特定の管理者を割り当て、そのサイト管理者がサイトのユーザーとアプリケーションを管理します。AdminSite以外のサイトのSiteAdminロールが割り当てられたユーザーには、暗黙的にAdminSiteのSiteAdminロールが割り当てられます。ユーザーにAdminSiteのみのSiteAdminロールを割り当てることはできません。

サイト管理者がWEM Adminインタフェースでアクセスできるのは、「サイト」フォームのみです。 次の管理タスクを実行できます。

- サイトへのユーザーの割当ておよびサイトからのユーザーの削除

- サイトへのアプリケーションの割当ておよびサイトからのアプリケーションの削除

- サイト・ユーザーのロール割当ての変更

- サイトでのアプリケーションのロール割当ての変更

サイト管理者は、サイト、ユーザーまたはロールを作成、変更または削除できません。サイト管理者は、サイトのパラメータの範囲内でそれらがどのように結び付いているかを判定します。WEM Adminのどのフォームおよびインタフェース機能にアクセスできるかは権限によって決まります。

WEMフレームワークを実行しているWebCenter Sitesシステム上で、WEMのサイト管理者を別個に構成する必要があります。それらは、WebCenter Sites Adminインタフェースで構成されるデフォルトのRESTセキュリティ・グループであるSiteAdmin_AdminSiteグループに割り当てる必要があります。手順は、ユーザーの作成を参照してください。

11.4 WebCenter Sitesアプリケーション

ContributorインタフェースおよびAdminインタフェースは、登録済アプリケーションです。これらは、WEM Adminインタフェースの「アプリケーション」ページにリストされます。WebCenter Sitesユーザーは、アプリケーション・レベルで認可された後、WEMフレームワークからアプリケーションにアクセスできます。また、WebCenter Sitesアプリケーションには、通常のURLを使用して引き続き直接アクセスできます。

11.5 WEMフレームワークでのWebCenter Sites CMサイトの管理

WEM Adminインタフェースを使用してサイトを削除または変更する場合、そのサイトがWebCenter Sitesプラットフォームのアクティブなコンテンツ管理サイトではないことを確認します。WEM Adminインタフェースからサイトを削除すると、サイトがシステムと、さらにそのサイトが使用されていたすべてのアプリケーションから削除されます。サイトを削除しようとすると、決定の確認を求められます。サイトのステータスを決定したとみなされます。

他のオブジェクト(たとえばロール)にも同じことが言えますが、1つ相違があります。それは、ユーザーとアプリケーションに割り当てられたロールを削除しようとすると、ロールを削除する前にクリアする必要がある依存性のリストが表示される点です。

WebCenter SitesアプリケーションをアクティブなWebCenter Sites CMサイトで稼働するように構成し、自らをそのサイトに割り当てると、WEM Adminでそのサイトを公開して簡単にアクセスできます。例:

1. AdminインタフェースのWEM Adminで、「サイト」ページにサイトがリストされます。

2. サイトに移動し、「サイト・アプリケーションの管理」をクリックします。

アプリケーションが割り当てられていない場合、サイトは非アクティブとみなされる可能性があります。

3. WebCenter Sites Adminアプリケーションと自身をサイトに割り当てると、サイトはサイト・メニュー(アプリケーション・バーにある)のオプションとしてリストされます(必要に応じて、表示をリフレッシュします)。

4. ログイン・ダイアログを開くには、メニューからサイトを選択します。サイトがメニューにリストされます。

ログインすると、WebCenter Sites Adminアプリケーション・アイコンが左上にあり、サイトの名前は右上のドロップダウン・メニューにあります。後続のアクセスではログインは必要ありません。

11.6 ツリー・タブの有効化

Adminインタフェースで作成されたサイトは、Adminインタフェースで公開されますが、Adminインタフェースで使用できるように構成されているわけではありません。一般管理者は、タブごとにWebCenter Sitesツリーを有効化することによって、各サイトでの操作を有効化する必要があります。

WEMサイト向けのWebCenter Sites Adminインタフェースのツリーおよびタブを有効化するには:

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. WEM Adminインタフェースで作成したサイトに関連するWebCenter Sitesツリーのタブを有効化します。

a. WebCenter Sitesツリーに移動し、「管理」タブを選択します。

b. 「ツリー」ノードをダブルクリックします。

c. 有効化する各タブを個別に選択します。たとえば、「サイト・デザイン」タブを有効化するとします。

i. ツリー・タブのリストから、「サイト・デザイン」をクリックします。

ii. 「ツリー・タブ」フォームで、「編集」をクリックします。
「サイト・デザイン」タブの「編集」フォームが表示されます。

iii. 「サイト」選択ボックスで、タブを有効化する必要があるサイトを選択します。

iv. タブへのアクセスを許可するロールを選択します。

v. タブのコンテンツを選択します。

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

vii. 他のタブを有効化する必要がある場合は、「編集」フォームの一番下にある「すべてのツリー・タブのリスト」をクリックして、前述の手順を繰り返します。

3. WebCenter Sitesツリーとタブをサイトで有効にしたら、次の項に進んで、ツリーとタブが正しく表示されることを確認します。

ツリー・タブが有効化されていることを検証するには:

前の項で有効化したタブへのアクセスは、各タブとロールを共有しているユーザーにのみ許可されます。ツリーとタブが有効化されていることをサイトごとに検証します。

1. WebCenter Sites Adminインタフェースに、特定のタブ(または特定の複数のタブ)に割り当てられているロールのいずれかを共有するユーザーとしてログインします。

2. サイトを選択します。WebCenter Sitesツリーが、選択したサイトで有効化したタブとともに表示されます。

3. WebCenter Sitesツリーが有効化されていない場合、次のエラー・メッセージが表示されます。

図11-4 エラー・メッセージ

ユーザーおよびタブに対するサイトとロールの割当てを検証します。

11.7 WEMフレームワークの管理 - 簡単なヒントとロードマップ

この項の残りの手順を実行する前に、いくつかのヒントを書き留めておきます。

- (オプション)WEMのサイト、ユーザーおよびロールを試す場合は、WebCenter Sites CM専用のサイト、ユーザーおよびロールと区別することをお薦めします。たとえば、サイト/ユーザー/ロールに説明を追加する、名前に「WEM」」などの接頭辞を追加する、などの方法があります。サイト、ユーザーまたはロールを作成した後に名前を変更することはできません。

- ユーザー・アカウントにはACLが必要です。ACLを作成できるのは、一般管理者のみ、そしてWebCenter Sites 管理ノードの下にある「一般的な管理」のみです。

- ユーザーおよびアプリケーションにロールを割り当てると、そのサイトの当該アプリケーションへのアクセス権がユーザーに付与されます。

- アプリケーションのインタフェース機能はロールで保護できます。ユーザーおよびインタフェース機能でロールを割り当てると、そのインタフェース機能へのアクセス権がユーザーに付与されます。

- グループは、RESTリソースへのアクセスを提供します。グループは、WebCenter Sites Adminインタフェースで構成する必要があります。

- グループは、アプリケーションのリソースへのアクセスの制御に使用されます。
カスタム構築アプリケーションで事前定義済ユーザーが指定されていない場合は、アプリケーション・レベルおよびRESTレベルでアプリケーション・ユーザーを認可します。

カスタム構築アプリケーションで事前定義済ユーザーが指定されている場合は、システム・レベル、アプリケーション・レベルおよびRESTレベルでそのユーザーを認可します。アプリケーション・ユーザーはアプリケーション・レベルで認可します。

11.8 WebCenter Sites管理者の共通WEMタスク

WEM Adminインタフェースを使用して、サイト、アプリケーション、ユーザーおよびロールを作成および管理します。

- WEM Adminインタフェースでのサイトの管理

- アプリケーションの管理

- WEM Adminインタフェースでのユーザーの管理

- WEM Adminインタフェースからのロールの管理

- WEM Adminインタフェースからのプロファイルの管理

11.8.1 WEM Adminインタフェースでのサイトの管理

サイトを作成、編集および削除できるのは、一般管理者のみです。「サイト」フォームには、一般管理者とサイト管理者がアクセスできます。

WEMのAdminインタフェースでサイトを管理するには、次のトピックを参照してください。

- WEM Adminインタフェースでのサイトの作成

- WEM Adminインタフェースでのサイトの編集

- WEM Adminインタフェースでのサイトの削除

- WEM Adminインタフェースのサイト・リストからサイトへのアプリケーションの追加

- WEM Adminインタフェースのサイト・リストのサイトへのユーザーの割当て

- WEM Adminインタフェースのサイト・リストからユーザーへのロールの再割当て

- WEM Adminインタフェースのサイト・リストからアプリケーションへのロールの再割当て

- WEM Adminインタフェースのサイト・リストのサイトからのユーザーの削除

- WEM Adminインタフェースのサイト・リストのサイトからのアプリケーションの削除

11.8.1.1 WEM Adminインタフェースでのサイトの作成

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、「サイトの追加」をクリックします。

3. 「サイトの追加」フォームで、サイトの名前と説明を入力します。

4. 「保存して閉じる」をクリックします。

サイトの名前が「サイト」リストにリストされます。

11.8.1.2 WEM Adminインタフェースでのサイトの編集

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、編集するサイトを選択し、「編集」オプションをクリックします。

3. 「サイトの編集」フォームで、サイトの名前または説明を変更します。

4. 「保存して閉じる」をクリックします。

編集したサイトが「サイト」リストにリストされます。

11.8.1.3 WEM Adminインタフェースでのサイトの削除

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、削除するサイトを選択し、「削除」をクリックします。

3. 「警告」ダイアログで、「削除」をクリックします。

サイトが、WEM Adminインタフェースの「サイト」リスト、Adminインタフェースの「管理」ツリーおよびWebCenter Sitesシステムから削除されます。

11.8.1.4 WEM Adminインタフェースのサイト・リストからサイトへのアプリケーションの追加

アプリケーションをサイトに追加する別の方法を必要とする一般管理者は、アプリケーションの管理を参照してください。

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、アプリケーションを追加するサイトを選択し、「サイト・アプリケーションの管理」、「アプリケーションの割当て」の順に選択します。

3. 「サイトのアプリケーションの選択」フォームでサイトに追加するアプリケーションを選択し、「選択済」リストに移動します。

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

5. 「アプリケーションへのロールの割当て」フォームでアプリケーションに割り当てるロールを選択し、「選択済」リストに移動します。

6. 「保存して閉じる」をクリックします。

11.8.1.5 WEM Adminインタフェースのサイト・リストのサイトへのユーザーの割当て

サイトにユーザーを追加する別の方法を必要とする一般管理者は、WEMの管理者インタフェースでのユーザーの管理を参照してください。

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、ユーザーを割り当てるサイトを選択し、「サイト・ユーザーの管理」、「ユーザーの割当て」の順に選択します。

3. 「サイトのユーザーの選択」フォームでサイトに割り当てるユーザーを選択し、「選択済」リストに移動します。

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

5. 「ユーザーへのロールの割当て」フォームでユーザーに割り当てるロールを選択し、「選択済」リストに移動します。

6. 「保存して閉じる」をクリックします。

11.8.1.6 WEM Adminインタフェースのサイト・リストからユーザーへのロールの再割当て

注意: WEMでサイトのユーザーのロールを再割当てすると、ユーザーとそのサイトの一部のアプリケーションの結合が解除される可能性があります。

ロールをユーザーに再割当てするには:

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、ユーザーを変更するサイトを選択し、「サイト・ユーザーの管理」を選択します。

3. 「サイト・ユーザーの管理」フォームで、サイト・ロールを変更するユーザーを選択し、続いて「ユーザーへのロールの割当て」を選択します。

4. 「ユーザーへのロールの割当て」フォームで、必要に応じて新しいロールをサイト・ユーザーに割り当てるか、ロールの割当てを解除します。

5. 「保存して閉じる」をクリックします。

注意: サイトでユーザー・ロールを変更する別の方法を必要とする一般管理者は、WEM Adminインタフェースのユーザー・リストからユーザーへのロールの再割当てを参照してください。

11.8.1.7 WEM Adminインタフェースのサイト・リストからアプリケーションへのロールの再割当て

注意: WEMでサイトのアプリケーションのロールを再割当てすると、アプリケーションとそのサイトの一部のユーザーの結合が解除される可能性があります。ロールをアプリケーションに再割当てするには:

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、アプリケーションを変更するサイトを選択し、「サイト・アプリケーションの管理」を選択します。

3. 「サイト・アプリケーションの管理」フォームで、サイト・ロールを変更するアプリケーションを選択し、続いて「アプリケーションへのロールの割当て」を選択します。

4. 「アプリケーションへのロールの割当て」フォームで、必要に応じて新しいロールをアプリケーションに割り当てるか、ロールの割当てを解除します。

5. 「保存して閉じる」をクリックします。

注意: サイトのアプリケーションのロールを変更する別の方法を必要とする一般管理者は、アプリケーションの管理を参照してください。

11.8.1.8 WEM Adminインタフェースのサイト・リストのサイトからのユーザーの削除

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、ユーザーを削除するサイトを選択し、「サイト・ユーザーの管理」を選択します。

3. 「サイト・ユーザーの管理」フォームで、サイトから削除するユーザーを選択し、続いて「除去」をクリックします。

4. 「警告」ダイアログで、「除去」をクリックします。

注意: 特定のサイトからユーザーを削除する別の方法を必要とする一般管理者は、WEMの管理者インタフェースでのユーザーの管理を参照してください。

11.8.1.9 WEM Adminインタフェースのサイト・リストのサイトからのアプリケーションの削除

1. WEM Adminインタフェースで、メニュー・バーの「サイト」オプションを選択します。

2. 「サイト」リストで、アプリケーションを削除するサイトを選択し、「サイト・アプリケーションの管理」を選択します。

3. 「サイト・アプリケーションの管理」フォームで、サイトから削除するアプリケーションを選択し、続いて「除去」をクリックします。

4. 「警告」ダイアログで、「除去」をクリックします。

注意: サイトからアプリケーションを削除する別の方法を必要とする一般管理者は、アプリケーションの管理を参照してください。

11.8.2 アプリケーションの管理

アプリケーションを変更できるのは、一般管理者のみです。「アプリケーション」フォームには、一般管理者のみがアクセスできます。

次の各トピックでは、WEM Adminインタフェースからのアプリケーションの管理について説明します。

- アプリケーションの変更

- WEM Adminインタフェースでのアプリケーションのサイトへの割当て

- WEM Adminインタフェースのアプリケーション・リストからアプリケーションへのロールの再割当て

- WEM Adminインタフェースのアプリケーション・リストのサイトからのアプリケーションの削除

11.8.2.1 アプリケーションの変更

1. WEM Adminインタフェースで、メニュー・バーの「アプリケーション」オプションを選択します。

2. 「アプリケーション」リストで、変更するアプリを選択し、続いて「編集」を選択します。

3. 「編集」フォームで、次のフィールドを更新します。

- 名前: 変更できません。

- ツールチップ: アプリケーション・アイコンにカーソルを重ねたときに開く名前。

- 説明: アプリケーションの簡単な説明。

4. 「保存して閉じる」をクリックします。

11.8.2.2 WEM Adminインタフェースでのアプリケーションのサイトへの割当て

1. WEM Adminインタフェースで、メニュー・バーの「アプリケーション」オプションを選択します。

2. 「アプリケーション」リストで、サイトに割り当てるアプリケーションを選択し「アプリケーションの管理」を選択し、続いて「サイトへの割当て」を選択します。

3. 「アプリケーションのサイトの選択」フォームでアプリケーションを割り当てるサイトを選択し、「選択済」リストに移動します。

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

5. 「アプリケーションへのロールの割当て」フォームでアプリケーションに割り当てるロールを選択し、「選択済」リストに移動します。

6. 「保存して閉じる」をクリックします。

サイトにアプリケーションを追加する別の方法は、WEM Adminインタフェースでのサイトの管理を参照してください。

11.8.2.3 WEM Adminインタフェースのアプリケーション・リストからアプリケーションへのロールの再割当て

注意: WEMでサイトのアプリケーションのロールを再割当てすると、アプリケーションとそのサイトの一部のユーザーの結合が解除される可能性があります。

ロールをアプリケーションに再割当てするには:

1. WEM Adminインタフェースで、メニュー・バーの「アプリケーション」オプションを選択します。

2. 「アプリケーション」リストで、選択したサイトにあわせてロールを変更するアプリケーションを選択し、続いて「アプリケーションの管理」を選択します。

3. 「アプリケーションの管理」フォームで、アプリケーション・ロールを変更するサイトを選択し、続いて「アプリケーションへのロールの割当て」を選択します。

4. 「アプリケーションへのロールの割当て」フォームで、必要に応じてロールをアプリケーションに追加するか、ロールを削除します。

5. 「保存して閉じる」をクリックします。

注意: サイトでアプリケーション・ロールを変更する別の方法は、WEM Adminのサイト・リストからアプリケーションへのロールの再割当てを参照してください。

11.8.2.4 WEM Adminインタフェースのアプリケーション・リストのサイトからのアプリケーションの削除

1. WEM Adminインタフェースで、メニュー・バーの「アプリケーション」オプションを選択します。

2. 「アプリケーション」リストで、サイトから削除するアプリケーションを選択し、続いて「アプリケーションの管理」を選択します。

3. 「アプリケーションの管理」フォームで、アプリケーションを削除するサイトを選択し、続いて「除去」をクリックします。

4. 「警告」ダイアログで、「除去」をクリックします。

注意: アプリケーションをサイトから削除する別の方法は、WEMの管理者インタフェースでのサイトの管理を参照してください。

11.8.3 WEM Adminインタフェースでのユーザーの管理

ユーザーを作成、編集および削除できるのは、一般管理者のみです。「ユーザー」フォームには、一般管理者のみがアクセスできます。

次の各トピックでは、WEM Adminインタフェースからのユーザーの管理について説明します。

- WEM Adminインタフェースのユーザー・リストからのユーザーの作成

- WEM Adminインタフェースでのユーザー・リストからのユーザーの有効化

- WEM Adminインタフェースでのユーザー・リストからサイトへのユーザーの割当て

- WEM Adminインタフェースでのユーザー・リストからのユーザーの編集

- WEM Adminインタフェースでのユーザー・リストからユーザーへのロールの再割当て

- WEM Adminインタフェースからのユーザーのグループへの割当て

- WEM Adminインタフェースのユーザー・リストでのサイトからのユーザーの削除

- WEM Adminインタフェースでのユーザー・リストからのWebCenter Sitesユーザーの削除

11.8.3.1 WEM Adminインタフェースのユーザー・リストからのユーザーの作成

1. WEM Adminインタフェースで、メニュー・バーから「ユーザー」オプションを選択し、「ユーザーの追加」をクリックします。

2. 「ユーザーの追加」フォームで、次のフィールドを更新します。

ACL: ACLはユーザーのデータベースに対するアクセス権限を決定します。

注意: WEM AdminインタフェースではACLを作成できません。

グループ: グループはユーザーのRESTアプリケーション・リソースに対するアクセス権限を決定します。RestAdmin (一般管理者グループ)およびSiteAdmin_AdminSite (サイト管理者グループ)の2つのデフォルト・グループが構成されています。

3. 「保存して閉じる」をクリックします。

注意: ユーザーを作成すると、そのユーザーはログインできます。サイトとアプリケーションにアクセスするには、ユーザーを有効化する必要があります。

11.8.3.2 WEM Adminインタフェースでのユーザー・リストからのユーザーの有効化

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、有効化するユーザーを選択し、「ユーザーの管理」を選択し、続いて「サイトへの割当て」を選択します。

3. 「ユーザーのサイトの選択」フォームで次を実行します。

- 一般管理者を有効化する場合は、ユーザーをAdminSiteに割り当てます。

- サイト管理者を有効化する場合は、ユーザーをAdminSite以外のサイトに割り当てます。

- 一般ユーザーを有効化する場合は、ユーザーをAdminSite以外のサイトに割り当てます。

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

5. 「ユーザーへのロールの割当て」フォームで次を実行します。

- 一般管理者を有効化する場合は、ユーザーにGeneralAdminロールを割り当てます。

- サイト管理者を有効化する場合は、ユーザーにSiteAdminロールを割り当てます。

- 一般ユーザーを有効化する場合は、ユーザーにGeneralAdminでもSiteAdminでもないロールを割り当てます。

6. 「保存して閉じる」をクリックします。

11.8.3.3 WEM Adminインタフェースでのユーザー・リストからサイトへのユーザーの割当て

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、サイトに割り当てるユーザーを選択し、「ユーザーの管理」を選択し、続いて「サイトへの割当て」を選択します。

3. 「ユーザーのサイトの選択」フォームでユーザーに割り当てるサイトを選択し、「選択済」リストに移動します。

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

5. 「ユーザーへのロールの割当て」フォームでユーザーに割り当てるロールを選択し、「選択済」リストに移動します。

6. 「保存して閉じる」をクリックします。

サイトにユーザーを追加する別の方法は、WEM Adminインタフェースでのユーザーの管理を参照してください。

11.8.3.4 WEM Adminインタフェースでのユーザー・リストからのユーザーの編集

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、変更するユーザーを選択し、「編集」をクリックします。

3. 「ユーザーの編集」フォームで、フィールドを更新し、続いて「保存して閉じる」をクリックします。

注意: ユーザーが保存された後でユーザー名(「名前」フィールドに表示)を変更することはできません。

11.8.3.5 WEM Adminインタフェースでのユーザー・リストからユーザーへのロールの再割当て

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、ロールを変更するユーザーを選択し、続いて「ユーザーの管理」を選択します。

3. Manage Userフォームで、ユーザー・ロールを変更するサイトを選択し、「ユーザーへのロールの割当て」をクリックします。

4. 「ユーザーへのロールの割当て」フォームで、必要に応じてロールをユーザーに追加するか、ロールを削除します。

5. 「保存して閉じる」をクリックします。

11.8.3.6 WEM Adminインタフェースからのユーザーのグループへの割当て

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、グループに割り当てるユーザーを選択し、続いて「編集」を選択します

3. 「グループ」フィールドで適切なグループを選択し、「選択済」リストに移動します。

4. 「保存して閉じる」をクリックします。

注意: グループは、RESTに対するアクセスを提供します。これらはアプリケーションのリソースへのアクセスの制御に使用されます。

11.8.3.7 WEM Adminインタフェースのユーザー・リストでのサイトからのユーザーの削除

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、サイトから削除するユーザーを選択し、続いて「ユーザーの管理」を選択します。

3. 「ユーザーの管理」フォームで、ユーザーを削除するサイトを選択し、続いて「除去」をクリックします。

4. 「警告」ダイアログで、「除去」をクリックします。

サイトからユーザーを削除する別の方法は、WEM Adminインタフェースのサイト・リストでのサイトからのユーザーの削除を参照してください。

11.8.3.8 WEM Adminインタフェースでのユーザー・リストからのWebCenter Sitesユーザーの削除

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、システムから削除するユーザーを選択し、続いて「削除」をクリックします。

3. 「警告」ダイアログで、「削除」をクリックします。

11.8.4 WEM Adminインタフェースからのロールの管理

ロールを作成、編集および削除できるのは、一般管理者のみです。「ロール」フォームには、一般管理者のみがアクセスできます。

次の各トピックでは、WEM Adminインタフェースからのロールの管理について説明します。

- WEM AdminインタフェースからのWebCenter Sitesシステムへのロールの追加

- WEM Adminインタフェースでのロール・リストからのロールの編集

- WEM Adminインタフェースでのロール・リストからのロールの削除

11.8.4.1 WEM AdminインタフェースからのWebCenter Sitesシステムへのロールの追加

1. WEM Adminインタフェースで、メニュー・バーの「ロール」オプションを選択します。

2. 「ロール」リストで、「ユーザー・ロールの追加」をクリックします。

3. 「ロールの追加」フォームで、ロールの名前と説明を入力し、続いて「保存して閉じる」をクリックします。

11.8.4.2 WEM Adminインタフェースでのロール・リストからのロールの編集

1. WEM Adminインタフェースで、メニュー・バーの「ロール」オプションを選択します。

2. 「ロール」リストで、変更するロールを選択し、続いて「編集」をクリックします。

3. 「ロールの編集」フォームで、説明フィールドを更新し、続いて「保存して閉じる」をクリックします。

注意: ロールを保存した後は、ロールの名前は変更できません。

11.8.4.3 WEM Adminインタフェースでのロール・リストからのロールの削除

1. WEM Adminインタフェースで、メニュー・バーの「ロール」オプションを選択します。

2. 「ロール」リストで、削除するロールを選択し、続いて「削除」をクリックします。

3. 「警告」ダイアログで、「削除」をクリックします。

ロールが、ユーザーとアプリケーションのいずれかまたは両方に割り当てられている場合、ユーザーやアプリケーションから割当て解除するまでロールを削除できません。「ロールの依存性」フォームで依存性の表を確認します。「すべての依存性の削除」は、ロールをそのユーザーおよびアプリケーションから削除し、システムからロールを削除します。

11.8.5 WEM Adminインタフェースからのプロファイルの管理

一般管理者は、ユーザー・プロファイルを変更できます。

次の各トピックでは、ユーザー・プロファイルの変更について説明します。

- ユーザー・プロファイルの変更

- 自身のプロファイルの変更

11.8.5.1 ユーザー・プロファイルの変更

1. WEM Adminインタフェースで、メニュー・バーの「ユーザー」オプションを選択します。

2. 「ユーザー」リストで、プロファイルを変更するユーザー名を選択し、続いて「編集」をクリックします。

3. 「ユーザーの編集」フォームで、目的のフィールドを更新し、続いて「保存して閉じる」をクリックします。

注意:

「名前」フィールドの値は変更できません。

11.8.5.2 自身のプロファイルの変更

1. WEM Adminインタフェースで、アプリケーション・バーを開き、続いて自身のユーザー名をクリックします。

2. 「プロファイルの編集」フォームで、フィールドを更新し、続いて「保存して閉じる」をクリックします。

注意:

「名前」フィールドの値は変更できません。

第IV部 ユーザーおよびセキュリティの管理

ユーザーは、WebCenter Sitesのネイティブのユーザー・マネージャ(Adminインタフェース内)またはLDAPのどちらかを使用して作成できます。ただし、ユーザー・プロファイルおよび属性を構成するには、Adminインタフェースを使用する必要があります。続いて管理者は、WebCenter Sitesリソースへのユーザー・アクセスを管理するために、管理および配信の両システム上に外部セキュリティ・プロトコルを構成します。

次の各トピックでは、WebCenter Sitesのユーザーとセキュリティの管理に関する情報を提供します。

- ユーザー、プロファイルおよび属性の構成

- 外部セキュリティの設定

12 ユーザー、プロファイルおよび属性の構成

次の各トピックではWebCenter Sitesでのユーザーの作成方法と、そのプロファイルおよびユーザー属性の構成方法を示します。外部ソースでのユーザーの作成の詳細は、製品のドキュメントを参照してください。

- WebCenter Sitesユーザーの作成について

- ユーザー管理オプションの理解

- WebCenter Sitesでのユーザーの構成

- ユーザー・アカウントの使用

- ユーザー・プロファイルとユーザー属性の使用

12.1 WebCenter Sitesユーザーの作成について

WebCenter Sitesユーザーは、WebCenter Sitesのネイティブのユーザー・マネージャ、WEM Admin、またはLDAPなどの外部ユーザー・マネージャを使用して作成できます。

各WebCenter Sitesユーザーは次のデータのセットで定義されます。

- ユーザー・アカウント。これにより、ユーザーにWebCenter Sitesシステムとそのデータベース表へのアクセスを付与します。

- ユーザー・プロファイル。これは、ユーザーが次に関する作業をするために必要です。

- WebCenter Sitesアプリケーション

- 言語パックとデフォルトの言語の設定

- ワークフロー参加者に割当てを通知するために電子メール・メッセージを送信するワークフロー・プロセス。ユーザー・プロファイルは、電子メール・アドレスにユーザー名をマップすることで、ワークフロー・アクションをサポートします。

- ユーザー属性(ユーザー・プロファイルの電子メールおよびロケールの属性に加えて)。ワークフローに加えてアクションおよびイベントがサポートされている必要があります。

ユーザーを作成および構成したら、ロールを使用して、作業するサイトと関連付ける必要があります。(ユーザーをサイトと関連付ける手順は、コンテンツ管理サイトのアセンブルを参照してください。)

12.2 ユーザー管理オプションの理解

WebCenter Sitesのディレクトリ・サービスAPIにより、認証情報、ユーザー情報などが保存されている外部ディレクトリ・サーバーまたはユーザー・マネージャにWebCenter Sitesシステムを接続できます。次の接続オプションを使用できます。

- Central Authentication Service (CAS): WebCenter Sitesネイティブのユーザー・マネージャで、ネイティブのWebCenter Sitesユーザー管理表、SystemUsersおよびSystemUserAttrsを使用します。

- Oracle Access Management: WebCenter Sitesは、Oracle Access Managementと統合して、継ぎ目のないシングル・サインオン・エクスペリエンスを提供します。セキュリティを最強にするため、本番環境でこの認証方法を使用することを強くお薦めします。

- LDAPディレクトリ: このオプションでは、ユーザー名および属性が、WebCenter Sitesデータベース以外のLDAPディレクトリ・サーバーに格納されます。セキュリティを最強にするため、本番環境で、Oracle Access Management統合の代替選択肢としてこの認証方法を使用することを強くお薦めします。

WebCenter SitesのセキュリティはACLを基盤としているため、外部ユーザー管理システム(Oracle Access ManagementやLDAPディレクトリなど)は、WebCenter Sites ACLと一致するように構成する必要があります。

外部認証ソリューションへの切替えに関する情報は、『Oracle WebCenter Sitesのインストールと構成』の、外部認証への切替えに関する項を参照してください。プラグインを構成するプロパティは、wcs_properties.jsonおよびldap.iniファイルにあります。これらのファイルについては、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』で説明しています。

注意:

このガイドでは、一貫してネイティブの(CAS) WebCenter Sitesユーザー・マネージャを使用します。

次のトピックでは、ユーザー管理オプションに関する情報を提供します。

- ネイティブのWebCenter Sitesユーザー・マネージャの理解

- LDAPプラグインの理解

12.2.1 ネイティブのWebCenter Sitesユーザー・マネージャの理解

ネイティブのWebCenter Sitesユーザー・マネージャを使用している場合、WebCenter Sitesの管理のロードマップのガイドラインに従ってユーザーを作成および構成し、管理システムへのアクセス権を付与します。

12.2.2 LDAPプラグインの理解

LDAPを使用して、管理システムまたは配信システムのユーザーを管理している場合、WebCenter Sites管理者のインタフェースではなくLDAPでユーザー・アカウントを作成します。ただし、WebCenter SitesデータベースにACLおよびロールを作成するには、依然として管理者のインタフェースを使用する必要があります。

12.3 WebCenter Sitesでのユーザーの構成

各WebCenter Sitesユーザーは、ユーザー・アカウント、ユーザー・プロファイル、および必要に応じてユーザー属性で完全に定義されています。

- ユーザー・アカウントは、WebCenter Sitesで作業するすべての人に必要です。

- ユーザー・プロファイルは、WebCenter Sitesモジュールおよび製品の作業、デフォルト言語の設定、および電子メール・メッセージを送信するワークフロー・プロセスへの参加をする予定のユーザーに必要です。

- 運用のために、ユーザー・プロファイルのロケールおよび電子メールの属性に加えてユーザー属性も必要な場合があります。その場合、追加の属性を作成できます。

ユーザーを作成したら、そのユーザーが作業する予定のサイトごとにそのユーザー名にロールを割り当てることで、適切なサイトに対してそのユーザーを有効化する必要があります。ユーザーの作成後の有効化の詳細は、ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)を参照してください。

新しいユーザーを作成して有効化した後、そのユーザーに次の情報を必ず指定してください。

- ユーザー・アカウントのユーザー名とパスワードの組合せ。

- WebCenter SitesのURL:
http://<server>:<port>/<context>/login

ここで

<server>は、WebCenter Sitesを実行するシステムのホスト名またはIPアドレスです。システムの設定によっては、ポート番号(たとえば、server:8080)も必要になる場合があります。

<context>は、同じサーバー上のWebアプリケーションの名前です。

ユーザー・アカウント、プロファイルおよび属性の作成、変更および削除の手順は、次の各トピックを参照してください。

- ユーザー・アカウントの使用

- ユーザー・プロファイルとユーザー属性の使用

12.4 ユーザー・アカウントの使用

次の各トピックでは、WebCenter Sites管理者のインタフェースでユーザーを作成、編集および削除する手順について説明します。

注意:

LDAPを使用している場合は、そのLDAP製品のドキュメントを参照してください。WEM Adminを使用している場合は、Webエクスペリエンス管理フレームワークの使用を参照してください。

また、そのガイドを読むときは、ACLという語をgroupという語に置き換え、それらの名前でグループに属するユーザーを作成してください。

- Adminインタフェースでのユーザーの作成

- 一般的なユーザー・タイプの作成

- Adminインタフェースからのユーザーの編集

- Adminインタフェースを使用したシステムからのユーザーの削除

12.4.1 Adminインタフェースでのユーザーの作成

次のタスクは、Adminインタフェースでのユーザーの作成に関する情報と手順の説明です。

注意:

LDAPを使用している場合は、そのLDAP製品のドキュメントを参照してください。WEM Adminを使用している場合は、Webエクスペリエンス管理フレームワークの使用を参照してください。

ユーザーを作成する前に、ユーザーについて次の事項を決定します。

- ユーザー名。

- パスワード。

- ACL。これにより、WebCenter Sitesのデータベース表へのユーザーのアクセスが制限されます。

- ユーザーに必要なACLを決定するには、カスタム・ユーザー用の必須のACLを参照してください。

- ユーザーの追加のシステムACLを決定するには、システムACLとその権限を参照してください。

- ユーザーがアクセスする必要があるデータベース表にどのACLが割り当てられているのかを判別するには、カスタム表へのACLの割当ての手順に従います。

Adminインタフェースでユーザーを作成するには

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー」をダブルクリックします。

2. 「ユーザー」フォームで、「ユーザーの追加」を選択し、「OK」をクリックします。
「OK」をクリックする前にユーザー名を追加できます。このユーザー名は、次のフォームの「ログイン名」フィールドに自動入力されて表示されます。

「ユーザーの追加」フォームが開きます。

図12-1 「ユーザーの追加」フォーム

3. 「ユーザーの追加」フォームのフィールドに次のように入力します。

a. 「ログイン名」フィールドに、一意の名前を入力します。空白や特殊文字(記号など)は含めないでください。アンダースコア文字(_)は使用できます。

b. 「アクセス権限」リストで、ユーザーのACLを選択します。複数のACLを選択するには、各ACLを[Ctrl]キーを押しながらクリックします。また、範囲内の最初と最後のACLを[Shift]キーを押しながらクリックして選択することで、特定の範囲のACLを選択することもできます。

c. 「パスワード」フィールドと「パスワードの再入力」フィールドに同じパスワードを入力します。

d. 「追加」をクリックします。
ユーザーが作成されます。

e. 一般管理者を作成できます。ユーザーを管理者またはコンテンツ・コントリビュータにする場合の詳細は、一般的なユーザー・タイプの作成を参照してください。

作成後の手順を完了するには

1. ユーザーが次のオプションのいずれかを実装する場合、ユーザーのプロファイルを作成します。

- Oracle WebCenter Sites: EngageなどのOracle WebCenter Sites製品。

- 言語パックおよび様々な言語

- 電子メール・メッセージを送信するワークフロー・プロセス

ユーザー・プロファイルの作成手順は、ユーザー・プロファイルの作成および編集を参照してください。

2. ユーザーが、ロケールおよび電子メール(ユーザー・プロファイルで指定される)に加えて、またはそのかわりに属性を必要としている場合は、属性を作成します。手順は、ユーザー属性の修正、追加および削除を参照してください。

3. ユーザーを完全に定義したら、ロールを使用してそのユーザーをサイトに関連付ける必要があります。

a. 未実行の場合、Adminインタフェースからのロールの作成の説明に従ってユーザーのロールを作成します。

b. ユーザーをサイトに関連付けるには、サイトを作成し、ユーザーをそのサイトに追加します。手順については、管理者インタフェースからのサイトの作成およびユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)を参照してください。

12.4.2 一般的なユーザー・タイプの作成

ユーザーを作成するときは、そのユーザーが別のWebサイトで持つ予定のロールを考慮することが重要です。多くの場合、ユーザーはあるサイトでは管理者になり、別のサイトではコンテンツ・コントリビュータになります。次の各トピックでは、各ユーザーを特定のタイプのユーザーにする方法について説明します。

- ユーザーを一般管理者にする

- ユーザーをサイト管理者にする

- ユーザーをワークフロー管理者にする

- ユーザーをコンテンツ・コントリビュータにする

12.4.2.1 ユーザーを一般管理者にする

サイトの一般管理者は、そのサイトのすべての局面を制御します。ユーザーが一般管理者である場合、その管理アクションは特定の1つのサイトにログインしている場合にのみ制御できますが、ログインしているときはすべてのサイトを管理できることに注意してください。

1. 新しく作成したユーザーについて、正しいACLが割り当てられているかどうかを確認します。

ユーザーのACLを決定するには、カスタム・ユーザー用の必須のACLを参照してください。そこに記載されている表をみると、一般管理者のACLがBrowser、Element Reader、PageReader、UserReader、xceleditor、xceladmin、TableEditor、UserEditor、およびVisitorAdminであることがわかります。

2. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」、続いて「RESTセキュリティ」、「グループへのユーザーの割当て」を開き、続いて「新規追加」をダブルクリックします。

「ユーザーへのグループの割当て」フォームが表示されます。

3. 一般管理者にするユーザーを選択し、「グループ」フィールドでRestAdminを選択します。

[Ctrl]キーを押しながらクリックすると複数のユーザーまたはグループを選択できますが、一般管理者は少数にする可能性が高いため、誤ってユーザーをRestAdminグループに追加しないように、一度に1つずつ追加することをお薦めします。

4. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてユーザーを追加するサイトを選択します。

5. 「ユーザー」をクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

このフォームは、「サイト管理者」タブの下でも使用できます。特定のサイトにログインする場合、「ユーザー」をダブルクリックします。

6. ユーザーのログイン情報を入力して「編集」アイコンをクリックします。

「ユーザーのロールを編集」フォームが開きます。

7. GeneralAdminと、このWebサイト上でそのユーザーに持たせる他のロールを選択します。

注意:

このドキュメントで使用されるロールの名前は、インストールされるFirstSiteIIサンプルWebサイトで使用されているロールの名前です。パブリッシュするWebサイトには、別のロールまたはロール名を使用することもできます。

サイトに一般管理者を追加するときは、その同じ人に別のサイトで別のロールを設定するかどうかを考慮します。そのユーザーがこのような別のロールを割り当てるサイトにログインするときには、そのユーザーにこれらのロールを割り当てる必要があります。

ユーザーが一般管理者権限を持っている場合、彼らがその一般管理者ロールを持っているWebサイトにログインしているときにのみ「管理」タブが表示されます。

12.4.2.2 ユーザーをサイト管理者にする

1. 新しく作成したユーザーについて、正しいACLが割り当てられているかどうかを確認します。

ユーザーのACLを決定するには、カスタム・ユーザー用の必須のACLを参照してください。そこに記載されている表をみると、サイト管理者のACLがBrowser、Element Reader、PageReader、UserReader、xceleditor、およびxceladminであることがわかります。

2. 「一般的な管理」ツリーで、「管理」、続いて「サイト」を開き、続いてユーザーを追加するサイトを開きます。

3. 「ユーザー」をダブルクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

このフォームは、ログインしているサイトで、「サイト管理者」を開いて「ユーザー」をダブルクリックしても表示できます(「サイト」ツリー下)。

4. 「ユーザー名」フィールドで、ユーザーの名前を入力して「選択」をクリックします。

5. 「ユーザー・ロールの管理」フォームで、ユーザーの名前の隣にある「編集」アイコンをクリックします。

「ユーザーのロールを編集」フォームが開きます。

6. 「ロール」フィールドで、SiteAdmin、Advanced User、およびこのWebサイト上でそのユーザーに持たせる他のロールを選択します。SiteAdminロールによってそのユーザーに「サイト管理者」タブへのアクセス権が付与され、AdvancedUserロールによってAdminインタフェースへのアクセス権が付与されます。

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

8. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」、続いて「RESTセキュリティ」、続いて「グループへのユーザーの割当て」を開きます。

9. 「新規追加」をクリックします。

10. サイト管理者にするユーザーを選択し、「グループ」フィールドでSiteAdmin_AdminSiteを選択します。

[Ctrl]キーを押しながらクリックすると複数のユーザーまたはグループを選択できますが、サイト管理者は少数にする可能性が高いため、誤ってユーザーをSiteAdmin_AdminSiteグループに追加しないように、一度に1つずつ追加することをお薦めします。

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

注意:

このドキュメントで使用されるロールの名前は、インストールされるavisportsサンプル・サイトで使用されているロールの名前です。パブリッシュするWebサイトには、別のロールまたはロール名を使用することもできます。

サイトにサイト管理者を追加するときは、その同じ人に別のサイトで別のロールを設定するかどうかを考慮します。そのユーザーがこのような別のロールを割り当てるサイトにログインするときには、そのユーザーにこれらのロールを割り当てる必要があります。

ユーザーがサイト管理者権限を持っている場合、彼らがそのサイト管理者ロールを持っているWebサイトにログインしているときにのみ「サイト」ツリーが表示されます。

12.4.2.3 ユーザーをワークフロー管理者にする

1. 新しく作成したユーザーについて、正しいACLが割り当てられているかどうかを確認します。

ユーザーのACLを決定するには、カスタム・ユーザー用の必須のACLを参照してください。そこに記載されている表をみると、ワークフロー管理者のACLがBrowser、Element Reader、PageReader、UserReader、xceleditor、およびxceladminであることがわかります。

2. 「一般的な管理」ツリーで、「管理」を開き、続いてユーザーを追加するサイトを開きます。

3. 「ユーザー」をダブルクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

その特定のサイトにログインしている場合、このフォームは、「サイト管理者」を開いて「ユーザー」をダブルクリックしても表示できます(「サイト」ツリー下)。

4. 「ユーザー名」フィールドで、ユーザーの名前を入力して「選択」をクリックします。

5. 「ユーザー・ロールの管理」フォームで、ユーザーの名前の隣にある「編集」アイコンをクリックします。
「ユーザーのロールを編集」フォームが開きます。

6. 「ロール」フィールドで、WorkflowAdmin、AdvancedUser、およびこのWebサイト上でそのユーザーに持たせる他のロールを選択します。WorkflowAdminロールは、「ワークフロー」ノード(「一般的な管理」ツリーの「管理」配下)へのユーザー・アクセスを付与し、AdvancedUserロールはAdminインタフェースへのアクセスを付与します。

注意:

このドキュメントで使用されるロールの名前は、インストールされるFirstSiteIIサンプルWebサイトで使用されているロールの名前です。パブリッシュするWebサイトには、別のロールまたはロール名を使用することもできます。

サイトにワークフロー管理者を追加するときは、その同じ人に別のサイトで別のロールを設定するかどうかを考慮します。そのユーザーがこのような別のロールを割り当てるサイトにログインするときには、そのユーザーにこれらのロールを割り当てる必要があります。

ユーザーがワークフロー管理者権限を持っている場合、彼らがそのワークフロー・ロールを持っているWebサイトにログインしているときにのみ「ワークフロー」タブが表示されます。

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

12.4.2.4 ユーザーをコンテンツ・コントリビュータにする

新しく作成したユーザーについて、正しいACLが割り当てられているかどうかを確認します。

ユーザーのACLを決定するには、カスタム・ユーザー用の必須のACLを参照してください。表を見ると、すべてのユーザーのACLがBrowser、Element Reader、PageReader、UserReader、およびxceleditorであることがわかります。そのユーザーが寄与するようにするコンテンツのタイプに応じて、コンテンツ・コントリビュータに必要な他のACLを追加できます。

たとえば、PageEditor ACLでは、ユーザーにサイトへのページの追加、および定義済エレメントに基づいたコンテンツの変更が許可されます。ElementEditor ACLでは、コントリビュータにテンプレートの作成が許可されます。特定のACLおよびそれがコントリビュータの編集アクセスに与える影響の詳細は、システム・デフォルトを参照してください。

ユーザーがページ上の既存のコンテンツの編集のみを行うようにする場合は、追加のACLは必要ありません。単純な編集は、割り当てられたロールに含まれています。

1. 「一般的な管理」ツリーを開き、続いて「サイト」を開き、続いてサイトを開き、ユーザーを追加します。

2. 「ユーザー」をクリックします。

「ユーザー・ロールの管理」フォームが表示されます。

このフォームは、ログインしているサイト名の下で、「サイト管理者」を開いて「ユーザー」をダブルクリックしても表示できます(「サイト」ツリー下)。

3. 「ユーザー名」フィールドで、ユーザーの名前を入力して「選択」をクリックします。

4. 「ユーザー・ロールの管理」フォームで、ユーザーの名前の隣にある「編集」アイコンをクリックします。

5. 「ロール」フィールドで、SitesUserロールを選択します。

ロールがアセットにどのように接続されているのかに応じて、別のロールの追加が必要な場合もあります。アセットは作成されるときに、ロールに接続されます。そのアセットにアクセスできるロールは、これらのロールのみです。

注意:

通常、ユーザーを同じWebサイトのSitesUserロールとAdvancedUserロールには割り当てません。SitesUserロールによってOracle WebCenter Sites: Contributorインタフェースへのアクセス権が付与され、AdvancedUserロールによってAdminインタフェースへのアクセス権が付与されます。

このドキュメントで使用されるロールの名前は、FirstSiteIIサンプルWebサイトで使用されているロールの名前です。パブリッシュするWebサイトには、別のロールまたはロール名を使用することもできます。

様々なアセットの設定方法にもよりますが、ほとんどのコンテンツ・コントリビュータには、Webサイト上で、SitesUserを超えるロールを割り当てる必要はありません。コンテンツ・コントリビュータは、管理者が使用するAdminインタフェースではなく、Contributorインタフェースのみを使用してコンテンツを変更します。

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

12.4.3 Adminインタフェースからのユーザーの編集

次の手順は、WebCenter Sites Adminインタフェースでユーザーを編集する方法を示しています。LDAPを使用している場合は、そのLDAP製品のドキュメントを参照してください。

ユーザーを編集するには、次の手順を実行します。

注意:

WebCenter Sitesシステム・ユーザーの名前またはACL (DefaultReader、ContentServer、xceladmin)を変更しないでください。

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー」をダブルクリックします。

2. 開いたフォームに、ともに作業するユーザーの名前を入力します。ユーザー名がわからない場合は、そのフィールドを空白のままにします。WebCenter Sitesによってシステム内のすべてのユーザーのリストが返されます。

3. 「ユーザーの修正」を選択し、「OK」をクリックします。

4. ユーザーのリストで、作業対象のユーザーを選択します。

5. 「ユーザーの修正」フォームで目的の変更を行い、「修正」をクリックします。

12.4.4 Adminインタフェースを使用したシステムからのユーザーの削除

次の手順は、WebCenter Sites Adminインタフェースを使用してWebCenter Sitesシステムからユーザーを削除する方法を示しています。LDAPを使用している場合は、そのLDAP製品のドキュメントを参照してください。

注意:

WebCenter Sitesシステム・ユーザー(fwadminまたは管理者として使用されるユーザー、ContentServer、またはDefaultReader)を削除しないでください。

1. ユーザー・プロファイルを削除します。Adminインタフェースでのユーザー・プロファイルの削除を参照してください。

2. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー」をダブルクリックします。

3. 開いたフォームに、削除するユーザーの名前を入力します。ユーザー名がわからない場合は、そのフィールドを空白のままにします。WebCenter Sitesによってシステム内のすべてのユーザーのリストが返されます。

4. 「ユーザーの削除」を選択し、「OK」をクリックします。

5. ユーザーのリストで、削除対象のユーザーの横にある「削除」ラジオ・ボタンを選択します。

6. 「削除...」をクリックします。

警告メッセージが開きます。

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

ユーザーがWebCenter Sitesシステムから削除されます。

12.5 ユーザー・プロファイルとユーザー属性の使用

ユーザー・プロファイルは、次に関する作業をするすべてのユーザーに必要です。

- サイト・モジュールおよび製品

- 言語パック

- ワークフロー参加者に割当てを通知するために電子メール・メッセージを送信するワークフロー・プロセス。ユーザー・プロファイルは、電子メール・アドレスにユーザー名をマップすることで、ワークフロー・アクションをサポートします。

ユーザー・プロファイルには、一連のユーザー属性が保持されます。デフォルトでは、ユーザー・プロファイルに保持されるユーザー属性は次のもののみです。

- 電子メール属性。ワークフロー・アクションをサポートするために使用され、値としてユーザーの電子メール・アドレスを取ります。ワークフロー参加者に割り当てられたアセットに関する電子メールをその参加者に送信するワークフロー・アクションを作成できます。

- ロケール属性。特定のユーザーにどの言語を使用するのかを決定するために使用されます。この属性は、値としてユーザーの優先場所を取ります。

- タイムゾーン属性。特定のユーザーにどのタイムゾーンを使用するのかを決定するために使用されます。この属性は、値としてユーザーの優先タイムゾーンを取ります。

ユーザーがWEM Adminインタフェースで作成された場合、アバターも属性として付加されます。ユーザー属性を追加し、WebCenter Sitesユーザー管理表にそれらの値を格納できます。ただし、WebCenter Sitesインタフェースでこれらの値を使用するには、ユーザー・プロファイルのフォームを表示するエレメントをカスタマイズする必要があります。WebCenter Sitesインタフェースのエレメントのカスタマイズの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

この項の内容は次のとおりです。

- ユーザー・プロファイルの作成および編集

- Adminインタフェースでのユーザー・プロファイルの削除

- ユーザー属性の修正、追加および削除

12.5.1 ユーザー・プロファイルの作成および編集

LDAPを使用している場合、ユーザーおよびサイト管理操作に対するシステム・レスポンスに注意してください。これらのシステム・レスポンスについては、LDAP統合Sitesシステムでのユーザー、サイト、およびロールを参照してください。

ユーザー・プロファイルを作成または編集するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー・プロファイル」をダブルクリックします。

「ユーザー・プロファイル管理」フォームが開きます。

2. フォームで、ユーザー名を入力し、「選択」をクリックします。

選択したユーザーのプロファイルが開きます。

3. 「編集」アイコンをクリックします。

「ユーザー・プロファイルの編集」フォームが開きます。

図12-2 「ユーザー・プロファイルの編集」フォーム

4. 「電子メール」フィールドに、そのユーザーの電子メール・アドレスを入力します。

5. (オプション)「ロケール設定」ドロップダウン・リストから、このユーザーのロケール設定を選択します。ユーザーのローカル設定は、WebCenter Sitesシステムの言語設定(「ロケール・マネージャ」で設定)より優先されます。

注意:

ユーザーのロケール設定を設定しない(「ロケール設定」ドロップダウン・リストで「設定されていません」が選択されている)場合、WebCenter Sitesインタフェースは、WebCenter Sitesシステムに設定されている言語で表示されます。

6. (オプション)「タイムゾーン」ドロップダウン・リストで、ユーザーのタイムゾーン設定を選択します。タイムゾーン設定を指定しない(ドロップダウン・メニューで「自動検出」が選択されている)場合、ユーザーのタイムゾーンは、ユーザーのブラウザから自動的に検出されます。

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

8. このユーザーが作業する必要があるサイトに対してこのユーザーを有効化します。手順については、ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)を参照してください。

12.5.2 Adminインタフェースでのユーザー・プロファイルの削除

ユーザー・プロファイルを削除するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー・プロファイル」をダブルクリックします。

「ユーザー・プロファイル管理」フォームが開きます。

2. 「削除...」をクリックします。

警告メッセージが開きます。

3. 「ユーザー・プロファイルの削除」をクリックします。

削除を確認するメッセージが開きます。

12.5.3 ユーザー属性の修正、追加および削除

デフォルトでは、WebCenter Sitesコンテンツ・アプリケーションが必要とするユーザー属性は、電子メール・アドレスとロケール設定のみです。さらに、WEMに作成されたユーザーには、アバター属性があります。これらの属性をユーザーに割り当てるには、ユーザー・プロファイル機能を使用します。ユーザー・プロファイルの作成および編集を参照してください。必要に応じて、LDAPを使用している場合であっても、この表でユーザーの追加のユーザー属性を格納および使用できます。

「ユーザー属性の修正」オプションを使用すると、ユーザー・プロファイルで使用されている属性を変更できます。属性の追加や削除も可能になります。

ユーザーの属性を修正するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「ユーザー・アクセス管理」を開き、「ユーザー」をダブルクリックします。

2. 開いたフォームに、ともに作業するユーザーの名前を入力します。ユーザー名がわからない場合は、そのフィールドを空白のままにします。WebCenter Sitesによってシステム内のすべてのユーザーのリストが返されます。

3. リストで、属性を変更するユーザー名をクリックします。

「ユーザー属性」フォームが表示されます。

図12-3 「ユーザー属性」フォーム

4. 「ユーザー属性」フォームのフィールドで、必要に応じて次のうち少なくとも1つを実行します。

- 「属性値」フィールドの内容を編集することで、属性に割り当てられている現在の値を変更します。

- フォームの下部にあるフィールドに、その名前と少なくとも1つの値を入力することで新しい属性を追加します。

- 不要な属性は(「属性値」フィールドで)その関連付けられた値を削除することで削除します。

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

変更内容がデータベースにコミットされます。

13 外部セキュリティの設定

次の各トピックでは、セキュリティ・プロトコルの実装について説明します。

- 外部セキュリティの設定

- 暗号化および暗号化キー・セキュリティの実装

- RESTセキュリティの使用

13.1 外部セキュリティの設定

テンプレートのコーディングやアセット・タイプの設計を始める前に、管理者とサイト開発者は、セキュリティの管理システムと配信システムの両方に構成する方法を検討し、決定する必要があります。

次の各トピックで、WebCenter Sitesシステム上でのセキュリティの実装とテストについて説明します。

- WebCenter Sitesのセキュリティの概要

- セキュリティの実装

- セキュリティのテスト

13.1.1 WebCenter Sitesのセキュリティの概要

開発者がオンライン・サイトの設計や管理システムのユーザー・インタフェースの変更を行う前に、管理者はセキュリティ・プロトコルを実装する必要があります。セキュリティ構成に関する決定は、オンライン・サイトの開発方法に影響を与えます。

定期的にシステムを確認し、それらが正しく機能しているかどうかを判断する必要があります。図13-1 は、セキュアなWebCenter Sitesシステムの例を示しています。

図13-1 WebCenter Sitesシステム

次の各トピックでは、利用できるWebCenter Sitesのセキュリティ対策に関する概要情報を提供します。

- ACLとセキュリティの理解

- DefaultReader、secure.CatalogManagerおよびsecure.TreeManagerの理解

- BlobServerとセキュリティの理解

- セキュリティの目的の実装

13.1.1.1 ACLとセキュリティの理解

ACLおよびロールの使用で説明したように、ACL (アクセス制御リスト)は、WebCenter Sitesシステムでセキュリティおよびユーザー管理モデルの基盤として機能します。ACLは、データベース表およびWebCenter Sitesページの両方へのアクセスを制限する権限のセットです。

ACLの制限は、wcs_properties.jsonファイル内のcc.securityプロパティおよびsecurity.checkpageletsプロパティがtrueに設定されている場合にのみ実施されます。これらのプロパティは、デフォルトでtrueに設定されています。なんらかの理由でセキュリティを無効にしなければならない場合は、Adminインタフェースからプロパティ管理ツールを開いて、cc.securityプロパティをfalseに設定します。ただし、サイトの開発が確実にセキュリティを有効にした状態で行われるようにするため、このプロパティはすべてのシステムでtrueのままにすることをお薦めします。

システムのセキュリティ対策を計画する際には、デフォルトのACL (システム・デフォルトを参照)のリストを調べ、追加のACLが必要かどうかを判断します。開発者が表の作成またはユーザー・インタフェースへの追加を計画している場合には、システムACLとは異なる権限の組合せでACLを作成する必要が生じる場合があります。

注意:

どのような状況においても、システムのデフォルトACLを変更したり、WebCenter Sitesのシステム表またはWebCenter Sitesのコンテンツ・アプリケーションの表に割り当てられたACLを変更しないでください。

13.1.1.2 DefaultReader、secure.CatalogManagerおよびsecure.TreeManagerの理解

WebCenter SitesおよびWebCenter Sitesコンテンツ・アプリケーションには、いくつかのデフォルトのユーザー・アカウントが付属します。DefaultReaderアカウントは権限のないすべてのサイト訪問者に割り当てられます(WebCenter Sitesにホストされるサイトのすべての訪問者にWebCenter SitesのユーザーIDが必要なため)。

DefaultReaderユーザー・アカウントには、デフォルトで、BrowserおよびVisitorのACLがあります。Visitorにより、統計を目的とする訪問者の追跡が有効になります。データベース表の多くにもBrowser ACLが割り当てられており、様々なOracle WebCenter Sites: Engage表にはVisitor ACLが割り当てられているため、セキュリティの問題が生じます。これにより、DefaultReaderアカウントを使用していれば、だれでもその表内の情報を調べることが可能となります,ただし、このユーザーとして表に書き込むことはできません。誰かがDefaultReaderユーザー・アカウントを使用してWebCenter Sitesデータベースの表を表示するのを防ぐには、Adminインタフェースのプロパティ管理ツールを使用して、をwcs_properties.jsonファイルの次のプロパティをtrueに設定します。

- secure.CatalogManager

- secure.TreeManager

これらのプロパティがtrueに設定されている場合、DefaultReaderユーザーは、読取り専用データであっても、CatalogManagerおよびTreeManagerサーブレットにはアクセスできません。

注意:

EngageのACL (VisitorおよびVisitorAdmin)の詳細は、システム・デフォルトを参照してください。各ACLに関連付けられている権限の詳細は、表36-3を参照してください。ACLの詳細は、表36-4を参照してください。

13.1.1.3 BlobServerとセキュリティの理解

BLOBにセキュリティを実装する場合は、BlobServerサーブレットのセキュリティ機能を有効にする必要があります。それには、Adminインタフェースのプロパティ管理ツールを使用して、wcs_properties.jsonファイルのbs.securityパラメータをtrueに設定します。

bs.security=trueの場合、リクエストする個人が正当なユーザーとして認証された証拠がblobのURLに含まれていないかぎり、BlobServerはblobを提供することを拒否します。次のような証拠が必要です。値がcsblobidという名前のセッション変数に一致しているcsblobidパラメータから取得されたURLの値。このため、BlobServerセキュリティが有効である場合、開発者は通常と異なる方法でblobへのリンクをコーディングする必要があります。

それらのリンクのコーディング方法の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

13.1.1.4 セキュリティの目的の実装

一般的には、WebCenter Sitesシステム(開発システム、管理システムおよび配信システム)ごとに、異なるセキュリティの目的があります。

次の各トピックで、各WebCenter Sitesシステム上でのセキュリティの実装について説明します。

- 開発システムのセキュリティの目的の実装

- 管理システムのセキュリティの目的の実装

- 配信システムのセキュリティの目的の実装

13.1.1.4.1 開発システムのセキュリティの目的の実装

開発システムは一般的にはファイアウォールの内側にありますが、開発システムにおいても、開発者が設計対象とするシステム(管理または配信)で実装されるものと同じセキュリティ構成を実装する必要があります。両方のシステムで条件を同じにすることで、コードがターゲット・システムで適切に機能するようにするためです。

- 配信システムでBlobServerセキュリティの使用を計画している場合、BLOBのURLを作成するテンプレートは異なる方法でコード化する必要があります。したがって、開発システムでもBlobServerセキュリティを有効にする必要があります。

- オンライン・サイトで、訪問者が自分自身を識別することが要求される場合、開発システムには、配信システムで使用するものと同じセキュリティ構成が必要です。

13.1.1.4.2 管理システムのセキュリティの目的の実装

管理システムのセキュリティには、次の2つの主な概念が含まれています。

- 有効なWebCenter Sitesユーザーのみがシステムにアクセスできるようにする(この章で説明します)。

- 有効なユーザーが、そのユーザーに適した機能のみにアクセスできるようにする。詳細は、ACLおよびロールの使用を参照してください。

13.1.1.4.3 配信システムのセキュリティの目的の実装

サイトを一般に配信する際には、訪問者はサイト上のコンテンツにアクセスできるようにする一方、ハッカーが公開しない領域にアクセスできないようにすることも必要なため、元来配信システムでの警戒はより厳しいものとなります。

配信システムを構成する際には、WebCenter Sitesのユーザー・インタフェースを無効にし、このインタフェースや開発者ツールを使用してアセットやコードを追加できないようにします。さらに、一部のWebCenter Sitesサーブレットへのアクセスを制限します。

13.1.2 セキュリティの実装

次の各トピックでは、プロパティの設定、デフォルト・ユーザー・アカウントのパスワードの変更、企業ネットワーク外でアクセス可能なシステムでのSSLの使用、特定のWebCenter SitesサーブレットのURLのマッピングおよび配信システム上でのアプリケーションの特定の部分の無効化といった、セキュリティ対策の構成について説明します。

各トピックでは、どのシステムでどの手順を実行するのかが示されています。

- プロパティを使用したセキュリティ設定の構成

- ユーザーとパスワードの使用

- SSLとデジタル証明の使用

- URLとWebサーバーの使用(配信システムのみ)

- WebCenter Sitesフォームとページの使用(配信システムのみ)

13.1.2.1 プロパティを使用したセキュリティ設定の構成

様々なセキュリティを実装するプロパティは、WebCenter Sites wcs_properties.jsonファイルにあります。

プロパティ管理ツールを使用して、次のプロパティがtrueに設定されていることを確認します。

- cc.security

- security.checkpagelets

- secure.CatalogManager

- secure.TreeManager

- contentsecurity.enabled

BlobServerセキュリティを使用する計画の場合、bs.securityをtrueに設定します。

セッション・タイムアウト値が各システムに適した値になるよう、次のようにcs.timeoutプロパティを設定します。

- 開発システムおよび管理システムでは、支障なく設定できると考えられる場合、長いタイムアウト値を設定します。

- 配信システムでは、訪問者にフラストレーションを感じさせることなく可能なかぎり短いタイムアウト値を設定します。

さらに、配信システムに指定する別のプロパティとして、cs.wrapperがあります。ラッパーとは、Webサーバー上のfuturetense_csディレクトリにあるHTMLファイルです。このディレクトリには、Devというサブディレクトリも含まれ、これは配信システムから削除する必要があります。ただし、配信システム上のWebサーバーからfuturetense_csディレクトリ全体を削除する場合は、cs.wrapperプロパティをfalseに設定する必要があります。

詳細は、WebCenter Sitesフォームとページの使用(配信システムのみ)を参照してください。

13.1.2.2 ユーザーとパスワードの使用

WebCenter Sitesのインストール後にすべてのシステムでデフォルトのユーザー・アカウントがセキュアになったことを確認してください。ユーザー・アカウントとパスワードのポリシーを強化するには、OAMおよびLDAPの使用をお薦めします。

開発、管理および配信の全システムで、次の手順を実行します。

- fwadminユーザー・アカウントのデフォルト・パスワードを変更します(Adminインタフェースの「一般的な管理」ツリーで、「管理」、「ユーザー・アクセス管理」の順に開き、「ユーザー」をダブルクリックします)。

- インストール時に作成されたWebCenter SitesユーザーがContentServerという名前の場合、そのパスワードがデフォルトのパスワード(password)ではないことを確認します。使用されているパスワードがデフォルト・パスワードの場合、変更します(Adminインタフェースの「一般的な管理」ツリーで、「管理」、「ユーザー・アクセス管理」の順に開き、「ユーザー」をダブルクリックします)。

- アプリケーション・サーバーのデフォルトの管理者ユーザー名およびパスワードを変更します。

- Webサーバーのデフォルトの管理者ユーザー名およびパスワードを変更します。

- サンプル・サイトがインストールされている場合、サーバーへのミラーリングのパブリッシュ方法に対してミラー・ユーザーが作成されています(名前: mirroruser、パスワード: mirroruser)。このユーザーのパスワードを変更します。

- SiteGod ACLを持つすべてのユーザー・アカウントで、パスワードを頻繁に変更します(Adminインタフェースの「一般的な管理」ツリーで、「管理」、「ユーザー・アクセス管理」の順に開き、「ユーザー」をダブルクリックします)。SiteGod ACLを持つユーザー・アカウントは、UNIX rootユーザーのように対処してください、

注意:

DefaultReaderユーザーのデフォルト・パスワードは変更しないでください。

avisportsおよびFirstSiteII以外のサンプル・サイトが管理システムまたは配信システムにインストールされている場合、エディタを含むすべてのサンプル・ユーザーを削除しますが、xceleditor ACLは削除しないでください。また、fwadminユーザーは削除しないでください。さらに、mirroruserユーザーのパスワードを変更します。

配信システムでは、そのシステムのシステム管理者以外のユーザーに、xceleditor ACLを割り当てないでください。WebCenter Sitesのコンテンツ・アプリケーションがその配信システムにインストールされている場合、このACLにより、このコンテンツ・アプリケーションへのアクセスが可能になります。

13.1.2.3 SSLとデジタル証明の使用

リモートの従業員でもアクセスできる管理システムなど、企業ネットワーク外からアクセス可能なシステムや専用データを含むシステムでは、SSLを使用して、暗号化されたセキュアな接続を確立することをお薦めします。

自己署名証明書ではなく、信頼できる機関により承認されたデジタル証明書を使用する必要があります。自己署名証明書を使用すると、次のような結果になる場合があります。

- Javaによるシステムへの内部コールが失敗する可能性がある。

- 左側のナビゲーション・ツリーやパブリッシュなど、ユーザー・インタフェースの一部の機能が正常に動作しない可能性がある。

13.1.2.4 URLとWebサーバーの使用(配信システムのみ)

配信システムのWebサーバーでは、次のWebCenter Sitesサーブレットのみにアクセス権を与えるようにします。それらのURLのみをアプリケーション・サーバーにマップします。

- ContentServer

- BlobServer

- Satellite

- CookieServer

その他のWebCenter Sitesサーブレットのアプリケーション・サーバーには、URLをマップしないでください。かわりに、次のサーブレットのURLは、「404 見つかりません」ページなどのエラー・ページにマップします。

- HelloCS

- CatalogManager

- TreeManager

- DebugServer

- CacheServer

- Inventory

13.1.2.5 WebCenter Sitesフォームとページの使用(配信システムのみ)

配信システムでは、必ずWebCenter Sitesアプリケーションの次の部分を無効にするか、完全に削除してください。

- Webサーバーからfuturetense_csディレクトリ全体を削除します。アプリケーション・サーバーからは、これを削除しないでください。その場合、プロパティ管理ツールを使用して、wcs_properties.jsonファイルのcs.wrapperプロパティをfalseに設定します(ラッパーはそのフォルダのHTMLファイル)。これを行わない場合、サイトの訪問者には、システム・エラー・メッセージではなく、「404ページが見つかりません」が表示されます。

- SiteCatalog/OpenMarket/Xcelerate/UIFrameworkに移動し、すべてのページの名前を変更します。最低でも、LoginPageとLoginPostの名前は変更してください。

13.1.3 セキュリティのテスト

セキュリティ対策を実装したら、システムをテストします。

開発、管理および配信の各システムで、次の手順を実行します。

1. Try to log in to the database with Oracle WebCenter SitesSites Explorerで、デフォルトのユーザー・アカウントを使用して、データベースへのログインを試みます。

- DefaultReader
パスワードにSomeReaderを使用してログインできる場合、secure.CatalogManagerおよびsecure.TreeManager プロパティはfalseに設定されています。これらはtrueに変更してください。

- ContentServer
パスワードにpasswordを使用してログインできる場合は、このパスワードをただちに変更してください。

- editor
パスワードにxceleditorを使用してログインできる場合は、このパスワードをただちに変更してください。

- fwadmin
パスワードにxceladminを使用してログインできる場合は、このパスワードをただちに変更してください。

2. 管理システムと配信システムには、サンプル・サイト・ユーザーが存在しないことを確認します。

3. 次のCatalogManager URLを使用して、ContentServer/passwordでログインできないことを確認します。

http://<server>:<port>/<context>/CatalogManager?ftcmd=login&username=ContentServer&password=password

4. 次のCacheServer URLを使用して、ContentServer/passwordでキャッシュ全体をフラッシュできないことを確認します。

http://<server>:<port>/<context>/CacheServer?all=true&authusername=ContentServer&authpassword=password

5. デフォルトの管理者ユーザーとしてアプリケーション・サーバーにログインできないことを確認します。

6. デフォルトの管理者ユーザーとしてデータベースにログインできないことを確認します。

7. デフォルトの管理者ユーザーとしてWebサーバーにログインできないことを確認します。

13.2 暗号化および暗号化キー・セキュリティの実装

次の各トピックでは、セキュアなサーバー・アクセスを使用した、セキュリティ攻撃からのシステム保護について説明します。アクセスはすべて、暗号化を介して保護されています。すべての組織がセキュリティ標準を確立して、重要情報が危険にさらされないようにすることが重要です。

- WebCenter Sitesのセキュリティの概要

- WebCenter Sitesのセキュリティ構成について

- SitesSecurityContext.xml構成ファイルについて

- WebCenter Sitesセキュリティ・ユーティリティの使用

- ESAPIセキュリティ検証の使用

13.2.1 WebCenter Sitesのセキュリティの概要

WebCenter Sitesでは、システムはデフォルトで保護されており、さらにインストール要件に適合するようにセキュリティを厳しくする様々なオプションが用意されています。

システムには、暗号化手法によってパスワードおよびネットワーク全体でのデータ交換を正しく処理するために必要な、暗号化鍵を提供する保護されたキー・ストアがインストールされています。これにより、システムのセキュリティを危険にさらす可能性のある未認可の個人には機密情報が表示されないようになります。

WebCenter Sitesは、セキュリティ向上のために、Oracle Platform Security Services (OPSS)資格証明ストアをサポートします。この資格証明ストア機能は、Oracleの高度な暗号化を使用して対称暗号化鍵を作成および維持します。資格証明ストアの場所は、適切に構成されたJPS (Javaプラットフォーム・セキュリティ)プロバイダによって識別されます。資格証明ストアのアクセスや変更は、JPS権限によって保護されています。認可されたプログラムにのみ、資格証明ストアの読込み、修正、またはその両方を実行するためのアクセスが許可されます。

複数のアプリケーション・サーバー・コンテキストやシステム、またはその両方にまたがった暗号化のサポートを必要とするコンポーネントでは、同じ暗号化キーを使用できる必要があります。言い換えれば、ある場所で暗号化されたデータ値を別の場所で複合化する場合は、同じ鍵を使用する必要があります。暗号化および復号化を必要とする場所ごとに、中央キー・ストアのコピーを使用する必要があります。

13.2.2 WebCenter Sitesのセキュリティ構成について

セキュリティの構成は、SitesSecurityContext.xml構成ファイルによって制御されます。このファイルは、OPSS資格証明ストアへのアクセスを必要とする外部プログラムのクラスパス上に存在する必要があります(構成の詳細はOPSSのドキュメントを参照してください)。WebCenter Sitesでは、製品内部の様々な機能に関連付ける暗号化鍵に標準のネーミング規則を使用します。あらゆる場合に使用される暗号化鍵は1つも存在しません。そのため、機能ごとの鍵の変更は、他の機能に影響を与えることなくいつでも実行できます。あらゆるキー・ストア・タイプに、次の4つの関連する名前が使用されます。

1. masterkey: 将来使用するために予約されています

2. tokenskey: WebCenter Sitesトークン・ジェネレータで使用される暗号化鍵です

3. generalkey: 暗号化されたPOSTによるデータ交換および外部ファイルに存在する機密情報のすべてに使用される暗号化鍵です

4. passwordkey: データベース内のユーザー・パスワードを対称暗号化でエンコードする際に使用される暗号化鍵です

セキュリティを強化するために、4つの暗号化キーのセットは、WebCenter Sitesのすべてのインストールで固有です。

Oracle資格証明ストア機能(CSF)は、Javaプラットフォーム・セキュリティ(JPS)経由でアクセスする非常にセキュアなキー・ストレージ機能です。この機能は、すべての環境にわたり使用できます。Oracleセキュリティの不可欠な部分であり、特定のプロバイダに固有なものではありません。この機能には、Oracle OSDT (Oracle Security Developer Tools)によって作成された対称暗号化鍵のみを格納できます。WebLogic環境では、この資格証明ストアはJPSの権限によって保護されます。資格証明ストアにアクセスする、またはそのコンテキストを操作するプログラムは、権限を付与されている必要があります。適切な権限を付与されていないプログラムはアクセスを拒否されます。最高レベルのセキュリティが要求される状況では、このオプションを使用することをお薦めします。

13.2.3 SitesSecurityContext.xml構成ファイルについて

SitesSecurityContext.xmlファイルは、WebCenter Sitesおよびその関連ユーティリティが動作するセキュリティ環境のすべての面を制御します。それはWebCenter Sitesサーバー内で、暗号化、暗号化キー・ストレージ、CSRFトークン生成および内部セキュリティ・プロセスのための実装クラスをインスタンス化するSpring構成ファイルです。様々なシステム構成要素間のセキュリティの不可欠な部分です。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

<!-- Crypto support package -->
<!-- Default Crypto package for WebLogic -->
<bean id="cryptoPackage" class="com.fatwire.security.common.OracleSecurityCrypto" />

<!-- Credential store support package -->
<!-- Default Credential Store for WebLogic -->
<bean id="credentialPackage" class="com.fatwire.security.common.WeblogicCredentialStore" >
<property name="securityMetaInfo" ref="securityMetaInfo" />
</bean>

<!-- CSRF Token generation/validation package -->
<bean id="tokenPackage" class="com.fatwire.auth.SecurityTokenImpl" >
</bean>

<bean id="securityMetaInfo" class="oracle.fatwire.security.common.SecurityMetaInfo" >
<property name="uniquePrefix" value="Sites" />
</bean>

<!-- Security Basis -->
<bean id="securityBasis" class="com.fatwire.security.common.SecurityBasis" >
<property name="securityCrypto" ref="cryptoPackage" />
<property name="securityToken" ref="tokenPackage" />
<property name="credentialStorage" ref="credentialPackage" />
<property name="securityMetaInfo" ref="securityMetaInfo" />
</bean>

<!-- Security Context -->
<bean id="securityContext" class="COM.FutureTense.Security.Context.AdvancedSecurityContextImpl" >
<property name="securityBasis" ref="securityBasis" />
<property name="convertCredentials" value="true" />
</bean>

</beans>

SitesSecurityContext.xmlファイルは5つのBeanに分割され、そのうち3つは必須で(cryptoPackage、credentialPackageおよびsecurityBasis)、2つはWebCenter Sitesサーバーのみにより使用されます(tokenPackageおよびsecurityContent)。変更する場合、修正済ファイルを、それを必要とするすべてのコンポーネントのクラスパスに配置する必要があります。

このファイルに含まれるBeanは次のとおりです。

- cryptoPackage: 初期化する暗号化パッケージを指定します。

- com.fatwire.security.common.OracleSecurityCrypto: OSDTを使用。Oracle資格証明ストア機能を使用する場合は、この暗号化パッケージを指定する必要があります。

- credentialPackage: 初期化するキー・ストレージを指定します。

- com.fatwire.security.common.WeblogicCredentialStore: WebLogic固有のCSF実装

- tokenPackage: このBeanを必要とするのはWebCenter Sitesサーバーのみです。クラス・キーワードは適切なクラス実装を選択します(デフォルトはcom.fatwire.auth.SecurityTokenImpl)。securityTokenインタフェースを実装する、独自のセキュリティ・トークン・ジェネレータを実装するオプションがあります。

- securityMetaInfo - このBeanは、資格証明ストアを使用するアプリケーションの接頭辞を指定するために必要です。接頭辞は、異なるアプリケーションが同じ資格証明ストアを使用できるように、キーおよびパスワードに追加されます。WebCenter Sitesの接頭辞はSitesです。

- securityBasis - このBeanはすべてのセキュリティ・コンポーネントをまとめてバインドします。変更しないでください。プロパティ・エントリは、他のBean定義を参照します。securityTokenプロパティは、WebCenter Sitesサーバーでのみ指定されます。

- securityContext: このBeanを必要とするのはWebCenter Sitesサーバーのみです。それは、すべての内部セキュリティ・プロセスを扱うクラスを定義します。このBeanは変更しないでください。

このファイルは、暗号化およびキー・ストア機能へのアクセスを必要とする各アプリケーションのクラスパスに存在する必要があります。OPSS資格証明ストアへのアクセスを必要とするアプリケーションに対して、このファイルのコピーを、同じ暗号化および資格証明ストア・パッケージを使用して構成する必要があります(構成の詳細はOPSSのドキュメントを参照してください)。

13.2.4 WebCenter Sitesセキュリティ・ユーティリティの使用

WebCenter Sitesシステムには、暗号化キー・ストレージの作成および保守を支援する様々なユーティリティが存在します。これらのユーティリティはsite-security.jarに存在し、Javaコマンドから特定のクラス名をコールすることによって実行されます。実行時は、ユーティリティに必要なすべての jarのクラスパスを定義する必要があります。

Weblogic CSFにアクセスしてキーを取得しようと試みるすべてのJava SE環境では、一部の構成が次のとおりに設定されている必要があり、資格証明ストアのコンテキストにアクセスするかそれを操るプログラムには、権限が付与されている必要があります。

config、fmwconfigおよびlibという名前のフォルダを作成します。作成したフォルダに次のファイルを配置します。

- config: 'java.policy'(<weblogic_Home_Path>\oracle_common\modules\oracle.jps\domain_config\jse) 'SitesSecurityContext.xml'(Sitesのconfigから)

- fmwconfig: 'bootstrap', 'keystores.xml' and 'jps-config-jse.xml' (<weblogic_Home_Path>\user_projects\domains\<domain_name>\config\fmwconfig)

- lib: 次に示すJARをここに置く必要があります。

最初の引数に指定されたクラス名のユーティリティ・クラスを実行するサンプル・シェル・スクリプトを次に示します。

#!/bin/sh
# Set JAVA_HOME
JAVA_HOME="/fmw/jdk/bin"
# Set CLASS_PATH
weblogicPath=<Path to weblogic>
fmwConfigPath=./fmwconfig
oracleCommonPath=${weblogicPath}/oracle_common
oracleJps=${oracleCommonPath}/modules/oracle.jps

jpsConfigPath=${fmwConfigPath}/jps-config-jse.xml
javaPolicy=./config/java.policy

jpsManifestJar=${oracleJps}/jps-manifest.jar

javaOpts=-cp .;./config
javaOpts=${javaOpts};./lib/sites-security.jar

javaOpts=${javaOpts};%jpsManifestJar%
javaOpts=${javaOpts};./lib/commons-codec-1.6.jar
javaOpts=${javaOpts};./lib/commons-configuration-1.9.jar
javaOpts=${javaOpts};./lib/commons-lang-2.4.jar
javaOpts=${javaOpts};./lib/commons-logging-1.1.3.jar
javaOpts=${javaOpts};./lib/log4j-1.2.16.jar
javaOpts=${javaOpts};./lib/quartz-1.5.2.jar
javaOpts=${javaOpts};./lib/sites-request-authenticator.jar
javaOpts=${javaOpts};./lib/sites-cs.jar
javaOpts=${javaOpts};./lib/spring-2.5.5.jar
javaOpts=${javaOpts};./lib/xercesImpl-2.11.0.jar
javaOpts=${javaOpts};./lib/xml-apis-1.4.01.jar
javaOpts=${javaOpts};./lib/javaee-api-7.0.jar

$JAVA_HOME/java ${javaOpts} -Doracle.security.jps.config=${jpsConfigPath} -Dcommon.components.home=${oracleCommonPath} -Djava.security.policy=${javaPolicy} com.fatwire.security.util.$1 $2 $3

Javaクラスの説明

com.fatwire.security.util.CreateDefaultCredentialStore : このユーティリティは、OPSSストアに、Oracle暗号化キーのランダムに生成されたセットを移入します。このユーティリティで既存のWebCenter Sites暗号化鍵を置き換える場合は、replace引数をyesに設定します。

引数

product=sites

replace=no | yes (デフォルトはno)

com.fatwire.security.util.ExportFromCSFは、現在のストアの各WebCenter Sitesキーのソルトを抽出して、値を作業ディレクトリのexport.keysファイルに書き込みます。このエクスポート・ファイルは、次に示すインポート・ユーティリティ・プログラムの入力として使用されます。

引数:(オプション)

export.keys

com.fatwire.security.util.ImportToCSF.classは、抽出されたソルトをexport.keysファイルから取り出し、それを使用してWebCenter Sitesの各暗号化鍵を作成し、出力資格証明ストアに追加します。出力資格証明ストアは、 jps-config.xmlのlocationプロパティで定義されます。

引数

product=sites

import=export.keys

replace=no | yes (デフォルトはno)

13.2.5 ESAPIセキュリティ検証の使用

WebCenter Sitesサーバーは、Enterprise Security APIを使用して、悪意のあるWebデータのインジェクションから発生するセキュリティ脆弱性をチェックし、抑止します。ESAPI.propertiesファイルに含まれる検証式は変更できます。WebCenter Sitesサーバーをインストールする場合、このファイルはWebCenter Sites WEB-INF/classesフォルダにあります。

ESAPIの詳細は、https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_APIを参照してください。

13.3 RESTセキュリティの使用

次の各トピックでは、RESTセキュリティに関する情報を提供します。

- REST認可

- アプリケーション・リソースへのアクセスのユーザーへの認可

- RESTセキュリティ構成リファレンス

13.3.1 REST認可

REST認可は、アプリケーションのリソース(WebCenter Sites内のオブジェクトにマップされる)に対してRESTの各操作を実行するための権限を付与します。REST認可は、「デフォルトではすべてを拒否」するモデルを使用します。権限が特定のグループに対して明確に付与されていない場合、その権限は拒否されます。一般管理者は、アプリケーションがデプロイされ、WEMフレームワークに登録された後で、ユーザーを認可します。

次の各トピックでは、REST認可に関する情報を提供します。

- セキュリティ・モデル

- 権限解決アルゴリズム

13.3.1.1 セキュリティ・モデル

WEMセキュリティ・モデルはオブジェクト、グループおよびアクションに基づいています。オブジェクトとグループは、WebCenter Sitesであらかじめ定義されています(WebCenter Sites内のオブジェクトはWEMフレームワークのRESTリソースにマップされます)。アクションは、WebCenter Sitesで作成する権限(READ、CREATE)です。セキュリティは、WebCenter Sites Adminインタフェースでオブジェクト・タイプごとに構成する必要があります。

図13-2 「新規セキュリティ構成の追加」フォーム

- オブジェクトとは、サイト、ユーザーまたはアセットのような、あらゆるエンティティです。保護オブジェクトには次のタイプがあります。

- アセット・タイプ

- サイト

- ユーザー・ロケール

- アプリケーション

- アセット

- ロール

- ACL

- 索引

- ユーザー

- グループ

- セキュリティ・グループは、オブジェクトを操作する複数ユーザーの権限を管理するために使用されます。

- 所定のタイプのオブジェクトは、ユーザーが、所定のタイプのオブジェクト上で指定されたアクションを実行する権限を持つ少なくとも1つのグループに属する場合のみ、ユーザーにアクセスできます。

- アクションとは、LIST、HEAD、READ、UPDATE、CREATE、DELETEの各セキュリティ権限です。グループには、そのグループに許可されたオブジェクトを操作するための権限が割り当てられます。ACLなど一部のオブジェクトはリスト専用です(WebCenter Sitesで直接作成されますが、RESTを介しての作成はできません)。

セキュリティ構成は、次を指定する配列です。

- 保護されているオブジェクト・タイプおよびオブジェクト

- オブジェクトにアクセス可能なグループ

- グループ(およびそのメンバー)がオブジェクトに実行できるアクション

13.3.1.2 権限解決アルゴリズム

セキュリティ権限を構成する際に、特定のタイプのすべてのオブジェクトまたは特定のタイプの単一のオブジェクトに権限が適用されるように指定できます。たとえば、UPDATE (POST)への権限を任意のサイトに付与すると、グループ内のユーザーはすべてのサイトの詳細をWEMフレームワークで変更できます。avisportsサイトのUPDATE (POST)権限を付与すると、グループ内のユーザーはavisportsサイトの詳細をWEMで変更できます。

Assetオブジェクト・タイプでは、セキュリティ設定の適用先サイトを指定する必要があります。アセットは、常に特定のサイトからアクセスされるからです。サブタイプを指定することで、AssetTypeオブジェクト・タイプを調整できます。たとえば、アセット・タイプContent_Cに対するDELETE権限を設定する場合、RESTリソース/types/Content_C上でDELETEリクエストを実行します(つまり、Content_Cアセット・タイプをシステムから削除します)。

権限はグループにのみ付与できるため、ユーザーの総合的な権限は、ユーザーが属するすべてのグループにわたり計算されるまで明らかになりません。WEMフレームワークには、権限解決アルゴリズムが用意されています。その基本的な手順を次に示します。

1. RESTによって、ユーザーがメンバーシップを持つグループが検索されます。

2. RESTによって、各グループが実行できるREST操作およびその対象となるRESTリソースが判別されます。サイトまたはサブタイプが指定されている場合は、個々に考慮されます。

3. RESTによって、手順1および2の結果が比較されます。手順1で得られたグループの少なくとも1つが手順2で得られたグループのリストに存在する場合、アクセスは許可されます。そうでない場合は、アクセスが拒否されます。

13.3.2 アプリケーション・リソースへのアクセスのユーザーへの認可

ユーザーにアプリケーション・リソースへのアクセスを認可する前に、次のトピックで説明する手順に関する背景情報を、REST認可で参照してください。

- RESTセキュリティ構成の表示

- グループの作成

- グループへのユーザーの追加

- RESTリソースのセキュリティの構成

注意:

RESTリソースのセキュリティを構成するには、権限をグループに割り当てる必要があります。グループのリストを表示するには、RESTセキュリティ構成の表示に進んでください。グループを作成するには、グループの作成を参照してください。

13.3.2.1 RESTセキュリティ構成の表示

セキュリティ構成では、どのグループがどのRESTリソースに対するどの権限を持っているかを指定します。WebCenter Sitesでは、2つのデフォルト・グループのセキュリティ構成が定義されています。これらは、RestAdminとSiteAdmin_AdminSiteです。

RESTセキュリティ構成を表示するには::

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. 「一般的な管理」ツリーを選択し、続いて「管理」、「ユーザー・アクセス管理」および「RESTセキュリティ」の順に開き、続いて、「セキュリティの構成」をダブルクリックします。

「セキュリティの構成」ウィンドウがメイン・ウィンドウに開きます。

図13-3 「セキュリティの構成」フォーム

3. 要件に応じて次を実行します。

- グループを作成するには、グループの作成を参照してください。

- グループにユーザーを追加するには、グループへのユーザーの追加を参照してください。

注意:

この手順を完了するために、必要なグループが存在することを確認します。権限はグループに割り当てる必要があります。

- RESTリソースのセキュリティ権限を構成するには、RESTリソースのセキュリティの構成を参照してください。

13.3.2.2 グループの作成

1. 一般管理者としてAdminインタフェースにログインします。

2. 「編集」ツリーで「管理」ノードを開きます。「ユーザー・アクセス管理」、「RESTセキュリティ」、「グループ」の順に開きます。「新規追加」をダブルクリックします。

3. 「新規グループの追加」フォームで、作成するグループの名前と簡単な説明を入力します。

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

作成したグループが「グループ」ノードにリストされます。

5. グループを作成したら、次を実行できます。

- グループにユーザーを追加します。手順は、グループへのユーザーの追加を参照してください。

- グループのRESTセキュリティを構成します。手順は、RESTリソースのセキュリティの構成を参照してください。

13.3.2.3 グループへのユーザーの追加

グループにユーザーを追加して、アプリケーションに関連付けられたRESTリソースを操作するために持つ必要がある権限を決定します。

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. 「編集」ツリーで「管理」ノードを選択します。「ユーザー・アクセス管理」ノード→「RESTセキュリティ」ノード→「グループへのユーザーの割当て」の順に開きます。「新規追加」をダブルクリックします。

3. 「ユーザーへのグループの割当て」フォームで、ユーザーを選択し、リストされているグループの任意の組合せに対して割り当てます。

図13-4 「ユーザーへのグループの割当て」フォーム

注意:

グループに割り当てるユーザーがリストされていない場合、そのユーザーはグループのメンバーになっています。このユーザーを別のグループに割り当てるには、手順5を参照してください。

4. 「保存」をクリックします。
選択したユーザー名は、「グループへのユーザーの割当て」ノードにリストされます。特定のユーザーを含むグループを表示するには、ユーザー名をダブルクリックします。

5. (オプション)。特定のグループに割り当てるユーザーの名前が「ユーザー名」フィールドに表示されない場合、次を実行します。

a. WebCenter Sitesツリーで「管理」タブを選択します。「ユーザー・アクセス管理」ノード→「RESTセキュリティ」ノード→「グループへのユーザーの割当て」の順に開き、別のグループに割り当てるユーザーの名前をダブルクリックします。

b. ユーザーの「調査」フォームで「編集」をクリックして、「ユーザー・グループの編集」フォームを開きます。

c. 「グループ」フィールドで、ユーザーを割り当てるグループを選択して「保存」をクリックします。

6. グループにユーザーが追加されたら、次を実行できます。

- グループを作成します。詳細は、「グループの作成」を参照してください。

- グループのセキュリティを構成します。詳細は、RESTリソースのセキュリティの構成を参照してください。

13.3.2.4 RESTリソースのセキュリティの構成

セキュリティを構成する際、どのオブジェクト・タイプおよびオブジェクトにグループがアクセスできる必要があるか、およびどのアクションをグループがオブジェクトに対して実行できるかを指定します。

RESTリソースのセキュリティを構成するには::

1. 一般管理者としてAdminインタフェースにログインします。

2. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

3. 「新規セキュリティ構成の追加」フォームでは、オブジェクト・タイプおよびオブジェクトのセキュリティを設定できます。

表13-1および表13-2に、可能なセキュリティ構成の概要を示します。

表13-1 使用できるアクション(セキュリティ権限)

アクション

説明

作成

グループ・メンバーは、指定されたリソースを作成できます。

削除

グループ・メンバーは、指定されたリソースを削除できます。

リスト

グループ・メンバーは、指定されたリソースを取得できます。

読取り/先頭

グループ・メンバーは、指定されたリソースを読むことができます。読取りは、リクエストされたリソースを戻します。先頭は、リクエストされたリソースを記述したメタデータを戻します。

更新

グループ・メンバーは、指定されたリソースを変更できます。

注意: 作成と更新はそれぞれが読取り/先頭権限とペアになります。これらの権限のいずれかをグループに割り当てると、自動的に読取り/先頭権限もグループに割り当てられます。

表13-2 可能なセキュリティ構成オプションの概要

オブジェクト・タイプ

名前

サブタイプ

サイト

可能なアクション

参照項目

ACL

任意

該当なし

該当なし

リスト

ACLリソースのRESTセキュリティの構成

アプリケーション(注1参照)

任意

該当なし

該当なし

作成、更新、削除。

アプリケーション・リソースのRESTセキュリティの構成

アプリケーション

AppName

該当なし

該当なし

更新、削除

アプリケーション・リソースのRESTセキュリティの構成

アセット

任意

該当なし

任意

リスト、読取り/先頭、作成、更新、削除

アセット・リソースのRESTセキュリティの構成

アセット

任意

該当なし

SiteName

リスト、読取り/先頭、作成、更新、削除

アセット・リソースのRESTセキュリティの構成

アセット

AssetType

該当なし

SiteName

リスト、読取り/先頭(注2参照)、作成、更新、削除

アセット・リソースのRESTセキュリティの構成

アセット

AssetTypeおよびAssetName

該当なし

SiteName

読取り/先頭、更新、削除

アセット・リソースのRESTセキュリティの構成

AssetType

任意

該当なし

該当なし

リスト、読取り/先頭、作成、削除

アセット・タイプ・リソースのRESTセキュリティの構成

AssetType

AssetType

該当なし

該当なし

読取り/先頭、削除

アセット・タイプ・リソースのRESTセキュリティの構成

AssetType

AssetType

任意

該当なし

リスト

アセット・タイプ・リソースのRESTセキュリティの構成

AssetType

AssetType

サブタイプ

該当なし

読取り/先頭

アセット・タイプ・リソースのRESTセキュリティの構成

グループ

任意

該当なし

該当なし

リスト

グループ・リソースのRESTセキュリティの構成

グループ

GroupName

該当なし

該当なし

読取り/先頭

グループ・リソースのRESTセキュリティの構成

索引

任意

該当なし

該当なし

リスト、読取り/先頭、作成、更新、削除

索引付きアセット・タイプ・リソースのRESTセキュリティの構成

索引

IndexName

該当なし

該当なし

読取り/先頭、更新、削除

索引付きアセット・タイプ・リソースのRESTセキュリティの構成

ロール

任意

該当なし

該当なし

リスト、読取り/先頭、作成、更新、削除

ロール・リソースのRESTセキュリティの構成

ロール

Role

該当なし

該当なし

読取り/先頭、更新、削除

ロール・リソースのRESTセキュリティの構成

サイト

任意

該当なし

該当なし

リスト、読取り/先頭(注3参照)、作成、更新、削除

サイト・リソースのRESTセキュリティの構成

サイト

SiteName

該当なし

該当なし

読取り/先頭、更新、削除

サイト・リソースのRESTセキュリティの構成

ユーザー

任意

該当なし

該当なし

リスト、読取り/先頭、作成、更新、削除

ユーザー・リソースのRESTセキュリティの構成

ユーザー

UserName

該当なし

該当なし

読取り/先頭、更新、削除

ユーザー・リソースのRESTセキュリティの構成

UserDef

任意

該当なし

該当なし

リスト

UserDefリソースのRESTセキュリティの構成

UserLocales

任意

該当なし

該当なし

リスト

UserLocaleリソースのRESTセキュリティの構成

注意:

1. アプリケーションの設定セキュリティの例は、手順3を参照してください。

2. READの場合、名前が付けられたサイトで関連付けを読み取ることができます。

3. READの場合、名前が付けられたサイトでユーザーおよびアセット・タイプを読み取ることができます。

13.3.3 RESTセキュリティ構成リファレンス

次の参照トピックは、表13-2を補足します。各トピックで、表にあるセキュリティ構成の詳細を説明しています。

- ACLリソースのRESTセキュリティの構成

- アプリケーション・リソースのRESTセキュリティの構成

- アセット・リソースのRESTセキュリティの構成

- アセット・タイプ・リソースのRESTセキュリティの構成

- EngageリソースのRESTセキュリティの構成

- グループ・リソースのRESTセキュリティの構成

- 索引付きアセット・タイプ・リソースのRESTセキュリティの構成

- ロール・リソースのRESTセキュリティの構成

- サイト・リソースのRESTセキュリティの構成

- ユーザー・リソースのRESTセキュリティの構成

- UserDefリソースのRESTセキュリティの構成

- UserLocaleリソースのRESTセキュリティの構成

- 訪問者リソースのRESTセキュリティの構成

13.3.3.1 ACLリソースのRESTセキュリティの構成

ACLにセキュリティ権限を割り当てる際に、ACLリソース・リストをどのグループが表示できるかを決定します。

ACLのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「ACL」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

図13-5 ACLの「新規セキュリティ構成の追加」

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

13.3.3.2 アプリケーション・リソースのRESTセキュリティの構成

アプリケーションにセキュリティ権限を割り当てる際に、指定したアプリケーションに対してどのグループがどの操作を実行できるかを決定します。

アプリケーションのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「アプリケーション」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-3 「新規セキュリティ構成の追加」のフィールド名

フィールド

説明

名前

グループに権限を付与するアプリケーションの名前を選択するか、「任意」を選択してすべてのアプリケーションに対する権限をグループに付与します。

グループ。

アプリケーションを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「作成」を選択した場合、選択したグループのメンバーは、WEMでアプリケーションをアクセス可能にするアセットを作成できます。

13.3.3.3 アセット・リソースのRESTセキュリティの構成

アセットにセキュリティ権限を割り当てる際に、指定したアセットに対してどのグループがどの操作を実行できるかを決定します。

アセットのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「アセット」を選択します。

3. 「サイト」フィールドで、適切なサイトを選択します。

4. 「名前」フィールドで、「任意」を選択します。

5. 必要に応じて「グループ」および「アクション」を選択します。

6. 構成を保存するには、「保存」をクリックします。

表13-4 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

サイト

グループに権限を付与するアセットに関連付けられているサイトを選択するか、「任意」を選択してシステム全体のすべてのアセットに対する権限をグループに付与します。

名前

グループに権限を付与するアセットに関連付けられているアセット・タイプを選択するか、「任意」を選択してすべてのアセットに対する権限をグループに付与します。選択したアセット・タイプの、指定したアセットをグループが使用できるようにするには、「参照」ボタンをクリックします。

グループ。

アセットを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、特定のサイト、特定のアセット・タイプおよび「リスト」を選択した場合、選択したグループのメンバーは、指定したアセット・タイプのアセットを、指定したサイトで検索できます。

13.3.3.4 アセット・タイプ・リソースのRESTセキュリティの構成

アセット・タイプにセキュリティ権限を割り当てる際に、指定したアセット・タイプに対してどのグループがどの操作を実行できるかを決定します。

アセット・タイプのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「アセット・タイプ」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

図13-6 フィールド名の「新規セキュリティ構成の追加」フォーム

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-5 「新規セキュリティ構成の追加」のフィールド名

フィールド

説明

名前

グループに権限を付与するアセット・タイプを選択するか、「任意」を選択してすべてのアセット・タイプに対する権限をグループに付与します。

サブタイプ

(オプション)グループに権限を付与するアセット・タイプのサブタイプを選択します。

注意: 「名前」フィールドで「任意」オプションを選択した場合、「サブタイプ」フィールドは表示されません。

グループ。

アセット・タイプを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「作成」を選択した場合、選択したグループのメンバーは、アセット・タイプを作成できます。

13.3.3.5 EngageリソースのRESTセキュリティの構成

Engageリソースにセキュリティ権限を割り当てる際に、Engageに対してどのグループがどの操作を実行できるかを決定します。

グループのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「Engage」を選択します。

3. 「サイト」フィールドで、適切なサイトを選択します。

4. 「名前」フィールドで、「任意」を選択します。

5. 必要に応じて「グループ」および「アクション」を選択します。

6. 構成を保存するには、「保存」をクリックします。

表13-6 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

サイト

グループに権限を付与するアセットに関連付けられているサイトを選択するか、「任意」を選択してシステム全体のすべてのアセットに対する権限をグループに付与します。

名前

グループに権限を付与するアセットに関連付けられているアセット・タイプを選択するか、「任意」を選択してすべてのアセットに対する権限をグループに付与します。選択したアセット・タイプの、指定したアセットをグループが使用できるようにするには、「参照」をクリックします。

グループ。

アセットを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、特定のサイト、特定のアセット・タイプおよび「リスト」を選択した場合、選択したグループのメンバーは、指定したアセット・タイプのアセットを、指定したサイトで検索できます。

13.3.3.6 グループ・リソースのRESTセキュリティの構成

グループにセキュリティ権限を割り当てる際に、指定したグループに対してどのグループがどの操作を実行できるかを決定します。

グループのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「グループ」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-7 「新規セキュリティ構成の追加」のフィールド名

フィールド

説明

名前

グループに権限を付与するグループを選択するか、「任意」を選択してすべてのグループに対する権限をグループに付与します。

グループ。

グループを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「リスト」を選択した場合、選択したグループのメンバーは、システムにあるグループのリストを表示できます。

13.3.3.7 索引付きアセット・タイプ・リソースのRESTセキュリティの構成

索引付きアセット・タイプにセキュリティ権限を割り当てる際に、指定した索引付きアセット・タイプに対してどのグループがどの操作を実行できるかを決定します。

注意:

索引付きアセット・タイプのセキュリティを構成する前に、WebCenter Sitesのグローバル検索およびアセット・タイプ検索のための索引付けを有効にする必要があります。索引付けの詳細は、検索索引の設定を参照してください。

グループにグループ・セキュリティ権限を割り当てる際に、指定したグループに対してどのグループがどの操作を実行できるかを決定します。

索引付きアセット・タイプのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「グループ」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-8 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

名前

グループに権限を付与する索引付きアセット・タイプの名前を選択します。「任意」を選択すると、すべての索引付きアセット・タイプに対する権限がグループに付与されます。「グローバル」を選択すると、グローバル検索に関連付けられているすべての索引付きアセット・タイプに対する権限がグループに付与されます。

グループ。

索引付けされたアセット・タイプを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「リスト」を選択した場合、選択したグループのメンバーは、システムのすべての索引付きタイプのアセットを検索できます。

13.3.3.8 ロール・リソースのRESTセキュリティの構成

ロールにセキュリティ権限を割り当てる際に、指定したロールに対してどのグループがどの操作を実行できるかを決定します。

ロール・リソースのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ツリーを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「ロール」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-9 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

名前

グループに権限を付与するロールの名前を選択するか、「任意」を選択してすべてのロールに対する権限をグループに付与します。

グループ。

ロールを操作するための権限を付与するユーザー・グループを選択します。

アクション

セキュリティ権限をグループに割り当てます。オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「作成」を選択した場合、選択したグループのメンバーは、ロールを作成できます。

13.3.3.9 サイト・リソースのRESTセキュリティの構成

サイトにセキュリティ権限を割り当てる際に、指定したサイトに対してどのグループがどの操作を実行できるかを決定します。

サイトのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「サイト」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-10 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

名前

グループに権限を付与するサイトの名前を選択するか、「任意」を選択してすべてのサイトに対する権限をグループに付与します。

グループ。

サイトを操作するための権限を付与するユーザー・グループを選択します。

アクション

セキュリティ権限をグループに割り当てます。メニュー・オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「作成」を選択した場合、選択したグループのメンバーは、サイトを作成できます。

13.3.3.10 ユーザー・リソースのRESTセキュリティの構成

ユーザーにセキュリティ権限を割り当てる際に、指定したユーザーに対してどのグループがどの操作を実行できるかを決定します。

ユーザー・リソースのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「ユーザー」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-11 「新規セキュリティ定義の追加」のフィールド名

フィールド

説明

名前

グループに権限を付与するユーザーの名前を選択するか、「任意」オプションを選択してすべてのユーザーに対する権限をグループに付与します。

グループ。

ユーザーを操作するための権限を付与するグループを選択します。

アクション

セキュリティ権限をグループに割り当てます。メニュー・オプションは、前のフィールドで選択した値によって異なります。たとえば、「任意」および「作成」を選択した場合、選択したグループのメンバーは、ユーザーを作成できます。

13.3.3.11 UserDefリソースのRESTセキュリティの構成

ユーザー定義にセキュリティ権限を割り当てる場合、システムのユーザー定義を表示できるグループを指定します。

UserDefリソースのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「UserDef」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-12 「新規セキュリティ構成の追加」フォームのフィールド名

フィールド

説明

名前

すべてのユーザー定義に対する権限をグループに付与するオプションのみ選択できます。

グループ。

ユーザー定義を表示するための権限を付与するグループを選択します。

アクション

グループに割り当てることができるセキュリティ権限は、「読取り/先頭」のみです。これを選択すると、選択したグループのメンバーが、システムのユーザー定義を表示できるようになります。

13.3.3.12 UserLocaleリソースのRESTセキュリティの構成

ユーザー・ロケールにセキュリティ権限を割り当てる際に、UserLocaleリソース・リストをどのグループが表示できるかを決定します。

UserLocaleリソースのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「UserLocales」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 構成を保存するには、「保存」をクリックします。

表13-13 「新規セキュリティ構成の追加」のフィールド名

フィールド

説明

名前

すべてのユーザー・ロケールに対する権限をグループに付与するオプションのみ選択できます。

グループ。

ユーザー・ロケールを表示するための権限を付与するグループを選択します。

アクション

グループに割り当てることができるセキュリティ権限は、システム上のユーザー・ロケールのリストを表示する権限のみです。

13.3.3.13 訪問者リソースのRESTセキュリティの構成

訪問者にセキュリティ権限を割り当てる際に、訪問者アセットをどのグループが表示できるかを決定します。

訪問者リソースのグループ・セキュリティを構成するには::

1. 「一般的な管理」ツリーで、「管理」ノードを開き、「ユーザー・アクセス管理」、「RESTセキュリティ」および「セキュリティの構成」の順に開きます。「新規追加」をダブルクリックします。

「新規セキュリティ構成の追加」フォームが開きます。

2. 「タイプ」フィールドで、「訪問者」を選択します。

3. 「名前」フィールドで、「任意」を選択します。

4. 必要に応じて「グループ」および「アクション」を選択します。

5. 「保存」をクリックして構成を保存します。

表13-14 「新規セキュリティ構成の追加」のフィールド名

フィールド

説明

名前

すべての訪問者に対する権限をグループに付与するオプションのみ選択できます。

グループ。

訪問者のリストを表示するための権限を付与するグループを選択します。

アクション

グループに割り当てることができるセキュリティ権限は、訪問者のリストを表示する権限のみです。

第V部 パブリッシュの管理

次の各トピックでは、WebCenter Sitesのパブリッシュ・システムの管理に関する情報を提供します。

- パブリッシュの理解

- リアルタイム・パブリッシュの使用

- パブリッシュ・イベントのスケジュール

14 パブリッシュの理解

パブリッシュによりコンテンツを管理システムから配信システムにコピーすることによって、オンライン・サイトの訪問者がコンテンツにアクセスできます。WebCenter Sitesはまた、パブリッシュするコンテンツを決定する承認システム、パブリケーション時刻を設定できるスケジュール機能、およびサイト固有のパブリッシュの宛先の構成ユーティリティを提供します。

次の各トピックでは、パブリッシュ・システムと承認システムについて説明します。

- アセットのパブリッシュの前提条件

- パブリッシュの宛先

- ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可

- 承認システムの理解

- スケジュール済パブリッシュ・セッションについて

- パブリッシュ・セッションの理解

- パブリッシュ・セッションに関する情報の取得

14.1 アセットのパブリッシュの前提条件

アセットをパブリッシュするには、その前に、次のことを決定しておく必要があります。

- WebCenter Sitesが使用するパブリッシュ方法。推奨するパブリッシュ方法はリアルタイム・パブリッシュです。リアルタイム・パブリッシュの使用を参照してください。ディスクへのエクスポート、サーバーへのミラーリングまたはXMLへのアセットのエクスポートなどの代替パブリッシュ方法の詳細は、代替パブリッシュ方法を参照してください。
管理者は、パブリッシュの宛先を構成する際に、宛先に対するパブリッシュ方法を指定します。詳細は、代替パブリッシュ方法についてを参照してください。

- 特定のセッション中にWebCenter Sitesがパブリッシュする必要があるパブリッシュの宛先。
管理者は、システムに対してパブリッシュの宛先を構成します。詳細は、パブリッシュの宛先を参照してください。

- 現在の宛先にパブリッシュすることが承認済でその準備ができているアセット。この情報は、承認システムが決定します。
コンテンツ・プロバイダは、パブリケーションの準備ができているアセットに、特定のパブリッシュの宛先に対して承認済というマークを付けます。承認システムは、承認済ラベルを検証して、アセットのパブリッシュによってライブ・サイトに機能しないリンクが作成される可能性があるかどうかを判断します。その可能性がある場合、そのアセットの他のアセットに対する依存性が、ユーザーがそれらのアセットを承認することによって解決されるまで、そのアセットのパブリッシュ・セッションは保留されます。承認済アセットがどのアセットに対しても依存性を持たないか、またはその依存性が十分な場合、承認システムはそのアセットをパブリッシュ・システムにリリースします。

承認システムのプロセスは複雑で、パブリッシュ方法ごとに異なります。承認システムの機能の詳細は、承認システムの理解とディスクへのエクスポートのパブリッシュの用語の詳細を参照してください。

- アセットをパブリッシュする必要がある日時。
管理者は、パブリッシュ・スケジュールを設定します。パブリッシュ・プロセスは、一定間隔で実行されるようにスケジュールされたバッチ・プロセスとして実行されます。スケジュールを無視して、オンデマンドでパブリッシュすることもできます。スケジュールのパブリッシュの詳細は、スケジュールされたパブリッシュ・セッションについてを参照してください。

- どのユーザーに、WebCenter Sites: Contributorインタフェースから個々のアセットのオンデマンド・パブリッシュを実行する権限を付与するか。
Contributorインタフェース・ユーザーに、Contributorインタフェースからアセットをパブリッシュする権限を付与するには、各ユーザーにパブリッシャ・ロールを割り当てる必要があります。手順は、ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可を参照してください。

パブリッシュ・セッションでは、セッション情報がログ・ファイルに記録されます。パブリッシュ・コンソールを介してセッションを監視し、パブリッシュ履歴と現在実行中のパブリッシュ・セッションのステータスを判断できます。パブリッシュ・プロセスはバックグラウンドで実行されるため、ブラウザを他のタスクのために使用することもできます。パブリッシュ・セッションで発生するイベントの詳細は、パブリッシュ・セッションの理解を参照してください。パブリッシュ情報を取得する方法の詳細は、パブリッシュ・セッションに関する情報の取得を参照してください。

Contributorインタフェースから起動されたパブリッシュは、Contributorインタフェースのパブリッシュ・コンソールから参照することもできます。

14.2 パブリッシュの宛先

パブリッシュの宛先は、コンテンツのミラーリング先のWebCenter Sitesデータベースか、またはエクスポート先ディレクトリのどちらかです。パブリッシュの宛先は、次のパラメータを定義する名前付きオブジェクトとして表されます。

- パブリッシュ方法。

- 場所:

- ディスクへのエクスポートのパブリッシュおよびXMLへのアセットのエクスポートの場合、パブリッシュ・システムは承認済アセットをHTMLファイルまたはXMLファイルに変換します。場所は、ファイルが保存されるルート・ディレクトリです。このディレクトリは、wcs_propertiesファイルのcs.pgexportfolderプロパティ(「パブリッシュ」カテゴリ)で設定します。

- サーバーへのミラーリングのパブリッシュの場合、宛先は、コンテンツの配信元として想定されるサーバーの URL形式によるサーバー名(ポート番号を含む)です。(このサーバー名は「宛先」フォームの「宛先アドレス」フィールドに設定します。)

- 宛先に対してパブリッシュ可能なアセットが存在するCMサイトの名前。

どのパブリッシュ方法でも、複数のパブリッシュの宛先を構成できます。開発者によるサイトの設計方法によっては、静的コンテンツ(HTMLファイル、ディスクへのエクスポートを使用)および動的コンテンツ(サーバーへのミラーリングまたはXMLへのエクスポートのパブリッシュ方法を使用してすぐに生成されるページ)を両方ともパブリッシュする必要がある場合があります。このような二重の実装を行う場合は、開発者に相談して、パブリッシュの宛先を構成する方法を決定してください。

このドキュメントでは、パブリッシュの宛先および構成について説明する際、次の用語を使用します。

- ソース。パブリッシュ・セッションでソースとして機能するWebCenter Sitesデータベース。任意のWebCenter Sitesシステム間でアセットをミラーリングできるので、ソースは必ずしもコンテンツ管理システムではありません。

- 宛先。ミラーリング先のWebCenter Sitesデータベースか、またはエクスポート先ディレクトリのどちらかです。

パブリッシュの宛先の作成の詳細は、エクスポート先の構成およびミラーリング先の作成を参照してください。

14.3 ユーザーに対するContributorインタフェースからのアセットのパブリッシュの認可

通常、パブリッシュはAdminインタフェースからスケジュールおよび実行されます。ただし、Contributorインタフェースには、適切なロールを付与されたユーザーが使用して個々のアセットをContributorインタフェースから直接パブリッシュできるオンデマンド・パブリッシュ機能があります。

ユーザーにContributorインタフェースからアセットをパブリッシュする認可を付与するには:

1. WEM Adminインタフェースのメニュー・バーで「サイト」をクリックします。

2. 「サイト」リストで、サイト名にマウスを重ねて「サイト・ユーザーの管理」をクリックします。

注意:

Contributorアプリケーションは、選択したサイトに割り当てられている必要があります。アプリケーションのサイトへの割当ての詳細は、アプリケーション使用のユーザーへの認可を参照してください。

3. 「サイト・ユーザーの管理」リストで、Contributorインタフェースから直接アセットをパブリッシュすることを認可するユーザーを選択し、「ユーザーへのロールの割当て」を選択します。

4. 「ユーザーへのロールの割当て」フォームで、「使用可能」リスト・ボックスから「パブリッシャー」ロールを選択して、それを「選択済」リスト・ボックスへ移動します。

5. 「保存して閉じる」をクリックします。

6. Contributorインタフェースからユーザーが選択されたサイトでパブリッシュする権限を持っていることを確認します。

a. ユーザーの資格証明を使用してサイトにログインし、「コントリビュータ」アイコンを選択します。

b. Contributorインタフェースで、パブリッシュするアセットを検索して開きます。Contributorインタフェースでアセットを検索して開く手順は、『Oracle WebCenter Sitesの使用』の、アセットの検索と整理に関する項を参照してください。

c. アセットのツールバーで、「承認」アイコンを選択します。ツールチップが「パブリッシュ」となっている場合、Contributorインタフェースでパブリッシュする権限をユーザーに正常に付与できています。

14.4 承認システムの理解

特定の宛先へのパブリケーションに対してアセットが承認されると、WebCenter Sitesは承認システムを起動して、各アセットのパブリッシュの準備ができていることを確認します。承認システムは、機能しないリンクや古いコンテンツが発生しないようにサイトを保護するパブリケーション前プロセスを実行します。このプロセスでは、次の質問に対する回答を決定します。

1. パブリッシュの準備ができているのはどのアセットか。すなわち、ユーザーが承認済とマークを付けたアセットはどれか。

2. 承認済アセットに依存性があるか。すなわち、承認済アセットに他のアセットが付属する必要があるか。または、サイトのリンクがすべて正常に機能することを保証するために、宛先に他のアセットが存在する必要があるか。
たとえば、イメージ・ファイルを参照する記事アセットが存在するサイトが設定されているとします。非承認のイメージ・ファイルが関連付けられている承認済の記事は、イメージ・ファイルも承認されるまで、パブリッシュできません。

承認システムは、これらの質問に対する回答に応じて、パブリッシュ・システムに次回のパブリッシュ・セッションで承認済アセットをパブリッシュすることを許可するか、または依存性テストに不合格のアセットのパブリケーションを保留します。

注意:

ディスクへのエクスポートのパブリッシュでは、テンプレートを選択することによって、アセットに承認システムをバイパスさせることができます。ディスクへのエクスポートのパブリッシュにおける承認システムの詳細は、ディスクへのエクスポートのパブリッシュの用語の詳細を参照してください。

アセットの承認方法の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

承認システムの機能の詳細は、承認システムの理解とディスクへのエクスポートのパブリッシュの用語の詳細を参照してください。

14.5 スケジュール済パブリッシュ・セッションについて

パブリッシュ・セッションは(パブリッシュ方法に関係なく)、パブリッシュ・イベントと呼ばれるバックグラウンドのバッチ・プロセスとして実行されます。管理者は、パブリッシュ・イベントのスケジュールを構成します。

パブリッシュ・イベントは、毎日、毎週、毎時、15分間隔、またはこれらの間隔を様々に組み合せてスケジュールできます。複数のパブリッシュ・セッションをスケジュールする場合は、次のような様々なルールを考慮してください。

- 特定の宛先に対するパブリッシュは、逐次実行する必要があります。
各パブリッシュ・セッションはバックグラウンド・イベントなので、特定の宛先では同時に1つのパブリッシュ・セッションのみサポートできます。特定の宛先で次のイベントがスケジュールされている時間に、その宛先に対してパブリッシュが実行中の場合は、スケジュールされているイベントは実行しようとして失敗し、その宛先に対して実行中のパブリッシュ・セッションが存在することを報告します。

同様に、複数のソースを同一の宛先に同時にパブリッシュするように構成しないでください。そのような構成は、パブリッシュ・エラーおよびデータ整合性に関する問題の原因になります。

- 宛先システムが別の宛先へのパブリッシュを実行する可能性がある時間に、その宛先へのパブリッシュ・セッションをスケジュールしないでください。
たとえば、開発システムから管理システムにパブリッシュし、管理システムから配信システムにパブリッシュするとします。この場合、管理システムから配信システムにパブリッシュしている間に、開発システムから管理システムへのパブリッシュ・セッションをスケジュールしないでください。

- 複数の宛先に対するパブリッシュは、同時に実行できます。複数の宛先に対してイベントを設定してすべて同じ時刻を選択することによって、複数の宛先に同時にパブリッシュできます。

- Contributorインタフェースのパブリッシュ機能は、スケジュール済パブリッシュ・セッションの間は無効です。

パブリッシュ・イベントではデータベース・トランザクションを完了するので、パブリッシュ機能にユーザー・アカウントを指定する必要があります。このユーザーはバッチ・ユーザーと呼ばれ、wcs_properties.jsonファイルのxcelerate.batchuserプロパティおよびxcelerate.batchpassプロパティ(「パブリッシュ」カテゴリ)を使用して、WebCenter Sitesシステムのバッチ・ユーザー・アカウントを指定します。

注意:

パブリッシュには、バッチ・ユーザーとは別に、ミラー・ユーザーも必要です。詳細は、ユーザーの使用とサーバーへのミラーリングのパブリッシュを参照してください。

14.6 パブリッシュ・セッションの理解

パブリッシュ・システムが承認済アセットのパブリッシュを開始すると、WebCenter Sitesは次の処理を実行します。

- PubSession表に行を追加してパブリッシュ・セッションを作成し、PubSession IDという一意なIDをセッションに割り当てます。

- 問合せを実行して、パブリッシュ・セッションの宛先にパブリッシュされることが承認済で準備ができているすべてのアセットを収集します。

- 問合せによって返されたアセットをロックし、それらのアセットについてCacheManagerに通知して、パブリッシュ・セッションの実行中は編集できないようにします。

- パブリッシュ方法に適したエレメントを起動し、パブリッシュする必要があるアセットのリストを渡します。

リストのアセットは、使用するパブリッシュ方法に応じて、ファイルにレンダリングされるか、または宛先データベースにミラーリングされます。

パブリッシュ・セッションが終了すると、パブリッシュ・システムはどのアセットがパブリッシュされたかを承認システムに通知し、次にそれがページ・キャッシュを更新します。

14.7 パブリッシュ・セッションに関する情報の取得

WebCenter Sitesは、各パブリッシュ・セッションに関する情報をログ・ファイルおよびWebCenter Sitesデータベースの様々な表に書き込みます。この情報の大半は、セッションのパブリッシュ履歴として「パブリッシュ・コンソール」に表示されます。「パブリッシュ・コンソール」を表示するには、メイン・ウィンドウの一番上のボタン・バーにある「パブリッシュ」ボタンをクリックします。「トラブルシューティング」も参照してください。

注意:

「パブリッシュ・コンソール」を表示するには、xcelpublish ACLが必要です。

15 リアルタイム・パブリッシュの使用

リアルタイム・パブリッシュ・プロセスの構成時、パブリッシュの宛先とその宛先へのミラー・サイト構成データを定義します。また、パブリッシュ・スケジュールを設定し、RealTimeプロセスを使用してサイト・データを同期させることができます。パブリッシュ管理者は、処理中のセッションを監視し、パブリッシュのスケジュールを確認し、履歴レコードを調査し、さらにログの内容を表示できます。

次の各トピックでは、リアルタイム・パブリッシュを構成し、パブリッシュ・プロセスからのフィードバックを監視する方法について説明します。

- リアルタイム・パブリッシュの概要

- リアルタイム・パブリッシュの使用

- リアルタイム・パブリッシュに対するシステムの構成

- 新規リアルタイム宛先定義の追加

- サイト構成データの同期について

- 完了および遅延パブリッシュの区別

- パブリッシュ・コンソールについて

- アクティブなパブリッシュ・セッションの使用

- スケジュール済パブリッシュ・セッションの使用

- 以前のパブリッシュ・セッションの使用

- パブリッシュ・ログの使用

15.1 リアルタイム・パブリッシュの概要

リアルタイム・パブリッシュは、ステータス・メッセージの更新をリアルタイムでパブリッシュするユーザー・インタフェースから名付けられた、動的なパブリッシュ・メソッドです。プログレス・バーとマウスオーバー・ツールチップは、パブリッシュ・セッションの進行を、ソースと宛先の両方のシステムからのステータス情報とともに示します。

図15-1 「ステータスのパブリッシュ」フォーム

リアルタイム・ユーザー・インタフェースも対話形式で操作できます。承認済アセットのリストでは、アイテムを「オンデマンド・キュー」に入れることで、それらを即時パブリッシュ用に必要な数だけ選択できます。また、「非承認」を使用して、承認済アセット・リストからアセットを削除できます。オンデマンド・パブリッシュとアセットの非承認の両方で、宛先システムのWebサイトでのリンクの破壊や存在しないアセットが生じないよう、アセットの依存性が考慮されます。

ステータス・メッセージおよびアセットの承認機能に加えて、リアルタイム・ユーザー・インタフェースにも対話形式のロギング・フォームがあります。ロギング・フォームでは、ログ・エントリの検索、ページ表示およびフィルタが可能です。サマリー・ログ・メッセージの「すべて表示」リンクの上にマウス・カーソルを重ねると、エントリが開いて詳細レポートが表示されます。

リアルタイム・ユーザー・インタフェースは、複数ステージのパブリッシュ・プロセスが基礎となっています。WebCenter Sitesでは、5つのステージでWebサイトのデータがレプリケート、転送および保存されます。図15-1の「ステータスのパブリッシュ」フォームには、パブリッシュの5つのステージが表示されています。これらのステージの詳細は、リアルタイム・パブリッシュの使用を参照してください。

リアルタイム・パブリッシュを個別のステージに細分化する利点の1つは、特定のステージを完了した後でパブリッシュ・プロセスを停止し、次のステージからセッションを再開するオプションを導入できることです。

リアルタイム・パブリッシュには、完了と遅延の2つのパブリッシュ・モードがあります。WebCenter Sitesの完了パブリッシュ・モードでは、1つの連続するシーケンスでパブリッシュのすべてのステージが実行されます。WebCenter Sitesの遅延パブリッシュ・モードでは、プロセスの途中で一時停止するため、管理者がWebCenter Sites宛先データベースへのアセットの書込みを開始するタイミングを制御できます。

遅延パブリッシュを使用することで、Webサーバーのパフォーマンスにパブリッシュが与える影響を最低限に抑えることができます。管理者は、遅延パブリッシュを使用して、通信量が少ない時間帯に宛先システムの更新を実行するように時間指定できます。これは、大量のアセットをパブリッシュするときに特に便利です。

複数ステージ・パブリッシュ・プロセスのもう1つの利点は、任意に実行中のセッションをキャンセルし、必要に応じて、キャンセルされたセッションを最後に正常に完了したパブリッシュ・ステージから再開できることです。また、エラーや停電により完了しなかったパブリッシュ・セッションを再実行することもできます。

リアルタイム・パブリッシュの方法を使用することで、次の操作が可能です。

- アクティブなパブリッシュ・セッションを監視する。「ステータスのパブリッシュ」フォームのプログレス・バーに、ソースおよび宛先WebCenter Sitesシステムの両方で実行されているセッションの現在の進行状況が表示されます。

- オンデマンド・パブリッシュを使用して、承認済アセットを選択的にパブリッシュする。

- アセットを選択的に非承認にする。

- ソート可能なセッション・ログを対話形式で確認する。

- 宛先を完了パブリッシュ・モードに構成し、パブリッシュ・プロセス全体を中断のないセッションで実行する。

- 宛先を遅延パブリッシュ・モードに構成して、パブリッシュ・セッションを途中で一時停止する。これによりアセットの宛先データベースへの書込みを開始するタイミングを制御できるようになります。

- アクティブなパブリッシュ・セッションをキャンセルする。

- 取り消されたパブリッシュ・セッションを最後に完了したステージの直後から再開する。

- 失敗したパブリッシュ・セッションを再実行する。

動的パブリッシュは、WebCenter Sitesシステムから別のWebCenter Sitesシステムへ、アセットおよびそれらの基礎となるスキーマをコピーするプロセスです。リアルタイム・パブリッシュ・プロセスが機能するように、ソースとターゲットの両方のシステムがリアルタイム・パブリッシュ用に設定されている必要があります。

15.1.1 ソース・システムのパブリッシュ用構成

ソース・システムでは、次のアイテムを構成する必要があります。

- バッチ・ユーザー・アカウント。このユーザーは、パブリッシュをバックグラウンド・プロセスとして実行することを許可し、パブリッシュ・ログの場所を指定します。

- プロキシがある場合は、ローカル・プロキシ・サーバーのID。これは、wcs_propeties.jsonファイルでWebCenter Sitesのものと特定されます。

- 大規模なパブリッシュの場合(サイトの最初のパブリケーションなど)、セッション・タイムアウトをデフォルトの900秒よりも大きくすることが必要になる場合があります(たとえば、9000秒)。これを行うには、プロパティ管理ツールのAdminインタフェースを開き、cs.timeoutを9000に変更して、WebCenter Sitesを再起動します。パブリッシュが完了したときに、この値をリセットできます。

- パブリッシュの宛先。これは次の項目を特定します。

- 宛先のURLとポート

- パブリッシュ方法

- パブリッシュ・ログおよび電子メール通知のオプション

- 承認されるユーザー・ロールおよびパブリッシュの権限

- その宛先でのパブリッシュ権限を持つリアルタイム・ユーザー

さらに、パブリッシュを正常動作させるためには必須ではありませんが、定期的に承認済アセットをパブリッシュするパブリッシュ・スケジュールを構成できます。

15.1.2 宛先システムのパブリッシュ用構成

宛先システムでは、次のアイテムを構成する必要があります。

- その宛先でのパブリッシュ権限を持つリアルタイム・ユーザー・アカウント。

- パブリッシュするサイトのソース・システムのミラー・サイト構成データ。

- WebCenter Sites

- PublicationおよびSitePlanTree表データ

- 補助表(SourceやMimeTypeなど)

- アセット・タイプ

- ロール

- スタート・メニュー・アイテム *

- ワークフロー・グループとプロセス *

- ツリー・タブ *

- 保存済の検索 *

アスタリスクが付けられたアイテムは、配信システムでは通常必要ありません。

宛先システムからパブリッシュしない場合は、アセットの無効化を解除することをお薦めします。

15.2 リアルタイム・パブリッシュの使用

動的パブリッシュは、WebCenter Sitesシステムから別のWebCenter Sitesシステムへ、アセットおよびそれらの基礎となるスキーマをコピーするプロセスです。リアルタイム・パブリッシュでは、この処理が5つのステージに分けられます。

WebCenter Sitesでは、常に5つのステージが順番に実行されます。宛先が完了パブリッシュ・モードに構成されている場合、プロセスは中断なしに実行されます。遅延パブリッシュ・モードに構成された場合、プロセスが4番目のステージの前で一時停止します。セッションの完了にはユーザーの操作が必要です。

パブリッシュ・セッションの進行時に、「ステータスのパブリッシュ」フォームで各ステージの進行状況を監視できます。パブリッシュ・セッションの監視手順は、アクティブなパブリッシュ・セッションの使用を参照してください。

パブリッシュのステージは次のとおりです。

1. パブリッシュするデータの収集:

a. WebCenter SitesWebCenter Sitesのソース・システムは、このパブリッシュ・セッションの承認されたアセットをロックします。承認済アセットのロックによって、パブリッシュ中に編集されることを防止します。

b. ソース・システム上で、リアルタイム・パブリッシュは、承認システムからのデータを使用して、マニフェスト(パブリッシュするアセットのリスト)を作成します。マニフェストは、リソース・グループ(破損リンクと不完全なページができないように、まとまって宛先に存在する必要があるアセットのグループ)を識別します。

2. データのシリアライズ:

a. WebCenter SitesWebCenter Sitesのソース・システムは、次のアイテムをミラーリングします。

- アセット・タイプ

- 補助表(宛先の構成で識別)

- 承認済アセット

b. ソース・システムによってミラーリングされたデータがシリアライズされます(バイナリ形式に変換されます)。

注意:

この手順を実行するには、膨大な領域が必要です。(java.io.tempを使用して) JVMに割り当てる一時領域は、パブリッシュされるデータのサイズの少なくとも3倍にすることをお薦めします。ソースおよび宛先データベースは、表FW_PUBDATASTOREの増大を見越した十分な領域を持つ必要があります。これはソース・サイト全体(ディスク上に格納されたオブジェクトとデータベースの両方)のサイズに等しくなる可能性があるので、特に大きなバイナリが含まれる場合、必要な領域が、WebCenter Sitesが使用中の領域を上回ることがあります。

3. ターゲットへのデータの送信:

a. WebCenter Sitesの宛先データベースは、このパブリッシュ・セッションの承認されたアセットをロックします。ターゲットのアセットがロックされると、編集できなくなります。

b. WebCenter SitesWebCenter Sitesのソース・システムは、宛先にマニフェストとシリアライズされたすべてのデータを送信します。これらのデータは、宛先のデータベースに対してまだコミットされていません。

遅延パブリッシュ・セッションは、この時点で一時停止します。このセッションは、管理者が「パブリッシュ・コンソール」フォームまたは「ステータスのパブリッシュ」フォームで「再開」ボタンを選択した場合にのみステージ4から続行します。

4. データのデシリアライズと保存:

a. WebCenter Sitesの宛先システムで、ミラーリングされたアセット・タイプ、補助表および承認済アセットがデシリアライズされます(WebCenter Sites形式に戻されます)。

b. 宛先データベースでは、デシリアライズされたアセット・タイプと補助表に更新されるか、それらが新しいデータとして追加されます。

c. 宛先システムではマニフェストを使用して、データベースにアセットをコミットするタイミングが決定されます。リソース・グループのアセットは、グループ内のすべてのアセットがデシリアライズされたときにのみコミットされます。

d. 宛先システムは、リソース・グループ内のすべてのアセットをコミットすると、次の処理を行います。

i. 編集のためにデータベース内のアセットのロックを解除します。パブリッシュ・セッションが実行されると、宛先データベース内のパブリッシュされた編集可能アセットの数が増加します。

ii. 宛先システムからソース・システムに、正常にパブリッシュされたアセットを識別するメッセージが送信されます。リソース・グループ内のアセットは、ソース・システムで編集のためにロックが解除されます。パブリッシュ・セッションが実行されると、ソース・システムの編集可能アセットの数が増加します。

5. ページ・キャッシュの更新:
宛先システムでパブリッシュ・プロセスが完了します。

a. ページ・キャッシュがフラッシュされ、期限切れのページが削除されます。

b. キャッシュに新しいページが追加されます。

図15-2 パブリッシュの5つのステージ

15.3 リアルタイム・パブリッシュに対するシステムの構成

次の各トピックでは、リアルタイム・パブリッシュ環境に、インストールしたWebCenter Sitesとビジネス慣行に固有の情報を構成する手順を説明します。

- バッチ・ユーザー・アカウントの作成(存在しない場合)

- 宛先システムの設定

- ソース・システムのプロキシ・サーバーの識別

- ソース・システムでのリアルタイム宛先定義の作成

- 宛先データベースの初期化

- 宛先データベースへのサイト構成データのミラーリング

- パブリッシュ・プロセスのテスト

- パブリッシュされたサイトのテスト

- スケジュールの設定

- 配信システムでのアセットの無効化の解除

15.3.1 バッチ・ユーザー・アカウントの作成(存在しない場合)

構成しているパブリッシュの宛先の数やタイプに関係なく、この手順はソース・システムごとに1回のみ実行する必要があります。

バッチ・ユーザー・アカウントを作成していない場合、これを作成します。パブリッシュのいずれのタイプを実行する場合でも、あらかじめバッチ・ユーザー・アカウントが必要です。ソース・システムにバッチ・ユーザー・アカウントが存在する場合は、宛先システムの設定に進みます。

バッチ・ユーザー・アカウントには、次の2つの目的があります。

- ソース・システムのバックグラウンド・プロセスとしてパブリッシュ・プロセスを実行できるようにする。

- パブリッシュ・ログを保存する場所を指定する。

注意:

xcelerate.batchhostプロパティを、ソース・システムをホストしているアプリケーション・サーバーのホスト名に設定します。ソース・システムが、バッチ・ホストになります。Webサーバーが80以外のポート番号を使用している場合は、そのポート番号も含める必要があります。たとえば、myserver:7001と指定します。WebCenter Sites環境がクラスタ化されている場合、サポートされるバッチ・ホストは1つのみです。xcelerate.batchhostプロパティは、クラスタ・メンバーごとに専用ホストを指定するように設定する必要があります。

バッチ・ユーザー・アカウントを作成するには::

1. ソース・システムのAdminインタフェースにログインします。

2. 「管理」タブで、「ユーザー・アクセス管理」を開き、 「ユーザー」をダブルクリックします。

3. ソース・システム上のパブリッシュ・システムが使用するユーザー・アカウント(つまりバッチ・ユーザー)を作成し、次のACLに割り当てます。

- Browser

- ElementEditor

- PageEditor

- TableEditor

- UserReader

- Visitor

- VisitorAdmin

- xceladmin

- xceleditor

この手順のヘルプが必要な場合、Adminインタフェースでのユーザーの作成を参照してください。

4. プロパティ管理ツールを開きます:

「管理」ツリーで、「システム・ツール」ノードを開き、「プロパティ管理」をダブルクリックします。

注意:

プロパティ管理ツールの使用の詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

5. 「カテゴリ」ドロップダウン・メニューで、「パブリッシュ」を選択します。

6. 「検索」をクリックします。

7. 次のプロパティに対し値を設定します。

- xcelerate.batchhost
このプロパティを、ソース・システムをホストしているアプリケーション・サーバーのホスト名に設定します。ソース・システムが、バッチ・ホストになります。Webサーバーが80以外のポート番号を使用している場合は、そのポート番号も含める必要があります。たとえば、myserver:7001と指定します。WebCenter Sites環境がクラスタ化されている場合、サポートされるバッチ・ホストは1つのみです。xcelerate.batchhostプロパティは、クラスタ・メンバーごとに専用ホストを指定するように設定する必要があります。

- xcelerate.batchuser
このプロパティを、この手順の手順3で作成したユーザーの名前に設定します。

- xcelerate.batchpass
このプロパティを、この手順の手順3で作成したユーザーのパスワードに設定します。

- request.folder
このプロパティでは、パブリッシュ・ログ・ファイルを保持するディレクトリを参照します。デフォルトでは、このプロパティは、アプリケーション・サーバーのインストール・ディレクトリのdispatcherサブディレクトリに設定されています。

注意:

このプロパティを書き込み可能なディレクトリに設定していることを確認してください。設定されていない場合、「パブリッシュ・コンソール」の「パブリッシュ履歴」タブに何もセッション情報が表示されません。

8. アプリケーション・サーバーを再起動します。

15.3.2 宛先システムの設定

ソースと宛先システムに同じデータベース・スキーマが存在しないかぎり、データを動的にパブリッシュすることはできません。この手順では、ソース・データベースの補助表の構造が宛先データベースに再現されるようにします。

また、宛先では、ミラー・ユーザーがパブリッシュ中に宛先システムでデータベース・トランザクションを完了する必要があります。ミラー・ユーザーが確実に宛先に存在するようにします。(ミラー・ユーザーは、ソース・システムに存在するバッチ・ユーザーとは異なります。)

宛先システムを設定するには::

1. ユーザーがパブリッシュするアセットのタイプをソース・システムのどの補助表でサポートするかを指定し、宛先システムで表構造を手動で再作成します。

注意:

補助表はアセット・タイプをサポートするカスタム定義の表です。この表は、WebCenter SitesのAssetMakerまたはフレックス・ファミリ・メーカーを使用して作成されます。補助表の例には、Source、MimeType、lookup表(アセット・タイプの異なる属性用)などがあります。

ソース・システムと宛先システムのデータベース・プロパティは、完全には一致していなくても、特にデータベース・スキーマ・オプション(プロパティ管理ツールで設定するwcs_properties.jsonファイルにあります)は互換性がある必要があります。データベース・スキーマ・プロパティを変更する場合は、必ずアプリケーション・サーバーを再起動します。

2. 宛先システムに(管理者のインタフェースを使用して)リアルタイム・ユーザーを作成します。次の点に注意してください。

注意:

リアルタイム・ユーザーは、サーバーへのミラーリングのパブリッシュ用に構成されたミラー・ユーザーと同じ権限を持ちます。ミラー・ユーザーがサーバーへのミラーリングのパブリッシュ用に構成されている場合、同じユーザーをリアルタイム・ユーザーとして使用できます。

- 基本的な権限 : リアルタイム・ユーザーには次のACLが割り当てられている必要があります。

- Browser

- ElementEditor

- PageEditor

- TableEditor

- Visitor

- VisitorAdmin

- xceladmin

- xceleditor

- 追加の権限: リアルタイム・ユーザー・アカウントは、CacheManagerによってパブリッシュ・セッションの後にページ・キャッシュを再生成するために使用されるため、リアルタイム・ユーザーには、キャッシュ内のすべてのページを再生成するのに十分な権限が与えられる必要があります。したがって、リアルタイム・ユーザー・アカウントには、SiteCatalog表またはレンダリングするデータを保持するデータベース表内のページ・エントリに割り当てられるすべてのACLが割り当てられる必要があります。

ミラー・ユーザーの作成のヘルプが必要な場合、Adminインタフェースでのユーザーの作成を参照してください。

15.3.3 ソース・システムのプロキシ・サーバーの識別

構成しているパブリッシュの宛先の数やタイプに関係なく、この手順はソース・システムごとに1回のみ実行する必要があります。

ローカル・プロキシがすでにソース・システムで識別されているか、プロキシ・サーバーが使用されていない場合は、ソース・システムでのリアルタイム宛先定義の作成にスキップします。

ソース・システムへのプロキシ・サーバーを識別するには、次のトピックの1つを参照してください。

- すべての宛先についてのソース・システムでのローカル・プロキシ・サーバーの識別

- ローカル・プロキシ・サーバーをソース・システムで宛先ごとに識別する

15.3.3.1 すべての宛先についてのソース・システムでのローカル・プロキシ・サーバーの識別

1. Adminインタフェースで、プロパティ管理ツールを開きます。

2. 「カテゴリ」ドロップダウン・メニューで、「パブリッシュ」を選択します。

3. 「検索」をクリックします。

4. 次のプロパティに対し値を設定して保存します。

- cs.mirrorproxyserver
このプロパティを、ローカル・プロキシ・サーバーの名前かIPアドレスに設定します。

- cs.mirrorproxyserverport
このプロパティをローカル・プロキシ・サーバーのポート番号に設定します。

5. アプリケーション・サーバーを再起動します。

15.3.3.2 ローカル・プロキシ・サーバーをソース・システムで宛先ごとに識別する

1. 管理インタフェースで、「管理」ツリーを選択します。「管理」、「パブリッシュ」、「宛先」の順に開き、宛先を開きます。

メイン・フォームで宛先が開きます。

2. 「編集」をクリックします。

宛先の「宛先の編集」フォームが表示されます。

3. 「他の引数」フィールドに次を入力します。

PROXYSERVER=wcs.example.com&PROXYPORT=8080

wcs.example.comはローカル・プロキシ・サーバー、8080はプロキシが動作するポートです。

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

15.3.4 ソース・システムでのリアルタイム宛先定義の作成

この手順では、パブリッシュの宛先をソース・システムに定義します。

注意:

複数の宛先を定義可能ですが、順次的なパブリッシュのみがサポートされることに注意してください。

1. ソース・システムで、管理者のインタフェースにログインします。

2. 「一般的な管理」ツリーで、「管理」、「パブリッシュ」および「宛先」を開きます。

3. 「宛先」で、「新規追加」をダブルクリックします。

「新規宛先の追加」フォームが表示されます。

4. 「新規宛先の追加」フォームに入力します。次の情報をガイドラインとして使用してください。

- 名前: 一意の宛先の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

- 配信タイプ: 「リアルタイム: リモート動的サーバーへのアセットのコピー」を選択し、次のいずれかのオプションを選択します。

- パブリッシュの完了: パブリッシュ・プロセスを中断することなくアセットを宛先アドレスにコピーします。

- 遅延されたパブリッシュ: アセットが宛先データベースへコミットされる前に、パブリッシュ・プロセスが一時停止されます。セッションを再開するには、ユーザーがパブリッシュの4番目のステージを開始する必要があります(データのデシリアライズ(拡張)と、宛先データベースへの保存)。遅延パブリッシュの詳細は、遅延パブリッシュ・セッションの再開を参照してください。

- 宛先アドレス: 表示された形式でURLを入力します。[targetserver:port]には、大カッコを取り、宛先システムのホスト名またはIPアドレスを入力し、宛先で使用されるポートを指定します。(URLは、動的に付加されるため、URLの後にスラッシュが必要です。)

- リモート・ユーザー: 宛先システムの設定で作成したリアルタイム・ユーザーの名前を入力します。このユーザーは、宛先システム上のリアルタイム・キューを解凍するために、パブリッシュ・システムによって呼び出されます。

- リモート・パスワード: リアルタイム・ユーザーのパスワードを入力します。

- 失敗時の電子メールの送信: パブリッシュに失敗した場合に、その影響についての電子メール通知が必要な場合は、このチェック・ボックスを選択し、表示されたフィールドに入力します。

- 電子メールID: 受信者の電子メール・アドレスを入力します。(このフィールドは、「失敗時の電子メールの送信」を選択した場合にのみ使用可能になります。)

- 詳細出力: パブリッシュ・プロセス中に詳細エラー・ロギングを有効にするには、このオプションを選択します。このオプションを選択した場合、エラー・メッセージの追加のメッセージがPubMessage表に書き込まれます。追加情報によりパブリッシュ・プロセスが長くなるため、このパラメータはトラブルシューティングの場合にのみ選択してください。

- 他の引数: このパラメータは予約されています。この時点で指定できる追加の引数はありません。

- サイト: アセットを承認し、この宛先に対してパブリッシュすることが可能なサイトを選択します。

- ロール(パブリッシュの承認): アセットの承認権限を割り当てるロールを選択します。このロールが割り当てられたすべてのユーザーは、アセットを承認できます。

- ロール(パブリッシュ): パブリッシュ権限を割り当てるロールを選択します。これらのロールが割り当てられたすべてのユーザーは、パブリッシュと「パブリッシュ・コンソール」の表示ができます。

5. 「新規宛先の追加」をクリックします。

WebCenter Sitesによって、情報がPubdestination表に書き込まれ、「調査」フォームに宛先の定義が表示されます。

図15-3 「パブリッシュの宛先」フォーム

注意:

宛先名の横の赤いボタンは、ターゲット・サーバーが見つからないことを意味します。一般的には、ターゲットURLが正しくないか、ターゲット・サーバーが実行されていないことが原因です。

6. さらに、宛先の定義を作成する必要がある場合は、新しい定義ごとに手順3から5を繰り返してください。

7. 宛先システムを初期化する準備ができたら、次の項、宛先データベースの初期化に進みます。手順3から始めてください。

15.3.5 宛先データベースの初期化

宛先データベースへパブリッシュする前に、そのデータベースを初期化する必要があります。初期化するには、2つの構成要素、WebCenter Sitesと、補助表(ユーザーがパブリッシュするアセットのタイプをサポートします)のデータをミラーリングします

PublicationおよびPublicationTree表は、ミラーリングのために選択したサイト名と表データで更新されます。

宛先を初期化するには::

1. ソース・システムの「一般的な管理」ツリーで、「管理」、「パブリッシュ」および「宛先」を開きます。

2. 「宛先」で、初期化するリアルタイム宛先をダブルクリックします。

3. 「パブリッシュの宛先」フォームで、「リアルタイム宛先の初期化」をクリックします。

「リアルタイム宛先の初期化」フォームが表示されます。

4. 「サイト」フィールドで、この宛先にアセットをパブリッシュするサイトを選択します。

5. 「補助表」フィールドで、次の表の名前を入力します。

- Source: いずれかのアセット・タイプに対してソース機能を使用している場合。

- MimeType: フレックス・フィルタ・アセット、ImageFileアセット・タイプを使用している場合、またはいずれかのカスタム・アセット・タイプに対してMimeType表を使用している場合。

- Filters: サイトでフレックス・フィルタを使用している場合。(Filters表には、フレックス・フィルタで使用するクラスがリストされます。jarファイルとクラスを手動でコピーする必要があります。)

- アセット・タイプのその他の補助表(参照表など)。

注意:

表名に指定するフィールドは5つのみです。6つ以上の表名を入力する必要がある場合、最初の5つの表に対してこの手順の6までを行い、次に残っている表に対して手順3から 6を繰り返します。

6. 「ミラー」をクリックします。

初期化に成功した場合は、WebCenter Sitesに確認メッセージが表示されます(不成功の場合はエラー・メッセージが表示されます)。

手順4で選択したサイトに基づき、Publication、SitePlanTreeおよびAssetTypeの各表の対応する行が宛先にコピーされます。

手順5で補助表を指定した場合は、その表のすべての行が宛先にコピーされます。

注意:

SitePlanTreeの既存のページ・アセットの下に新しいページを追加すると、親ページが変更済とマークされます(つまり、承認が必要)。ただし、依存関係はキャッシュに反映されず、親をパブリッシュしなくても子ページ・アセットをパブリッシュできます。親ページ・アセットがキャッシュからフラッシュされず、親にあるナビゲーション上に子ページ・アセットが表示されなくなることがあります。

15.3.6 宛先データベースへのサイト構成データのミラーリング

この手順では、ソースのサイト構成データ(アセット・タイプやスタート・メニュー・アイテムなど)を宛先データベースにミラーリングします。

1. ソース・システムの「一般的な管理」ツリーで、「管理」、「サイト」の順に開き、宛先にデータをパブリッシュするサイトをダブルクリックします。

2. 「パブリッシュの宛先」(フォームの下部近く)で、宛先の「ミラー・サイト構成」をクリックします。

「ミラー・サイト構成」フォームが開きます。

図15-4 「ミラー・サイト構成」フォーム

3. 宛先へミラーリングするデータを選択します。

注意:

ミラーリングするために選択するデータは、通常宛先システムの目的によって異なります。

- 宛先システムが、配信用としてのみ使用される場合、アセット・タイプのみをミラーリングすることが適切です。

- コンテンツの管理機能がサポートされる場合は、残りのデータも同様にミラーリングします。

- アセット・タイプ: 宛先で使用可能にするアセット・タイプを選択します。
アセット・タイプにサブタイプおよびカテゴリがある場合、「アセット・タイプ」セクションのリストから適切なオプションを選択し、対応するチェック・ボックスを選択します。たとえば、AssocNamed表には、アセット・タイプのアソシエーションに関する情報が含まれます。表は、「選択したアセット・タイプのアセットのアソシエーション」と関連するアセット・タイプを選択している場合にのみミラーリングされます。

- スタート・メニュー・アイテム: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意のスタート・メニュー・アイテムを選択します。

- ワークフロー・プロセス: アセット・タイプのワークフロー・プロセスがある場合、これらのプロセスおよび適切なワークフロー・アイテムを選択します。

- ワークフロー・グループ: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意のワークフロー・グループを選択します。

- ツリー・タブ: 宛先で使用可能にするツリー・タブを選択します。

- 保存済検索: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意の保存済検索を選択します。

- ロール: 宛先に存在する必要があるロールを選択します。

4. 「ミラー」をクリックします。

手順3で選択したアセット・タイプの構成オプションを基に、AssocNamed、AssocNamed_SubtypesおよびCategoryの各表の該当する行が宛先にコピーされます。

- 「スタート・メニュー・アイテム」または「保存済検索」を選択した場合、これらの機能を実装する表の該当する行が、宛先にコピーされます。

- 手順3で選択したワークフロー構成オプションを基に、ワークフロー表の該当する行が宛先にコピーされます。

5. アセットを宛先にパブリッシュするサイトごとに手順1から4を繰り返します。

15.3.7 パブリッシュ・プロセスのテスト

パブリッシュ・プロセスは、すべてのパブリッシュ可能アセットまたはその一部を使用してテストできます。テスト環境にアセットをパブリッシュするには、先にパブリッシュするアセットを承認する必要があります。次の各トピックでは、アセットの承認およびパブリッシュについて説明します。

- アセットの承認

- アセットのパブリッシュ

15.3.7.1 アセットの承認

アセットを承認するには、次のいずれかを実行します。

- パブリッシュ・プロセス全体をテストするには、パブリッシュする予定のすべてのアセットを承認する必要があります。複数のアセットの一括承認のヘルプは、複数アセットの承認を参照してください。

- 構成の単純なテストを実行する場合は、依存が数個のみのホームページ・アセットを一時的に作成します。

15.3.7.2 アセットのパブリッシュ

承認済アセットでテスト・パブリッシュ・セッションを実行するには::

1. ソース・システムのボタン・バーで「パブリッシュ」をクリックします。

2. 「パブリッシュ・コンソール」で、リストからリアルタイム宛先を選択し、「宛先の選択」をクリックします。

WebCenter Sitesに、この宛先にパブリッシュする準備のできているアセットに関する情報が表示されます。

3. 宛先が初期化されていない場合は、すぐに初期化しないとパブリッシュ・セッションが失敗します。宛先を初期化するには、「パブリッシュ・コンソール」コンソールで「ターゲットでのサイトの作成」をクリックします(または宛先データベースの初期化の手順に従います)。これにより、宛先に基本的なサイト情報が作成されます。

4. 「パブリッシュ」をクリックします。

パブリッシュ・システムにより、この宛先に対して承認されたすべてのアセットが、その宛先システムのWebCenter Sitesデータベースにミラーリングされます。

15.3.8 パブリッシュされたサイトのテスト

パブリッシュされたサイトをテストするには、宛先システムでホームページ・アセットをブラウザからポイントし、サイトを確認します。

ホームページ・アセットのURLが決定していない場合は、まずこれを決定する必要があります。WebCenter SitesのURLは、次のように値を連結して構成します。

http://<targetserver:port>/<cgipath>/ContentServer?pagename=<your_home_page>/<other_info>

この例の説明は、次のとおりです。

- <targetserver:port>は、宛先システムのホスト名またはIPアドレスです(ポート番号が付く場合もあります)。

- <cgipath>は、wcs_properties.jsonファイルのft.cgipathプロパティの値です。たとえば、<cgipath>は、Oracle WebLogic Serverやその他のサーブレット・アーキテクチャを持つアプリケーション・サーバーの場合、/servlet/です。

- ContentServer?pagename=は、このURLで表示されるページの名前を設定します。

- <your_home_page>は、SiteCatalogエントリからのホームページ名です。

- <other_infoは、WebCenter Sitesページの基準変数(c、cid、tidおよびp)で渡される追加情報です(これらの変数の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください)。

たとえば、Burlington FinancialのホームページのURLは、WebCenter Sitesスタートアップ・キットによってレンダリングされた場合、次のようになります。

http://localhost:7001/servlet/
ContentServer?pagename=BurlingtonFinancial/Page/Home

ホームページのURLを決定し、サイトをテストするには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。この手順のヘルプは、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

a. 「カテゴリ」ドロップダウン・メニューで、「コア」を選択し、続いて「検索」をクリックします

b. ft.cgipathおよびft.approotプロパティを見つけて、値を書きとめます。

2. テキスト・エディタを開き、URLを構成します。

a. http://またはhttps:// を入力し、続けて<targetserver:port>/<cgipath>/を入力します
例:

http://example.com:8080/servlet/

(Oracle WebLogic ServerおよびIBM WebSphereの場合)

b. 文字列の後に、次のテキストを追加します。

ContentServer?pagename=<your_home_page>

これで、URLが次の例のようになるはずです(Oracle WebLogic ServerおよびIBM WebSphereの場合)。

http://bigfatsun.fatwire.com:8080/servlet/
ContentServer?pagename=ExampleSite/Page/Home

3. ブラウザが構成したURLをポイントするようにします。

4. エラーがないかページをスキャンし、すべてのリンクをテストしてこれらが機能することを確認します。

注意:

アセットとして保存されていないコンテンツ(WebCenter Sitesの外部に保存されたコンテンツ)に関連するエラーが検出された場合、適切な転送プロトコルを使用して、そのコンテンツをパブリッシュします。詳細は、スケジュールの設定を参照してください。

テスト戦略を考慮した時間に、システムの完全なテストを実施することをお薦めいたします。サイト全体を最初にミラーリングした後に負荷がピークの条件で実施し、その後に標準的な時間帯で実施します。

15.3.9 スケジュールの設定

宛先を正しく設定したら、ソースのパブリッシュ・システムの構成を完了します。

- ソース・システムで、宛先へのパブリッシュ・セッションを実行する時間をスケジュールします。この手順の詳細は、パブリッシュ・イベントのスケジュールを参照してください。

- Webサーバーでアセットではなくイメージとして保存されているイメージ・ファイルをサイトで使用している場合、CMシステムWebサーバーから配信システムWebサーバーにイメージ・ファイルを移動する方法を計画してください。たとえば、FTPです。

- CSElementアセットやSiteEntryアセットではないエレメントおよびSiteCatalogページを使用している場合、CatalogMoverツールを使用してこれらを宛先システムにミラーリングする必要があります。CatalogMoverのヘルプは、『Oracle WebCenter Sitesでの開発』を参照してください。

15.3.10 配信システムでのアセットの無効化の解除

デフォルトでは、宛先での連鎖的なパブリッシュは無効になっています。つまり、宛先パブリッシュ・システムでは、アセットがパブリッシュされたという理由のみで、パブリッシュされたアセットごとに変更済のマークが付けられます。したがって、アセットをさらに他の宛先にパブリッシュできるようにするには、アセットが現在の宛先から承認されることが必要です。

配信システムなど、最終宛先上のアセットについては、アセットの無効化を解除する必要があります。そこからアセットがパブリッシュされることはありません。アセットの無効化を解除するには、次の手順を実行します。

1. 最終宛先システム上のAdminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「名前」フィールドに、xcelerate.publishinvalidateと入力します。

3. 「検索」をクリックします。

4. フォームの「プロパティ」セクションで、プロパティの名前を選択します。

5. このプロパティの値をfalseに変更します。

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

15.4 新規リアルタイム宛先定義の追加

あるリアルタイム宛先へパブリッシュするようにソース・システムを構成したら、必要に応じて他のリアルタイム宛先を定義できます。次の手順のみを実行します。

1. 宛先システムの設定

2. ソース・システムでのリアルタイム宛先定義の作成

3. 宛先データベースの初期化

4. 宛先データベースへのサイト構成データのミラーリング

5. パブリッシュ・プロセスのテスト

6. パブリッシュされたサイトのテスト

7. スケジュールの設定

8. 配信システムでのアセットの無効化の解除

15.5 サイト構成データの同期について

アセットのパブリッシュに加えて、ソースと宛先間のサイト構成を同期できます。たとえば、開発システムから管理システムまたは配信システムへとサイト構成データを同期できます。

「ミラー・タイプ構成」ページは次の場合に使用します。

- アセット・タイプをサポートする構成アイテム(スタート・メニュー・アイテム、アソシエーション、アセット・タイプなど)を移動する。

- 管理者または開発者が、既存のアセット・タイプにカテゴリまたはサブタイプを追加する場合。

- ワークフロー構成データを開発システムから管理システムに移動する。

「サイト構成」フォームの使用手順は、宛先データベースへのサイト構成データのミラーリングを参照してください。

「ミラーリング先の初期化」ページは次の場合に使用します。

- 管理者または開発者が、パブリッシュするサイトまたは補助表をシステムに追加する場合。

- 構成をトラブルシューティングする必要がある場合。リアルタイム宛先を正常に初期化できれば、ソース・システムと宛先システム間での通信が行われています。

「ミラーリング先の初期化」フォームの使用手順は、宛先データベースの初期化を参照してください。

15.6 完了および遅延パブリッシュの区別

パブリッシュ・セッションは、完了と遅延の2つのモードのいずれかで実行できます。リアルタイム・パブリッシュに対するシステムの構成に示されているように、モードは明示的に指定する必要があります。

- 完了パブリッシュ・セッションでは、リアルタイム・パブリッシュの5つのステージが、中断のない1つのシーケンスで実行されます。セッションには、停止と再開、または取消のオプションがあります。

- 遅延パブリッシュの場合、セッションは2番目のステージ(データ・シリアライズ)の後で一時停止します。セッションを完了するまで実行するの場合、セッションを再開する必要があります。以降のステージは自動的に実行されます。
遅延パブリッシュの場合、システムが接続先データベースへの書込みをいつ開始するかを制御可能です。たとえば、大量のアセットを通信量が多いWebサイトにパブリッシュする場合、遅延パブリッシュによって、通信量の少ない期間まで待つという選択もできるため、宛先データベースへデータを保存するプロセスを効率化できます。

この章では、完了および遅延パブリッシュ・セッションを監視する手順、パブリッシュのスケジュールを調整する手順および以前のセッションの履歴を取得する手順について説明します。

15.7 パブリッシュ・コンソールについて

リアルタイム・パブリッシュでは全般にわたって「パブリッシュ・コンソール」を使用します。「パブリッシュ・コンソール」では、構成済のすべてのパブリッシュの宛先に対して、現在のパブリッシュ・セッション、スケジュール済パブリッシュ・セッション、および以前のパブリッシュ・セッションに関する情報がやり取りされます。

「パブリッシュ・コンソール」を開くには、Adminインタフェースにログインし、ボタン・バーの「パブリッシュ」をクリックします。

図15-5 パブリッシュ・コンソール

- 「アクティブ」タブには、AdminおよびContributorインタフェースから起動された進行中のパブリッシュ・セッションの概要が表示されます。パブリッシュ・セッションが実行されている間に、「ステータスのパブリッシュ」フォームを開いて、パブリッシュ・プロセスに関する詳細情報をリアルタイムに確認できます。また、対話形式ログの内容を表示できます。パブリッシュ・セッションが完了すれば、テキストのログをダウンロードできます。「アクティブ」タブの機能を使用する方法の詳細は、アクティブなパブリッシュ・セッションの使用を参照してください。ログの使用の詳細は、ログの表示と検索を参照してください。

- 「スケジュール済」タブには、パブリッシュ・セッションの宛先およびスケジュールごとに、承認済アセットの数が表示されます。「スケジュール済」タブの機能を使用する方法の詳細は、スケジュール済パブリッシュ・セッションの使用を参照してください。

- 「履歴」タブには、以前のパブリッシュ・セッションに関するサマリー情報が表示されます。「履歴」タブの使用方法の詳細は、以前のパブリッシュ・セッションの使用を参照してください。このタブでは、以前のパブリッシュ・セッションのログにアクセスすることもできます。ログの詳細は、パブリッシュ・ログの使用を参照してください。

15.8 アクティブなパブリッシュ・セッションの使用

パブリッシュ・コンソールの「アクティブ」タブには、AdminとContributorインタフェースから起動された、現在実行中のすべてのパブリッシュ・セッションに関する情報が表示されます。「アクティブ」タブでは、宛先名をクリックして、選択したセッションの「ステータスのパブリッシュ」フォームにアクセスできます。「ステータスのパブリッシュ」フォームでは、セッションの実行時に進行状況を監視できます。

このセクションの手順は、パブリッシュの完了と遅延の両方のモード(完了および遅延パブリッシュの違いを参照)に適用されます。

次の各トピックでは、アクティブなパブリッシュ・セッションの使用について説明します。

- パブリッシュ・セッションの監視

- 遅延パブリッシュ・セッションの再開

- パブリッシュ・セッションの取消し

注意:

遅延パブリッシュ・セッションは、一時停止しているときも、「アクティブ」タブのリストに残されます。取り消されたセッションは「履歴」タブに移動されます。

15.8.1 パブリッシュ・セッションの監視

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

「アクティブ」タブが表示された状態で、「パブリッシュ・コンソール」が開かれます。

図15-6 パブリッシュ・コンソール

この画面では、いくつかのアクションに注意してください。

- 「アクティブ」タブ上で円を描く緑色の矢印は、少なくとも1つのセッションが進行中であることを示します。カッコ内の数は、進行中セッションの数を示します。

- 「宛先」列に表示される各宛先は、アクティブなリンクです。宛先をクリックすると、それの「パブリッシュ・ステータス」フォームが開きます。

- 「ログの表示」チェック・ボックスを選択すると、作成中のログが表示されます。

- 赤いボタンをクリックすると、セッションが取り消されます。

2. セッションを監視するには、「アクティブ」タブ内で、実行中のセッションの宛先を選択します。

「ステータスのパブリッシュ」フォームが開きます。

図15-7 ステータスのパブリッシュ

パブリッシュのステージが1つずつ表示された5つのステータス・バーに注目してください。これらのステータス・バーは対話型の操作が可能です。

ステージの進捗状況の割合を表示するには、そのステージのステータス・バーの上にカーソルを置きます。このステータス・バーの上にカーソルを重ねると、現在処理されているアセット・タイプを示す別のツールチップが開きます。そのまま重ねていると、そのツールチップはリアルタイムで更新され、常にパブリッシュ・システムの最新のアクションを表示します。

セッションの実行中に、「ログの表示」をクリックして、そのログを表示することもできます。「ログのダウンロード」をクリックして、完了後に表示するログをダウンロードできます。

15.8.2 遅延パブリッシュ・セッションの再開

遅延パブリッシュの場合、システムが宛先のWebCenter Sitesデータベースへ書込みを開始するタイミングを制御可能です。このパブリッシュのモードは、大量のアセットをパブリッシュするとき、通信量の少ない時間帯まで宛先データベースへのデータの保存の開始を待機させる場合に使用できます。

セッションが遅延パブリッシュ・モードで実行されている場合、2番目のステージ(データ・シリアライズ)の後で一時停止します。セッションが一時停止の場合でも、現在のセッションが完了するまで、その宛先に対して他のパブリッシュ・セッションを実行することはできません。セッションを完了する場合、そのセッションを再開する必要があります。以降のステージは自動的に実行されます。

遅延パブリッシュ・セッションを再開するには:

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

2. 「アクティブ」タブ内で、パブリッシュ・セッションを実行中の宛先まで移動します。(宛先名が表示されない場合は、その宛先で実行されているセッションはありません。)

3. 宛先の「ステータス」列を確認して、次のいずれかを実行します。

- ステータスが「一時停止」の場合、パブリッシュの最初の3つのステージが完了していることを意味します。セッションを続行するには、「再開」ボタン(一時停止の間のみ使用可能)をクリックします。

- ステータスが「実行中」の場合、どのステージが処理中かを判別できます。「ステータスのパブリッシュ」フォームを開きます。

a. セッションが実行されている宛先を選択します。

b. 「ステータスのパブリッシュ」フォームで、プログレス・バーを確認し、2番目のステージが完了するまで待ちます。2番目のステージを完了できない場合、このセッションは再開できません。
ステータス・バーは、次のように対話型の操作が可能です。

ステージの進捗状況の割合を表示するには、そのステージのステータス・バーの上にカーソルを置きます。

このステータス・バーの上にカーソルを重ねると、現在処理されているアセット・タイプを示す別のツールチップが開きます。そのまま重ねていると、そのツールチップはリアルタイムで更新され、常にパブリッシュ・システムの最新のアクションを表示します。

(セッションの実行中に、そのログを表示することもできます。)

c. 2番目のステージが完了したら、「再開」ボタンをクリックします。
「再開」ボタンは、「開始」ボタンと「取消」ボタンの間にあります。

d. パブリッシュ・セッションが完了すると、5つのすべてのステージの「ステータス」列に「成功」と表示されます。

4. セッションが完了すると、「パブリッシュ・コンソール」の「履歴」タブで、その概要情報やすべてのログにアクセスできます。「履歴」タブにアクセスする手順は次のとおりです。

a. 「パブリッシュ・コンソール」に戻ります(ボタン・バーで「パブリッシュ」をクリックします)。

b. 「履歴」タブをクリックします。「履歴」タブのオプションの詳細は、スケジュール済パブリッシュ・セッションの使用を参照してください。

15.8.3 パブリッシュ・セッションの取消し

実行中のパブリッシュ・セッションは、パブリッシュの権限を持つ任意のユーザーによって取り消す(さらに再起動する)ことができます。セッションが取り消されると、セッション情報が「アクティブ」タブから「履歴」タブに移動します。ここでは、セッションを再起動できますが、取消しの前に最低でも2番目のパブリッシュ・ステージが正常に完了し、さらにこれが最後に取り消されたセッションの場合に限ります。

注意:

パブリッシュ・セッションは、「パブリッシュ・コンソール」か、「ステータスのパブリッシュ」フォームから取り消すことができます。このオプションの選択には注意が必要です。再実行するつもりのセッションの取消しが早すぎると、そのセッションを再実行できなくなります。これが不明確な場合は、少なくとも2番目のステージが完了していることを確認できる「ステータスのパブリッシュ」フォームでセッションを取り消してください。

パブリッシュ・セッションの取消しの詳細は、次のトピックを参照してください。

- 「パブリッシュ・コンソール」からのパブリッシュ・セッションの取消し

- 「ステータスのパブリッシュ」フォームからのパブリッシュ・セッションの取消し

15.8.3.1 「パブリッシュ・コンソール」からのパブリッシュ・セッションの取消し

1. 「パブリッシュ・コンソール」を開きます(管理者のインタフェースのボタン・バーにある「パブリッシュ」をクリックします)。

注意:

取り消すセッションが再起動されないことが明らかな場合にのみ、次の手順を使用してください。そうではなくセッションを再実行する予定の場合は、「ステータスのパブリッシュ」フォームでセッションを取り消してください。

「パブリッシュ・コンソール」が開き、「アクティブ」タブにアクティブなパブリッシュ・セッションが開きます。(「アクティブ」タブに何も表示されていない場合は、実行中のパブリッシュ・セッションはありません。)

2. 「アクティブ」タブ内で、セッションが実行中の宛先に移動し、そのセッションの「取消」ボタンをクリックします。

取消しリクエストが送信されたというメッセージが、アクティブなパブリッシュ・セッションのリストの上に開きます。WebCenter Sitesは、安定した停止点を探します。セッションの取消しには数秒かかる場合があります。続いて、セッション情報が「アクティブ」タブから「履歴」タブに移動します。

15.8.3.2 「ステータスのパブリッシュ」フォームからのパブリッシュ・セッションの取消し

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

「パブリッシュ・コンソール」が開き、「アクティブ」タブにアクティブなパブリッシュ・セッションが開きます。「アクティブ」タブに何も表示されていない場合は、現在実行中のパブリッシュ・セッションはありません。

注意:

取り消すセッションを再実行する予定の場合は、次の手順を使用する必要があります。「ステータスのパブリッシュ」フォームでは、パブリッシュ・プロセスを監視して、少なくとも2番目のステージ(データ収集とシリアライズ)の実行を完了させることができます。このステージの前に取り消すと、セッションの再実行は無効になります。

これらの条件が満たされると、セッションを再実行するオプションを使用できます。

- パブリッシュの最初の2つのステージが正常に完了している。

- 最後に取り消されたパブリッシュ・セッションである。

2. 「アクティブ」タブ内で、パブリッシュ・セッションが実行中の宛先を選択します。

3. 「ステータスのパブリッシュ」フォームで、セッションの進行状況を確認し、少なくとも2番目のステージが完了するまで待ちます。

4. 2番目(以降)のステージが完了したら、「取消」ボタンをクリックします。

図15-8 「ステータスのパブリッシュ」フォーム

取消しリクエストが送信されたというメッセージが、ステータス列の上に開きます。WebCenter Sitesは、安定した停止点を探します。セッションが取り消されるまで数秒かかる場合があります。続いて、セッション情報が「アクティブ」タブから「履歴」タブに移動します。

5. セッションを再実行する準備ができたら、「履歴」タブを選択し、そのセッションに移動して、「再実行」ボタンをクリックします。詳細は、パブリッシュ・セッションの再実行を参照してください。

15.9 スケジュール済パブリッシュ・セッションの使用

宛先が、スケジュール済パブリッシュに対して構成されている場合は、そのスケジュールが「パブリッシュ・コンソール」の「スケジュール」タブに表示されます。パブリッシュ・スケジュールを構成する手順は、パブリッシュ・イベントのスケジュールを参照してください。

「スケジュール済」タブは、次の操作に使用します。

- 宛先のパブリッシュ・スケジュールの表示

- パブリッシュ・スケジュールの編集

すべての構成済宛先のパブリッシュ・スケジュールを表示または編集するには::

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

2. 「スケジュール済」タブをクリックします。

「スケジュール済」タブには、パブリッシュ・スケジュールが設定されている宛先のみが表示されます。

注意:

パブリッシュ・スケジュールは、SystemEvents表で使用される、文字列形式で表現されます。

時:分:秒 曜日/日/月

構文の詳細は、スケジュールの略称の読取りを参照してください。

3. パブリッシュ・スケジュールをよりわかりやすい形式で表示するには、スケジュールの上にカーソルを置きます。

4. スケジュールを編集するには、宛先名をクリックして、パブリッシュの条件を指定します。(スケジュールを無効にすることもできます。)

15.10 以前のパブリッシュ・セッションの使用

「パブリッシュ・コンソール」の「履歴」タブでは、概要情報と以前に実行されたパブリッシュ・セッションごとの詳細なログが表示されます。以前のセッションには、完了したセッション、取り消されたセッション、失敗したセッションなどがありますが、一時停止している遅延パブリッシュ・セッションはこれに含まれません。

注意:

遅延パブリッシュ・セッションは、一時停止しているときも、「アクティブ」タブのリストには引き続き表示されます。これは、アクティブ・セッションと見なされます。

「履歴」タブは対話的です。各宛先にカーソルを重ねると宛先の概要情報をポップアップ・ウィンドウに表示でき、宛先を選択するとセッション・ログを取得できます。次の基準で宛先のリストをソートすると、すぐに情報を見つけることができます: 宛先、パブリッシュ終了時刻、ステータスおよびパブリッシュしたユーザー。

「履歴」タブでは、次の操作が可能です。

- 以前のパブリッシュ・セッションについての概要情報を表示する。以前のパブリッシュ・セッションの表示を参照してください。

- 完了したセッションの最終的な「ステータスのパブリッシュ」フォームにアクセスする。以前のパブリッシュ・セッションの表示を参照してください。

- 取り消されたセッションを再実行する。パブリッシュ・セッションの再実行を参照してください。

- セッション・ログへのアクセス

- 履歴リスト全体の消去または選択したセッションの削除

15.10.1 以前のパブリッシュ・セッションの表示

AdminまたはContributorインタフェースの両方から起動された、以前のパブリッシュ・セッションは、履歴に格納されています。履歴にアクセスすると、各パブリッシュ・セッションのログが表示されます。履歴はクリアできます。

以前のパブリッシュ・セッションを表示するには::

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

2. 「履歴」タブをクリックします。

3. セッションのサマリー情報を表示するには、セッションが実行された宛先の上にカーソルを置きます。(「宛先」列はタイトルをクリックすることでソートできます。)
図15-9に示すように、ポップアップ・ウィンドウに概要情報が表示されます。

ポップアップ・ウィンドウには、セッションの開始および終了の日時、アセットのパブリッシュにかかった時間およびパブリッシュしたアセットの数が表示されます。

図15-9 「パブリッシュ・コンソール」フォームの「履歴」タブに表示されるコンテキスト・ウィンドウ

4. セッション・ログを表示およびダウンロードする手順は次のとおりです。

a. セッションが実行された宛先を選択します。

b. 「ステータスのパブリッシュ」フォームで、「ログの表示」をクリックします。
ログ・エントリが200文字を超える場合は、「すべて表示」リンクをクリックして、エントリ全体を表示します。また、特定のエントリのログを検索することもできます。

c. ログをダウンロードするには、「ログのダウンロード」リンクをクリックします。

15.10.2 パブリッシュ・セッションの再実行

セッションが停止した場合(システム・エラーまたはユーザーによる取消しのため)、セッションを再実行、つまりセッションを再び開始することができます。セッションが開始されると、最後に正常に完了したステージからパブリッシュ・プロセスが続行されます。次の条件をすべて満たしている場合には、セッションの再実行のオプションを利用できます。

- パブリッシュするデータが、正常に収集されシリアライズされている(つまり、パブリッシュの最初の2つのステージを正常に完了している)。

- 最後に失敗したか、取り消されたパブリッシュ・セッションである。

「再実行」オプションは、電源障害などの中断によりパブリッシュが妨げられた場合に役立ちます。

パブリッシュ・セッションを再実行するには::

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

2. 「履歴」タブをクリックして、以前のパブリッシュ・セッションを表示します。
以前のパブリッシュ・セッションのリストが表示されます。「再実行」ボタンは、再実行可能なセッションの場合のみアクティブになります(右側の列)。

「再実行」ボタンが無効な場合、このパブリッシュ・セッションは再実行できるようになるまで処理が進められていなかったか、最後に取り消された(または失敗した)セッションではありません。図15-10で、最初の宛先の詳細が記述された行の末尾に「再実行」ボタンが表示されています。「再実行」ボタンをクリックすると、ターゲットにデータを送信するところから、パブリッシュ・セッションが開始されます。

図15-10 「再実行」ボタンが表示されている履歴タブ

3. 次のいずれかを実行します。

- 「再実行」ボタンをクリックしてパブリッシュ・セッションを再起動します。

- 「ステータスのパブリッシュ」フォームからセッションを再実行します。

a. 再実行するセッションの宛先のリンクをクリックします。
セッションの最終的な「ステータスのパブリッシュ」フォームが開きます。

b. 「再実行」ボタンをクリックしてパブリッシュ・セッションを再起動します。

「再起動リクエストが送信されました。」のメッセージが開き、このセッションが「履歴」タブから「アクティブ」タブに移動されます。「アクティブ」タブの端で円を描く緑色の矢印は、パブリッシュ・セッションがアクティブであることを示します。

4. セッションの完了を監視するには、「アクティブ」タブをクリックし、次に宛先名をクリックします。(詳細は、アクティブなパブリッシュ・セッションの使用を参照してください。)

15.11 パブリッシュ・ログの使用

次の各トピックでは、パブリッシュ・ログの表示、ダウンロードおよび削除に関する情報と手順を説明します。

- ログの表示と検索

- ログのダウンロード

- パブリッシュ履歴の削除

15.11.1 ログの表示と検索

リアルタイム・パブリッシュ・ログには、パブリッシュ・セッションで実行されるトランザクションの詳細な情報が保存されます。アクティブなパブリッシュ・セッションと以前のパブリッシュ・セッションに関するログを表示できます。また、ログは、セッションの実行時や終了後に、いつでもダウンロードできます。

注意:

WebCenter Sitesでは、詳細なログ・ファイルを生成するように構成でき、通常のログ・ファイルよりも詳細な情報を含めることができます。詳細化によりパブリッシュ・プロセスが長くなるため、このオプションは必要な場合にのみ使用する必要があります(通常はトラブルシューティングの場合)。

WebCenter Sitesは、パブリッシュ・セッションの完了時にテキスト書式のログ・ファイルを自動的にメール送信するように構成することもできます。

ログ・ファイルを構成し、電子メール・オプションを指定するには、ソース・システムでのリアルタイム宛先定義の作成を参照してください。

パブリッシュ・ログを表示するには::

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。
「アクティブ」タブが開いた状態で「パブリッシュ・コンソール」が開き、現在実行されているすべてのリアルタイム・セッションが表示されます。

2. 現在のセッションのログを表示するには、「アクティブ」タブ内で、目的のセッションに移動し、「ログの表示」をクリックします。以前のセッションのログを表示するには、「履歴」タブをクリックし、目的のセッションに移動して、「ログの表示」をクリックします。

- 「パブリッシュ・セッション・ログ」フォームが開きます。セッションの継続とともにページが追加されます。

- ログ・エントリが200文字を超える場合、省略記号(3つのピリオド)が末尾に表示されます。エントリ全体を表示するには、エントリの上にマウス・カーソルを置きます。ログ・ファイルの上に開かれるウィンドウに、エントリ全体が表示されます。ログ・イベントの原因が特定されます。

図15-11 ポップオーバー・ウィンドウに表示されるログ・イベント情報

3. ログファイルは様々な方法で検索できます。

- 特定のエントリを検索するには、「検索」フィールド(フォームの右上)に検索語句を入力します。

注意:

検索ユーティリティによって、「ステージ」、「ステータス」および「詳細」列で使用されている語句が認識されます。ワイルドカードやブール演算子は認識されません。

- エラー・メッセージのみを表示するには、「エラーのみ表示」チェック・ボックスを選択し、「検索」フィールドは空のままにします。

- 特定の語句でエラー・メッセージをフィルタするには、「エラーのみ表示」チェック・ボックスを選択し、「検索」フィールドに検索語句を入力します。

a. 「検索」をクリックします。
「検索結果」タブが開きます(「セッション・ログ」タブの横)。

図15-12 「パブリッシュ・セッション・ログ」フォームの「検索結果」タブ

b. 「検索結果」タブを終了するには、タブ上の「X」をクリックします。
「セッション・ログ」タブに戻ります。

15.11.2 ログのダウンロード

パブリッシュ・ログは、セッション中やセッションの終了時にいつでもダウンロードできます。次の手順に示すとおり、ログ・ファイルは、リアルタイム・パブリッシュ・インタフェースのいくつかの場所からダウンロードできます。

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

「アクティブ」タブが表示された状態で、「パブリッシュ・コンソール」が開かれます。「アクティブ」タブには、現在処理中のパブリッシュ・セッションが表示されます。

2. アクティブなセッションまたは以前のセッションのログ・ファイルをダウンロードします。

- 「アクティブ」タブ: 宛先名を選択し、「ログのダウンロード」をクリックします。

- 「履歴」タブ: 宛先名を選択し、「ログの表示」をクリックして、「ログのダウンロード」を選択します。
「ステータスのパブリッシュ」フォームが開きます。

3. セッションが完了したら、「ログのダウンロード」をクリックし、表示される指示に従います。

ログ・ファイルは、テキスト書式であり、任意のテキスト・エディタで開くことができます。

15.11.3 パブリッシュ履歴の削除

操作およびパフォーマンスを適切に保つため、パブリッシュ履歴は定期的に削除することをお薦めします。これはパブリッシュに関連したすべてのデータがデータベースに格納され、その表のサイズが時間経過とともにパフォーマンス上の問題になる可能性があるためです。定期的にパブリッシュしてもこの表のサイズが大幅に増大することはありませんが、大規模なパブリッシュ(サイトの初期パブリッシュなど。特に失敗した場合)では、大量のデータが残されることがあります。

パブリッシュ・セッションの削除では、次の処理が実行されます。

- データベース表からのセッションに関連するすべてのメッセージが削除されます。

- このシステムのFW_PUBDATASTOREから、セッションに関連するすべてのデータが消去されます(パブリッシュに失敗した場合、しばしばこの表にデータが残されます)。

- 宛先へのアクセスを試行し、関連するデータをFW_PUBDATASTOREから消去します(パブリッシュに失敗した場合、しばしばこの表にデータが残されます)。

セッション・ログを削除するには::

1. 「パブリッシュ・コンソール」を開きます(Adminインタフェースのメニュー・バーにある「パブリッシュ」をクリックします)。

「アクティブ」タブが表示された状態で、「パブリッシュ・コンソール」が開かれます。

2. 「履歴」タブを選択します。

すべての使用可能なログが表示されます。

図15-13 「パブリッシュ・コンソール」フォームの「履歴」タブ

3. 削除する各ログの横にあるボックスを選択します。

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

選択したログが削除されます。

注意:

FW_PUBDATASTORE内にあるデータは、バイナリ・ラージ・オブジェクトを使用して保存されるため、この処理の実行後、DBAによって手動でバイナリ・ラージ・データをクリーンアップすることが必要になる場合があります。

16 パブリッシュ・イベントのスケジュール

すべてのパブリッシュの宛先について、パブリッシュ・イベントを設定できます。パブリッシュ・イベントはバックグラウンド・プロセスとして実行され、パブリッシュ・キューは存在しないので、必要であれば、複数の宛先に対して同時に実行されるパブリッシュ・イベントを設定できます。

- パブリッシュ・イベントのスケジュール

- スケジュールの略称の読取り

- パブリッシュ・イベントの編集

- スケジュールのオーバーライド

- 承認テンプレートまたはプレビュー・テンプレートの割当て

- 「パブリッシュ・コンソール」でのセッションの監視

- パブリッシュの準備状況の検証

- パブリッシュ履歴について

- セッション履歴について

- すべての承認済アセットのパブリッシュについて

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

16.1 パブリッシュ・イベントのスケジュール

パブリッシュ・イベントをスケジュールする場合、次の2つのことを知っておく必要があります。

- 宛先ごとにパブリッシュ・イベント・スケジュールを1つのみ設定できます。

- ソースと宛先の両方として機能するシステムが存在する場合、受信パブリッシュ・セッションと送信パブリッシュ・セッションが重ならないようにします。たとえば、開発システムから管理システムにパブリッシュし、管理システムから配信システムにパブリッシュするとします。この場合、管理システムから配信システムにパブリッシュしている間に、開発システムから管理システムへのパブリッシュ・イベントはスケジュールできません。

パブリッシュ・イベントをスケジュールするには::

1. 「一般的な管理」ツリーで、「管理」、「パブリッシュ」および「宛先」を開きます。

2. パブリッシュ・イベントをスケジュールする宛先をダブルクリックします。

3. 「パブリッシュの宛先」フォームで、「パブリッシュ・イベントの設定」ボタンをクリックします。
パブリッシュ・イベントの編集フォームが開きます。

ここで日、月、時および分を選択してスケジュールを設定します。

パブリッシュ・イベントを設定するためのフォームは、ワークフローの時間指定アクション・イベントを設定するフォームに似ています。詳細は、時間指定アクション・イベントの設定を参照してください。

スケジュールの例:

たとえば、日曜日を除くすべての曜日の午前7時、午後4時および午後8時に、WebCenter Sitesによりこの宛先の承認済のアセットがパブリッシュされるようにスケジュールを設定するには、次の手順を実行します。

1. 「繰返しパターン」の「曜日」タブで、「月曜日」をクリックして「土曜日」までドラッグし、日曜日を除くすべての曜日を選択します。選択された曜日はグレーでハイライトされます。

図16-1 「曜日」タブ

2. 曜日を選択済なので、「月の日付」タブでは何もしません。

3. 「月」タブで、「すべて」をクリックし、すべての月を選択します。すべての月がグレーでハイライトされます。

図16-2 「月」タブ

4. 「繰返しの回数」セクションの「時間」セレクタで、「AM」の「7」および「PM」の「4」と「8」を選択します。

5. 「分」セレクタで「0」をクリックします。

図16-3 「時間」と「分」のセクション

6. フォームの「有効な日時」セクションで、選択した日時を確認します。

図16-4のサンプルのようになります。

図16-4 スケジュールの詳細

7. 「有効な日時」セクションの「有効」をクリックします。

8. 「保存」ボタンをクリックします。

「パブリッシュの宛先」フォームの「パブリッシュ・イベント」セクションに、スケジュールの概要が開きます。

16.2 スケジュールの略称の読取り

作成されたスケジュール済イベントは、WebCenter Sitesインタフェースに文字列形式で表示されます。

パブリッシュ・イベントの編集フォームでは、ページの一番上の「有効な日時」セクションに、読みやすい形式でスケジュールが開きます。「パブリッシュの宛先」フォームでは、「パブリッシュ・イベント」フィールドに文字列としてスケジュールが開きます。

スケジュール文字列のキーを次に示します。

時:分:秒 曜日/日/月

次のように情報が開きます。

- 時間は、0 (午前0時)から23 (午後11時)までの数値として表示され、分との間はコロンで区切られます。
複数の時間が選択されている場合、選択されている時間はカンマで区切られて表示されます。

サンプル・スケジュール(パブリッシュ・イベントのスケジュール内)に、パブリッシュする時刻として、午前7時、午後4時および午後8時が設定されています。これは、7,16,20:と表示されます。

- 分は5分刻みで設定できるので、0から55までの5分刻みの数値として表示されます。秒との間はコロンで区切られます。
スケジュールで複数の分が選択されている場合、選択されている分はカンマで区切られて表示されます。

分が0と表示されている場合、正時にイベントが実行されることを意味します。

例の時間と分は、7,16,20:0:のように表示されます。

- 秒は常に0に設定されます。したがって、例の時間表示を完全に示すと、7,16,20:0:0となります。

- 時間と日は空白で区切られます。

- 曜日は、0 (日曜日)から6 (土曜日)までの数値として表現され、最後にスラッシュ(/)文字が付きます。

- 1つも曜日が選択されていない場合またはすべての曜日が選択されている場合、パブリッシュ・イベントはすべての曜日に実行されます。その場合、フィールドにはアスタリスク(*)文字が表示されます。

- 複数の曜日がスケジュールされている場合、選択されている曜日はカンマで区切られて表示されます。

例のスケジュールでは、日曜日を除くすべての曜日が選択されています。したがって、曜日が追加されて、7,16,20:0:0 1,2,3,4,5,6/のように表示されます。

- 日付も、数値(1から31まで)として表示され、最後にスラッシュ(/)文字が付きます。

- 日付のリストは、カンマで区切られます。

- 日付が1つも選択されていない場合、パブリッシュ・イベントはその月のすべての日に実行されます。その場合、フィールドにはアスタリスク(*)文字が表示されます。

- 曜日と日付の両方を指定した場合、その日がどちらかの設定と一致した場合にイベントが実行されます。

例のスケジュールでは、日付は指定されていません。したがって、このアイテムの値がアスタリスクとして追加されて、7,16,20:0:0 1,2,3,4,5,6/*/のように表示されます。

- 文字列の最後には、月が1 (1月)から12 (12月)までの数値として表示されます。

- 月のリストは、カンマで区切られます。

- すべての月が選択されている場合は、毎月パブリッシュ・イベントが実行されます。その場合、フィールドにはアスタリスク(*)文字が表示されます。

例のスケジュールでは、すべての月を指定しました。したがって、最終的な文字列は次のようになります。

7,16,20:0:0 1,2,3,4,5,6/*/*

16.3 パブリッシュ・イベントの編集

パブリッシュ・スケジュールは、必要に応じて編集できます。これは、新しいスケジュールを取り入れるのでなく、スケジュールを修正するため、スケジュールの数を抑制する助けになります。パブリッシュ・イベントを編集するには::

1. 「一般的な管理」ツリーで、「管理」、「パブリッシュ」および「宛先」を開きます。

2. パブリッシュ・イベントをスケジュールする宛先をダブルクリックします。

3. 「パブリッシュの宛先」フォームで、「パブリッシュ・イベントの設定」をクリックします。

「パブリッシュ・イベント」フォームが表示されます。フォームの一番上に、イベントの現在の構成内容を示すテキストが表示されます。

4. 必要に応じてイベントを編集し、「スケジュール」をクリックします。選択を消去するには、「取消」をクリックします。

16.4 スケジュールのオーバーライド

すぐにサイトをパブリッシュする必要がある場合、スケジュールのオーバーライドが使用されます。すぐにパブリッシュ・セッションを開始するには:

1. Adminインタフェースで、ツールバーの「パブリッシュ」ボタンをクリックします。

2. 「パブリッシュ・コンソール」で、リストから、パブリッシュする宛先を選択します。

3. 「宛先の選択」ボタンをクリックします。

WebCenter Sitesによって、選択した宛先にパブリッシュ可能なアセットが存在するかどうかが判断され、概要フォームが表示されます。

選択した宛先にパブリッシュ可能なアセットが存在する場合、「パブリッシュ」ボタンが開きます。パブリッシュするアセットが存在しない場合、「パブリッシュ」ボタンは表示されません。

4. 「パブリッシュ」をクリックします。

WebCenter Sitesによって、パブリッシュ・セッションが開始されます。

注意:

この宛先のパブリッシュ・セッションが実行されている場合、実行しようとしたパブリッシュ・イベントは失敗し、WebCenter Sitesに、同じ宛先の別のセッションが実行中であることを示すステータス・メッセージが表示されます。それでも、このイベントを実行する必要がある場合は、現在のセッションが完了するまで待機して、前述の手順を繰り返します。

16.5 承認テンプレートまたはプレビュー・テンプレートの割当て

ディスクへのエクスポートのパブリッシュの宛先に対してアセットが承認されると、その依存性を判断するために、承認システムによりアセットに割り当てられているテンプレートが調査されます。

ただし、アセットがパブリッシュされる際、必ずしもアセットに割り当てられているテンプレートが使用されるわけではありません。なぜなら、別のエレメントのコードによって、特定のケースではそのアセットに別のテンプレートが使用されていると判断される可能性があるからです。

サンプル・サイトについて考えます。このサンプル・サイトの記事のアセットは、コンテキストに応じて、様々なテンプレートでレンダリングできます。

このため、ユーザーがサイトの記事アセットを承認する場合、すべてのテンプレートに対する依存性の最も代表的な組合せを含むテンプレートを使用して、記事の依存性を決定する必要があります。依存性の最も代表的な組合せが含まれるテンプレートが、アセットに割り当てるテンプレートと異なる場合は、それをそのタイプのアセットのデフォルト承認テンプレートに設定する必要があります。

ミラーリング先にパブリッシュされるアセットにデフォルト・テンプレートを割り当てた場合、そのテンプレートは、依存性の計算では使用されませんが、「ステータス」フォームからアセットをプレビューする際は使用されます。

デフォルト・テンプレートを設定するには::

1. 「一般的な管理」ツリーで、「管理」、「パブリッシュ」および「宛先」を開きます。

2. デフォルト・テンプレートを構成する宛先を開き、「デフォルト・テンプレートの設定」アイテムを選択します。
「デフォルトのテンプレート」フォームが表示されます。

3. 「デフォルト・テンプレート」フォームで、「構成の編集」をクリックします。

図16-5のものに類似したフォームが表示されます。

図16-5 「デフォルト・テンプレート」フォーム

4. 構成する必要があるアセット・タイプごとに、そのタイプのアセットの承認テンプレートまたはプレビュー・テンプレートとしてWebCenter Sitesによって使用されるテンプレートおよびラッパー・ページを選択します。アセット・タイプにサブタイプが構成されている場合、そのアセット・タイプのサブタイプごとにデフォルト・テンプレートを指定できます。

5. 「保存」ボタンをクリックします。

その宛先の「デフォルト・テンプレート」フォームに戻ります。

16.6 「パブリッシュ・コンソール」でのセッションの監視

「パブリッシュ・コンソール」を使用して、パブリッシュ・セッションを監視します。「パブリッシュ・コンソール」を開くには、WebCenter Sitesインタフェースの一番上にある「パブリッシュ」ボタンをクリックします。「パブリッシュ・コンソール」フォームが開きます(図16-6)。

コンソールに、現在実行中、スケジュール済または完了済のセッションを含むすべてのパブリッシュ・アクティビティのサマリーが表示されます。

図16-6 「パブリッシュ・コンソール」フォーム

16.7 パブリッシュの準備状況の検証

パブリッシュ・セッションの準備が整っているか、または承認されていないアセットに問題がないかを判断するには::

1. 「パブリッシュ・コンソール」で、リストから宛先を選択します。

2. 「宛先の選択」ボタンをクリックします。

概要フォームが開きます。ここには、パブリッシュする必要があるけれどもまだ準備が整っていない(保留されている)アセットおよびパブリッシュ可能なアセットがリストされます。

3. パブリッシュが保留されているアセットの数またはパブリッシュの準備ができたアセットの数に対応するリンクをクリックすると、詳細が表示されます。

承認済アセットまたは承認済だが依存性を理由に保留されているアセットのリストが表示されます。一方のタブは承認済アセットのリスト、もう一方のタブはオンデマンド・キューに存在するアセットです。

問題を解決する必要がある場合、アセットへのリンクをクリックし、必要な変更を(おそらく承認も)行います。

- オンデマンド・キューにアセットを配置するには、アセットを選択し、「オンデマンド・キューへ追加」をクリックします。オンデマンド・キューから(「オンデマンド・キュー」タブから)アセットを除去するには、アセットを選択し、「オンデマンド・キューから除去」をクリックします。

- オンデマンド・キューのアセットをパブリッシュするには、どちらかのタブで「オンデマンド・キューのパブリッシュ」をクリックします。

- アセットが保留されている理由の詳細は、表17-4を参照してください。

- アセットを使用する手順は、『Oracle WebCenter Sitesの使用』を参照してください。

16.8 パブリッシュ履歴について

完了済のパブリッシュ・セッションは、「パブリッシュ」ボタンをクリックすると開く「パブリッシュ・コンソール」の、「パブリッシュ履歴」セクションにリストされます。リストの各パブリッシュ・セッションは、実行中、完了、失敗のいずれかのステータスを持っています。

リストの各アイテムには、次の2つのアイコンが表示されます。

- セッションの概要を表示する調査アイコン(丸で囲まれた文字「i」)。概要の調査が、失敗したセッションのトラブルシューティングの最初の手順です。

- セッションを削除する削除アイコン(ゴミ箱)。このアイコンをクリックすると、WebCenter Sitesによって、PubSession表の該当する行、セッションのパブリッシュ・ログ・ファイル、およびPubMessage表のこのセッションに関するメッセージが削除されます。

このセクションにリストされるパブリッシュ・セッションの数が増えるほど、WebCenter Sitesで「パブリッシュ・コンソール」を開く際にかかる時間が長くなります。

セッションのステータスが「失敗」と表示されたら、調査アイコンをクリックし、エラー・メッセージをメモして、トラブルシューティングを参照します。

16.9 セッション履歴について

パブリッシュ履歴ログ・ファイルは、「パブリッシュ・コンソール」の「履歴」タブに、パブリッシュ・セッションの概要として表示されます。

履歴ファイルのテキストは、そのセッション中にパブリッシュされたすべての参照のリストです。参照という用語の意味は、パブリッシュ方法ごとに多少異なります。

- サーバーへのミラーリングのパブリッシュの場合、参照はアセットです。パブリッシュされた各アセットは、そのアセット・タイプとIDでリストされます。

- ディスクへのエクスポートのパブリッシュおよびXMLへのアセットのエクスポートの場合、参照は生成されたファイルです。作成された各ファイルは、そのファイル名でリストされます。

パブリッシュ履歴ログを表示するには、「履歴」タブで特定のセッションを選択し、そのセッションの「ステータスのパブリッシュ」フォームを表示します。

図16-7 「ステータスのパブリッシュ」フォーム

「ログの表示」をクリックすると、履歴ログが表示されます。「ログのダウンロード」をクリックして、ログのダウンロードと表示を個別に行うこともできます。

セッションに問題があった場合、エラー・メッセージがPubMessage表に書き込まれ、履歴として開きます。パブリッシュ・セッションの履歴でエラー・メッセージを見つけた場合は、トラブルシューティングを参照して、問題の解決を試みてください。

16.10 すべての承認済アセットのパブリッシュについて

パブリッシュ・システムは、増分パブリッシュ・セッションを実施します。すなわち、セッション中にパブリッシュされるのは、同じ宛先に対する前回のセッションの後に承認されたアセットのみです。

ただし、サイト全体のすべての承認済アセットをパブリッシュする必要がある状況が生じる可能性があります。(たとえば、配信システムでデータが修復された後。)その場合は、「宛先の編集」フォームで、「次回すべてのアイテムを強制パブリッシュ」ボタンを使用します。

このボタンをクリックすることは、すべての承認済アセットのステータスを未パブリッシュに変更することと同じです。これは、同じ宛先への次回のパブリッシュ・セッションでは、パブリッシュされていてその後変更されていないかどうかに関係なく、すべての承認済アセットがパブリッシュされることを意味します。

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

この項では、構成、システムまたはデータのエラーを示すエラー・メッセージまたは他のシステム・インジケータについて説明し、それぞれの修正措置を提示します。次の項目が含まれます。

- パブリッシュ・システムのエラー・メッセージの理解

- 数値メッセージの理解

- 他のシステムまたは構成上の問題点の兆候

16.11.1 パブリッシュ・システムのエラー・メッセージの理解

パブリッシュ・システムは、次の方法でパブリッシュ・セッションに関する情報を報告します。

- 「パブリッシュ・コンソール」の「パブリッシュ履歴」リストに、セッションごとのステータスを表示します。ステータスとして「失敗」、「見つかりません」または「false」が表示されている場合、パブリッシュ・セッションで問題が発生したことを示します。

- パブリッシュされたアセットに関する情報を、そのパブリッシュ・セッションのログ・ファイルに書き込みます。「パブリッシュ・コンソール」でパブリッシュ・セッションの調査アイコンをクリックすると、そのセッションの履歴ログ・ファイルが開きます。
パブリッシュ履歴ログ・ファイルの配置場所は、wcs_properties.jsonファイルのrequest.folderプロパティ(「パブリッシュ」カテゴリ)で定義されます。各ログ・ファイルの名前は、次のように決まります。

PubSession ID + Output.html

たとえば、注目するセッションのPubSession IDが9876544である場合、ログ・ファイルは9876544Output.htmlという名前となり、request.folderプロパティで指定されているディレクトリに配置されています。

- パブリッシュ・セッションに関するエラー・メッセージをPubMessage表に書き込みます。書き込まれたメッセージは、「パブリッシュ・コンソール」で特定のパブリッシュ・セッションのパブリッシュ履歴を調査したときに、「メッセージ」テキスト領域に表示されます。
PubSession IDを使用して、PubMessage表で特定のパブリッシュ・セッションに関するメッセージを検索できます。宛先構成でVerboseパラメータを選択した場合、ステータス・メッセージはPubMessage表にも書き込まれます。

- セッションに関する他の情報をPubSession表に書き込みます。たとえば、パブリッシュ・セッションの開始時刻を知るには、そのPubSession IDを使用してPubSession表でセッションを検索します。

- ソースと宛先(ターゲット)システムの両方で、futuretense.txtファイルにエラー・メッセージを書き込みます。

失敗したパブリッシュ・セッションに関するエラー・メッセージは、次の場所でも見つけることができます。

- ソースと宛先システムの両方のアプリケーション・サーバー・ログ・ファイル。

- ソースと宛先システムの両方のstdoutログとstderrログ。

16.11.2 数値メッセージの理解

表16-1では、パブリッシュ・システムが前述のリストで説明したいずれかのログ・ファイルに報告する可能性のある数値エラー・メッセージについて説明し、修正措置を提示します。

注意:

表のリストには、WebCenter Sitesシステムが報告する可能性のあるすべてのエラー・メッセージが網羅されているわけではありません。すべてのエラー・メッセージの完全なリストは、Oracle WebCenter Sitesタグ・リファレンスの、エラー条件に関する章を参照してください。

表16-1 数値エラー・メッセージ

エラー番号

説明

修正処理

-2

このエラーは、ミラー・ユーザーの名前またはパスワードが正しく識別されないことを示します。ソースのパブリッシュ・システムはパブリッシュ・プロセスを開始しましたが、宛先システムはミラー・ユーザーとして指定されているユーザーを認証できませんでした。

ミラー・ユーザー情報を修正します。ヘルプは、ソース・システムでのミラー・ユーザーの識別の手順を参照してください。

-3

このエラーは、宛先システムでWebCenter Sitesデータベースにアセットを保存するための適切な権限をミラー・ユーザーが持っていないことを示します。つまり、ソースでミラー・ユーザーとして識別されている宛先システム・ユーザーは、必要なACLをすべて持っているわけではありません。

ミラー・ユーザーのアカウントを編集し、適切なACLを割り当てます。

ミラー・ユーザーに必要なACLのリストは、宛先システムの設定を参照してください。

それでもミラー・ユーザーのアカウントからどのACLが欠落しているか決定できない場合、宛先システムのfuturetense.txtファイルを調べます。ミラー・プロセスがどの表の更新に失敗したかを説明するエントリがあるはずで、表の名前が、どのACLが欠落しているかを決定する助けになる場合があります。

たとえば、ミラー・セッションが訪問者表で失敗している場合、ミラー・ユーザーに割り当てられていないのは、おそらくVisitor ACLまたはVisitorAdmin ACLです。

-103

このエラーは、ミラー・パブリッシュされるデータを持つ表が、宛先システムに存在しないことを示します。このエラーは通常、ソース上に、宛先にまだ存在しないアセット・タイプがある場合に発生します。サイトに対してカスタム・デザインされた機能をサポートするためにカスタム表を作成したが、宛先システム上ではその表がまだ作成されていないことはありえます。

宛先システムのsites.logファイルを調査して、-103エラーがリストされている行を探します。メッセージ内のテキストに、欠落している表が示されています。

適切なツールを使用して、欠落している表を宛先システムで作成します。ベーシック・アセット・タイプの場合はAssetMakerを使用します。フレックス・アセット・タイプの場合はフレックス・ファミリ・メーカーを使用します。それがカスタム表の場合は、Oracle WebCenter Sites Explorerを使用します。

-611

このエラー・メッセージは、一般的なミラー・パブリッシュ・エラー・メッセージです(もう1つは-12011)。通常は、-611は、パブリッシュ・システムが宛先システムにアクセスを試みたときに問題が発生したことを意味しており、他のエラー・メッセージも報告されているはずです。

宛先システムでsites.logファイルとアプリケーション・サーバー・ログを調査して、他のメッセージを探します。

-612

このエラー・メッセージは、ミラーリング先の定義のどこかが正しくないことを示します。おそらく、宛先アドレスの構文が正しくないか、またはなんらかの誤字があります。

ソースでWebCenter Sitesインタフェースにログインし、宛先の定義を調査して、正しいかどうかを判断します。詳細は、ミラーリング先の作成を参照してください。

-12011

このエラー・メッセージは、(-611と並んで)ミラー・プロセスが失敗したことを意味する一般的なメッセージです。他のエラー・メッセージが報告されない場合にこのメッセージが表示される可能性は高くありません。通常は、他のエラーが不都合の詳細を説明します。

ソースでPubMessage表とsites.logファイルのメッセージを調査し、他のエラー・メッセージを探します。

-12044

このエラーは、セッションを開始するための宛先に連絡できなかったため、パブリッシュ・システムがパブリッシュ・セッションを開始できなかったことを示します。つまり、宛先から応答がありませんでした。宛先システムの一部がオフラインです。

まずWebサーバーとアプリケーション・サーバーが宛先システムで動作中であることを確認します。動作していない場合は、これを起動します。2つのシステムがネットワーク経由で相互接続可能であることを確認します(おそらくネットワークが、オフラインなどになっています)。

-12045

このエラーは、パブリッシュ・システムはセッションを開始できたが、その後どこかで失敗したことを示します。

宛先システムのsites.logファイルを調査して、ログでエラー・メッセージと例外メッセージを探します。

-12046

このエラーは、パブリッシュ・システムがセッションごとに作成される一時表のクリーンアップを開始したときに、パブリッシュ・セッションの片側で問題が発生したことを示します。クリーンアップ・プロセスが始まったときに、宛先との接続に失敗しました。つまり、パブリッシュ・プロセスが一時表のクリーンアップを試みたときに、ソース・システムが宛先から応答を得られませんでした。

宛先システムのWebサーバーとアプリケーション・サーバーが動作中かどうかを判断します。動作していない場合は、これを起動します。また、ネットワーク接続に問題がないか、チェックします。

-12047

このエラーは、パブリッシュ・システムはクリーンアップ・プロセスを開始できたが、その後処理中にどこかで失敗したことを示します。

宛先のsites.logファイルを調査して、問題を示すエラー例外メッセージと例外を探します。

-13054

このエラーは、コンプレックス・アセットおよびフレックス・アセットの場合のみ発生します。この場合、パブリッシュ・システムはコンプレックス・アセットまたはフレックス・アセットのパブリッシュを始めましたが、データは宛先に到達しませんでした。データそのものが破損していたか、HTTPリクエスト接続が失敗した可能性もあります。

ソース・システムでsites.logファイルをチェックします。データ自体に問題がある場合、問題の原因となったアセットの特定に役立つ可能性がある他のメッセージがこのログ・ファイルに存在します。ただし、宛先システムが応答する前にHTTPリクエストが破棄された場合、ログに他のメッセージは存在しません。

-13055

このエラーは、コンプレックス・アセットおよびフレックス・アセットの場合のみ発生します。この場合、フレックス・アセットまたはコンプレックス・アセットのデータは配信されましたが、宛先システムがそのWebCenter Sitesデータベースにアセットを保存できませんでした。

このメッセージは、データに問題があることを示します。たとえば、複数のソースから同じ宛先へのパブリッシュを試みている場合、このエラーの原因となるIDの競合およびデータ整合性に関する他の問題が発生している可能性があります。

宛先システムでsites.logファイルとアプリケーション・サーバー・ログ・ファイルを調査します。多くの場合、stderrログに、発生した問題を示すスタック・トレース・メッセージが存在します。

16.11.3 他のシステムまたは構成上の問題点の兆候

この項では、パブリッシュ・システムが構成エラーまたはシステムの問題を検出したときに、WebCenter Sitesシステムが示す可能性がある症状について説明します。

このリファレンスの内容は次のとおりです。

- パブリッシュ・セッションが終了せずに普通でないステータスが表示される

- システムが完全に停止する

- パブリッシュ・セッションの終了後にページがリフレッシュされない

- DB2システムを使用している場合にアソシエーションが存在するアセットをパブリッシュするとトラブルが発生する

パブリッシュ・セッションが終了せずに普通でないステータスが表示される

パブリッシュ・セッションが開始または終了できない場合、通常は、バッチ・ユーザーが正しく構成されていません。パブリッシュ・セッションの「ステータス」を調査します。「ステータス」が「見つかりません」または「false」である場合、バッチ・ホストが正しく構成されていないと考えられます。

ミラーリング先の初期化機能では、バッチ・ユーザーを使用しません。宛先を正しく初期化できたのにパブリッシュ・セッションでエラーが発生する場合、バッチ・ユーザーが正しく設定されていないと考えられます。

修正処理:

バッチ・ユーザー・アカウントの作成(存在しない場合)を参照し、バッチ・ユーザーを正しく構成していることを確認します。

- xcelerate.batchuserプロパティで指定されているバッチ・ユーザーには、適切な読取り/書込み権限が必要です。必要な権限は、前述の手順に記載されています。

- xcelerate.batchuserプロパティでバッチ・ユーザーの名前が正しいスペルで指定され、xcelerate.batchpassプロパティで正しいパスワードが指定されている必要があります。

- xcelerate.batchhostプロパティで正しいサーバーが指定されている必要があります。このプロパティで指定する必要があるのは、ソース・システムがホストされているアプリケーション・サーバーであり、宛先およびロード・バランサを使用している場合のロード・バランサがホストされているサーバーではありません。80以外のポート番号を使用している場合、ポート番号も指定する必要があります。たとえば、myserver:7001と指定します。
WebCenter Sites環境がクラスタ化されている場合、サポートされるバッチ・ホストは1つのみです。xcelerate.batchhostプロパティは、クラスタ・メンバーごとに専用ホストを指定するように設定する必要があります。

パブリッシュ履歴に「パブリッシュ・セッションの出力を取得できません」というメッセージが書き込まれている場合、サーバー名が正しくないと考えられます。

- バッチ・ホスト・サーバーのポート番号も正しく指定する必要があります。パブリッシュ履歴に「パブリッシュ・セッションの出力を取得できません」というメッセージが書き込まれている場合、ポート番号が正しくないか、またはポート番号が指定されていない場合はデフォルト・ポート(80)が正しくないと考えられます。

システムが完全に停止する

システムが単純に停止した場合、この動作は、パブリッシュ・システムが動作するための十分な空きディスク領域が存在していない可能性があることを示します。

修正処理:

stdoutファイルとstderrファイルをチェックします。Javaの書込みエラーが見つかった場合、ディスク領域が不足しています。

- ディスクへのエクスポートのパブリッシュおよびXMLへのアセットのエクスポートの場合、生成されるすべてのファイルを格納するための十分なディスク領域がファイル・システムに存在する必要があります。

- サーバーへのミラーリングのパブリッシュの場合、ミラーリングされるデータのサイズの4倍に等しい空き領域がソースおよび宛先システムの両方に存在する必要があり、存在しない場合はミラーリング操作が失敗します。

Java tempディレクトリに十分な容量が存在しない場合、パブリッシュ・プロセスも失敗します。

パブリッシュ・セッションの終了後にページがリフレッシュされない

Satellite Server (管理システムまたは開発システムに共存するSatelliteまたは配信システムのリモートSatellite Serverのどちらか)を使用している状況で、キャッシュされたページの再生成がパブリッシュ・セッションの終了後から行われていないことが判明した場合、Satellite Serverが正しく構成されていないと考えられます。

修正処理:

宛先システムのsites.logファイルを調査して、次のようなメッセージを探します。

- Satellite Serverの数はユーザー名とパスワードの数と一致する必要があります。
このメッセージは、wcs_properties.jsonファイルでcs.satellitehosts、cs.satelliteusersおよびcs.satellitepasswordの各プロパティに指定されている値がどこか間違っていることを示します。

- -100.FormPosterがURLのフラッシュに失敗しました。
このメッセージは、Satelliteサーブレットが動作していないか、または宛先システムが接続を試みているSatelliteサーブレットに接続できなかったことを示します。

プロパティ管理ツールでcs.Pastramiengineとsatellite.blob.cachecontrol.default propertiesを調べ、ユーザー名、パスワードおよびホスト名に設定されている値を書きとめます。続いて、cs.satellitehosts、cs.satelliteusersおよびcs.satellitepasswordの各プロパティに指定されている値を書きとめます。これらの値を、リモートのSatellite Server(クラスタ環境では<WCSites_Shared_Dir>配下、非クラスタ環境では<WCSites_Product_Home>配下にあります)のwcs_properties.jsonファイルでusername とpasswordプロパティに設定されている値と比較します。両者は一致する必要があります。

wcs_properties.jsonファイルでホスト名を指定する順序が、ユーザー名とパスワードを指定する順序と一致する必要があることを忘れないでください。

DB2システムを使用している場合にアソシエーションが存在するアセットをパブリッシュするとトラブルが発生する

アソシエーションが存在するアセットをパブリッシュする際に問題が発生することが判明したとき、DB2データベースを使用している場合は、LOCKLISTパラメータが正しく設定されていないと考えられます。

修正処理:

このプロパティは1000以上に設定することをお薦めします。アソシエーションが存在するアセットをパブリッシュできない場合は、この値を増やします。

第VI部 承認およびワークフローの管理

次の各トピックでは、承認およびワークフローの管理に関する情報を提供します。

- 承認システムの理解

- ワークフロー・プロセスの作成と管理

17 承認システムの理解

次の各トピックでは、WebCenter Sites承認システムの基本的な働きについて説明します。特定の操作を実行する手順は含みません。目的は、管理者が(特にディスクへのエクスポートのパブリッシュの場合に複雑で高度に対話的になる)承認システムの処理に関する基本的な理解を獲得するのを助けることです。

- 承認システムについて

- 依存性分析の理解

- パブリッシュの用語と定義の理解

- 依存性分析のルールの使用

- 承認依存性と親子関係の理解

- ディスクへのエクスポートのパブリッシュの使用

- サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの使用

- コンテンツのバージョンの一致の保証

- サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

- ディスクへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

- Exists/Exact依存性ルールの使用

- パブリッシュされたコンテンツの評価

- 承認システムの例

- 承認状態の使用: リファレンス

17.1 承認システムについて

パブリッシュ・セッションを開始するには、パブリッシュの宛先に対してアセットを承認する必要があります。これは、想像以上に複雑なタスクです。企業サイトでは膨大な数のアセットがホストされているので、依存性によって相互に関連付けられていて、パブリッシュするために一緒に承認する必要があるアセットをユーザーが追跡することは不可能です。非承認アセットが存在すると、アセット間のリンクが機能しなくなるため、承認アセットの整合性が失われる恐れがあります。そこで、この部分を承認システムで処理します。

承認システムの最終目的は、パブリッシュされたコンテンツの整合性を保護することです。承認システムはユーザー承認済アセットのパブリケーションを機械的には許可しません。かわりに、パブリケーションの準備ができているのかを判断するために、ユーザー承認済アセットの状態を評価します。必要であれば、承認システムは、ユーザーによるサポート・アセットの承認を支援します。

操作時に、承認システムは、アセット依存性(テンプレートまたはデータ・モデルにエンコード済)が、承認済アセットの間でそのまま保持されることを保証します。このため依存性は、アセットがパブリッシュされるときに、パブリッシュ宛先に再現されます。承認された一連のアセットに破損したリンクがない場合、パブリッシュ時に、破損したリンクがない可能性が高くなります。承認された一連のアセットがバージョンの一致を維持している場合、パブリッシュ時に、バージョンの一致を維持する可能性が高くなります。

図17-1 パブリッシュ方法における承認システム

17.2 依存性分析の理解

承認システムは、承認済アセットの機能しないリンクおよびバージョンの不一致を分析する際、依存性テストを実行します。

1. 承認システムは、ユーザー承認済アセット間の依存性が、テンプレート・コードまたはデータ・モデルのどちらかで指定されている依存性と一致するかどうかを、パブリッシュ方法を考慮しながら判断します。図17-2 および図17-3 を参照してください。

- ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて(承認済アセット間の)依存性をテストします。テンプレートのコードを評価して、依存性を判断します。特定のタイプのアセットにデフォルト・テンプレートが割り当てられている場合は、そのテンプレートを使用して依存性を判断します。デフォルトのテンプレートがない場合、承認システムでは特定のアセットに指定されるテンプレートが使用されます。承認とディスクへのエクスポートのパブリッシュの詳細は、ディスクへのエクスポートのパブリッシュの用語の詳細を参照してください。

- サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、承認システムはデータ・モデルに基づいて(承認済アセット間の)依存性をテストします。

2. ユーザー承認済アセットに十分な依存性があることを検出した場合、アセットをパブリッシュすることを許可し、パブリッシュ・システムにリリースすることによって次回のパブリッシュ・セッションの処理対象にします。
一方、依存性が不十分なことを検出した場合は、それらの依存性がパブリケーション時に十分になるようなパブリッシュされたアセットを探し、パブリッシュされたコンテンツを参照します。PublishedAssets表をスキャンして、ターゲット宛先に何がパブリッシュされているかを調べます。

- 承認を必要とするアセットがターゲット宛先に(該当する場合は正しいバージョンで)存在しない場合、ユーザーにアセットを承認するように要求します。

- 承認を必要とするアセットがターゲット宛先に(該当する場合は正しいバージョンで)存在する場合、このアセットによりパブリケーション時に依存性が十分になるので、このアセットを承認(および再パブリケーション)する必要はありません。

注意:

管理者は、バージョンの一致を強制できます。その場合、ユーザー承認済アセットは、パブリッシュされたアセットのバージョンと一致して、依存性の基準に適合する必要があります(existsおよびexactと呼ばれます)。

サーバーへのミラーリングのパブリッシュの場合、バージョンの一致は、wcs_properties.jsonファイルの、mwb.conservativedependenciesプロパティ(Oracle WebCenter Sites: Engageカテゴリ)で指定されます。ディスクへのエクスポートのパブリッシュの場合は、テンプレート・コードで指定します。詳細は、コンテンツのバージョンの一致の保証を参照してください。

図17-2 ディスクへのエクスポートのパブリッシュ方法と承認

図17-3 サーバーへのミラーリングのパブリッシュ方法と承認

3. 承認システムは、すべてのユーザー承認済アセットの分析を完了すると、特定のアセットのパブリッシュを承認または禁止します。
承認システムは、パブリッシュを一括して承認または禁止するのではなく、分割してパブリッシュする方法をサポートします。依存性テストに合格したアセットはパブリッシュ・システムにリリースされ、次回のパブリッシュ・セッションの処理対象になります。依存性テストで不合格だったアセットはパブリッシュ・システムで保留され、承認を必要とするアセットが追加されたことがユーザーに通知されます。承認済アセット間の依存性は、パブリッシュ・セッションの処理量が想定より少なくなる原因になります。

承認済アセット間の依存性には、固有の処理および名前(承認依存性)があり、どちらも承認システムの動作を理解するために重要です。承認依存性は、同等に重要な用語、「承認」および「承認状態」とともに、パブリッシュの用語と定義の理解で説明されます。

17.3 パブリッシュの用語と定義の理解

承認、承認依存性および承認状態は、WebCenter Sitesパブリッシュ・モデルで特に重要な用語です。これらは、承認システムの動作を理解する上で重要な依存性に関連しています。このガイド全体で、さらにWebCenter Sitesパブリッシュ・インタフェースでも、使用されています。

この項の内容は次のとおりです。

- 承認: パブリッシュする意図とパブリッシュする権限の対比の理解

- 承認依存性の理解

- 承認状態の使用

17.3.1 承認: パブリッシュする意図とパブリッシュする権限の対比の理解

アセットをパブリッシュするには、まずユーザーが承認し、次に承認システムが承認する必要があります。承認のタイプを区別するために、ここではユーザー承認とシステム承認という用語を使用します。

- アセットのユーザー承認とアセットのシステム承認の相違点。
ユーザーのアセット承認は、ユーザーがアセットをパブリッシュする意図であることを示します。システムのアセット承認は、パブリッシュ・システムに、アセットをパブリッシュする権限を付与します。

アセットのユーザー承認は、依存性テストを実行するためにアセットを承認システムに送信することと同等です。ユーザー承認済アセットに対するシステム承認は、(1)ユーザー承認済アセットが依存性テストに合格していることを確認し、(2)次回のパブリッシュ・セッションでパブリケーションするためにアセットをパブリッシュ・システムにリリースすることと同等です。

- ユーザーがアセットを承認する機会を得る前に、そのアセットを承認システムが承認することは決してありません。
アセットがシステム承認済であるということは、ユーザーはそのアセットを承認済であるということです。

- ユーザーがアセットを承認する場合、常に特定のパブリッシュの宛先が対象になります。
アセットがユーザー承認済であるという場合、パブリッシュの宛先はわかっています(必要であれば明示的に特定されます)。

- システム承認は条件付きです。
ユーザーがアセットを承認する際、「承認済」状態をアセットに割り当てることができます。承認システムはこれを仮の承認として扱い、確認を必要とする状態として対応します。承認システムは、依存性テストを完了して「承認済」状態が有効であることを確認したときにのみ、アセットのパブリケーションを承認(リリース)します。

承認システムが「承認済」状態を確認できない場合、状態を却下して、独自の承認状態をアセットに割り当て、どのサポート・アセットが承認を必要とするかをユーザーを通知し、ユーザーがサポート・アセットを承認できるまで、現在のユーザー認証済アセットをパブリケーションから保留します。ユーザー承認済アセットのシステム承認は、ユーザーによるサポート・アセットの承認が条件になります。条件付き承認は承認依存性により引き起こされるもので、承認依存性の理解で説明しています。

- 承認システムは、アセットを非承認にできます。
承認システムは、承認表を最新の状態に維持する方法の1つとして、アセット変更イベントを処理する承認キューをサポートしています。たとえば、アセットがパブリケーションを承認された後に変更された場合、承認キューでアセットを非承認にして、パブリッシュ・キューから却下することによってこの変更を処理します。

承認キューは、ユーザーにアクセスできません。デフォルトでは、5分ごとに実行されます。ただし、承認機能を使用する機能(「パブリッシュ」タブなど)を起動すると、承認情報を最新の状態に維持するために、フォームが表示される前に承認キューが実行されます。

17.3.2 承認依存性の理解

このトピックを読む前に、ユーザー承認とシステム承認の2つの用語の違いを理解していることを確認してください。詳細は、承認: パブリッシュする意図とパブリッシュする権限の対比の理解を参照してください。

図17-4に示すように、承認依存性は条件付き依存性であり、これによる結果は条件付き承認となります。

図17-4 条件付き承認

条件1.承認依存性は、コンテンツ用に別のアセットを参照するアセットをユーザーが承認した場合に作成されます。

条件2.承認依存性が作成されている場合、参照元アセットのシステム承認は、承認先アセットが承認されることが条件になります。参照先アセットも承認されている場合のみ、承認システムは、参照元アセットを承認できます。このとき、参照元アセットは、参照先アセットに対する承認依存性があるといいます。

注意:

ここからは、参照元アセットを親アセットと定義します。参照先アセットは子アセットです。わかりやすくするために、親アセットは親としてのみ定義され、子アセットは子としてのみ定義されているとします。

承認依存性には、次のような重要な意味合いがあります。

承認依存性は2つのソース(データ・モデルまたはテンプレート・コード)のどちらかで作成されますが、承認依存性の数は必ずしもソースの依存性の数に等しいわけではありません。ソースに依存性が存在する場合、承認の際に、不十分な承認依存性、十分な承認依存性または承認依存性なしのいずれかになる可能性があります。どれになるかは、次の2つの要因によって決まります。

- ユーザーが承認済のアセット。

- 承認システムによる承認依存性の取扱い。承認システムは、指定のアセット・ペアに対して依存性が存在することを決定するだけではありません。承認済アセットが親か子かをテストすることによって、依存性の方向を明示的に示します。親アセットが承認済と判断した場合、承認依存性を記録します。子アセットが承認済と判断した場合、承認依存性を記録しません。

承認依存性の判断方法の詳細な例は、承認依存性の例を参照してください。

図17-5 エンコードされた依存性と承認依存性

17.3.2.1 承認依存性の例

前の項を補足するために、この例では承認依存性の判断方法を詳細に示します。

図17-6 エンコードされた依存性

図17-6は、2アセット・データ・モデルの図解です。アセットA1はコンテンツ用にアセットA2を参照します。データ・モデルで指定されている依存性は1つですが、ユーザーがアセットを承認する方法は3つあり、したがって、それぞれ異なる承認依存性が作成されます。

- 不十分な承認依存性:
この例では、ユーザーは親アセット(A1)を承認していますが、その子(A2)を承認していません。承認システムは、データ・モデルを(承認済アセットをシードとして)クロールし、A1→A2依存性を検出します。(ユーザーがA1のみ承認していることから)この依存性は不十分であると判断すると、それを不十分な承認依存性として分類します。さらに、A1の「承認済」状態を却下し、ユーザーがA2も承認するまでA1のパブリケーションを禁止し、ユーザーにA2を承認する必要があることを通知します。

図17-7 不十分な依存性

図17-7では、A1のシステム承認は、A2のユーザー承認が条件になります。A1は、A2に対する承認依存性があるといいます。承認依存性が不十分なので承認システムがユーザーに通知します。

- 十分な承認依存性:
この例では、ユーザーは親アセットとその子の両方を承認しています。承認システムは、データ・モデルの依存性が(ユーザーがA1とA2の両方を承認していることから)十分であることを検出して、依存性を十分な承認依存性として分類します。さらに、「承認済」状態であることを確認し、次回のパブリッシュ・セッションの開始時のA1とA2の両方のパブリケーションを許可します。

図17-8 承認依存性

前の例と同じように、A1のシステム承認は、A2のユーザー承認が条件になります。ただし、この例では、承認依存性は十分です。ユーザーには何も通知されません。アセットは、次回のパブリッシュ・セッションでパブリッシュされます。

- 承認依存性なし:
この例では、ユーザーは子アセット(A2)を承認していますが、その親(A1)を承認していません。この場合、(A2がA1に対して依存性がないので)承認システムは、承認依存性を認識しません。承認システムは、ユーザーの「承認済」状態を確認します。その結果、A2はパブリッシュされます(A1はパブリッシュされません)。

図17-9 承認依存性なし

17.3.2.2 承認依存性についての注意

- データ・モデルとテンプレート・コードでは指定する依存性のタイプが区別されますが(たとえば、アソシエーションと推奨アソシエーション)、承認システムはそれらの依存性を親子承認依存性として処理することによって単純化します。親は参照元アセットであり、コンテンツをその子に依存しています。詳細は、依存性分析のルールの使用を参照してください。

- データ・モデル依存性とテンプレート依存性は、開発者がどのアセットがコンテンツ用にどのアセットをどのように参照するかを指定するために作成しますが、承認依存性は、アセットを承認するユーザーが作成します。承認依存性は、承認システムによって分析され、どのユーザー承認済アセットがパブリケーションのためにリリース可能であり、どのユーザー承認済アセットがパブリケーションを保留する必要があるのか、どのアセットがまだユーザーによって承認されていないのか、どのアセットがパブリッシュ済なのか、などを示すために使用されます。

- データ・モデル依存性とテンプレート・コード依存性は、特定のデータ・モデルおよびテンプレートに対して固定されています。承認依存性は、一連のアセットおよび特定のパブリッシュの宛先が固定されていたとしても、変動する可能性があります。これは、承認するアセットの組合せが、承認のたびに異なるからです。

17.3.3 承認状態の使用

承認システムは、承認依存性を検出すると、アセットごとにユーザーが設定した「承認済」ラベルを確認するか、またはアセットに独自の承認状態を設定するか、どちらかを実行する必要があります。承認状態は、承認システムによってユーザー承認済アセットに割り当てられたラベルであり、その承認ステータス、すなわちなぜ承認済アセットをパブリッシュできないのか、アセットは承認されてパブリッシュされているのか、アセットはパブリッシュ可能(承認済だがパブリッシュ・セッションがまだ開始されていないのでパブリッシュされていない)なのか、などを示します。承認状態の完全なリストは、表17-4に示しています。

図17-10 承認済および非承認の承認状態

図17-10で、ユーザーはアセットA1を承認済としてマークしました。しかし、システムはこれを仮の承認として扱います。システムは、依存性分析の後で、A1が(たとえ承認済であっても)A2に対する不十分な承認依存性があり、(A2も承認されるまで)パブリケーションを保留する必要があると判断します。

システムはA1に「保留」という承認状態を割り当てることによって、ユーザーによるA1の承認をオーバーライドします。A2には「承認が必要」状態を割り当てます。

承認状態のリストは、承認のたびに異なることがあります(通常は異なります)。これは、ユーザーが承認したアセットの組合せが、通常、承認のたびに異なるからです。図17-11は単純な依存性モデルと3つの承認シナリオを示しています。どのシナリオにも同一のユーザーが関わります。

図17-11 単純な依存性モデル

それぞれの矢印が承認依存性を表します。4つのアセットがすべてパブリッシュされるには、パブリケーション時に4つの承認依存性が十分である必要があります。

A1→A2

A2→A3

A2→A4

A3→A4

(どのアセットも一度もパブリッシュされていません。)

ここで、ユーザーが承認するアセットの組合せが異なる3つのシナリオについて考えます。

1. 最初の(理念的な)試行で、ユーザーは4つすべてのアセットを承認し、4つすべての承認依存性を一度に満たします。このシナリオでは、システムは、4つの承認依存性を記録し、それらが満たされていると判断し、アセットを承認済として確認し、次のパブリッシュ・セッションの開始時におけるパブリケーションを許可します。これを図17-12 に示します。

図17-12 承認システム - すべて承認済

2. 2番目のシナリオ(図17-13)では、ユーザーはA1とA2の2つのアセットを承認し、これにより4つの承認依存性のうち1つが十分になります。次の3つの承認依存性は不十分なままです。
A2→A3

A2→A4

A3→A4

図17-13 依存性モデル

3. 図17-14に示すとおり、承認システムは3つの不十分な承認依存性を記録します。すべてのアセットについてパブリケーションの準備ができていないと判断し、すべてのアセットに独自の承認状態を割り当てて、次のリストをユーザーに返します。

- A3およびA4、「承認が必要」状態

- A1およびA2、「保留」状態。これらのアセットはA3とA4が承認されるまでパブリッシュできません。

図17-14 「保留」状態で承認待ちのアセット

4. 3番目のシナリオ(図17-15)では、ユーザーは2つのアセット(A1とA3)も承認しますが、承認依存性は満たしません。
A1→A2

A2→A3

A2→A4

A3→A4

図17-15 部分的承認状態

5. 承認システムは、4つの満たされていない承認依存性を記録し、すべてのアセットについてパブリケーションの準備ができていないと判断します(図17-16)。シナリオ2のリストとは異なるアセットと承認状態のリストを返します。

図17-16 保留依存性、承認待ち

今回のリストは次のとおりです。

- A2およびA4、「承認が必要」状態

- A1およびA3、「保留」状態

注意:

ユーザーが承認するアセットの組合せが異なると、システムが判断する承認依存性が異なり、したがって関連するアセットに割り当てる承認状態も異なります。

- ユーザーがA2を承認した場合、この例ではデータ・モデルで4つの依存性が指定されているにもかかわらず、承認システムが判断するのは3つの承認依存性のみ(A2→A3、A2→A4およびA3→A4)です。

- ユーザーがA3を承認した場合、承認システムは1つの承認依存性(A3→A4)を判断します。

- ユーザーがA4を承認した場合、承認システムは承認依存性を1つも判断しません。

承認依存性の判断方法の詳細は、承認依存性の理解を参照してください。

17.4 依存性分析のルールの使用

この機能を実行するために、承認システムは様々なルールに従います。この項ではそれらのルールの概要を示し、その後の項で詳細に説明します。

- 承認システムは、すべての承認依存性を親子関係として処理することによって単純化します。詳細は、承認依存性と親子関係の理解を参照してください。

- ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて承認依存性をテストします。詳細は、ディスクへのエクスポートのパブリッシュの使用を参照してください。

- サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、承認システムはデータ・モデルに基づいて承認依存性をテストします。詳細は、サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの使用を参照してください。

- バージョンの一致を制御する必要がある場合、管理者は、exists、exactまたはnoneのいずれかの依存性を設定して、バージョンの一致を強制または取り消すことができます。詳細は、コンテンツのバージョンの一致の保証を参照してください。

- 不十分な承認依存性があると判断すると、冗長な承認を回避するため、承認システムはパブリッシュされたコンテンツを検索します。詳細は、パブリッシュされたコンテンツの評価を参照してください。

17.5 承認依存性と親子関係の理解

承認システムは、データ・モデルとテンプレート・コードで指定されている様々なタイプの依存性(たとえば、アソシエーションと推奨アソシエーション)を単純化します。その由来やタイプに関係なく、すべての承認依存性を親子関係として分類し、次のルールに従います。

- 別のアセットを参照するアセットは常に親アセットで、参照されたアセットは子アセットです。図17-17に、1つのアセットが単に親アセットのみであり、別の1つが単に子アセットのみであり、残りがその混合である親子関係の例を示します。

図17-17 親子関係

以前の例と同様に、A1が親アセットで、A2はA1の子アセットかつA3とA4の親アセット、A3はA2の子アセットかつA4の親アセット、A4はA2とA3の子アセットです。

- 親アセットは、コンテンツを子アセットに依存しています。

- 承認システムは、子アセットがユーザー承認済であるか、またはパブリッシュの宛先に存在する場合にのみ、親アセットを承認します。

- 子アセットが親でもある場合、その子アセットを承認する必要があり(または宛先に存在する必要があり)、以下同様に繰り返されます。

- パブリッシュ方法がサーバーへのミラーリングまたはXMLへのアセットのエクスポートの場合、バージョンの一致を要件にできます(WebCenter Sites管理者の裁量によります)。その場合、承認システムは、アセットのバージョンをチェックします。バージョンの一致の詳細は、Exists/Exact依存性ルールの使用を参照してください。

- 承認システムは、親アセットとは独立して、子アセットのパブリケーションを承認します。ライブ・サイトでは、親から子へのリンクは破損しているように表示されるのでなく、単に表示されなくなります。(この点で、親データをライブ・サイトから不注意に削除することがありえます。)

図17-18に、4つのアセット間の階層依存性を示し、同時に承認する必要があるアセット(承認依存性の結果として)および単独で承認できるアセットを示します。

図17-18 承認依存性

- A1をシステム承認するには、A2、A3およびA4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A2をシステム承認するには、A3およびA4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A3をシステム承認するには、A4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A4は、単独でパブリッシュできます。

エレメントに追加された子アセットがある場合、これが原因となって親アセットが変更済とみなされます。このとき、親アセットが以前に承認されている場合、子アセットを追加することは、親ページがもはや承認されていない状態になることを意味します。これにより、承認済親アセットを使用して、変更のパブリッシュを保留することができます。

17.6 ディスクへのエクスポートのパブリッシュの使用

ディスクへのエクスポートのパブリッシュの場合、承認システムはテンプレート・コードに基づいて承認依存性をテストします。

注意:

承認テンプレートは、ディスクへのエクスポートのパブリッシュに対する開発者の承認方針を表します。ディスクへのエクスポートのパブリッシュについては、ディスクへのエクスポートのパブリッシュの用語の詳細で説明しています。

この項の内容は次のとおりです。

- 承認依存性の評価

- テスト・レンダリングの理解

17.6.1 承認依存性の評価

ディスクへのエクスポートを使用してパブリッシュされるフレックス・アセットとベーシック・アセットの場合、どちらにもテンプレートと参照の2つのタイプの承認依存性があります。

テンプレート依存性は、データ・モデルから独立しており、データ・モデルでアセットがどのように関連付けられているか(またはアセットが関連付けられているかどうか)には無関係です。たとえば、データ・モデルでは、記事とイメージのアソシエーションを指定できます。サーバーへのミラーリングのパブリッシュでは、記事はコンテンツをイメージに依存しており、イメージなしではパブリッシュできません。しかし、ディスクへのエクスポートのパブリッシュでは、アセットをレンダリングするために選択されているテンプレートで、独自の依存性が定義されます。この場合、次の可能性が考えられます。

- 承認テンプレート・コードで記事とイメージのアソシエーションを依存性として再作成し、それによってデータ・モデルに既存の関係をパブリッシュされたページに作成します。

- 承認テンプレート・コードでさらに別のアセット(オーディオ・ファイルなど)に対する依存性を作成し、それによってデータ・モデルには存在しないけれどもパブリッシュされたページには存在する関係を作成します。

- 承認テンプレート・コードでは2つのアセット間に依存性を作成しません。したがって、パブリッシュされたページでも関係を作成しません。それらのアセットは、データ・モデルでアソシエーションが指定されていたとしても、スタンドアロン・コンテンツとして処理され、互いに独立してパブリッシュされます。

テンプレート依存性を生成するタグは次のとおりです。

- <asset:load>

- <asset:loadall>

- <assetset:setasset>

- <assetset:setlistedassets>

- <render:logdep>

参照依存性は、あるページから別のページへのリンクが作成される際に生成されます。これらは、2つのページのプライマリ・アセット間の参照依存性として登録されます。たとえば、アセットAの承認テンプレートから、アセットBがプライマリ・アセットであるページへのリンクを作成した場合、承認システムはこれをアセットAのBに対する参照依存性として登録します。このような依存性を生成するタグは次のとおりです。

- <render:getpageurl>

- <render:gettemplateurl>

- <render:gettemplateurlparameters>

ディスクへのエクスポートのパブリッシュの承認依存性は、複雑なトピックです。承認依存性の詳細は、ディスクへのエクスポートのパブリッシュの用語の詳細を参照してください。

17.6.2 テスト・レンダリングの理解

アセットがディスクへのエクスポートのパブリッシュの宛先に対してユーザー承認済である場合、承認システムは、アセットに割り当てられているテンプレートのコードを評価することによって、そのアセットの承認依存性を判断します。また、コンテンツがパブリッシュされる際に明示される構成依存性のテンプレート・コードを評価するテスト・レンダリングも実行します。

構成依存性は、アセットを使用して生成されたページのアセットに対する依存性です。これらはページのテンプレートのロジックによって決まります。テンプレートを作成し、承認時に承認依存性を作成するタグと同じタグで、パブリケーション時の構成依存性も作成します。

そのタイプのアセットにデフォルト・テンプレートが割り当てられている場合、承認システムはそのテンプレートを使用して依存性を判断します。デフォルトのテンプレートがない場合、承認システムでは特定のアセットに指定されるテンプレートが使用されます。

開発者がアセット・タイプのデフォルト・テンプレートを作成するのは、ディスクへのエクスポートのパブリッシュ方法で実際にアセットをパブリッシュする場合、必ずしもそのアセットに割り当てられているテンプレートが使用されるわけではないためです。別のエレメントのコードにより、特定のケースではそのアセットに別のテンプレートが使用されていると判断される可能性があります。サイトでそのような状況になる場合、テンプレートを作成した開発者が、承認システムが承認依存性を決定する際に使用するデフォルト・テンプレートも設計していることが考えられます。

管理者またはサイト・デザイナは、アセット・タイプごとおよびパブリッシュの宛先ごとにデフォルト承認テンプレートを設定できます。詳細は、承認テンプレートまたはプレビュー・テンプレートの割当てを参照してください。

17.7 サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの使用

サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュ方法では、承認システムはデータ・モデルに基づいて承認依存性をテストします。

注意:

サーバーへのミラーリングのパブリッシュおよびXMLへのエクスポートの場合、ライブ・サイトに不十分な構成依存性が存在する可能性があります。これは、サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの際、ページをレンダリングするテンプレートは評価されないからです。

構成依存性は、動的ページをアセンブルしたときに現れます。構成依存性には、ページを生成するために使用する一連のアセットが含まれます。構成依存性の詳細は、テスト・レンダリングの理解と構成依存性の使用を参照してください。

17.8 コンテンツのバージョンの一致の保証

管理者が親アセットと子アセットのバージョンの一致を要求することによって、あらゆるパブリッシュ・セッション(たとえば図17-18のもの)の条件を厳しくできます。この要件により、自己矛盾のないコンテンツが保証されます。バージョンに対する依存性は、データ・モデルまたはテンプレート・コードのどちらにもエンコードされません。

- サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの場合、wcs_properties.jsonファイルのmwb.conservativedependenciesプロパティの値をexistsまたはexactに設定することによって指定します。

- ディスクへのエクスポートのパブリッシュの場合は、該当するタグのdeptype属性をexists、exactまたはnoneに設定することによって指定します(タグのリストは承認依存性の評価を参照)。

バージョンに対する依存性は、exists、exactまたはnoneの用語で修飾されます。

- exists依存性は、バージョンの一致を必要としません。親をパブリッシュするには、単純に、その子アセットが承認済アセットまたはパブリッシュの宛先のパブリッシュされたアセットのいずれかとして存在する必要があります。親アセットのバージョンは、その子アセットのどのバージョンとも一致していてはなりません。

- exact依存性は、バージョンの一致を必要とします。この依存性は、親のバージョンがその子アセットのバージョンと一致する必要がある(これはその依存性に関連するすべてのアセットのバージョンが互いに一致する必要があることを意味します)という点を除けば、exists依存性と同じです。

- none依存性の場合、それを使用しているタグでは承認依存性が指定されません。

exists依存性とexact依存性について図17-19 にまとめ、説明します。

図17-19 Exists/Exact依存性

exists依存性は、バージョンの一致を必要としません。

- A1をシステム承認するには、A2、A3およびA4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A2をシステム承認するには、A3およびA4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A3をシステム承認するには、A4が承認済アセット(あるいは、宛先におけるパブリッシュ済アセット)として存在する必要があります。

- A4は、単独でパブリッシュできます。

exact依存性は、バージョンの一致を必要とします。

- A1のシステム承認はexists依存性と同じですが、A1のバージョンは子アセットA2のバージョンと一致する必要があります。

- A2のシステム承認はexists依存性と同じですが、A2のバージョンは子アセットA3およびA4のバージョンと一致する必要があります。

- A3のシステム承認はexists依存性と同じですが、A3のバージョンは子アセットA4のバージョンと一致する必要があります。

- A4は、単独でパブリッシュできます。

17.9 サーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

フレックス・アセットのサーバーへのミラーリングおよびXMLへのエクスポートのパブリッシュの場合、existsまたはexactのどちらの依存性が有効なのかは、wcs_properties.jsonファイルのmwb.conservativedependenciesプロパティの値によって決まります。

- デフォルト値(false)は、exists依存性を示します。

- 値trueは、exact依存性を示します。

注意:

mwb.conservativedependenciesがfalse (exists)に設定され、属性を使用している場合、その属性の「値タイプ」、「ストレージ・スタイル」、「外部ID」、「外部表」および「外部列」の各フィールドはロックされ、変更できません。

mwb.conservativedependenciesの値を変更した場合、その変更の影響を受けるアセットを再承認する必要があります。

17.10 ディスクへのエクスポートのパブリッシュのExists依存性とExact依存性の使用

ディスクへのエクスポートのパブリッシュの場合、開発者は、getpageurlおよびassetloadといった適用可能なタグのdeptype属性を使用して、exists、exactまたはnoneに設定します。(タグのリストは、テスト・レンダリングの理解を参照してください)。

テンプレート依存性は、exact依存性がデフォルトです。アセットBが変更されている場合、アセットAを承認するにはアセットBを承認する必要があります。参照依存性は、常にexists依存性です。Bを一度承認してパブリッシュした場合、Aを再パブリッシュするためにBを再承認する必要はありません。

いずれかのタグでdeptype="none"が設定されている場合は例外です。その結果、タグによって承認依存性は一切作成されません。このことは、承認中に依存性のレコードが作成されないことを意味します。ディスクへのエクスポートのパブリッシュおよびライブ・サイトなど、他のすべてのコンテキストでは、deptype属性は無視されます。

17.11 Exists/Exact依存性ルールの使用

サーバーへのミラーリングまたはXMLへのアセットのエクスポートの宛先に対してアセットが承認されている場合、承認システムはデータ・モデルに基づいて承認依存性を判断します。

注意:

この項を読む場合、承認依存性のコンテキストでは、依存アセットという用語は親アセットと同等であるという点に留意してください。承認依存性の親子関係を管理するルールの詳細は、承認依存性と親子関係の理解を参照してください。

この項の内容は次のとおりです。

- ベーシック・アセット・タイプの依存性ルールの理解

- CSElementおよびSiteEntryアセットの依存性ルールの理解

- フレックス・ファミリの依存性ルールの理解

- Engage訪問者データ・アセットの依存性ルールの理解

17.11.1 ベーシック・アセット・タイプの依存性ルールの理解

ベーシック・アセットの場合、承認システムは表17-1の依存性ルールに従います。

表17-1 アセットの関係と依存性

承認済アセットとの関係

依存性 - Exists

依存性 - Exact

アソシエーション

あり - exactとして構成されている場合を除き、これがデフォルトです

該当なし

ページ・アセットのみの場合: サイト・プランの下位レベルの別のページ・アセット

あり

該当なし

埋込みリンク

あり

該当なし

埋込みページレット

該当なし

あり

アソシエーションのルール:

- アセット・アソシエーションの設計方法に応じて、承認済アセットは、名前付きアセット・アソシエーションを通じて参照しているアセットに対して、exists依存性またはexact依存性があります。

ページ・アセットのルール:

- 承認済ページ・アセットは、サイト・プランの階層(SitePlanTree表に反映されます)でそれ自体より下位にあるページ・アセットに対して、exists依存性があります。

埋込みリンクのルール:

- 承認済アセットは、埋込みリンクによって参照しているアセットに対して、exists依存性があります。埋込みリンクの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

埋込みページレットのルール:

- 承認済アセットは、埋込みページレットとして参照しているアセットに対して、exact依存性があります。埋込みページレットの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

17.11.2 CSElementおよびSiteEntryアセットの依存性ルールの理解

SiteEntryアセットのルート・エレメントは、CSElementアセットにより表されます。次のルールが適用されます。

承認済SiteEntryアセットは、参照しているCSElementに対して、exists依存性があります。

17.11.3 フレックス・ファミリの依存性ルールの理解

フレックス・ファミリ・メンバーの場合、承認システムは表17-2の依存性ルールに従います。

表17-2 フレックス・ファミリの依存性ルール

承認済アセット

フレックス親定義

フレックス親

フレックス定義

フレックス属性

フレックス・フィルタ

属性エディタ

テンプレート

フレックス親定義

既存

該当なし

該当なし

既存

該当なし

該当なし

該当なし

フレックス親

既存

既存

該当なし

既存

該当なし

該当なし

該当なし

フレックス定義

既存

該当なし

該当なし

既存

該当なし

該当なし

該当なし

フレックス・アセット

該当なし

既存

既存

既存

該当なし

該当なし

既存

フレックス属性

該当なし

該当なし

該当なし

該当なし

既存(デフォルト)

既存

該当なし

フレックス親定義のルール:

- 承認済フレックス親定義は、そのフレックス親定義およびフレックス属性に対して、exists依存性があります。

フレックス親のルール:

- 承認済フレックス親は、そのフレックス親定義、フレックス親およびフレックス属性に対して、exists依存性があります。

フレックス定義のルール:

- 承認済フレックス定義は、そのフレックス親定義、フレックス親およびフレックス属性に対して、exists依存性があります。

フレックス・アセットのルール:

- 承認済フレックス・アセットは、そのフレックス親、フレックス・アセット定義、フレックス属性およびテンプレートに対して、exists依存性があります。

フレックス属性のルール:

- 承認済フレックス属性は、フレックス・フィルタに対して、そのコード化方法に応じて、exists依存性またはexact依存性があります。デフォルト・フレックス・フィルタは、exists依存性用にコード化されています。属性のタイプがアセットの場合、そのアセットに対してexists依存性またはexact依存性のどちらがあるかは、ユーザーが決定できます。

承認済フレックス属性は、(属性エディタが割り当てられている場合)その属性エディタに対して、exists依存性があります。

フレックス・ファミリ・メンバー間のexists依存性とexact依存性の詳細は、フレックス・ファミリの依存性ルールの理解を参照してください。フレックス・ファミリ・メンバーの機能の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

17.11.4 Engage訪問者データ・アセットの依存性ルールの理解

承認システムは、次のルールを使用して、Engage訪問者データ・アセット・タイプの承認依存性を判断します。

表17-3 Engage訪問者データ・アセットの承認依存性

承認済アセット

履歴定義

履歴属性

訪問者属性

推奨事項

関連フレックス・アセット

履歴定義

該当なし

exact

該当なし

該当なし

該当なし

セグメント

既存

該当なし

既存

該当なし

該当なし

推奨事項

該当なし

該当なし

該当なし

該当なし

該当なし

プロモーション

該当なし

該当なし

該当なし

既存

該当なし

フレックス・アセット

該当なし

該当なし

該当なし

該当なし

既存

- 履歴定義は、その履歴属性に対して、exact依存性があります。

- セグメントは、使用している履歴定義および訪問者属性に対して、exists依存性があります。

- プロモーションは、オーバーライドする推奨アセットに対して、exists依存性があります。

- フレックス・アセットは、関連アイテムとして指定されている任意のアセットに対して、exists依存性があります(関連アイテム推奨の場合)。

17.12 パブリッシュされたコンテンツの評価

不十分な承認依存性があると判断すると、冗長な承認を回避するため、承認システムはパブリッシュされたコンテンツを検索します。

具体的に言うと、承認システムは、PublishedAssets表を読み取ります。承認を必要とするアセットが、特定の宛先にパブリッシュ済としてリストされている場合、承認システムは、バージョンの一致は要求されていないと想定して、同じアセットを承認および再パブリッシュする必要はないとみなします。exact依存性がデータ・モデルまたはテンプレート・コードで指定されている場合は、承認システムは、パブリッシュされているアセットのバージョンをチェックします。コンテンツのバージョンの一致の強制の詳細は、コンテンツのバージョンの一致の保証を参照してください。

17.13 承認システムの例

この項には、承認システムの仕組みを包括的に説明するシナリオが示されています。このシナリオでは、まずユーザーがアセットを承認し、次に承認システムが依存性を分析し、最後に承認システムから対応する様子を示します。その際、サーバーへのミラーリングのパブリッシュの例およびexists依存性を使用して、この章でこれまでに説明したすべての概念、すなわち承認、承認依存性および承認状態に言及します。

1. このシナリオ(図17-20 )では、(使用可能な4つのアセットのうち) 1つのアセットA2を編集し、exists依存性に従って動的にパブリッシュすることを承認します。ターゲット宛先にはA4のみがすでにパブリッシュされています。

図17-20 ユーザー承認済アセット

2. ユーザーがパブリッシュしようとすると、承認システムはデータ・モデルをクロールして、エンコードされている依存性(図17-21で矢印で表示)を判断します。

図17-21 システムによるデータ・モデルのクロール

承認システムは、承認済アセットをシードとして使用して、データ・モデルでアセットのリンクをたどってリンク元またはリンク先の他のアセットに移動し、さらにそのアセットのリンクをたどってリンク元またはリンク先のまた別のアセットに移動するということを、シードの依存性ネットワークの境界が特定されてそれ以上依存性が検出されなくなるまで、繰り返します。

3. 手順1の結果に基づいて、承認システムは、承認ランドスケープを構成します。承認ランドスケープでは、相互に依存するすべてのアセットおよびそれらの間の関係が特定されます(図17-22 )。

図17-22 システムによる承認の作成

4. 承認システムは、承認依存性およびパブリッシュ・セッションに対するそれらの影響をテストします。図17-23に、承認システムの判断プロセスを示します。

図17-23 システムによる承認依存性の分析

この例では、承認システムは次のことを判断します。

- A1は、その子の承認済アセットA2が独立してパブリッシュ可能なので、承認を必要としません。ただし、A2は親アセットでもあり、その子アセット(A3およびA4)のステータスが決定されるまではパブリッシュできません。承認システムは、今度はすでにパブリッシュされているアセットを検索します。PublishedAsset表を参照し、さらに次のことを判断します。

- A3はターゲット宛先には一度もパブリッシュされていません。A2→A3に十分な依存性があるためには、A3を承認する必要があります。

- A4はターゲット宛先にすでにパブリッシュされているので、その再承認(および再パブリッシュ)は必要ありません。A2およびA3のA4に対する依存性は、パブリケーション時に十分な依存性になります。

5. 手順4より、承認システムは、承認済アセットをパブリッシュするために3つの承認依存性が十分である必要があると結論付けて、それに基づいてアセットに独自の承認状態を割り当てます。図17-24に、システムによる承認状態の割当ての例を示します。

図17-24 システムによる承認状態の割当て

- A2→A3承認依存性を(ユーザーがA3を承認することで)十分にする必要があります。A3に「承認が必要」状態を割り当て、A2に「保留」状態を割り当てます。

- A3→A4を(「承認が必要」状態が割り当てられているA3をユーザーが承認することで)十分にする必要があります。

- A2→A4は、A4がすでにパブリケーションされているので、自動的に十分になります(現在「承認済かつパブリッシュ済」状態が割り当てられています)。

(承認状態の完全なリストは、表17-4にあります。)

6. 最後に、承認システムは、アセットおよびその承認状態(図17-24で表示)のリストを表示します。ユーザーは、リストに基づいて、「承認が必要」状態が割り当てられているアセット(A3)を承認します。

図17-25 ユーザーによるサポート・アセットの承認

7. 承認システムは、承認プロセスを実行するために、A2の承認状態を「承認済」に更新し、A2とA3の両方を次回のパブリッシュ・セッションでのパブリケーションのためにパブリッシュ・システムにリリースします(図17-26 )。

図17-26 システムによるユーザー承認の確認

17.14 承認状態の使用: リファレンス

表17-4に、承認システムによって承認依存性のアセットに割り当てられ、ユーザーに表示される可能性がある承認状態を示します。

注意:

表17-4で、承認依存性のコンテキストでは、依存アセットという用語は親アセットと同等であるという点に留意してください。承認依存性の親子関係の詳細は、承認依存性と親子関係の理解を参照してください。

表17-4 承認システムにより割り当てられる承認状態

承認状態

説明

承認済。宛先に対するパブリッシュが承認済で準備ができています。

(情報)このアセットは、アセットが変更されるか、またはexact依存性が変化した場合を除き、この宛先に対する次回のパブリッシュ・イベントでパブリッシュされます。

承認済かつパブリッシュ済。アセットのバージョンが宛先のアセットのバージョンと一致しています。

(情報)exact依存性を持つアセットが、この宛先にパブリッシュされています。

現在チェックアウトされています。宛先にはパブリッシュされません。

(アクションが必要な可能性あり)アセットはリビジョン追跡でチェックアウトされています。承認済ですが、リビジョン追跡が次のいずれかの方法で制御を放棄するまでパブリッシュできません。

- チェックイン: アセットを再承認する必要があります。

- チェックアウトを元に戻す: アセットは承認済のままであり、パブリッシュできます。

- ロールバック: アセットを再承認する必要があります。

宛先に対してエクスポートされるページでリンクとして承認されています。

(情報)このアセットは、エクスポートされるページからリンクされている場合、ディスクへのエクスポートのパブリッシュを承認されています。

アセットは宛先に対するパブリッシュの承認後に修正されています。

(アクションが必要)アセットを再承認する必要があります。

承認されましたが、宛先に対するパブリッシュの承認は、存在しない子アセットのバージョンに基づいています。

(アクションが必要)アセットは、そのバージョンがその子アセットのバージョンと一致するように、再承認する必要があります。

保留。承認されましたが、子アセットが宛先に対するパブリッシュを承認されていません。

(アクションが必要)アセットは、次のいずれかの条件が成立する場合、パブリッシュ・セッションで保留されます。

- アセットが承認後に再編集され、その後再承認されていません。

- アセットにexact依存性のある子アセットがあり、その子アセットが承認されていません。

- アセットにexists依存性のある子アセットがあり、その子アセットが一度もパブリッシュされていません。

- アセットにexact依存性のある子アセットがあります。子アセットはパブリッシュされていますが、その後編集され、まだ承認されていません。

- アセットに、別のアセットの子アセットに対するexact依存性があり、その子アセットは以前承認されましたが、その後編集され、まだ再承認されていません。

- アセットはチェックアウトされています(リビジョン追跡)。

承認が必要。宛先に対するパブリッシュはまだ承認されていません。

(アクションが必要)アセットを承認する必要があります。

このアセットは、参照しているアセットが承認されるまでパブリッシュできません。

(アクションが必要)このアセットをパブリッシュできるようにするには、参照先アセットを承認する必要があります。保留されている関連アセットもリストされ、承認が必要な場合があります。

18 ワークフロー・プロセスの作成と管理

次の各トピックでは、アセットの作成に複数の人が参加している場合にその作業を管理するために使用する機能であるワークフローについて説明します。たとえば、特定のタイプのアセットをパブリッシュ用に承認する前に、編集者または法定代理人によるレビューが必要な場合、ワークフロー機能でそれらのアセットを適切な人々に適切なときにルーティングできます。

- ワークフロー機能について

- ワークフロー・プロセスの計画

- ワークフロー・プロセスの構成

- 電子メール・オブジェクトの設定

- アクションと条件の設定

- パブリッシュの承認ステップ・アクションの構成

- 時間指定アクション・イベントの設定

- 状態の設定

- ワークフロー・プロセスの設定

- ワークフロー・プロセスの作成

- ワークフロー・プロセスのテスト

- 作業の移動

- ワークフローの割当ての消去

- ワークフロー・レポートの作成および表示

- ワークフロー・グループの作成

18.1 ワークフロー機能について

すべてのコンテンツ・プロバイダにとって、最終目標はコンテンツ・アセットをパブリッシュすることです。アセットは、パブリッシュする前にパブリッシュ用に承認する必要があります。ワークフロー機能により、作成から承認までアセットを誘導するワークフロー・プロセスで必要な一連のタスクすべてが、アセットに対して実行されます。

ワークフロー・プロセスは、組織でその作業の遂行手順を反映するために必要な任意の数のタスクで構成できます。アセットが割り当てられたこと、および期限が近づいていることや期限を過ぎていることをユーザーに通知するためにWebCenter Sitesから送信される電子メッセージを構成できます。

考えられる構成が数多くあるため、複数のアセット・タイプに1つのプロセスを作成するのではなく、ワークフローを使用する予定のアセット・タイプごとに個別のワークフロー・プロセスを作成することが一般的です。

ワークフロー機能の詳細は、次の各トピックを参照してください。

- ワークフローの参加者の理解

- ワークフロー状態の理解

- 状態から状態へのアセットの移動

- アセットに対する複数のパスの使用

- デッドロックの管理

- ワークフロー・グループの理解

- 割当ての委任と消去

- ワークフローへのアセットの配置

- ワークフロー内にあるアセットへのアクセスの制限

- 期限の使用

- 期限計算のスケジュール

- ワークフロー・プロセスの終了

18.1.1 ワークフローの参加者の理解

ワークフロー・プロセスに参加する人々の役職は、WebCenter Sitesインタフェースではロールとみなされます。ロールは、そのサイトでの個々の機能を説明します。サイトに対してユーザーを有効にするとき、そのユーザーに、そのサイトに対して実行するロールを割り当てます。

ワークフロー・プロセスを作成するときに、タスクごとにどのロールが適しているのか判別します。個々のアセットがワークフロー・プロセスを通過していく際に、適切なロールを持つユーザーのみがそのタスクの実行を許可されます。任意の時点で適切なロールを持つユーザーのプールから選択された個々のユーザーは、ワークフロー参加者と呼ばれます。

18.1.2 ワークフロー状態の理解

アセットに対して実行されるタスクは、ワークフロー状態と呼ばれます。状態は、その時点でのアセットのステータスを表すワークフロー・プロセス内のポイントです。たとえば、記事の執筆、イメージのレビュー、法的レビューなどです。参加者は、アセットがその状態にある間に状態が表す作業を完了します。

状態間のアセットの移動はステップと呼ばれます。プロセス内のステップを作成すると、状態が特定の順序でつなぎ合され、ワークフロー・プロセス内のステップを作成することで、プロセスが編成されます。

参加者が作業するアセットは割当てと呼ばれます。ユーザーの割当てリストは、管理者のインタフェースの「割当て」フォームに表示されます。アセットは、ユーザーがワークフロー参加者の状態になるとすぐに、ユーザーに割り当てられます。

アセットを、特定の期間のみ、ある状態に維持するには、その状態に期限を割り当てます。その後、ワークフロー・プロセスを構成して、その期限が近づくか期限を過ぎたときに、参加者に通知する電子メール・メッセージを送信することができます。これらの電子メール・メッセージは時間指定アクションの例です。各状態に1つ以上の時間指定アクションを作成できます。

18.1.3 状態から状態へのアセットの移動

プロセス内のステップを作成する際、ステップによってどの状態からアセットが移動されるのか(開始状態)、ステップによってどの状態にアセットが移動されるのか(終了状態)、およびどのロールがステップを実行できるのかを指定します。

ステップにより、アセットはある状態に置かれ、適切なロールの参加者に通知されます。この処理により、割当てが作成されます。次に、それらのロールの参加者がアセットを次の状態に移動するためのステップが必要です。つまり、前のステップによって通知されたロールが、次のステップを実行するよう認可されたロールです。例:

図18-1 編集におけるステップ

ユーザーが割り当てられているアセットに対して「割当ての終了」オプションを選択すると、そのオプションによってステップが呼び出され、アセットが次の状態に移動され、次の参加者に割り当てられます。同じ状態の1つのアセットに複数の参加者が割り当てられている場合、「割当ての終了」オプションを使用することは投票とも呼ばれます。各参加者は、投票して、アセットを次の状態に移動します。

ワークフロー・プロセスの最初のステップが、開始ステップです。開始ステップには、開始状態がありません。つまり、開始ステップによってワークフロー・プロセスが始まり、そのアセットが一連の状態のうちの最初の状態に移動します。これは、ワークフロー・プロセスがアセットに割り当てられたときにコールされるステップです。開始ステップに対して認可されたロールを持つユーザーのみが、アセットに対してワークフロー・プロセスを開始できます。

ステップ・アクションは、ステップが完了したときに発生するイベントです。各ステップに1つ以上のステップ・アクションを指定できます。ステップ・アクションの例は、ApproveForPublishアクションです。これは、アセットを承認するデフォルトのアクションであり、WebCenter Sitesに付属しています。通常、このアクションはワークフロー・プロセスの最終ステップで使用します。

18.1.4 アセットに対する複数のパスの使用

ワークフロー・プロセスに、人がアセットをレビューする状態が含まれている場合、通常、そのワークフローには1つのアセットに対して考えられるパスが複数あります。これは、レビューアがそれをそのまま受け入れる場合と拒否する場合があるためです。

そのような場合、レビュー状態からアセットを移動するステップを2つ作成します。アセットがその状態にあるとき、「割当ての終了」フォームには両方のオプションがリストされ、参加者は割当てを終了するときに該当するステップを選択します。

図18-2 ワークフローのステップ

複数の参加者が同じ状態の同じアセットをレビューしていて、異なるステップを選択した場合にどうなるかは、各ステップをどのように構成したかによって異なります。次のようないくつかの可能性があります。

- 割当て(投票)を最初に終了した参加者によってアセットの進む方向が決定されるようにステップを構成する。

- アセットがいずれかの方向に進むためにはすべての参加者が同じステップを選択する(同じように投票する)必要があるようにステップを構成する。ステップを完了するにはその前にすべての参加者が選択する必要があるステップはすべて投票ステップと呼ばれます。このオプションは、デッドロックの管理で説明するように、デッドロックになることがあります。

- 前述の方法を組み合せて使用する。すべて投票ステップ(すべての参加者が同意する必要がある)を1つ構成し、さらにそれ以外のステップを構成して、それを選択した参加者がいた場合に、そのステップが実行されアセットがそのパスをたどるようにします。

18.1.5 デッドロックの管理

デッドロックは、次の条件が満たされると発生します。

- 1つの状態からのステップが複数ある。

- 2つ以上のステップで、参加者がそのステップを実行する必要がある。つまり、これらはすべて投票ステップです。

- その状態のアセットが複数の参加者に割り当てられている。

- 参加者が割当てを終了するときにすべて投票の異なるステップを選択する。

図18-3に、デッドロックを図解します。

図18-3 ワークフローのデッドロック

ステップのうちの1つがすべて投票ではなく、参加者がそのステップを選択しても、そのアセットはデッドロックになりません。

デッドロック状態にあるアセットは、デッドロックが解決されるまでワークフロー・プロセスを進めることはできません。デッドロックを解決するには、参加者同士で協議し、アセットが進むパスについて同意する必要があります。その後、選択内容を変更する必要がある参加者が次のいずれかを実行することでデッドロックを解決できます。

- 割当てを終了し、全員が同意したステップを選択します。

- アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストから「投票の棄権」オプションを選択します。

デッドロックになる可能性があるワークフロー・プロセスを構成する前に、その状態からの考えられるすべてのステップについて、完全な同意が絶対に必要であることを確認します。この説明から明らかなように、デッドロックはすべての参加者に追加作業が生じるため、この機能は必要な場合にのみ使用してください。

たとえば、考えられるステップとして「改訂のために戻す」と「パブリッシュ用に承認する」の2つがあるレビュー状態を考えてみます。「改訂のために戻す」には全員一致の投票は必要ないが、「パブリッシュ用に承認する」にはそれが必要となるようにステップを構成すると、デッドロックのリスクがない適切な制御(すべてのレビューアは、アセットがパブリッシュされる前に同意する必要があり、拒否されるとアセットのパブリッシュは停止される)が作成されます。

デッドロックになる可能性があるワークフロー・プロセスを作成する必要がある場合は、必ず、デッドロックを発生させる可能性があるステップごとに、デッドロックを参加者に通知するデッドロック・アクションを構成して割り当ててください。デフォルトのデッドロック・アクションは、ステップでデッドロックが発生したときに、該当する参加者にWebCenter Sitesから送信される電子メール・メッセージです。

18.1.6 ワークフロー・グループの理解

ワークフロー・グループを使用すると、いくつかのアセットを1つの作業単位とみなすことができます。1つのワークフロー・グループのアセットは、同時に承認する必要があります。

ワークフロー・グループと使用するワークフロー・プロセスを作成し、そのいずれかのステップがデッドロックになる可能性がある場合は、必ず、グループ・デッドロックがあったときに参加者に通知するグループ・デッドロック・アクションを構成し、それをそのプロセスに割り当てます。

ワークフロー・グループによって、コンテンツ・プロバイダは、ワークフローを介して一緒にアセットの定義済セットを送信できます。ワークフロー・グループの作成とグループに割り当てるアセットの選択はコンテンツ・プロバイダが行いますが、管理者は、ワークフロー・プロセスを適切に構成できるように、ワークフロー・グループにどの種類のアセットが含まれるのかを把握する必要があります。

ワークフロー・グループの作成に関する詳細は、ワークフロー・グループの作成を参照してください。

18.1.7 割当ての委任と消去

人は休暇を取ったり、新しいワーク・グループに再割当てされたり、別の仕事に異動したりします。彼らが作業をしていたアセットはどうなるのでしょうか。そのような場合、その割当てを適切なロールを持つ他の参加者に委任できます。

各ワークフロー・プロセスにはワークフロー管理者を設定できます。ワークフロー・プロセスの管理者は、他の参加者のかわりに割当てを委任できます。各ワークフロー・プロセスについて、電子メール通知など、1つ以上の委任アクションを指定できます。

アセットを割り当てる必要がなくなった場合または割当てを消去して最初からやり直すほうが簡単な場合は、「管理」タブの「割当てのクリア」を使用できます。

18.1.8 ワークフローへのアセットの配置

アセットは、次の方法のいずれかでワークフロー・プロセスへの参加を開始します。

- ユーザーがそのアセットの「ステータス」フォームの「ワークフロー・コマンド」フィールドからワークフロー・プロセスを選択する。
ワークフロー・プロセスを選択すると、そのプロセスの開始ステップがコールされ、それによってアセットが最初の状態に配置されます。

- ユーザーが、アセットを作成し、そのタイプのアセットのスタート・メニューの「新規」アイテムが、デフォルトのワークフロー・プロセスが存在するように構成される。
この場合、アセットを保存すると、そのプロセスの開始ステップがコールされ、それによってアセットが最初の状態に自動的に配置されます。

ステップは特定のロールに対して有効化されているため、プロセスの開始ステップに割り当てられているロールを持つユーザーのみがそのプロセスを選択できます。スタート・メニュー・アイテムを使用してワークフローにアセットを配置する場合、そのスタート・メニュー・アイテムに割り当てられているロールがデフォルトのワークフローの開始ステップに割り当てられているものと同じロールであることを確認してください。

18.1.9 ワークフロー内にあるアセットへのアクセスの制限

ワークフローによってアセットはビジネス・プロセスを通り、適切なときに適切なユーザーに送られますが、アセットが特定のユーザーに割り当てられたからと言って、他のユーザーがこれを修正または削除できなくなるわけではありません。

誰がワークフロー内のアセットにアクセスできるかを制限するには、機能権限と呼ばれるワークフロー機能を使用します。これらは、ワークフロー状態とワークフロー・ロールのコンテキストで、編集、コピー、承認、削除、バージョンの表示などの機能に対して設定される制限です。

機能権限には、次の3つの部分があります。

- 制限される機能。

- その機能の実行を許可されるまたは許可されないロール。

- それらのロールを持つユーザーがその機能の実行を許可されるまたは許可されない状態。

機能権限が有効になっているということは、次の条件を満たす場合にのみユーザーがその機能を実行できることを意味します。

- そのユーザーが適切なロールを持っている。

- そのアセットが適切な状態にある。

- そのアセットがそのユーザーに割り当てられている。

ユーザーが適切なロールを持っていて、かつアセットが適切な状態にある場合でも、そのアセットがそのユーザーに割り当てられていなければ、そのユーザーはそのアセットに対してその機能を実行できません。

機能権限によって、機能へのアクセスがそのユーザー・インタフェースからのみに制限されます。その時点でどの機能権限が設定されているのかに関係なく、ステップが実行されたときに機能をコールするステップ・アクションをプログラミングできます。

ApproveForPublishステップ・アクションが1つの例です。ユーザーがそのユーザー・インタフェースから「承認」オプションを使用することを禁止する機能権限を指定しても、ワークフロー・ステップによって「パブリッシュの承認」アクションがコールされ、そのユーザーがそのステップを実行するための適切なロールを持っていると、同じそれらのユーザーがそのワークフロー・ステップでアセットを承認できます。

つまり、機能権限を使用することでユーザーが誤ってアセットを選択および変更することを防止し、アクションを使用して高度な制御方法でそれらの機能をコールすることができます。

特定のロールに対して機能へのアクセスを許可または制限する機能権限を1つでも作成する場合は、その機能に対して他のすべてのロールを対象とする機能権限を作成する必要があります。

たとえば、削除機能のみを制限する(記事がレビュー状態にあるときにのみ、編集者のみが記事アセットを削除できるようにする)とします。レビュー状態にある記事アセットの削除を編集者に許可する機能権限を作成するが、その他の機能権限を作成しない場合、レビュー状態での削除機能へのアクセスを他のロールに明示的に付与するまで、レビュー状態になっている記事アセットをほかには誰も削除できません。

レビュー状態にあるアセットに対する削除機能へのアクセスを編集者に対して拒否する機能権限を作成すると、レビュー状態での削除機能へのアクセスを他のロールに明示的に付与するまで、レビュー状態になっている記事アセットをどのユーザーも削除できません。

18.1.10 期限の使用

ワークフロー期限には、次の2種類があります。

- 割当て期限: アセットが個々の状態に留まる期間の長さを指定します。状態の「予測時間」フィールドに値を設定すると、アセットがその状態にあるときにワークフロー参加者に割り当てられるアセットの期限が作成されます。

- プロセスの期限: アセットがプロセス全体を通過するためにかかる時間の長さを指定します。

これらの異なるタイプの期限は、相互に対話することはなく、個別に計算され、相互に排他的です。多くの場合、同じワークフロー・プロセスではどちらか一方の種類を使用し、両方を使用することはありません。

ワークフロー状態を作成するとき、それに対して予測時間を設定し、割当てが、その予測時間から計算された期限を過ぎたときに通知電子メールを送信するかどうかを決定できます。

状態を使用するワークフロー・プロセスを作成するとき、アセットをその状態に移動するステップをユーザーが実行したときにその状態の予測時間を変更(オーバーライド)できるかどうかを指定します。

期限が変更可能な場合、その実行を禁止する機能権限を構成しないかぎり、ステップを実行する参加者は誰でもその期限をオーバーライドできます。ワークフロー・プロセスに対して管理者ロールとして指定されたロールを持つ参加者は誰でも割当て期限をいつでもオーバーライドできます(その期限が変更可能である場合)。

ワークフロー・プロセスを作成するときに、プロセスの期限を設定可能かどうかを決定します。プロセスの期限は、アセットがワークフローに最初に配置されるときに「ワークフローの選択」フォームで設定します。ただし、割当て期限とは異なり、プロセスを構成してプロセスの期限が近づいたときに通知電子メールを送信することはできません。

プロセスの期限を設定可能な場合、その実行を禁止する機能権限を構成しないかぎり、ワークフローにアセットを配置する参加者は誰でもそのアセットのプロセスの期限を設定できます。さらに、ワークフロー・プロセスに対して管理者ロールとして指定されたロールを持つ参加者は誰でもプロセスの期限をいつでも設定できます(期限が設定可能である場合)。

18.1.11 期限計算のスケジュール

次の2種類のアクションがあります。

- ステップによってコールされるアクション。これらのアクションは、ステップが実行されるときにWebCenter Sitesによって完了されるイベントです。

- 期限によってトリガーされるアクション。これらのアクションは、キューに入れられており、WebCenter Sitesによってそのアセットの期限が計算され、どの時間指定アクション(存在する場合)をコールするか決定された後にのみトリガーされます。

時間指定アクション・イベントを構成することで期限の計算頻度を指定します。これは、すべての期限のバックグラウンド計算プロセスを呼び出すイベントです。これは、バックグラウンド承認計算プロセスを呼び出すパブリッシュ・イベントと同様です。

パブリッシュ・プロセスによって承認が計算されてどのアセットをパブリッシュするのかが決定されるのと同様に、時間指定アクション・イベントによってコールされる期限計算プロセスによってワークフロー・プロセスに参加しているすべてのアセットに対する期限が計算され、割当て期限について通知メッセージを送信するかどうかが決定され、アセットに対して割当てリストの「期限」および「プロセスの期限」列に表示される時間が決定されます。

管理システム上で「時間指定アクション・イベント」を構成し、必要な回数だけ実行できます。

18.1.12 ワークフロー・プロセスの終了

ワークフロー・プロセスは、アセットが進む先の状態がなくなったときに終了します。これは、最後の参加者がワークフロー・プロセスの終了ステップを実行したときに起こります。

終了ステップは、開始状態はあるが終了状態はない開始ステップの反対です。ユーザーが終了ステップを実行すると、それはステートレス状態に移動します。これはアセットがすでにワークフロー内にはないことおよび、そのワークフロー・プロセスに対して設定されている機能権限が適用されなくなったことを意味します。

18.2 ワークフロー・プロセスの計画

ワークフロー・プロセスを作成するときは、そのプロセスの状態をつなぎ合わせるステップを作成します。ワークフロー・プロセスを作成する前に、自身または他の人がワークフロー・コンポーネント(ロール、電子メール・メッセージ、各種アクション、ステップ条件、および状態)を作成する必要があります。

この項では、ワークフロー・プロセスを計画および実装できるように、各ワークフロー・コンポーネントの構成を詳しく説明します。ワークフロー・プロセスを計画するには、次を実行します。

- スケッチからの開始

- ロールと参加者の決定

- 電子メール・オブジェクト、アクションおよび条件の決定

- 状態の決定

- ステップの決定

- 機能権限の決定

- 追加のワークフロー・プロセスの詳細の決定

18.2.1 スケッチからの開始

どこから始めますか。ワークフロー・プロセスとして実装する必要があるビジネス・プロセスの次のようなスケッチからです。

- ボックスを使用して、状態を表します。

- 矢印を使用して、状態を接続するステップを表します。

この項の説明を読みながら、スケッチに、そのプロセス内の各状態またはステップに対してどのロール、アクション、条件、期限などが適切であるかについて詳細を書き込みます。

次に、ワークフロー・プロセスの構成の説明のように管理者のインタフェースを使用しながらスケッチを参照してワークフロー・プロセスを作成します。

18.2.2 ロールと参加者の決定

ワークフロー・プロセスの計画を開始する際は、まずロールから始めます。ワークフローにはどのような種類の機能グループが参加しますか。次に、それらのロールの個々のユーザーがどのように特定のアセットのワークフロー・プロセスの参加者になるのかを決定します。

プロセスに対して作成する必要があるロールを決定するには、自分自身に次の質問を問いかけます。

- WebCenter Sites管理システムを使用しているコンテンツ・プロバイダの役職またはロールは何か。

- 各ロールの人々は何を実行するか。(彼らが実行するタスクを状態にマッピングできます。)

- ロールはどのように編成されているか。たとえば、サブジェクト別に編成されたコンテンツ・プロバイダからなるいくつかのグループ(たとえば、スポーツ・ライター、ファイナンシャル・ライター、マーケティング・ライターなど).以外に、すべてをレビューするレビューアのグループが1つがありますか。

- 特定のグループの人々は特定のアセット・タイプの作業を行い、それ以外のタイプの作業は行わないのか。その場合、どのロールが、ワークフロー・プロセスを作成する予定の各アセット・タイプに対するアクセス権を持つようにしますか。

- ワークフローに参加していない人に、ワークフロー内のアセットのステータスに関して通知する必要があるか。その場合、ステップまたは時間指定アクションによってその人に電子メール・メッセージを送信できるように、その人にはロールが必要です。

ワークフロー・プロセスのスケッチで、各状態でアセットを割り当てるロールの名前を書き込みます。

ロールの作成の詳細は、ACLおよびロールの使用を参照してください。

ワークフロー・プロセスを構成するとき、ワークフローを通過する個々のアセットごとにどの特定のユーザーがそのワークフローに参加するのかを決定するにはいくつかの方法があります。

- ワークフローを割り当てるとき。
最初にワークフローをアセットに割り当てる人が、参加予定のすべてのユーザーを選択する必要があるように、プロセスを構成できます。彼らは、各状態についてリストからユーザーを選択します。このリストには、その状態に対して適切なロールを持つすべてのユーザーが含まれています。

- 参加者がその割当てを終了するとき。
各参加者が、その割当てを終了するときに次の参加者を誰にするのか決定するようにプロセスを構成できます。その参加者は、次の状態に対して適切なロールを持つすべてのユーザーを含むリストからユーザー名を選択します。

このステップを構成するときに参加者をどのように選択するのかを指定します。

サイト間でアセットを共有することができます。共有されているアセットがワークフロー・プロセスに入る場合、そのアセットへのアクセス権を持つ、すべてのサイトのユーザーをそのワークフローに参加する候補者と見なす必要がありますか。見なす必要がある場合は、サイト間割当て機能を有効にします。

サイト間割当て機能を使用すると、ユーザーが現在どのサイトにログインしているのかに関係なく、そのユーザーに対して、彼らがアクセス権を持つすべてのサイトから彼らへのすべての割当てが彼らの割当てリストに表示されます。1つの統合された割当てリストを持つことは、ユーザーにとって大変便利です。

ただし、ユーザーがサイトによって異なるロールを持っていて、ワークフロー・プロセス内で機能権限が使用されていると、彼らはその割当てリストに表示されているアセットに対して作業できない場合があることに注意してください。たとえば、ユーザーの中に1つのサイトでは作成者ロールを持っていて、別のサイトでは編集者ロールを持っている人がいるとします。機能権限を使用して編集作業を特定のサイトの編集者に制限すると、作成者として機能するサイトに彼らがログインしたときにその割当てリストに編集を許可されていないアセットが表示されることがあります。

この機能を有効化するには、xcelerate.crosssiteassignプロパティの値をtrueに設定します。このプロパティは wcs_properties.jsonファイルにあります(「UI」カテゴリ)。プロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

18.2.3 電子メール・オブジェクト、アクションおよび条件の決定

アクションは、次の3つのうちのいずれかの方法でトリガーされるイベントです。

- ステップがコールする(ステップ・アクション)。

- 期限がトリガーする(時間指定アクション)。

- ワークフローの状況がトリガーする(デッドロック、グループ・デッドロック、および委任アクション)。

条件は、ステップが試みられるときに評価されるイベントです。条件が満たされない場合、そのステップは完了できません。

アクションまたは条件を作成するときは、エレメントを識別します。エレメントは、ElementCatalog表に格納されている名前の付いたコードの断片です。アクションによって表される機能を呼び出すのがエレメントです。変数または引数を取るようにエレメントをコード化する場合は、アクションを作成するときにそれらの値を識別します。すると、それらの変数はアクションがトリガーされたときにそのエレメントに渡されます。

管理者は、エレメントのコード化を担当しません。提供されたデフォルト・ワークフロー・エレメントでワークフロー要件を満たせない場合は、開発者が必要な機能をコード化できます。ワークフローのカスタマイズの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

WebCenter Sitesには、次のデフォルト・ワークフロー・エレメントが用意されています。

表18-1 ワークフロー・エレメントの名前と期待される変数

エレメント名

期待される変数

OpenMarket/Xcelerate/Actions/Workflow/ StepActions/ApproveForPublish

target

アセットを承認する対象となるパブリッシュの宛先の名前。

OpenMarket/Xcelerate/Actions/Workflow/ StepActions/SendEmailToAssignees

emailname

送信する電子メール・オブジェクトの名前。

OpenMarket/Xcelerate/Actions/Workflow/ StepConditions/ExampleStepCondition

OpenMarket/Xcelerate/Actions/Workflow/ AssignmentActions/SendEmail

emailname

送信する電子メール・オブジェクトの名前。

OpenMarket/Xcelerate/Actions/Workflow /DeadlockActions/SendEmailToAssignees

emailname

送信する電子メール・オブジェクトの名前。

OpenMarket/Xcelerate/Actions/Workflow/ GroupActions/SendEmailToAssignees

emailname

送信する電子メール・オブジェクトの名前。

これらのエレメントの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

ApproveForPublishとExampleStepConditionを除いて、これらのエレメントはemailnameという変数を取り、その変数によって識別される電子メール・メッセージを送信します。

ワークフロー電子メール・オブジェクトを作成して、emailname変数の値を決定します。「管理」タブで作成する電子メール・オブジェクトの名前は、電子メール・メッセージを送信するアクションで、emailname変数の引数として指定する名前です。

この項の内容は次のとおりです。

- 電子メール・オブジェクトの理解

- 時間指定アクションの理解

- 委任アクションの理解

- ステップ・アクションの理解

- ステップ条件の理解

- デッドロック・アクションの理解

- グループ・デッドロック・アクションの理解

18.2.3.1 電子メール・オブジェクトの理解

電子メール・オブジェクトは、アクションから切り離されている構築ブロックであるため、複数のアクションで使用できます。たとえば、デフォルト・デッドロック・アクションおよびデフォルト・グループ・デッドロック・アクションでは同じ電子メール・メッセージ(デッドロック・メッセージという名前)が使用されます。

電子メール・オブジェクトは、名前、説明、件名の行、本文テキストを指定することで作成します。メッセージが送信されるときに、件名に指定したテキストが件名の行に配置され、本文に指定したテキストがメッセージの本文に配置されます。

件名の行および本文テキストで使用でき、受信者ごとにパーソナライズされた電子メール・メッセージの作成を容易にするいくつかのワークフロー電子メール変数があります。次の表に、どの電子メール・メッセージでも使用できるデフォルト・ワークフロー変数をリストします。

表18-2 デフォルト・ワークフロー変数

変数名

説明

Variables.assetname

アセットの名前。

この変数は、すべての電子メール・メッセージで使用します。それにより、受信者はどのアセットについて述べているのかがわかります。

Variables.assigner

電子メールを受信する人にアセットを割り当てた参加者のユーザー名。

この変数は、参加者に新しいアセットが割り当てられたことを通知するステップ・アクションの電子メール・メッセージで使用します。

Variables.time

状態について「予測時間」フィールドで指定される時間。

この変数は時間指定アクションに対して使用します。

Variables.instruction

前の参加者がその割当てを終了したときに「割当ての終了」フォームの「実行するアクション」フィールドに入力したテキスト。

この変数は、参加者に新しいアセットが割り当てられたことを通知するステップ・アクションの電子メール・メッセージで使用します。

カスタム電子メール変数の例については、デッドロック・メッセージという名前の電子メール・オブジェクトとOpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/ SendEmailToAssigneesという名前の対応するデッドロック・アクション・エレメントを参照してください。

次は、デフォルトのワークフロー電子メール・オブジェクトです。

- 割当て期限リマインダ: アセットおよびその期限を指定します。

- 割当てメッセージ: アセット、そのアセットを割り当てた人、および「割当ての終了」フォームの「実行するアクション」ボックスのメッセージを指定します。

- デッドロック・メッセージ: ユーザーおよびユーザーが実行したステップをリストすることで、デッドロックがどのように発生したのかを説明します。

- 拒否メッセージ: 割当てメッセージと同様ですが、アセットが前の参加者(割当て者)によって拒否されたことが示されています。

作成する必要がある電子メール・オブジェクトを判別するには、オブジェクトに保持される電子メール・メッセージを送信するアクションも決定する必要があります。件名および本文の中で電子メール変数を使用することで、同じ電子メール・オブジェクトを複数の時間指定アクションまたはステップ・アクションで使用できる可能性があります。

通常、次の種類のものを指定する電子メール・メッセージを作成します。

- 参加者にアセットが割り当てられたこと。(ステップ・アクションの場合。)

- 新しい参加者にアセットが委任されたこと。(委任アクションの場合。)

- アセットの期限が近づいていること。(時間指定アクションの場合。)

- アセットの期限が過ぎていること。(これも時間指定アクションの場合。)

- アセットがデッドロックの状態であること。(デッドロック・アクションの場合。)

- アセットのグループがデッドロックの状態であること。(グループ・デッドロック・アクションの場合。)

「管理」タブで、「電子メール」をダブルクリックします。デフォルトの電子メール・オブジェクトを調査し、それらを使用できるかどうかを確認します。デフォルト・メッセージを変更するか、独自の電子メール・メッセージを作成できます。ワークフロー・プロセスのスケッチの1つの隅に、そのワークフローに必要な電子メール・メッセージをリストします。

18.2.3.2 時間指定アクションの理解

時間指定アクションは、状態の期限に基づいたアクションです。状態に対して期限を指定する場合、期限について参加者に通知するために時間指定アクションを指定できます。

時間指定アクションを作成するには、名前と説明を指定し、エレメントを指定し、必要に応じてそのエレメントに引数値を指定します。

期限に関する電子メール通知を送信する時間指定アクションを作成するには、OpenMarket/Xcelerate/Actions/Workflow/AssignmentActions/SendEmailエレメントを指定し、「引数」フィールドを使用して、どの電子メール・メッセージを送信するのかを指定します。

状態を作成する場合は、どの時間指定アクションを使用するのかと、それらをいつトリガーするのかを状態に指定された期限を基準にして指定します。各状態に複数の時間指定アクションを指定できます。

時間指定アクション・イベントが実行されて、現在ワークフローに参加しているすべてのアセットの期限が計算されると、適切な時間指定アクションがトリガーされます。

デフォルトの時間指定アクションが1つあります。「電子メールの送信」です。これは、OpenMarket/Xcelerate/Actions/Workflow/AssignmentActions/SendEmailエレメントを使用して、割当て期限リマインダ電子メール・メッセージを送信します。

時間指定アクションを計画する場合、次のワークフロー・コンポーネントも考慮する必要があります。

- 作成する状態。これらのアクションは、状態に対して設定する期限に関連してトリガーされるためです。

- 作成する必要がある電子メール・オブジェクト。時間指定アクションによって電子メール・メッセージが送信される可能性があるためです。

時間指定アクションがトリガーされる時間は、アクション自体の外部で決定される(管理者が状態のフォーム内で行う)ため、少数の汎用時間指定アクション(それらによって送信される電子メール・メッセージのみが異なる)を作成し、それらを複数の状態で繰り返し使用できる可能性があります。

「一般的な管理」ツリーで、「ワークフロー」ノードを開き、「アクション」、続いて「時間指定アクション」を開きます。「電子メールの送信」アクションを調査し、それらを使用できるかどうかを確認します。デフォルト時間指定アクションを変更するか、独自のものを作成できます。

ワークフロー・プロセスの各スケッチで、電子メール・メッセージのリストの近くに、そのプロセスに必要な時間指定アクションをリストします。

18.2.3.3 委任アクションの理解

ワークフロー・プロセスに委任アクションを割り当てると、そのアクションは参加者(またはワークフロー管理者)が割当てを別の参加者に委任するたびにトリガーされます。

委任アクションを作成するには、名前と説明を指定し、エレメントを指定し、必要に応じてそのエレメントに引数値を指定します。

ワークフロー・プロセスごとに1つの委任アクションを指定できます。用意されているデフォルト委任アクションはありません。

委任アクションによって、割当ての委任先の参加者に電子メール・メッセージが送信される可能性があります。その場合、電子メールを送信するデフォルト・ワークフロー・エレメントのいずれかを使用する委任アクションを作成し、そのエレメントが送信する新しい電子メール・オブジェクトを作成できます。

ワークフロー・プロセスのスケッチごとに、そのプロセスに使用する委任アクションの名前を書き込みます。(プロセスごとに1つ割り当てることができます。)

18.2.3.4 ステップ・アクションの理解

ステップにステップ・アクションを割り当てると、参加者がそのステップを実行するときにそのアクションがトリガーされます。

ステップ・アクションを作成するには、名前と説明を指定し、エレメントを指定し、必要に応じてそのエレメントに引数値を指定します。

ステップ・アクションには一般的なカテゴリが2つあります。機能を完了するカテゴリと、そのステップによってアセットを割り当てられる参加者に電子メール・メッセージを送信するカテゴリです。

ステップ・アクションは、機能権限に関係なく実行されます。つまり、WebCenter Sites機能を実行するステップ・アクションを作成した場合、そのアクションによってそのステップを実行する参加者の機能権限がチェックされることはありません。ユーザー・インタフェースから機能へのアクセスを制限し、参加者に特定の機能(たとえば、パブリッシュ用の承認)を実行するためにワークフロー内のステップを使用するように要求できます。

各ステップに1つ以上のステップ・アクションを指定できます。

デフォルトのステップ・アクションは次のとおりです。

- パブリッシュの承認: OpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublishエレメントを使用してアセットを承認します。その後、次にパブリッシュ・プロセスが実行されたときに、アセットがパブリッシュされます(その依存性もすべて承認されている場合)。
ワークフロー・プロセスにこのアクションを使用するには、targets引数を使用することで、アセットを承認する対象となるパブリッシュの宛先を指定する必要があります。

- 割当て電子メールの送信: OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssigneesエレメントを使用して割当てメッセージ電子メール・オブジェクトを、そのアセットを割り当てられているすべての参加者(つまり、そのステップの「割当て方法」で指定されている人々)に送信します。

- 拒否電子メールの送信: OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssigneesエレメントを使用して、拒否メッセージ電子メール・メッセージを新しい割当て先(そのステップの「割当て方法」で指定されている参加者)に送信します。

作成する必要があるステップ・アクションの種類を判別するには、次のワークフロー・コンポーネントを考慮する必要があります。

- プロセスに対して作成するステップ。人々は、ステップによってアセットが割り当てられたことを通知される必要があるでしょうか。その必要がある場合、電子メール・メッセージを送信するステップ・アクションが必要です。

- ステップによってアセットが移動される先の状態。状態は、機能の完了後のアセットを表しますか。表す場合、その機能を実装するステップ・アクションが必要です。

「ワークフロー」タブで、「アクション」を選択し、次に「ステップ・アクション」を選択します。これらのアクションを調査し、それらを使用できるかどうかを確認します。デフォルトのステップ・アクションを変更することも、独自のものを作成することもできます。

ワークフロー・プロセスのスケッチごとに、適切なステップの横にそのステップ・アクションの名前を書き込みます。各ステップに1つ以上のステップ・アクションを割り当てられます。

18.2.3.5 ステップ条件の理解

ステップにステップ条件を割り当てると、そのステップが実行されるときにその条件が評価されます。その条件によって、そのステップを完了できるかどうかが決定されます。

ステップ条件を作成するには、名前と説明を指定し、エレメントを指定し、必要に応じてそのエレメントに引数値を指定します。ワークフロー・プロセスで条件を使用するには、開発者にそのエレメントを通して実装する必要があるという条件について伝えてください。

各ステップに1つ以上の条件を指定できます。

デフォルトのステップ条件が1つあります。サンプル・ステップ条件です。これは、条件をチェックするためのエレメントのコード化方法を示すhello worldスタイルの例です。管理者および開発者は、それを調査してその動作を把握し、その後、開発者が独自の条件エレメントを作成する必要があります。

ステップ条件について検討するときは、ステップと状態を考慮する必要があります。ワークフロー・プロセスに条件が必要であると判断した場合は、開発者にそれらを作成するように依頼します。

ワークフロー・プロセスのスケッチごとに、適切なステップの横に必要なステップ条件の名前を書き込みます。

18.2.3.6 デッドロック・アクションの理解

デッドロックになる可能性があるステップにデッドロック・アクションを割り当てると、そのアクションはそのステップ中にアセットがデッドロックになるたびにトリガーされます。

デッドロック・アクションを作成するには、名前と説明を指定し、エレメントを指定し、必要に応じてそのエレメントに引数値を指定します。

各ステップに1つ以上のデッドロック・アクションを割り当てられます。

デフォルトのデッドロック・アクションが1つあります。デッドロック電子メールの送信です。これは、OpenMarket/Xcelerate/Actions/Workflow/DeadlockActions/SendEmailToAssigneesエレメントを使用して、デッドロック・メッセージ電子メール・メッセージを送信します。

使用する可能性があるデッドロック・アクションについて検討する場合は、ワークフロー・プロセスに対して作成するステップを考慮する必要があります。デッドロックが発生しないようにステップを設計する予定である場合は、デッドロック・アクションを作成する必要はありません。

「ワークフロー」タブで、「アクション」を開き、次に「デッドロック・アクション」を開きます。このアクションを調査し、それを使用できるかどうかを確認します。デフォルトのデッドロック・アクションを変更するか、独自のものを作成できます。

ワークフロー・プロセスのスケッチで、デッドロックになる可能性があるステップの横に適切なデッドロック・アクションの名前を書き込みます。

18.2.3.7 グループ・デッドロック・アクションの理解

グループ・デッドロック・アクションは、ワークフロー・グループがデッドロックになったときにトリガーされます。ワークフロー・グループの作成者が、グループ・デッドロック・アクションを選択します。グループごとに1つ以上のアクションを選択できます。

グループ・デッドロック・アクションは、そのワークフロー・プロセスの状態またはステップと関連付けられた他のアクションに追加してコールすることができます。デフォルトのグループ・デッドロック・アクションが1つあります。デッドロック電子メールの送信です。これは、デフォルト・デッドロック・アクションと同一です。

デッドロック・アクションの場合と同じ考慮事項が、グループ・デッドロック・アクションの場合にも適用されます。ただし、ワークフロー・グループに対してグループ・デッドロック・アクションを選択するのはコンテンツ・プロバイダであるため、グループ・デッドロック・アクションには必ず意味のある明確な名前を付けてください。

18.2.4 状態の決定

状態を作成するときは、次の種類の情報を指定します。

- 名前と説明。状態の名前は意味のあるものとし、かつアセットがその状態にある間に実行される作業の種類を表す必要があります。

- この状態にアセットが留まっている時間の長さ(「予測時間」)。期限は、アセットがその状態になってからの時間数または日数について計算されます。
予測時間(期限)は、特定の日付ではなく、時間数または日数で設定することに注意してください。これは、状態の期限はアセットが状態を通過するときに各アセットに対して計算されるためです。

- 起動される必要がある時間指定アクションおよびそれが起動されるタイミング。期限前または期限後の日数または時間数で示します。

すべてのサンプル・サイトで提供されているサンプルの状態はありますが、デフォルトの状態はありません。サンプル・サイト状態がどのように構成されているのかを調査するには、サンプル・サイトがインストールされているシステム上で、「ワークフロー」を選択し、次に「状態」を選択して状態を選択してください。

作成する必要がある状態を決定するには、自分自身に次の質問を問いかけます。

- 各状態に参加するのはどのロールか。スケッチで、状態の横にロールの名前を書き込みます。

- これらの状態の中に、複数のアセット・タイプに適用されるものがあるか。その場合、同じ状態を複数のワークフロー・プロセスに再利用できる可能性があります。

- 各状態を完了するためにどれくらいの時間がかかるか。

- この時間の長さは、アセット・タイプまたはサイトによって異なるか。異なる場合は、同じ状態を複数のワークフロー・プロセスで再利用したり、ワークフロー・プロセスを別のサイトと共有することはできません。

- 期限がある場合、期限が近づいたときにWebCenter Sitesから参加者に通知する必要があるか。その場合、それはいつですか。前日ですか。数時間前ですか。そして、どの時間指定アクション(これにより、どの電子メール・メッセージかが決定される)を使用する必要がありますか。

- 期限を過ぎたときに通知する必要があるか。その場合、それはいつですか。そして、どの時間指定アクションを使用する必要がありますか。

ワークフロー・プロセスのスケッチで、各状態の横にこの情報をすべてリストします。

目的によっては、実際には終了しないワークフロー・プロセスの作成を検討します。たとえば、Hello Asset Worldサンプル・サイト・ワークフロー・プロセスは、HelloArticleアセットが承認された後に終了します。ただし、このような場合、誰かが誤ってアセットを開いて保存する可能性があり、それはそのアセットがこの先承認されることはなくなり、パブリッシュされないことを意味します。

承認されてからパブリッシュされるまでにアセットが編集されないようにするには、承認後にアセットを保持する最終状態を作成し、その状態にすべての人にアセットの編集を禁止する機能権限を設定します。

このような状態を作成する場合は、そのアセットをワークフロー内の編集中状態に戻すことができるステップを作成し、意図的にそれを編集できるようにしてください。

18.2.5 ステップの決定

ステップをプロセス内に作成します。これらのステップを使用して、状態をつなぎ合わせます。これが、実際にプロセスを作成する方法です。

プロセス内のステップごとに次の種類の情報を指定します。

- ステップの名前。名前は意味があるものとし、進むパスを説明するものにする必要があります。たとえば、レビューのための送信、承認のための送信などです。

- 開始状態。ステップによってアセットが移動される前の状態です。ステップに開始状態がない場合、それはワークフロー・プロセスを開始する開始ステップです。開始状態は、開始ステップ以外の各ステップに必要です。

- 終了状態。ステップによってアセットが移動された後の状態です。ステップに終了状態がない場合、それはワークフロー・プロセスを終了する終了ステップです。

- ステップに対してどのロールが認可されるのか。
これが最初のステップである場合、指定するロールによって、アセットに対してこのワークフローを選択できるユーザーが決定されます。スタート・メニュー・アイテムを使用して、アセットにワークフロー・プロセスを割り当てる場合、この最初の(開始)ステップに割り当てるロールが、スタート・メニュー・アイテムに割り当てられているロールに必ず一致するようにしてください。

最初の(開始)ステップの後の後続のステップについては、選択したロールは、前のステップによって通知されるように選択されたロールに一致するかそのロールのサブセットである必要があります。それ以外の場合、そのアセットに割り当てられている誰もそれを次の状態に移動することを許可されていないため、そのアセットはその状態から移動できません。

- そのアセットを次に取得するのは誰か。(次＝このステップが完了したとき)。次の割当て方法のいずれかを選択することで終了状態の割当て先を指定します。

- 割り当てられたユーザーを「開始状態」に維持。
このオプションは、その現在の割当て先(このステップを完了するユーザー)にアセットを割り当てます。

このオプションは、同じ状態に戻る(反復状態を作成する)ステップを作成する場合、またはそれが開始ステップであり、そのアセットを(スタート・メニュー・アイテムを使用するか、「ステータス」フォームでそれを選択することによって)ワークフロー・プロセスを選択した人に割り当てる場合に便利です。

- 割当てなし、機能privsを使用したアクションの制御。
このオプションは、ワークフロー・プロセス内にアセットを保持します。つまり、機能権限が適用されますが、アセットは実際は誰にも割り当てられません。

注意:

アセットが現在の割当て先に割り当てられているとき(「割り当てられたユーザーを「開始状態」に維持」オプション)または誰にも割り当てられていないとき(「割当てがありません」オプション)、ワークフロー・システムによってそのステップのワークフロー履歴が記録されます。

- 参加者リストからの割当て。
このオプションでロールを選択します。ユーザーがアセットにワークフロー・プロセスを割り当てると、選択したロールを持つユーザーのリストが表示されます。ユーザーがリストから1人以上のユーザーを選択すると、このステップによってアセットが移動された先の状態になったときにそれらのユーザーにそのアセットが割り当てられます。

- ステップ実行時に割り当てられるユーザーを選択。
このオプションでもロールを選択します。このオプションは、ワークフロー・プロセス中に(割当てを完了することで)このステップを実行する人が、次にこのアセットが割り当てられるユーザーを、このステップ用に選択されたロールを持つユーザーのリストから選択することを意味します。

- このステップがアセットを移動する先の状態に対する予測時間を変更できるかどうか。(割当て期限と呼ぶ。)

- 実行される必要があるすべてのステップ・アクション。

- 評価する必要があるすべてのステップ条件。

- ステップを複数のユーザー(割当て先)が実行できる場合、アセットが次の状態に移動するにはすべての割当て先がこのステップを実行する必要があるかどうか。(「割り当てられたすべてのユーザーが投票する必要あり」フィールド。)

- ステップがデッドロックになる可能性がある場合、どのようなデッドロック・アクションにする必要があるかどうか。

- このプロセスがワークフロー・グループに対して使用される場合、アセットのいずれかが次の状態に移動するには、そのグループ内のすべてのアセットがこのステップを完了する必要があるかどうか。(「ステップをグループ単位で同期」フィールド。)

すべてのサンプル・サイト・ワークフロー・プロセスにサンプル・ステップがあります。サンプル・サイトがインストールされているシステム上で、「ワークフロー」を選択し、次に「プロセス」を選択し、プロセスを調査して、そのサンプル・ワークフロー・ステップがどのように構成されているのかを把握します。

ステップをどのようなものにするか決定するときは、次の質問を考慮します。

- すべてのプロセスに開始ステップが必要です。開始ステップを作成する前に、最初にアセットをどのように作成するのかを決定してからワークフローに配置します。
最初の参加者がアセットを作成し、それをワークフローに配置し、そしてそのアセットの作業を続けますか。その場合は、開始ステップを実行する人にそのステップが割り当てられるようにステップを構成(「割り当てられたユーザーを「開始状態」に維持」オプションを選択)し、デフォルトでそのアセットにそのワークフローを割り当てるスタート・メニュー・アイテムを必ず作成します。

または、スーパーバイザがアセットを作成し、それを参加者に割り当てますか。その場合は、開始ステップを実行する人が割当て先を選択する必要があるように開始ステップを構成します。

- 状態の順序はどのようにしますか。

- 各状態の間に必要なパスの数はいくつですか。この答えによって必要なステップ数が決定します。

- 反復状態を作成する必要がありますか。その場合は、ステップを実行している人にそれが割り当てられるように、その状態にアセットを戻すステップを構成します(「割り当てられたユーザーを「開始状態」に維持」オプションを選択します)。

- 複数の人がそのアセットに対して作業している状態からアセットを移動するステップの場合に、ステップを実行する前に、それらの参加者全員が彼らの割当てを完了する必要がありますか。その場合は、すべて投票ステップになるようにそのステップを構成します。

- アセットに、1つの状態から実行可能なパスが複数ありますか。(つまり、同じ開始状態を持つ複数のステップにする必要がありますか。)その必要がある場合、その状態からのいずれかのステップで、そのアセットが進む前にすべての参加者が同じように投票する必要がありますか。その場合は、すべての参加者が同じように投票することを必要とするステップは、その状態から導かれるステップのうちの1つのみになるようにプロセスを設計してください。同じ状態からのすべて投票ステップが2つあると、デッドロックが発生する可能性があります。

- ステップごとに、ステップが完了してアセットが次の状態に進むときに、影響を受ける参加者にWebCenter Sitesから通知する必要がありますか。その必要がある場合、そのステップでどのステップ・アクション(これにより電子メール・メッセージが決定される)を使用する必要がありますか。

- 関連付けられたアセットのグループは同時に作業する必要がありますか。その場合、1つのアセットとアセットのグループの両方に対して適切に機能するようにステップを構成できますか。できない場合、ワークフロー・グループに対して個別のワークフロー・プロセスを作成します。

- ワークフロー・グループに対して、そのグループ内のすべてのアセットが、同時に入る必要がある状態がありますか。(すべてのアセットが同時に承認される必要があるなど。)その場合は、同期ステップになるようにそのステップを構成します。ワークフロー・プロセスごとに同期ステップを1つのみ持つようにすることをお薦めします。

- 結局、アセットをパブリッシュしないことに決定した場合、そのアセットはどのようになりますか。取消しステップを設定する必要がありますか。必要な取消しステップの数はいくつですか。

ワークフロー・プロセスのスケッチで、ステップを表すボックスの右横に、ステップ・アクション、そのステップを実行できるロール、ステップが実行されるときに通知される必要があるロール、ステップがすべて投票ステップであるかどうか、およびステップが同期ステップであるかどうかをリストします。

18.2.6 機能権限の決定

管理者は、指定のサイトに対して機能(作成や編集など)を使用する権限をロールに付与または拒否します。権限が付与されると、それらのロールを持つサイト・ユーザーにその機能が表示されます。ユーザーは、アセットが権限によって指定されている状態になったときに、その機能をコールすることができます。(デフォルトでは、機能権限は、指定のサイトのすべてのロールに付与されています。)

機能権限は、必要に応じてワークフロー・プロセスの機能ごとに設定できます。機能権限の設定の詳細は、(オプション)ワークフロー・プロセスの機能権限の構成に記載されています。

次の表に、ワークフロー・プロセス中の実行をユーザーに許可または拒否できる機能をリストします。

表18-3 機能および許容されるユーザー処理

機能

機能権限が付与されている場合

投票の棄権

ユーザーは、ワークフロー・ステップで投票しないことを選択できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・メニューにオプションとして表示されます。

パブリッシュの承認

ユーザーは、アセットをパブリッシュ用に承認済として選択できます。

アセットの「調査」および「ステータス」フォームの「詳細」ドロップダウン・メニューのオプションとして表示されます。

認可

ユーザーは、アセットに権限を構成できます。

作成

ユーザーは、コレクション・アセットを作成できます。

アセットの「調査」および「ステータス」フォームの「詳細」ドロップダウン・メニューのオプションとして表示されます。

チェックアウト

ユーザーは、そのアセット・タイプに対してリビジョン追跡が有効化されている場合、アセットをチェックアウトできます。

アセットの「編集」および「ステータス」フォームの最上部にある「チェックアウト」ボタンとして表示されます。

コピー

ユーザーは、アセットをコピーできます。

アセットの「調査」および「ステータス」フォームの「詳細」ドロップダウン・メニューのオプションとして表示されます。

割当ての委任

ユーザーは、アセット(自分自身に割当て済)を別のユーザー(アセットがその状態にある間そのアセットに対して適切なロールを持っている)に委任できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストにオプションとして表示されます。

削除

ユーザーは、アセットを削除できます。

アセットの「調査」および「ステータス」フォームのアクション・バーにアイコンとして表示されます。リスト内のアセットの横にあるアイコンとしても表示されます。

編集

ユーザーは、アセットをその「編集」フォームで開くことができます。

アセットの「調査」および「ステータス」フォームのアクション・バーにアイコンとして表示されます。リスト内のアセットの横にあるアイコンとしても表示されます。

調査

ユーザーは、アセットをその「調査」フォームで開くことができます。

注意: アセットを調査する権限のないユーザーは、そのアセット・タイプに特有のデータを表示できません。かわりに、標準の無制限のフィールド(名前、説明、IDなど)のみを表示する「調査」フォームの制限されたバージョンが表示されます。

翻訳のルートの作成

ユーザーは、アセットを翻訳のマスター・アセットとして設定できます。(多言語アセットにより使用されます。)

多言語アセットの「調査」フォームの「翻訳」フィールドの「マスターの作成」リンクとして表示されます。

ページの配置

ユーザーは「サイト・プラン」タブでページを配置できます。

ユーザーが「「配置済ページ」」を右クリックしたときに、「「サイト・プラン」」タブのコンテキスト・メニューのオプションとして表示されます。

プレビュー

ユーザーは、そのページのコンテキストでアセットを表示できます。

アセットのツールバーの「プレビュー」アイコンとして表示されます。

グループからの除去

ユーザーは、ワークフロー・グループからアセットを削除できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストにオプションとして表示されます。

ワークフローからの除去

ユーザーは、ワークフロー・プロセスからアセットを削除できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストにオプションとして表示されます。

ロールバック

ユーザーは、アセットを以前のバージョン(すべてリビジョン追跡システムに格納されている)のいずれかに戻すことができます。

注意: この機能は、リビジョン追跡が有効化されており、少なくともそのアセットの2つのバージョンが存在している場合に、アセットの「編集」および「ステータス」フォームの最上部にある「ロールバック」ボタンとして表示されます。

エクスポート先パス/ファイル名の設定

ユーザーは、アセットの「新規」または「編集」フォームの「パス」および「ファイル名」フィールドに入力できます。

参加者の設定

ユーザーは、ワークフロー・プロセスの参加者を設定できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストにオプションとして表示されます。

さらに、この機能によって、ワークフロー・プロセスが構成されたときにユーザーは参加者を選択するように要求されます。このようにして、割当てを終了するユーザーは、次の参加者(そのアセットを割り当てられる人)を選択する必要があります。

プロセスの期限の設定

ユーザーは、それまでにワークフロー・プロセスを完了する必要がある日付と時刻を示す期限を設定できます。

注意: この機能は、ワークフローが、そのユーザーにプロセス期限の設定を許可するように構成されている場合にのみ表示されます。その場合、この機能は、アセットの「ワークフローの選択」フォームのオプションとして、およびワークフロー・グループが作成または編集されるときのオプションです。

割当て期限の設定

ユーザーは、それまでに次の状態を完了する必要がある日付と時刻を示す期限を設定できます。このオプションで設定される期限によって、そのワークフロー・プロセスでその状態に対して設定されている期限はすべてオーバーライドされます。

注意: この機能は、ワークフローが、そのユーザーに割当て期限の設定を許可するように構成されている場合にのみ表示されます。この機能は、アセットの「ワークフローの選択」フォームおよび「割当ての終了」フォームのオプションとして表示されます。

アセットの共有

ユーザーは、別のCMサイトとアセットを共有できます。

アセット・タイプが複数のCMサイトに対して有効化されている場合に、アセットの「編集」、「調査」および「ステータス」フォームの「詳細」ドロップダウン・メニューの「共有アセット」オプションとして表示されます。

参加者の表示

ユーザーは、現在アセットに割り当てられているワークフロー・プロセスの参加者のリストを表示できます。

アセットの「ステータス」フォームの「ワークフロー・コマンド」ドロップダウン・リストにオプションとして表示されます。

ステータスの表示

ユーザーは、アセットの「ステータス」フォームを表示できます。

アセットの「調査」および「ステータス」フォームの「詳細」ドロップダウン・メニューのオプションとして表示されます。

バージョンの表示

ユーザーは、リビジョン追跡システムに格納されているアセットの各バージョンに関する情報を表示できます。

リビジョン追跡がこのアセット・タイプに対して有効化されている場合、アセットの「編集」および「ステータス」フォームの最上部にある「バージョンの表示」ボタンとして表示されます。

ネスト・ワークフローの設定

ユーザーは、既存のワークフロー内にワークフローを作成できます。

注意: 管理者のインタフェースではネスト・ワークフローはサポートされていませんが、機能はタグの使用により取得できます。

翻訳

ユーザーは、マスター・アセットの翻訳を作成できます。(多言語アセットにより使用されます。)

「編集」、「調査」および「ステータス」フォームの多言語アセットの「詳細」ドロップダウン・メニューのオプションとして表示されます。

ワークフロー・プロセスごとに、アクセスを制限する機能、それらの機能を制限する期間となる状態、ロールに割り当てられているアセットがそれらの状態にあるときにそれらの機能にアクセスできるまたはできないロールを決定します。ワークフロー・プロセスのスケッチの適切な状態の横に、適用する制限をすべてリストします。

機能権限で目的の制限を適用するには、機能権限で状態に対して指定されているユーザーのロールが、ワークフロー・プロセスでそれらの状態と関連付けられているユーザーのロールに一致している必要があることに留意してください。それらのロールが一致しない場合、誰もそのアセットを状態から移動できない状況になる可能性があります。

また、特定のロールに対して機能へのアクセスを許可または制限する機能権限を1つでも作成する場合は、その機能に対して他のすべてのロールを対象とする機能権限を作成する必要があることにも留意してください。

機能権限は、ワークフロー・プロセスと関連付けられているため、アセットがワークフロー・プロセスに参加している場合にのみ、個々のユーザーのアクセスを特定の機能に制限できます。

ワークフロー・プロセスの設計および実装は行わないが、特定の機能に対するアクセス制御が必要な場合は何ができるでしょうか。1つの状態を持つ単純化されたワークフロー・プロセスを作成し、「割当てなし、機能privsを使用したアクションの制御」割当て方法を使用します。

ステップによって、「割当てがありません」の割当て方法を使用して、アセットをある状態に移動する場合、そのアセットは誰の割当てリストにも表示されません。単にその状態に留まり、それは、その状態に割り当てられている機能権限があればそれが適用されることを意味します。

18.2.7 単純化されたアクセス制御の実装

アクセス制御を実装するには:

1. 状態を作成します。名前と説明が必要です。期限や時間指定アクションは必要ありません。

2. 新しいワークフロー・プロセスを作成します。制限を適用するすべてのロールと、このワークフロー・プロセスを使用するすべてのアセット・タイプを選択します。

3. 1つのステップ(それらのタイプのアセットをその状態にする開始ステップ)を作成します。そのステップに対して、「割当てがありません」オプションを選択します。このタイプのアセットを作成できるようにして、かつこのワークフローの割当て先となるロールに対してそのステップを有効化します。

4. 作成したその状態のアセットに対して適用する機能権限を構成します。

5. そのアセット・タイプに対してこのワークフロー・プロセスを自動的に割り当てるスタート・メニュー・アイテムを作成します。スタート・メニュー・アイテムを使用できるロールが、ワークフロー・プロセスの開始ステップに割り当てられているロールと一致することを確認します。

これで、ユーザーが「新規」を選択し、アセット・タイプを選択すると、新しいアセットが自動的に単一状態ワークフローに入れられます。このワークフローにあるのは、そのタイプのすべてのアセットを単一の状態に配置する開始ステップのみであるため、これらのアセットはその状態から移動することはなく、機能権限が常に適用されます。

18.2.8 追加のワークフロー・プロセスの詳細の決定

ワークフロー・プロセスをスケッチし、アクション、条件、電子メール・メッセージ、状態、ステップ、および機能権限に関するすべての詳細を書き込んでいた場合、この時点までにワークフロー・プロセスの設計のほぼすべてを計画済です。

プロセスを作成するときの主要なタスクは、状態をつなぎ合わせるステップ(これがビジネス・プロセスを表す方法です)を作成することですが、ワークフロー・プロセスごとに次の種類の情報を指定することも必要です。

- その名前と説明。名前は内容を説明するものにして、ユーザーが適切なアセット・タイプに対して適切なワークフロー・プロセスを選択するようにする必要があります。

- どのサイトがそのプロセスを使用できるのか。

- どのアセット・タイプがそのプロセスを使用できるのか。

- どのロールが参加できるのか。これは、ステップ内で指定されているすべてのロールのスーパーセットです。

- どのロールがワークフローの管理者の役割を果たすのか。ワークフロー管理者は、他の参加者のかわりに割当てを委任できます。

- プロセス期限を、このワークフロー・プロセスに参加するアセットに対して設定可能かどうか。

- 委任アクションは何か。

- ステップは何か。ステップごとに、ステップの決定で説明する情報を指定します。

- 特定のロールのユーザーが特定の状態のアセットに作業する間、WebCenter Sitesのコンテンツ・アプリケーション機能のいずれかを彼らのみが実行できるように限定する必要があるかどうか。機能権限については、機能権限の決定で説明する情報を指定します。

18.3 ワークフロー・プロセスの構成

この項では、ワークフロー・プロセスのすべてのコンポーネントを作成する手順と、それらのコンポーネントをつなぎ合わせてワークフロー・プロセスにする手順について説明します。

電子メール・オブジェクト、アクション、および条件を作成したり、時間指定アクション・イベントをスケジュールするには、「「管理」」タブへのアクセス、つまり、GeneralAdminロールとxceladmin ACLが必要なことを忘れないでください。ワークフロー状態およびワークフロー・プロセスを作成するには、「「ワークフロー」」タブへのアクセスが必要です。

WebCenter Sitesのインタフェースのアクセス権の詳細は、ACLおよびロールの使用とユーザー、プロファイルおよび属性の構成を参照してください。

ワークフロー・プロセスを作成する前に、そのプロセスに必要な個々のワークフロー・コンポーネントを作成する必要があります。次に、実行する必要がある一般的な手順をその実行順に示します。

1. ワークフロー・プロセスを図に描いて計画します。この手順のヘルプは、ワークフロー・プロセスの計画を参照してください。描いた図やメモは、このトピックを通して参照してください。

2. ワークフロー・プロセスに必要なロールを作成します。この手順のヘルプは、ACLおよびロールの使用を参照してください。ワークフローに参加するユーザーに、ユーザー・プロファイルが作成されていることを確認します。作成されていない場合、ワークフロー・プロセスからの電子メール・メッセージを受信できません。

注意:

アセットを共有するすべてのサイトの人々を、ワークフローの参加者となる候補のユーザーのプールに含める場合、サイト間割当て機能を有効化してください。詳細は、ロールと参加者の決定を参照してください。

3. アクションに必要な電子メール・オブジェクトを作成し、wcs_properties.jsonファイルのxcelerate.emailnotificationプロパティを有効化します。詳細は、電子メール・オブジェクトの設定を参照してください。

4. 必要なステップ・アクション、時間指定アクション、デッドロック・アクション、グループ・デッドロック・アクションおよび委任アクションを作成します。詳細は、アクションと条件の設定を参照してください。

5. 状態を作成します。詳細は、状態の設定を参照してください。

6. プロセスを作成します。ワークフロー・プロセスを作成しながら、そのプロセスの手順を作成します。状態が適切な順序で発生するように、手順でこれらの状態を結合します。さらに、プロセスの作成の際、必要な機能の権限も構成します。詳細は、ワークフロー・プロセスの設定を参照してください。

7. 状態に期限がある場合は、アセットの期限を定期的に計算して、適切な時間指定アクションがあれば、これをタイムリに起動するように、時間指定アクション・イベントを構成します。詳細は、時間指定アクション・イベントの設定を参照してください。

8. ワークフロー・プロセスをテストします。詳細は、ワークフロー・プロセスのテストを参照してください。

9. 作成したワークフロー・プロセスが自動的にアセットに割り当てられるように、スタート・メニュー・ショートカットを設定します。スタート・メニュー・アイテムの詳細は、スタート・メニュー・アイテムの管理を参照してください。

18.4 電子メール・オブジェクトの設定

電子メール・オブジェクトを作成し、ステップ・アクションおよび時間指定アクションからそれらを適切なときに適切な参加者に送信できるようにします。ワークフロー・プロセスのスケッチを調査し、必要な電子メール・メッセージを特定し、この項の手順を使用してそれらを作成および編集します。

電子メール・オブジェクトを作成するには、ユーザー・アカウントに、「一般的な管理」ツリーの下の「管理」ノードへのアクセス権がある必要があります。

ワークフロー・プロセスで電子メール・メッセージを正常に送信できるようにするには、次の条件を満たす必要があります。

- 次の各プロパティを構成して、電子メール・サーバーに関する情報を提供する必要があります。

- cs.emailaccount

- cs.emailauthenticator

- cs.emailcharset

- cs.emailcontenttype

- cs.emailhost

- cs.emailpassword

- cs.emailreturnto

- xcelerate.emailnotificationプロパティは、trueに設定する必要があります。
前述のプロパティと、プロパティ管理ツールの使用の詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

- ワークフロー参加者は、彼らのユーザー・プロファイルに電子メール・アドレスが指定されている必要があります。ユーザー・プロファイルの作成の詳細は、ユーザー・プロファイルとユーザー属性の使用を参照してください。

次の各トピックでは、電子メール・オブジェクトを使用する手順について説明します。

- 電子メール・オブジェクトの作成

- 電子メール・オブジェクトの編集

- 電子メール・オブジェクトの削除

18.4.1 電子メール・オブジェクトの作成

1. 「ワークフロー」タブで、「電子メール」を開き、「新規追加」をダブルクリックします。

「新規ワークフロー電子メールの追加」フォームが開きます。

図18-4 「新規ワークフロー電子メールの追加」フォーム

2. 「名前」フィールドに、最大36文字の一意の名前を入力します。これは、この電子メール・オブジェクトをアクションで使用するときにemailname変数に指定する名前です。

注意:

「名前」フィールドでは、二重引用符(")、小なり記号(<)および大なり記号(>)は使用できません。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

3. 「説明」フィールドに、最大36文字で短い説明を入力します。

4. 「件名」フィールドに、電子メール・メッセージの情報を伝える短い件名を入力します。使用できる変数のリストは、電子メール・オブジェクトの理解を参照してください。

5. 「本文」フィールドに、そのメッセージのテキストを入力します。使用できる変数のリストは、電子メール・オブジェクトの理解を参照してください。

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

18.4.2 電子メール・オブジェクトの編集

1. 「管理」タブで、「電子メール」を開き、電子メール・オブジェクトをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「ワークフロー電子メールの編集」フォームが開きます。

3. 必要な変更を行い、「Save」をクリックします。

18.4.3 電子メール・オブジェクトの削除

1. 「管理」タブで、「電子メール」を開き、電子メール・オブジェクトをダブルクリックします。

2. アクション・バーで、「削除」をクリックします。

警告メッセージが開きます。

3. 「電子メールの削除」をクリックします。

18.5 アクションと条件の設定

いずれかの種類のアクションまたはステップ条件を作成する場合、エレメントを特定し、そのエレメントが取る変数の値を提供します。電子メール・メッセージを送信するアクションを作成している場合、emailname変数でどの電子メール・オブジェクトを送信するのか特定します。

アクションまたはステップ条件の作成を開始する前に、必要なエレメントおよび電子メール・オブジェクトが揃っていることを確認します。WebCenter Sitesには、いくつかのデフォルトのアクション・エレメントおよび電子メール・オブジェクトが用意されています。管理者のインタフェースを使用して、電子メール・オブジェクトを調査し、WebCenter Sites Explorerを使用して、ElementCatalog表を調査します。どのエレメントを使用する予定であるのか決定し、それらのエレメントの名前全体を書き留めます。追加の電子メール・メッセージが必要な場合、電子メール・オブジェクトの設定を参照して、必要な電子メール・メッセージを作成します。

次の手順は、ワークフロー・アクション(ステップ、時間指定、委任、デッドロック、およびグループ・デッドロックのアクション)およびステップ条件を作成、編集、および削除する方法を説明しています。

注意:

アクションまたは条件を作成するには、自身のユーザー・アカウントに「ワークフロー」タブへのアクセス権があることが必要です。

- アクションと条件の作成

- アクションと条件の編集

- アクションと条件の削除

18.5.1 アクションと条件の作成

1. 「ワークフロー」タブで、「アクション」を開きます。

2. 「アクション」の下で、作成するアクションを示すカテゴリを開き、「新規追加」をダブルクリックします。

使用可能なカテゴリは、「ステップ・アクション」、「ステップ条件」、「時間指定アクション」、「委任アクション」、「デッドロック・アクション」または「グループ・デッドロック時のアクション」です。

選択した種類のアクションに対応する「新規追加」フォームが開きます。

図18-5 「新規ステップ・アクションの追加」フォーム

次の例は、「新規ステップ・アクションの追加」フォームを示しています。

3. 「名前」フィールドに、最大40文字の一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

4. 「説明」フィールドに、最大40文字で短い説明を入力します。

5. 「エレメント名」フィールドに、エレメントの完全な名前を入力します。

たとえば、デフォルト・ワークフロー・エレメントSendEmailToAssigneesを使用するには、次のように入力します。

OpenMarket/Xcelerate/Actions/Workflow/StepActions/SendEmailToAssignees

6. 「引数」フィールドに、次の表記規則を使用して、そのエレメントが適切に機能するために必要な引数または変数の値を指定します。

name=value

たとえば、SendEmailToAssigneesエレメントの場合は、emailname変数の値(つまり、電子メール・オブジェクトの名前)を指定する必要があります。例:

emailname=AssignmentDueReminder

エレメントが複数の変数を取る場合は、名前と値のペアをアンパサンド(&)文字で区切ります。例:

name1=value1&name2=value2

7. 「新規アクションの追加」をクリックします。

18.5.2 アクションと条件の編集

1. 「ワークフロー」ノードで、「アクション」を開きます。

2. 「アクション」の下で、編集するアクションを示すカテゴリを開きます。

使用可能なカテゴリは、「ステップ・アクション」、「ステップ条件」、「時間指定アクション」、「委任アクション」、「デッドロック・アクション」または「グループ・デッドロック時のアクション」です。

3. 選択したカテゴリの下で、編集するアクションをダブルクリックします。

4. アクション・バーで、「編集」をクリックします。

5. 変更を行い、「保存」をクリックします。

18.5.3 アクションと条件の削除

1. 「ワークフロー」タブで、「アクション」を開きます。

2. 「アクション」の下で、削除するアクションを示すカテゴリを開きます。

使用可能なカテゴリは、「ステップ・アクション」、「ステップ条件」、「時間指定アクション」、「委任アクション」、「デッドロック・アクション」または「グループ・デッドロック時のアクション」です。

3. 選択したカテゴリの下で、削除するアクションをダブルクリックします。

4. アクション・バーで、「削除」をクリックします。

警告メッセージが開きます。

5. 「アクションの削除」をクリックします。

18.6 パブリッシュの承認ステップ・アクションの構成

承認プロセスによって、特定のパブリッシュの宛先に対してアセットが承認されます。ワークフロー・プロセスでデフォルトのパブリッシュの承認ステップ・アクションを使用するには、そのアクションによって承認されるアセットのパブリッシュの宛先を指定します。

すべてのワークフロー・プロセスのすべてのアセットが同じ宛先にパブリッシュされる場合、単に既存のApprove For Publishアクションを構成できます。ただし、一部の種類のアセットが他と異なる宛先にパブリッシュされる場合、各パブリッシュの宛先に対する追加のアクションが必要です。

パブリッシュの承認ステップ・アクションは、targets変数を取るOpenMarket/Xcelerate/Actions/Workflow/StepActions/ApproveForPublishエレメントを使用します。この同じエレメントを、必要な数の追加の承認ステップ・アクションで使用できます。

デフォルトのパブリッシュの承認ステップ・アクションの場合は、targets変数の値を指定します。targets変数が取ることができる値は、このWebCenter Sitesシステム上に作成済のいずれかのパブリッシュの宛先の名前です。

例:

targets=serverX.

複数のパブリッシュの宛先を指定するには、1つずつカンマで区切ります。例:

targets=serverX,serverY

注意:

targets変数によって参照されるパブリッシュの宛先の名前が変更された場合、パブリッシュの承認ステップのtargets変数の値も変更する必要があります。

18.7 時間指定アクション・イベントの設定

時間指定アクションをトリガーできるようにするには、その前に、通常の発生間隔で期限を計算するように時間指定アクション・イベントを構成する必要があります。時間指定アクションはWebCenter Sitesシステムごとに1つのみ設定できることに注意してください。

1. 「ワークフロー」タブで、「時間指定アクション・イベント」をダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「時間指定ワークフロー・アクション・イベントの編集」が開きます。

図18-6 「時間指定ワークフロー・アクション・イベントの編集」

3. 選択した間隔に応じて、月数、日数、時間数、分数で状態の期限を計算する頻度のスケジュールを設定します。選択した値は、青でハイライト表示されます。すべての値は個別に切り替わるため、[Ctrl]キーを使用して複数の値を選択する必要はありません。

時間指定アクション・イベントの設定方法は、パブリケーション・イベントの設定方法と似ています。詳細は、パブリッシュ・イベントのスケジュールのスケジュールの例を参照してください。

4. 「有効な日時」フィールドで「有効」を選択します。

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

スケジュールの概要が開きます。

WebCenter Sitesでは、時間指定アクション・イベントのスケジュールの概要に、パブリッシュ・イベントと同じ略称およびコードを使用します。スケジュールの読取り方法の詳細は、スケジュールの略称の読取りを参照してください。

18.8 状態の設定

ワークフロー状態を作成する場合、期限を指定し、時間指定アクションを選択し、その時間指定アクションを実行するタイミングを構成します。したがって、ワークフロー状態を作成する前に、必要な時間指定アクションを作成済であることを確認します。

次の手順は、ワークフロー状態を作成、編集および削除する方法の説明です。

注意:

ワークフロー状態を操作するには、操作しているサイトに対するWorkflowAdminロールが自身のユーザー名に割り当てられていることが必要です。

- ワークフロー状態の作成

- ワークフロー状態の編集

- ワークフロー状態の削除

18.8.1 ワークフロー状態の作成

1. 「ワークフロー」タブで、「状態」を開き、「新規追加」をダブルクリックします。
「新規ワークフロー状態の追加」フォームが開きます。

2. 「名前」フィールドに、最大40文字の意味のある一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

3. 「説明」フィールドに、最大40文字で短い説明を入力します。

4. (オプション)「予測時間」フィールドで、この状態のアセットの期限を構成します。期限は、日数、時間数、およびそれら2つの組合せで指定できます。

5. (オプション)「時間指定アクションの追加」をクリックし、次の手順を実行します。

図18-7 「ワークフロー状態への時間指定アクションの追加」フォーム

a. 「実行するアクション」リストで、時間指定アクションを選択します。

b. 「オフセット」フィールドに、そのアクションを期限の前と後のどちらでトリガーするのかを指定します。

c. 「日間」フィールドまたは「時間」フィールド、あるいはその両方に、アクションをトリガーする期限の前または後の時間数または日数を指定します。

d. 「時間指定アクションの追加」をクリックします。

e. この状態に対して設定する時間指定アクションごとにこの手順全体を繰り返します。

6. 「新規状態の追加」をクリックします。

18.8.2 ワークフロー状態の編集

1. 「ワークフロー」タブで、「状態」を開き、編集する状態をダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「編集」フォームが開きます。

3. 次の変更を行います。

4. (オプション)時間指定アクションまたはそれを実行するようにスケジュールされた時間を変更するには、「時間指定アクションの追加」をクリックし、適切な変更を行い、「時間指定アクションの追加」を再度クリックします。

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

18.8.3 ワークフロー状態の削除

1. 「ワークフロー」タブで、「状態」を開き、削除する状態をダブルクリックします。

2. アクション・バーで、「削除」をクリックします。

警告メッセージが開きます。

3. 「状態の削除」をクリックします。

18.9 ワークフロー・プロセスの設定

ワークフロー・プロセスを作成するときは、グローバル・プロセス情報を指定し、次にステップを作成し、ステップ・アクションを必要に応じてそれらに割り当てます。プロセス内のステップによって、状態が特定の順序でつなぎ合わされ、プロセスのフローが作成されます。ワークフロー・プロセスの作成を開始する前に、ステップ・アクション、ステップ条件(必要な場合)、および状態を作成しておく必要があります。

ワークフロー・プロセスを操作するには、操作しているサイトに対するWorkflowAdminロールが自身のユーザー名に割り当てられていることが必要です。

注意:

コンテンツ・プロバイダがワークフロー・グループを使用する場合は、必ずそのグループに対して「ワークフロー・グループ」タブを有効にしてください。詳細は、「「ワークフロー・グループ」タブの作成」を参照してください。

次の手順は、ワークフロー・プロセスを設定する手順です。

- ワークフロー・プロセスの編集

- ワークフロー・ステップの編集

- 機能権限の編集

- ワークフロー・プロセスのコピー

- ワークフロー・プロセスの削除

- ワークフロー・ステップの削除

- 機能権限の削除

18.9.1 ワークフロー・プロセスの編集

1. 「ワークフロー」タブで、「プロセス」を開き、編集するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「ワークフロー・プロセス」フォームが開きます。

3. 次のように変更を行います。

- 名前、説明、またはその他のグローバル設定のいずれかを変更するには、フォーム内で直接変更を行います。

- ステップを編集するには、ワークフロー・ステップの編集を参照してください。

- 機能権限を編集するには、機能権限の編集を参照してください。

4. 終了したら、「保存」をクリックします。

18.9.2 ワークフロー・ステップの編集

1. 「ワークフロー」タブで、「プロセス」を開き、使用するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「ワークフロー・プロセス」フォームが開きます。

3. 「ステップの追加/編集」をクリックします。

「ワークフロー・プロセスのステップ」フォームが開きます。

4. 編集するステップの隣にある「編集」をクリックします。

「ワークフロー・プロセス・ステップの編集」フォームが開きます。

5. 変更を行い、「保存」をクリックします。

プロセスが保存され、「調査」フォームが開きます。

18.9.3 機能権限の編集

機能権限を編集するには、それを削除してから再作成します。

1. 「ワークフロー」タブで、「プロセス」を開き、使用するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「ワークフロー・プロセス」フォームが開きます。

3. 「機能権限の追加/編集」をクリックします。

「ワークフロー・プロセスの機能」フォームが開きます。

4. 変更する機能の横にある「除去」をクリックします。

確認ダイアログが開きます。

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

6. 削除した機能の横にある「新規」をクリックします。

「機能権限の追加」フォームが開きます。

7. 機能権限を選択し、「保存」をクリックします。

「ワークフロー・プロセスの機能」フォームが開きます。

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

ワークフロー・プロセスが保存され、「調査」フォームが開きます。

18.9.4 ワークフロー・プロセスのコピー

ワークフロー・プロセスをコピーできます。これにより、追加のプロセスの構成においていくつかの手順を省略できます。

1. 「ワークフロー」タブで、「プロセス」を開き、コピーするワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、ドロップダウン・リストから「プロセスのコピー」を選択します。

「ワークフロー・プロセスのコピー」フォームが開きます。

図18-8 「ワークフロー・プロセスのコピー」フォーム

3. 「プロセス名」フィールドに、そのプロセスの一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

4. 「説明」フィールドに、そのプロセスの短い説明を入力します。

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

6. 必要に応じてプロセスを編集します。詳細は、次の手順を参照してください。

- ワークフロー・プロセスの編集

- ワークフロー・ステップの編集

- 機能権限の編集

18.9.5 ワークフロー・プロセスの削除

1. 「ワークフロー」タブで、「プロセス」を開き、削除するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「削除」をクリックします。

警告メッセージが表示されます。

3. 「プロセスの削除」をクリックします。

プロセスが削除されます。

18.9.6 ワークフロー・ステップの削除

1. 「ワークフロー」タブで、「プロセス」を開き、使用するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「プロセスの編集」フォームが開きます。

3. 「ステップの追加/編集」をクリックします。

「ワークフロー・プロセスのステップ」フォームが開きます。

4. 削除するステップの隣にある「除去」をクリックします。

ダイアログ・ボックスが開きます。

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

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

ワークフロー・プロセスが保存され、「調査」フォームが開きます。

18.9.7 機能権限の削除

1. 「ワークフロー」タブで、「プロセス」を開き、編集するワークフロー・プロセスをダブルクリックします。

2. アクション・バーで、「編集」をクリックします。

「ワークフロー・プロセス」フォームが開きます。

3. 「機能権限の追加/編集」をクリックします。

「ワークフロー・プロセスの機能」フォームが開きます。

4. 削除する機能権限の隣にある「除去」をクリックします。

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

ワークフロー・プロセスが保存され、「調査」フォームが開きます。

18.10 ワークフロー・プロセスの作成

ワークフロー・プロセスを作成する場合は、グローバル・プロセス設定、ステップ、および機能権限の3つのカテゴリの情報を構成します。

ワークフロー・プロセスを作成するには、次の手順を実行します。

- プロセスの名前付けおよびグローバル設定の設定

- ワークフロー・プロセスの開始ステップの作成

- 後続のワークフロー・ステップの作成

- (オプション)ワークフロー・プロセスの終了ステップの作成

- (オプション)ワークフロー・プロセスの機能権限の構成

18.10.1 プロセスの名前付けおよびグローバル設定の設定

1. 「ワークフロー」タブで、「プロセス」を開き、「新規追加」をダブルクリックします。

「ワークフロー・プロセス: (新規)」フォームが開きます。

2. 「名前」フィールドに、最大25文字の一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

3. 「説明」フィールドに、最大64文字で短い説明を入力します。

4. 「サイト」リストで、このワークフロー・プロセスを使用できるサイトを選択します。

5. 「アセット・タイプ」リストで、このワークフロー・プロセスの対象となるアセット・タイプを1つ以上選択します。

6. 「ロール」リストで、参加するロールを選択します。

7. 「管理ロール」リストで、アセットがこのワークフロー・プロセスを使用するときにこのワークフロー・プロセスの管理者として機能できるロールを選択します。

8. 「プロセスの期限」セクションで、ワークフロー管理者(または他のユーザーにそれを許可する機能権限を構成する場合はそのユーザー)が、このワークフロー・プロセスに参加するアセットのプロセス期限を設定できるかどうかを指定します。

9. 1つ以上の委任アクションを構成済である場合は、「委任アクション」リストで適切なアクションを選択します。

10. 「開始ステップ」セクションで、「新規ステップの追加」をクリックします。

「新規ワークフロー・プロセス・ステップの追加」フォームが開きます(図18-9参照)。

11. 開始ステップを作成します。手順は、ワークフロー・プロセスの開始ステップの作成を参照してください。

18.10.2 ワークフロー・プロセスの開始ステップの作成

図18-9 「新規ワークフロー・プロセス・ステップの追加」フォーム

1. 「ステップ名」フィールドに、最大64文字の意味のある一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

2. 次のように状態を構成します。

a. 「開始状態」リストで、何も選択しません(ワークフローの開始)。

b. 「終了状態」リストで、このワークフロー・プロセスの最初の状態の名前を選択します。

3. 「認可ロール」リストで、このワークフローをアセットに割り当てることによってこのステップの実行を許可されるロールを選択します。

4. 「割当て方法」セクションで、次のオプションのいずれかを選択し、アセットが割り当てられるロールを指定します。

- 割り当てられたユーザーを「開始状態」に維持: 開始ステップの場合、これは、ワークフローをアセットに割り当てるユーザーにそのアセットが割り当てられることを意味します。

- 割当てなし、機能権限を使用したアクションの制御

- 参加者リストからの割当て

- ステップ実行時に割り当てられるユーザーを選択
「参加者リストからの割当て」または「ステップ実行時に割り当てられるユーザーを選択」のいずれかを選択する場合、これらのオプションの右にあるリストから適切なロールを選択します。(このオプションの定義はステップの決定を参照してください。)

- 全員への割当て

5. 「割当て期限」セクションで、ワークフロー管理者(または適切な機能権限を持つ別のユーザー)が、このステップがアセットの移動先の状態に対して設定されている予測時間(期限)をオーバーライドできるかどうかを指定します。

6. (オプション)「ステップ・アクション」リストで、このステップの実行時にコールする必要のある1つ以上のステップ・アクションを選択します。

7. (オプション)「ステップ条件」リストで、必要に応じてステップ条件を選択します。

8. (オプション)「投票」チェック・ボックスを選択して、割り当てられたすべてのユーザーが投票して承認する必要があるように選択します。

9. (オプション)「ワークフロー・グループ」チェック・ボックスを選択して、ステップ・グループが同期するようにします。

10. 「保存」をクリックします。
開始ステップが追加され、「ワークフロー・プロセスのステップ」フォームが開きます。

11. 「保存」をクリックします。
「調査」フォームが開きます。このステップがフォームに「開始ステップ」として開きます。

18.10.3 後続のワークフロー・ステップの作成

次の手順を使用して、終了ステップを含む残りの後続のステップを作成します。

1. ワークフロー・プロセスの「調査」フォームのアクション・バーで、「編集」をクリックします。
「編集」フォームが開きます。

2. 「ステップの追加/編集」をクリックします。
「ワークフロー・プロセスのステップ」フォームが開きます。

3. 「新規ステップの追加」をクリックします。
「新規ワークフロー・プロセス・ステップの追加」フォームが開きます。

4. 「ステップ名」フィールドに、最大64文字の意味のある一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

5. 次のように状態を構成します。

a. 「開始状態」リストで、前のステップの「終了状態」として選択された状態の名前を選択します。

b. 「終了状態」リストで、このワークフロー・プロセスの次の状態の名前を選択します。(反復ステップを作成する場合、「開始状態」と「終了状態」リストで同じ状態を選択します。)

6. 「認可ロール」リストで、この割当てを終了することでこのステップの実行を許可されるロールを選択します。このリストから選択するロールは、このワークフロー・ステップの直前のワークフロー・ステップで「割当て方法」に対して選択したロールのサブセットに一致するかそれを含む必要があります。

7. 「割当て方法」セクションで、次のオプションのいずれかを選択し、アセットが割り当てられるロールを指定します。

- 割り当てられたユーザーを「開始状態」に維持
「開始状態」と「終了状態」が異なる場合、前のステップによって複数の参加者にこのアセットが割り当てられていても、最初にこのステップを実行する(割当てを終了する)人にアセットが割り当てられます。

「開始状態」と「終了状態」が同じ場合、最後のステップによってこのアセットが割り当てられたすべてのユーザーに、このステップで再びアセットが割り当てられます。

- 割当てなし、機能権限を使用したアクションの制御

- 参加者リストからの割当て

- ステップ実行時に割り当てられるユーザーを選択
前述の最後の2つのオプションのいずれかを選択する場合、それらのオプションの右にあるリストから適切なロールを選択します。このオプションの定義はステップの決定を参照してください。

- 全員への割当て

8. 「割当て期限」セクションで、ワークフロー管理者(または適切な機能権限を構成する場合は他のユーザー)がこのステップによってアセットの移動先の状態の予測時間(期限)をオーバーライドできるかどうかを決定します。

9. (オプション)「ステップ・アクション」リストで、このステップの実行時にコールする必要のある1つ以上のステップ・アクションを選択します。

10. (オプション)「ステップ条件」リストで、必要に応じてステップ条件を選択します。

11. ステップで、複数の参加者がアセットを操作していたある状態からアセットを移動する場合に、ステップが完了する前にすべての参加者がその割当てを終了するようにするには、「割り当てられたすべてのユーザーが投票する必要あり」オプションを選択します。

12. このプロセスに同じ「開始状態」を持つ他のステップがあり、それらのステップのいずれかもすべて投票ステップである(「割り当てられたすべてのユーザーが投票する必要あり」が選択されている)場合、「デッドロック・アクション」を選択します。デッドロックとその回避については、デッドロックの管理および委任アクションの理解を参照してください。

13. このワークフロー・プロセスがワークフロー・グループに対して使用される予定であり、すべてのアセットが同時に、この手順の手順4で選択した終了状態に進むようにする場合は、「ステップをグループ単位で同期」オプションを選択します。1つのプロセス内に作成する同期ステップは1つのみにすることをお薦めします。

14. 「保存」をクリックします。
ステップが保存され、「ワークフロー・プロセスのステップ」フォームが開きます。

15. 「保存」をクリックします。
「調査」フォームが開きます。

16. この手順を、終了ステップを除く、このプロセスに対して作成する各ステップに繰り返します。
終了ステップを作成するには、「(オプション)ワークフロー・プロセスの終了ステップの作成」に進みます。

機能権限を構成するには、(オプション)ワークフロー・プロセスの機能権限の構成に進みます。

18.10.4 (オプション)ワークフロー・プロセスの終了ステップの作成

終了ステップによってワークフローが終了します。これは、アセットがすでにプロセス内になく、機能権限を使用している場合、そのアセットへのアクセスを制御する機能権限もすでにないことを意味します。次の手順を使用して、ワークフロー・プロセスの終了ステップを作成します。

1. ワークフロー・プロセスの「調査」フォームのアクション・バーで、「編集」をクリックします。
「プロセスの編集」フォームが開きます。

2. 「ステップの追加/編集」をクリックします。
「ワークフロー・プロセスのステップ」フォームが開きます。

3. 「新規ステップの追加」をクリックします。
「新規ワークフロー・プロセス・ステップ」フォームが開きます。

4. 「ステップ名」フィールドに、最大64文字の意味のある一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。二重引用符(")、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

5. 次のように状態を構成します。

a. 「開始状態」リストで、前のステップの「終了状態」として選択された状態の名前を選択します。

b. 「終了状態」リストで、何も選択しません(ワークフローの終了)。

6. 「認可ロール」リストで、割当てを終了することでこのステップの実行を許可されるロールを選択します。このリストから選択するロールは、プロセス内のこのワークフロー・ステップの直前のワークフロー・ステップの「割当て方法」に対して選択したロールのサブセットに一致するかそれを含む必要があります。

7. (オプション)「ステップ・アクション」リストで、このステップの実行時にコールする必要のある1つ以上のステップ・アクションを選択します。

8. (オプション)「ステップ条件」リストで、必要に応じてステップ条件を選択します。

9. ステップで、複数の参加者がアセットを操作していたある状態からアセットを移動する場合に、ステップが完了する前にすべての参加者がその割当てを終了するようにするには、「割り当てられたすべてのユーザーが投票する必要あり」オプションを選択します。

10. このプロセスに同じ「開始状態」を持つ他のステップがあり、それらのステップのいずれかもすべて投票ステップである(「割り当てられたすべてのユーザーが投票する必要あり」が選択されている)場合、「デッドロック・アクション」を選択します。デッドロックとその回避については、デッドロックの管理および委任アクションの理解を参照してください。

11. このワークフロー・プロセスがワークフロー・グループに対して使用され、このステップをグループ内のすべてのアセットに同時に実行する場合は、「ステップをグループ単位で同期」オプションを選択します。プロセス内に作成する同期ステップは1つのみにすることをお薦めします。

12. 「保存」をクリックします。
開始ステップが追加され、「ワークフロー・プロセスのステップ」フォームが開きます。

13. 「保存」をクリックします。
「調査」フォームが開きます。

機能権限を構成する必要がない場合、このワークフロー・プロセスは完了します。機能権限を構成する必要がある場合は、次の手順に進みます。

18.10.5 (オプション)ワークフロー・プロセスの機能権限の構成

1. 目的のワークフロー・プロセスを見つけ、その「調査」フォームを開きます。

2. アクション・バーで、「編集」をクリックします。

「編集」フォームが開きます。

3. そのフォームの下部にある「機能権限の追加/編集」をクリックします。

「ワークフロー・プロセスの機能」フォームが開きます。

4. 権限を設定する機能まで下にスクロールします。

5. 機能の横にある「新規」をクリックします。

「機能権限の追加」フォームが開きます。

図18-10 「機能権限の追加」フォーム

6. 「状態」リストから適切な状態を選択します。

7. 「ロール」リストで、アセットがこの状態にあるときに、この権限の実行を許可されるまたはされないロールを選択します。

8. 次のいずれかを行います。

- 選択したロールを持つユーザーに機能の実行を許可するには、「許可」チェック・ボックスを選択します。

- 選択したロールを持つユーザーに機能の実行を禁止するには、「許可」チェック・ボックスを選択解除します。

9. 「新規追加」をクリックします。

権限が保存され、「ワークフロー・プロセスの機能」フォームが開きます。

10. 構成する必要がある機能権限ごとに手順3から8を繰り返します。機能権限の詳細は、機能権限の決定を参照してください。

11. すべての機能権限を構成したら、「保存」をクリックします。

プロセスが保存されます。「ワークフロー・プロセス」フォームが開きます。

ワークフロー・プロセスが完了します。

18.11 ワークフロー・プロセスのテスト

ワークフロー・プロセスを管理システムに移動し、そのワークフロー・プロセスをそこで実装する前に、開発システムでこれをテストします。

プロセスをテストする完全な方法論には、次が含まれます。

- 管理者アクセス権を持つユーザーとしてログインし、必要に応じてワークフロー・プロセスをアセットに割り当てるスタート・メニュー・アイテムを構成します。

- ワークフロー・プロセスの開始ステップの実行を認可されたロールを持つユーザーとしてログインします。アセットを作成し、ワークフロー・プロセスを選択し(スタート・メニュー・アイテムによってそれが割り当てられていない場合のみ)、割当てを終了します。

- 現在割当てを持っている参加者としてログインします。割当てを終了し、次の参加者としてログインします。この方法でワークフロー全体を通して続行します。

- 送信する必要がある電子メール・メッセージが送信されていることを確認します。

- ワークフローによって、プロセスを通してアセットが適切に送信されていることを確認します。

18.12 作業の移動

ワークフローがコンテンツ・プロバイダによって使用される準備が整ったら、ミラー・ターゲットの初期化機能を使用して、ワークフロー・コンポーネントを管理システムに移動します。

この機能の詳細は、あるシステムから別のシステムへのサイトの移行を参照してください。

18.13 ワークフローの割当ての消去

人は休暇を取ったり、新しいワーク・グループに再割当てされたり、別の仕事に異動したりします。それらの状況では、彼らのワークフローの割当てはどのようになるでしょうか。元の割当て先によって終了できない作業割当てを処理するための1つの選択肢は、その割当てを誰か他の人に委任することです。ただし、管理者は、委任機能を持っていても、ユーザーの割当てリストから割当てを消去する場合があります。

ユーザーの割当てを消去するには::

1. 「ワークフロー」タブで、「割当てのクリア」をダブルクリックします。

「割当ての検索」フォームが開きます。

2. ユーザー名を入力して、「割当ての表示」をクリックします。

「割当てのクリア」フォームが開き、そのユーザーに現在割り当てられているアセットのリストが表示されます。

図18-11 「割当てのクリア」フォーム

3. クリアする各割当ての隣の「クリア」チェック・ボックスを選択します。

4. (オプション)「割当てコメントのクリア」フィールドに、選択した割当てを消去する理由の簡単な説明を入力します。このフィールドに入力する説明は、そのアセットの「ステータス」フォームの「ワークフロー履歴」セクションにある「実行されたアクション」フィールドに開きます。

5. 次のいずれかを行います。

- アセットが他の誰にも割り当てられていない場合に、ワークフローからそれを削除するには「はい」を選択します。

- そのアセットを割り当てられている他のユーザーの割当てリストにそのアセットを残しておく場合は、「いいえ」を選択します。

6. 「割当てのクリア」をクリックします。

変更を要約した「割当てレポートのクリア」が開きます。

18.14 ワークフロー・レポートの作成および表示

ワークフロー・レポートは、ワークフローのアセットのステータスを表示するために使用されます。タイプ、ユーザー割当て、ロール割当て、ワークフロー状態および期限を基準にアセットを表示するようにレポートを構成できます。

ワークフロー・レポートを作成するには、次の手順を完了します。

1. メニュー・バーの「ワークフロー」をクリックします。表示されたフォームで、「ワークフロー・レポートの作成」をクリックします。

2. 「ワークフロー・レポートの作成」フォームで、アセット・タイプ、ワークフロー状態、ユーザー、ロールまたはアセットが割り当てられるユーザーおよびロール、割当て期限、プロセス期限および最終レポート・オプションを選択します。

これらのオプションは、いずれも必須ではありません。いずれのオプションも選択しない場合、レポートはワークフローのすべてのアセットを表示します。

3. 「レポート」をクリックして、レポートを表示します。

レポートは、選択した基準を満たすワークフローのすべてのアセットを表示します。定期的に実行および表示するためにレポート・パラメータを保存するには、「このワークフロー・レポートの保存」をクリックします。レポート基準を変更して、レポートを再実行するには、「このワークフロー・レポートの編集」をクリックします。

18.15 ワークフロー・グループの作成

ワークフロー・グループにアセットを配置すると、すべてのアセットを1つの作業単位とみなすことができます。グループ内のすべてのアセットは、まとめて承認するまで、ワークフロー内の次のポイントに移動できません。

ワークフロー・グループを作成するには、次の手順を完了します。

1. メニュー・バーの「ワークフロー」をクリックします。表示されたフォームで、「ワークフロー・グループの作成」をクリックします。

2. 「ワークフロー・グループの作成」フォームで、名前、説明およびワークフロー・プロセスを入力します。参加者を選択する前に、プルダウン・メニューからワークフロー・プロセスを選択する必要があります。

3. 「参加者の設定」をクリックして、グループの参加者を選択します。使用できる参加者は、選択したワークフロー・プロセスによって異なります。

参加者を選択すると、「ワークフロー・グループの作成」フォームが再表示されます。

4. アセットを追加および削除できるロールを選択し、続いてワークフロー・グループを編集または削除できるロールを選択します。

5. グループ・デッドロック・アクションを選択します。デッドロックの管理の詳細は、デッドロックの管理を参照してください。

6. 「保存」をクリックします。ワークフロー・グループが、新しいフォームに表示されます。

この時点でグループが作成されますが、まだ空です。「グループへ追加」をクリックしてグループにアセットを追加します。

Part VII ブログ・コンポーネントの有効化

コンテンツ・プロバイダはブログ・コンテンツを作成するためにブログ・コンポーネントへのアクセスを必要とします。次の各トピックでは、コンテンツ・プロバイダがアクセスする必要があるブログ・コンポーネントの有効化についての情報と、作成者アセットを作成するための情報を提供します。

- ブログ・アセット・タイプの有効化

- ブログ・ツリー・タブの作成

- ブログ・アセットの共有

- ブログ作成者の使用

- ブログ・アセットのワークフロー作成とパブリッシュについて

19 ブログ・アセット・タイプの有効化

異なるCMサイトでOracle WebCenter Sites: Blogsモジュールを使用する場合は、それらのサイトでブログ・アセット・タイプを有効にする必要があります。ブログ・アセット・タイプを有効にすると、そのスタート・メニュー・アイテムも有効にできます。コンテンツ・プロバイダは、このスタート・メニュー・アイテムを使用して、有効にするタイプのアセットを作成および検索できます。

ブログ・アセット・タイプを有効にするには::

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. サイトを選択します。

3. ツリーで「管理」タブを選択して、「サイト」ノード、ブログ・アセット・タイプを有効にするサイトのノード、「アセット・タイプ」ノードの順に開きます。

4. 「有効化」をダブルクリックします。

5. 「アセット・タイプの有効化」フォームで、ブログ・アセット・タイプのチェック・ボックスを選択します。ブログ・アセット・タイプの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

6. 「アセット・タイプの有効化」をクリックします。

7. 「スタート・メニューの選択」フォームで、「アセット・タイプの有効化」をクリックします。

8. ユーザーにスタート・メニュー・アイテムへのアクセスを認可します。手順については、コンテンツ管理サイト・コンポーネントへのアクセスの管理を参照してください。

20 ブログ・ツリー・タブの作成

ブログ・カタログとそのアセットの階層を表示するようにツリー・タブを構成できます。

ブログ・ツリー・タブを作成するには::

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. サイトを選択します。

3. 「管理」タブで、「ツリー」ノードをダブルクリックします。

4. 「新規ツリー・タブの追加」をクリックします。

「新規ツリー・タブの追加」フォームが開きます。

5. 「新規ツリー・タブの追加」フォームでフィールドに値を入力します。

- タイトル: 短くわかりやすい名前を64文字以内で入力します。

- ツールチップ: タブの短くわかりやすい説明を255文字以内で入力します。この説明はマウス・カーソルをタブに重ねたときに開きます。

- サイト: このタブを表示するサイトを選択します。これらのサイトではブログ・アセット・タイプを有効にする必要があります。手順については、ブログ・アセット・タイプの有効化を参照してください。

- 必須ロール: このタブにアクセスするためにユーザーに割り当てる必要のあるロールを選択します。

- タブ・コンテンツ: タブに表示されるアセット・タイプを選択し、「選択したアイテムの追加」をクリックします。

- (オプション)カスタム機能をこのタブに追加するには、「セクション名」フィールドおよび「エレメント名」フィールドを使用します。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

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

新しく作成したブログの「情報」ページが開きます。

さらに、ツリーに新しいブログ・タブが開きます(必要に応じて、ブラウザをリフレッシュしてください)。

図20-1 新しいブログを表示するツリー

21 ブログ・アセットの共有

ブログ・フレックス・アセットを他のサイトと共有できます。すべてのタイプのブログ・アセットを共有する必要があります。

注意:

ブログ・アセット定義は、ブログ・アセット・フォームを構成する属性を定義するために必要です。

ブログ・アセットを共有するには::

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. サイトを選択します。

3. 共有するアセットを検索します。

a. メニュー・バーで、「検索」をクリックします。

b. アセット・タイプの「検索」または「詳細検索」をクリックします。

c. フィールドに記入して、「検索」をクリックします。

4. 検索結果リストで、共有するアセットをクリックします。

5. フォーム上部のボタン・バーで、「エレメントの共有」をクリックします。
エレメントの共有ページが開きます。

6. 「共有先」フィールドで、選択したブログ・アセットを共有するサイトを選択します。

7. 「変更の保存」をクリックします。
これで、選択したブログ・アセットが、それを共有するサイト上で使用可能になります。

アセットの共有の詳細は、コピーと共有を参照してください。

22 ブログ作成者の使用

サンプル・ブログ・ページでは、作成者のフル・ネームとイメージが作成者のブログ投稿の横に表示されます。この項では、作成者情報を含むブログ作成者アセットを作成する手順について説明します。また、自身のブログ作成者アセットへのアクセス権をユーザーに付与する手順についても説明します。

次の各トピックでは、ブログ作成者との作業について説明します。

- 作成者アセットの作成

- ブログ作成者アセットへのアクセス権限の設定方法

22.1 作成者アセットの作成

ブログ作成者のフル・ネームとイメージを作成者のブログ投稿の横に表示するには、作成者アセットを作成して、ユーザーのフル・ネームとイメージ(オプション)を指定する必要があります。

作成者アセットを作成するには::

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインします。

2. ブログ・アセット・タイプを有効にするサイトを選択します。

3. ボタン・バーで、「新規」をクリックします。

4. 「新規ブログ作成者」をクリックします。

5. 「ブログ作成者」フォームで、次のフィールドに値を入力します。

図22-1 「新規ブログ作成者」フォーム

- 名前: ブログ作成者アセットの名前を入力します。
「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、疑問符(?)、パーセント記号(%)、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

注意:

作成者がブログ・アセットを作成している場合は、同じ名前をブログ・アセットの「作成者」フィールドにも入力する必要があります。そうでないと、作成した作成者アセットが割り当てられた領域にパブリッシュされません。

- 説明: 作成者アセットの短くわかりやすい概要を入力します(作成者のフル・ネームなど)。

- ブログ作成者カテゴリ: デフォルトではこのフィールドは単一値です。BlogAuthorsのみ選択可能です。

- フル・ネーム: ブログ作成者のフル・ネームを入力します。この名前は、この作成者が作成したブログに表示されます。

- 作成者プロファイル・イメージ: 「参照」をクリックして、コンテンツ・プロバイダのイメージを選択します。

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

22.2 ブログ作成者アセットへのアクセス権限の設定方法

ブログ作成者アセットには、Webサイトのブログ・コンテンツを作成するコンテンツ・プロバイダのプロファイルが含まれます。ブログ作成者アセットのアクセス権限を設定するには、次の手順を実行する必要があります。

1. ブログ作成者用の一意のロールの作成

2. ブログ作成者へのロールの割当て

3. ブログ作成者アセットへのアクセス権限の設定

22.2.1 ブログ作成者用の一意のロールの作成

1. 一般管理者としてWebCenter Sites Adminインタフェースにログインし、サイトを選択します。

2. ツリーで「管理」タブを選択して、「ユーザー・アクセス管理」ノード、「ロール」ノードの順に開いて、「新規追加」をクリックします。

「新規ロールの追加」フォームが開きます。

図22-2 「新規ロールの追加」フォーム

- 名前: ロールの一意の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、パーセント記号(%)、疑問符(?)、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

- 説明: ロールの役割を説明する短くわかりやすい文を入力します。

3. 「新規ロールの追加」をクリックします。

ここで、ブログ作成者アセットへのアクセス権限が必要なコンテンツ・プロバイダにロールを割り当てる必要があります。

22.2.2 ブログ作成者へのロールの割当て

1. 「サイト」ツリーを選択して、「サイト管理者」ノード、作成者のサイトのノードの順に開きます。「ユーザー」をダブルクリックします。

2. 「ユーザー名」フィールドで、ロールを割り当てるユーザーの名前を入力して「選択」をクリックします。

3. 「編集」(鉛筆)アイコンをクリックします。

4. 「ユーザーのロールを編集」フォームで、手順2および3で作成したロールを選択します。

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

22.2.3 ブログ作成者アセットへのアクセス権限の設定

1. 権限を設定するブログ作成者アセットにアクセスします。

a. ボタン・バーで、「検索」をクリックします。

b. 「ブログ作成者の検索」をクリックします。

c. 「検索」をクリックします。

2. ブログ作成者アセットを選択します。

3. ブログ作成者の「調査」フォームで、「詳細...」メニューを選択し、「アクセス権限」をクリックします。

図22-3 「アクセス権限」フォーム

4. 「ロール別に表示」ラジオ・ボタンを選択します。

5. 「ロール」リストで、ブログ作成者へのロールの割当てで作成したロールを選択します。

6. 「継承」リストで、すべての機能を選択し([Shift]キーを押しながら最初と最後の機能をクリック)、「付与」をクリックします。
「継承」リストのすべての機能が「付与」リストに移動します。

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

管理者を除く、選択したロールを割り当てられたブログ作成者のみが、このブログ作成者アセットを操作できるユーザーになります。

23 ブログ・アセットのワークフロー作成とパブリッシュについて

次の各トピックでは、ブログ・アセットのワークフローの作成と、ブログ・アセットのパブリッシュに関する情報を提供します。

- ブログ・アセット用ワークフローの作成

- ブログ・アセットのパブリッシュについて

23.1 ブログ・アセット用ワークフローの作成

ワークフローを使用して、ブログ・アセットに対する作業を管理できます。ブログ・アセットをパブリッシュするには、その前に、パブリッシュ用に承認する必要があります。ワークフロー機能は、作成から承認まで、指定された一連の手順に従ってブログ・アセットを誘導します。

たとえば、ブログ・アセットをパブリッシュ用に承認する前にエディタにレビューしてもらう場合は、WebCenter Sitesのワークフロー機能により、そのブログ・アセットを適切なユーザーに適切なタイミングで誘導できます。ワークフロー・プロセスの詳細は、ワークフロー・プロセスの作成と管理を参照してください。

23.2 ブログ・アセットのパブリッシュについて

ブログ・アセットをパブリッシュするには、その作成者アセットを事前に承認する必要があります。これは、作成者のプロファイルがブログ・アセットとともにパブリッシュされるようにするためです。

第VIII部 A/B Testingの有効化

A/Bテスト・コンポーネントを使用すると、マーケティング担当者は、Webサイトで収集した訪問者データをさらにエンリッチできます。A/Bテスト・アセットを有効化すると、マーケティング担当者はA/Bテスト機能を使用してWebページのデザインとコンテンツの変更をテストし、どのバージョンが顧客アクティビティを活発化するかを決定できます。

次の各トピックでは、A/Bテスト・コンポーネントの構成と有効化について説明します。

- A/B Testingの管理

24 A/B Testingの管理

Oracle WebCenter Sites: A/B Testing機能を使用すると、マーケティング担当者は、Webサイトを完全に変更せずに、Webサイト・ページ上でデザインとコンテンツのバリエーションを実験して、どのバリエーションで結果が最適になるかを判断できます。このOracle WebCenter Sites製品のA/Bテスト機能は、Google Analyticsとの統合を介して提供されます。このOracle製品でA/Bテスト機能を使用するには、Googleに先にGoogle Analyticsアカウントを登録すると、「A/B」テストのパフォーマンスを測定可能になります。さらに、「A/B」テストの一部として、匿名のエンド・ユーザー情報(つまり、テストのためにWebサイトにアクセスするエンド・ユーザーの情報)が、その情報に関するGoogleの規約に応じてGoogleに提供および使用される場合があることに注意してください。

マーケティング担当者がどのようにA/Bテストを作成、実行するかについては、『Oracle WebCenter Sitesの使用』の、A/B Testingの使用に関する項を参照してください。

A/B Testingの管理の詳細は、次の各項を参照してください。

- A/B Testingの有効化

- A/B Testingの依存性の考慮

- A/Bテストのパブリッシュについて

24.1 A/B Testingの有効化

A/B Testing機能を使用するには、その前に、管理者が次を実行する必要があります。

1. まだ有効でない場合、A/B TestingアセットWCS_ABTestを有効化します。サイトに対するアセット・タイプの有効化の説明に従って実行してください。

2. A/Bテストの「勝者を昇格させる」能力がある任意のユーザーにMarketingAuthorロールを割り当て、A/Bテスト・レポートを参照し、テストを停止できる任意のユーザーにMarketingEditorロールを割り当てます。ユーザーの構成に関する詳細は、ユーザー、プロファイルおよび属性の構成を参照してください。

他のアクションは、ユーザーと開発者により、A/B Testingの前提条件として実行される必要があります。完全なリストは、『Oracle WebCenter Sitesの使用』の、A/B Testingの開始前に関する項を参照してください。

24.2 A/B Testingの依存性の考慮

A/B Testingは、WebCenter Sitesの依存性追跡と完全に統合されています。コントリビュータがバリアント・ページ(つまり、テストの場合、「B」ページまたはそれ以上)を作成する場合、ページの範囲内でアセットに依存性が配置されていることがあります。たとえば、ワークフローをパス・スルーする必要がある新しいイメージをコントリビュータが確認する場合、Bバリアント上に追加されたアセットのため、ページには新しい依存性があります。その場合、Bバリアントに変更すると、新しい依存性が満たされることが必要になります。これらの依存性がすべて満たされないと、WCS_ABTestアセット(テスト済バリアントのすべてを記述しています)をパブリッシュすることができません。

24.3 A/Bテストのパブリッシュについて

A/Bテストは、他のアセットをパブリッシュするのと同様にパブリッシュできます。指定した期間にA/Bテストを実行するよう設定できるので、パブリッシュ時に、テストが実行を開始しない場合があります。開始日を指定した場合は、指定した日まで、パブリッシュ済テストは開始しません。開始日を指定しない場合、パブリッシュの30秒後(デフォルト)に開始します。

30秒ごとに実行されるシステム・イベントがあり、必要に応じて、テストの開始または停止を確認します。イベントはRefreshActiveABTestsと呼ばれ、SystemEvents表で参照および構成できます。

第IX部 キャッシュの管理と調整

WebCenter Sitesは、キャッシュ・システムとしてinCacheを使用しています。inCacheフレームワークの詳細は、次のトピックを参照してください。

- inCacheフレームワークの使用

25 inCacheフレームワークの使用

次の各トピックでは、inCacheフレームワーク、または単にinCacheと呼ばれるキャッシング・システムについて説明します。このシステムは、Terracotta社によるオープン・ソースで標準ベースの製品であるEhcacheの上に構築されています。従来の方法によるデータベースへのキャッシングと比べて、inCacheでは、Webサイト・パフォーマンスが向上しています。

- 概要

- inCacheの仕組みの理解

- ノードの再起動

- リアルタイム・パブリッシュ時のページの再生成

- ダブルバッファ・キャッシング

- inCacheによるページ・キャッシングのためのシステムの構成

- チューニング・オプション

- AssetCacheコンテナの使用

- アセットのキャッシング操作の使用

- アセットのキャッシングのタイプ

- アセットのキャッシングのカスタマイズ

- アセットのキャッシングの無効化

- キャッシュ管理ツールの使用

- リモートのSatellite ServerのinCache機能の使用

25.1 概要

inCacheはメモリーベースのページおよびアセット・キャッシング・システムで、これを使用すると、WebCenter Sitesのデータを中央の共有リポジトリや共有ファイル・システムにキャッシュする必要がなくなります。inCacheは、Terracotta社によるオープン・ソースのJavaキャッシング・フレームワークであるEhcacheに基づいており、任意のキャッシング・システム上に実装できます。(Ehcacheの詳細は、http://ehcache.org/を参照してください。)

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

- Caching Frameworkの概要

- ページ・キャッシングの概要

- アセットのキャッシングの概要

25.1.1 Caching Frameworkの概要

inCacheフレームワークは、レガシーのページ・キャッシング・フレームワークに置き換わるものです。inCacheでは、デフォルトでアセットのキャッシングもサポートしています。inCacheフレームワークには次のような利点があります。

- 高パフォーマンス。レスポンスが速いので、パブリッシング・セッションの頻度を上げることができます。ページおよびアセットの効果的な無効化により、更新済コンテンツがすばやく提供されます。

- 分散化アーキテクチャ。ノードはそれぞれ独自のローカル・キャッシュを維持しています。inCacheフレームワークでは、データベースのキャッシングと共有ディスクが排除されています。

- ブロードキャスト・システム。個別のノードがキャッシュ全体の完全なビューを持つ必要がなくなりました。コンテンツへの変更をリスニングしているノードが、個々のコンテンツの必要に応じてブロードキャストに応答します。

- リニアなスケーラビリティが強化され、ディスクやメモリーのデータに対して拡張。

- フェイルオーバーと永続性。シャットダウンされたノードはローカル・キャッシュ内にデータを保持し、再起動時に、中央管理されている無効化のレコードに対して自己更新します。

- オンデマンドのページ評価と無効化。ノードは、コンテンツがリクエストされたときのみ、現在キャッシュされているコンテンツを有効化して更新します。

この章では、主にページ・キャッシングについて説明します。ここでは、「ページ」という用語を、ページ・アセットでなく、レンダリング済ページを意味するものとして使用します。アセットのキャッシングに関する説明を理解するために、この章、特にinCacheの仕組みの理解を最初に読み、キャッシュ・コンテナと、その相互に関連した機能に関する基本を理解しておくことをお薦めします。

25.1.2 ページ・キャッシングの概要

inCacheはディスクのストライプ化をサポートし、donoteregenerateフラグを非アクティブ化することでリアルタイム・パブリッシュに影響を与えます。リアルタイム・パブリッシュの間にページの再生成を有効にするオプションでは、配信システムのFW_RegenCriteria表に、クロールおよび再生成されるページのURLを移入する必要があります。ページ伝播も1つのオプションで、すべてのノードが同じページをホストするようにして、各ノードでページを再生成する必要をなくす場合に使用します。さらに、代替ページが再生成されるまでの少しの間、失効したページを引き続き提供するように、リモートのSatellite Serverを構成することもできます。

注意:

必要に応じて、次の手順を実行することで、レガシーのページ・キャッシング方法に戻すこともできます。

1. すべてのWebCenter SitesノードとSatellite Serverノードで、–Dcs.useEhcache=falseのようにVM引数を設定します

2. すべてのWebCenter SitesノードとSatellite Serverノードを再構成して、データベースと共有ファイル・システムを使用するようにします。

3. 無効化以降に古くなってしまっている可能性が高い状況での、操作を再開する前のレガシー・ページ・キャッシュの消去。

一般的に、キャッシュ方法を切り替える場合には、WebCenter SitesノードとSatellite Serverノードが同じキャッシュを使用するように再構成して、使用前にキャッシュを消去する必要があります(ベスト・プラクティスとして推奨)。

25.1.3 アセットのキャッシングの概要

アセットのキャッシングは、インストール時とアップグレード時にWebCenter Sitesシステム上で有効になります。アセットのキャッシングは、inCacheフレームワーク上に構築された、メモリーをベースにしたシステムで、そのままではデータベースに影響を与えるような負荷を担うことによってパフォーマンスを保護します。アセットのキャッシングにはAssetCacheコンテナという独自のコンテナが使用され、このコンテナは、他のinCacheコンポーネント(特にdependencyRepositoryキャッシュとnotifierキャッシュ)と相互に作用することによって機能します。

pageByQueryキャッシュは、アセットのキャッシングでは使用されませんが、キャッシュ・コンテナの仕組みの説明には便利です。それに相当するAssetCacheコンテナが同様に機能します。アセットのキャッシングとinCacheページ・キャッシングは、互いに独立に機能します。キャッシュの各タイプは、互いに関係なく有効または無効にできます。

AssetCacheコンテナの使用では、AssetCacheコンテナ、アセットのロードと無効化に関連する機能、アセット・キャッシングとページ・キャッシングの比較、およびアセットのキャッシングをアセット・タイプによってカスタマイズする方法について説明します。

25.2 inCacheの仕組みの理解

クラスタ化された環境では、inCacheはクラスタのデータベースの外側の分散化されたアーキテクチャに実装されます。図25-1に示すように、各ノードにはそれぞれ独自のローカル・キャッシュがあります。各WebCenter Sitesノードは、他のWebCenter Sitesノードからのブロードキャストをリスニングすることで、ローカル・キャッシュを最新に保ち、HTTPを介してリモートのSatellite Serverに更新を伝達します。

図25-1 ローカル・キャッシュ

ノードのローカル・キャッシュはパーティションで区切られています。

- pageByQryキャッシュには、ノードのWebページが格納されます。

- dependencyRepositoryキャッシュには、Webページを構成するアセットの識別子が格納されます。

注意:

pageByQryキャッシュは、ページ・キャッシュとも呼ばれます。dependencyRepositoryキャッシュは、依存性キャッシュとも呼ばれます。

- notifierキャッシュは、編集またはパブリッシュのプロセスで変更されたアセットの識別子をブロードキャストします。ブロードキャストは、アセットの変更されたノードによって開始されます。リスニングするノードがブロードキャストに応答する方法は、ノードによって異なります。例:

1. ノードAのWebCenter SitesユーザーがアセットAを編集します。

2. ノードAのnotifierキャッシュが、その他のすべてのノードに変更の通知をブロードキャストします。

3. アセットAを含むすべてのWebCenter Sitesノードが、それぞれ独自のローカル・キャッシュ内のアセットを無効化することで応答します。各ノードは独自のdependencyRepositoryキャッシュを参照し、アセットの識別子を無効にマークして、キャッシュ全体の依存性生成数を増分させます。無効化されたアセットは、そのアセットを参照するページで使用できなくなるので、これらのページそのものも無効になります。ただし、ノードは、ページがリクエストされるまでページを評価しません。ここにパフォーマンス上の利点があります。
無効化されたアセットに対する依存性を持つページのリクエストにノードが応答する場合、このノードはpageByQryキャッシュを参照し、ページを評価し、無効化するページを決定し、それをフラッシュし、新規ページを生成し、そのページを訪問者のブラウザに提示して、ローカル・キャッシュ内に新規ページとその依存性を記録します(依存性は、ページを構成するアセットの識別子として記録されます)。その時点から、ページが異常終了するか、アセットが再び無効化されるまで、ノードのローカル・キャッシュからは同じページが提示されます。

WebCenter SitesとSatellite Serverは同じキャッシング・フレームワークを使用していますが、Satellite Serverノードは、HTTPを介してWebCenter Sitesノードと通信しています。

注意:

pageByQueryキャッシュはページ・キャッシングにしか使用されませんが、キャッシュ・コンテナの仕組みの説明には役立ちます。アセットのキャッシングの場合、inCacheフレームワークでは、それに相当するAssetCacheという名前のコンテナが使用されます。それはpageByQueryと同様の方法で機能し、dependencyRepositoryおよびnotifierキャッシュと対話します。アセットのキャッシングの詳細は、アセットのキャッシング操作の使用を参照してください。

25.3 ノードの再起動

WebCenter SitesまたはSatellite Serverノードが停止している場合、そのキャッシュにあるデータは保持されますが、アクティブ・ノードが引き続きアセットを無効化するため、すぐに古くなります。その結果、ノードを再起動するには、それが持つキャッシュを更新する必要があります。再起動時の更新を保証するのが共通の無効化メモリーで、それはWebCenter Sitesクラスタのデータベースに表として格納され、クラスタのすべてのノードが再起動時に使用できる状態に維持されます。表の名前はFW_InvalidationMemoryです。

無効化メモリーには、アセット無効化のレコード(特に、コンテンツ管理またはパブリッシュ・プロセスで変更または削除されたアセットの識別子)が格納されます。15分間隔で実行されるクリーンアップ・メカニズムにより表の増大がチェックされ、最も古い期間の無効化レコードが破棄されます。

ノードは再起動時に、非アクティブであった期間に欠落した情報をリカバリしようとして、無効化メモリーを参照します。

- ノードの非アクティブ期間の無効化レコードが存在する場合、ノードは自分自身でリプレイします。

- 非アクティブ期間に無効化されたアセットが存在しない場合、ノードはシャットダウンされなかったかのように動作を続行します。

- ノードが非アクティブであった間にクリーンアップ・メカニズムによって無効化レコードが消去された場合、ノードのキャッシュは自らを破棄するので、再構築する必要があります。

リモートのSatellite Serverは、WebCenter Sitesに更新を求めるリクエストを送信することによって失った情報を、再起動時に取得します。

25.4 リアルタイム・パブリッシュ時のページの再生成

inCacheを有効にすると、リアルタイム・パブリッシュ・プロセス用のdonotregenerateフラグが無効になります。このフラグが認識されなくなるので、リアルタイム・パブリッシュ・セッション時のページの再生成には、クロールが使用されます。クローリングを実装していなければ、ページはリクエスト時のみ再生成されます。

クロール・オプションでは、ページ・リジェネレータによって分析される一連のURLを指定する必要があります。通常、これらはホームページやその他のトラフィックの多いページのURLです。それらのページをクロールする深さを指定することもできます。たとえば、深度1では指定したページとそれらのページのリンク先のページがクロールされ、0では指定したページのみがクロールされます。クロールされるページは、そのコンポーネント・アセットがパブリッシュ・セッション時に無効化された場合か、それらのページがキャッシュされていない場合のみ再生成されます。指定したページ上のすべてのページレットがプロセス内で再生成されます。

URLとクロール深度のリストを、inCache構成後の最初のパブリッシュ・セッション時に配信システム上で作成されるFW_RegenCriteria表で指定する必要があります。ft_ssパラメータをURLに含むことで、ページ・リクエストをWebCenter Sitesで直接処理するのか、リモートのSatellite Serverによって処理するのかを指定できます。inCacheの構成とページ再生成の有効化の詳細は、アセットのキャッシング操作の使用を参照してください。

25.5 ダブルバッファ・キャッシング

WebCenter Sitesのダブルバッファによるページ・キャッシング方法では、ライブWebサイト上でWebCenter SitesとSatellite Serverのキャッシュを連結させて使用します。ダブル・バッファリングでは、ページが常にWebCenter SitesかSatellite Serverのいずれかのキャッシュ内に保持され、ページ・リクエストの過負荷からWebCenter Sitesを保護し、ライブWebサイトで空白ページやリンク切れが表示されないようにします。

inCacheフレームワークで従来のシステムのダブルバッファ・キャッシングを維持するために、HTTPリクエストを介してリモートのSatellite ServerはWebCenter Sitesと通信を続けるようになっています。Satellite Serverはこれまでどおりの方法で、HTTPリクエストを介してページ・データを読み取ってキャッシュします。ただし、ページ・データには、アセット識別子のカンマ区切りのリスト形式で依存性情報が含まれるようになり、この情報はリモートのSatellite Serverにもストリームされます。

25.6 inCacheによるページ・キャッシングのためのシステムの構成

この構成プロセスは、一連の必須の手順とオプションの最適化手順によって構成されます。たとえば、複数のWebCenter Sitesノードの相互通信を有効にして、WebCenter SitesとリモートのSatellite Server上の各ローカル・キャッシュのストレージ・プロパティを設定します。

inCacheページ・キャッシング用にシステムを構成するには::

1. inCacheによるページのキャッシングが有効になっていることを確認します。VM引数–Dcs.useEhcacheを検索して、これがtrueに設定されているか、何も設定されていない(その場合の値はtrueと想定される)かのどちらかであることを確認します。

2. システムの再起動時に、WebCenter SitesノードとSatellite Serverノードのそれぞれで、キャッシュ・コンテンツが保持されるように構成します。次のVM引数を渡します。

–Dnet.sf.ehcache.enableShutdownHook=true

3. オプションの最適化。各WebCenter SitesおよびSatellite ServerノードにdiskStoreパスを設定します。複数のノードが同じシステム上にある場合(垂直クラスタ)は、各ノードが固有のdiskStoreパスを持っていることを確認します。cs-cache.xmlおよびss-cache.xmlファイルで、diskStore path="<path to disk store>"プロパティを設定します。両方のxmlファイルが各WebCenter Sitesノードに格納されます。cs-cache.xmlはWebCenter Sites酔うで、ss-cache.xmlは共存するSatellite Server用です。リモートのSatellite Serverにはss-cache.xmlファイルのみが格納されます。これらのファイルはWEB-INF/classesフォルダの下に配置されます。
diskStoreプロパティに関する詳細は、次のEhcache Webサイトにあるドキュメントを参照してください。

http://ehcache.org/documentation/configuration.html

注意:

inCacheは、WebCenter Sites、リモートのSatellite Server、共存するSatellite Serverに存在しています。アーキテクチャと機能の面で、共存するSatellite ServerとリモートのSatellite Serverに存在しているinCacheは同じものです。ただし、共存するSatellite Serverには次の推奨事項が適用されます。

- ディスクの永続性をオフにします。

- 各キャッシュのサイズは、WebCenter Sitesのキャッシュ・サイズよりも小さくします。これはメモリーの過負荷を防ぐためです。共存するSatellite Server上の完全なダブルバッファ・キャッシングに対する要件などの特別な状況を除いて、このサイズは小さくしておくことをお薦めします。

4. inCacheポートの構成。inCacheは、クラスタ・メンバー間の通信には、EhcacheのRMIベースのトランスポート・メカニズムを使用します。通常、これに追加の設定は不要ですが、Ehcacheが使用する正確なポートを指定することは可能です。クラスタ・メンバー間にファイアウォールがある場合、これは特に重要です。
特定のポートを使用するようにEhcacheを構成する方法の詳細は、次のEhcache Webサイトのドキュメントを参照してください。

http://ehcache.org/files/documentation/EhcacheUserGuide-1.6.pdf

5. 複数のノードに必要な手順です。WebCenter Sitesクラスタに対して自動ノード検出を構成します(Satellite Serverノードはクラスタ化できません)。例として、この手順では、CS1、CS2、CS3という名前の3つのWebCenter Sitesノードを使用します。

注意:

ある場合には、inCacheノード・ネットワーク上のファイアウォールにより、ノード間の通信が阻害されます。複数のノードにinCacheをインストールして構成する場合、それらのファイアウォールを無効にします。検証が済んだら、システム管理者/ネットワーク管理者は、inCacheテストおよびRemote Satellite Serverへのページ伝播の際にポートを監視し、それに応じてファイアウォールを適応させてください。

a. 各WebCenter Sitesノードで、cs-cache.xmlとss-cache.xml (WEB-INF/classesにある)でcacheManagerPeerListenerFactoryが指定されていることを確認します。これはCacheManagerPeerProviderを作成するために使用されます。このプロバイダがクラスタ内の他のノードを検出します。次の例に示すように、自動検出を構成します。

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMCacheManagerPeer
ProviderFactory"
properties="peerDiscovery = automatic,
multicastGroupAddress = 230.0.0.1,
multicastGroupPort = 4444, timeToLive = 32"/>

注意:

multicastGroupPortプロパティは、クラスタ・メンバー全体に対して同一に設定する必要があります。たとえば、CS1のcs-cache.xmlファイル内でmulticastGroupPort=4444と指定されている場合、CS2とCS3でもそれぞれのファイル内で同じ設定を指定する必要があります。

timeToLiveプロパティは、1つのパケットに対して許可されるホップの数を指定するもので、これによってパケットの伝播距離が決まります。有効な値範囲は、0から255の間で、次の制約があります。

- 0: 同一ホスト

- 1: 同一サブネット

- 32: 同一サイト

- 64: 同一範囲

- 128: 同一大陸

- 255: 無制限

b. すべてのSatellite Server(共存およびリモート)で、次のいずれかを実行します。

- 各ss-cache.xmlファイル内のmulticastGroupPortプロパティを一意の値に設定します。

- キャッシュのレプリケーションをサポートする場合は、各ss-cache.xmlファイル内のmulticastGroupPortプロパティを同一の値に設定します。

注意:

ss-cache.xmlファイルに設定する値は、cs-cache.xmlファイル内にあるWebCenter SitesのmulticastGroupPortプロパティとは別の値にする必要があります。

inCacheが構成されている場合、cs-cache.xmlおよびss-cache.xmlに指定された構成を使用してシステムが起動します。キャッシュは、WebCenter Sites内のいずれかのページ(キャッシュされるかどうかにかかわらず)を最初にコールした時点で初期化されます。

6. オプションの最適化。必要に応じて、表25-1をプロパティ・リファレンスとして使用して、ローカル・キャッシュを構成します。WebCenter SitesとリモートのSatellite Serverの各ノードのローカル・キャッシュは、パーティションで区切られています。各部分は、cs-cache.xmlファイルとss-cache.xmlファイルにある独自の<cache>タグで定義されます。各部分の名前は次のとおりです。

- pageByQry: ページ・データそのもののキャッシュで、問合せのURLによるキーが設定されています。

- dependencyRepository: ページ構築の基礎となる依存性のキャッシュです。pageByQryキャッシュにページが追加されると、dependencyRepositoryキャッシュにエントリが自動的に作成されます。このキャッシュ内の各エントリは、アセットのid、unknowndepまたはunknowndep-<type>のいずれかです。したがって、このキャッシュには最大でもシステム内のアセット数と、様々なバリエーションのunknowndepの少数のアイテムが格納されるのみです。
依存性のないページがキャッシュされると、そのページが_NODEP_ (依存性のないページの識別に使用されるdependencyRepositoryキャッシュ内の1つのアイテム)に依存性をログ記録します。_NODEP_アイテムとページとの関連付けは、そのページが異常終了するか手動でフラッシュされるまで維持されます。リモートのSatellite Serverでは、(Satellite Serverごとに)JVMオプションの

-Dignore_nodep_pagesをtrueに設定することで、依存性のないページのキャッシュを無効にできます。

- notifier: このキャッシュは、アクティブなWebCenter Sitesクラスタ・メンバーが他のWebCenter Sitesクラスタ・メンバーにコンテンツの変更を通知するために使用します。

7. 構成されたすべてのWebCenter SitesノードとSatellite Serverノードを再起動します。

8. すべてのアクティブなクラスタ・メンバーがキャッシング・ネットワーク内にあり、互いを認識していることを検証します。「クラスタ情報」診断ツールを使用すると、notifierキャッシュを持つすべてのWebCenter Sitesメンバーがリストされます。「クラスタ情報」をコールするには:

a. キャッシュ可能なページをレンダリングすることで、inCacheをブートストラップします。

b. 一般管理者(デフォルトではfwadmin/xceladmin)として、WebCenter Sites Adminインタフェースにログインします。

c. WebCenter Sitesのクラスタ・メンバーと、共存するSatellite Serverが、相互に通信していることを確認します。「管理」タブを開き、「システム・ツール」、「キャッシュ管理」、「Sitesキャッシュ」の順に開き、「クラスタ情報」をダブルクリックします。

図25-2 「クラスタ情報」フォーム

キャッシュ構成ツールでは、様々なタイプのページ・キャッシュ統計を使用できます。詳細は、システム・ツールを使用したトラブルシューティングを参照してください。

9. ディスク・ストライプの必要がある場合は、リアルタイム・パブリッシュ時のページの再生成を有効にするか、ページ伝播を有効にします。詳細は、チューニング・オプションを参照してください。

表25-1 キャッシュ構成プロパティ

プロパティ

必須かどうか

説明

name

Y

キャッシュの名前を指定します。

有効な値:

- pageByQry

- dependencyRepository

- notifier

詳細は、手順5を参照してください。

diskPersistent

N

JVMの再起動と再起動の間にディスク上にデータを保持するかどうかを指定します。

デフォルト/推奨値: true

注意: diskPersistent設定は、生成数で競合が発生する可能性をなくすために、PageByQry、dependencyRepositoryおよびnotifierの各キャッシュ間で一貫性を保つ必要があります。

maxElementsInMemory

Y

メモリーに格納するオブジェクトの最大数を指定します。

デフォルト値: 200000

maxElementsOnDisk

Y

ディスクに格納するオブジェクトの最大数を指定します。ディスクはストライプ化できます。詳細は、ディスク・キャッシュのストライプ化を参照してください。

デフォルト値: 1000000

eternal

Y

WebCenter Sitesによってキャッシュを消去するかどうかを指定します(inCacheによって消去されることはありません)。

デフォルト値: true

このプロパティの値を変更しないでください。

overflowToDisk

Y

メモリー・キャッシュをディスクベースのキャッシュにオーバーフロー可能にするかどうかを指定します。

デフォルト値: true

このプロパティの値を変更しないでください。

diskSpoolBufferSizeMB

N

ディスク・バッファのサイズを指定します(MB単位)。大量のディスクI/Oが予想される場合(ディスク・キャッシュがメモリー・キャッシュよりはるかに大きい場合など)は、バッファを20MBに設定します。

デフォルト値: 5。

memoryStoreEvictionPolicy

N

キャッシュからアイテムを削除する方法を指定します。推奨されるデフォルト値は、LFU (Least Frequently Used: 最低アクセス頻度)です。LRU (Least Recently Used: 最低使用頻度)も適切な値です。

デフォルト/推奨値: LFU

clearOnFlush

N

メモリーがディスクにフラッシュされるときにこれを消去するかどうかを指定します。

デフォルト値: false

このプロパティの値を変更しないでください。

25.7 チューニング・オプション

inCacheフレームワークには多くのオプションがあり、システムにあわせて最適化できます。この項には、それらのオプションをまとめました。

- ディスク・キャッシュのストライプ化

- リアルタイム・パブリッシュ時のページの再生成の構成

- ページ伝播の設定

- バックグラウンドでページレットを再生成するための構成

25.7.1 ディスク・キャッシュのストライプ化

inCacheフレームワークでは、キャッシュの大部分をディスクに書き込む必要があるときに発生する競合をなくすために、pageByQryキャッシュのストライプ化をサポートしています。

inCacheフレームワークでは、WebCenter SitesノードとリモートのSatellite Serverに対して次の手順を実行します。

pageByQryキャッシュをストライプ化するには::

1. ストライプ化を有効にするには次のVM引数を追加します。ここで、Xがストライプの数です。

–DnumOfDiskStores=X

ストライプ数は、ストライプ化できる一意のスピンドルの数に設定します(たとえば、5つのドライブがある場合はXを5に設定します)。

注意:

ディスクベースのキャッシュのストライプ化に使用するドライブは、その他の目的には使用できません。

各DiskStoreのサイズは、xml構成ファイル内のmaxElementsOnDiskプロパティによって指定されているサイズです(表25-1 を参照)。たとえば、5つのストライプを使用しており、maxElementsOnDiskが100000アイテムに設定されている場合、合計で500000アイテムを格納できます。

2. シンボリック・リンクを作成するか、ドライブを物理的に正しい場所にマウントして、ストライプが適切に分散されるようにします。

定義された各キャッシュ用のディレクトリが、diskStoreパス(ページ伝播の設定の手順3で構成)の下に作成されます。各ディレクトリの下にも、0で始まる番号の付いた一連のディレクトリが作成されます。各ディレクトリは別々のドライブを指しています。

たとえば、–DnumOfDiskStores = 5と設定した場合、アイテムは、WebCenter Sitesのディスクベースのキャッシュ内に次のように格納されます。

<custom_path>/cs-cache:
Directory: 0
Directory: 1
Directory: 2
Directory: 3
Directory: 4
File: dependencyRepository.data
File: dependencyRepository.index
File: notifier.data
File: notifier.index
<custom_path>/cs-cache/0:
File: pageByQry.data
File: pageByQry.index
<custom_path>/cs-cache/1:
File: pageByQry.data
File: pageByQry.index
<custom_path>/cs-cache/2:
File: pageByQry.data
File: pageByQry.index
<custom_path>/cs-cache/3:
File: pageByQry.data
File: pageByQry.index
<custom_path>/cs-cache/4:
File: pageByQry.data
File: pageByQry.index

この例では、ルート・キャッシュに依存性とnotifierキャッシュが格納されています。ディレクトリ0から4に拡散しているのは、pageByQryキャッシュのストライプです。この例の0から4のディレクトリは、シンボリック・リンクの使用によって5つの別個のドライブに配置されました。

25.7.2 リアルタイム・パブリッシュ時のページの再生成の構成

ページは、リクエストされた場合のみ再生成されます。

リアルタイム・パブリッシュ時のページの再生成を構成するには::

1. デフォルトでは、PageCacheUpdaterが、WebCenter Sitesインストーラによって、ParallelCacheRegeneratorを使用するように設定されます。
WebCenter Sitesの配信システム上のWEB-INF/classesフォルダにあるAdvPub.xmlファイルを開き、PageCacheUpdaterセクションに次に示すコード行があることを確認します。

注意:

次に示すもの以外は、PageCacheUpdaterセクションの値を変更しないでください。

- numThreadsPerServer: クロールするときの同時スレッド数を指定します。

- regenServers: <address>と<port of server where pages will be regenerated>によって、WebCenter Sitesノードを指定します

<bean id="PageCacheUpdater"
class="com.fatwire.realtime.regen.ParallelRegeneratorEh" singleton="false">
<property name="id" value="CacheFlusher" />
<property name="numThreadsPerServer" value="3" />
<property name="regenServers">
<list>
<value>http://address:port of server where pages are regenerated/
servlet/ContentServer</value>
</list>
</property>
</bean>

2. 配信システムを再起動します。

3. WebCenter Sitesの配信システムに対してリアルタイム・パブリッシュが行われ、そのシステム上にFW_RegenCriteria表が作成されます。

4. Oracle WebCenter Sites Explorerを使用して、FW_RegenCriteria表を開きます。再作成するページと、フォローするリンクの深さ指定します。ft_ssパラメータをURLに含むことで、ページ・リクエストをWebCenter Sitesで直接処理するのか、リモートのSatellite Serverによって処理するのかを指定できます。

注意:

URLアセンブラを使用する場合は、クロールするページの内部URLを指定します。リジェネレータはURLアセンブラのURLを認識しません。

例:

pagename=SiteName/HomePage&ft_ss=true
Level=1

WebCenter SitesによってHomePageと、HomePageからリンクされるページが再生成されます。ft_ss=trueと指定した場合、Satellite Serverで生成されたもののように、リクエストが処理されます。

5. WebCenter Sitesの配信システムにリアルタイム・パブリッシュを行います。
パブリッシュ・セッションの間、配信システムはFW_RegenCriteria表で指定されたすべてのページをクロールしますが、再生成するのはコンポーネント・アセットが無効化されたものだけです(未キャッシュのページも生成します)。

例:

a. 更新されたアセットが配信システムにパブリッシュされます。

b. 配信システムは、dependencyRepositoryキャッシュ内でアセットの識別子を無効にマークし、依存性生成数を増分させることで、再パブリッシュされたアセットの既存の依存性情報を無効化します。無効化されたアセットは、そのアセットを参照するページで使用できなくなるので、これらのページも無効になります。

c. ページ・リジェネレータは、FW_RegenCriteria表に指定されているURLを使用してページをクロールし、無効化されたページを再生成します。さらに、未キャッシュのページも生成します。

25.7.3 ページ伝播の設定

ページ伝播によって、WebCenter Sitesクラスタ内のすべてのノード(Satellite Serverノードを含む)が同じページをホストでき、それぞれのノードがページを再生成する必要がなくなります。

inCacheを使用するように構成した場合は、各WebCenter Sitesが別個のJVMを持ち、別々のローカル・キャッシュを維持することになります。1つのWebCenter Sitesによって新しいページが生成され、キャッシュされても、その他のWebCenter Sitesで新しくページがキャッシュされたり、そのページについて通知されることはありません。同じページに対するリクエストを受信すると、各ノードがデータベースや共有のファイル・システムを参照することでそのページを生成する必要があり、両方のコンポーネントに余分な負担が課せられます。ページ伝播では、クラスタ全体にページが伝播されるので、別々のノードが同じページを再生成しなくてもよくなります。

ページ伝播は、ノードのローカル・キャッシュにページがロードされたときに引き起こされます。この機能は、inCacheの基本機能から始まる、次のシナリオに示すように機能します。

1. 新しく生成されたページに対するinCacheのページ・キャッシング:

a. ノードA (WebCenter Sitesノード)が、新規ページのリクエストを受信します。

b. ノードAが、リクエストされたページを生成します。

c. ノードAは、新規ページと完全な依存性情報(コンポーネント・アセットの識別子)を、ローカル・キャッシュと依存性キャッシュにキャッシュします。

d. ページ伝播が有効な場合は、手順3に続きます。

2. 再生成されたページに対するinCacheのページ・キャッシング:

a. ノードBもWebCenter Sitesノードで、無効化されたページに対するリクエストを受信します(コンポーネント・アセットが変更されました。このアセットは、ノードBのローカルの依存性キャッシュと、アセットを含むその他すべてのノードの依存性キャッシュで、無効としてマークされています)。

b. ノードBが、リクエストされたページを再生成します。

c. ノードBは、再生成されたページをキャッシュし、生成数を増分させることで依存性を更新します(手順2a)。

d. ページ伝播が有効な場合は、手順3に続きます。

3. ページ伝播によるinCacheのページ・キャッシング:
ノードは、ページを(再)生成するときに、その他のノードにもこのページを伝播します。伝播される情報は、次の内容で構成されています。

- ページの完全な依存性情報。たとえば、ページにxの依存性(アセット識別子)が存在する場合は、xの依存性がすべて、ローカルの依存性キャッシュから他のWebCenter Sitesノードの依存性キャッシュに伝播されます。

- ページ自体。ページは、ローカルのページ・キャッシュから他のWebCenter Sitesノードのページ・キャッシュに伝播されます。

受信側のノードにページが存在している場合、そのノードは伝播を無視します。

次のリストでは、ページ伝播のイベントと条件をまとめています。

- WebCenter Sitesノードでページがキャッシュされた場合、その完全なページ情報(前述の手順3を参照)が、その他すべてのWebCenter Sitesノードに伝播されます。

- リモートのSatellite Serverノードでページがキャッシュされた場合、その完全なページ情報(前述の手順3を参照)が、Java RMI (Remote Method Invocation)を経由して他のSatellite Serverに伝播されます。

- ページが伝播されると、次のような処理が行われます。

- そのページの最終更新時のタイムスタンプが、すべてのWebCenter SitesノードとSatellite Serverノードで保持されます。

- 所定のノードの再生数が、その他すべてのノードの再生数とは無関係に維持されます。たとえば、ノードAの再生数が10でも、他のノードは別のタイプの依存性の生成数に10を使用します。WebCenter SitesまたはSatellite Serverすべてに同じオブジェクトが伝播されても、WebCenter SitesノードまたはSatellite Serverノードごとに異なる生成数が割り当てられる場合もあります。オブジェクトとその最終更新/変更時間のタイムスタンプは、ノード全体で同じになります。

- そのページが存在しているノードでは、伝播が無視されます。

- キャッシュされたページの依存性を、そのページの存在しないノードに伝播できなかった場合、そのページがノード上でリクエストされて生成されるまで、ページはノード上にキャッシュされません。

- それでもSatellite ServerキャッシュにはBLOBが格納されているので、それがSatellite Server全体にレプリケートされます。

この項の内容は次のとおりです。

- ページ伝播の有効化

- 再起動時のページ伝播の設定

25.7.3.1 ページ伝播の有効化

inCacheを使用するように構成されたシステムを起動します。

ページ伝播を有効化するには::

1. すべてのWebCenter Sitesノード上で、次の手順を実行します。

a. プロパティ管理ツールで、propagatecache=trueを設定します。すべてのノードにこのプロパティを設定するために、「グローバル」を選択します。

b. cs-cache.xmlで、クラスタ内のすべてのWebCenter Sitesノードに対するmulticastGroupPortが同一で、相互に通信可能であることを確認します。(このファイルはWEB-INF\classesにあります。)

2. すべてのリモートのSatellite Serverで、次の手順を実行します。

a. リモート・サテライト・サーバーのwcs_properties.json ファイルで、propagatecache=trueを設定します。このファイルはconfigフォルダにあります。

注意:

Satellite Serverのconfigフォルダは、インストール時に、ユーザー定義の場所に配置されます。クラスタ化環境の場合、推奨される場所は、サイト共有ディレクトリ(<WCSITES_SHARED DIR>)配下です。非クラスタ化環境の場合、推奨される場所は、ホーム・ディレクトリ(<WCSITES_PRODUCT HOME>)の外です。configフォルダがない場合、インストールのエンジニアに問い合せてください。

b. ss-cache.xmlで、キャッシュ伝播するつもりのすべてのSatellite ServerでmulticastGroupPortが同一であるが、WebCenter SitesノードのmulticastGroupPortとは異なっていることを確認します。

3. すべてのノードで、任意のページをレンダリングすることでページ伝播を初期化して、システムが次のように応答することを確認します。

- WebCenter Sitesノードでは、ページのキャッシュによって、ローカル・キャッシュから他のWebCenter Sitesノードのキャッシュへの伝播が引き起こされます(ページ伝播の設定の手順3を参照)。この間、すべてのWebCenter Sitesにわたり、ページの最終更新/変更時間のタイムスタンプが保持されます。そのページが存在しているWebCenter Sitesノードでは、伝播が無視されます。

- Satellite Serverでの応答は、WebCenter Sitesノードでの応答と同じですが、こちらはJava RMIを経由しています。

25.7.3.2 再起動時のページ伝播の設定

ノードに対して再起動時のページ伝播を有効にする場合、ノードがページ伝播を認識するために、ローカル・キャッシュを再初期化する必要があります。

ローカル・キャッシュを再初期化するには:

1. ノード上のキャッシュ可能なページをレンダリングします。
キャッシングによって、ノードが他のノードにページを伝播し、他のノードによって伝播されたページを認識します。

2. ノードを再起動します。ノードが非アクティブだった期間に実行されなかった伝播は、そのローカル・キャッシュが再初期化されても、ノードで再現されません。

25.7.4 バックグラウンドでページレットを再生成するための構成

リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。

無効化されたページレットを提供できるようにするには:

- リモートのSatellite Serverのwcs_properties.jsonファイル(クラスタ化環境の場合、WCSites_Shared_Dir配下、非クラスタ化環境の場合、WCSites_Product_Home配下にあります)に、serveStale=trueを追加します。
それでもページレットが無効化されている場合は、次の方法で再生成します。

- ブラウザが次の30分以内にページレットをリクエストする場合、リモートのSatellite Serverによって、ページを再生成するためのリクエストをWebCenter Sitesに送信するプロセスが、バックグラウンドで開始されます。バックグラウンド・プロセスの実行中、ブラウザには、リモートのSatellite Serverのキャッシュから、無効化されたページレットが提供されます。これ以降すべてのリクエストで、バックグラウンド・プロセスによってページレットが再生成されるまで、無効化されたページレットが提供されることになります。

- ブラウザが30分経過後にページレットをリクエストする場合、リモートのSatellite Serverは通常のプロセスを使用してページレットを再生成します。つまり、ページレットを再生成するためのリクエストがWebCenter Sitesに送信されます。リクエスト側のブラウザは、ページが再生成されるまで待機する必要があります。

- バックグラウンド・プロセスに関する情報を入手するには、logging-config.propertiesファイルで、com.fatwire.logging.cs.cache.ehcache loggerをDEBUGに設定します。
DEBUGによって、バックグラウンド・プロセスの開始時には次のメッセージが作成されます。

"Data for <cache key> is found to have been invalidated.
A new request has started processing new data in the background."

プロセスの後で、次のメッセージが表示されます。

"Background process for request <cache key> has completed successfully,
data in cache is updated."

25.8 AssetCacheコンテナの使用

WebCenter Sitesでは、アセットのプログラム的な使用は、その属性のロードと読込みで構成されます。アセットは、WebCenter Sitesに格納されているテンプレートによってロードされるため、AssetCacheはWebCenter Sitesノードでのみ使用されます。

- AssetCacheは、inCacheフレームワークのコンポーネントです。pageByQryキャッシュと同様に、AssetCacheはinCacheフレームワーク内で各WebCenter Sitesノード下の独自のコンテナとして個別に使用できます。

- AssetCacheコンテナは、各WebCenter Sitesのcs-cache.xmlファイル内でデフォルトで有効になっており、ここでは<cache>エレメントという名前で呼ばれています。AssetCacheコンテナは、すべてのタイプのアセットをキャッシングし、次に示すinCacheコンポーネントと相互に作用することで機能します。特定のタイプのアセットについては、追加のAssetCacheコンテナを構成できます。詳細は、アセットのキャッシングのタイプおよびアセットのキャッシングのカスタマイズを参照してください。

- dependencyRepositoryキャッシュとの相互作用
AssetCacheにアセットをロードすると、表25-2 に示すように、inCacheがdependencyRepositoryキャッシュ内にエントリを作成することで、そのアセットへの依存性をログ記録します。そのアセットを変更または保存すると、dependencyRepositoryキャッシュから依存情報が削除されるので、AssetCacheではこのアセットのエントリが無効になります。一般に、キャッシュされたアセットに対して保存または削除操作を実行すると、そのアセットは無効になります。

注意:

アセットのキャッシングが有効になっている場合、Oracle WebCenter Sites ExplorerまたはCatalogManager APIを使用してデータベース表にアセットを直接保存したり削除しないでください。この方法で保存および削除操作を実行しても、アセットのキャッシュは無効になりません。

- notifierキャッシュとの相互作用
どれか1つのノードで無効化が行われると、notifierキャッシュによって他のノードに反映されます。このキャッシュは、どのアセットが変更されたかという情報を広める働きをします。受信したノードのAssetCacheにそのアセットが含まれている場合、そのノードはこの情報に従って独自のdependencyRepositoryキャッシュを更新します。

表25-2は、アセットのキャッシングがページ・キャッシングと独立して機能するが、なおも様々なキャッシュ・コンテナを共有する仕組みを示しています。

表25-2 アセットとページのキャッシングで使用されるキャッシュ・コンテナ

アセットのキャッシング機能

ページのキャッシング機能

AssetCacheコンテナ

pageByQryコンテナ

dependency Repositoryコンテナ

notifierコンテナ

オフ

オフ

未使用

未使用

未使用

未使用

オフ

オン

未使用

ページのキャッシングで使用

ページのキャッシングで使用

ページのキャッシングで使用

オン

オフ

アセットのキャッシングで使用

未使用

アセットのキャッシングで使用

アセットのキャッシングで使用

オン

オン

アセットのキャッシングで使用

ページのキャッシングで使用

アセットのキャッシングとページのキャッシングで使用

アセットのキャッシングとページのキャッシングで使用

25.9 アセットのキャッシング操作の使用

この項の内容は次のとおりです。

- アセット・ローディングの使用

- アセットのキャッシングとinCacheのページ・キャッシングの比較

- AssetCacheのフラッシュ

25.9.1 アセット・ローディングの使用

アセットのデータは、APIまたはasset:loadタグを使用する複数の方法で読み込むことができます。

- 次のAPIは、アセットを、readonly_completeモードでAssetCacheにロードします。

- AssetDataManager.read(AssetId)

- アセットに対するREST API GET

- 次のタグは、アセットをAssetCacheに、様々なモードでロードします。

- asset:load(objectid="cid1" option="editable")

- asset:load(objectid="cid1" option="readonly")

- asset:load(objectid="cid1" option="readonly_complete")

optionパラメータでは、アセットをキャッシュするかどうかと、AssetCacheおよびdependencyRepositoryでの、キャッシュされたアセットのキーの命名方法を決定します。キャッシングのシナリオを、図25-3 にまとめます。シナリオDでは、AssetCacheコンテナに同じアセットの複数のエントリが存在しています。これは、アセットがreadonlyおよびreadonly_completeという2つのモードでロードできるためです。

次のモードでは、アセットをキャッシュするかどうかと、AssetCacheおよびdependencyRepositoryでの、キャッシュされたアセットのキーの命名方法が決定されます。

図25-3 アセットのキャッシングのシナリオ

25.9.2 アセットのキャッシングとinCacheのページ・キャッシングの比較

図25-4 に示すように、キャッシュされたアセットとページ、さらにそれぞれの依存性では、キーの名前が異なります。この違いを理解することは、(「管理」タブの「システム・ツール」ノードにある)キャッシュ管理ツールに表示されるキャッシング情報の解析に役立ちます。

図25-4 アセットのキャッシングとページ・キャッシングにおける依存性の命名規則

たとえば、図25-4は、AssetCacheコンテナにおいて、キャッシュされたアセットのキーの名前がassettype:cid1:2であることを示しています。ここで最後の整数は、アセットが読み取られたモードを示します(2はreadonlyモード)。同じアセットがreadonly_completeモードでもロードされた場合、そのキーはassettype:cid1:3になります。アセットが複数のモードでコールされた場合、AssetCacheコンテナにはそのアセットに対する複数のエントリが確認されます(図25-3を参照)。

キャッシュされたページのキーは、pagenameで始まります。ページにはモードは適用されません。ページのキャッシュは1度しか行われません。

アセットのロードのモードの詳細は、アセット・ローディングの使用を参照してください。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。

25.9.3 AssetCacheのフラッシュ

アセットは、次のAPIやタグ経由で保存された場合、AssetCacheからフラッシュすることができます。

- API

- REST API PUT

- AssetDataManagerWrite

- JSPタグ

- asset:save

- asset:saveall

- asset:delete

- asset:deleteassettype

- asset:void

- asset:rollback

- asset:deleterevision

- asset:undocheckout

- insite:edit

- XMLタグ

- INSITE.EDIT

- ASSET.VOID

- ASSET.SAVE

- ASSET.SAVEALL

- ASSET.DELETE

25.10 アセットのキャッシングのタイプ

WebCenter Sitesノードでアセットのキャッシングを有効にすると、そのノードにあるcs-cache.xmlファイルには、次の<cache>エレメントのどれか1つ以上が格納されます。

- デフォルトの<cache>エレメント。すべてのタイプのアセットが、AssetCacheという名前の汎用のキャッシュ・コンテナにキャッシュされるように指定します。

<cache name="AssetCache"
diskPersistent="true" maxElementsInMemory="100"
maxElementsOnDisk="100" eternal="true" overflowToDisk="true"
diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU"
clearOnFlush="false" />

汎用のAssetCacheコンテナは、WebCenter Sitesのインストール・プロセス中に、すべてのWebCenter Sitesノードで自動的に構成されます。

- カスタムの<cache>エレメント。特定のタイプのアセットが、AssetCacheAsset_type_nameという名前の独自のコンテナにキャッシュされるように指定します。

<cache name="AssetCacheAsset_type_name"
diskPersistent="true" maxElementsInMemory="100"
maxElementsOnDisk="100" eternal="true" overflowToDisk="true"
diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU"
clearOnFlush="false" />

タイプ固有のすべてのカスタムAssetCacheコンテナは、cs-cache.xmlファイル内で手動で構成する必要があります。タイプ固有のコンテナの作成数は、独自のコンテナにキャッシュする必要のあるアセットのタイプと、各コンテナのキャッシングに適用する必要のある条件によって異なります。

汎用のAssetCacheコンテナを、1つまたは多数のタイプ固有のアセット・キャッシュと共存させるか、あるいはそれらによって置き換えることができます。アセットがキャッシュするすべてのコンテンツは、排他的です。つまり、汎用のAssetCacheコンテナでは、タイプ固有のコンテナにキャッシュされているアセット・タイプは除外され、タイプ固有のコンテナでは、その他すべてのタイプのアセットが除外されます。

さらに、アセットのキャッシングが有効になっている場合、(「管理」タブの「システム・ツール」ノードにある)キャッシュ管理ツールには、AssetCacheコンテナのコンテンツ、dependencyRepository内の対応するエントリ、その他のタイプの情報を示すダイアログが表示されます。検索もサポートされます。

アセットのキャッシングの構成の詳細は、アセットのキャッシングのカスタマイズを参照してください。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。

25.11 アセットのキャッシングのカスタマイズ

次の手順は、タイプ固有のアセット・キャッシュの構成方法を示しています。

アセットのキャッシングを構成するには::

1. WebCenter Sitesノードでデフォルトのアセットのキャッシングが有効になっている場合は、WebCenter Sitesノードのcs-cache.xmlファイルに次のエントリが表示されます。これは、すべてのタイプのアセットがAssetCacheという名前の汎用コンテナにキャッシュされることを指定するものです(name以外のパラメータは表25-2で定義されています)。

<cache name="AssetCache"
diskPersistent="true" maxElementsInMemory="100"
maxElementsOnDisk="100" eternal="true"
overflowToDisk="true" diskSpoolBufferSizeMB="20"
memoryStoreEvictionPolicy="LFU" clearOnFlush="false" />

注意:

汎用のAssetCacheコンテナを、1つまたは多数のタイプ固有のアセット・キャッシュと共存させるか、あるいはそれらによって置き換えることができる場合は、次のいずれかを実行することができます。

- 汎用のAssetCacheコンテナを保持し、タイプ固有のコンテナを必要な数だけ追加することができます。すべてのタイプのアセットがキャッシュされます。独自のタイプ固有のコンテナがあるアセットは、それぞれの独自のコンテナに排他的にキャッシュされ、表25-2に示されているパラメータを使用することで、個別にチューニングすることができます。

- 汎用のAssetCacheコンテナを、1つ以上のタイプ固有のコンテナで置き換えることができます。名前の付いたタイプのアセットのみがキャッシュされます。

AssetCacheコンテナの作成数は、独自のコンテナ内に作成する必要のあるアセットのタイプと、適用する必要のあるチューニングによって異なります。構成情報は、次の手順で使用できます。

2. 独自のコンテナ内の特定のタイプのアセットをキャッシュするには、そのアセット・タイプの<cache>エレメントを作成し、name="AssetCacheAsset_type_name"を設定します(カスタムの<cache>エレメント1つに対して1つのアセット・タイプのみがサポートされます)。表25-2 に示されたパラメータを使用して、キャッシュを構成します。

例:

<cache name="AssetCacheContent_C"
diskPersistent="true" maxElementsInMemory="100"
maxElementsOnDisk="100" eternal="true"
overflowToDisk="true" diskSpoolBufferSizeMB="20"
memoryStoreEvictionPolicy="LFU" clearOnFlush="false" />

この例では、name="AssetCacheContent_C"によってタイプ固有のAssetCacheコンテナが作成され、そこにはタイプがContent_Cのアセットのみが保持されます。汎用のAssetCacheコンテナも構成された場合、そこにはタイプがContent_Cのアセットはキャッシュされません。

25.12 アセットのキャッシングの無効化

アセットのキャッシングをサポートするようにinCacheフレームワークが設定されているときに、アセットのキャッシングを無効化する場合は、次の手順を実行します。

inCacheフレームワークの各WebCenter Sitesノードで、cs-cache.xmlファイル(WEB-INF/classes/ディレクトリにある)を開き、名前がAssetCacheで始まる<cache>エレメントを削除します。選択した<cache>エレメントを削除するか、すべての<cache>エレメントを削除することができます。それぞれのエレメントはAssetCacheコンテナを表しています。AssetCacheコンテナのタイプの詳細は、アセットのキャッシングのタイプを参照してください。

25.13 キャッシュ管理ツールの使用

アセットのキャッシングを構成する場合、キャッシュ管理ツールには、AssetCacheコンテナのコンテンツ、それに対応するdependencyRepository内のエントリ、その他の情報を示すダイアログが表示されます。検索もサポートされます。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。

25.14 リモートのSatellite ServerのinCache機能の使用

リモートSatellite Serverは、ページ・キャッシングでのみ使用されます。これは、ページ伝播やバックグラウンドでのページ再生成など、高度な機能をサポートするように構成できます。

ページ伝播

ページ伝播オプションによって、すべてのWebCenter SitesノードとSatellite Serverノードが同じページをホストできるようになり、それぞれのノードがページを再生成する必要がなくなります。ノードは生成および再生成されたページを、ページの(再)生成元およびキャッシュ元のノードから、ローカル・キャッシュに受信します。ページのキャッシングによって伝播が引き起こされます。ページ伝播の詳細は、ページ伝播の設定を参照してください。

バックグラウンドでのページの再生成

リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。詳細は、バックグラウンドでページレットを再生成するための構成を参照してください。

第X部 WebCenter Sitesのモニターおよび保守

次の各トピックでは、WebCenter Sitesでのコンテンツ管理サイトの監視と保守について説明します。

- システム・ツールによるトラブルシューティング

- コンテンツ管理サイトのレプリケート

- リビジョン追跡の管理

- バニティURLの構成

- Lucene検索エンジンの構成

- サイト・キャプチャ・アプリケーションの使用

- Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理

26 システム・ツールによるトラブルシューティング

この章では、「システム・ツール」ノードで使用できるツールについて説明します。「管理」タブの「システム・ツール」ノードは、一般管理者がWebCenter Sites管理者のインタフェースからトラブルシューティングに直接使用できる一連の診断ユーティリティを提供します。log4jログ出力の構成、様々なタイプのシステム情報へのアクセス、キャッシュの管理、WebCenter Sitesログの内容の検索、共有ファイル・システムのパフォーマンスのテストなどの機能があります。

この章の内容は次のとおりです。

- ログODLの構成ツールの使用

- システム情報ツールの使用

- キャッシュ管理ツールの使用について

- キャッシュ管理の使用 - CASキャッシュ

- キャッシュ管理の使用 - 結果セットのキャッシュ

- キャッシュ管理の使用 - Sitesキャッシュ

- キャッシュ管理の使用 - Co-Resキャッシュ

- ログ・ビューアの使用

- ファイル・システム・テスト・ツールの使用

- スロット・アセットの使用

- URLノードの使用

- 無効アセット・ノードのパージの使用

26.1 ログODLの構成ツールの使用

デフォルトでは、WebCenter SitesはOracle Diagnostic Logging (ODL)システムを使用するように設定されています。ログODLの構成ツールを使用すると、現在のログ出力レベルの表示、ログ出力レベルの変更、およびAdminインタフェースからの新しいログ出力の直接追加が可能です。さらに、ログ出力レベルの変更および追加されたログ出力が有効になっているのは、WebCenter Sitesを再起動するまでのみであるため、変更内容を保持するには、新しいログ出力を手動でlogging-config.xmlファイルに追加します。

次の各トピックでは、AdminインタフェースでのログODLの構成ツールの使用について説明します。

- ログ出力の表示

- ログ出力レベルの変更

- 新しいログ出力の追加

26.1.1 ログ出力の表示

WebCenter Sitesのログ出力およびそれらの詳細レベルのリストを表示できます。リストには、次のものが含まれています。

- <sites-shared>/configディレクトリのlogging-config.xmlファイルに登録されているログ出力。このファイルは、システム起動時にのみ読み取られます。実行中にlogging-config.xmlファイルを変更し、それらを保存した場合、ログODL構成フォームにその変更は表示されません。それらはWebCenter Sitesを再起動したときに適用され、表示されます。

- 実行中に検出されたログ出力。ログ出力は次のときに検出されます。

- システム機能またはアドオン・コンポーネントが初めてアクセスされたとき。

- 新しいログ出力の追加に示すように、「ログ出力の追加」機能を使用して、開発者が手動でログ出力をシステムに追加したとき。

リストの折りたたまれたビューには、ルート・ログ出力および親ログ出力が、すべて明示的に詳細レベルを割り当てられて表示されます。より粒度の細かいビューが必要な場合は、リストを開くとルート・ログ出力または親ログ出力からレベルを継承するログ出力も表示できます。

ログ出力を表示するには:

1. 「一般的な管理」ツリーで、「管理」ノード、続いて「システム・ツール」を開き、続いて、「ログODLの構成」をダブルクリックします。

明示的にレベルが割り当てられたログ出力のリストが表示されます(図26-1 )。

図26-1 ログODL構成フォーム

2. リストを開いて、レベルを継承するログ出力を含める場合は、フォームの下部にある「すべての既知のログ出力を表示」をクリックします。

レベルを継承するログ出力は、それらの親ログ出力の下にリストされます。

3. 再度、明示的に割り当てられたレベルを持つログ出力のみを表示するには、フォームの下部にある「構成済のログ出力を表示」をクリックします。

26.1.2 ログ出力レベルの変更

ログ出力レベルを一時的に変更し、logging-config.xmlファイルで指定されているWebCenter Sitesログに書き込まれる文のタイプと数を定義できます。変更はただちに適用されます。ログ出力が実行されるとすぐに、そのログで新しいレベルの影響を追跡できます。この新しいレベルが有効になっているのはWebCenter Sitesを再起動するときまでのみですが、変更を保持する必要がある場合は、アプリケーション・サーバーの<sites-shared>/configディレクトリにあるlogging-config.xmlファイルのログ出力値を手動で変更できます。

このオプションは、

注意:
ユーザーによって設定されたLog4jログ・レベルは、ODLログに移行できません。アップグレード後に、これらのレベルを手動で設定する必要があります。

継承されたログ出力レベルを一時的にオーバーライドする場合に特に便利です。たとえば、親ログ出力がTRACE:16などの高度な詳細レベルに設定されており、その子ログ出力の1つがそのレベルから継承しないようにする場合は、その子ログ出力に異なるレベルを割り当てることができます。

次に、詳細レベルの高いものから順に、使用可能なログ出力レベルをリストします。

ERROR:1、WARNING:1、NOTIFICATION:1、TRACE:16、TRACE:1、OFF

OFFは、ログ出力によってログに文が書き込まれないことを示します。ログ出力レベルの詳細は、Oracle Diagnostic Logging (ODL)のドキュメントを参照してください。

ログ出力レベルを変更するには::

1. 「一般的な管理」ツリーで、「管理」、続いて「システム・ツール」を開き、続いて、「ログODLの構成」をダブルクリックします。
明示的にレベルが割り当てられたログ出力のリストが表示されます。より粒度の細かいビューが必要な場合は、フォームの下部にある「すべての既知のログ出力を表示」をクリックし、リストを開いて親ログ出力からレベルを継承するログ出力を含めます。

2. 変更するログ出力を見つけ、「新規レベルの設定」列で新しいログ出力レベルを選択します。
新しいレベルが、「レベル」列に表示されます。

ログ出力が実行されると、新しいレベルの影響をログで追跡できます。詳細は、ログ・ビューアの使用を参照してください。

3. WebCenter Sitesの再起動後も新しいログ出力レベルを有効にしておく場合は、logging-config.xmlファイルで、ログ出力レベルを手動で変更する必要があります。手順は、ログ出力レベルの変更を参照してください。

26.1.3 新しいログ出力の追加

WebCenter SitesシステムのODLフレームワークに新しいログ出力を追加し、ルート・ログ出力または親ログ出力から詳細レベルを継承しない場合は、Adminインタフェースを介してログ出力を追加し、そのそれぞれに詳細レベルを割り当てることができます。(独自のカスタム・ログ出力を追加する場合は、サポートするclassおよび jarファイルを必ずデプロイしてください。)

割り当てられた詳細レベルが有効になっているのはWebCenter Sitesが再起動するまでだけですが、そのレベルを恒久的に適用する場合、アプリケーション・サーバーの<sites-shared>/configディレクトリにあるlogging-config.xmlファイルに、ログ出力プロパティを手動で追加できます。

新しいログ出力を追加するには::

1. 「一般的な管理」ツリーで、「管理」ノード、続いて「システム・ツール」を開き、続いて、「ログODLの構成」をダブルクリックします。
明示的にレベルが割り当てられたログ出力のリストが表示されます。

2. ログ出力のリストの下にあるフィールドに、追加するログ出力の名前を入力し、その詳細レベルを選択します。

3. 「ログ出力の追加」をクリックします。
新しいログ出力がリストに追加されます。ログ出力が実行されると、ただちにログでその割り当てたレベルの影響を追跡できます(ログ・ビューアの使用を参照)。

4. WebCenter Sitesの再起動後も、追加したログ出力を有効にしておく場合は、logging-config.xmlファイルにログ出力を追加します。手順は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』の、ログ出力の追加を参照してください。

26.2 システム情報ツールの使用

「システム情報」ツールにより、トラブルシューティングに関する様々なタイプのWebCenter Sites、データベース、およびスレッドの情報に直接アクセスでき、アプリケーションの状態をチェックできます。情報をファイルにダウンロードし、管理者のインタフェースで直接表示できます。

この項の内容は次のとおりです。

- WebCenter Sites情報の表示

- データベース情報の表示

- スレッド情報の表示

注意:

「システム情報」ツールを右クリックして「ダウンロード」を選択することで、使用可能なすべてのシステム情報とアプリケーション・サーバー上のすべてのWebCenter Sitesディレクトリおよびファイルのリストをダウンロードできます。Sigarが構成されている場合は、そのツールを右クリックし、「システム詳細(Sigar)」を選択することでSigarの情報をダウンロードしてテクニカル・サポートに送信することもできます。

26.2.1 WebCenter Sites情報の表示

次のタイプのWebCenter Sites情報をダウンロードまたは表示できます。

- メモリー情報: アプリケーション・サーバーのJava仮想マシンの空きメモリー容量、空きメモリーと使用中メモリーの合計量、およびJava仮想マシンが使用を試みるメモリーの最大容量。

- Sitesプロパティ: WebCenter Sitesのインストール・ディレクトリにあるini、xmlおよびpropertiesファイル。

- Webアプリケーション・プロパティ: アプリケーション・サーバー上のWEB-INFおよびWEB-INF/classesディレクトリにあるxmlおよびpropertiesファイル。

- その他のSites情報: アプリケーション・サーバー上のWEB-INF/libディレクトリにあるjarファイル、現在WebCenter Sitesにログインしているユーザーのセッション変数、およびJavaランタイム・プロパティ。

WebCenter Sites情報をダウンロードまたは表示するには:

1. 「管理」タブで「システム・ツール」、「システム情報」の順に開き、「Sites情報」をダブルクリックします。
WebCenter Sites情報のフォームが表示されます。

このフォームには、ダウンロードまたは表示を選択できるメモリー情報とその他の情報が表示されます。

2. 「Sitesプロパティ」および「Webアプリケーション・プロパティ」セクションで、目的のファイルを選択し、「追加」をクリックします。

3. 「その他のSites情報」セクションで、次のように実行します。

- アプリケーション・サーバー上のWEB-INF/libディレクトリにあるjarファイルに関する情報を取得するには、「Jarバージョン」チェック・ボックスを選択します。

- 現在WebCenter Sitesにログインしているユーザーのセッション変数を取得するには、「Sitesセッション変数」チェック・ボックスを選択します。

- Javaランタイム・プロパティを取得するには、「システム変数」チェック・ボックスを選択します。

4. 選択したWebCenter Sites情報をテキスト・ファイルとしてダウンロードするには、「ダウンロード」をクリックし、SysInfo.zipを開くか保存します。テキスト・ファイルはSysInfo.zip内にあります。

5. 選択したWebCenter Sites情報を管理者のインタフェースで表示するには、「結果の表示」をクリックします。

a. 選択したファイルおよび情報は、管理者のインタフェースに直接表示されます。

b. ファイルの詳細または情報のタイプを表示するには、そのプラス・アイコンをクリックします。
iniおよびpropertiesファイル、およびWebCenter Sitesのセッション変数およびシステム変数について、プロパティと値が表示されます(図26-2 )。

図26-2 cas.propertiesのプロパティと値

xmlファイルの場合は、コードが表示されます(図26-3)。

図26-3 XMLファイルのコードの表示

Jarバージョンについては、jar名、バージョンおよび実装ベンダーが表示されます(図26-4)。

図26-4 Jarのバージョンおよびベンダー

NA : NAは、jarファイルでそのバージョンおよびベンダーが提供されていないことを示します。

26.2.2 データベース情報の表示

次のタイプのデータベース情報をダウンロードまたは表示できます。

- 基本情報: データベース・エンジンおよびバージョン、デフォルト・トランザクション分離レベル、JDBCドライバ、URL、バージョン、およびJNDIデータ・ソース。

- システム表: コアWebCenter Sitesデータが格納されている表。たとえば、ElementCatalog表には、システムで使用されるXML要素またはJSP要素がすべてリストされています。

- ツリー表: オブジェクト間の親子関係が格納されている表。たとえば、AssetRelationTreeにはアセット間のアソシエーションについての情報が格納されています。

- Sitesオブジェクト表: アセット・タイプ、アセット属性、アセット定義など一意に識別されるオブジェクトが格納されている表。

- その他のSites表: 親子関係に編成できない水平データを格納する表およびWebCenter Sitesによって管理されない外部表。

注意:

表に割り当てられているアクセス制御リスト(ACL)の少なくとも1つが自身のユーザーに割り当てられている場合、自身にデータベース表にアクセスする権限があります。データベース権限の詳細は、アクセス制御リスト(ACL)を参照してください。様々なタイプのWebCenter Sitesデータベース表の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

データベース情報をダウンロードまたは表示するには::

1. 「管理」タブで「システム・ツール」、「システム情報」の順に開き、「DB情報」をダブルクリックします。
「データベース情報」フォームに、使用しているデータベースの基本情報および選択してダウンロードまたは表示できる表が表示されます。

2. 「システム表」、「ツリー表」、「Sitesオブジェクト表」および「その他のSites表」セクションで、表示する表を選択し、「追加」をクリックします。

3. 選択したデータベース情報をスプレッドシート・ファイルとしてダウンロードするには、「ダウンロード」をクリックし、SysInfo.zipを開くか保存します。スプレッドシート・ファイルはSysInfo.zip内にあります。

4. 選択したデータベース情報を管理者のインタフェースで表示するには、「結果の表示」をクリックします。

a. アクセスする権限を持っている選択済の表ごとに、次の情報が表示されます。

- 表名

- 主キー

- 行数

- CSz(メモリー内にキャッシュされる結果セットの数)

- タイムアウト(メモリー内にキャッシュされる結果セットを保持する分数)

- Abs(結果セットの有効期限の計算方法)

- SQLを実行する時間

- 特殊表キー

b. 表の列および索引を表示するには、そのプラス・アイコンをクリックします。索引が複数リストされている場合、複数の行にわたって表示されます(図26-5参照)。

図26-5 ツリー表情報

26.2.3 スレッド情報の表示

スレッド・ダンプをダウンロードまたは表示し、アプリケーション・サーバーの実行時の状態を分析できます。これは、特に、リソースの枯渇またはスレッド・ハングになる可能性がある問題の検出に役立つ場合があります。

スレッド情報をダウンロードまたは表示するには::

1. 「管理」タブで「システム・ツール」、「システム情報」の順に開き、「スレッド情報」をダブルクリックします。

「スレッド情報」フォームが表示されます。

2. デフォルトで「正規表現」チェック・ボックスが選択されています。このオプションによって、Java正規表現を使用してスレッド名を検索できます。

例:

- Thread.*でThread-0、Thread-1およびThread-3が検索されます。

- .*thread.*でpool-6-thread-1、pool-8-thread-1およびpool-14-thread-2が検索されます。

このチェック・ボックスの選択を解除する場合、完全なスレッド名で検索する必要があります。

3. 「スレッド名」フィールドに、検索するスレッド名またはテキスト文字列を入力します。

4. 検索を1つ以上のスレッド状態に限定するには、「状態」フィールドで状態を選択します。状態を選択しない場合は、すべての状態が検索されます。

5. 選択したスレッド情報を、スレッド・ダンプ・アナライザで使用するためにテキスト・ファイルとしてダウンロードするには、「ダウンロード」をクリックし、SysInfo.zipを開くか保存します。テキスト・ファイルはSysInfo.zip内にあります。

注意:

スレッド情報のダウンロードは、次の場合にのみ可能です。

- WebCenter SitesのJDKに、互換性があるjstackユーティリティが含まれている。

- 使用しているオペレーティング・システムのライブラリ・パスに最初にリストされているJDKに、WebCenter SitesのJDKと互換性があるjstackユーティリティが含まれている。

互換性があるjstackが見つからない場合、「このプラットフォームではスレッド・ダンプ機能はサポートされていません。」というメッセージが表示されます

6. 選択したスレッド情報を管理者のインタフェースで表示するには、「結果の表示」をクリックします。

検索に一致するスレッドごとに、次の情報が表示されます。

- 名前

- ID

- 状態

- CPUがスレッドを実行した合計時間

- スレッドがユーザー・モードであった合計時間

- それをブロックおよび待機した回数

- それをブロックおよび待機した長さ

- それが待機したオブジェクト

- スタック・トレース

26.3 キャッシュ管理ツールの使用について

ページ・キャッシングまたはアセット・キャッシング、あるいはその両方のためにinCacheフレームワークが設定されている場合、「キャッシュ管理」ツールで、WebCenter Sitesクラスタ・メンバーおよびそれらの共存Satellite Server上のキャッシング・プロセスを監視できます。機能としては、キャッシュの検索、ディスクへの強制書込み、個別ページ、アセット、依存性、およびキャッシュ全体のフラッシュがあります。

注意:

「キャッシュ管理」ツールは、WebCenter Sitesクラスタ・メンバーおよびそれらの共存Satellite Serverに対してのみキャッシング情報を提供します。リモートSatellite Serverのキャッシュ情報にアクセスするには、次のURLを使用してください。

http://<server>:<port>/<application_context_path>/Inventory?username=<SatelliteServer>&password=<password>&detail=debug

26.4 キャッシュ管理の使用 - CASキャッシュ

この章では、CASキャッシュのキャッシュ管理について説明します。

この項には次のトピックが含まれます:

- CASキャッシュ概要フォームの概要

- クラスタ情報の使用

26.4.1 CASキャッシュ概要フォームの概要

CASキャッシュ概要・フォームには、各キャッシュの次の基本データ(値は推定)がリストされます。

- 合計数(キャッシュされたエレメントの合計数)

- メモリー格納数(メモリー内のキャッシュされたエレメントの数)

- ディスク格納数(ディスク上のキャッシュされたエレメントの数)

- キャッシュ・ヒット(メモリーとディスクの両方から取得されたキャッシュ済エレメントの数)

- メモリー・ヒット(メモリーから取得されたキャッシュ済エレメントの数)

- ディスク・ヒット(ディスクから取得されたキャッシュ済エレメントの数)

- キャッシュ・ミス(キャッシュ内でエレメントが見つからなかった回数)

- 削除件数(キャッシュから削除したエレメントの数)

- 平均取得時間(エレメントの取得にかかったミリ秒数の平均)

- メモリーの最大エレメント(メモリー内で許容されるエレメントの最大数)

- ディスクの最大エレメント(ディスク上で許容されるエレメントの最大数)

- ディスクへのオーバーフロー(メモリーがいっぱいになったときにエレメントがディスクに書き込まれるかどうか)

このフォームには、次のオプションもあります。特に配信システムではサイトのパフォーマンスに影響を与えることがあるため、これらは注意深く使用する必要があります。

- ディスクへのキャッシュのメモリー・ストア全体の書込み。このオプションは、WebCenter Sitesがシャットダウンの前にキャッシュのメモリー・ストアをディスクに自動的に書き込むように設定されていない場合に特に役立つことがあります。

- キャッシュのメモリー・ストアおよびディスク・ストア全体のフラッシュ

注意:

レガシーのページ・キャッシングが有効な場合、キャッシュされたページ・データはSystemPageCache表に格納され、格納されたデータに関する情報は「概要」ウィンドウには表示されません。

概要キャッシュ情報を表示および使用するには::

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「CASキャッシュ」を開いて「概要」をダブルクリックします。

「概要」ページが表示されます(図26-6)。

図26-6 CASキャッシュの概要

2. 「チケット・キャッシュ」または「セッション・キャッシュ」(または両方)のチェック・ボックスを選択し、「ディスクへの書込み」をクリックして、選択したキャッシュのメモリー・ストア全体をディスクに書き込みます。

3. 「チケット・キャッシュ」または「セッション・キャッシュ」(または両方)のチェック・ボックスを選択し、「キャッシュのフラッシュ」をクリックして、選択したキャッシュのメモリー・ストアおよびディスク・ストアをフラッシュします。

26.4.2 クラスタ情報の使用

Sigarが構成されている場合、このフォームには、追加の各WebCenter Sitesクラスタ・メンバーの名前、URL、ポートおよびGUIDがリストされます。

クラスタ情報を表示および使用するには:

1. 「一般的な管理」ツリーで、「システム・ツール」を開きます。

2. 「システム・ツール」ノードの下で、「キャッシュ管理」を選択し、続いて「CASキャッシュ」を開き、続いて「クラスタ情報」をダブルクリックします。

「クラスタ情報」ページが表示されます(図26-7)。

図26-7 「クラスタ情報」フォーム

26.5 キャッシュ管理の使用 - 結果セットのキャッシュ

Oracle WebCenter Sitesによって、システム・パフォーマンスの最適化に役立つように結果セットがキャッシュされます。キャッシングにより、同じ情報に対して問合せを繰り返すことによるデータベースの過負荷が防止され、さらに、キャッシュから提供すると、別のデータベースの参照を実行するよりも常に高速です。

デフォルトでは、WebCenter Sitesは、結果セットをハッシュ表のかわりにinCacheフレームワークに格納します。どちらのキャッシュ・フレームワークでもJavaメモリーが使用されます。Adminインタフェースのプロパティ管理ツールを使用して、(wcs_properties.jsonで)rsCacheOverInCacheプロパティをtrueまたはfalseに設定することによって、フレームワークを切り替えることができます。

inCacheによる結果セット・キャッシングが有効になると、「システム・ツール」ノードに結果セットのキャッシュ・ツールが表示され、この項で説明したキャッシュやその内容に関する統計情報を提供します。結果セットのキャッシュに関する追加情報は、『Oracle WebCenter Sitesでの開発』にあります。

この項の内容は次のとおりです。

- inCacheを使用した結果セットのキャッシングの有効化と構成

- サマリー・ビュー

- クラスタ情報の表示

26.5.1 inCacheを使用した結果セットのキャッシングの有効化と構成

inCacheを使用した結果セットのキャッシングが有効でない場合、デフォルトでハッシュ表でのキャッシングが有効化されます。

結果セットのキャッシュを有効化および構成するには::

1. 次のように結果セットのキャッシングを有効化します。

a. linked-cache.xml構成ファイルがアプリケーション・サーバーのクラスパス(WEB-INF/classesディレクトリ)に存在していることを確認します。

b. Adminインタフェースで、プロパティ管理ツールにアクセスし、rsCacheOverInCacheプロパティを見つけ、その値をtrueに設定します。(プロパティ管理ツールを使用してプロパティを変更する手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

2. 次のように結果セットのキャッシングを構成します。
プロパティ管理ツールで、次の結果セットのキャッシングのプロパティの値を設定します。

- cc.cacheResults: キャッシュする結果セットのデフォルトの数を指定します。

- cc.cacheResultsTimeout: キャッシュされた結果セットを保持する分数を指定します。

- cc.cacheResultsAbs: キャッシュされた結果セットに対して有効期限を計算する方法を指定します。

結果セットのキャッシングのプロパティの構成に関する詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

26.5.2 サマリー・ビュー

結果セットのキャッシュの概要表示には、すべてのキャッシュの統計情報が表示されます。概要表からキャッシュを選択して、それに含まれるデータベース問合せを表示できます。さらに、キャッシュに含まれるデータベース問合せの結果セット・エレメントを表示できます。

キャッシュ情報を表示するには::

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「結果セットのキャッシュ」を開いて「概要」をダブルクリックします。

「inCache上の結果セットのキャッシュ」フォームが表示されます。

2. 概要表の上にあるボタンをクリックします。

- リフレッシュ: 概要表の結果をリフレッシュします。

- フィルタ (キャッシュ): 概要表に表示する結果を、選択したキャッシュのみに絞り込みます。

- クリア: 選択したキャッシュを消去します。

- 無効化: 選択したキャッシュを無効化します。すべての無効化された結果セット・エレメントは、定期的に実行される消去スレッドによって消去されます。
各結果セット・エレメントには、それが依存する表のリストが含まれています。無効化された結果セット・エレメントが要求されたときは、データベースから読み取られ、キャッシュにリロードされます。

表26-1に、各列値の計算方法を示します。

表26-1 概要表の列の説明

列名

説明

キャッシュ

キャッシュの名前。

数

キャッシュ内の結果セット・エレメントの数。結果セット・エレメントは、キーと値のペアです。ここでキーは問合せであり、値はその問合せによって戻される結果です。

最大数

キャッシュの容量(キャッシュで許容される結果セット・エレメントの最大数)。

フィル率

キャッシュ容量の使用率: (数/最大数) x 100

ヒット

すべての結果セット・エレメントがキャッシュから読み取られた回数の合計。

ミス

キャッシュで結果セット・エレメントが見つからなかった回数。

ヒット率

ヒットの割合: [ヒット/ (ヒット+ミス)] x 100

期限切れミス

期限切れになったが削除されていない結果セット・エレメントが原因のミスの数。

取得時間

get操作にかかった平均時間(ミリ秒単位)。

プット

データベースの問合せに続いて、キャッシュに結果セット・エレメントが入れられた回数。

更新

キャッシュ内の個々の結果セット・エレメントが更新された回数。

期限切れ

期限切れ結果セット・エレメントの数。これらは、バックグラウンドで定期的に実行されるクリーニング・スレッドによって削除されます。

除去済

いずれかの理由(手動によるクリア操作またはクリーニング・スレッドなど)で削除された結果セット・エレメントの数。

削除済

削除済結果セット・エレメントの数。削除は、キャッシュの容量を超えたときに実行されます。

不変

キャッシュ内のすべての結果セット・エレメントの有効期限が無期限になっているかどうかを示します。

TTL

有効時間。結果セット・エレメントがキャッシュ内に留まる時間の長さ(秒数)。

TTI

アイドル時間。この時間内に結果セット・エレメントがヒット(キャッシュから読取り)されなかった場合、それがアイドルとしてマークされます。

3. キャッシュの内容の詳細を表示するには、概要表のキャッシュ名をクリックします。

詳細ビューが開き、キー(問合せ)、それらに関連する統計と、キー、有効期限、および依存性によってキャッシャの内容を検索するための検索フィールドが表示されます(図26-8 )。

図26-8 キャッシュ・コンテンツの詳細ビュー

フォームをリフレッシュするには、「検索」をクリックします。

表26-2は、キャッシュ詳細の列についての説明です。

表26-2 キャッシュ詳細表の列の説明

列名

説明

キー

結果セット・エレメントのキー(問合せ)

依存性

問合せの実行対象の表のリスト

作成時間

結果セット・エレメントがキャッシュ内に入れられたタイミング。

最終アクセス時間

このキャッシュされた結果セット・エレメントが最後にアクセスされたタイミング。

期限切れ時間

この結果セット・エレメントの期限が切れるタイミング。

4. キーの結果セット・エレメントを表示するには、キー(問合せ)をクリックします。

結果セットフォームが表示されます。

表内で開く列は、動的であり、サイトのデータ・モデルおよび問合せの設定方法によって異なります。

26.5.3 クラスタ情報の表示

Sigarが構成されている場合、「クラスタ情報」フォームには、追加の各WebCenter Sitesクラスタ・メンバーの名前、URL、ポートおよびGUIDがリストされます。

クラスタ情報を表示および使用するには:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「結果セットのキャッシュ」を開いて「クラスタ情報」をダブルクリックします。

「クラスタ情報」フォームが表示されます(図26-9)。

図26-9 「クラスタ情報」フォーム

26.6 キャッシュ管理の使用 - Sitesキャッシュ

次の各トピックでは、Sitesキャッシュのキャッシュ管理に関する情報を提供します。

- Sitesキャッシュ概要フォームの概要

- ページ・キャッシュの使用

- 依存性キャッシュの使用

- アセット・キャッシュの使用

- URLキャッシュの使用

- クラスタ情報の表示

26.6.1 Sitesキャッシュ概要フォームの概要

Sitesキャッシュ概要・フォームには、各キャッシュの次の基本データ(値は推定)がリストされます。

- 合計数(キャッシュされたエレメントの合計数)

- メモリー格納数(メモリー内のキャッシュされたエレメントの数)

- ディスク格納数(ディスク上のキャッシュされたエレメントの数)

- キャッシュ・ヒット(メモリーとディスクの両方から取得されたキャッシュ済エレメントの数)

- メモリー・ヒット(メモリーから取得されたキャッシュ済エレメントの数)

- ディスク・ヒット(ディスクから取得されたキャッシュ済エレメントの数)

- キャッシュ・ミス(キャッシュ内でエレメントが見つからなかった回数)

- 削除件数(キャッシュから削除したエレメントの数)

- 平均取得時間(エレメントの取得にかかったミリ秒数の平均)

- メモリーの最大エレメント(メモリー内で許容されるエレメントの最大数)

- ディスクの最大エレメント(ディスク上で許容されるエレメントの最大数)

- ディスクへのオーバーフロー(メモリーがいっぱいになったときにエレメントがディスクに書き込まれるかどうか)

このフォームには、次のオプションもあります。特に配信システムではサイトのパフォーマンスに影響を与えることがあるため、これらは注意深く使用する必要があります。

- ディスクへのキャッシュのメモリー・ストア全体の書込み。このオプションは、WebCenter Sitesがシャットダウンの前にキャッシュのメモリー・ストアをディスクに自動的に書き込むように設定されていない場合に特に役立つことがあります。

- キャッシュのメモリー・ストアおよびディスク・ストア全体のフラッシュ

注意:

レガシーのページ・キャッシングが有効な場合、キャッシュされたページ・データはSystemPageCache表に格納され、格納されたデータに関する情報は「概要」ウィンドウには表示されません。このウィンドウには「ページ・キャッシュのクリア」ボタンも表示され、それを使用して、システム・ページ・キャッシュとCo-Res SSキャッシュに格納されているデータをフラッシュできます。

システム・ページ・キャッシュはレガシーなので、使用するには有効化する必要があります。それには、AppServerのJVMパラメータとして次の設定を追加して、Ehcacheを無効にします。

-Dcs.useEhcache=false

概要キャッシュ情報を表示および使用するには::

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「概要」をダブルクリックします。

「概要」フォームが表示されます(図26-10)。

図26-10 「Sitesキャッシュ」の「概要」

2. 「ページ・キャッシュ」、「キャッシュ依存性」、「アセット・キャッシュ」または「URLキャッシュ」のチェック・ボックスを選択し、「ディスクへの書込み」をクリックして、選択したキャッシュのメモリー・ストア全体をディスクに書き込みます。

3. 「ページ・キャッシュ」、「キャッシュ依存性」、「アセット・キャッシュ」または「URLキャッシュ」のチェック・ボックスを選択し、「キャッシュのフラッシュ」をクリックして、選択したキャッシュのメモリー・ストアおよびディスク・ストアをフラッシュします。

システム・ページ・キャッシングを有効にしている場合、「ページ・キャッシュのクリア」というラベルの付いたボタンが「キャッシュのフラッシュ」ボタンの下に表示されます。「ページ・キャッシュのクリア」をクリックすると、SystemPageCache表およびCo-Res SSキャッシュがフラッシュされます。

26.6.2 ページ・キャッシュの使用

このフォームには、キャッシュされたページごとに、訪問者数、作成時間、最終アクセス時間、有効期限、依存性などの統計がリストされます。表の凡例は、追跡される情報のタイプを特定しています(無効化されたページ、依存性の更新、依存性の生成数に対する変更)。フォームには、次のオプションも用意されています。

- キャッシュでの特定のページの検索: 検索はCPUに負荷がかかるため、配信システムでは注意して使用する必要があります。

- キャッシュからのページのフラッシュ

- ページのHTML情報の表示

- ページ依存性の参照

ページ・キャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「ページ・キャッシュ」をダブルクリックします。

「ページ」フォームが表示されます(図26-11)。

図26-11 Sitesページ・キャッシュ

2. フォームの上部に検索領域があります。検索条件として「キー」、「期限切れ時間」または「依存性」を選択します。検索する期限切れ時間を入力する場合は、mm/dd/yyyyまたはmm/dd/yyyy hh:mm:ssの形式で日時を入力します。「検索」をクリックします。

3. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「ページ」フォームを最初にロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

4. 「キー」列では、各アイテムの下に「ページの詳細の表示」リンクが開きます。「ページの詳細の表示」をクリックすると、新しいウィンドウが開いて、ページのHTML情報が表示されます。

5. キャッシュから選択したアセットをフラッシュするには、各アセットの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットが選択されます。「キャッシュのフラッシュ」をクリックすると、アセットのメモリーおよびストアがフラッシュされます。

6. キャッシュ内の特定のアイテムのページを表示するには、各アイテムの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべての依存性がマークされます。「ページ参照」をクリックすると、選択した依存性のページが表示されます。

キャッシュ内の各アイテムの右側には、複数の依存性を反映して複数のチェック・ボックスが表示される場合があります。

注意:

WebCenter Sitesを再起動した後、キャッシュ・エンジンが初期化されるまでこのフォームにはページ・キャッシュ情報は表示されません。キャッシュ・エンジンは、最初のページまたはアセットがリクエストされると初期化されます。

26.6.3 依存性キャッシュの使用

このフォームには、依存性キャッシュの内容と、依存性ごとの生成数がリストされます。さらに、次のオプションがあります。

- キャッシュでの特定の依存性の検索: 検索はCPUに負荷がかかるため、配信システムでは注意して使用する必要があります。

- キャッシュからの依存性のフラッシュ

- ページ依存性の参照

依存性キャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「依存性」をダブルクリックします。

「依存性」フォームが表示されます(図26-12)。

図26-12 「Sitesキャッシュ」の「依存性」

2. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「依存性」フォームを初めてロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

3. キャッシュから選択したアセットをフラッシュするには、各アセットの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットが選択されます。「キャッシュのフラッシュ」をクリックすると、アセットのメモリーおよびストアがフラッシュされます。

4. キャッシュ内の特定のアイテムのページを表示するには、各アイテムの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべての依存性がマークされます。「ページ参照」をクリックすると、選択した依存性のページが表示されます。

注意:

WebCenter Sitesを再起動した後、キャッシュ・エンジンが初期化されるまでこのフォームには依存性キャッシュ情報は表示されません。キャッシュ・エンジンは、最初のページまたはアセットがリクエストされると初期化されます。

26.6.4 アセット・キャッシュの使用

このフォームには、キャッシュされたアセットごとに、訪問者数、作成時間、最終アクセス時間、依存性などの統計がリストされます。表の凡例は、追跡される情報のタイプを特定しています(無効化されたアセット、依存性の更新、依存性の生成数に対する変更)。フォームには、次のオプションも用意されています。

- キャッシュでの特定のアセットの検索。検索はCPU集約的なので、配信システム上では注意して使用してください。

- キャッシュからのアセットのフラッシュ

- アセットの依存性の参照

アセット・キャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「アセット・キャッシュ」をダブルクリックします。

「アセット」フォームが表示されます(図26-13)。

図26-13 アセット・キャッシュ

2. フォームの上部に検索領域があります。検索条件として「キー」または「依存性」を選択し、すべてを表示するか、入力した検索値を持つアセットを表示するかを選択します。「検索」をクリックします。

3. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「アセット」フォームを初めてロードしたときは、すべてのアセットが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

4. キャッシュから選択したアセットをフラッシュするには、各アセットの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットが選択されます。「キャッシュのフラッシュ」をクリックすると、アセットのメモリーおよびストアがフラッシュされます。

5. キャッシュ内の特定の依存性のアセットを表示するには、各アセットの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットがマークされます。「ページ参照」をクリックすると、依存性が表示されます。

注意:

WebCenter Sitesを再起動した後、キャッシュ・エンジンが初期化されるまでこのフォームにはアセット・キャッシュ情報は表示されません。キャッシュ・エンジンは、最初のページまたはアセットがリクエストされると初期化されます。

26.6.5 URLキャッシュの使用

すべてのバニティURLは、Webページで解決が完了すると、inCacheにキャッシュされます。このキャッシュは、「システム・ツール」の「キャッシュ管理」ノードで参照および管理できます。

URLキャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「URLキャッシュ」をダブルクリックします。

「URL」フォームが表示されます(図26-14)。

図26-14 「URL」フォームのURLキャッシュ

2. フォームの上部に検索領域があります。検索条件として「キー」または「依存性」を選択します。「検索」をクリックします。

3. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「URL」フォームを初めてロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

4. キャッシュから選択したURLをフラッシュするには、各URLの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのURLが選択されます。「キャッシュのフラッシュ」をクリックすると、URLのメモリーおよびストアがフラッシュされます。

5. キャッシュ内の特定の依存性のURLを表示するには、各URLの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのURLがマークされます。「ページ参照」をクリックすると、依存性が表示されます。

26.6.6 クラスタ情報の表示

Sigarが構成されている場合、「クラスタ情報」フォームには、追加の各WebCenter Sitesクラスタ・メンバーの名前、URL、ポートおよびGUIDがリストされます。

クラスタ情報を表示および使用するには:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Sitesキャッシュ」を開いて「クラスタ情報」をダブルクリックします。

「クラスタ情報」フォームが表示されます(図26-15)。

図26-15 「クラスタ情報」フォーム

26.7 キャッシュ管理の使用 - Co-Resキャッシュ

次の各トピックでは、Co-Resキャッシュのキャッシュ管理に関する情報を提供します。

- Co-Res SSキャッシュ概要フォームの概要

- ページ・キャッシュの使用

- 依存性キャッシュの使用

- URLキャッシュの使用

- クラスタ情報の表示

26.7.1 Co-Res SSキャッシュ概要フォームの概要

Co-Res Satellite Serverのキャッシュ概要フォームには、各キャッシュの次の基本データ(値は推定)がリストされます。

- 合計数(キャッシュされたエレメントの合計数)

- メモリー格納数(メモリー内のキャッシュされたエレメントの数)

- ディスク格納数(ディスク上のキャッシュされたエレメントの数)

- キャッシュ・ヒット(メモリーとディスクの両方から取得されたキャッシュ済エレメントの数)

- メモリー・ヒット(メモリーから取得されたキャッシュ済エレメントの数)

- ディスク・ヒット(ディスクから取得されたキャッシュ済エレメントの数)

- キャッシュ・ミス(キャッシュ内でエレメントが見つからなかった回数)

- 削除件数(キャッシュから削除したエレメントの数)

- 平均取得時間(エレメントの取得にかかったミリ秒数の平均)

- メモリーの最大エレメント(メモリー内で許容されるエレメントの最大数)

- ディスクの最大エレメント(ディスク上で許容されるエレメントの最大数)

- ディスクへのオーバーフロー(メモリーがいっぱいになったときにエレメントがディスクに書き込まれるかどうか)

このフォームには、次のオプションもあります。特に配信システムではサイトのパフォーマンスに影響を与えることがあるため、これらは注意深く使用する必要があります。

- ディスクへのキャッシュのメモリー・ストア全体の書込み。このオプションは、WebCenter Sitesがシャットダウンの前にキャッシュのメモリー・ストアをディスクに自動的に書き込むように設定されていない場合に特に役立つことがあります。

- キャッシュのメモリー・ストアおよびディスク・ストア全体のフラッシュ

注意:

レガシーのページ・キャッシングが有効な場合、キャッシュされたページ・データはSystemPageCache表に格納され、格納されたデータに関する情報は「概要」ウィンドウには表示されません。

概要キャッシュ情報を表示および使用するには::

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Co-Res SSキャッシュ」を開いて「概要」をダブルクリックします。

「概要」ページが表示されます(図26-16)。

図26-16 「Co-Res SSキャッシュ」の「概要」

2. 「ページ・キャッシュ」、「キャッシュ依存性」または「URLキャッシュ」のチェック・ボックスを選択し、「ディスクへの書込み」をクリックして、選択したキャッシュのメモリー・ストア全体をディスクに書き込みます。

3. 「ページ・キャッシュ」、「キャッシュ依存性」または「URLキャッシュ」のチェック・ボックスを選択し、「キャッシュのフラッシュ」をクリックして、選択したキャッシュのメモリー・ストアおよびディスク・ストアをフラッシュします。

26.7.2 ページ・キャッシュの使用

このフォームには、キャッシュされたページごとに、訪問者数、作成時間、最終アクセス時間、有効期限、依存性などの統計がリストされます。表の凡例は、追跡される情報のタイプを特定しています(無効化されたページ、依存性の更新、依存性の生成数に対する変更)。フォームには、次のオプションも用意されています。

- キャッシュでの特定のページの検索: 検索はCPUに負荷がかかるため、配信システムでは注意して使用する必要があります。

- キャッシュからのページのフラッシュ

- ページのHTML情報の表示

- ページ依存性の参照

ページ・キャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Co-Res SSキャッシュ」を開いて「ページ・キャッシュ」をダブルクリックします。

「ページ」フォームが表示されます(図26-17)。

図26-17 Co-Res SSページ・キャッシュ

2. フォームの上部に検索領域があります。検索条件として「キー」、「期限切れ時間」または「依存性」を選択します。検索する期限切れ時間を入力する場合は、mm/dd/yyyyまたはmm/dd/yyyy hh:mm:ssの形式で日時を入力します。「検索」をクリックします。

3. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「ページ」フォームを最初にロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

4. 「キー」列では、各アイテムの下に「ページの詳細の表示」リンクが開きます。「ページの詳細の表示」をクリックすると、新しいウィンドウが開いて、ページのHTML情報が表示されます。

5. キャッシュから選択したアセットをフラッシュするには、各アセットの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットが選択されます。「キャッシュのフラッシュ」をクリックすると、アセットのメモリーおよびストアがフラッシュされます。

6. キャッシュ内の特定のアイテムのページを表示するには、各アイテムの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、すべてがマークされます。「ページ参照」をクリックすると、選択した依存性のページが表示されます。

キャッシュ内の各アイテムの右側には、複数の依存性を反映して複数のチェック・ボックスが表示される場合があります。

注意:

WebCenter Sitesを再起動した後、キャッシュ・エンジンが初期化されるまでこのフォームにはページ・キャッシュ情報は表示されません。キャッシュ・エンジンは、最初のページまたはアセットがリクエストされると初期化されます。

26.7.3 依存性キャッシュの使用

このフォームには、依存性キャッシュの内容と、依存性ごとの生成数がリストされます。さらに、次のオプションがあります。

- キャッシュでの特定の依存性の検索。検索はCPU集約的なので、配信システム上では注意して使用してください。

- キャッシュからの依存性のフラッシュ

- ページ依存性の参照

依存性キャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Co-Res SSキャッシュ」を開いて「依存性」をダブルクリックします。

「依存性」フォームが表示されます(図26-18)。

図26-18 「Co-Res SSキャッシュ」の「依存性」

2. 表示されたキャッシュ内アイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「依存性」フォームを初めてロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

3. キャッシュから選択したアセットをフラッシュするには、各アセットの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのアセットが選択されます。「キャッシュのフラッシュ」をクリックすると、アセットのメモリーおよびストアがフラッシュされます。

4. キャッシュ内の特定のアイテムのページを表示するには、各アイテムの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべての依存性がマークされます。「ページ参照」をクリックすると、選択した依存性のページが表示されます。

注意:

WebCenter Sitesを再起動した後、キャッシュ・エンジンが初期化されるまでこのフォームには依存性キャッシュ情報は表示されません。キャッシュ・エンジンは、最初のページまたはアセットがリクエストされると初期化されます。

26.7.4 URLキャッシュの使用

すべてのバニティURLは、Webページで解決が完了すると、inCacheにキャッシュされます。このキャッシュは、「システム・ツール」の「キャッシュ管理」ノードで参照および管理できます。

URLキャッシュのアイテムの表示および使用:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Co-Res SSキャッシュ」を開いて「URLキャッシュ」をダブルクリックします。

「URL」フォームが表示されます(図26-19)。

図26-19 「URL」フォームのURLキャッシュ

2. フォームの上部に検索領域があります。検索条件として「キー」または「依存性」を選択します。「検索」をクリックします。

3. 表示されたアイテムのヘッダー・タイトルをクリックすると、それを基準にしてアイテムがソートされます。

「URL」フォームを初めてロードしたときは、すべてのアイテムが表示されます。「検索」フォームを使用して表示するアイテムを絞り込むと、キャッシュ内のアイテムを見つけやすくなります。

4. キャッシュから選択したURLをフラッシュするには、各URLの左側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのURLがマークされます。「キャッシュのフラッシュ」をクリックすると、URLのメモリーおよびストアがフラッシュされます。

5. キャッシュ内の特定の依存性のURLを表示するには、各URLの右側にあるチェック・ボックスを選択します。ヘッダーにあるチェック・ボックスを選択すると、表示されているすべてのURLがマークされます。「ページ参照」をクリックすると、依存性が表示されます。

26.7.5 クラスタ情報の表示

Sigarが構成されている場合、「クラスタ情報」フォームには、追加の各WebCenter Sitesクラスタ・メンバーの名前、URL、ポートおよびGUIDがリストされます。

クラスタ情報を表示および使用するには:

1. 「管理」タブで、「システム・ツール」を開いて「キャッシュ管理」を選択し、「Co-Res SSキャッシュ」を開いて「クラスタ情報」をダブルクリックします。

「クラスタ情報」フォームが表示されます(図26-15)。

図26-20 「クラスタ情報」フォーム

26.8 ログ・ビューアの使用

「ログ・ビューア」ツールによって、WebCenter SitesAdminインタフェースからlogging-config.xmlファイルに指定されているWebCenter Sitesログの内容を表示、末尾を表示、ダウンロード、および検索できます。ログの合計サイズがツールのパフォーマンスに影響するため、ログ・サイズが100MBを超える場合、管理者にはこれが通知され、続行するか取り消すかを選択できます。

次の各トピックでは、ログ・ビューア・ツールの使用について説明します。

- ログの表示

- ログの末尾の表示

- ログのダウンロード

- ログの検索

26.8.1 ログの表示

WebCenter Sitesログの内容全体を、最新の文または特定の時点に書き込まれた文から表示することができます。

ログの内容を表示するには::

1. 「管理」タブで「システム・ツール」を開き、「ログ・ビューア」をダブルクリックします。
「ログ・ビューア」フォームに、ログの最新の100行が表示されます。

2. 特定の時点に書き込まれた文に移動するには、次のように実行します。

a. カレンダ・アイコンをクリックして日付と時刻を選択するか、yyyy-mm-dd hh:mm:ss形式で日付と時刻を手動で入力します。

注意:

この機能は、logging-config.xmlファイルで指定されているタイムスタンプ・パターンで書き込まれたログ文のみを対象にしています。

b. 「ログの表示」をクリックします。
「ログ・ビューア」フォームが表示されます。

フォームに、指定した日付と時刻以降に書き込まれた文が表示されます。

26.8.2 ログの末尾の表示

別のウィンドウにWebCenter Sitesログの末尾を表示できます。このオプションは、特に、例外を発生させるアクションの実行中にログに書き込まれる文を追跡する場合に役立ちます。

ログの内容の末尾を表示するには::

1. 「管理」タブで「システム・ツール」を開き、「ログ・ビューア」をダブルクリックします。

「ログ・ビューア」フォームが表示されます(図26-21)。

図26-21 「ログ・ビューア」フォーム

2. 「ログの末尾」をクリックします。

ログ内の最新の100行が新しいウィンドウに表示され、5秒ごとにリフレッシュされます。

26.8.3 ログのダウンロード

WebCenter Sitesログの内容全体を含む圧縮ファイルをダウンロードできます。

ログの内容のダウンロードするには::

1. 「管理」タブで「システム・ツール」を開き、「ログ・ビューア」をダブルクリックします。

「ログ・ビューア」フォームが表示されます(図26-21)。

2. 「ログのダウンロード」をクリックします。

3. WebCenter Sitesログを含む圧縮ファイルを開くか保存します。ログが複数のファイルに渡る場合は、各ファイルを含めます。

26.8.4 ログの検索

WebCenter Sitesログの内容を特定の情報について検索できます。

ログの内容を検索するには::

1. 「管理」タブで「システム・ツール」を開き、「ログ・ビューア」をダブルクリックします。

「ログ・ビューア」フォームが表示されます(図26-21)。

2. 大文字小文字を区別するには、「大/小文字の区別」チェック・ボックスを選択します。デフォルトでは、大文字小文字の区別はUS-ASCII文字のみを対象としています。大文字小文字の区別をUnicode文字にも適用する場合は、「Unicode Case」チェック・ボックスも選択します。「Unicode Case」チェック・ボックスは、「大/小文字の区別」チェック・ボックスを選択した場合に表示されます。

3. 検索でJava正規表現を使用できるようにする場合は、「正規表現」チェック・ボックスを選択します。「正規表現」チェック・ボックスを選択すると、「すべてにドット」および「複数行」チェック・ボックスが表示されます。これらを使用して、正規表現設定を調整します。

- ドット(.)を任意の文字および行の終了文字と一致させる場合は、「すべてにドット」チェック・ボックスを選択します。このチェック・ボックスの選択が解除されている場合、ドットは文字にのみ一致します。

- カレット( ^)を行の先頭と、ドル記号($)を行の終わりと一致させるには、「複数行」チェック・ボックスを選択します。

注意:

正規表現を使用して検索する場合、1つの検索結果のログの行数は、最大40行に制限されます。

4. 検索フィールドに、ログで検索する表現を入力します。

5. 「ページ当たりの結果数」フィールドで、各ページにリストする結果の数を選択します。

6. 「ログの検索」をクリックします。

「ログ・ビューア」フォームに、検索に一致するログの行が表示されます。

7. より大きなコンテキストで検索結果を表示するには、結果行の下の「ログの表示」をクリックします。

検索に一致する行から始めて100行のログが、新しいウィンドウに表示されます。

26.9 ファイル・システム・テスト・ツールの使用

「ファイル・システムのテスト」ツールによって、ローカル・アプリケーション・サーバー・ディレクトリと共有ファイル・システム(<cs_install_dir>/Shared)の中央ディレクトリをテストし、提供されているベンチマークとそれらのパフォーマンスを比較できます。

表26-3 テストされるファイル・システム

FileSystem

説明

spc

すべてのWebCenter Sitesクラスタ・メンバーの共有ページ・キャッシュ・ディレクトリ。

サンプル・パス:

\cs76\Shared\SystemPageCache\

local

サーブレット・コンテキスト情報の一時ディレクトリ。

サンプル・パス:

\apache-tomcat-6.0.16\work\Catalina\localhost\cs

data

すべてのWebCenter Sitesクラスタ・メンバーの共有BLOBデータ・ディレクトリ。

サンプル・パス:

\cs76\Shared\ccurl

sync

すべてのWebCenter Sitesクラスタ・メンバーの共有同期ディレクトリ。

サンプル・パス:

\cs76\Shared\clustersync

テスト・スイートは、ローカル・アプリケーション・サーバー・ディレクトリと共有ファイル・システム・ディレクトリで実行されるいくつかのテストで構成されています。これらのテストのそれぞれによって複数のスレッドが実行されます。各スレッドによって、空のファイルが作成され、そのファイルへの書込み、そのファイルの読取り、そのファイルの削除が実行されます。使用可能なテスト・スイートは次のとおりです。

- 小規模のテスト: 合計16個のテストが実行されます(4個のテストが表26-3 にリストされているディレクトリそれぞれに対して実行されます)。

- 中規模のテスト: 合計64個のテストが実行されます(16個のテストが表26-3 にリストされているディレクトリそれぞれに対して実行されます)。

- 大規模のテスト: 合計384個のテストが実行されます(96個のテストが表26-3 にリストされているディレクトリそれぞれに対して実行されます)。

ファイル・システムをテストするには::

1. 「管理」タブで、「システム・ツール」を開き、「ファイル・システムのテスト」をダブルクリックします。
「ファイル・システムのテスト」フォームが表示されます。

2. 実行するテストのタイプを選択し、「テストの開始」をクリックします。
テストは、「パフォーマンスの概要」表に記載されているディレクトリに対して実行されます。ファイル・システム・テストの結果を、その進行に従って追跡できます。

注意:

テストに時間がかかりすぎたり、パフォーマンスへの影響が大きすぎたりする場合は、「テストの停止」をクリックできます。ファイル・システム・テストの結果は、テストが完了したときにのみ、提供されているベンチマークと比較できます。

3. テストが完了したら、「パフォーマンスの概要」表の全体的な結果を確認します。次の情報が、ディレクトリごとに表示されます。

- 太字で表示されている数字はベンチマークです。このベンチマークは、NFSバージョン4を介して10K RPM SAS300 HDに接続されているOracle Secure Linux 5.4システム上で標準テストを実行することで計算されました。クライアントとサーバーの両方が同じネットワーク・スイッチ上にあり、テスト時に他のトラフィックはありませんでした。

- 「ファイル・システム」は、テストが実行されたディレクトリをリストします。

- 「パス」は、ファイル・システム・テストが実行されたディレクトリのパスを示します。

- 「作成」は、作成操作の実行にかかったミリ秒数の平均を示します。

- 「書込み」は、書込み操作の実行にかかったミリ秒数の平均を示します。

- 「読取り」は、読取り操作の実行にかかったミリ秒数の平均を示します。

- 「削除」は、削除操作の実行にかかったミリ秒数の平均を示します。

4. 各テストの詳細は、グラフ(「パフォーマンスの概要」表の下にある)およびテスト結果表(グラフの下にある)を確認してください。

a. 単一テストの結果を表示するには、グラフ上のポイントにマウスを置くか、テスト結果表の行に移動します。

注意:

グラフ上の各ポイントおよび表内の行には、単一テストに関する情報が表示されます。グラフのポイントにマウスを置いて単一テストの詳細を表示するには、Internet Explorer以外のブラウザを使用します。

次の情報が、テストごとに表に表示されます。

- 「テスト」は、各テストのシリアル番号を示します。

- 「スレッド」は、テスト中に作成されたスレッドの数をリストします。

- 「ファイル」は、スレッド1つ当たりに対して作成されたファイルの数をリストします。

- 「サイズ」は、ファイル1つ当たりのバイト数を示します。

- 「読取り」は、テストによって各ファイルが読み取られた回数をリストします。

- 「ロック」は、各ファイルがロックされたかどうかを示します(ランダム・アクセス・ロック操作)。

- 「属性」は、テスト中に各ファイルの属性が読み取られたかどうかをリストします。

- 「モード」は、スレッド中にファイルにアクセスするためのJava I/Oランダム・アクセス・モードをリストします。

- 「ファイル・システム」は、テストが実行されたディレクトリをリストします。

- 「作成」は、テストによる作成操作の実行にかかったミリ秒数の最小、最大および平均をリストします。

- 「書込み」は、テストによる書込み操作の実行にかかったミリ秒数の最小、最大および平均をリストします。

- 「読取り」は、テストによる読取り操作の実行にかかったミリ秒数の最小、最大および平均をリストします。

- 「削除」は、テストによる削除操作の実行にかかったミリ秒数の最小、最大および平均をリストします。

- 「合計テスト時間」は、テストの完了にかかったミリ秒数の合計をリストします。

b. テスト結果表で、行を開き、特定のテスト中に作成された各スレッドに関する詳細を表示します。次の情報が、スレッド詳細表に表示されます。

- 「スレッド」は、各スレッドのシリアル番号を示します。

- 「作成」は、スレッドが空のファイルの作成にかかったミリ秒数の合計を示します。

- 「書込み」は、スレッドがファイルへの書込みの終了にかかったミリ秒数の合計を示します。

- 「読取り」は、スレッドが、それが作成したファイルの読取りにかかったミリ秒数の合計を示します。

- 「削除」は、スレッドがファイルの削除にかかったミリ秒数の合計を示します。

5. テスト結果をスプレッド・シートとしてダウンロードするには、「ファイル・システムのテスト」フォームの上部に移動し、「ダウンロード」をクリックします。

26.10 スロット・アセットの使用

スロット・アセットは、コンテキスト内のWebサイトを編集する際に変更されたプレゼンテーションを格納するために使用します。スロット・アセットは透過的に管理され、ユーザー・インタフェースでは使用できません。システム・ツールの「スロット」ノードは、既存のスロット・データを無効化または削除する場所です。

削除されたスロット・アセットの行は、データベース表から削除されます。無効化されたスロット・アセットは、ステータスがVOに変更されたアセットです。ただし、データベースからは削除されないため、検索やそれに類した照会にも表示されません。無効化されたスロット・アセットは、パージで物理的に削除できます。無効アセットのパージの詳細は、無効アセット・ノードのパージの使用を参照してください。

アセットを無効化または削除するには::

1. 「管理」タブで、「システム・ツール」ノードを開きます。「スロット」ノードをダブルクリックします。

「スロット・アセット・ユーティリティ』フォームが開きます。

2. 「スロット・アセット・ユーティリティ」フォームに、スロット・アセットが表示されます。表のヘッダーをクリックすると、その条件(「スロット名」、「サイト」、「コンテキスト」、「テンプレート」または「プライマリ・アセットID」)でソートされます。または、これらのいずれかの条件を検索パラメータとして選択し、検索する値を入力することによって検索する方法もあります。

3. チェック・ボックスを選択し、1つ以上のアセットを選択します。

4. 「アセットの無効化」をクリックして、選択したアセットを無効化する(後で実行するパージのため)か、または「削除」をクリックしてアセットを削除します。

注意:

スロット・アセットを削除または無効化する場合、確認メッセージは表示されません。残ったアセットのリストが再表示されます。

アセットが無効化されると、いかなるアセットのリストにも、アセットの検索にも表示されません。ただし、データベースではなおも領域を占有しています。場合によっては、無効アセットが占有する領域を解放する必要があります。この処理には、無効アセットのパージを使用します。無効アセットのパージ方法の詳細は、無効アセット・ノードのパージの使用を参照してください。

26.11 URLノードの使用

URLノードでは、カスタムURL (バニティURLとも呼ばれます)を検索、表示および削除できます。これらのURLは、Webサイトの特定のセクションへのリダイレクトに使用するドメインです。ホストされているWebサイトの他の部分には、アクセスできる場合とできない場合があります。通常、これらのバニティURLは、コード化された文字列を含む長いURLを使用しなくても、提供するページにWebユーザーが簡単にアクセスできるようにするために使用します。

バニティURLを表示および管理するには::

1. 「管理」タブで「システム・ツール」を開き、「URL」をダブルクリックします。

「URLユーティリティ」フォームが表示されます(図26-22)。

図26-22 「URLユーティリティ」フォーム

自動生成されたURLを含むすべてのバニティURLが表示されます。

2. 「ホスト」、「URL」、「テンプレート」、「ラッパー」または「HTTPステータス」の検索条件を入力し、「検索」をクリックすることで、リストを絞り込むことができます。

3. 表示されたバニティURLは、「ホスト」、「URL」、「テンプレート」、「ラッパー」および「HTTPステータス」の列ヘッダーをクリックしてソートできます。

4. バニティURLを削除するには、チェック・ボックスを選択し、「削除」をクリックします。

26.12 無効アセット・ノードのパージの使用

「無効アセットのパージ」ノードでは、無効とマークされているアセットを削除できます。無効アセットをすべてパージするのか、または特定のアセット・タイプの無効アセットをパージするのかを選択できます。

無効アセットをパージするには::

1. 「システム・ツール」ノードを開き、「無効アセットのパージ」をダブルクリックします。

2. 無効アセットをパージするアセット・タイプまたはすべてのアセット・タイプを選択します。

3. 「パージ」をクリックします。

アセットがパージされると、次の確認メッセージが表示されます。

asset typeタイプのnアセットをパージしました

アセットが1つもパージされなかった場合、次のメッセージが表示されます。

asset typeタイプの無効アセットが見つかりません

「すべて」が選択された場合、タイプごとに、そのタイプのアセットがパージされたのか、またはそのタイプのパージできるアセットがなかったのかを示すメッセージが表示されます。

27 コンテンツ管理サイトのレプリケート

次の各トピックでは、サイト・ランチャの概要、レプリケーションのガイドライン、要件およびオプション、さらにサイト・ランチャを有効化および使用する手順について説明します。Site Launcherは準備済のコンテンツ管理(CM)サイトをレプリケートし、そのコンポーネントを共有するか、新しいサイトにコピーします。さらに、新規サイトを変更して、デプロイできます。

- サイト・ランチャの概要

- レプリケーションの準備

- サイト・レプリケーションの有効化

- ポストレプリケーション・タスクの実行

27.1 サイト・ランチャの概要

WebCenter Sitesでは、新規サイトを作成する労力をできるだけ少なくするために、サイト・ランチャというサイトレプリケーション・ユーティリティを提供しています。このユーティリティはCMサイトのバックアップ用ではなく、CMサイトをスピンオフさせるために設計されています。

たとえば、管理システムが、Productsという名前の部門に専用のCMサイトをホストしているとします。最近Servicesという新しい部門が設立され、迅速に公開する必要があります。Servicesは、サイズと構造がProductsと類似していますが、メンバーは宣伝担当者ではなく、広報の専門家です。Services CMサイトを最初から作成するのではなく、管理システム上でProducts CMサイトを直接レプリケートして、新しく設立されたServices部門に対応するようにレプリケートされたサイトを変更できます。

サイト・ランチャは、既存のデータベース・スキーマを再利用し、ソース・サイトをネイティブWebCenter Sitesシステム上で直接レプリケートします。サイトが、すばやく簡単にレプリケートされ、コーディングも必要ありません。ただし、レプリケーション自体は、直接的で迅速な手順ですが、管理者の作業では事前準備と事後処理が必要になります。どの程度の負担になるかは、コンテンツ管理の要求によって異なります。

この章の以降の部分では、1:1、1:n、x:nなど(コンテンツ管理モデルを参照)、あらゆるコンテンツ管理モデルで使用できるように、正しくサイトをレプリケートするために従う必要がある手順を説明します。

注意:

サイトのレプリケーションを実施できるのは一般管理者のみです。サイト管理者とワークフロー管理者は、サイト・ランチャへのアクセス権限がないため管理しているサイトをレプリケートできません。

27.2 レプリケーションの準備

サイトのレプリケーションを試みる前に、サイトやレプリケートされたサイトの特性に関するいくつかの推奨事項を考慮する必要があります。さらに、コピーまたは共有するコンポーネントを決定する必要があり、最終的にはソース・サイトがレプリケーションのシステム要件を満たすようにする必要があります。この項では、推奨事項、選択できる方法およびシステム要件について概要を説明します。

- ソース・サイトのレプリケーション要件

- 新規サイトの計画

27.2.1 ソース・サイトのレプリケーション要件

サイト・ランチャは、ほぼすべてのCMサイトのレプリケートに使用できます。小規模、大規模、機能しているサイトや、不完全なサイト、他のサイトから独立したサイトおよびコンポーネントの共有により他のサイトと重複するものなどです。

ただし、Site Launcherを最も効率的に使用するには、小規模で、機能的で、必要なサイトと類似しているサイトから始めるのが最適です。一般に、ソース・サイトは骨格のようなもの、つまり構造とデザインはありますが、コンテンツはほとんどないものにします。これらの特性があると、レプリケートが扱いやすくなるだけでなく、リソースを保存して、レプリケーション時間を短縮しやすくなります。

さらに、ソース・サイトが管理システムに配置されていることを確認します。(レプリケート可能なソース・サイトを先に作成する必要がある場合、WebCenter Sitesの管理のロードマップの手順に従います。)

27.2.2 新規サイトの計画

次の各トピックでは、サイトのレプリケーション・オプションとシステム要件の概要を説明します。

- コピーと共有

- アセット名の接頭辞

- ユーザーの計画

- レプリケーション・スケジュール

27.2.2.1 コピーと共有

ソース・サイトを指定する場合、特定のサイト・コンポーネントをコピーまたは共有するかどうかを決定する必要があるため、最初から、新しいサイトがソース・サイトとの関連でどのように機能するかを決めておきます(複製またはサブセットとして、独立したサイトまたは重複したサイトとして)。(より大きいスケールでは、新しいサイトがコンテンツ管理モデル内の他のサイトとの関連でどのように機能するかも決定します。)

次の表は、ソース・サイトがレプリケートされるとき、多くのコンポーネントがデフォルトで共有されることを示しています。その他のコンポーネントは、任意に共有またはコピーできます。ユーザーは、コピーも共有もされません。

表27-1 コンポーネントとレプリケーション

ソース・サイトのコンポーネント

レプリケーション方法

アセット・サブタイプ

共有

アセット・タイプ

共有

アセット

コピーまたは共有(管理者により決定)

関連付け

共有

パブリッシュの宛先

共有

ロール

共有

スタート・メニュー・アイテム

共有

テンプレート(デザイン・アセット)

コピーまたは共有(管理者により決定)

ツリー・タブ

共有

ユーザー

共有もコピーもされない

ワークフロー・プロセス

共有

アセットのコピーおよび共有は、アセット・タイプ・レベルで選択できますが、アセット・レベルではできません。コピーする(または共有する)アセット・タイプを選択すると、そのタイプのすべてのアセットがコピー(または共有)されます。これはテンプレート(デザイン・アセット)についても同様です。

アセットとテンプレートに関して、管理者固有のタスクは、次の点について決定することです。

- アセットをコピーまたは共有する必要があるアセット・タイプはどれか。

- テンプレート・アセットをコピーまたは共有する必要はあるか。

- 新規サイトでアセットを書式設定されたコンテンツとしてプレビューするか。

アセットとテンプレートをコピーまたは共有する必要があるかどうかを決定するには、次のガイドラインを使用してください。

- アセットを共有するために、アセットをレンダリングするテンプレートを共有する必要はありません。テンプレートはコピーできます。
アセットを共有するのかあるいはコピーするのかは、テンプレートのレンダリング・ロジックがアセット名をどのように処理するかによります。たとえば、テンプレート・ロジックを共有テンプレート(render:satellitepageおよびrender:callelementタグで、明示的なテンプレート名で構成)と、コピー・テンプレート(render:satellitepageおよびcallelementタグで、前にVariables.siteを付けたテンプレート名で構成)のいずれかを仮定するように記述できます。

同じ論理が他のアセット・タイプにも適用されます。レンダリング・ロジックで、フレックス属性名やイメージ名などのアセット名を使用すると、テンプレート・ロジックがアセット・タイプを共有(明示的な名前)またはコピー(構成された名前)のいずれかとして処理し、それに応じてソース・サイトを指定する必要があります。

テンプレート・アセットをコピーすると決定した場合、そのテンプレート・アセットにハードコードされたテンプレート名が含まれておらず、テンプレートがいずれのスタート・メニュー・アイテムの「デフォルト値」リストでも指定されていないことを確認します。

- アセットがサイト・ランチャによって新規サイトと共有されている場合、そのデータは変更されません。例外はテンプレート・アセットです。テンプレート・アセットでは、そのアセットを共有するサイトごとにSiteCatalogエントリが維持されます。テンプレートが共有されると、エントリのテンプレートのリストが更新されます(新規サイトがSiteCatalogエントリのリストに追加されます)。

- 共有アセット内のデータが変更されないため、そのアセットのアセット参照も変更されないまま維持されます。アセット参照を持つアセットが共有される場合は、アセット参照も共有される必要があります。たとえば、ImageFileアセットへの参照を持っている記事アセットがある場合、両方のアセット・タイプを共有し、両方のアセット・タイプをコピーして、記事をコピーし、ImageFilesを共有することができます。
ただし、記事を共有し、ImageFileをコピーすることはできません。これを行うと、サイトのコピーを起動するときエラーが表示されます。

- スタート・メニューは、ソース・サイトとレプリケートされたサイト間で共有されます。したがって、ワークフロー・プロセスがソース・サイトのスタート・メニューで設定されている場合、そのワークフローはレプリケート・サイトでも設定されます。新規サイトでユーザーがアセットを作成するためにスタート・メニュー・アイテムをコールした場合、ワークフローが実行されます。

計画ステージでの決定は、インストール時の指定や、独自のWebCenter Sites環境の管理方法によって左右されます。レプリケーションによって作成されたサイトは、最終的には、管理システムのコンテンツ管理モデルにあわせる必要があります。サイトのモデリングの詳細は、コンテンツ管理モデルを参照してください。

27.2.2.2 アセット名の接頭辞

新規サイトにコピーされるアセットは、次のように接頭辞を使用し、アルゴリズムによって命名されます。

- ソースの接頭辞は、サイトをサイト・ランチャのソース・サイトとして設定するときに指定し、デフォルトではそのサイトの名前になります。

- 新規サイトの接頭辞は、サイト・ランチャ自体で指定し、デフォルトでは、新規サイトの名前です。接頭辞を指定するときには、短いものを指定してください。

- ソース・アセットに接頭辞がある場合、またはアセット・タイプに一意の名前が必要な場合、接頭辞が新規アセットの名前に使用されます。ソース・アセットに接頭辞がある場合、新規アセットでは、古い接頭辞にかわって新しい接頭辞が使用されます。

- ソース・アセットに接頭辞がない場合、新規アセットの名前を生成するためにアセット名の先頭に接頭辞が追加されます。

27.2.2.3 ユーザーの計画

ユーザーがレプリケーション時に新規サイトでコピーまたは共有されない場合、手動でユーザーを新規サイトに追加する必要があります。

ユーザーがソース・サイトのユーザーと異なる場合、ユーザー・アカウントを作成する必要があります。このプロセスでは、新規サイトでのユーザーの機能、必要なロール、スタート・メニュー・アイテムへのアクセス、ワークフロー、ツリー・タブなどを検討してください。

コンポーネント間の元のアソシエーションは、新規サイトで維持されます。ユーザーの機能を再定義する場合、そのサイトでのその他のコンポーネントとのアソシエーションを再定義することが必要になる可能性があります。

27.2.2.4 レプリケーション・スケジュール

通常の処理がサイトのレプリケーションに影響を与えるため、ソース・サイトが頻繁に編集されていないときにサイト・ランチャを実行することをお薦めします。さらに、レプリケーション前に、ソース・サイトのすべてのアセットがデータベースにチェックインされていることを確認してください。そうしないと、リビジョン追跡が有効で、共有するアセットがチェックアウトされている場合、アセットの共有に失敗します。

27.3 サイト・レプリケーションの有効化

この項では、サイト・ランチャの有効化と使用方法を示します。ソース・サイトと計画しているサイトが要件を満たすことを確認したら(レプリケーションの準備を参照)、ソース・サイトを構成およびレプリケートできます。

- サイト・ランチャに対するソース・サイトの構成

- ソース・サイトのレプリケート

27.3.1 サイト・ランチャに対するソース・サイトの構成

サイト・ランチャを構成するには::

この項の手順を完了したら、すぐにソース・サイトのレプリケートの手順を使用して事後処理を行います。即座の事後処理により、ソース・サイトの条件が変更されないことが保証されます。

1. 「一般的な管理」ツリーで、「管理」ノードを開き、続いて「サイト」を開き、続いてレプリケートするサイトをダブルクリックします。これがソース・サイトになります。

「調査」フォームが開きます。

2. 「このサイトのサイト・ランチャの構成」をクリックします。

「サイト・ランチャの構成」フォームが開きます。

図27-1 「サイト・ランチャの構成」フォーム

3. アセットをコピーするには、「アセット接頭辞」フィールドに移動し、アセットの接頭辞を入力するか、デフォルト(ソース・サイトの名前)を受け入れます。

4. 「有効なアセット・タイプ」セクションで、そのアセットをコピーまたは共有するアセット・タイプを見つけて、対応する「コピー」または「共有」ラジオ・ボタンをクリックします。

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

27.3.2 ソース・サイトのレプリケート

ソース・サイトをレプリケーションできるようにしたら、サイト・ランチャを使用して必要な数だけソース・サイトのコピーを作成できます。

ソース・サイトをレプリケートするには::

1. サイト・ランチャに対するソース・サイトの構成の手順を完了していることを確認します。

2. 「調査」フォームの下部にある「コピーの起動」をクリックします。
「サイト・ランチャ」フォームが開きます。

図27-2 「サイト・ランチャ」フォーム

3. 「名前」フィールドに、新規サイトの名前を入力します。サイトに名前を付ける際は、次の規則に注意してください。

- 1から255文字で指定する必要があります。

- 次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、疑問符(?)、アンパサンド記号(&)、小なり記号(<)、大なり記号(>)。さらに、名前の末尾にバックスラッシュは使用できません。

- 名前に空白を含めることはできません。

4. 「説明」フィールドに、新規サイトの説明を入力します。

5. 「パブリッシュの宛先」領域で次の手順を実行します。

a. 必要に応じてチェック・ボックスを選択し、宛先を初期化します。

b. 新規サイトに使用するパブリッシュの宛先を選択します。

6. 「サイトの追加」をクリックしてサイトをコピーします。
新しいサイトが作成された後で、次の内容を示す概要が表示されます。

- どのアセットがコピーまたは共有されたか。共有されているアセットごとに、WebCenter Sitesにより、AssetPublication表に新規サイトのサイトID (パブリケーションID)を示す行が追加されます。コピーされたアセットごとに、WebCenter Sitesにより、元のアセットが格納されている表にコピーが入力されます。

- 新規サイトで共有されるスタート・メニュー・アイテムの数、ワークフロー・プロセスおよびパブリッシュの宛先。

7. この時点で、ユーザーを追加するか、その他の方法で新しいサイトが正しく構成されたことを確認する必要があります。手順とガイドラインは、ポストレプリケーション・タスクの実行を参照してください。

27.4 ポストレプリケーション・タスクの実行

新規サイトの作成後、次の手順を実行して新規サイトの構成を完了する必要があります。

1. 既存のユーザーを新規サイトに追加するのか、新規ユーザーを作成するのかは、新規サイトをどのように計画しているかによります。

- 既存ユーザーを追加するには、次のユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)の手順を実行してください。

- 新しいユーザーを設定するには、WebCenter Sitesの管理のロードマップのガイドラインに従います。

2. ワークフロー・プロセスが存在する場合は、正しいアセット・タイプとロールがスタート・メニュー・アイテムのプロセスに関連付けられていることを確認します。

3. 新規サイトをテストします。

4. 必要に応じて、サイト管理者を作成します。xceladmin ACLをユーザー・アカウントに割り当てて、ユーザーに新規サイトのSiteAdminロールを付与します。

28 リビジョン追跡の管理

WebCenter Sitesはこのリビジョン追跡機能をアセット・タイプに適用します。管理者は、追跡する必要のあるアセット・タイプと保存するリビジョンの数を決定します。その後、必要に応じて、コンテンツ・プロバイダがそれらのアセットをチェックインおよびチェックアウトし、バージョンを比較できます。

次の各トピックでは、リビジョン追跡を有効にする方法およびアセットのバージョンを管理する方法を説明します。

- リビジョン追跡の概要

- リビジョン追跡の有効化

- リビジョン追跡の無効化

- リビジョンのロック解除

28.1 リビジョン追跡の概要

WebCenter Sitesは、リビジョン追跡APIによりリビジョン追跡機能を提供します。このAPIは、アセット・タイプの表に対する追加リビジョン追跡機能の提供に使用されます。

アセット・タイプに対してリビジョン追跡を有効にすると、WebCenter Sitesでは、そのタイプのアセットに対して、トラッカ表と呼ばれる新しい表が作成されます。管理者は、保存するバージョン数を指定し、トラッカ表が追跡するアセットのサポート・ファイルの保存に使用するストレージ・ディレクトリも指定します。

WebCenter Sitesのリビジョン追跡の実装により、次の機能が提供されます。

チェックアウトとチェックイン。

チェックアウトは、一度に1人のユーザーのみが編集できるように、アセットをロックします。

チェックインは、アセットへのロックを解除し、バージョン番号を上げ、バージョンの数が構成した制限内であるかどうかを判断します。新しいバージョンが制限を超えている場合、最も古いバージョンが削除され、次のバージョンのための余地を作ります。

複数のバージョンのアセットの格納。

アセット・タイプに対してリビジョン追跡を有効にすると、WebCenter Sitesはトラッカ表にバージョンを保存します。アップロード・データは、RTInfo表に示すように、指定したストレージ・ディレクトリに格納されます。過去のバージョンが格納されている(つまり、履歴が存在する)ため、ユーザーは、アセットを前のバージョンにロールバックしたり、アセットの2つのバージョンの相違を調べられます。

管理または保守機能。

管理者は、アセットの過去のバージョンを削除したり、アセットのチェックアウトを上書きし、再度チェックインすることで、アセットに対するチェックアウトを消去できます。

アセット・タイプが追跡されるとき、WebCenter Sitesは、これらのタイプのアセットの「新規」フォームおよび「編集」フォームで、チェックイン、チェックアウト、およびその他のリビジョン追跡機能を提供します。

この項の内容は次のとおりです。

- トラッカ表とストレージ・ディレクトリ

- RTInfo表

- リビジョン追跡と2つのアセット・モデル

- 暗黙的チェックインと明示的チェックイン、および明示的チェックアウト

- リビジョン追跡とアセット以外の表

- バージョンの数

28.1.1 トラッカ表とストレージ・ディレクトリ

アセット・タイプのリビジョン追跡を有効にすると、WebCenter Sitesは、ソース表のレコードのリビジョン情報を格納するトラッカ表を作成します。トラッカ表には、そのアセット・タイプのメインのストレージ表と同じ名前に_tを付加した名前が付与されます。たとえば、記事(article)アセット・タイプのトラッカ表の名前はArticle_tとなります。属性タイプ(attribute type)アセット・タイプのトラッカ表の名前はAttrTypes_tとなります。

追跡されたアセット・タイプ表の各レコードに対し、そのバージョン情報を格納する該当のトラッカ表にいくつかの行があります。トラッカ表には次の2種類の列があります。

- リビジョン追跡システムがすべてのバージョンを追跡する必要のあるシステム情報を格納する列

- ストレージ・ディレクトリに格納されるテキスト・ファイルのIDを保持する列

新しいバージョンのアセットがチェックインされると、WebCenter Sitesは、各アセット・タイプのアップロード(URL)フィールドおよび64文字を超える文字を保持するように構成されたテキスト・フィールドのデータを保持するためのテキスト・ファイルを作成します。これらのファイルは、shared/rtStorage/AssetTypeに格納されます。ストレージ・ディレクトリには、アセットのバージョンごとにこれらのテキスト・ファイルが1セット格納されます。

注意:

トラッカ表にはシステム情報のみが保持されるため、これらはOracle WebCenter Sites Explorerには表示されません。トラッカ表の情報はデータベース・ツールで変更しないでください。

28.1.2 RTInfo表

トラッカ表が非表示のままであるのに対し、RTInfo表はOracle WebCenter Sites Explorerで表示されます。この表には、どの表のリビジョンが追跡されるのかについての情報が保持されます。次のような列があります。

表28-1 RTInfo表

列

説明

tblname

リビジョンが追跡される表の名前。アセット・タイプの場合、これはメインのアセット・タイプ表の名前です。

versions

このタイプの各アセットに対して格納するバージョン数。

storage

このタイプのアセットの各バージョンのテキスト・ファイルを保持するストレージ・ディレクトリへのパス。パスは、shared/rtStorage/AssetTypeにある共有フォルダにあります。

recordupdate

バージョンが最後にトラッカ表に格納されたときのタイムスタンプ。

trackingupdate

ソース表に対してリビジョン追跡が有効になった時間。

28.1.3 リビジョン追跡と2つのアセット・モデル

ベーシック・アセットのデータ・モデルはフレックス・アセットのデータ・モデルとは異なるため、この2つのアセット・モデルでは、リビジョン追跡システムの動作が異なります。

- ベーシック・アセットの場合、メインのアセット・ストレージ表の行のみが追跡されます。

- フレックス・アセットとその他の複数表のアセット・タイプ(テンプレートとCSElement)の場合、それらのすべての表の該当する行の情報は、1つのオブジェクトにシリアライズされ、そのアセット・タイプのトラッカ表に格納されます。

たとえば、テンプレート・アセットに対してリビジョン追跡を有効にすると、Template、SiteCatalogおよびElementCatalogの各表の該当する行は、1つのオブジェクトにシリアライズされ、Template_t表に格納されます。

28.1.4 暗黙的チェックインと明示的チェックイン、および明示的チェックアウト

アセット・タイプに対してリビジョン追跡が有効の場合、WebCenter Sitesは暗黙的(自動)チェックアウトと明示的(手動)チェックアウトの両方と、明示的チェックイン機能を提供します。リビジョンが追跡されるタイプのアセットを作成または編集する場合、ユーザーが手動でそのアセットをチェックアウトする必要はありません。アセットは自動的にユーザーに割り当てられます。ただし、暗黙的チェックインはできません。「保存」をクリックしても、アセットは再度チェックインされません。ユーザーは手動でアセットをチェックインする必要があります。

これは、望ましい動作である場合も、そうではない場合もあります。たとえば、作成者が暗黙的にチェックアウトされたアセットに対して多数のリビジョンを作成している場合、その作成者が明示的にそのアセットのチェックインも行うまで、その変更は有効になりません。これにより、保存しておきたい古いバージョンが上書きされることを回避できます。追加の例は、作成者がアセットを暗黙的にチェックアウトして編集する場合で、この場合、作成者は異なる領域に移動して、その後でアセットに戻ります。暗黙的にチェックアウトされたアセットが外部から操作される場合、完了時に明示的にチェックインする必要があります。

暗黙的チェックアウトは、編集と保存が1つの操作で行われる迅速な編集に使用されます。このタイプの更新は、最小限のクリックで実行できると予期されます。明示的チェックアウトは、時間経過に伴うアセットの変化のためのものです。

コンテンツ・プロバイダが暗黙的または明示的にアセットをチェックアウトすると、これを何回保存しても、手動で再度チェックインされるまでバージョンは格納されません。

28.1.5 リビジョン追跡とアセット以外の表

アセット・タイプに対するリビジョン追跡の使用に加え、アセット以外の表にリビジョン追跡を実施することもできます。

このためには、「管理」タブの「ユーザー・アクセス管理」機能を使用して、表に対する追跡を有効にします。すると、WebCenter Sitesは対応するトラッカ表を作成し、追跡される表をサポートします。これには、アセット・タイプのトラッカ表と同様にnameOfTable_tという名前が付けられます。

アセット以外の表に対してリビジョン追跡が有効になっている場合、Oracle WebCenter Sites Explorerのメニューまたは「管理」タブの「ユーザー・アクセス管理」ノードからアクセスできるリビジョン追跡機能を使用して、行をロック(チェックアウト)し、完了したらその行をロック解除(再度チェックイン)できます。

アセット以外の表のリビジョン追跡に対して、Oracle WebCenter Sites Explorerツール以外の追加サポートを提供する必要がある場合、開発者は、WebCenter Sitesリビジョン追跡APIおよびリビジョン追跡XMLまたはJSPタグを使用して、追加のフォームをコード化できます。詳細は、Oracle WebCenter Sitesタグ・リファレンスおよびOracle WebCenter Sites Java APIリファレンスを参照してください。

注意:

WebCenter Sitesデータベースからアセット以外の表を削除する必要があり、そのテーブルがリビジョン追跡されている場合は、表を削除する前に追跡を解除してください。

28.1.6 バージョンの数

アセットまたはデータベースの行の各リビジョンは、ディスク領域を占有します。したがって、保存するリビジョン数の決定は、次の要因に基づくものである必要があります。

- 使用可能なディスク領域の量

- 一般的なアセット(または行)のデータ・サイズ

- いくつかのバージョンのロールバックが必要となる可能性

たとえば、少量のASCIIデータから構成されるアセットは、ほとんど領域を占有しないため、多数のリビジョンでもあまりディスク領域を取らない可能性があります。しかし、大量のバイナリ・データを保持するアセットの各バージョンは、かなりの量のディスク領域を占有する可能性があります。2番目の場合、ロールバックに必要な最小限のバージョンを格納して、適切なバランスを取る必要があります。

28.2 リビジョン追跡の有効化

リビジョン追跡は、アセットおよびアセット以外の表に対して有効にすることができます。次の各トピックで説明します。

注意:

リビジョン追跡がパブリッシュのターゲット宛先でElementCatalogまたはSiteCatalogのいずれかに対してオンになっている場合、テンプレートのパブリッシュは失敗し、テンプレートは壊れる可能性があります。

ターゲット宛先でリビジョン追跡を有効にすることはお薦めできません。

- アセットに対するリビジョン追跡の有効化

- アセット以外の表に対するリビジョン追跡の有効化

- リビジョン追跡設定の編集

28.2.1 アセットに対するリビジョン追跡の有効化

アセットに対してリビジョン追跡を有効にするには::

1. 「管理」タブで、「アセット・タイプ」 を開き、リビジョン追跡を有効にするアセット・タイプを開きます。

2. 選択したアセット・タイプの下で「リビジョン追跡」を開き、「追跡」をダブルクリックします。

アセット・タイプの追跡フォームが表示されます。

3. 「保持するリビジョン」フィールドで、選択したアセット・タイプの各アセットについて、WebCenter Sitesで格納するリビジョンの数を入力します。この数のリビジョンが格納されると、最も古いリビジョンが、次のリビジョンによって上書きされます。

レコード・ロック機能にのみリビジョン追跡を使用し、前のバージョンへのロールバックが必要ない場合は、このフィールドを1に設定できます。

4. 「リビジョン追跡の有効化」をクリックします。

28.2.2 アセット以外の表に対するリビジョン追跡の有効化

アセットを保持しないデータベース表に対してリビジョン追跡を有効にするには、「ユーザー・アクセス管理」ノードを使用します。

アセット以外の表に対してリビジョン追跡を有効にするには::

1. 「管理」タブで、「ユーザー・アクセス管理」を開き、「リビジョン・トラッキング」をダブルクリックします。

2. 開いたフォームで、「表の追跡」を選択し、「OK」をクリックします。

3. 「ルート・ストレージ・ディレクトリの入力」フィールドで、表の行のリビジョンが格納されるディレクトリへのフルパスを入力します。ディレクトリ名の後にスラッシュ(またはバックスラッシュ)文字を入れないでください。

4. 「保持するリビジョンの数の入力」フィールドで、ロールバックのためにWebCenter Sitesで格納する必要のあるリビジョンの数を入力します。

5. リビジョン追跡を有効にしている各表の横にある「追跡」チェック・ボックスを選択します。

6. 「表の追跡」をクリックします。

28.2.3 リビジョン追跡設定の編集

リビジョン追跡設定の調査または編集には、SiteGod、Xceladmin、Visitor AdminまたはRemote ClientのいずれかのACLが必要です。どのACLもない状態で、追跡されるアセット・タイプまたはアセット以外の表の現在のリビジョン追跡設定の調査を試みても、システムではルート・ストレージ・ディレクトリの名前やリビジョンの数が表示されません。リビジョン追跡設定ディレクトリはデータベースに影響を与えるため、これらの設定を変更する際は注意が必要です。

この項の内容は次のとおりです。

- ルート・ストレージ・ディレクトリの変更

- リビジョンの数の変更

28.2.3.1 ルート・ストレージ・ディレクトリの変更

注意:

アセット・タイプまたはアセット以外の表のルート・ストレージ・ディレクトリを変更する場合、そこに現在格納されているすべてのバージョンは失われます。

ルート・ストレージ・ディレクトリを変更する必要がある場合は、次の手順に従ってください。

1. アセット・タイプまたは表に対するリビジョン追跡を無効にします。無効にすると、そのアセット・タイプのすべてのバージョン・データは親がなくなります。

2. 新しいルート・ストレージ・ディレクトリを入力し、アセット・タイプまたは表に対するリビジョン追跡を有効にします。

28.2.3.2 リビジョンの数の変更

この後の項では、アセット・タイプまたは表に格納されるリビジョンの数の増減について説明します。

1. アセット・タイプに対して格納されるリビジョンの数を増やすには、「保持するリビジョン」フィールドの値を増やすのみです。

2. 値を増やすには、「管理」タブで、「アセット・タイプ」、変更するアセット・タイプ、「リビジョン追跡」の順に開き、「リビジョンの設定」をダブルクリックします。 表示されるフォームを使用して、値を大きくします。

WebCenter Sites開発システムで構成設定をテストする際、またはWebCenter Sites管理システムを微調整する際にバージョン数を減らす必要がある場合がありますが、管理システムではリビジョン追跡により格納されるバージョン数は減らさないことをお薦めします。

「保持するリビジョン」フィールドの値を、現在格納されているリビジョン数未満に減らすと、次のようになります。

- 余分なバージョンのストレージ・ディレクトリ内のテキスト・ファイルは、親がなくなります。

- 余分なバージョンのトラッカ表内の行は、親がなくなります。

リビジョン数を減らす前に、余分なバージョン(最も古いバージョン)を削除することにより、トラッカ表内に親のない行が作成されることを回避できます。ただし、ストレージ・ディレクトリ内で親のないテキスト・ファイルが作成されることは回避できません。削除するファイルを判断することは非常に困難であるため、これらは削除しないでください。

リビジョン数を減らす必要がある場合は、アセット・タイプに関連付けられているフォームを使用します。「管理」タブで、「アセット・タイプ」、変更するアセット・タイプ、「リビジョン追跡」の順に開き、「リビジョンの設定」をダブルクリックします。値を小さくするには、フォームを使用します。

28.3 リビジョン追跡の無効化

アセット・タイプまたはアセット以外の表に対してリビジョン追跡を無効にすると、次のようになります。

- トラッカ表は無効となりますが、削除されることはありません。ここに格納されているバージョンは親がなくなりますが、削除されることはありません。表に対してリビジョン追跡が無効になると、WebCenter Sitesリビジョン追跡フォームを使用してバージョンを削除できなくなります。

- ストレージ・ディレクトリ内のテキスト・ファイルへのリンクはすべて壊れますが、ファイル自体は親がなくなるだけで、削除されません。

そのアセット・タイプに対するリビジョン追跡を再び有効にすると、古いバージョンおよびテキスト・ファイルは無視され、親がないままになります。

これらの古いバージョンは不要な領域を占有するので、場合によってはそれらを手動で削除する必要があります。そのアセット・タイプのストレージ・ディレクトリ内にあるリビジョン追跡ディレクトリからすべてのテキスト・ファイルを手動で削除します。たとえば、アセット・タイプのストレージ・ディレクトリが/Storage/AssetTypeの場合、/Storage/AssetType/AssetTypeのリビジョン追跡ディレクトリからすべてのファイルを削除します。

注意:

アセット・タイプのストレージ・ディレクトリのファイルは削除しないでください。

アセット・タイプに対してリビジョン追跡を無効にするには::

1. 「管理」タブで、「アセット・タイプ」を開き、リビジョン追跡を無効にするアセット・タイプを開きます。

2. 選択したアセット・タイプの下で「リビジョン追跡」を開き、「追跡の解除」をダブルクリックします。

WebCenter Sitesに警告メッセージが表示されます。

3. 「追跡の解除」をクリックします。

28.4 リビジョンのロック解除

ユーザーの操作により、アセットが不適切なロック状態のままになる場合があります。このような状態を解決するのは管理者の役割です。

アセット・タイプの場合、「管理」タブの「チェックアウトのクリア」機能を使用します。

開始する前に、アセットがロックされているユーザーの名前を検索します。この情報は、そのアセットの「調査」フォームにリストされています。

アセットに対してチェックアウトを消去するには::

1. 「管理」タブで、「チェックアウトのクリア」をダブルクリックします。

WebCenter Sitesに「チェックアウトの検索」フォームが表示されます。

2. アセットがロックされたままのユーザーの名前を入力し、「チェックアウトの表示」をクリックします。

3. 選択されたユーザーにチェックアウトされたアセットのリストで、チェックアウトを元に戻す各アセットの横にある「クリア」チェック・ボックスを選択します。

4. 「チェックアウトのクリア」をクリックします。

29 バニティURLの構成

この章では、短く、可読で、簡単に管理できるURLであるバニティURLについて説明します。通常は、名前のように読んでわかりやすい情報か、バニティURLが参照するWebページのコンテンツを説明する情報で構成されます。

バニティURLは、製品の既存のURLに置き換わるものではありません。バニティURLは既存のURLと共存し、どちらを使用してもコンテンツにアクセスできます。バニティURLは、コンテンツ・コントリビュータがOracle WebCenter Sites: Contributorインタフェースで自動生成またはカスタム作成します。

通常のWebCenter Sites URLの例:

http://www.example.com/<context>/Satellite?c=Page&cid=3451344545&pagename=avisports/Page/HomeLayout

同じアセットに、次のようなバニティURLを指定できます。

http://www.example.com/Running/Home

この例からわかるように、バニティURLの方が(特にモバイル・デバイス上で)簡単に入力でき、ユーザーが読んだり、後で思い出したりしやすいという利点があります。

バニティURLは、2つの部分から構成されています。まず、様々な環境でのバニティURLの解釈を制御するWebRoot。バニティURLのもう1つの部分は、URLパターンまたはフリー・フォーム・エントリです。URLパターンは、アセット・タイプ全体に対して定義されるルールですが、フリー・フォーム・エントリは、コンテンツ・コントリビュータによって各アセットに対して個々に作成されます。

この章の内容は次のとおりです。

- WebRootsの使用

- バニティURLの生成

- システム・ツールによるバニティURLの使用

- リライタ・フィルタによるバニティURLの解決

- モバイル・サイトのバニティURLの使用

- WebサーバーによるバニティURLの処理

- mod_rewriteによるバニティURLの処理

29.1 WebRootsの使用

WebRootは、バニティURLの解釈方法を制御するために使用します。WebRootはアセットに似ています。WebRootを配信システムで使用するには、構成した後に宛先にパブリッシュする必要があります。

WebRootsには、絶対および相対の2つの形態があります。絶対WebRootは、URL接頭辞全体(ホストおよびポート情報など)を含んでいる必要があり、また、オプションでPATH接頭辞を含む場合もあって、すべてのサーバーに固有です。相対WebRootは、PATHに関連する情報のみを含んでおり、ホストまたはポートに関する情報は一切含みません。両方のURLとも、WebCenter Sitesによって同様に処理されますが、相対WebRootでは、複数の環境(たとえば開発環境、ステージング環境および本番環境)でも単一のWebRootのみが必要です。絶対WebRootでは、これらの環境の各々が固有のWebRootを持ちます。

この制限を除去するために、VirtualRootの概念がサポートされています。VirtualRootを使用するには、wcs_properties.jsonファイルに環境識別子(sites.environment)を設定して、指定の環境で有効であることを識別する必要があります。パラメータが存在しない場合、WebRootが使用されます。絶対ルートと相対ルートを同時に定義しておくと便利な場合があるため、WebRootsのタイプを特定および理解しておくことは重要です。表29-1に、このタイプのWebRootsの長所と短所をリストします。

表29-1 WebRootの各タイプの利点と欠点

WebRootタイプ

利点

欠点

絶対WebRoot

- コンテンツ・コントリビュータに対してURL全体が表示される

- すべての環境に固有のURLが必要

- 仮想ルートを使用するためにWebCenter Sitesのプロパティを設定する必要がある。

- パブリッシュの前にバニティURLをテストすることは困難。

相対WebRoot

- すべてのシステムを通じて1つのWebRootで動作する

- パブリッシュの前にバニティURLを簡単にテストできる

- コンテンツ・コントリビュータには、URL全体ではなく、パスのみが表示される。

- 場合によってはURLをリライトする手順を実行する必要がある

組合せ

- コンテンツ・コントリビュータに対してURL全体が表示される

- すべてのシステムを通じて1つのWebRootで動作する

- パブリッシュの前にバニティURLを簡単にテストできる

- 使用するURLの数が増え、それらを格納/パブリッシュする必要がある。

- コンテンツ・コントリビュータには相対WebRootと絶対WebRootの両方のURLが表示される。URLの数が増えるので、コンテンツ・コントリビュータが混乱する可能性がある。

29.1.1 URLに必要なWebRootsの様々なタイプ: 例

次の例では、この章の冒頭で示したバニティURL (http://www.example.com/Running/Home)を使用し、管理サーバーと本番サーバーでそのURLを使用したり、アクセスしたりする方法を示します。

各環境で使用するバニティURLは次のとおりです。

- 本番: http://www.example.com/Running/Home

- 管理: http://management.example.com/Running/Home

パス部分であるURLのRunning/Homeパスの詳細は、バニティURLの生成を参照してください。

本番サーバーに使用するサーバー名はhttp://www.example.com/、管理サーバーに使用するサーバー名はhttp://management.example.com/です。

絶対WebRootの場合、ルートURLをhttp://www.example.comとして、各環境に固有のWebRootが必要です。プロパティ管理ツールでsites.environmentプロパティをmanagementに設定します。サイトは、avisportsです。

仮想ルートURIのWebRootに指定する値とsites.environmentプロパティに指定する値は同一である必要があることに注意することが重要です。

相対WebRootの場合、すべての環境を通じて1つのWebRootを使用します。ルートURLは/です。サイトは、avisportsです。

29.1.2 新しいWebRootの作成

新しいWebRootを作成するには::

1. 「管理」タブで、「WebRoots」を開きます。「新規追加」をダブルクリックします。

図29-1に示すように、WebRoot edit編集フォームが開きますが、すべてのフィールドは空白です。

図29-1 WebRoot編集フォーム

2. 「ホスト名」フィールドに名前を入力します。

この名前がWebRootインスタンスの一意の識別子になります。描画タグでそれを使用して、アセットの固有のバニティURLを取得できます。WebRootを保存した後でこの値を変更することはできません。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

3. 「ルートURL」フィールドにURLを入力します。

ルートURLの値は、絶対と相対のいずれかです。絶対WebRootの場合、通常、これは、配信環境でアセットをレンダリングするために使用されるURLです。相対WebRootの場合、これは/<Optional PATH Prefix>です。

コンテンツ・コントリビュータにとって、これは定義されているバニティURLを表示する際に接頭辞として使用するURLです。例:

- ホスト名のみを使用する絶対ルートURL

- 本番URL: http://www.example.com

- 完全なバニティURL: http://www.example.com/Running/Home

- ホスト名と接頭辞の両方をパスに含む絶対ルートURL

- 本番URL: http://www.example.com/Prefix

- 完全なバニティURL: http://www.example.com/Prefix/Running/Home

- モバイル・サイト向けのホスト名を含む絶対ルートURL

- 本番URL: http://www.example.mobi

- 完全なバニティURL: http://www.example.mobi/Running/Home

- 相対ルートURL

- 本番URL: /<context>/example

- 完全なバニティURL: http://<Current Host Name>/<context>/example/Running/Home

- 相対ルートURL

- 本番URL: /

- 完全なバニティURL: http://<Current Host Name>/Running/Home

4. 1つ以上の仮想URLを入力します。仮想URLは2つの部分から構成されます。

- 環境: 他の環境の識別子。wcs_properties.jsonファイルにsites.environment=<nameを設定して、環境を識別する必要があります。Adminインタフェースで、プロパティ管理ツールからこのプロパティを設定します。詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

- ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。

初期表示では、環境とルートURLを追加するための行が1つのみ存在します。「新規追加」ボタンをクリックすると、「環境」フィールドと「ルートURL」フィールドで構成される行が追加されます。

入力する仮想URLには、絶対ルートURLを使用する必要があります。例:

- http://management.example.com/Running/Homeという管理URLの場合、次のように入力します。

- 環境: management

- ルートURL: management.example.com

- sites.environment=management in wcs_properties.json (このプロパティはプロパティ管理ツールを使用して設定します)。

- http://staging.example.com/Running/HomeというステージングURLの場合、次のように入力します。

- 環境: staging

- ルートURL: staging.example.com

- wcs_properties.jsonのsites.environment=staging (このプロパティはプロパティ管理ツールを使用して設定します)。

- http://dev.example.com:8080/Running/Homeという開発URL (ポートを含む)の場合、次のように入力します。

- 環境: dev

- ルートURL: dev.example.com:8080

- wcs_properties.jsonのsites.environment=dev (このプロパティはプロパティ管理ツールを使用して設定します)。

注意:

仮想ルートURLは、Contributorインタフェースでの表示には使用されません。これが使用されるのは、「環境」の値がwcs_properties.jsonのsites.environmentプロパティに設定されている値と一致する環境でWebページをレンダリングする場合のみです。

5. 1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。

次の例では、「サイト」にavisportsを設定しています。これは、このサイトに固有のURLを使用しているためです。

6. すべての情報を追加したら、「保存」アイコンをクリックします。

WebRootが作成されます。

初めて作成した後のWebRootは、「管理」タブの「アセット・タイプ」ノードにアセット・タイプとして表示されます。

29.1.3 WebRootの表示

WebRootを表示するには::

1. 「管理」タブで、「WebRoots」を開きます。リストされたWebRootをダブルクリックします。

図29-2に示すようにWebRootの「コンテンツ」フォームが開き、保存されているそのWebRootの情報が表示されます。

図29-2 WebRootの「コンテンツ」フォーム

29.1.4 既存のWebRootの編集

既存のWebRootを編集するには::

1. 「管理」タブで、「WebRoots」を開きます。リストされたWebRootをダブルクリックします。

図29-2に示すように、WebRoot編集フォームが開きます。

2. WebRootを編集するには、「編集」アイコンをクリックします。

図29-3に示すように、WebRoot編集フォームが開きます。

図29-3 WebRoot編集フォーム

3. 「ホスト名」、「ルートURL」、「仮想ルートURL」および「サイト」の各フィールドに、保存されている情報が開きます。

「ホスト名」フィールドは、WebRootインスタンスの一意の識別子です。描画タグでこれを使用して、アセットの固有のバニティURLを取得できます。

「ルートURL」フィールドは、通常は、配信環境でアセットのレンダリングに使用するURLです。これは、コンテンツ・コントリビュータに対して表示されるURLです。

「仮想ルートURL」は2つの部分から構成されます。

- 環境: 他の環境の識別子。wcs_properties.jsonファイルにsites.environment=<nameを設定して、環境を識別する必要があります。Adminインタフェースで、プロパティ管理ツールからこのプロパティを設定します。詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

- ルートURL: これは編集、ステージングなど、他の環境でアセットをレンダリングするために使用するURLです。

仮想URLをさらに追加するには、「新規追加」ボタンをクリックして、「環境」フィールドと「ルートURL」フィールドで構成される行を追加します。

1つ以上のサイトを選択します。「サイト」フィールドを使用して、WebRootを特定のサイトで有効にできます。

4. すべての情報を追加したら、「保存」アイコンをクリックします。WebRootが更新されます。

29.1.5 WebRootの承認とパブリッシュ

WebRootは、他のアセットと同じ方法でパブリッシュ用に承認できます。

1. WebRootをプレビューした状態で、緑のチェック・マーク・アイコンをクリックします。

2. 管理者は、WebRootを個別に承認してパブリッシュする必要があります。WebRootはブロッキング・アセットとして設定されることはありません。

29.2 バニティURLの生成

バニティURLを構成する方法は2つあります。1つは、コンテンツ・コントリビュータでバニティURLを個別に手動で構成する方法です(詳細は『Oracle WebCenter Sitesの使用』を参照してください)。この項では、パターンからバニティURLを生成するもう1つの方法について説明します。

この項の内容は次のとおりです。

- 自動生成URLの構成

- URLパターンの使用

- URLパターンのパブリッシュについて

- バニティURLへのリダイレクトの無効化

29.2.1 自動生成URLの構成

パターンに基づくバニティURLは、個々のアセットから自動生成されます。パターンを登録した後、アセットを初めて保存する際にバニティURLが生成されます。パターンは、アセット・タイプごとに作成できますが、1つのサイトでのみ有効です。アセット・タイプを共有する各サイトに、同じパターンを作成する必要があります。

注意:

パターンを変更した場合、それが反映されるのはアセットを作成または保存するときのみです。パターンを変更した場合、または新しいパターンを作成した場合、それらはパターンを保存した後に作成されたアセットにのみ適用されます。

自動生成されるバニティURLを構成するには::

1. 「管理」タブで、「アセット・タイプ」ノードを開き、自動生成URLを作成する特定のアセット・タイプのノードを開きます。この特定のアセット・タイプのノードで「URLパターン」を開き、「新規追加」をダブルクリックします。

「URLパターン・フォーム」が表示されます。

図29-4 「URLパターン・フォーム」 - 「アセット」

図29-5 「URLパターン・フォーム」 - 「Blob」

2. 「名前」フィールドにパターンの名前を入力します。この名前は一意で、このパターンを参照するためにのみ使用され、いつでも変更できます。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、パーセント記号(%)、アンパサンド(&)、疑問符(?)、小なり記号(<)、大なり記号(>)およびバックスラッシュ(\)。

3. 「パターン」フィールドに、バニティURLを定義するルールを入力します。使用可能な有効な属性と関数のリストが右側に表示されます。パターン作成の詳細は、URLパターンの使用を参照してください。

4. 「BLOBヘッダー」フィールド(Blobが選択されている場合のみ入力可能)に、バニティURLのBLOBヘッダーの定義に使用するルールを入力します。

5. 「サイト」は、パターンが適用されるサイトで、アセット・タイプが有効である場所のみリストされます。サイトを選択しても、「ホスト」(WebRoot)、「サブタイプ」、「テンプレート」(アセットのみ)および「ラッパー」(アセットのみ)の選択を絞り込めます。

注意:

このサイトでこのアセット・タイプが後から無効にされても、定義されているパターンは残ります。ただし、そのようなURLを使用すると、機能しないページが表示される可能性があります。

6. 「ホスト」は、バニティURLが適用されるWebRootです。このサイトに定義されているWebRootまたは「任意」のみが表示されます。WebRootが存在しない場合、パターンは機能しません。

7. 「サブタイプ」は、バニティURLが適用されるアセット・タイプのサブタイプです。「サブタイプ」を選択すると、「テンプレート」と「ラッパー」で選択できるアイテムが絞り込まれます。

注意:

BLOBの「サブタイプ」フィールドには、フレックス・アセットのオプションとして「任意」は表示されません。BLOBの「サブタイプ」フィールドは、ベーシック・アセットの場合は表示されません。

8. 「フィールド」は、このURLでレンダリングされるBLOBです。このフィールドは、BLOBが選択された場合のみ表示されます。アセットに複数のBLOBエントリが含まれる場合、複数のアイテムが表示される可能性があります。

「ダウンロード可能」チェック・ボックスを選択すると、このバニティURLにアクセスしたとき、ブラウザでは、ページ内にBLOBオブジェクトではなく保存ダイアログが表示されます。

9. 「デバイス・グループ」には、定義されているデバイス・グループのリストが表示されます。このフィールドは、アセットが選択された場合のみ表示されます。デバイス・グループが、サイトにおける現在の状態に関係なく、拡張子に基づいてフォーマットされてリストに表示されます。デバイス・グループの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

10. 「テンプレート」はURLのテンプレートで、そのアセット・タイプ、サブタイプおよびサイトにあてはまるテンプレートはすべて、モバイル・バリエーションの存在に関係なく、表示されます。有効であるすべてのテンプレートが表示されますが、すべてのテンプレートに、指定された「デバイス・グループ」用のバリエーションがあるとはかぎりません。デフォルトでないデバイス・グループを使用する場合、適切なバリエーションが存在することを確認するのは、管理者の仕事です。

11. 「ラッパー」には、「テンプレート」で選択したテンプレートで有効なすべてのラッパー要素のリストが表示されます。1つも存在しない場合、このフィールドは無効になります。

12. ここで、「保存」をクリックしてパターンを保存して作業を続行するか、URLパターンを評価できます。

フォームの「URLパターンの評価」セクションには、パターン生成されたバニティURLがどのようなものか、例が表示されます。パターンを検証するために保存する前に、URLパターンを評価することをお薦めします。

注意:

該当するタイプのアセットがない場合、この機能は使用できません。

13. 「アセット」リストでは、パターン・タイプに現在定義されているアセットを選択できます。アセット・タイプの名前を入力するために、「先読み」機能も使用できます。アセットを選択すると、WebCenter Sitesは作成されたパターンを評価し、このアセットのURLがどのように表示されるかを示します。これは、URLの最終的な見かけのほんの一例です。パターンが保存され、アセットが編集、保存されるまで、URLは有効になりません。

29.2.2 URLパターンの使用

自動パターンは、バニティURLの中心的存在です。ただし、管理者がパターン一致させたURLは、多くの場合、サイトに存在するバニティURLの大部分を構成します。パターンはパスと変数を組み合せた形式であり、変数はアセットから取得するフィールドまたは事前定義済関数です。

注意:

URLのすべての部分は、保存する前にURLとしてエンコードされます。

存在する実際の変数は、選択されているアセット・タイプに応じて異なりますが、すべてのアセット・タイプで共有される共通変数が存在します。表29-2 に、頻繁に使用される変数をリストします。

表29-2 共通のアセット・タイプ変数

変数名

変数タイプ

createdby

文字列

createddate

日付

description

文字列

enddate

日付

fwtags

配列

id

long

locale

文字列

name

文字列

startdate

日付

status

文字列

subtype

文字列

template

文字列

updatedby

文字列

updateddate

日付

変数をパターン・フィールドの後に配置するには、クリックします。カーソルがどこにあっても違いはなく、新しいパターンは常に最後のアイテムです。

変数は、${<Name>}のように指定します。たとえば、アセットのIDを取得するには、${id}と指定します。

タイプがstring、intおよびlongの変数は、変更せずにそのまま使用できます。

タイプがarrayの変数は、1つの値のみが抽出されるように指定する必要があります。たとえば、アセットに最初に定義されているタグを取得するには、${fwtags[0]}と指定するか、またはlistAsPath関数を使用します。配列の番号付けは0で始まり、配列の境界外の値を使用するとNULLになります。

タイプがdateの変数はフォーマットする必要があります。そのための関数としてformatDateが用意されています。

urlなど、他のタイプは、使用できなかったり、URLを生成する機能を必要としたりする場合があります。これらの変数を使用する場合、「URLパターンの評価」オプションを使用すると便利です。

通常のJava関数も追加できるように、変数はJava標準タイプを使用して定義されています。たとえば、nameというstring変数に対して、name.toLowerCase()は名前を小文字に変換します。

この項の内容は次のとおりです。

- 関数の使用

- パターンの使用

- パターンの削除

29.2.2.1 関数の使用

関数は、データを変換およびフォーマットして、バニティURLに使用する際に役に立ちます。WebCenter Sitesには、バニティURLの作成に役立つ事前定義済関数が用意されています。

1. 機能をクリックすると、パターン・フィールドの後に表示されます。

カーソルがどこにあっても違いはなく、新しいパターンは常に最後のアイテムです。次に、事前に定義されたヘルパー関数のリストを示します。

- spaceToUnderscore(java.lang.String)
空白を_に変換します。たとえば、Page 001がPage_001になります。

- formatDate(java.util.Date, java.lang.String)
日付を数字とスラッシュを使用した形式にフォーマットします。たとえば、updatedateが"Thu Feb 28 12:57:12 UTC 2013"である場合、formatDate関数を使用して"2/28/2013"と表示できます。使用する文字列は、JavaのSimpleDateFormat関数で使用する文字列と一致する必要があります。

- spaceToDash(java.lang.String)
空白を-に変換します。たとえば、Page 001がPage-001になります。

- listAsPath(java.util.List, int)
配列を、その先頭のx個のアイテムのリストに変換します。たとえば、[1, 2, 3 ,4, 5, 6]という配列に対してlistAsPathをx = 4で使用すると、1\2\3\4というリストが生成されます。

x (intで定義)は必須です。

- getFileName(com.fatwire.assetapi.data.BlobObject)
BLOBオブジェクトのファイル名をテキストとして取得します。たとえば、BLOBの名前がxyz.pngである場合、テキストxyz.pngを返します。通常は、これを一番最後に使用して、正しいファイル拡張子を指定します。

この関数は、アセット・メーカー・アセットのバイナリ・フィールドには使用できません。

- property(java.lang.String, java.lang.String, java.lang.String)
iniファイルまたはプロパティ・ファイルからプロパティを読み込みます。これは、ics.GetPropertyを使用します。このメソッドのパラメータは、1)プロパティ名、2)プロパティがない場合はデフォルト値、3)ファイル名のカンマ区切りリストです。

関数は、${f:<name>(<variables>)}という形式で指定します。したがって、前述のspaceToUnderscoreの例の関数は次のように記述します。

${f:spaceToUnderscore("Page 001")}

2. 記述が正しくない場合、または無効なパラメータを渡した場合、「URLパターンの評価」セクションで、パスの該当する部分にはNULLが返されます。最も外側の変数のみ${}を使用する必要がありますが、すべての関数は先頭にf:を指定する必要があります。

29.2.2.2 パターンの使用

ここでは、avisports記事アセット・タイプに基づいて例を示します。アセット名は、"Baker Likely to Stay With Stars"です。

図29-6 「URLパターン・フォーム」 - 「アセット」

注意:

URLの先頭部分は常にWebRootです。例の場合、これはローカル・システム名とコンテキスト・ルートです。次の部分、「Avi」はフィルタ接頭辞です。この後の例では、固有のパスのみを示します。

アセット"Baker Likely to Stay With Stars"に対して、URL生成に使用できる様々なオプションがあります。それぞれの例で、関数と生成されるURLを示します。

1. まずは単純な名前のパターンです。

- /Article/${name}

- /Article/Baker+Likely+to+Stay+With+Stars

2. 名前を小文字に変換します。

- /Article/${name.toLowerCase()}

- /Article/baker+likely+to+stay+with+stars

3. このURLから空白を削除します。

- /Article/${f:spaceToUnderscore(name)}

- /Article/Baker_Likely_to_Stay_With_Stars

4. 複数の変数を使用します。

- /Article/${id}/${createdby}

- /Article/1328196049037/fwadmin

5. 関数内部で関数を使用します。

- /Article/${(f:formatDate(createddate,"yy/MM/dd")}

- /Article/12-04-27

29.2.2.3 パターンの削除

パターンは、ナビゲーション・ツリーから削除できます。

パターンを削除するには::

1. 「管理」タブで、「アセット・タイプ」を開きます。パターンが含まれるアセット・タイプをダブルクリックします。

選択したアセット・タイプが開きます。

2. 「URLパターン」をダブルクリックします。

現在保存されているパターンが表示され、他のアセットと同様に調査、編集または削除できます。

29.2.3 URLパターンのパブリッシュについて

パターンは、アセット・タイプとともに自動的にパブリッシュされます。URLパターンの場合、特に承認またはパブリッシュする必要はありません。

29.2.4 バニティURLへのリダイレクトの無効化

開発者が一時的にバニティURLを無効化したい、いくつかのインスタンスがあります。たとえば、テスト・インスタンスをバニティURLにリダイレクトしたくないことがあります。バニティURLを有効化および無効化するフラグが、futuretense.iniパラメータに含まれています。

バニティURLリダイレクションを無効化するには:

1. -Dsites.disablevanityurlフラグのTrueへの設定。

2. このフラグをfalseに設定すると、バニティURLリダイレクトが戻されます。

29.3 システム・ツールによるバニティURLの使用

「システム・ツール」ノードを使用すると、管理者は現在定義されているすべてのバニティURLを表示して、URL競合を解決できます。次の各項の説明を参照してください。

- すべてのバニティURLの表示

- バニティURL競合の解決

29.3.1 すべてのバニティURLの表示

すべてのバニティURLを表示するには:

1. 「管理」タブで、「システム・ツール」ノードを開きます。

2. 「URL」をダブルクリックします。

「URLユーティリティ」フォームが開きます。

図29-7 「URLユーティリティ」フォーム

このリストには、(すべてのサイトで)定義されているすべてのURLが表示されるので、用意されている検索ボックスを使用してフィルタすることによって、目的のURLを探す必要があります。このメニューから、バニティURLの手動による削除、問題の有無のチェック、競合の発生元の確認を実行できます。ただし、パターンに基づいて生成されたURLは、アセットが次回保存されたときに自動的に再生成されます。

29.3.2 バニティURL競合の解決

同じパスを持つバニティURLは(WebCenter Sites全体でも) 1つしか存在できないので、バニティURLは一意です。たとえば、2つのサイトがあり、各サイトにルール・パターン/Page/${name}が存在し、両方でページに同じ名前(たとえば"Home")を使用している場合、競合が発生します。

どちらのページであっても、先に保存したページは正常に保存されてバニティURLが作成されますが、後から保存したページはバニティURLの作成に失敗します。

1. この場合、システム・ツールを使用してバニティURLの作成を阻害する原因を特定し、必要に応じて既存のURLを削除して、新しいURLを作成できるようにする必要がある可能性があります。

2. この問題は、WebRootが特定のサイトに固有であることを保証することによって抑止できます。

29.4 リライタ・フィルタによるバニティURLの解決

バニティURLを解決する方法は2つあります。1つは、Webサーバーを使用してURLをリライトする方法です。もう1つは、開発時によく見られる、Webサーバーが存在しない場合のために設計された方法で、フィルタを使用します。

WebCenter Sitesにはデフォルトで、サンプル・サイト専用のURLリライタ・フィルタが用意されています。このリライタ・フィルタは、任意のサイトでWebRootと組み合せて使用するように構成できます。このフィルタは、(先頭からの文字列一致に基づいて)フィルタを通過するすべてのコールをインターセプトし、バニティURLフィルタとしてWebCenter Sitesに渡します。

簡単に言えば、Webサーバー上にリライト・ルールが存在しなくてもバニティURLが動作するようにできます。このフィルタを使用する場合の主要な制限は、正しいURLがバニティURLとして処理されるように、コンテキスト・ルートと一意の接頭辞を持つ必要があるということです。

注意:

"FSII"と"Avi"は、サンプル・サイトがインストールされる際に、web.xmlでURLリライト・フィルタ用に事前構成されるパラメータです。

リライタ・フィルタを有効にするには::

1. 次のコードを、web.xmlの一番最後に記述されている</filter>の後にコピーします。次に、Aviを一意の文字列(たとえばサイト名)で置き換えて、WebCenter Sitesを再起動します。

注意:

param-valueにカンマ区切りリストを指定することで、複数のSitePrefixを追加できます。各SitePrefixについて、手順2に示すように、接頭辞に一致するWebCenter Sitesの内部にWebRootが作成されていることを確認します。

<filter>
<filter-name>URLRewriteFilter</filter-name>
<filter-class>COM.FutureTense.Servlet.URLRewriteFilter</filter-class>
<init-param>
<param-name>SitePrefix</param-name>
<param-value>Avi</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>URLRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

2. 接頭辞に一致するWebCenter Sitesの内部にWebRootを作成します。たとえば、"Avi"を使用する場合、/<contextroot>/Aviで始まるWebRootを作成する必要があります。相対WebRootを使用する場合、これは必須です。絶対WebRootを使用する場合は、ホスト名とポートも指定する必要があります。保存する前に、このWebRootが定義されているサイトを選択する必要があります。

3. 保存した後、新しいWebRootを使用するURLを1つ作成します。

4. 作成したバニティURLがブラウザで機能することを確認します。

例:

相対WebRootが/Avi、パスが/Running/Homeである場合、フィルタによって次のようなURLが生成されます。

http://<Sites Host>:<Sites Port>/<Context Root>/Avi/Running/Home

フィルタを使用するので、フィルタとWebRootの両方で接頭辞(具体的に言うと、この例ではAvi)を使用する必要があります。

注意:

バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があります。そのような場合、既存のパラメータが既存のURLに連結されます。たとえば、time=trueを渡す場合、サイトに送信される前述のURLは、次のようになります。

http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true

29.5 モバイル・サイトのバニティURLの使用

多くの場合、モバイル固有のサイトを使用するユーザーは、モバイル・ユーザー専用のURLを使用することを望みます。短いURLがモバイル・ユーザーに利点をもたらすだけでなく、通常は固有のドメインとURLが存在するためです。Webサイトのモバイル・ページ用に固有のドメインとURLを設定するには、次のアイテムを実行します。

1. モバイル・ドメイン名用のWebRootを設定する必要があります。WebRootのルートURLには、モバイル・ドメイン名を使用する必要があります。

2. モバイル・デバイス・グループ用のバニティURLを作成する際、正しいホスト名を選択します。これにより、モバイル・ドメイン名用のリンクが正しく生成されることが保証されます。

3. WebサーバーのURLのリライトなど、他のすべての手順は、WebRootの使用、バニティURLの生成およびシステム・ツールによるバニティURLの使用に示す手順と同じです。

29.6 WebサーバーによるバニティURLの処理

URLのリライトにWebサーバーを使用することで、フィルタと同じ方法でバニティURLにアクセスでき、URLリライトに伴うすべての制御と機能を利用できます。

Webサーバーを使用する場合、リライトされるバニティURLはすべて、WebCenter Sitesに送信される前に2つに分割する必要があります。1つはWebRoot、もう1つはパスです。たとえば、URL http://www.example.com/Running/Homeに対しては、WebRoot http://www.example.comと、/Running/Homeを生成するパターンを使用します。このURLをWebサーバーから渡すには、URLをWebRootとパスに分ける必要があります。そうすると、これらはWebCenter Sitesの特別なフィルタへの問合せパラメータとして別々に渡されます。リライトされたURLを処理するために使用されるバニティURLフィルタは、「サイト」と呼ばれ、<content root>/Sitesでアクセスされます。

URLの2つの部分は分割されて、それぞれlookuphostとlookuppageに格納されます。lookuphostはWebRootを参照します(絶対WebRootの場合はフル・サーバー名、ポートおよび接頭辞、相対WebRootの場合は接頭辞のみ)。lookuppageは接頭辞の後のパスの残りの部分を参照します。例に示したURLを使用する場合、WebCenter Sitesに渡すURLは、次のようにリライトされている必要があります。

http://<Sites Host>:<Sites Port>/<contextpath/Sites?lookuppage=/Running/Home
&lookuphost=http://www.example.com

注意:

バニティURLは、問合せパラメータをサポートします。必要なパラメータがバニティURLから削除されていても、場合によってはURLの一部として追加データを渡す必要があります。そのような場合、既存のパラメータが既存のURLに連結されます。たとえば、time=trueを渡す場合、サイトに送信される前述のURLは、次のようになります。

http://<Sites Host>:<Sites Port>/<Context root>/Avi/Running/Home?time=true

29.7 mod_rewriteによるバニティURLの処理

Webサーバーとサイトの組合せはすべて一意なので、次の内容は、mod_rewrite (OHS、ApacheおよびIBM HTTPサーバーでURLのリライトに使用される)の使用方法のガイドラインおよび例として参照する必要があります。ほとんどのシステムでは、示されているルールを正しく動作させるために変更が必要です。

mod_rewriteを使用する方法は2つあります。WebCenter SitesフィルタのURLを直接変換するために使用することも、URLリライタ・フィルタとともに使用して、同じアクションをはるかに単純なmod_rewriteルールで実行することもできます。どちらの方法についても例を示します。どちらが適切かを決定するには、WebCenter SitesフィルタがバニティURLを分割する追加手順(ならびにコスト)が、リライト・ルール簡略化に見合うかどうかを判断します。

次以降の手順は、手動でコンパイルされたApache 2.4.xに基づいています。オペレーティング・システム付属のバージョンを使用する場合、mod_rewriteを有効にして構成するために必要な変更は異なる可能性がありますが、ルールと概念は同じです。

この項の内容は次のとおりです。

- mod_rewriteの設定

- mod_rewriteによる変換について

- mod_rewriteによるWebCenter Sitesフィルタの使用

- mod_rewriteによるリライタ・フィルタの使用

- mod_rewriteによる静的コンテンツの使用

29.7.1 mod_rewriteの設定

mod_rewriteを設定するには:

1. httpd.confを編集し、次の行を非コメント化することによってmod_rewriteを有効にします。

LoadModule rewrite_module modules/mod_rewrite.so

2. httpd.confに次の行を追加して、リライト・エンジンを有効にします。

RewriteEngine On

3. デバッグ用に、mod_rewriteのロギングのみ有効にします(これは非常にコストの高い操作なので、デバッグ時のみ使用してください)。

LogLevel alert rewrite:trace6

4. httpd.confへの変更を保存します。これで、mod_rewriteが有効になります(ルールはなし)。Webサーバーの起動を確認します。

注意:

はるかに簡単な構造とテストが可能なWebページがあります。mod_rewriteルールを最初に作成しておく場合、これらのサイトの1つを使用することをお薦めします。

29.7.1.1 用意されている例の設定

mod_rewriteルールの例をいくつか示すために、まず環境の概要を定義します。次に示すのは、このガイドで使用しているバニティURLに基づくサンプルです。開始するには、同じエレメントを、環境にあわせて値を変更して使用してください。

ユーザーが使用することになるバニティURL:

- 本番:

http://www.example.com/Page/Surfing
http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
http://www.example.com/Home
http://www.example.com/Home?time=true

- 開発:

http://dev.example.com:8080/Running/Home

WebCenter Sitesの一般情報:

- 本番コンテキスト・ルート: /cs

- 本番リライト・フィルタ: /AVISPORTS

- 開発コンテキスト・ルート: /csdev

- 開発リライト・フィルタ: /Avi

各サーバーに定義されているWebRoot:

- 本番 - 絶対: http://www.example.com

- 開発 - 相対: /Avi

URL構造:

- 本番: http://www.example.com/Page/Surfing

- WebRoot: http://www.example.com

- パス: /Page/Surfing

- 本番: http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars

- WebRoot: http://www.example.com

- パス: /Article/Baker_Likely_to_Stay_With_Stars

- 本番: http://www.example.com/Home

- WebRoot: http://www.example.com

- パス: /Home

- 本番: http://www.example.com/Home?time=true

- WebRoot: http://www.example.com

- パス: /Home

- 問合せパラメータ: time=true

- 開発: http://dev.example.com:8080/Running/Home

- WebRoot: /Avi

- パス: /Running/Home

フィルタは2つあります。1つはWebCenter SitesバニティURLフィルタ、もう1つはWebCenter Sitesリライト・フィルタです。リライト・フィルタを使用する場合、データはリライト・フィルタからバニティURLフィルタに透過的に渡されます。

WebCenter SitesバニティURLフィルタを使用する場合、URLは次のようになります。

- 本番:

- http://www.example.com/Page/Surfing

lookuphost=http://www.example.com &lookuppage=/Page/Surfing

- http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars

lookuphost=http://www.example.com &lookuppage=/Article/Baker_Likely_to_Stay_With_Stars

- http://www.example.com/Home

lookuphost=http://www.example.com &lookuppage=/Home

- http://www.example.com/Home?time=true

lookuphost=http://www.example.com &lookuppage=/Home&time=true

- 開発:

- http://dev.example.com:8080/Running/Home

lookuphost=/cs/Avi&lookuppage=/Running/Home

WebCenter Sitesリライタ・フィルタを使用する場合、URLは次のようになります。

- 本番:

- http://www.example.com/Page/Surfing

/cs/AVISPORTS/Page/Surfing

- http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars

/cs/AVISPORTS/Article/Baker_Likely_to_Stay_With_Stars

- http://www.example.com/Home

/cs/AVISPORTS/Home

- http://www.example.com/Home?time=true

/cs/AVISPORTS/Home?time=true

- 開発:

- http://dev.example.com:8080/Running/Home

/csdev/Avi/Running/Home

29.7.2 mod_rewriteによる変換について

いくつかのURLを選択して、コンポーネント部分に分割したら、mod_rewriteを使用してこれらのURLを変換する必要があります。mod_rewriteのルールは、2つの部分から構成されます: 1つ目は、Webサーバーに提供されるURLに適合する正規表現、2つ目は、渡されたときの表示内容です。前半部分が一致しない場合、URLは次のリライト・ルールに渡されます。定義されているどのルールも一致しない場合、URLは変更されないままで渡されます。したがって、複数のルールが存在する場合、その順序が重要になります。

注意:

1. mod_rewrite は、あらかじめ有効にしておくオプション・コンポーネントです。mod_rewriteルールを作成しても、mod_rewriteコンポーネントを実際に有効にしていない場合、ルールはスキップされます。エラーは発生せず、何もリライトされません。そのため、開発中はデバッグをアクティブにしてerror.logを監視し、mod_rewriteに関する詳細を取得することをお薦めします。

ここで説明する内容は、mod_rewriteの機能のほんの一部にすぎません。大部分のサイトでは、通常はもっと複雑なルールが必要になります。詳細は、ベンダーのドキュメントを参照してください。

この例では、次に示す、本番用の最初のURLを使用します。

http://www.example.com/Page/Surfing

これに次のルールを作成します。

RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1 [L]

このルールには、次に示す4つのコンポーネント部分があります。

- RewriteRule — 後に続くエントリがmod_rewriteルールであることを示す文。)

- ^(.*)$ — 正規表現。次のように分割されます。

- ^ — 行インジケータの開始

- (.*) — 全テキスト一致選択インジケータ。カッコ内に記述すると、選択されたテキストが変数に保存されます。

- $ — 行インジケータの終了

したがって、この式は、文字列の開始と終了の間にあるすべてのテキストを変数に保存することを示します。

- /<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1 — バニティURLのWebCenter Sitesコンテキスト・ルート、フィルタおよびパス。次のように分解されます

- /<context>/Sites — Sitesコンテキスト・ルート(cs)およびバニティURLフィルタ(Sites)

- ? — この後に続くパラメータが問合せパラメータであることを示す

- lookuphost=http://www.example.com

- lookuphost — バニティURLフィルタにWebRootの名前を提供

- http://www.example.com — 本番サーバーのWebRoot (絶対WebRoot)

- lookuppage=$1

- lookuppage — バニティURLのパス部分(この場合は/Page/Surfing)

- $1 — 入力URLから抽出した1番目のテキストを示す置換変数。この場合は(.*)と一致した/Page/Surfing

- [L] — mod_rewriteにルールの終了を通知します。すべてのmod_rewriteルールは、最後にこれを記述する必要があります。

29.7.3 mod_rewriteによるWebCenter Sitesフィルタの使用

次のルールは/Page/Surfingだけでなく、送信された他のすべてのページも処理して、ホストの後から行の終了までのすべてを抽出します。

RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com& lookuppage=$1 [L]

したがって、次ではこのルールで処理されます。

http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars
および

http://www.example.com/Home

しかし、次のURLは、ホストとパス以外に、問合せパラメータが渡されているため、このルールで処理されません。

http://www.example.com/Home?time=true

問合せパラメータを処理するには、次のようにします。

1. mod_rewrite組込み変数"%{QUERY_STRING}"を使用して、/<context>/Sites? lookuphost=http://www.example.com& lookuppage=$1ルールを更新します。

更新後:

/<context>/Sites? lookuphost=http://www.example.com& lookuppage=$1&%{QUERY_STRING}

問合せパラメータを渡さないURLの場合、%{QUERY_STRING}は空になります。したがって、前述の3つのURLに加えて、次のURLも処理できます。

2. 今度は次の開発URLについて考えます。

http://dev.example.com:8080/Running/Home

これを、次のようにしてバニティURLフィルタに渡す必要があります。:

lookuphost=/<context>/Avi&/<context>/Sites?lookuppage=/Running/Home

mod_rewriteは、デフォルトではホストとポートを処理しないので(この情報を含む専用パラメータが存在します)、リライト・ルールは次のルールによく似たものになります。

RewriteRule ^(.*)$ /<context>/Sites?lookuppage=$1&lookuphost=/<context>/Avi [L]

この場合、開発では相対WebRootを利用するので、名前を調整する必要があります。URLの残りの部分は変更されないため同じルールが適用されます。

29.7.4 mod_rewriteによるリライタ・フィルタの使用

リライト・フィルタを使用する場合、バニティURLフィルタの場合のようにURLを分割する必要はありません。かわりに、Sitesコンテキスト・ルートおよびリライタ・フィルタ接頭辞がURLに追加されます(これはバニティURLの導入前のWebCenter Sitesを使用する場合とよく似ています。したがって、既存のルールは、バニティURLをサポートするように簡単に変更できます)。

次の例では、URLとしてhttp://www.example.com/Page/Surfingを使用しており、これは/<context>/AVISPORTS/Page/Surfingになります。

1. 前述のURLを処理するために、次のmod_rewriteルールを新しく作成します。

RewriteRule ^(.*)$ /<context>/AVISPORTS$1 [L]

このルールは、単純に渡されたものを受け取り、その先頭に/<context>/AVISPORTSを追加します。

同じルールで次も処理できます。

http://www.example.com/Article/Baker_Likely_to_Stay_With_Stars およびhttp://www.example.com/Home

2. http://www.example.com/Home?time=trueを処理するために、ルールに%{QUERY_STRING}パラメータを追加するため、次のようになります。

RewriteRule ^(.*)$ /<context>/AVISPORTS$1?%{QUERY_STRING}  [L]
http://www.example.com/Home?time=true

29.7.5 mod_rewriteによる静的コンテンツの使用

mod_rewriteとバニティURLを使用する場合の問題の1つが、既存のCSSと静的イメージのアクセスです。通常、これらはアプリケーション・サーバー上またはWebサーバー上にある、サイトと同じ名前のディレクトリに格納されます。多くの場合、リライト・ルールによって、それらにアクセスできなくなります。

1. 次の例を使用し、CSSファイルは、AVISPORTS_STATICという名前のディレクトリに格納されているものとします。

http://www.example.com/Page/Surfing

2. これを処理するために、2つ目のmod_rewriteルールを作成します。このルールを前述のルールの前に置くことによって、このディレクトリへのコールがリライトされないことを保証します。

これは、次のように記述できます。

RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /<context>/<site-prefix>/$1 [L,PT].

これらの2つのルールを使用して、1つ目のルールですべての静的ページとCSSがバニティURLに変換されないことを保証し、2つ目のルール(mod_rewriteによる変換についてで構築)で残りのURLをバニティURLフィルタに送信します。

RewriteRule ^.*/AVISPORTS_STATIC/(.*)$ /<context>/<site-prefix>/$1 [L,PT]
RewriteRule ^(.*)$ /<context>/Sites?lookuphost=http://www.example.com&lookuppage=$1&%[QUERY STRING} [L]

30 Lucene検索エンジンの構成

この章では、WebCenter Sitesと統合されるLuceneサードパーティ検索エンジンを設定および保守する方法について説明します。Luceneは、Oracle WebCenter Sites: Contributorインタフェースの検索機能を動作させ、パブリック・サイト検索APIでWebサイト上の検索機能をサポートできるようにします。

この章の内容は次のとおりです。

- WebCenter Sitesの検索機能の概要

- 検索索引の設定

- Lucene検索エンジンの無効化

- 検索索引の維持

- 検索索引の問合せコードの記述

30.1 WebCenter Sitesの検索機能の概要

WebCenter Sitesをインストールすると、WebCenter Sitesデータベースの検索機能とLuceneが使用可能になります。LuceneエンジンはWebCenter Sitesのインストール時に設定され、コンテンツ・コントリビュータ、Webサイト訪問者およびサードパーティのアプリケーションがアセットを検索できます。

この章には、Lucene検索エンジンの使用方法、追加のアセットを検索可能にする方法、検索エンジンを一時停止または無効にする方法に関する情報が含まれています。

この項の内容は次のとおりです。

- 検索のための索引付け機能

- WebCenter Sitesの検索機能の使用

30.1.1 検索のための索引付け機能

「コントリビュータ」検索は、WebCenter Sitesデータベースではなく、Lucene検索索引に対して実行されます。検索索引は索引付けと呼ばれる自動プロセスによって作成され、検索時にアセット・データを収集して、すぐに取得できる書式で格納します。

検索結果は、検索の実行時に索引内で使用可能なデータのみに基づいて返されます。索引内に含まれるアセットが多くなるほど、構築と検索にかかる時間が長くなります。

索引付けするアセットのタイプは、検索の構成フォームで選択します。選択したアセットが索引付けされ、検索できるようになります。索引付けから除外したアセット・タイプは、索引付けされず、検索できません。

索引が構築されると、Lucene検索エンジンが30秒ごとに、索引付けに選択されたアセット・タイプに対する変更をチェックします。変更(新しい検索アイテムの作成、既存のエントリの編集、エントリの削除など)が行われた場合、Luceneによって索引が更新されます。デフォルトで、索引データは<cs_shared_dir>/luceneディレクトリ(<cs_shared_dir>はWebCenter Sites共有ファイル・システム・ディレクトリ)に格納されます。

30.1.2 WebCenter Sitesの検索機能の使用

WebCenter Sitesには、グローバル検索、アセット・タイプ検索、さらに最も詳細な検索機能である「アセット・タイプ索引の属性の構成」といった検索機能があります。この検索オプションは、索引付け対応のアセット・タイプの検索可能な属性を指定できることから、アセット・タイプ索引オプションのサブセットになります。

システム上のすべての検索を有効にすることができます。検索は、索引付けされたユーザー定義の属性の格納方法によって区別されます。

グローバル検索では、システム定義の属性を個別に索引付けし、ユーザーが固有の属性によって検索できるようにします。アセットのユーザー定義の属性値は、1つの表のセルにまとめて格納されます。属性名は省略されます。グローバル検索を構成すると、ユーザーはアセット・タイプごとにすべてのユーザー定義の属性を検索するように制限されることになります。

たとえば、記事のアセットがあるとします。Jane Doeという文字列で検索できるかもしれませんが、固有のユーザー定義の属性1つだけに検索を絞ることはできません。すべてのユーザー定義の属性データは1つのセルにまとめて格納されており、そのセルでは属性同士は区別されないからです。

アセット・タイプ検索は、各属性値を属性名ごとに独自の個別セルで索引付けします。アセット・タイプ検索は、パブリック・サイト検索APIで使用され、Webサイト上の検索機能を有効にします。パブリック・サイトの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

アセット・タイプ検索では、グローバル検索にはない固有性のレベルで検索結果を得ることができるのです。アセット・タイプ検索は、グローバル検索よりも短時間で検索結果を戻すことができます。アセット・タイプ検索では、関連する属性のみに検索を限定することで、不必要な索引データで検索を実行する必要がなくなります。

アセット・タイプ検索の属性の構成を使用すると、アセット・タイプ検索によって有効になっているアセット・タイプに対して指定した属性のみに、検索を制限することができます。

図30-1と表30-1には、Luceneベースの各検索の相違点と、それらの粒度のレベルが示されています。各表は、同じ記事タイプのアセットの索引を表していますが、それぞれの検索機能のタイプが異なっています。これらすべての表では、システム定義の属性データのみが同じ方法で格納されています。

注意:

次の表は、グローバル検索、アセット・タイプ検索、属性固有の検索の粒度を示すものです。索引付けされたデータが検索エンジンによって格納される方法を示すものではありません。

図30-1 各検索機能を示す表と相違点

検索では、データの索引付け方法以外に、表30-1にまとめたような様々な機能が有効になります。

表30-1 検索機能

グローバル索引

アセット・タイプ索引

選択されているすべてのアセット・タイプを通じて検索できます。

アセット・タイプごとに検索できます(複数のアセット・タイプを有効にできます)。

選択されているすべてのアセット・タイプに対して1つの索引を作成します。

アセット・タイプごとに1つの索引を作成します。

システム定義属性による検索をサポートします。

システム定義属性とカスタム属性による検索をサポートします。

(アセット・タイプ索引の属性の構成を使用して)システム定義属性をフィルタできます。

(アセット・タイプ索引の属性の構成を使用して)システム定義属性とカスタム定義属性をフィルタできます。

ライブ・サイト上のパブリック検索をサポートします。

ライブ・サイト上のパブリック検索をサポートします。

パブリック・サイト検索APIの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

30.2 検索索引の設定

Luceneを設定する主な手順は、次のとおりです。

1. Lucene検索エンジンの有効化。Luceneを構成するには、その前に、システム上でそれを有効化する必要があります。

2. 検索索引へのアセット・タイプの追加。それによりLuceneは、どのアセットに索引付けするべきかを認識します。グローバル索引とアセット・タイプ索引にアセットを追加できます。

索引付けするアセットを選択し、バイナリ・ファイルの索引付けを有効にすると、索引付けプロセスを開始できます。

Luceneは索引付け中に、選択されたアセット・タイプのアセットのコンテンツと、アセットが参照するバイナリ・ファイルのコンテンツ(該当する場合)を調べ、これらのアセットのエントリを索引内に作成します。グローバル索引では選択されているすべてのアセット・タイプに対して1つの索引が作成され、アセット・タイプ索引ではアセット・タイプごとに1つの索引が作成されます。

グローバル索引を作成してから、ユーザーが検索を実行すると、Contributorインタフェースまたはライブ・サイト上の検索機能によってアセットが返されます。アセット・タイプ索引を作成してから、ユーザーが検索を実行すると、ライブ・サイト上の検索機能によってアイテムが返されます。

3. アセット・タイプ索引に対する属性の構成索引を作成すると、検索する特定属性を選択することができます。これらの指定移入した属性の索引を作成、移入し、検索を実行すると、ライブ・サイトの検索機能によって、指定した属性が戻されます。

4. バイナリ・ファイルの索引付けの有効化。索引に追加した1つ以上のアセット・タイプでバイナリ・ファイルを参照するように設定する場合、これらのバイナリ・ファイルを参照するアセットを索引付けするときに、Luceneによってバイナリ・ファイルのコンテンツをテキストに変換するように構成できます。

この項の内容は次のとおりです。

- Lucene検索エンジンの有効化

- 検索索引へのアセット・タイプの追加

- アセット・タイプ索引に対する属性の構成

- バイナリ・ファイルの索引付け

30.2.1 Lucene検索エンジンの有効化

この項では、Luceneエンジンを有効化する方法について説明します。

Luceneエンジンを起動するには::

1. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

2. 「検索エンジンの起動」をクリックします。

Luceneで、選択したデータの索引付けを開始できるようになります。データの索引付けにかかる時間は、索引付けされるアセットの数と、使用しているシステムの速度によって異なります。

Lucene検索エンジンは、一度起動したら、無効化されるまで継続して実行されます。索引付けの実行中は、選択したアセット・タイプに対する変更が検出され、索引が更新されます。索引の実行中、アセット・タイプのステータスは「有効」と表示されます。検索機能を削除する場合は、索引付けを停止するだけでなく、索引データを削除する必要もあります。索引データの削除を参照してください。

30.2.2 検索索引へのアセット・タイプの追加

この項では、グローバル検索索引とアセット・タイプ索引にアセット・タイプを追加する方法について説明します。各初期索引が作成されると、Luceneは5秒ごとに変更を確認します。デフォルトで、索引データは<cs_shared_dir>/luceneディレクトリ(<cs_shared_dir>はWebCenter Sites共有ファイル・システム・ディレクトリ)に格納されます。データは、追加された後、索引付けが全面的に停止されるか、選択したアセット・タイプに対して一時停止されるまで、維持されます。Luceneが索引付けするまで、選択したタイプのアセットが検索機能によって戻されることはありません。

検索索引に新しいアセット・タイプを追加するには::

1. Luceneエンジンを有効化します。

a. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

b. 「検索エンジンの起動」をクリックします。

2. グローバル検索索引にアセット・タイプを追加します。

a. 「グローバル検索の構成」をダブルクリックします。

b. 「索引」リストで、「追加」を選択します。WebCenter Sitesに、現在索引付けされていないアセット・タイプのリストが表示されます。

図30-2 「グローバル検索の構成」フォーム

c. 「アセット・タイプ」のリストで、索引付けするアセット・タイプを選択します。

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

e. 確認ポップアップ・ダイアログで、「OK」をクリックします。アセット・タイプのステータスが「有効」に変わり、選択したアセット・タイプに対して索引付けが有効になります。このタイプの最初のアセットが作成されるとすぐに、そのアセット・タイプに対して索引が作成されます。

3. アセット・タイプ検索索引にアセット・タイプを追加します。

a. 「アセット・タイプ検索の構成」をダブルクリックします。

b. 「索引」リストで、「追加」を選択します。
WebCenter Sitesに、現在索引付けされていないアセット・タイプのリストが表示されます。

c. リストで、索引付けするアセット・タイプを選択します。

d. 「OK」をクリックします。
確認のポップアップ・ダイアログが開いたら、「OK」をクリックします。

アセット・タイプのステータスが「有効」に変わり、選択したアセット・タイプに対して索引付けが有効になります。このタイプの最初のアセットが作成されるとすぐに、そのアセット・タイプに対して索引が作成されます。

4. 必要に応じて、バイナリ・ファイルの索引付けを有効にします(「バイナリ索引作成の開始」をクリックします)。バイナリ・ファイルの索引付けの詳細は、バイナリ・ファイルの索引付けを参照してください。

30.2.3 アセット・タイプ索引に対する属性の構成

特定のアセット・タイプの固有の属性に対する索引付けを構成できます。選択されたアセット・タイプの固有の属性が選択できるようにするには、まずそのアセット・タイプに対して索引付けを有効にする必要があります。Luceneを有効にして、ライブ・サイト上で検索を実行したら、索引付けされた属性データが検索条件と一致したアセットが返されます。

選択されたアセット・タイプの属性を構成するには::

1. 構成するアセット・タイプがアセット・タイプ索引に追加されていない場合は、追加します。手順については、検索索引へのアセット・タイプの追加を参照してください。

2. 「管理」タブで、「検索」を開き、「アセット・タイプ索引の属性の構成」をダブルクリックします。

3. 「アセット・タイプ」のリストで、構成するアセット・タイプを選択します。WebCenter Sitesに、選択したアセット・タイプの属性のリストが表示されます。

図30-3 「アセット・タイプ索引のアセットの構成」フォーム

4. 次の情報も開きます。

- 有効: 指定した属性が、その特定のアセット・タイプの索引付けに対して有効化されているかどうかを示します。属性を無効化するには、その属性のチェック・ボックスを選択解除します。

- タイプ: 属性に格納されるデータのタイプを示します。たとえば、NUMERICの場合は価格情報が格納されていることを示している可能性があります。TEXTやDATETIMEのデータを持つこともできます。

- トークン化済: このデータをテキストに変換してから索引付けする場合は、「True」を選択します。トークン化されていないデータは1語として索引付けされ、読み手に解釈してもらえない可能性があります。

- 格納済: 指定した属性の元のテキスト全体が索引に追加されているかどうかを示します。索引にテキスト全体を格納する場合は、「True」を選択します。

注意:

リストされている各アセット・タイプに対して、少なくとも1つの属性を有効にする必要があります。

5. 選択されているアセット・タイプに対する変更が完了したら、「保存」をクリックします。

30.2.4 バイナリ・ファイルの索引付け

バイナリ・ファイルとは、WordやPDFドキュメントなど、テキスト以外のタイプのファイルのことです。アセットがバイナリ・ファイルを参照しない場合や、参照先のファイルに索引付けのできないコンテンツ(画像やビデオ)が含まれている場合は、このオプションを無効のままにしておくことができます。

この項の内容は次のとおりです。

- バイナリ・ファイルの索引付けの有効化

- バイナリ・ファイルの索引付けの無効化

30.2.4.1 バイナリ・ファイルの索引付けの有効化

索引付けのキューに追加した1つ以上のアセット・タイプで、WebCenter Sitesファイル・システム内に格納されたバイナリ・ファイルを参照するように設定する場合、これらのバイナリ・ファイルを参照するアセットを索引付けするときに、Luceneによってバイナリ・ファイルのコンテンツをテキストに変換するように構成できます。デフォルトでは、Luceneは、索引付けされたアセットが参照するすべてのバイナリ・ファイルを無視するように設定されています。

バイナリ・ファイルの索引付けを有効化するには::

1. Luceneエンジンが有効でない場合は、これを有効にします。

a. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

b. 「検索エンジンの起動」をクリックします。
ボタン名が「検索エンジンの停止」に変わります。

2. 「管理」タブで、「検索」を開きます。

3. 次のいずれかを実行します。

- グローバル検索に対してバイナリ・ファイルの索引付けを有効化するには、「グローバル検索の構成」をダブルクリックします。

- アセット・タイプ検索に対してバイナリ・ファイルの索引付けを有効化するには、「アセット・タイプ検索の構成」をダブルクリックします。

4. 「バイナリ索引作成の開始」をクリックします。
索引付けされたアセットが参照するすべてのバイナリ・ファイルが、Luceneによってテキストに変換されます。

30.2.4.2 バイナリ・ファイルの索引付けの無効化

索引付けされたアセットが参照するバイナリ・ファイルのコンテンツを、Luceneによって変換する必要がなくなったと判断したら、この機能を無効化してパフォーマンスを向上させることができます。

バイナリ・ファイルの索引付けを無効化するには::

1. Luceneエンジンが有効でない場合は、これを有効にします。

a. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

b. 「検索エンジンの起動」をクリックします。
ボタン名が「検索エンジンの停止」に変わります。

2. 「管理」タブで、「検索」を開きます。

3. 次のいずれかを実行します。

- グローバル検索に対してバイナリ・ファイルの索引付けを無効化するには、「グローバル検索の構成」をダブルクリックします。

- アセット・タイプ検索に対してバイナリ・ファイルの索引付けを無効化するには、「アセット・タイプ検索の構成」をダブルクリックします。

4. 「バイナリ索引作成の終了」をクリックします。
Luceneは、索引付けされたアセットが参照するすべてのバイナリ・ファイルを無視するようになります。

30.3 Lucene検索エンジンの無効化

パフォーマンスを向上させる場合は、Luceneエンジンを停止することができます。このエンジンを停止すると、アセットを追加または削除したり、索引付けを一時停止することができません。アセットの索引を再作成することもできません。

索引付けを停止する手順:

1. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

2. 「検索エンジンの停止」をクリックします。

ボタン名が「検索エンジンの起動」に変わります。

これでLuceneエンジンによる索引付けが無効になります。ただし索引データは保持されるので、Contributorインタフェースやパブリック・サイトでの検索では、前回索引を構築したときに含まれていたアセットが返されます。索引データを削除する(つまり検索機能を削除する)場合は、索引データの削除を参照してください。

注意:

グローバル検索の索引付けを停止すると、Contributorインタフェースの検索機能やパブリック・サイトで使用される検索索引が更新されません。このため、検索結果が不正確になります。

- Contributorから検索機能を削除するには、グローバル索引からすべてのアセットを削除することも必要です。手順は、索引データの削除を参照してください。

- 索引付けの停止中にアセットを追加または削除した場合は、索引付けを再起動するときに索引を再構築することで、正確な検索索引を作成する必要があります。詳細は、索引の再作成を参照してください。

30.4 検索索引の維持

Luceneの設定後は、アセットに対する一括操作、索引の再作成、索引データの削除、または検索エンジンの固有の問合せのためのコード記述を行うために、索引付けの一時停止などのタスクを実行する必要が生じる場合があります。

この項の内容は次のとおりです。

- 索引付けの一時停止と再開

- 索引の再作成

- 索引データの削除

30.4.1 索引付けの一時停止と再開

索引付けの一時停止と停止は、類似した機能です。索引付けを一時停止する場合、選択したアセット・タイプの索引付けを一時停止できます。検索索引を停止すると、すべてのアセットの索引付けが停止されます。

多数のアセットを追加および削除する場合は、追加または削除するアセット・タイプの索引付けを一時停止することで、プロセスの速度を上げることができます。これらの変更内容を検索索引に反映させるには、索引の再作成機能を使用して、追加または削除したすべてのアセット・タイプの索引付けを行う必要があります。

- グローバルおよびアセット・タイプの索引付けの一時停止

- グローバルおよびアセット・タイプの索引付けの再開

30.4.1.1 グローバルおよびアセット・タイプの索引付けの一時停止

索引付けが有効になっている場合、WebCenter Sitesデータベースに追加または更新されたすべてのアセットは、保存後に索引付けされます。多数のアセットを保存する場合、そのアセット・タイプの索引付けを一時停止すると、処理速度が上がります。アセットがデータベースに追加されたら、索引付けを再開し、すべてのアセット・タイプの索引を再作成して、すべての新しい(および既存の)アセットの索引付けを一度に行います。

一時停止しても、検索では既存の索引に対する結果が引き続き返されます。ただし、索引付けの一時停止後に行われたデータベースへの変更は索引付けされません。このため、索引付けの一時停止後のデータベースへの変更は、検索結果に反映されなくなります。

索引付けを一時停止する手順:

1. Luceneエンジンが有効でない場合は、これを有効にします。

a. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

b. 「検索エンジンの起動」をクリックします。
ボタン名が「検索エンジンの停止」に変わります。

2. 「管理」タブで、「検索」を開きます。

3. 次のいずれかを実行します。

- グローバル検索に対して索引付けを一時停止するには、「グローバル検索の構成」をダブルクリックします。

- アセット・タイプ検索に対して索引付けを一時停止するには、「アセット・タイプ検索の構成」をダブルクリックします。

4. 「索引」リストで、「一時停止」を選択します。
WebCenter Sitesに、索引付けを一時停止できるアセット・タイプのリストが表示されます。

5. 「アセット・タイプ」のリストで、索引付けを一時停止するアセット・タイプを選択します。

注意:

リストで「一時停止」を選択したときにアセット・タイプが表示されない場合は、そこで処理を中止します。すべてのアセット・タイプに対して索引付けが一時停止されているか、索引付けのためのアセット・タイプが選択されていないからです。

6. 操作の選択肢が表示されるリストの横にある「OK」ボタンをクリックします。

7. 確認のポップアップ・ダイアログが開いたら、「OK」をクリックします。
Lucene検索エンジンによって、選択されたタイプのアセットに対する索引付けが一時停止され、索引データが保存されます。アセット・タイプのステータスが「一時停止」に変わります。

30.4.1.2 グローバルおよびアセット・タイプの索引付けの再開

索引付けを一時停止または無効化した後は、索引の再作成を行って、すべてのアセット・データが索引に含まれている状態にする必要があります。

索引付けを再開する手順:

1. 一時停止されたアセット・タイプに対して索引付けを再起動します。手順については、検索索引へのアセット・タイプの追加を参照してください。

2. 索引付けの一時停止中にデータベースにアセットを追加した場合、索引を再作成して、新しいデータが索引に含まれるようにする必要があります。索引の再作成に進みます。

3. 索引付けの一時停止中にアセットを削除した場合は、通常の索引付けプロセスによって削除されたアセットが検出され、索引からそのデータが削除されます。ただし、多数のアセットを削除した場合は、削除したアセット・タイプの索引全体を削除して、索引を再作成した方が速い場合もあります。

- 索引データの削除の詳細は、索引データの削除を参照してください。

- 索引の再作成の詳細は、索引の再作成を参照してください。

30.4.2 索引の再作成

アセットの索引の再作成にかかる時間は、索引付けされるアセットの数と使用しているシステム構成によって異なります。選択したタイプのアセットに対して更新された検索結果が返されるのは、Lucene検索エンジンがこれらを索引付けしてからです。

索引を再作成する手順:

1. Luceneエンジンが有効でない場合は、これを有効にします。

a. 「管理」タブで、「検索」を開き、「検索エンジン索引の開始/停止」をダブルクリックします。

b. 「検索エンジンの起動」をクリックします。

2. 「管理」タブで、「検索」を開きます。

3. 次のいずれかを実行します。

- グローバル検索に対して索引を再作成するには、「グローバル検索の構成」をダブルクリックします。

- アセット・タイプ検索に対して索引を再作成するには、「アセット・タイプ検索の構成」をダブルクリックします。

4. 「索引」リストで、「索引の再作成」を選択します。
WebCenter Sitesには、現在、索引用に選択されているアセット・タイプが表示されます。

注意:

リストで「索引の再作成」を選択したときにアセット・タイプが表示されない場合は、そこで処理を中止します。索引付けのキューにアセット・タイプが存在しないか、キューの中のすべてのアセット・タイプに対する索引付けが一時停止になっているからです。

5. リストから、索引データを構築(または再構築)するアセット・タイプを選択します。

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

7. 確認のポップアップ・ダイアログが開いたら、「OK」をクリックします。
索引付けが開始されます。

選択されたアセット・タイプのステータスが「有効」に変わります。

選択したタイプのアセットに対して更新された検索結果が返されるのは、Lucene検索エンジンがこれらを索引付けしてからです。

30.4.3 索引データの削除

特定のタイプのアセットに対して検索を実行する必要がなくなった場合、不要なデータを索引から削除すれば、検索結果がさらにすばやく返ってくるようになります。

また、索引付けを停止した後に多数のアセットを削除した場合も、索引を削除する必要が生じることがあります。このような場合、該当する索引データを削除してから残りのアセットの索引を再作成した方が、通常の索引付けプロセスよりも速いことがあります。詳細は、索引付けの一時停止と再開を参照してください。

索引データを削除する場合、WebCenter Sitesはまず選択したアセット・タイプのアセットの索引付けを一時停止し、続いてそれらのアセットの索引データを削除します。索引からデータを削除すると、選択したタイプのアセットの索引データが使用できなくなります。検索結果では、選択されたタイプのアセットによるデータが返されなくなります。

索引からデータを削除するには::

1. 「一般的な管理」ツリーで、「管理」を開き、続いて「検索」を開きます。

2. 次のいずれかを実行します。

- グローバル検索からアセットを削除するには、「グローバル検索の構成」をダブルクリックします。

- アセット・タイプ検索からアセットを削除するには、「アセット・タイプ検索の構成」をダブルクリックします。

3. 「索引」:リストで、「削除」を選択します。

現在索引付けされているアセット・タイプが表示されます。

4. リストから、索引データを削除するアセット・タイプを選択します。

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

6. 開かれる確認ダイアログ・ボックスで、「OK」をクリックします。

WebCenter Sitesによって、選択されたタイプのアセットに対する索引付けが一時停止され、索引データが削除されます。

「グローバル検索の構成」では、アセット・タイプのステータスが「一時停止」に変わります。このステータスは、既存の索引には新しいアセットが追加されないことを示しています。

「アセット・タイプ検索の構成」では、アセット・タイプのステータスが「無効」に変わります。このステータスは、このアセットが索引付けできない状態になったことを示しています。

Contributorインタフェースやパブリック・サイトの検索機能では、アセットが返されなくなります。

アセットを再び検索可能にするには、アセット・タイプを索引付けにもう一度追加する必要があります。手順については、検索索引へのアセット・タイプの追加を参照してください。

30.5 検索索引の問合せコードの記述

次のコードは、Lucene検索エンジンの索引を問い合せる方法を示すサンプル・コードです。このコードは、ユーザーが特定のサイトと特定のアセット・タイプに対する検索を実行する必要があり、サイトはcurrentSite、タイプはassetTypeという変数で渡されるという前提に基づいています。グローバル索引に対する問合せを記述するにはコードを使用します。Lucene検索エンジンからは、すべてのアセットか、指定したサイトに属するタイプについて指定されたmaxResults (合計がmaxResultsよりも大きい場合)が返されます。

import COM.FutureTense.CS.Factory;
import COM.FutureTense.Interfaces.ICS;
import com.fatwire.cs.core.search.data.ResultRow;
import com.fatwire.cs.core.search.engine.*;
import com.fatwire.cs.core.search.query.Operation;
import com.fatwire.cs.core.search.query.QueryExpression;
import com.fatwire.cs.core.search.source.IndexSourceConfig;
import com.fatwire.cs.core.search.source.IndexSourceMetadata;
import com.fatwire.search.engine.SearchEngineConfigImpl;
import com.fatwire.search.query.QueryExpressionImpl;
import com.fatwire.search.source.IndexSourceConfigImpl;
import com.fatwire.search.source.SearchIndexFields;

import java.util.Collections;

public class SearchTest
{
public static void main(String[] args )
{
SearchTest searchTest = new SearchTest();
String assetType = "Content_C";
int maxResults = 100;
try
{
searchTest.testSelect( assetType, maxResults );
}
catch (Exception e)
{
//
}
}
public void testSelect(String assetType, int maxResults) throws Exception
{
ICS ics = Factory.newCS();
IndexSourceConfig srcConfig = new IndexSourceConfigImpl(ics);
SearchEngineConfig engConfig = new SearchEngineConfigImpl(ics);
IndexSourceMetadata sourceMd =
srcConfig.getConfiguration("Global");
String engineName = sourceMd.getSearchEngineName();
SearchEngine eng = engConfig.getEngine(engineName);
String currentSite = (String)
sourceMd.getProperty(SearchIndexFields.Global.SITEID);
QueryExpression siteExpr = new
QueryExpressionImpl(SearchIndexFields.Global.SITEID,
Operation.CONTAINS, currentSite);
siteExpr =
siteExpr.or(SearchIndexFields.Global.SITEID, Operation.EQUALS, "0");        QueryExpression typeQ = new                QueryExpressionImpl(SearchIndexFields.Global.ASSET_TYPE,
Operation.EQUALS, assetType);
QueryExpression qe = typeQ.and(siteExpr);
qe.setMaxResults(maxResults);
SearchResult<ResultRow> res =
eng.search(Collections.singletonList("Global"), qe);
}
}

31 サイト・キャプチャ・アプリケーションの使用

次の各トピックではサイト・キャプチャ・アプリケーションについて説明し、そのインタフェースを操作する方法を示します。

- サイト・キャプチャ・モデル

- サイト・キャプチャ・アプリケーションへのログイン

- デフォルト・クローラの使用

- サイト・キャプチャの操作の設定

- パブリッシュによってトリガーされるサイト・キャプチャの有効化

- 静的にキャプチャされたサイトの管理

- アーカイブされたサイトの管理について

- クローラおよびキャプチャされたデータを管理するための注意事項とヒント

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

- カスタム・フォルダ

31.1 サイト・キャプチャ・モデル

クロール・セッションは、サイト・キャプチャ・インタフェースから手動で開始することも、WebCenter Sitesリアルタイム・パブリッシュ・セッションの完了時に起動することもできます。いずれの場合も、クローラは、その実行方法として選択されたモード(静的またはアーカイブ・モード)に応じてWebサイトをディスクにダウンロードします。

この項の内容は次のとおりです。

- キャプチャ・モード

- クローラ

31.1.1 キャプチャ・モード

サイトを静的またはアーカイブのいずれのモードでダウンロードした場合も、ディスクには同じファイル(html、cssなど)が格納されますが、いくつかの相違点があります。たとえば、静的にダウンロードしたサイトはファイル・システムでのみ使用可能ですが、アーカイブしたサイトはファイル・システムとサイト・キャプチャ・インタフェースの両方で使用可能になります。つまりキャプチャのモードによって、クローラがサイトをダウンロードする方法およびその結果の管理方法が決まります。

表31-1 静的キャプチャ・モードとアーカイブ・モード

静的モード

アーカイブ・モード

迅速なデプロイメントと高可用性のシナリオをサポートします。

コンプライアンスなどを目的として、定期的にWebサイトのコピーを維持するために使用されます。

クロールされたサイトが提供可能なファイルとして格納されます。最新のキャプチャのみが保持されます(以前に格納されたファイルは上書きされます)。

クロールされたすべてのサイトが保持され、タイムスタンプ付きのフォルダにzipファイル(アーカイブ)として格納されます。このzipファイルへのポインタがサイト・キャプチャ・データベースで作成されます。

静的クロール・セッションは、アプリケーション・インタフェースから手動で開始することも、パブリッシュ・セッション後に開始させることもできます。ただし、ダウンロードしたサイトは、サイト・キャプチャ・ファイル・システムからのみ管理できます。

アーカイブ・クロール・セッションは、静的セッション同様、サイト・キャプチャ・インタフェースから手動で開始することも、パブリッシュ・セッションの終了時に開始させることもできます。ただし、zipファイルはサイト・キャプチャ・データベース内のポインタによって参照されるため、サイト・キャプチャ・インタフェースで管理できます。ここで、ファイルのダウンロード、アーカイブされたサイトのプレビュー、およびキャプチャ・スケジュールの設定を実行できます。

いずれのキャプチャ・モードでも、クロール・セッション後にログが生成され、クロールされたURL、HTTPステータス、およびネットワーク条件などの情報が提供されます。静的キャプチャでは、ログをファイル・システムから取得する必要があります。アーカイブ・キャプチャでは、ログをサイト・キャプチャ・インタフェースからダウンロードできます。いずれのキャプチャ・モードにも、レポート生成時にレポートを電子メールで送信するようクローラを構成するオプションが用意されています。

31.1.2 クローラ

どのタイプのサイト・キャプチャ・プロセスを開始する場合でも、サイト・キャプチャ・インタフェースでクローラを定義する必要があります。すぐに始められるよう、サイト・キャプチャにはSampleおよびFirstSiteIIという2つのサンプル・クローラが用意されています。ここでは、サイト・キャプチャのインストール・プロセスでこれらのクローラがインストールされていることを前提としています。このガイドでは主にSampleクローラを使用します。

独自のクローラを作成するには、クローラに名前を付け(通常はターゲット・サイトにちなんだ名前)、サイト・キャプチャ・プロセスを制御するCrawlerConfigurator.groovyという名前のテキスト・ファイルをアップロードします。groovyファイルはBaseConfiguratorクラスのメソッドを使用してコード化し、少なくともクローラの開始URIとリンク抽出ロジックを指定する必要があります。groovyファイルはサイト・キャプチャ・プロセスを制御しますが、キャプチャ・モードはファイル外部で設定されます。

パブリッシュ・トリガー・サイト・キャプチャ用のクローラを使用するには追加の手順が必要です。『Oracle WebCenter Sitesのインストールと構成』で説明されているように、クローラに名前を付け、サイト・キャプチャと統合されているWebCenter Sitesソース・システム上のパブリッシュの宛先定義でキャプチャ・モードを指定します。(すべてのパブリッシュの宛先定義で1つ以上のクローラを指定できますが、単一のキャプチャ・モードしか指定できません。)クローラ・セッションの正常起動に関する情報は、サイト・キャプチャ・ファイル・システムと、WebCenter Sitesソースおよびターゲット・システムのログ・ファイル(デフォルトではfuturetense.txt)に格納されます。

この章の演習では、手動およびパブリッシュ・トリガーの両方のタイプのクローラのシナリオについて説明します。

31.2 サイト・キャプチャ・アプリケーションへのログイン

サイト・キャプチャ・アプリケーションには、WebCenter Sitesにログインしてアクセスします。

1. 次のURLでWebCenter Sitesにアクセスします。

http://<server>:<port>/<context>/login

前述の例で<server>はWebCenter Sitesを実行しているサーバーのホスト名またはIPアドレス、<port>はWebCenter Sitesアプリケーションの番号、<context>はサーバー上にデプロイされているWebCenter Sites Webアプリケーションの名前です。

2. 一般管理者としてログインします。ログイン資格証明では大文字と小文字が区別されます。このガイドでは、次のデフォルトの資格証明を使用します。

ユーザー名: fwadmin

パスワード: xceladmin

3. 「ログイン」をクリックします。

4. 初めてログインする場合は、次のダイアログが開きます。

AdminSite (デフォルトでサイト・キャプチャ・アプリケーションが割り当てられている)を選択し、サイト・キャプチャ・アイコンを選択します。

「クローラ」ページが開きます。

5. デフォルトのクローラがサイト・キャプチャとともにインストールされている場合は、SampleおよびFirstSiteIIという名前でそれらがリストされます。

図31-1 「クローラ」ページ

6. 次の手順は、要件によって異なります。

- デフォルトのクローラについて詳細を習得するには、デフォルト・クローラの使用に進みます。

- 独自のサイト・キャプチャ操作を設定し、その過程でサイト・キャプチャ・インタフェースの移動方法について習得するには、サイト・キャプチャの操作の設定に進みます。

- クローラ構成コードの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.3 デフォルト・クローラの使用

このガイドでは、デフォルトのクローラSampleおよびFirstSiteIIがサイト・キャプチャ・アプリケーションにインストールされており、(サイト・キャプチャ・アプリケーションへのログインの手順1に示すように)そのインタフェースに表示されていることを前提としています。独自のクローラを定義するには、サイト・キャプチャの操作の設定を参照してください。

この項の内容は次のとおりです。

- Sampleクローラ

- FirstSiteIIクローラ

- デフォルト・クローラの実行

31.3.1 Sampleクローラ

Sampleクローラを使用して、あらゆるサイトをダウンロードできます。Sampleクローラの目的は、サイトを迅速にダウンロードできるようにし、独自のクローラを作成するときに再利用する必須の構成コードを提供することです。Sampleクローラは、必須メソッドと、クロールへのリンク数を制限することでクロールの期間を制限するオプション・メソッドによる最小構成になっています。

- 必須メソッドは、getStartURiおよび(クロールしたページからリンクを抽出するロジックを定義する)createLinkExtractorです。

- オプションのメソッドは、クロールするリンク数を指定するgetMaxLinksです。

これらの方法、クローラのカスタマイズ方法およびインタフェースの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.3.2 FirstSiteIIクローラ

FirstSiteIIクローラは、WebCenter WebCenter Sitesの動的FirstSiteIIサンプルWebサイトを静的サイトとしてダウンロードするために使用されます。クローラの目的は、LinkExtractorおよびResourceRewriterインタフェースを使用して、カスタム・リンク・エクストラクタおよびリソース・リライタの作成方法を示す高度な構成コードを提供することです。インタフェースの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.3.3 デフォルト・クローラの実行

この項では、SampleクローラまたはFirstSiteIIクローラのいずれかを実行します。FirstSiteIIクローラを使用するには、WebCenter Sites FirstSiteIIサンプル・サイトをパブリッシュすることが必要です。

1. 「クローラ」ページで、デフォルト・クローラのSampleまたはFirstSiteIIをポイントし、「構成の編集」を選択します。

注意:

デフォルト・クローラがリストされていない場合は、サイト・キャプチャの操作の設定に進み、独自のクローラを定義します。

2. クローラ構成ファイルを編集することによって、クローラの開始URIを設定します。手順については、クローラの定義の1に進み、クローラを実行してキャプチャされたデータを管理するための残りの手順を実行します。

31.4 サイト・キャプチャの操作の設定

この項では、独自のクローラを作成および実行するプロセスを通じて、サイト・キャプチャ・インタフェースおよびファイル・システムがどのように編成されるかを理解します。

この項の内容は次のとおりです。

- 初期クローラ構成ファイルの作成

- クローラの定義

- クローラ構成ファイルの編集

- クロールの開始

31.4.1 初期クローラ構成ファイルの作成

クローラを作成する前に、クローラのサイト・キャプチャ・プロセスを制御する構成ファイルが必要です。有用なファイルを作成する最速の方法は、サンプル・コードをコピーして、必要に応じてリコードすることです。

1. 次のいずれかの方法で、サンプル構成ファイルをローカル・コンピュータにコピーします。

- サイト・キャプチャ・アプリケーションにログインします。「クローラ」ページにSampleクローラがリストされている場合は、次を実行します(それ以外の場合は、次の項目に進みます)。

a. Sampleをポイントし、「構成の編集」を選択します。

b. 「構成ファイル」フィールドに移動し、そのコードをローカル・コンピュータ上のテキスト・ファイルにコピーして、ファイルをCrawlerConfigurator.groovyとして保存します。

- サイト・キャプチャ・ホスト・コンピュータに移動し、CrawlerConfigurator.groovyファイルを<SC_INSTALL_DIR>/fw-site-capture/crawler/Sample/app/からローカル・コンピュータにコピーします。

注意:

各クローラは自身のCrawlerConfigurator.groovyファイルによって制御されます。このファイルはカスタム・フォルダ構造に格納されます。例:

クローラを定義すると、サイト・キャプチャによってクローラの名前(<crawlerName>、このシナリオではSample)の付いたフォルダが作成され、そのフォルダが<SC_INSTALL_DIR>/fw-site-capture/crawler/というパスに配置されます。サイト・キャプチャは、<crawlerName>フォルダ内に/appサブフォルダを作成し、ローカル・コンピュータからこのフォルダにgroovyファイルをアップロードします。

クローラが指定のモードで初めて使用される場合、サイト・キャプチャはそのモードでキャプチャしたサイトを格納するための追加のサブフォルダを(/<crawlerName>/内に)作成します。サイト・キャプチャ・ファイル・システムの詳細は、静的にキャプチャされたサイトの管理を参照してください。

2. サンプルのgroovyファイルは、サンプルの開始URIを指定しています。次の手順でクローラを作成するときにリセットします。(開始URIのほか、クローラ深度などのパラメータを設定し、post-crawlコマンドを起動して、ターゲット・サイトに固有のロジックを定義するためのインタフェースを実装します。)
この時点では、ダウンロードされたgroovyファイルをただちにカスタマイズするか、最初にクローラを作成してからそのgroovyファイル(サイト・キャプチャ・インタフェースで編集可能)をカスタマイズするかのオプションがあります。

- この演習を行うには、次の手順クローラの定義に進みます。

- クローラの構成方法およびインタフェースの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.4.2 クローラの定義

クローラを定義するには:

1. 「クローラ」ページに移動して、「クローラの追加」をクリックします。

2. 「クローラの追加」ページで次の手順を実行します。

a. クロール対象サイトにちなんでクローラに名前を付けます。

注意:

- クローラを保存した後で名前を変更することはできません。

- このガイドでは、すべてのカスタム・クローラがターゲット・サイトにちなんだ名前を付けられ、その他のサイトのキャプチャには使用されないことを前提としています。

b. 説明を入力します(オプション)。たとえば、「このクローラはパブリッシュ・トリガー・サイト・キャプチャ用に予約されています」または「このクローラはスケジュール済キャプチャ用に予約されています」のように入力します。

c. 「構成ファイル」フィールドで、初期クローラ構成ファイルの作成で作成したgroovyファイルを参照します。

d. 新しいクローラを保存します。
CrawlerConfigurator.groovyファイルは、サイト・キャプチャ・ホスト・コンピュータの<SC_INSTALL_DIR>/fw-site-capture/crawler/<crawlerName>/appフォルダにアップロードされます。サイト・キャプチャ・インタフェースで、直接ファイルを編集できます。

3. クローラ構成ファイルの編集に進みます。

31.4.3 クローラ構成ファイルの編集

サイト・キャプチャ・インタフェースから、クローラ構成ファイル全体をリコードできます。この例では、単純に開始URIを設定します。

1. 「クローラ」ページで、定義したクローラをポイントし、「構成の編集」を選択します。

図31-2 「構成」ページ

「構成ファイル」フィールドには、<SC_INSTALL_DIR>/fw-site-capture/crawler/<crawler name>/appにある、クローラのCrawlerConfigurator.groovy ファイルが表示されます。

2. 次の方法で、開始URIをクローラに設定します。

public String[] getStartUri() {
return ["http://www.example.com/home"]

注意:

次の点に注意してください。

複数の開始URIを設定できます。それらは同じサイトに属している必要があります。次の例に示すように、カンマ区切りの配列を入力します。

public String[] getStartUri() {  return ["http://www.example.com/product","http://www.example.com/support"];  }

構成ファイルには、クロール対象のリンクを抽出するためのロジックをコールするcreateLinkExtractorメソッドが含まれています。リンクは、クロール・セッション中にダウンロードされるマークアップから抽出されます。この方法と抽出ロジックに関する追加情報は、『Oracle WebCenter Sitesでの開発』を参照してください。

構成ファイルには、クロールするリンク数を指定するgetMaxLinksメソッドも含まれています。デフォルト値は、迅速な実行を確保するため150に設定されています。なんらかの理由で静的キャプチャを停止する必要がある場合は、アプリケーション・サーバーを停止する必要があります。キャプチャのアーカイブは、サイト・キャプチャ・インタフェースから停止できます。

クローラの構成方法およびインタフェースの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

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

4. クロールの開始に進みます。

31.4.4 クロールの開始

クロールは次のいくつかの方法で開始できます。1つのモードでクローラを使用した場合、別のモードで再実行できます。

- 静的モードでのクローラの手動実行

- アーカイブ・モードでのクローラの手動実行

- クローラのアーカイブ・キャプチャのスケジュール

- リアルタイム・モードでのサイトのパブリッシュについて

31.4.4.1 静的モードでのクローラの手動実行

クローラを静的モードで手動実行するには:

1. 「クローラ」ページで、作成したクローラをポイントし、メニューから「静的キャプチャの開始」を選択します。

キャプチャが開始されると、「クローラ」ページに次のメッセージが表示されます。

「成功しました。 クローラ<crawlerName>によって静的キャプチャが開始されました。」

2. この時点では、サイト・キャプチャ・インタフェースにはクローラまたはそのプロセスに関する他の情報は表示されず、ダウンロードされたサイトを使用することもできません。かわりに、サイト・キャプチャ・ファイル・システムを使用して、ダウンロードされたファイルや様々なログにアクセスします。

- 静的キャプチャ・プロセスを監視するには、次のファイルを検索します。

- <SC_INSTALL_DIR>/fw-site-capture/<crawlerName>/logsにあるlockファイル。lockファイルは一時ファイルです。追加の静的キャプチャを開始するためにクローラがコールされないよう、静的キャプチャ・プロセスの開始時に作成されます。クロール・セッションが終了すると、lockファイルは削除されます。

- <SC_INSTALL_DIR>/fw-site-capture/logs/のcrawler.logファイル。(このファイルで使用されている「VirtualHost」という用語は「クローラ」を意味します。)

- <SC_INSTALL_DIR>/fw-site-capture/<crawlerName>にあるinventory.dbファイル。このファイルには、クロールしたURLがリストされています。inventory.dbファイルはサイト・キャプチャ・システムによって使用されるため、削除したり変更したりしないでください。

- audit.log、links.txtファイルおよびreport.txtファイルは、/fw-site-capture/crawler/<crawlerName>/logs/yyyy/mm/ddにあります。

- ダウンロードされたファイルにアクセスするには、<SC_INSTALL_DIR>/fw-site-capture/crawler/<crawlerName>/wwwに移動します。

サイト・キャプチャ・ファイル・システムの詳細は、静的にキャプチャされたサイトの管理を参照してください。

31.4.4.2 アーカイブ・モードでのクローラの手動実行

クローラをアーカイブ・モードで手動実行するには:

1. 「クローラ」ページで、作成したクローラをポイントし、「アーカイブの開始」を選択します。

コメント・ダイアログが開きます。

2. ダイアログで、今後のジョブに関するコメントを追加します。

図31-3 「コメント」ダイアログ

注意:

クローラが実行を開始した後は、コメントを追加できません。

前出のダイアログでコメントを追加するように選択した場合、それは次の場所に表示されます。

- 「ジョブの詳細」ページの「ジョブのコメント」フィールド(次の手順に示す)。

- 「ジョブ」ページの「ジョブのコメント」フィールド。

- 「アーカイブ」ページの「コメント」フィールド。

3. 「アーカイブの開始」をクリックします。

「ジョブの詳細」ページが開きます。ここでは、アーカイブ・プロセスをいくつかの方法で管理できます。この演習を続けるには、「終了」が開くまで、「リフレッシュ」(「ジョブの状態」の隣)をクリックします。

- 「リフレッシュ」は、ジョブ状態が「スケジュール済」または「実行中」のときに表示されます。「リフレッシュ」をクリックすると、表示されたジョブ状態が更新されます。可能なジョブ状態は、「スケジュール済」、「実行中」、「終了」、「停止」および「失敗」です。

- 「アーカイブの停止」は、クローラ・セッションを終了します。キャプチャされたリソースはすべてアーカイブされ、ジョブ状態が「実行中」から「終了」に変更されます(変更を表示するには、「リフレッシュ」をクリックします)。

- ジョブ状態が「終了」の場合、「プレビュー」が表示されます。「プレビュー」をクリックすると、アーカイブされたサイトが表示されます。

- 「取消」をクリックすると、「ジョブ」ページにリダイレクトされます。実行中の場合、クローラは実行を継続します。

4. アーカイブ・クロールが終了すると、結果がサイト・キャプチャ・インタフェースで使用可能になります。次に例を示します。

- クローラ・レポートが「ジョブの詳細」ページに表示されます。レポートには、ダウンロードされたリソース数、その合計サイズとダウンロード時間、ネットワーク条件、HTTPステータス・コード、および必要に応じて追加のメモが記載されます。

- アーカイブされたサイトをレンダリングするには、「ジョブの詳細」ページの「プレビュー」をクリックします。サイトの横には、アーカイブ管理オプションを備えたアーカイブIDテーブルがあり、これはアーカイブをポイントすると表示されます。

注意:

アーカイブされたサイトに外部ドメインへのリンクが含まれる場合、特に(CrawlerConfigurator.groovyファイルで)クロール深度とクロールするリンク数が大きな値に設定される場合には、そのプレビューにこれらのリンクが含まれることがあります。外部ドメインは参照できますが、アーカイブされません。

- 様々なデータへの経路の要約は、アーカイブされたサイトの管理についてを参照してください。

31.4.4.3 クローラのアーカイブ・キャプチャのスケジュール

アーカイブ・キャプチャのみをスケジュールできます。特定のクローラに対して複数のスケジュールを作成できます。たとえば、定期的なキャプチャ用と、特定かつ一意の時間のキャプチャ用に別々のスケジュールを作成できます。

注意:

複数のスケジュールを設定する場合は、それらが重複しないようにしてください。

1. 「クローラ」ページに移動して、作成したクローラをポイントし、「アーカイブのスケジュール」を選択します。

2. 「スケジュールの追加」をクリックし、すべてのカレンダーで「曜日」、「日付」、「月」、「時間」および「分」を選択します。

3. 「保存」をクリックし、必要に応じて別のスケジュールを追加します。

31.4.4.4 リアルタイム・モードでのサイトのパブリッシュについて

WebCenter Sitesパブリッシュ・システムを構成してサイト・キャプチャ・アプリケーションと通信する場合は、新たなパブリッシュ済サイトをキャプチャするために1つ以上のクローラを起動するようにリアルタイム・パブリッシュ・プロセスを設定できます。手順については、パブリッシュ・トリガー・サイト・キャプチャの有効化を参照してください。

31.4.5 キャプチャ・データの管理について

静的およびアーカイブ・キャプチャに関連付けられた様々なデータへのアクセスの詳細は、静的にキャプチャされたサイトの管理を参照してください。

クローラおよびキャプチャされたデータを管理するための注意事項とヒントに、クローラとキャプチャされたデータを管理する場合に留意すべき注意事項とヒントをまとめてあります。

31.5 パブリッシュによってトリガーされるサイト・キャプチャの有効化

管理ユーザーは、必要な数のサイト・キャプチャ用のパブリッシュの宛先定義を構成し、必要な数のクローラをコールできます。パブリッシュ・トリガー・サイト・キャプチャを有効にするための主な手順は次のとおりです。

- サイト・キャプチャ・アプリケーションとOracle WebCenter Sitesの統合について

- サイト・キャプチャ用のリアルタイム・パブリッシュの宛先定義の構成

- クローラの一致

- サイト・キャプチャの管理

31.5.1 サイト・キャプチャ・アプリケーションとOracle WebCenter Sitesの統合について

サイト・キャプチャ・アプリケーションが、パブリッシュ・プロセスで使用されるWebCenter Sitesソースおよびターゲット・システムと最初に統合される場合のみ、リアルタイム・パブリッシュ・セッション後にサイト・キャプチャを有効にできます。サイト・キャプチャが統合されていない場合は、『Oracle WebCenter Sitesのインストールと構成』で統合手順を参照してから、次の手順に進みます。

31.5.2 サイト・キャプチャ用のリアルタイム・パブリッシュの宛先定義の構成

パブリッシュの宛先定義を構成する場合、パブリッシュ・セッションの後でコールされるクローラの名前を指定します。キャプチャ・モードも指定します。

1. サイト・キャプチャ・アプリケーションと統合されるWebCenter Sitesソース・システムに移動します。

a. サイト・キャプチャと統合されるWebCenter Sitesターゲット・システムをポイントするリアルタイム・パブリッシュの宛先定義を作成します。リアルタイム・パブリッシュの宛先作成の詳細は、リアルタイム・パブリッシュの使用を参照してください。

b. パブリッシュの宛先定義の「他の引数」セクションで、パブリッシュ・セッションの後で起動するクローラを指定し、次のパラメータを使用してキャプチャ・モードを設定します。

- CRAWLERCONFIG: 各クローラの名前を指定します。複数のクローラを使用する場合は、名前をセミコロン(;)で区切ります。
例:

単一クローラの場合: CRAWLERCONFIG=crawler1

複数クローラの場合: CRAWLERCONFIG=crawler1;crawler2;crawler3

注意:

ここで指定するクローラは、サイト・キャプチャ・インタフェースでも構成され、さらに同じ名前である必要があります。クローラ名は大文字と小文字が区別されます。

- CRAWLERMODE: アーカイブ・キャプチャを実行するには、このパラメータをdynamicに設定します。デフォルトでは、静的キャプチャが有効になります。
例: CRAWLERMODE=dynamic

注意:

- CRAWLERMODEモードが省略されるかdynamic以外の値に設定された場合、パブリッシュ・セッションが終了すると、静的キャプチャが開始されます。

- 両方のクローラ・パラメータを、次のように単一の文で設定できます。CRAWLERCONFIG=crawler1;crawler2&CRAWLERMODE=dynamic

- 複数のクローラを指定できますが、設定できるモードは1つのみです。すべてのクローラがそのモードで実行されます。一部のクローラを異なるモードで実行するには、別のパブリッシュの宛先定義を構成します。

2. 次の手順に進みます。

31.5.3 クローラの一致

パブリッシュの宛先定義で指定したクローラは、サイト・キャプチャ・インタフェースに存在している必要があります。次の手順を実行します。

1. 宛先定義(サイト・キャプチャ用のリアルタイム・パブリッシュの宛先定義の構成の手順b)とサイト・キャプチャ・インタフェースのクローラ名が同じであることを確認します。名前は、大/小文字が区別されます。

2. 各クローラの構成ファイルでターゲット・サイトの有効な開始URIが設定されていることを確認します。クローラの構成ファイルへの移動の詳細は、クローラ構成ファイルの編集を参照してください。構成コードの記述方法の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.5.4 サイト・キャプチャの管理

サイト・キャプチャを管理するには:

1. パブリッシュ・トリガー・サイト・キャプチャが有効になると、いつでもターゲット・サイトをパブリッシュできます。パブリッシュが終了すると、サイト・キャプチャが開始されます。パブリッシュの宛先定義でCRAWLERMODEパラメータをどのように設定したかに応じて(サイト・キャプチャ用のリアルタイム・パブリッシュの宛先定義の構成の手順b)、静的モードまたはアーカイブ・モードのいずれかで、クローラがページをキャプチャします。

2. サイト・キャプチャ・プロセスを監視するには、次の手順を実行します

- 静的キャプチャの場合、サイト・キャプチャ・インタフェースにはセッションに関する情報が表示されず、キャプチャされたサイトも使用可能になりません。

- クローラがコールされたかどうかを判断するには、ソースまたはターゲットのWebCenter Sitesシステムでfuturetense.txtファイルを開きます。

注意:

WebCenter Sitesのソースおよびターゲット・システム上のfuturetense.txtファイルには、静的およびアーカイブのいずれかのタイプのクロールに関するクローラ起動ステータスが含まれています。

- キャプチャ・プロセスを監視するには、サイト・キャプチャ・ファイル・システムに移動し、静的モードでのクローラの手動実行の手順2でリストされたファイルを確認します。

- 動的キャプチャの場合、サイト・キャプチャ・インタフェースからクロールのステータスを表示できます。

a. 「クローラ」ページに移動し、クローラをポイントして、ポップアップ・メニューから「ジョブ」を選択します。

b. 「ジョブの詳細」ページで、「終了」が表示されるまで「ジョブの状態」の横にある「リフレッシュ」をクリックします。(「ジョブの状態」で可能な値は、「スケジュール済」、「実行中」、「終了」、「停止」または「失敗」です。)「ジョブの詳細」ページの詳細は、アクティブ・モードでのクローラの手動実行の手順3と4を参照してください。

3. キャプチャされたデータを管理します。
クロール・セッションが終了したら、キャプチャされたサイトと関連データを次のように管理できます。

- 静的にキャプチャされたサイトの場合は、サイト・キャプチャ・ファイル・システムに移動します。詳細は、静的にキャプチャされたサイトの管理を参照してください。

- アーカイブされたサイトの場合は、サイト・キャプチャ・インタフェースを使用してサイトをプレビューし、zipファイルとログをダウンロードします。詳細は、アーカイブされたサイトの管理についてを参照してください。

31.6 静的にキャプチャされたサイトの管理

サイト・キャプチャ・インタフェースでユーザーが作成するすべてのクローラごとに、サイト・キャプチャでは、そのファイル・システム内に同じ名前のフォルダが作成されます。このカスタム・フォルダ<crawlerName>は、クローラの構成ファイル、キャプチャおよびログを編成するのに使用されます。<crawlerName>フォルダとその内容の説明は図31-4を参照してください。

注意:

静的キャプチャおよびログにアクセスするには、ファイル・システムを使用する必要があります。アーカイブ・キャプチャおよびログはサイト・キャプチャ・インタフェースから管理されます(ファイル・システム内のこれらの場所については、この項で説明します)。

図31-4 サイト・キャプチャのカスタム・フォルダ: <crawlerName>

表31-2 <crawlerName>フォルダとそのコンテンツ

フォルダとそのコンテンツ" width="100%">

フォルダ

説明

/fw-site-capture/crawler/<crawlerName>

クローラを表します。サイト・キャプチャ・インタフェースでユーザーが定義するクローラごとに、サイト・キャプチャでは、/<crawlerName>フォルダが作成されます。たとえば、サンプル・クローラFirstSiteIIおよびSampleをインストールした場合、サイト・キャプチャ・インタフェースには両方のクローラがリストされ、サイト・キャプチャ・ファイル・システムに同じ名前のフォルダが存在するようになります。

注意: サブフォルダ(次を参照)のほか、<crawlerName>フォルダには、静的にクロールされたURLがリストされたinventory.dbファイルが含まれています。このファイルは、クローラがその最初の静的キャプチャを取得したときに作成されます。inventory.dbを削除したり変更したりしないでください。それはサイト・キャプチャ・システムによって使用されます。

/fw-site-capture/crawler/<crawlerName>/app

CrawlerConfiguration.groovyファイルが含まれます。そのコードはクロール・プロセスを制御します。クローラが作成され保存されると、/appフォルダが作成されます。

/fw-site-capture/crawler/<crawlerName>/archive

/archiveフォルダは、アーカイブ・キャプチャ用としてのみ使用されます。このフォルダにはyyyy/mm/ddサブフォルダの階層が含まれます。/ddサブフォルダには、すべてのアーカイブ・キャプチャがタイムスタンプ付きzipファイルとして格納されます。

/archiveフォルダは、クローラが最初にアーカイブ・モードで実行されたときに作成されます。zipファイル(/ddにある)はデータベースで参照されるため、サイト・キャプチャ・インタフェースでWebサイトとしてのダウンロードおよび表示が可能になります。

注意: アーカイブ・キャプチャは、サイト・キャプチャ・インタフェースからアクセスできます。各zipファイルには、__inventory.dbという名前のURLログが含まれます。__inventory.dbを削除したり変更したりしないでください。それはサイト・キャプチャ・システムによって使用されます。

/fw-site-capture/crawler/<crawlerName>/www

最新の静的にキャプチャされたサイトのみが含まれます(同じクローラが静的モードで再実行されると、前のキャプチャが上書きされます)。サイトは、html、cssおよび提供可能な他のファイルとして格納されます。

/wwwフォルダは、クローラが最初に静的モードで実行されたときに作成されます。

注意: 静的キャプチャは、サイト・キャプチャ・ファイル・システムからアクセスできます。

/fw-site-capture/crawler/<crawlerName>/logs/yyyy/mm/dd

クロールされたURLに関する情報を記載したログ・ファイルが含まれます。ログ・ファイルは/ddサブフォルダに格納され、図31-5 に示すように命名されます。

- audit.logファイルは、タイムスタンプ、クロール深度、HTTPステータス、ダウンロード時間などのデータとともにクロールされたURLをリストします。

- links.txtファイルは、クロールされたURLをリストします。

- report.txtファイルは、ダウンロードされたリソース数、合計サイズ、ダウンロード・サイズおよび時間、ネットワーク条件などのクロール統計全体をリストします。アーカイブ・キャプチャでは、このレポートを、クローラ・レポートとしてサイト・キャプチャ・インタフェースで使用できます(「ジョブの詳細」フォーム上で。「ジョブの詳細」フォームへのパスは、図31-6を参照してください)。

注意: クローラが静的モードとアーカイブ・モードの両方でキャプチャした場合、/ddサブフォルダには静的キャプチャとアーカイブ・キャプチャのログが含まれます。

/logsフォルダはlockという名前の一時ファイルを格納するためにも使用されます。このファイルは、追加の静的キャプチャを開始するためにクローラがコールされないよう、静的キャプチャ・プロセスの開始時に作成されます。クロール・セッションが終了すると、lockファイルは削除されます。

図31-5 ログ・ファイルの場所

logs/yyyy/mm/の下のフォルダには、次のログが含まれます。

- <yyyy-mm-dd-hh-mm-ss>-audit.log

- <yyyy-mm-dd-hh-mm-ss>-links.txt

- <yyyy-mm-dd-hh-mm-ss>-report.txt

31.7 アーカイブされたサイトの管理について

アーカイブされたサイトは、サイト・キャプチャ・インタフェースの様々なフォームから管理できます。図31-6は、アーカイブ、ジョブ、サイト・プレビュー、クローラ・レポート、URLログなどの様々な情報への経路の一部を示しています。

図31-6 アーカイブ情報へのパス

- たとえば、サイトをプレビューするには、「クローラ」フォームでクローラ(crawlerName)をポイントして、ポップアップ・メニュー(「アーカイブ」フォームを開くメニュー)から「アーカイブ」を選択し、「アーカイブID」をポイントして、ポップアップ・メニューから「プレビュー」を選択します。

- 破線は同じオプションへの複数のパスを示しています。たとえば、サイトをプレビューするには、クローラの「アーカイブ」パス、「ジョブ」パスまたは「アーカイブの開始」パスをたどることができます。アーカイブをダウンロードするには、「アーカイブ」パスまたは「ジョブ」パスをたどることができます。

- クローラ・レポートおよびURLログはアスタリスク(*)でマークされています。

31.8 クローラおよびキャプチャされたデータを管理するための注意事項とヒント

次の各トピックに、クローラおよびキャプチャされたデータを管理するための注意事項とヒントをまとめています。

- クローラを作成および編集する際のヒント

- クローラ削除の注意

- クローラのスケジュールの注意

- 静的クロールの監視について

- クロールの停止について

- アーカイブのダウンロードについて

- サイトのプレビューについての注意

- パブリッシュの宛先定義の構成のヒント

- ログ・ファイルへのアクセスについて

31.8.1 クローラを作成および編集する際のヒント

クローラを作成し、その構成コードを編集する場合は、次の情報を考慮してください。

- クローラ名は大文字と小文字が区別されます。

- すべてのクローラの構成ファイルには、CrawlerConfigurator.groovyという名前が付けられます。この名前は変更しないでください。

- クローラは、指定のサイト上で1つ以上のシードURIで開始し、1つ以上のパスをクロールするように構成できます。追加のJavaメソッドを使用して、クロール深度などのパラメータを設定したり、post-crawlコマンドを起動したり、セッション・タイムアウトを指定したりできます。リンクを抽出し、URLをリライトして、クロール・セッションの終了時に電子メールを送信するためのロジックを定義するようにインタフェースを実装できます。詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

- クローラが作成され保存されると、そのCrawlerConfigurator.groovyファイルはサイト・キャプチャ・ファイル・システムにアップロードされ、サイト・キャプチャ・インタフェースで編集可能になります。

- クローラが静的サイト・キャプチャ・プロセスを実行している間は、2番目の静的キャプチャ・プロセスを使用して実行することはできません。

- クローラがアーカイブ・キャプチャ・プロセスを実行している間は、2番目のアーカイブ・キャプチャ・プロセスを使用して実行することはできません。2番目のプロセスは「スケジュール済」としてマークされ、最初のプロセスが終了した後に開始されます。

31.8.2 クローラ削除の注意

クローラ(すべてのキャプチャされた情報を含む)を削除する必要がある場合は、ファイル・システムではなく、サイト・キャプチャ・インタフェースから実行してください。クローラをインタフェースから削除すると、リンクの破損を防ぐことができます。たとえば、クローラがアーカイブ・モードで実行された場合、インタフェースからそれを削除すると、アーカイブとログおよびこれらのアーカイブとログへのデータベース参照の2つの情報が削除されます。ファイル・システムからクローラを削除すると、すでに存在していないアーカイブやログに対するデータベース参照が保持されたままになるため、サイト・キャプチャ・インタフェースで破損したリンクが生じます。

31.8.3 クローラのスケジュールの注意

アーカイブ・クロールのみをスケジュールできます。

- クローラのスケジュールを設定する場合、サイトのパブリッシュ・スケジュールを考慮して、2つが重複しないようにします。

- 単一クローラに対して複数のスケジュールを作成できます。たとえば、クローラを定期的に起動するためのスケジュールを1つ作成し、特定の一意の時間にクローラをコールする別のスケジュールを作成できます。

- 複数のスケジュールを作成する場合は、それらが重複しないようにしてください。

31.8.4 静的クロールの監視について

静的クローラ・セッションが進行中であるか完了済かを判断するには、<SC_INSTALL_DIR>/fw-site-capture/<crawlerName>/logsフォルダのクローラlockファイルを検索します。lockファイルは一時ファイルです。追加の静的キャプチャを開始するためにクローラがコールされないよう、静的キャプチャ・プロセスの開始時に作成されます。クローラ・セッションが終了すると、lockファイルは削除されます。

31.8.5 クロールの停止について

クローラを実行する前に、クロールされるリンク数およびクロール深度を考慮してください。その両方によってクローラのセッション期間が決まります。

- アーカイブ・クロールを終了する必要がある場合、サイト・キャプチャ・インタフェースを使用します。(「ジョブの詳細」フォームで「アーカイブの停止」を選択します。)

- 静的クロールを終了する必要がある場合は、アプリケーション・サーバーを停止する必要があります。

31.8.6 アーカイブのダウンロードについて

サイト・キャプチャ・インタフェースからは(250MBを超える)大きなアーカイブ・ファイルをダウンロードしないでください。かわりに、getPostExecutionCommandを使用して、サイト・キャプチャ・ファイル・システムから必要な場所にファイルをコピーします。

「ジョブの詳細」フォームで、クローラ・レポートからアーカイブのサイズを取得できます。「ジョブの詳細」フォームへのパスは、図31-6を参照してください。getPostExecutionCommandメソッドの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

31.8.7 サイトのプレビューについての注意

アーカイブされたサイトに外部ドメインへのリンクが含まれる場合、特に(groovyファイルで)クロール深度とクロールするリンク数が大きな値に設定される場合には、そのプレビューにこれらのリンクが含まれることがあります。外部ドメインは参照できますが、アーカイブされません。

31.8.8 パブリッシュの宛先定義の構成のヒント

- パブリッシュ・トリガー・サイト・キャプチャを実行する場合は、パブリッシュの宛先定義の単一の文でクローラ・パラメータを設定できます。
CRAWLERCONFIG=crawler1;crawler2&CRAWLERMODE=dynamic

- パブリッシュの宛先定義で複数のクローラを指定できますが、設定できるキャプチャ・モードは1つのみです。すべてのクローラがそのモードで実行されます。一部のクローラを異なるモードで実行するには、別のパブリッシュの宛先定義を構成します。

31.8.9 ログ・ファイルへのアクセスについて

- 静的にキャプチャされたサイトの場合、ログ・ファイルはサイト・キャプチャ・ファイル・システムでのみ使用可能です。:

- 静的にクロールされたURLをリストしているinventory.dbファイルは、/fw-site-capture/crawler/<crawlerName>フォルダにあります。

注意:

inventory.dbファイルは、サイト・キャプチャ・システムによって使用されます。削除または変更しないでください。

- crawler.logファイルは、<SC_INSTALL_DIR>/fw-site-capture/logs/フォルダにあります。(crawler.logファイルで使用されている「VirtualHost」という用語は「クローラ」を意味します。)

- 静的にキャプチャされアーカイブされたサイトの場合、共通のログ・ファイル・セットがサイト・キャプチャ・ファイル・システムに存在します。

- audit.log。クロールされたURL、タイムスタンプ、クロール深度、HTTPステータスおよびダウンロード時間をリストします。

- links.txt。クロールされたURLをリストします。

- report.txt。クローラ・レポートです。

前出の名前のファイルは次のフォルダにあります。

/fw-site-capture/crawler/<crawlerName>/logs/yyyy/mm/dd

注意:

アーカイブされたサイトの場合、report.txtはサイト・キャプチャ・インタフェースの「ジョブの詳細」フォームでも入手可能で、そこでは「クローラのレポート」と呼ばれています。(「ジョブの詳細」フォームへのパスは、図31-6を参照してください)。

- アーカイブ・プロセスでは、すべてのクロールのURLログも生成されます。ログは次の2つの場所で入手可能です。

- サイト・キャプチャ・ファイル・システム内。__inventory.dbと呼ばれます。このファイルは次のフォルダのzipファイル内にあります。
/fw-site-capture/crawler/<crawlerName>/archive/yyyy/mm/dd

注意:

__inventory.dbファイルは、サイト・キャプチャ・システムによって使用されます。削除または変更しないでください。

- サイト・キャプチャ・インタフェースの「アーカイブ済URL」フォーム内(パスは図31-6に示されています)。

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

サイト・キャプチャ・ファイル・システムは、サイト・キャプチャがカスタム・クローラとそれらのキャプチャされたコンテンツを編成するフレームワークも提供します。ファイル・システムは、インストール関連ファイル、プロパティ・ファイル、サンプル・クローラ、およびサイト・キャプチャ・プロセスを制御するためにFirstSiteIIクローラによって使用されるサンプル・コードを格納するために、サイト・キャプチャ・インストール・プロセスで作成されます。

図31-7は、よく使用されるサイト・キャプチャ情報を検索するうえで役立つように、サイト・キャプチャで最も頻繁にアクセスされるフォルダを示しています。<crawlerName>以外のフォルダはすべて、サイト・キャプチャのインストール・プロセスで作成されます。<crawlerName>フォルダの詳細は、表31-3およびカスタム・フォルダを参照してください。

図31-7 サイト・キャプチャ・ファイル・システム

表31-3 サイト・キャプチャの頻繁にアクセスされるフォルダ

フォルダ

説明

/fw-site-capture

親フォルダです。

/fw-site-capture/crawler

すべてのサイト・キャプチャ・クローラが含まれ、それぞれ専用のクローラ固有フォルダに格納されます。

/fw/site-capture/crawler/_sample

FirstSiteIIサンプル・クローラのソース・コードが含まれます。

注意: アンダースコア(「_」)で始まるフォルダ名はクローラとして扱われません。それらはサイト・キャプチャ・インタフェースには表示されません。

/fw-site-capture/crawler/Sample

「Sample」という名前のクローラを表しています。このフォルダは、「Sample」クローラがサイト・キャプチャのインストール・プロセスでインストールされた場合にのみ作成されます。

Sampleフォルダには/appフォルダが含まれ、そこに「Sample」クローラ固有のCrawlerConfiguration.groovyファイルが格納されます。このファイルには動的サイトをキャプチャするための基本構成コードが含まれます。コードは、BaseConfiguratorクラスの必須メソッド(getStartUriなど)の使用方法を例示しています。

Sampleクローラが静的モードまたはアーカイブ・モードでコールされると、/Sampleフォルダ内にサブフォルダが作成されます。

/fw-site-capture/logs

サイト・キャプチャのシステム・ログであるcrawler.logファイルが含まれます。

/fw-site-capture/publish-listener

パブリッシュ・トリガー・クロール用のサイト・キャプチャをインストールするために必要な次のファイルが含まれます。

- fw-crawler-publish-listener-1.1-elements.zip

- fw-crawler-publish-listener-1.1.jar

/fw-site-capture/Sql-Scripts

サイト・キャプチャがデータを格納するために必要なデータベース表を作成する次のスクリプトが含まれます。

- crawler_db2_db.sql

- crawler_oracle_db.sql

- crawler_sql_server_db.sql

/fw-site-capture/webapps

ROOT/WEB-INF/フォルダが含まれます。

/fw-site-capture/webapps/ROOT/WEB-INF

crawler.logファイルへのパスをカスタマイズするために使用されるlog4j.xmlファイルが含まれます。

/fw-site-capture/webapps/ROOT/WEB-INF/classes

次のファイルが含まれます。

- sitecapture.propertiesファイル。サイト・キャプチャが実行されているWebCenter Sitesアプリケーションに関する情報を指定できます。情報には、WebCenter Sitesホスト・コンピュータ名(またはIPアドレス)およびポート番号が含まれます。

- root-context.xmlファイル。サイト・キャプチャ・データベースを構成できます。

31.10 カスタム・フォルダ

カスタム・フォルダは、ユーザーがサイト・キャプチャ・インタフェースで作成する各クローラについて作成されます。カスタム・フォルダの<crawlerName>は、図31-8に要約されているとおり、クローラの構成ファイル、キャプチャおよびログを編成するために使用されます。

図31-8 サイト・キャプチャのカスタム・フォルダ: <crawlerName>

32 Enterprise ManagerでのWebCenter Sitesとそのコンポーネントのパフォーマンスの管理

Enterprise Managerでは、管理、パフォーマンス・メトリックの監視、システム・パフォーマンスの監査、およびOracle WebCenter SitesおよびOracle WebCenter Sites: Visitor Servicesのシステム・メッセージの表示ができます。

次の各トピックでは、Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの管理について説明します。

- WebLogic ServerコンソールでのWebCenter Sitesとそのコンポーネントの起動

- Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動

- WebCenter Sitesとそのコンポーネントのホームページの表示

- WebCenter Sitesとそのコンポーネントのログ・ファイルの管理

- WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの監視

32.1 WebLogic ServerコンソールでのWebCenter Sitesとそのコンポーネントの起動

Oracle WebLogic Server管理コンソールは、WebLogic Serverドメインの管理に使用されるブラウザ・ベースのユーザー・インタフェースです。管理サーバーでは管理コンソールがホストされます。管理コンソールは、管理サーバーへのネットワーク・アクセスを持ち、サポートされたWebブラウザであればどのブラウザからでもアクセス可能なWebアプリケーションです。

WebLogic Serverでコンポーネントの機能に移動するには:

1. WebLogic ServerのURLを入力します。このURLには、インストール時にWebLogic Serverに割り当てられたホスト名とポート番号が含まれます。URLの形式は次のとおりです。

http://hostname.domain:port/console

portは、Oracle WebLogic Server上で実行されている管理サーバーのIPポート番号です。デフォルトのポート番号は7001です。

2. システム管理者のユーザー名とパスワードを入力し、「ログイン」ボタンをクリックします。

3. ナビゲーション・ペインで、ファーム、「WebLogicドメイン」の順に開き、 「サイト」またはVisitor Servicesコンポーネントをクリックします。

選択内容に対応するドメイン・ページが表示されます。

WebLogic Server管理コンソールでは、サーバー、クラスタ、仮想ホストおよびワーク・マネージャなどの環境を管理できます。詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

32.2 Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動

Oracle Enterprise Manager Fusion Middleware Controlは、Oracle WebCenterをインストールするときにデプロイされる、ブラウザベースの管理アプリケーションです。Oracle Enterprise Managerから、次を監視および管理できます。

- Oracle WebCenter Sites

- Oracle WebCenter Sites: Visitor Services

Oracle Enterprise ManagerでOracle WebCenter Enterprise Managementのページに移動するには:

1. Oracle Enterprise Manager Fusion Middleware ControlのURLを入力します。このURLには、インストール中にOracle Enterprise Managerに割り当てられたホスト名とポート番号が含まれます。URLの形式は次のとおりです。

http://hostname.domain:port/em

portは、Oracle WebLogic Server上で実行されている管理サーバーのIPポート番号です。デフォルトのポート番号は7001です。

2. システム管理者のユーザー名とパスワードを入力し、「ログイン」ボタンをクリックします。

3. 「ターゲット・ナビゲーション」ペインで、ファーム、「WebCenter」、「サイト」の順に開きます。

4. 「サイト」またはVisitor Servicesを選択し、続いてサーバー・ノード(たとえば、Visitor Services)を選択します。

起動したコンポーネントのホームページが表示されます。

5. 左側のペインでWebCenter Sites:<コンポーネント名>をクリックすると、<コンポーネント>メニューが表示されます。

次の表は、このページ上の <コンポーネント>サーバー・メニュー・オプションの一部のリストです。

表32-1 WebCenter Sites : <コンポーネント>メニュー・オプション

メニュー・オプション" width="90%">

メニュー・オプション

説明

ホーム

このオプションを使用して、WebCenter SitesまたはVisitor Servicesのホームページに移動します。WebCenter Sitesとそのコンポーネントのホームページの表示を参照してください。

監視

このオプションを使用して、WebCenter SitesまたはVisitor Servicesサーバーの主なパフォーマンス・メトリックを監視できます。WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの監視を参照してください。

制御

このオプションを使用して、WebCenter Sitesまたはサーバー上に展開されているVisitor Servicesアプリケーションを起動または停止します。

ログ

ログを表示したり、ログ・レベルを制御する場合は、このオプションを使用します。WebCenter Sitesとそのコンポーネントのログ・ファイルの表示を参照してください。

システムMBeanブラウザ

「システムMBeanブラウザ」は、ランタイムおよびアプリケーションによって定義された構成済のMBeanをすべてリストします。MBeanの属性にアクセスしたり、それらを操作する場合は、このオプションを使用します。

ターゲット・サイトマップ

このオプションを使用して、WebCenter SitesまたはVisitor Servicesサーバーのメニュー・オプションを表示できます。

ターゲット情報

このオプションを使用して、WebCenter SitesまたはVisitor Servicesサーバーに関する一般情報を表示できます。

32.3 WebCenter Sitesとそのコンポーネントのホームページの表示

Oracle WebCenter SitesまたはVisitor Servicesサーバーのステータスは、Oracle Enterprise ManagerまたはOracle WebLogic Serverを使用して表示できます。Oracle WebCenter SitesとOracle Enterprise ManagerのVisitor Servicesのホームページには、システムのステータスが表示されます。ホームページには、Oracle WebCenter SitesおよびVisitor Servicesシステムの状態、バージョンおよび稼働時間が表示されます。

Oracle WebCenter SitesまたはVisitor Servicesシステム・インストールのステータスを表示するには:

1. Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動に記載された手順を使用して、Oracle Enterprise Managerにログインします。
コンポーネント・ホームページが表示されます。

2. ホームページの「一般情報」セクションで、Oracle WebCenter Sitesまたはそのコンポーネント・システムのステータス(状態、バージョンおよび稼働時間)を確認します。

3. 下側のペインの「パフォーマンスの概要」セクションで、コンポーネントのパフォーマンス・メトリックを表示します。パフォーマンス・メトリックの詳細は、WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの監視を参照してください。

右側のペインにあるコンポーネント・メニュー・オプションの「ホーム」をクリックすることによって、他のどのページからでもホームページに移動できます。

注意:

Oracle WebLogic Server管理コンソールを使用したOracle WebCenter SitesまたはWebCenter Sites: Visitor Servicesシステムのステータスの表示の詳細は、Oracle WebLogic Serverのドキュメントを参照してください。

32.4 WebCenter Sitesとそのコンポーネントのログ・ファイルの管理

Oracle Enterprise Managerを使用して、構成メッセージのロギングの有効化、メッセージのデバッグ、メッセージの追跡およびログ・ファイルの構成ができます。

この項には次のトピックが含まれます:

- WebCenter Sitesとそのコンポーネントのログ・ファイル設定の構成

- WebCenter Sitesとそのコンポーネントのログ・ファイルの表示

32.4.1 WebCenter Sitesとそのコンポーネントのログ・ファイル設定の構成

デフォルトでは、Enterprise Managerのエラー、警告および重要なアプリケーション・ライフサイクル・イベントは、アプリケーション・サーバー上のログに記録されます。システム管理者は、段階的にログ・レベルを上げて、構成メッセージ、デバッグ・メッセージおよびトレース・メッセージのロギングを有効にできます。Oracle Enterprise Managerを使用すると、WebCenter Sitesシステムのログ・メッセージを表示および構成できます。ログ・ファイル管理の詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルと診断データの管理に関する項を参照してください。

{weblogic_server_name}はWebLogic Serverの名前です(たとえば VisitorServices01またはSites01)。

当初、ログ・ファイルはsites.logおよびcas.logという名前で、アプリケーション・サーバー・ログ・ディレクトリに作成されます。

WebCenter Sitesのログ・ファイルは、Oracle Enterprise Managerを使用して構成できます。

構成できるのは、ログ・ファイルの名前と場所、ログ・ファイルのサイズ、ログ・ファイルに記録する情報のレベル、形式およびロケール・エンコーディングです(『Oracle Fusion Middlewareの管理』のログ・ファイル設定の構成に関する項を参照)。

32.4.2 WebCenter Sitesとそのコンポーネントのログ・ファイルの表示

Oracle WebCenter SitesまたはVisitor Servicesのログ・ファイルは、Oracle Enterprise Managerから参照できます。

Oracle Enterprise Managerを使用してログ・ファイルを表示する手順は次のとおりです。

1. Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動に記載された手順を使用して、Oracle Enterprise Managerにログインします。

2. コンポーネント・メニューのオプションを表示するには、左側のペインでコンポーネント・サーバーをクリックします。

3. ログ・ファイルを表示するには、「ログ」を選択し、続いてコンポーネント・メニューから「ログ・メッセージの表示」を選択します。「ログ・メッセージ」ページが表示されます。

4. このページでは、特定の日付範囲やタイプに該当するメッセージ、または特定のキーワードを含むメッセージを検索できます。また、リストからメッセージを選択し、その詳細を表示することもできます。

32.5 WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの監視

システムのステータスの監視と表示の概要など、Oracle WebCenter SitesまたはVisitor Servicesシステムの監視の詳細は、次の各トピックを参照してください。

- WebCenter Sitesとそのコンポーネントのステータスの表示

- WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの表示

32.5.1 WebCenter Sitesとそのコンポーネントのステータスの表示

Oracle WebCenter SitesまたはVisitor Servicesのステータスは、Oracle Enterprise ManagerまたはOracle WebLogic Serverを使用して表示できます。Oracle Enterprise Managerのコンポーネント・ホームページに、コンポーネント・システムのステータスが表示されます。コンポーネント・システムの状態、バージョンと稼働時間が表示されます。

コンポーネント・システム・インストールのステータスを表示する手順は次のとおりです。

1. Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動に記載された手順を使用して、Oracle Enterprise Managerにログインします。
コンポーネント・ホームページが表示されます。

2. ホームページの「<コンポーネント>: 一般情報」セクションで、コンポーネント・システムのステータス(状態、バージョンおよび稼働時間)を確認します。

右側のペインにあるコンポーネント・メニュー・オプションの「ホーム」をクリックすることによって、他のどのページからでもホームページに移動できます。

注意:

Oracle WebLogic Server管理コンソールを使用したコンポーネント・システムのステータスの表示の詳細は、Oracle WebLogic Serverのドキュメントを参照してください。

32.5.2 WebCenter Sitesとそのコンポーネントのパフォーマンス・メトリックの表示

Oracle WebCenter SitesまたはVisitor Servicesシステム・インストールのパフォーマンス・メトリックを表示するには:

1. Enterprise ManagerでのWebCenter Sitesとそのコンポーネントの起動に記載された手順を使用して、Oracle Enterprise Managerにログインします。

2. コンポーネント・メニューのオプションを表示するには、右側のペインでコンポーネント・サーバーをクリックします。

3. パフォーマンス・メトリックを表示するには、コンポーネント・メニューから「監視」→「パフォーマンス・サマリー」を選択します。「パフォーマンス・サマリー」ページが表示されます。デフォルトでは、「パフォーマンス・サマリー」ページには、最近の15分間のパフォーマンス・メトリックが表示されます。

4. 必要に応じて、ページの右上にある「スライダ」をクリックしてタイム・スライダを表示します。

タイム・スライダを使用すると、メトリックの表示対象となる期間を選択できます。

5. 必要に応じて、ページの右上の「スライダ」の横にある「時間の入力」アイコンをクリックします。

「時間の入力」ダイアログ・ボックスが表示されます。

6. メトリックの表示対象となる期間の開始時間と終了時間を入力し、「OK」をクリックします。

7. 右側のペインにある「メトリック・パレットの表示」をクリックします。「メトリック・パレット」が表示されます。

8. 「メトリック・パレット」で、「パフォーマンス・サマリー」ページに表示するメトリックを選択します。メトリックを表形式で表示するには、「表ビュー」を選択します。

Oracle WebCenter SitesまたはVisitor Servicesのメトリックの詳細は、次の各項を参照してください。

- WebCenter Sitesのパフォーマンス・メトリック

- Visitor Servicesのパフォーマンス・メトリック

32.5.2.1 WebCenter Sitesのパフォーマンス・メトリック

この項では、WebCenter Sitesのパフォーマンスを監視するためのメトリックについて説明します。次が含まれています。

- BlobServerサーブレットの詳細、ContentServerサーブレットの詳細およびSatelliteサーブレットの詳細

- キャッシュ詳細

- JDBC Info

- ThreadPool Info

- OS詳細

- エラー数

- NIOの詳細

- メモリーの詳細メトリック

- 接続メトリック

- ServerStateメトリック

32.5.2.1.1 BlobServerサーブレットの詳細、ContentServerサーブレットの詳細およびSatelliteサーブレットの詳細

メトリック名

説明

平均実行時間

最近のデプロイ以降に、サーブレットのすべての呼出しを実行するためにかかった時間の平均を表示します(ミリ秒単位)。

最長実行時間

最近のデプロイ以降に、サーブレットの単一の最長の呼出しが実行された時間の平均を表示します(ミリ秒単位)。

合計実行時間

最近のデプロイ以降に、サーブレットのすべての呼出しが実行された時間の平均を表示します(ミリ秒単位)。

呼出し総数

WebLogic Serverの起動後にサーブレットが呼び出された合計回数が表示されます。

32.5.2.1.2 キャッシュ詳細

メトリック名

説明

CacheHits

リクエストされたアイテムがキャッシュ内に見つかった回数です。

CacheHitsPercentage

リクエストされたアイテムがキャッシュ内に見つかったキャッシュ・アクセスのパーセンテージです。

CacheMisses

リクエストされたエレメントがキャッシュ内に見つからなかったキャッシュ・アクセスの数です。

CacheMissPercentage

リクエストされたエレメントがキャッシュ内に見つからなかったキャッシュ・アクセスのパーセンテージです。

MemoryStoreObjectCount

MemoryStoreにおけるオブジェクトの数です。

DiskStoreObjectCount

DiskStoreにおけるオブジェクトの数です。

32.5.2.1.3 JDBC Info

メトリック名

説明

ActiveConnectionsAverageCount

データ・ソースのこのインスタンスにおけるアクティブな接続の平均数。アクティブな接続とは、アプリケーションが使用中の接続のことです。

ActiveConnectionsCurrentCount

アプリケーションが現在使用中の接続の数。

ActiveConnectionsHighCount

データ・ソースのインスタンス化以降の、データ・ソースのこのインスタンスにおけるアクティブなデータベース接続の最大数。アクティブな接続とは、アプリケーションが使用中の接続のことです。

ConnectionDelayTime

データベースへの物理接続の作成に要する平均時間(ミリ秒)。この値は、接続にかかった総時間を接続の総数で除算して計算されます。

ConnectionsTotalCount

データ・ソースのデプロイ以降にこのデータ・ソースで作成されたデータベース接続の累計数。

MaxCapacity

この接続プールに含めることのできる物理データベース接続の最大数。JDBCドライバとデータベース・サーバーが異なると、可能な物理接続の数が制限される場合があります。

NumAvailable

データ・ソースのこのインスタンスにおいて、現在アイドル状態でアプリケーションが使用できるデータベース接続の数。

PrepStmtCacheAccessCount

文キャッシュがアクセスされた、現在の累積回数。

PrepStmtCacheAddCount

文キャッシュに追加された文の現在の累積数。接続プール内の接続ごとに、独自の文キャッシュが保持されます。この数は、接続プール内の各接続のキャッシュに追加された文の合計数です。

PrepStmtCacheCurrentSize

文キャッシュに現在キャッシュされているプリコンパイルされた文および呼出し可能文の数。接続プール内の接続ごとに、独自の文キャッシュが保持されます。この数は、接続プール内すべての接続のキャッシュにある文の数の合計です。

PrepStmtCacheDeleteCount

キャッシュから破棄された文の現在の累積数。接続プール内の接続ごとに、独自の文キャッシュが保持されます。この数は、接続プールのすべての接続のキャッシュから破棄された文の数の合計です。

PrepStmtCacheHitCount

キャッシュにある文が使用された、現在の累積回数。

PrepStmtCacheMissCount

キャッシュにある文で文リクエストを満たすことができなかった回数。

ReserveRequestCount

このデータ・ソースの接続に対するリクエストの現在の累積数。

32.5.2.1.4 ThreadPool Info

この項では、スレッド・プールに関連したメトリックについて説明します。

メトリック名

説明

completedRequestCount

WebCenter Sitesまたはそのコンポーネント・アプリケーションで処理されたリクエストの総数。

executeThreadIdleCount

現在アイドル状態である実行中スレッドの数。追加の未使用容量も示します。

executeThreadTotalCount

システム内で現在アクティブである実行中スレッドの総数。

pendingUserRequestCount

キューで処理を待機しているリクエストの数。理想的には、キュー内のリクエスト数は低く抑えてください。

queueLength

優先度キューにある、保留中リクエストの数。内部システム・リクエストとユーザー・リクエストの合計です。

stuckThreadCount

スタックしているスレッドの数。Weblogicでは、600秒以上作業が発生しない場合、スレッドがスタックしているとみなします。スタックしたスレッドは、システムにトラブルがある徴候です。

throughput

システム・スループット。

32.5.2.1.5 OS詳細

この項では、オペレーティング・システムに関連したメトリックについて説明します。

メトリック名

説明

commitedVirtualMemorySize

仮想メモリーのサイズ(MB単位)。

freePhysicalMemorySize

未使用物理メモリーのサイズ(MB単位)。

freeSwapSpaceSize

スワップ空間が使用できるメモリーのサイズ(MB単位)。

maxFileDescriptorCount

システム全体のファイル・ディスクリプタの最大数。

openFileDescriptorCount

システム全体の開いているファイル・ディスクリプタの数。

processCpuLoad

WebCenter SitesまたはそのコンポーネントをホスティングするJavaプロセスが使用するCPU時間。

systemCpuLoad

システム内のすべてのプロセス全体の総CPU使用率。

systemLoadAverage

CPUが使用できるようになるのを待機している処理待ち、またはストールしたタスクの数。これはシステム全体のメトリックであり、通常のシステムでは3未満に抑える必要があります。

totalPhysicalMemorySize

物理メモリー・サイズ(バイト単位)。

totalSwapSpaceSize

スワップ・メモリー空間(バイト単位)。

32.5.2.1.6 エラー数

この項では、エラーの数に関連したメトリックについて説明します。

メトリック名

説明

エラー数

実行中にアプリケーションに捕捉された例外の数。

32.5.2.1.7 NIOの詳細

この項では、NIOの詳細に関連したメトリックについて説明します。

メトリック名

説明

count

ノンブロッキングI/O (NIO)オブジェクト・カウント。

使用済メモリー

システムで使用されているメモリー(MB単位)。

合計容量

システムの合計メモリー(MB単位)。

32.5.2.1.8 接続メトリック

この項では、接続に関連したメトリックについて説明します。

メトリック名

説明

アクティブ・スレッド

システム内のアクティブ・スレッド数。

デーモン・スレッド

システム内のデーモン・スレッド数。デーモン・スレッドは、バックグラウンドで実行するスレッドです。

最大スレッド件数

システムに含まれるスレッドの最大数。

32.5.2.1.9 メモリーの詳細メトリック

この項では、メモリーの詳細に関連したメトリックについて説明します。

メトリック名

説明

使用可能なプロセッサ

システム内の使用できるプロセッサの数。

空きメモリー(バイト)

システムの空きメモリー(バイト単位)。

メモリー合計(バイト)

システムの合計メモリー(バイト単位)。

最大メモリー(バイト)

システムの最大メモリー(バイト単位)。

32.5.2.1.10 ServerStateメトリック

次の表に、Visitor Services ServerStateメトリックをリストします。

メトリック名

説明

状態

選択したコンポーネント・サーバーのステータス。サーバーを選択するには、「メトリック行の一覧表示」アイコンをクリックして、コンポーネント・サーバーを選択します。

32.5.2.2 Visitor Servicesのパフォーマンス・メトリック

この項では、Visitor Servicesを監視するパフォーマンス・メトリックについて説明します。次が含まれています。

- ThreadPool Info

- OS詳細

- エラー数

- NIOの詳細

- メモリーの詳細メトリック

- 接続メトリック

- ServerStateメトリック

32.5.2.2.1 ThreadPool Info

この項では、スレッド・プールに関連したメトリックについて説明します。

メトリック名

説明

completedRequestCount

WebCenter Sitesまたはそのコンポーネント・アプリケーションで処理されたリクエストの総数。

executeThreadIdleCount

現在アイドル状態である実行中スレッドの数。追加の未使用容量も示します。

executeThreadTotalCount

システム内で現在アクティブである実行中スレッドの総数。

pendingUserRequestCount

キューで処理を待機しているリクエストの数。理想的には、キュー内のリクエスト数は低く抑えてください。

queueLength

優先度キューにある、保留中リクエストの数。内部システム・リクエストとユーザー・リクエストの合計です。

stuckThreadCount

スタックしているスレッドの数。Weblogicでは、600秒以上作業が発生しない場合、スレッドがスタックしているとみなします。スタックしたスレッドは、システムにトラブルがある徴候です。

スループット

システム・スループット。

32.5.2.2.2 OS詳細

この項では、オペレーティング・システムに関連したメトリックについて説明します。

メトリック名

説明

commitedVirtualMemorySize

仮想メモリーのサイズ(MB単位)。

freePhysicalMemorySize

未使用物理メモリーのサイズ(MB単位)。

freeSwapSpaceSize

スワップ空間が使用できるメモリーのサイズ(MB単位)。

maxFileDescriptorCount

システム全体のファイル・ディスクリプタの最大数。

openFileDescriptorCount

システム全体の開いているファイル・ディスクリプタの数。

processCpuLoad

WebCenter SitesまたはそのコンポーネントをホスティングするJavaプロセスが使用するCPU時間。

systemCpuLoad

システム内のすべてのプロセス全体の総CPU使用率。

systemLoadAverage

CPUが使用できるようになるのを待機している処理待ち、またはストールしたタスクの数。これはシステム全体のメトリックであり、通常のシステムでは3未満に抑える必要があります。

totalPhysicalMemorySize

物理メモリー・サイズ(バイト単位)。

totalSwapSpaceSize

スワップ・メモリー空間(バイト単位)。

32.5.2.2.3 エラー数

この項では、エラーの数に関連したメトリックについて説明します。

メトリック名

説明

エラー数

実行中にアプリケーションに捕捉された例外の数。

32.5.2.2.4 NIOの詳細

この項では、NIOの詳細に関連したメトリックについて説明します。

メトリック名

説明

count

ノンブロッキングI/O (NIO)オブジェクト・カウント。

使用済メモリー

システムで使用されているメモリー(MB単位)。

合計容量

システムの合計メモリー(MB単位)。

32.5.2.2.5 接続メトリック

この項では、接続に関連したメトリックについて説明します。

メトリック名

説明

アクティブ・スレッド

システム内のアクティブ・スレッド数。

デーモン・スレッド

システム内のデーモン・スレッド数。デーモン・スレッドは、バックグラウンドで実行するスレッドです。

最大スレッド件数

システムに含まれるスレッドの最大数。

32.5.2.2.6 メモリーの詳細メトリック

この項では、メモリーの詳細に関連したメトリックについて説明します。

メトリック名

説明

使用可能なプロセッサ

システム内の使用できるプロセッサの数。

空きメモリー(バイト)

システムの空きメモリー(バイト単位)。

メモリー合計(バイト)

システムの合計メモリー(バイト単位)。

最大メモリー(バイト)

システムの最大メモリー(バイト単位)。

32.5.2.2.7 ServerStateメトリック

次の表に、Visitor Services ServerStateメトリックをリストします。

メトリック名

説明

状態

選択したコンポーネント・サーバーのステータス。サーバーを選択するには、「メトリック行の一覧表示」アイコンをクリックして、コンポーネント・サーバーを選択します。

第XI部 Oracle WebCenter Contentとの統合

次の各トピックでは、Oracle WebCenter Contentの統合(WCC統合)を有効化し、構成して、Oracle WebCenter ContentからOracle WebCenter Sitesへのコンテンツの同期をサポートする手順について説明します。

- WebCenter Content統合の理解

- コンテンツ同期の設定

- WCCコネクタ構成ファイルの使用

33 WebCenter Content統合の理解

この章では、WebCenter Content統合(WCC統合)の使用の前提条件について説明します。続いて、コンテンツ同期の計画、設定および管理を助ける基本概念について説明します。この章では、SitesIntegrationコンポーネントおよび「コネクタ管理者」タブという、2つのWCC統合部分の有効化についても説明します。

Oracle WebCenter Contentの統合機能(WCC統合とも呼ばれる)は、GUIで制御されるコネクタです。WebCenter Contentのコンテンツ・アイテムがWebCenter Sitesに同期され、そこでネイティブ・アセットとして管理されます。このアセットは、WebCenter Sitesで直接作成されたアセットと同様に編集、削除、プレビュー、リビジョン追跡、およびパブリッシュできます。

システムでコンテンツ同期を構成する前に、SitesIntegrationコンポーネントおよび「コネクタ管理者」タブを有効にする必要があります。各手順の詳細は、該当する後述の項を参照してください。

次の各トピックでは、WebCenter Contentの統合について説明します。

- WCC統合の管理の前提条件

- WebCenter Content統合の基本

- WebCenter Contentのデータ・モデル

- アセット・タイプのマッピングとコネクタ・ルール

- WebCenter Contentの統合とその要素

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

- 「コネクタ管理者」タブへのアクセスの有効化

33.1 WCC統合の管理の前提条件

WCC統合は、WebCenter ContentとWebCenter Sitesの知識を備えた、それらのデータ・モデルの使用に精通している管理者向けの機能です。コンテンツ・アイテム、レンディション、変換、およびWebCenter Contentで定義されたメタデータに関する明確な知識を持っている必要があります。WebCenter Sitesのアセット・タイプ、特にフレックス・ファミリについても十分理解している必要があります。作業の重要な部分では、コンテンツ・アイテム・メタデータをアセット・タイプ属性にマッピングします。アセット・タイプを作成する必要がある場合は開発者とコラボレートする必要があります。

WebCenterコンテンツの詳細は、『Oracle WebCenter Contentの使用』を参照してください。

33.2 WebCenter Contentの統合の基本

WCC統合では、WebCenter Contentとそのコンテンツ変換エンジンの変換機能が利用されます。具体的には、WCC統合は、WebCenter Contentのドキュメントおよびデジタル・アセット(イメージやビデオなど)をネイティブ・ファイル、レンディションおよびHTML変換としてWebCenter Sitesに同期するように設計されています。レンディションは、ネイティブ・ファイルのタイプおよび必要なレンディションに応じて、コア変換エンジンまたはDigital Asset Managerで作成できます。HTML変換はDynamic Converterによって生成されます。ファイル形式に制限はありません。コンテンツ変換の詳細は、『Oracle WebCenter Contentの使用』を参照してください。

WCC統合を有効化して設定する前に、WCC統合で最も重要ないくつかの概念についておさらいしておきましょう。この概念は、WCC統合機能とこのガイドの章全体を通して使用されます。ここでは、WebCenter Contentのデータ・モデル、そのWebCenter Sitesのアセット・タイプへのマッピング、およびWebCenter Contentのポーリング時にコネクタを誘導するよう構成するルールについて説明します。詳細は、WebCenter Contentのデータ・モデルおよびアセット・タイプのマッピングとコネクタ・ルールを参照してください。

33.3 WebCenter Contentのデータ・モデル

WebCenter Contentのデータ・モデルはコンテンツ・アイテムと呼ばれるオブジェクトに基づいており、ここにネイティブ・ファイル、そのレンディション、変換、および関連付けられたメタデータなどの情報が保持されます。

- ネイティブ・ファイルはユーザーによってWebCenter Contentで直接作成され、元の形式で保持されます。WCC統合の有効なネイティブ・ファイルは、ドキュメント(docxファイルなど)およびデジタル・アセット(イメージ・ファイルやビデオなど)です。

- レンディションは変換されたコンテンツ・アイテムです。レンディションはネイティブ・コンテンツの異なる形式を表します。コンテンツ変換エンジンによって生成されるファイルで、ネイティブ(元の)ファイルを格納するコンテンツ・アイテムに関連付けられます。
例:

- ネイティブ・ドキュメントは、コア変換エンジン(WebCenter Contentでデフォルトで使用可能)によってWeb上で見やすいWeb形式に変換できます。たとえば、Microsoft WordドキュメントをPDFファイルに変換します。このネイティブ・ドキュメントがプライマリ・レンディション、そのWeb表示可能なコピーがWebレンディションと呼ばれます。ネイティブ・ファイルとそのレンディションは同じコンテンツ・アイテムに含まれます。

- Digital Asset Managerは、ネイティブ・イメージ・ファイルとビデオを、異なるサイズと形式の複数のレンディションに変換できます。元のイメージ・ファイルがプライマリ・レンディションとすると、その小さいサムネイル・バージョンはスモール・サムネイル・レンディション、大きいサムネイル・バージョンはラージ・サムネイル・レンディションのように呼ばれます。

- HTML変換は、(Microsoft Wordなど)ネイティブ・ドキュメントの特別なレンディションです。このレンディションは、テキストとグラフィックの両方を含む単一のネイティブ・ドキュメントをHTMLレンディションに変換するDynamic Converterによって作成されます。レンディションは、(1)ネイティブ・ドキュメントのすべてのテキストを含むHTMLファイルと、(2)グラフィックスを表すイメージ・ファイルの集合で構成されます。

- コンテンツ・アイテムに関連付けられたメタデータは、アセット・タイプに関連付けられた属性と似ています。

初回実行時、WCCコネクタはネイティブ・ファイル、レンディション、変換、メタデータまたはそれらの組合せの最新リリース・バージョンをWebCenter Sitesにインポートします。インポートするコンテンツは、コネクタ・ルールとそれが指定するマッピングによって異なります。

その後、WebCenter Content上でコンテンツ・アイテムが変更されると、コネクタによって次回のセッション時にWebCenter Sitesに同期されます。更新されたコンテンツ・アイテムはWebCenter Sitesに再インポートされ、削除されたコンテンツ・アイテムは、その対応するアセットがWebCenter Sitesから削除されます(前回の同期セッション以降、それらのアセットへの依存性が作成されていない場合)。

インポートと同期は手動でトリガーすることも、時間に基づいて実行するようにスケジュールすることもできます。

同期は常にWebCenter ContentからWebCenter Sitesへの一方向です。WCC統合は、多対1のクライアント/サーバー・モデルをサポートします。任意の数のWebCenter Sitesクライアントを単一のWebCenter Contentインスタンスに接続できます。

33.4 アセット・タイプのマッピングとコネクタ・ルール

管理対象アイテムは、WebCenter Contentではコンテンツ・アイテムと呼ばれ、WebCenter Sitesではアセットと呼ばれます。

- WebCenter Contentのコンテンツ・アイテムには、それに関連付けられたメタデータがあります。

- WebCenter Sitesのアセットはアセット・タイプのインスタンスであり、それに関連付けられた属性があります。

WCC統合を使用する目的は、コンテンツ・アイテムをアセットとしてWebCenter Sitesにインポートし、コンテンツ・アイテムの更新に応じた同期を維持することです。同期が成功するかどうかは多くの要因に左右されますが、その大部分はターゲット・アセット・タイプに依存します。具体的には、コンテンツ・アイテム・メタデータのアセット・タイプ属性へのマッピング、ポーリング・セッションを通してコネクタで使用されるルール内のマッピングの構成、およびルールの優先順位の設定に依存します。

この項の内容は次のとおりです。

- アセット・タイプのマッピング

- コネクタ・ルール

33.4.1 アセット・タイプのマッピング

ターゲット・アセット・タイプは作成または再利用できます。どのアセット・タイプをいくつ使用するかはコンテンツの要件によって異なります。ただし、次の最小限の要件があります。

- ターゲット・アセット・タイプはフレックス・ファミリに属している必要があります。

- ターゲット・アセット・タイプは少なくとも次の属性タイプを保持している必要があります。

- WebCenter Contentで使用されるコンテンツ識別子メタデータ・フィールドにマップするコンテンツ識別子属性。詳細は、コンテンツ識別子属性を参照してください。

- インポートされたファイル(ネイティブ・ファイル、レンディション、変換またはそれらの任意の組合せ)を保持するためのコンテンツ記憶域属性。詳細は、コンテンツ記憶域属性を参照してください。

- アセットのプレビューが要件であること(一般のケース)を前提に、アセットのプレビューを有効にするためのテンプレート記憶域属性。
テンプレート属性を作成する場合は、テンプレート属性で説明しているように、動的に変換されたHTMLファイルとその参照先イメージをプレビューするためのテンプレート・コードに特に注意する必要があります。

- 残りの要件は各ユーザーのニーズに固有であり、管理者定義の仕様で概説しています。

33.4.1.1 コンテンツ識別子属性

WebCenter Contentでは各アイテムに一意のIDがあり、これはdDocNameという名前のデータベース・フィールドに格納されます(そして、「コンテンツID」フィールドに表示されます)。デフォルトでは、dDocNameはname属性にマップされます。WebCenter Sitesでアセットが作成されてコンテンツ・アイテムが格納されるたびに、そのコンテンツ・アイテムのdDocNameの値がname属性に記録されます。

dDocName(コンテンツID)はいくつかの方法で使用されます。この識別子を使用することで、WCCコネクタ(および管理者)は、アセットを追跡して対応するコンテンツ・アイテムを確認することができます。また、コンテンツ・アイテムがWebCenter Sitesに同期されているかどうかをコネクタで判断し、コンテンツ・アイテムの作成、更新または削除に応じたアセットの作成、既存アセットの更新または削除を実行できます。

ユーザー構成可能なパラメータで説明しているように、dDocNameのnameへのデフォルトのマッピングは変更できます。これは新しいシステムで、コネクタ・ルールが作成され最初の同期セッションが開始される前に1回のみ実行されます。

33.4.1.2 コンテンツ記憶域属性

コンテンツ・アイテムをファイルとしてWebCenter Sitesにインポートする場合は、ターゲット・アセット・タイプにファイルを受け入れるためのblob型属性(単一値または複数値のいずれか)が必要です。

動的に変換されるドキュメントにはいくつかの特別な処理が必要になります。これは、単一のネイティブ・ファイルのHTMLへの変換プロセスで複数のアーティファクトが生成されるためです。たとえば、テキストとグラフィックの両方を含む単一のMicrosoft Wordドキュメントは、(1)すべてのテキストを含むHTMLファイルと、(2)すべてのグラフィックを表すイメージ・ファイルの集合に変換されます。

HTMLとイメージ・ファイルは個別の属性にマップされます。HTMLファイルは単一値のblob型属性にマップされます。イメージ・ファイルは複数値のblob型属性にマップされます。テンプレート属性で説明しているように、アセットをプレビューするためのテンプレート属性とテンプレートを構成する必要もあります。

33.4.1.3 テンプレート属性

通常、WebCenter Sitesのアセット・タイプには、アセットのプレビューをサポートするテンプレート属性があります。

特別な注意が必要なテンプレート

動的に変換されるHTMLファイルのテンプレートには、次の理由から特別な注意が必要です。

動的に変換されるHTMLファイルには、WebCenter Content形式のイメージ・リンクが含まれます。例:

<img src="${wcmUrl('dcresource','20673.jpg')}"
width="360" height="270" alt="2007_06240117.JPG" />

WebCenter Sitesでは${wcmUrl('dcresource','20673.jpg')}のような形式は認識されないため、このリンクをblobリンクに変換する必要があります。リンク形式の変換は、WebCenter Sitesの配布ファイルの/misc/Samples/WCCディレクトリにあるWccConversionPreview.jspという名前のサンプル・テンプレートに例示されています。開発者はサンプル・テンプレートをそのまま使用することも、そのロジックの一部をそれぞれのテンプレートに組み込むこともできます。サンプル・テンプレートは、表33-1 に示すファイル記憶域属性の名前とともにハードコードされています。

表33-1 WccConversionPreview.jsp内の属性

属性名

データ型

html

blob

images

blob (M)

ターゲット・アセット・タイプの属性名がhtmlおよびimages以外の場合、開発者はサンプル・テンプレートWccConversionPreview.jspをターゲット・アセット・タイプ内で使用されている属性名で更新する必要があります。

33.4.1.4 管理者定義の仕様

コンテンツ識別子属性、コンテンツ記憶域属性およびテンプレート属性で説明した必須の属性に加えて、ターゲット・アセット・タイプへの同期に必要なメタデータ用の属性を追加するオプションが用意されています。

ターゲット・アセット・タイプは、必要な数のコンテンツ管理サイトで有効にできます。同期セッション時、コンテンツ・アイテムはコネクタ・ルールに指定されたすべてのサイトのターゲット・アセット・タイプに同期されます。コネクタ・ルールの詳細は、コネクタ・ルールを参照してください。

33.4.2 コネクタ・ルール

WCCコネクタには1つ以上のアクティブ(有効な)ルールが必要です。アクティブ・ルールがないと、コネクタはWebCenter Contentをポーリングできません。

アクティブ・ルールとは、コネクタが実行するときに従う必要のある、有効な一連の命令です。ルールはWebCenter Sitesで構成されて有効化されます。これには、WebCenter Content上でどのメタデータをポーリングするか、どのターゲット・アセット・タイプを、そのターゲット・アセット・タイプが有効になっているどのコンテンツ管理サイトで使用するか、コンテンツ・アイテム・メタデータをどのようにアセット・タイプ属性にマップするかなどの命令が含まれます。コネクタはマップを使用して、取得した情報を格納する属性を決定します。

コネクタ・ルールを計画して構成する際は、以降の情報を考慮して、コンテンツ・アイテムが予期したとおりに処理されるようにしてください。

- ルールおよびターゲット・アセット・タイプ

- アクティブ・ルールの優先順位の設定

- コンテンツ・アイテムのWebCenter Sitesへの再同期

- アクティブ・ルールの無効化および削除

- 追加の考慮事項

ルールおよびターゲット・アセット・タイプ

1つのコネクタ・ルールは、1つのターゲット・アセット・タイプのみ指定します。そのため、WebCenter Sitesに様々なコンテンツ・アイテムを同期する場合は複数のルールを作成することになります。例:

- 動的に変換されたHTMLファイルとその参照先イメージを単一のアセット・タイプにインポートする必要があるとします。この場合は、目的のターゲット・アセット・タイプを指定した単一のルールを作成し、HTMLファイルとそのイメージをhtml属性およびimages属性にマップします。

- Microsoft Wordドキュメントおよび関連のないPDFファイルをインポートする必要があるとします。アセット・タイプには、docxファイル専用のアセット・タイプとpdfファイル専用のアセット・タイプがあります。この場合は、docxファイルを最初のアセット・タイプに同期するルールとpdfファイルを2番目のアセット・タイプに同期するルールの2つのルールを作成します。

アクティブ・ルールの優先順位の設定

同じコンテンツ・アイテムをそれぞれ異なるアセット・タイプにマップする複数のアクティブ・ルールがある場合、コネクタではそのコンテンツ・アイテムに最初に一致したルールのみが実行されます。ルールの実行順序によって、どのコンテンツ・アイテムがどのアセット・タイプに同期されるかが決まります。

たとえば、surfing.jpg、surfing.pngおよびskiing.pngという名前の新しいアイテムがあるとします。さらに次の2つのアクティブ・ルールがあります。

- ルール1は、surfing.any_extensionアイテムをavisportsサイト上のImages_aviアセット・タイプにマップします。

- ルール2は、pngアイテムをFirstSite II上のImages_FSIIアセット・タイプにマップします。

表33-2 は、ルール1とルール2が異なる順序で実行されたときに、アイテムが2つのアセット・タイプに異なる方法で配布されることを示しています。目的の結果を得られるように、ルールに優先順位を設定する必要があります。

表33-2 アクティブ・コネクタ・ルールの順序により決定されるコンテンツの配布方法

アクティブ・ルール

Images_aviターゲット・アセット・タイプ

Images_FSIIアセット・タイプ

ルール1が最初に実行される場合

surfing.jpgとsurfing.pngがこのアセット・タイプにインポートされます

skiing.pngがこのアセット・タイプにインポートされます

ルール2が最初に実行される場合

surfing.jpgがこのアセット・タイプにインポートされます

surfing.pngとskiing.pngがこのアセット・タイプにインポートされます

コネクタはルールを使用して、コンテンツ・アイテムを次のようにWebCenter Sitesに同期します。

- コネクタは実行時、同期が有効な(または有効であった)新規および更新されたコンテンツ・アイテムを調べていきます。コネクタはコンテンツ・アイテムを、次のように一度に1つずつ調べていきます。
コンテンツ・アイテムのメタデータをルールのメタデータと比較します。一致するメタデータが見つからない場合は、次のアクティブ・ルールを使用して同じコンテンツ・アイテムを再テストします。

一致するメタデータが見つかった場合は、ルールに指定されたレンディションに一致するレンディションを検索してコンテンツ・アイテムのテストを続行します。検索が完了すると、コネクタは(一致するレンディションが見つかったかどうかに関係なく)WebCenter Sitesに戻ります。

- WebCenter Sitesでは、コネクタがデータベース上で次のように動作します。
ルールに指定されたターゲット・アセット・タイプを起動してアセットを作成し、ルールを使用してどのメタデータをどの属性にマップするか決定し、さらにメタデータ値とレンディション(ある場合)をアセットの属性にインポートします。

インポートしたコンテンツ・アイテムが同期されると、コネクタは、そのコンテンツ・アイテムに対する他のすべてのルールを省略し、次のコンテンツ・アイテムのテストに移動して、手順1を開始します。

コンテンツ・アイテムのWebCenter Sitesへの再同期

コンテンツ・アイテムは、WebCenter Sitesに同期された後は、WebCenter Content上で変更(更新または削除)された場合のみ再同期されます。

注意:

WebCenter Sitesに同期されたコンテンツ・アイテムがWebCenter Contentから削除された場合は、前回の同期セッション以降そのアセットに依存性が作成されていなければ、対応するアセットがWebCenter Sitesから削除されます。

アクティブ・ルールの無効化および削除

アクティブ・ルールが無効化または削除された場合、そのルールによってWebCenter Sitesにインポートされたコンテンツ・アイテムはWebCenter Sitesに残ります。無効化されたルールはコネクタで無視されます。

追加の考慮事項

ルールの作成および管理は、コンテンツ同期の設定の一部にすぎません。完全な手順では、最初にWCC統合のいくつかの要素を有効にしてから(1回のみ操作します)、コンテンツ同期をサポートするようにそれらを構成します。詳細は、WebCenter Contentの統合とその要素を参照してください。

33.5 WebCenter Contentの統合とその要素

WCC統合機能はいくつかの要素で構成されており、それらを最初に有効にしてからコンテンツ同期を設定および管理するように構成する必要があります。この要素は、SitesIntegrationコンポーネント、WCCコネクタ、およびコネクタを制御する「コネクタ管理者」タブです。

- SitesIntegration: インストール時にデフォルトでWebCenter Contentにインストールされるコンポーネントです。WCCコネクタをサポートする場合は有効にする必要があります。
SitesIntegrationコンポーネントを有効にすると、次の機能がWebCenter Contentに追加されます。

- 「サイトに同期化」オプション。このオプションはコンテンツのチェックイン・フォーム、更新フォームおよび検索フォームに表示されます。「True」に設定すると、コネクタでコンテンツ・アイテムを取得できるようになります。コンテンツが実際に取得され格納されるかどうかは、そのコンテンツが作成されたアクティブ・ルールの条件に一致するかどうかによって決まります。

- 「WCSキュー・サポート情報」。このグラフィカル・インタフェースは、各WebCenter Sitesクライアントのトークン履歴をリストします。トークン情報は、前の更新にロールバックするために使用できます。

SitesIntegrationコンポーネントの有効化の詳細は、SitesIntegrationコンポーネントの有効化を参照してください。

- WCCコネクタ: WebCenter Contentと通信するためにWebCenter Sitesにインストールされます。WebCenter Sitesのインストール時またはアップグレード時にインストールすることも、後からインストールすることもできます(前者をお薦めします)。WebCenter Contentをポーリングするようにコネクタを構成するには、WebCenter Sites Adminインタフェースにある「コネクタ管理者」タブを使用します。

- 「コネクタ管理者」タブ: コネクタを制御するために使用されるグラフィカル・インタフェースです。WCC統合がインストールされると、図33-1に示すように、WebCenter Sites Adminインタフェースのナビゲーション・ツリーに「コネクタ管理者」タブが追加されます。

図33-1 WCCの「コネクタ管理者」タブ

「コネクタ管理者」タブはコネクタを設定、実行および管理するために使用されます。たとえば、コネクタ・ルールの作成および有効化、WebCenter Contentへの接続の確立、コネクタの手動実行、コネクタ・アクティビティの監視、コネクタ履歴の表示およびトークン情報の取得を実行できます。

「コネクタ管理者」タブの有効化の詳細は、「コネクタ管理者タブへのアクセスの有効化」を参照してください。

33.6 SitesIntegrationコンポーネントの有効化

SitesIntegrationコンポーネントは、Oracle WebCenter Contentの完全インストールまたはアップグレード・プロセスでインストールされます。SitesIntegrationコンポーネントを有効にすると、次の機能がWebCenter Contentに追加されます。

- SiSyncToSitesメタデータ・フィールドがWebCenter Contentスキーマに追加され、コンテンツのチェックイン・フォーム、更新フォームおよび検索フォームに「サイトに同期化」オプションとして表示されます。

- 「WCSキュー・サポート情報」ページが追加され、WebCenter Sitesクライアントとそのトークン履歴がリストされます。同期が開始されると、同期されたコンテンツ・アイテムとそれらの更新履歴が同じページに記録されます。

SitesIntegrationコンポーネントを有効にするには:

1. WebCenter Contentで「コンポーネント・マネージャ」ページを開きます。

a. Contentインスタンスのポータル・ナビゲーション・バーで「管理」をクリックします。

b. 「管理サーバー」をクリックします。

2. 「コンポーネント・マネージャ」ページで次の手順を実行します。

a. 「統合」セクションまでスクロールダウンし、「SitesIntegration」チェック・ボックスを選択します。

b. 「更新」をクリックします。

注意:

コンポーネントの有効化の詳細は、『Oracle WebCenter Contentのインストールと構成』またはオンライン・ヘルプを参照してください。

3. WebCenter Contentを再起動します。

4. コンテンツのチェックイン・フォーム、更新フォームまたは検索フォームを開いて、図33-2に示すように、「サイトに同期化」チェック・ボックスが開いていることを確認します。

図33-2 コンテンツ・アイテムの更新フォームの「サイトに同期化」オプション

5. 「WCSキュー・サポート情報」ページの表示を確認します。

a. WebCenter Contentに管理者としてログインします。

b. 「管理」→「WCS管理」の順に選択して、「WCSキュー・サポート情報」ページを開きます(図33-3 )。

図33-3 WebCenter Contentサーバーの「WCSキュー・サポート情報」ページ

6. 「コネクタ管理者タブへのアクセスの有効化」に進みます。

33.7 「コネクタ管理者」タブへのアクセスの有効化

WCC統合を使用する必要がある人全員にConnectorAdminロールを割り当てる必要があります。唯一の例外については、次の「注意」を参照してください。

注意:

WebCenter Sitesのインストール・プロセスで資格証明が使用された一般管理者には、唯一ConnectorAdminロールが自動的に割り当てられます。その他の一般管理者を含むすべてのユーザーには、手動でロールを割り当てる必要があります。

ConnectorAdminロールによって「コネクタ管理者」タブへのアクセス権限が付与されます。権限を付与されたユーザー(通常は管理者)は、コネクタを制御して、ルールの作成と管理、WebCenter Contentとの通信の確立、コネクタの実行、そのアクティビティの監視、およびその履歴の表示などの操作を実行できるようになります。

「コネクタ管理者」タブへのアクセスを有効にするには:

1. 作業するコンテンツ管理サイトでWebCenter Sites Adminインタフェースを開き、「コネクタ管理者」タブ(図33-4 を参照)を見つけます。

図33-4 「コネクタ管理者」タブ

2. 「コネクタ管理者」タブが表示されない場合は、自分自身(および他のユーザー)にConnectorAdminロールを割り当てます。ロールを割り当てる手順は、ACLおよびロールの使用を参照してください。

3. Adminインタフェースからログアウトし、手順1と同じコンテンツ管理サイトにログインしなおします。

4. 「コネクタ管理者」タブがまだ表示されない場合は、WebCenter Sitesインストール・プロセスでWCC統合がインストールされていません。
次の手順を実行してWCC統合をインストールします。

a. 現在のインストールのすべてのカスタマイズをバックアップし、WCC統合オプションを有効にして、WebCenter Sites Configuratorを再度実行します。Configuratorの実行の詳細は、『Oracle WebCenter Sitesのインストールと構成』を参照してください。

図33-5 WebCenter Sitesインストーラ: WCC統合手順

b. インストーラがプロセスを完了したら、カスタマイズを復元し、この項の手順を繰り返して「コネクタ管理者」タブへのアクセスを有効にします。

34 コンテンツ同期の設定

この章では、コンテンツ・アイテムをWebCenter ContentからWebCenter Sitesにインポートし、コンテンツ・アイテムの更新に応じて2つのシステム間で同期を維持するようにシステムを設定する手順について説明します。必要なアイテムをアセットとしてインポートしたら、アセットの識別および操作についてコンテンツ・コントリビュータをサポートできます。詳しい手順は、次の各項で説明しています。さらに、この章では、ロールバック手順と同期トークンについて説明します。

注意:

この章の手順を開始する前に、次のことを実行してください。

- WebCenter Content統合の理解で、WebCenter Contentのデータ・モデルおよび構成するアセット・タイプとコネクタ・ルールの説明を読みます。

- SitesIntegrationコンポーネントの有効化と「コネクタ管理者」タブへのアクセスの有効化の手順がすべて完了していることを確認します。

- この章の内容を読んで、実行する手順について理解します。予備知識があると計画に役立ちます。

- 可能な場合は、コンテンツ同期を設定してテストするためのWebCenter Sitesテスト・システムを設定します。結果を確認し、必要に応じて調整を加え、実際のシステムで最終構成を再現します。

この章の内容は次のとおりです。

- コンテンツ・アイテムの同期の有効化

- 同期するレンディションの決定

- ターゲット・アセット・タイプの選択または作成

- WebCenter Contentへの接続

- アクティブ・ルールの作成

- アクティブ・ルールの優先順位の設定とルールの管理

- コネクタの手動実行

- コネクタの監視

- コネクタ履歴の表示

- インポートされたコンテンツの検証

- 設定を変更するには

- コネクタのスケジュール

- 同期されたアセットの管理

- 同期ポイントのロールバック

- 生成されたトークン値について

34.1 コンテンツ・アイテムの同期の有効化

一般に、コンテンツ・アイテムの同期はWebCenter Contentユーザーが有効化します。図34-1に示すように、各アイテムの「サイトに同期化」オプションが「True」に設定されます。有効なコンテンツ・アイテムはドキュメントとデジタル・アセットです。

図34-1 WebCenter Contentサーバーの更新フォームの「サイトに同期化」オプション

同期が有効なコンテンツ・アイテムはWCCコネクタで処理されます。ただし、コンテンツ・アイテムをWebCenter Sitesにインポートできるのは、WCCコネクタが、それらを正しいアセット・タイプにインポートできるよう有効化されている場合のみです。後続のいくつかの手順を実行することでコネクタを有効にします。同期するレンディションの決定に進みます。

34.2 同期するレンディションの決定

コンテンツ・アイテムの同期の有効化で同期を有効化したコンテンツ・アイテムは、レンディションを持っています。デフォルトのレンディション・タイプはprimaryおよびwebです。

- primaryレンディションは、WebCenter Contentにチェックインされたネイティブ(元の)ファイルです(レンディションが作成される前のMicrosoft Wordドキュメントなど)。

- コンテンツ・アイテムのwebレンディションは、ネイティブ・ファイルのWeb表示可能なバージョンです。たとえば、Microsoft WordドキュメントのPDFバージョンはWordドキュメントのwebレンディションです。

カスタム・レンディションを使用できる場合もあります。WebCenter Sitesにインポートするレンディションを決定する際は、WebCenter Sitesを操作するサイト・デザイナに問い合せてください。コネクタ用のレンディションは、後続の手順(WebCenter Contentへの接続)で指定します。

ターゲット・アセット・タイプの選択または作成に進みます。

34.3 ターゲット・アセット・タイプの選択または作成

手順は次のとおりです。

- ターゲット・アセット・タイプが次の同期要件を満たしていることを確認します。

- アセット・タイプがアセット・タイプのマッピングで概説した最小要件に適合している。たとえば、フレックス・ファミリに属している必要があります。

- コンテンツ・アイテムの同期の有効化で有効化されたコンテンツ・アイテムを受け入れるように設定されていること。

- dDocNameメタデータ・フィールドのデフォルトのマッピングを(name以外の属性に)変更するには、ここでwcc-integration.iniファイルのwcc.keyfieldパラメータをリセットします。パラメータがリセットされて同期が開始されたら、この値は再編集しないでください。
dDocNameの詳細は、コンテンツ識別子属性を参照してください。wcc.keyfieldパラメータの詳細は、ユーザー構成可能なパラメータを参照してください。

- アセット・タイプにテンプレート属性がある場合は、そのテンプレートの表示名をWebCenter Sites Adminインタフェースで表示されているとおりに正確にコピーしてテキスト・ファイルに貼り付けます。このテンプレート名は、WebCenter Contentへの接続でコネクタ・ルールを構成する際に使用します。

34.4 WebCenter Contentへの接続

この項では、WebCenter SitesをWebCenter Contentに接続して、コネクタ・ルールの属性マッピングで使用可能にする必要のあるレンディション(同期するレンディションの決定で決定)を指定します。

WebCenter Contentに接続するには:

1. 「コネクタ管理者」タブで、「構成」を選択して「コネクタ構成」フォーム(図34-2 )を開きます。

図34-2 サンプル値の入力された「コネクタ構成」フォーム

2. 「コネクタ構成」フォームで、次のフィールドに値を入力します。

a. 「サーバーURL」フィールドに、接続先のWebCenter Contentインスタンスのアドレスを入力します。HTTP、HTTPSまたはIDCプロトコルを使用できます。WebCenter ContentインスタンスのURLパスの決定方法の詳細は、『Oracle WebCenter Contentの管理』を参照してください。

b. 「サーバー・ユーザー」フィールドに、WebCenter Contentインスタンスの管理権限を持つユーザーの名前を入力します。

注意:

「サーバーURL」フィールドにIDCプロトコルを指定した場合は、管理権限を持つローカル・ユーザーとして定義された名前を入力する必要があります(デフォルトはsysadmin)。

c. 「サーバーURL」フィールドにHTTPまたはHTTPS接続を指定した場合のみ、「サーバー・パスワード」フィールドに管理ユーザーのパスワードを入力します。

注意:

IDC接続の場合、サーバーのパスワードは必要ありません。IDCプロトコルは、WebCenter Contentサーバーに構成された信頼できるポートを使用します。

d. 「レンディション名」フィールドに、(同期するレンディションの決定で決定した)インポートするすべてのレンディションの名前を追加します。
レンディションを追加するには、「新しいレンディションの追加」をクリックして名前を入力します。ビデオ・レンディションを追加する場合は、media:rendition-nameなどのコロン区切り形式を使用します(図34-3を参照)。たとえば、media:flash8のように指定します。

図34-3 ビデオ・レンディションの例

レンディション・タイプprimaryおよびwebはデフォルトで入力されています。要件に応じて、保持または削除できます。

3. 「テスト」をクリックしてエントリをテストします。エントリが有効な場合は、確認メッセージが表示されます。

4. 「保存」をクリックして、エントリを保存します。構成が保存されると、確認メッセージが表示されます。

5. アクティブ・ルールの作成に進みます。

34.5 アクティブ・ルールの作成

アクティブ・ルールとは、実行時に従う必要のある、コネクタに対して有効な一連の命令です。コネクタは、アクティブ・ルールを使用して次のことを実行します。

1. コンテンツ・アイテムの同期の有効化で有効化されたコンテンツ・アイテムをサンプリングして、アクティブ・ルールに一致するアイテムを取得します。

2. ターゲット・アセット・タイプの選択または作成で選択または作成してアクティブ・ルールに指定されたターゲット・アセット・タイプの受信アセットを作成します。

3. WebCenter Contentへの接続およびアクティブ・ルールで指定されたレンディションを同期します。

注意:

ルールを作成する前に、計画および構成のガイドラインについてコネクタ・ルールを読んでください。

ルールは、(この手順で)作成する際に、または後の手順(アクティブ・ルールの優先順位の設定とルールの管理)で有効化できます。

ルールを作成するには::

1. 「コネクタ管理者」タブで「ルール」を選択します。

2. 「コネクタ・ルール」フォームで「新規ルールの追加」をクリックします。

3. ルール・ウィザードが開きます。次の手順に従ってルール・ウィザードを実行します。

ルール・ウィザード: 手順1 名前

ルールに名前を付けて説明を追加し、ルールを有効にします。

1. ルールの名前を入力します(必須)。英数字とハイフンのみ使用できます。

2. ルールの説明を入力します(必須)。

3. 「有効」オプションを選択して、このルールを有効にします。

注意:

「有効」オプションを選択しなければルールはアクティブ化されず、コネクタで実行されません。アクティブ・ルールの優先順位の設定とルールの管理で説明しているように、ルールはいつでも現在のウィザードまたは「コネクタ・ルール」フォームから有効または無効にできます。

4. ルール・ウィザード: 手順2 ルールに進みます。

ルール・ウィザード: 手順2 ルール

コンテンツ・アイテムの同期の有効化で有効化したコンテンツ・アイテムをポーリングする際にコネクタでのサンプリングが必要なメタデータを指定するルール文を設定します。

ルール・ウィザードのこの手順では、メタデータの名前を選択し、演算子を選択して、メタデータ値を指定します。AND/OR文を追加することで、複数のメタデータの名前と値を指定できます。

図34-4 手順2: サンプル値の入力された「ルール」ページ

コネクタでのサンプリングが必要なメタデータを指定するには::

1. 左側のリストで、メタデータの名前を選択します。
リストには、WebCenter Contentに定義されているすべてのメタデータ名が表示されます。メタデータの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

共通のメタデータ名には、次のものがあります。

- dDocName: WebCenter Contentのコンテンツ・アイテムのコンテンツID。

- dDocType: WebCenter Contentのコンテンツ・アイテム・タイプ。

- dDocTitle: WebCenter Contentのコンテンツ・アイテム・タイトル。

- dExtension: WebCenter Contentのファイル拡張子(txt、doc、pdf、jpgなど)。

- xComments: WebCenter Contentのコメント・フィールド。

2. 中央のリストで、演算子を選択します。

- 次と一致する: コネクタは右側のフィールドに入力された文字列全体と一致するメタデータ値を検索します。たとえば、文がdDocType matches imageの場合、コネクタはimageを認識しますが、imagesは認識しません。

- 次を含む: コネクタは右側のフィールドに入力されたメタデータ値の部分文字列検索を実行します。たとえば、文がdDocName contains abcの場合、コネクタはabc、abcde、およびabcを含むその他のdDocNameをすべて認識します。

- 次で始まる: コネクタは右側のフィールドに入力された文字列で始まるメタデータ値を検索します。

- 次で終わる: コネクタは右側のフィールドに入力された文字列で終わるメタデータ値を検索します。

- が次の値より大きい: 整数のみに適用されます(文字列の場合は無効)。

- が次の値より小さい: 整数のみに適用されます(文字列の場合は無効)。

3. 右側のフィールドに、選択したメタデータ・フィールドの値を入力します。

4. 必要な数だけOR文を追加します。

5. 必要な数だけAND文を追加します。

6. ルール・ウィザード: 手順3 ターゲットに進みます。

ルール・ウィザード: 手順3 ターゲット

ターゲット・アセット・タイプ、アセット・タイプを有効にするコンテンツ管理サイト、および入力が必要なその他の情報を選択します。

注意:

この手順のコンテンツは、アセット・タイプに応じて異なります。

ターゲット・アセット・タイプと、それを有効にするコンテンツ管理サイトを指定するには::

1. リストからターゲット・アセット・タイプを選択します。
選択するアセット・タイプに応じて異なるオプションがフォームに表示されます。

2. アセット・サブタイプを選択します。

3. リストから親を有効にします。

4. 「サイト」リストで、選択したアセット・タイプを有効にするコンテンツ管理サイトを指定します。1つ以上のサイトを選択します。コネクタは、コンテンツ・アイテムとメタデータを、選択されたすべてのサイト上のターゲット・アセット・タイプにインポートします。

5. 必要なその他の情報を入力します。

6. ルール・ウィザード: 手順4 属性に進みます。

ルール・ウィザード: 手順4 属性

同期が有効なコンテンツ・アイテム(コンテンツ・アイテムの同期の有効化で指定)のメタデータをターゲット・アセット・タイプの属性にマップします。

ステップ4。ルール・ウィザード(図34-5)の属性ページには、属性名と、「手順3 ターゲット」で選択したアセット・タイプにおけるデータ型がリストされます。赤いアスタリスクが付いている属性は必須です。データ・タイプが(M)を含む属性は、複数値属性です。そのような属性には、単一の値か、セミコロン(;)で区切った複数の値を含めることができます。例: value1;value2;。

図34-5 手順4: サンプル値の入力された「属性」ページ

コンテンツ・アイテム・メタデータをアセット・タイプ属性にマップするには::

属性ごとに「次から取得」列へ移動して、リストからオプションを選択します。オプションは属性タイプによって異なります。オプションは次のとおりです。

- 「リテラル」または「メタデータ」: これらのオプションはblob以外のタイプの属性のみに適用されます。

- 「リテラル」を選択した場合は、「値」列に標準テキスト文字列を入力します。選択した属性は、このルールでインポートするすべてのコンテンツ・アイテムに同じテキストを表示します。
また、次の点にも注意してください。

- アセット・タイプにテンプレート属性がある場合は、WebCenter Sites Adminインタフェースに表示されているとおりのテンプレート名を「値」列に入力してください。名前をコピーして「値」列に貼り付けることをお薦めします(ターゲット・アセット・タイプの選択または作成でテキスト・ファイルに貼り付けた名前を使用できます)。

- dateタイプの属性(たとえば、startdateやenddateという名前の属性)の場合、「リテラル」を選択すると、日付ピッカーを使用して日付を選択できます。

- 「次から取得」列のリストから「メタデータ」を選択した場合、「値」列からメタデータ名を選択します。

注意:

「メタデータ」を選択した場合、「値」列のリストには、ターゲットとしている属性のデータのタイプに一致するメタデータ・フィールドがリストされます。たとえば、属性がdateタイプの場合、「値」列にはdateタイプのメタデータ・フィールドのみがリストされます。メタデータ・タイプの詳細は、『Oracle WebCenter Contentサービス・リファレンス』を参照してください。

- 「レンディション」または「変換」: これらのオプションはblob タイプの属性のみに適用されます。

- 「次から取得」列のリストから「レンディション」を選択した場合は、「値」列から目的のレンディション・タイプ(たとえば、web、primaryまたはその他のレンディション・タイプ)を選択します。

注意:

「レンディション」を選択した場合、「値」列のリストにはWebCenter Contentへの接続の「コネクタ構成」フォームで指定したレンディション・タイプの名前のみがリストされます。

- 「次から取得」列のリストから「変換」を選択した場合、「値」列から変換タイプを選択します。オプションは「html」と「イメージ」のみです(「変換」はHTML変換のみに使用するオプションです)。
たとえば、HTML変換をインポートするために、次のようなマップを作成できます(ターゲット属性がHTMLおよびImagesという名前であるとします)。

- 表34-1 属性マップ・エントリ

属性

型

次から取得

値

HTML

blob

変換

html

Images

blob (M)

変換

images

ルール・ウィザード: 最終手順:

1. ツールバーの「保存」アイコンをクリックして、ルールをWebCenter Sitesデータベースにコミットします。

注意:

ルール・ウィザード: 手順1 名前で「有効」オプションを選択しなかった場合、ルールは保存されます、有効化されていません。「コネクタ・ルール」フォームから、いつでも有効または無効にできます。アクティブ・ルールの優先順位の設定とルールの管理を参照してください。

2. 必要に応じて追加ルールを作成します。

3. アクティブ・ルールの優先順位の設定とルールの管理に進みます。

34.6 アクティブ・ルールの優先順位の設定とルールの管理

ルールを管理するうえで重要な点に、それらをコネクタに対して有効にし、実行の優先順位を設定することがあります。この順位によって、同期セッション時、コネクタがコンテンツ・アイテムをターゲット・アセット・タイプ間で配布する方法が決まります。優先順位の設定の詳細は、コネクタ・ルールを参照してください。

ルールの編集、削除、追加などのその他の操作も、ルールを有効化して優先順位を設定する同じフォームで実行できます。

ルールに優先順位を設定したりルールを管理したりするには::

1. 「コネクタ管理者」タブで、「ルール」を選択して「コネクタ・ルール」フォームを開きます。

図34-6 サンプル・ルールの指定された「コネクタ・ルール」フォーム

2. コネクタのルールに優先順位を設定するには、この手順を続行します(それ以外の場合は、「コネクタ・ルール」フォームの編集や削除などのルール管理オプションについて説明している手順3に進みます)。

a. 優先するルールの「有効」チェック・ボックスが選択されていることを確認します。

b. ルールの順序を変更するには、「上に移動」または「下に移動」矢印を使用します。有効化されたルールが、設定された順序でコネクタによって実行されます。コンテンツ・アイテムがいずれかのアクティブ・ルールに一致すると、そのルールに従って同期化されます。当該コンテンツの同期に関するその他のルールはすべて無視されます。

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

3. 「コネクタ・ルール」フォームに表示される操作を実行するには、次のリストで操作の説明を参照してください。

- ルールを編集するには、そのルールの「編集」アイコン(鉛筆)をクリックします。ルール・ウィザードが開きます。ルールの構成方法の詳細は、アクティブ・ルールの作成を参照してください。

- ルールを削除するには、そのルールの「削除」アイコン(ゴミ箱)をクリックします。

- ルールの順序を変更するには、「上に移動」または「下に移動」矢印を使用します。有効化されたルールが、設定された順序でコネクタのポーリング時に実行されます。コンテンツ・アイテムがいずれかのアクティブ・ルールに一致すると、そのルールに従って同期化されます。当該コンテンツの処理に関するその他のルールはすべて無視されます。

- ルールを有効化または無効化するには、そのルールの「有効」オプションを選択または選択解除します。変更後、「保存」をクリックします。

注意:

- ルールが無効な場合、そのルールとそれに一致するコンテンツ・アイテムは、実行時にコネクタによって無視されます。

- アクティブ・ルールが実行され、その後無効化(または削除)された場合でも、そのルールに従ってインポートされたコンテンツ・アイテムはWebCenter Sitesに残ります。

- ルールを表示または編集するには、「名前」列でそのルールの名前をクリックします。ルール・ウィザードが開きます。

- 「説明」列にはルールの説明が示されます。この説明はルールの作成時に定義されます。

- 新しいルールを追加するには、「新規ルールの追加」をクリックします。ルール・ウィザードが開きます。

- ルールの有効化または無効化などの変更を保存するには、「保存」をクリックします。

4. アクティブ・ルールの最適化、有効化および優先順位の設定が完了したら、コネクタの手動実行に進みます。

34.7 コネクタの手動実行

この手順では、コネクタを手動で実行し、アクティブ・ルールの作成で構成してアクティブ・ルールの優先順位の設定とルールの管理で優先順位を設定したルールをテストします。

コネクタを実行するには::

1. 「コネクタ管理者」タブで、「コンソール」を選択して「コネクタ・コンソール」を開きます。

図34-7 サンプル・サーバー情報の指定されたコネクタ・コンソール

2. コネクタ・コンソールにWebCenter Contentへの接続で指定した情報が開きていることを確認します。

- 「サーバーURL」フィールドには、WebCenter Contentインスタンスのアドレスがリストされます。

- 「サーバー・ユーザー」フィールドには、WebCenter Contentインスタンスの管理権限を持つユーザーがリストされます。

3. 「トークンを使用して今すぐ実行」をクリックします。

コネクタの実行が開始され、現在のトークン値がトークン・フィールドに表示されます。トークンの詳細は、同期ポイントのロールバックを参照してください。

注意:

コネクタのスケジュールで説明しているように、時間に基づいて実行するようにコネクタをスケジュールできます。

4. コネクタの実行中は、現在使用している同じフォームでそのアクティビティを監視できます。詳細は、コネクタの監視を参照してください。

34.8 コネクタの監視

コネクタの実行時は、図34-8 に示すように、(前の手順で移入した)「コネクタ・コンソール」に「最近のアクティビティ」表が表示されます。

図34-8 「最近のアクティビティ」表が表示された「コネクタ・コンソール」フォーム

「最近のアクティビティ」表には直近24時間以内のアクティビティが一度に10行ずつリストされます。最新の情報を提供するには、表を手動でリフレッシュする必要があります。各行が1つのバッチを表しています。デフォルトでは、コネクタはコンテンツ・アイテムをバッチで処理します(バッチ当たり最大50アイテム)。ユーザー構成可能なパラメータで説明しているように、バッチ・サイズは変更できます。

1. コネクタがコンテンツ・アイテムをWebCenter Sitesにインポートしているかどうかを判別するには、表を更新して「更新済」列を確認します。

次に「最近のアクティビティ」表のすべてのオプションと統計について説明します。

- 表を更新するには、「リフレッシュ」をクリックします。

- 「取消」をクリックすると現在実行中のコネクタが取り消されます。次のバッチ(ある場合)の処理が取り消される点に注意してください。現在のバッチは完了まで処理されます。

- 「このアイテムの調査」アイコン(虫メガネ)をクリックすると、選択したバッチのコネクタ履歴が表示されます。詳細は、単一バッチのコネクタ履歴の表示を参照してください。

- 「タイムスタンプ」列にはバッチ処理の日付と時間が表示されます。

- 「起動者」列には、バッチ処理が名前付きユーザーによって(「コネクタ・コンソール」から)手動で起動されたか、あるいはSystemEvents表のコネクタ・スケジュールによって自動で起動されたか(AUTO)がリストされます。コネクタ・スケジュールの詳細は、コネクタのスケジュールを参照してください。

- 「状態」列にはバッチ処理の状態がリストされます。リストされる値には、「送信済」、「実行中」、「取消済」、「エラー」、「リセット」または「終了」があります。「リフレッシュ」をクリックすると最新の状態が表示されます。この表は自動更新されません。

- 「バッチ・サイズ」列にはバッチのアイテム数がリストされます。デフォルトでは、バッチ当たり最大50アイテムです。最大バッチ・サイズの変更方法の詳細は、WCCコネクタの構成ファイルを参照してください。

- 「更新済」列には、バッチ処理時にWebCenter Sitesで更新されたアイテム数がリストされます。この数には、作成、更新または削除されたアセットが含まれます。

- 「ルールなし」列には、アクティブ・ルールに一致しなかったコンテンツ・アイテムの数がリストされます。

- 「エラー」列には、このバッチの処理エラー数がリストされます。

2. (すべてまたは選択したバッチで)コネクタの履歴を表示することで、コネクタのアクティビティに関する追加情報を収集できます。コネクタ履歴の表示に進みます。

同期化されたアセットを検査して、それらが意図したアセット・タイプに格納されていることを確認する場合は、インポートされたコンテンツの検証に進みます。

34.9 コネクタ履歴の表示

コネクタ・セッションはすべてアーカイブされます。アーカイブ全体または選択したバッチを(1つずつ)表示できます。処理の詳細な情報を得るために、個々のコンテンツ・アイテムまで絞り込むこともできます。アーカイブされた情報は削除できます。

この項の内容は次のとおりです。

- コネクタ履歴全体の表示

- 単一バッチのコネクタ履歴の表示

34.9.1 コネクタ履歴全体の表示

すべてのバッチのコネクタ履歴を表示するには::

1. 「コネクタ管理者」タブで、「履歴」を選択して「コネクタ履歴」表を開きます。

図34-9 サンプル・アクティビティの表示された「コネクタ履歴」表

2. 「コネクタ履歴」表には次の情報とオプションが表示されます。

- 「コネクタ履歴」表の各行は1つのバッチを表しています。デフォルトでは、コネクタはコンテンツ・アイテムをバッチで処理します(バッチ当たり最大50アイテム)。

- 「このアイテムの調査」アイコン(虫メガネ)をクリックすると、選択したバッチのコネクタ履歴が表示されます。詳細は、単一バッチのコネクタ履歴の表示を参照してください。

- 「タイムスタンプ」列にはバッチ処理の日付と時間が表示されます。

- 「起動者」列には、バッチ処理が名前付きユーザーによって(「コネクタ・コンソール」から)手動で起動されたか、あるいはSystemEvents表のコネクタ・スケジュールによって自動で起動されたか(AUTO)がリストされます。コネクタ・スケジュールの詳細は、コネクタのスケジュールを参照してください。

- 「状態」列にはバッチ処理の状態がリストされます。リストされる値には、「送信済」、「実行中」、「取消済」、「エラー」、「リセット」または「終了」があります。「リフレッシュ」をクリックすると最新の状態が表示されます。

- 「バッチ・サイズ」列にはバッチのアイテム数がリストされます。デフォルトでは、バッチ当たり最大50アイテムです。最大バッチ・サイズの変更方法の詳細は、WCCコネクタの構成ファイルを参照してください。

- 「更新済」列には、バッチ処理時にWebCenter Sitesで更新されたアイテム数がリストされます。この数には、作成、更新または削除されたアセットが含まれます。

- 「ルールなし」列には、アクティブ・ルールに一致しなかったアイテムの数がリストされます。

- 「エラー」列には、このバッチの処理エラー数がリストされます。

- すべてのアクティビティ・リストを削除するには、「すべて」オプションを選択し、続いて「削除」をクリックします。

- バッチ(行)を選択して「削除」をクリックすると、そのバッチが削除されます。

3. 単一のバッチのコネクタ履歴を表示するには、そのバッチを選択します。「コネクタ履歴」表にそのバッチで処理されたすべてのアイテムがリストされます。単一バッチのコネクタ履歴の表示の図に示す例を参照してください。

34.9.2 単一バッチのコネクタ履歴の表示

単一バッチのコネクタ履歴を表示するには:

1. 「コネクタ管理者」タブで、「履歴」を選択して「コネクタ履歴」表を開きます。

2. バッチ(行)を見つけ、「調査」アイコン(虫メガネ)をクリックします。

「コネクタ履歴」表に、選択したバッチで処理されたすべてのアイテムがリストされます。

3. 単一バッチの「コネクタ履歴」表には次の情報とオプションが表示されます。

- 各行はバッチ内の単一のアイテムを表します。

- 「コンテンツID」列にはバッチ内の各アイテムのコンテンツIDがリストされます。

- 「アセットID」列にはバッチ内の各アイテムのアセットIDがリストされます。

- 「ステータス」列にはバッチ内の各アイテムの同期ステータスがリストされます。共通のステータス・フラグは、Added、Error、Updated、Not Matched(一致するルールがない)、Not Present(アセットが見つからない)およびDeleted(アセットは削除済)です。

- 「注釈」列には、バッチ内の各アイテムに関する追加情報が示されます。「詳細の表示」アイコン(プラス記号)または「詳細の非表示」アイコン(マイナス記号)を切り替えます。共通で返されるメッセージの例と説明は、手順4を確認してください。

- 「戻る」ボタンをクリックすると、前の表(すべてのバッチの履歴を表示)に戻ります。

4. 図34-10は、「注釈」列に表示されるメッセージの例を示しています。より包括的なリストは、図の下に記載されています。

図34-10 「注釈」列に詳細を示す単一バッチのコネクタ履歴

次に、共通メッセージの一部を紹介します。

- 「有効なルールが見つかりません」: ルールが定義されていないか、定義されたルールが無効であることを示しています。

- 「レコードが見つかりません」: データベース表でレコードが見つからない、つまり、特定の表に表示するエントリがないことを示しています。

- 「QueueToken {0}の削除 」: 値{0}はトークンIDです。このメッセージは、WebCenter Contentのアイテムが、WebCenter Sitesから削除する対象としてマークされていることを示しています。

- 「アセット{0}はサイト{1}から削除されました」: 値{0}はassetType_assetIDです。値{1}はサイト名です。このメッセージは、リストされたアセットが指定されたコンテンツ管理サイトから削除されたことを示しています。

- 「アセットが削除されました」: アセットが削除されたことを示しています。

- 「アセットが見つかりません」: このメッセージは通常、削除するアイテムの検索時、そのアイテムが削除されていたことを意味しています。

- 「サイト: {2}に対するアセットが作成されました: {0:1}」: 値{0:1}はアセット・タイプとアセットIDです。値{2}はサイト名またはサイト名のカンマ区切りリストです。このメッセージは、リストされたアセットがリストされたサイトで作成されたことを示しています。

- 「サイト: {2}に対するアセットが更新されました: {0:1}」: 値{0:1}はアセット・タイプとアセットIDです。値{2}はサイト名またはサイト名のカンマ区切りリストです。このメッセージは、リストされたアセットがリストされたサイトで更新されたことを示しています。

- 「理由: {2}のため、サイト{1}からのアセット{0}の削除に失敗しました」: 値{0}はアセットIDです。値{1}はサイト名です。値{2}は、削除が失敗した理由に関するメッセージです。通常、削除が失敗するのは、アセットが前回の同期以降に変更され、現在そのアセットを参照しているためです。削除に失敗した場合は、そのアイテムが「親がないコンテンツ」フォームにリストされます(詳細は、同期されたアセットの管理を参照してください)。

- 「QueueToken {0}のチェックイン」: 値{0}はトークンIDです。このメッセージは、キュー・トークン・チェックイン・リクエスト、つまり、新規または更新済アイテムをWebCenter ContentからWebCenter Sitesにインポートする準備が整っていることを示しています。

- 「ルールは{0}に一致しました。WCCリクエスト: {1}」: 値{0}はルール名です。値{1}は、ルールの属性マッピング・セクションで要求されたWebCenter Contentレンディションまたは変換です。

- 「一致するルールはありません」: アイテムに一致するルールがないことを示しています(「有効なルールが見つかりません」と比較してください)。

- 「ルールは{0}に一致しましたが、マッピングが見つかりません」:値{0}はルール名です。このメッセージは、ルールがWebCenter Contentからインポートされるアイテムに一致したが、メタデータと属性のマッピングが見つからなかったことを示しています。

- 「レンディション{0}は返されませんでした」: 値{0}はレンディション名です。このメッセージは、WebCenter Contentが、リクエストされたレンディションを戻さなかったことを示します(多くの場合、レンディションがなかったため)。使用可能なレンディションと「リクエストされたレンディションは使用できません」を比較してください。

- 「使用可能なレンディション: {0}」: 値{0}は、WebCenter Content上で使用可能なアイテムのレンディションのリストです。

- 「リクエストされたレンディションは使用できません」: リクエストされたレンディションがないことを示します。使用できるレンディションのリストは、使用可能なレンディションを参照してください。

- 「フィールド{0}、fieldDef: {1}でエラーが発生しました: {2}」: 値{0}および{1}は属性名(値は同一)です。値{2}は例外のエラー・メッセージです。このメッセージは、コネクタがコンテンツ・アイテム・メタデータ・フィールドを属性にマッピング中に不明または予期しない例外が発生したときに戻されます。

5. 同期の定期的な実行を自動化する前に、インポートされたコンテンツを検証して、それが意図したアセット・タイプに予期した詳細レベルで格納されていることを確認します。インポートされたコンテンツの検証に進みます。

34.10 インポートされたコンテンツの検証

ここまでの操作で、コンテンツ同期の動作について理解できたと思います。確認のため、インポートされたコンテンツ・アイテムを検査して、それらが意図したアセット・タイプに格納されていること、すべてのメタデータ値が正しい属性で記録されていること、そしてルールの属性マッピング部分で指定したその他のすべての条件が満たされていることを検証します。コンテンツ・アイテムおよびアセットを見つけるには、「コネクタ履歴」表でコンテンツIDとそれに対応するアセットIDを参照します。

検証が完了したら、次のいずれかを実行します。

- 調整が必要な場合は、設定を変更するにはに進みます。

- 要件が満たされている場合は、次の項に進みます。

- コネクタのスケジュール

- 同期されたアセットの管理

34.11 設定を変更するには

同期セッションの結果が要件を満たしていない場合にシステム構成を調整する方法はいくつかあります。そのオプションを次に示します。

- この章で説明したいくつかの手順に戻って、たとえば、より多くのコンテンツ・アイテムの同期を有効化したり、コンテンツ・アイテムを無効にしたり、ルールを変更したり、あるいはアクティブ・ルールの優先順位を再設定したりすることができます。

注意:

アクティブ・ルールの変更または優先順位の再設定を選択する場合、先に、同期済アセットをWebCenter Sitesから削除します。アセット・タイプをクリアすると、コネクタの再実行後に、同期結果の解釈が単純化されます。決定に応じて、同期ポイントを元の開始ポイントまたは特定の更新にロールバックするための準備も行われます。

- wcc-integration.iniファイルを使用して、最大バッチ・サイズなどの様々なパラメータを再構成します。詳細は、WCCコネクタの構成ファイルの使用を参照してください。

- トークンをリセットすることで、同期ポイントを元の開始ポイントまたは特定の更新にロールバックできます。

注意:

トークンをリセットする場合は、コネクタによって新しい同期ポイントのすべてのコンテンツ・アイテムが再検査され、WebCenter Sitesに再同期されます。

ロールバックする前に、同期されたアセットをWebCenter Sitesから削除してシステムを準備します。この手順は、ターゲット・アセット・タイプの変更、コンテンツ管理サイトの変更、またはルールの優先順位の再設定のいずれかによってコネクタ・ルールが変更された場合に特に重要です。アセットが削除された後、トークンをリセットできます。トークンの詳細は、同期ポイントのロールバックを参照してください。

設定を変更したら、次の項に進みます。

- コネクタのスケジュール

- 同期されたアセットの管理

34.12 コネクタのスケジュール

コンテンツ同期を構成して検証したら、時間に基づいて実行するようにコネクタをスケジュールできます。Explorerユーティリティを使用して、SystemEvents表に時間指定エントリを追加します。

注意:

Oracle WebCenter Sites Explorerは、Windowsのみのユーティリティです。

コネクタをスケジュールするには::

1. 配布ファイルのSitesExplorerディレクトリのあるOracle WebCenter Sites Explorer実行可能ファイル(ContentServerExplorer.exe)を起動します。

2. Oracle WebCenter Sites Explorerにログインします。(ログイン資格証明の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。)

3. Oracle WebCenter Sites Explorerで、次を実行します。

a. Tablesノードを展開します。

図34-11 表ノードが開かれているExplorer

b. SystemEvents表を選択します(図34-11 を参照)。

c. メイン・メニューから、「ファイル」→「新規」→「レコード」の順に選択します。

d. 次の情報を入力して、WCCコネクタのスケジュール・イベントを定義します。

- eventname: WCCConnector

- タイプ: 1

- 有効化: 1

- times: 現時点ではこのフィールドは空白のままにしておきます。手順eで設定します。

- target: ContentServer

- params: pagename=WCC/Pull

e. 次の形式でtimesフィールドに時間パターンを入力することで、コネクタを実行するスケジュールを定義します。

h:m:s W/D/M

時間パターンの各フィールドとそれらの有効な値を表34-2 に示します。次の表は時間パターンの一例です。

表34-2 SystemEvents表の時間パターンのフィールド

フィールド

有効な値

すべての有効な値

単一値の形式

包含範囲の形式

リスト・フォーマット

h (時間)

0–23

*

h

h-h

h,h

m (分)

0–59

*

m

m-m

m,m

s (秒)

0–59

*

s

s-s

s,s

W (曜日)

0–6 (0=日曜日)

*

W

W-W

W,W

D (日付)

0–31

*

D

D-D

D,D

M (月)

1–12

*

M

M-M

M,M

時間パターンの例:

2,5-7:0:0 5/*\/*

最初のフィールド、2,5-7:0:0 は、時間のカンマ区切りリストで、範囲も含まれています。これは、イベントが2 AM、5 AM、6 AMおよび7 AMの、それぞれ0 分0 秒に起動されることを意味します。次のフィールド(5/)は、イベントが毎週金曜日に起動されるよう指定しています。次のフィールド(*\)は、イベントがどの日も起動されないようにしています。最後のフィールド(/*)は、イベントがどの月も起動されることを保証します。

曜日(WD)および日付(DD)フィールドの片方または両方を使用して、日を指定します。両方を指定すると、両方が反映されます。たとえば、1:0:0 1/15/*は、イベントが毎週月曜日と各月の15日の午前1時0分0秒にトリガーされることを意味しています。1つのフィールドのみで日付を指定するには、他のフィールドを*に設定します。

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

5. 同期されたアセットの管理に進んで、同期されたアセットをコンテンツ・コントリビュータが識別および管理するうえで役立つ情報を参照してください。

34.13 同期されたアセットの管理

必要なコンテンツ・アイテムをWebCenter Sitesにインポートしたら、特に同期セッションを定期的に実行する場合など、同期されたアセットの識別および管理についてコンテンツ・コントリビュータをサポートします。パブリッシュを行う管理者およびコンテンツ・コントリビュータも、アセットが同期セッションにどのように影響されるかを理解しておく必要があります。

次の各トピックでは、同期されたアセットに関する情報を提供します。

- マップ済属性

- 親がないコンテンツ

34.13.1 マップ済属性

コンテンツ・コントリビュータが、コネクタ・ルールの属性マッピング部分で明示的にマップされた属性の値を変更することでアセットを変更した場合、それらの値は、コンテンツ・アイテムが更新され再同期された時点で更新されます。その他のすべての属性には、それぞれの値が保持されます。

注意:

マップされた属性の値が変更された場合は、そのコンテンツ・アイテムが更新され再同期された時点で値が上書きされます。マップされた属性への変更を保持するには、アセットをコピーする必要があります。

34.13.2 親がないコンテンツ

同期で実行でないタスクの1つに、依存性のある同期化されたアセットの削除があります。これにより、親がないコンテンツが生じます。

親がないコンテンツとは、対応するコンテンツ・アイテムが同期で削除されたか、(「サイトに同期化」オプションを「False」に設定して)無効化されたか、あるいは期限切れになったときに削除できないアセットです。親がないアセットは、前回の同期セッション以降、そのアセットに依存性が作成されているため削除できません。

注意:

同期されたアセットがコンテンツ管理サイト全体で共有されている場合は、依存性がないかぎり削除されます。

親がないアセットを判別するには::

1. WebCenter Sites Adminインタフェースで、「コネクタ管理者」タブを開きます。

2. 「親がないコンテンツ」を選択し、「コネクタの親がないコンテンツ」表を開きます。

「コネクタの親がないコンテンツ」表には、削除されたソースのコンテンツ・アイテム、親がないアセットおよびそれらの依存アセットを示す列が表示されます。

- 「コンテンツID」列には、WebCenter Contentの同期において削除または無効化されたコンテンツ・アイテムのコンテンツIDがリストされます。

- 「コネクタ・トークン」列には、トークンのupdate_numberがリストされ、これに基づいてコンテンツ・アイテムがコネクタによって処理された日時を導出できます。同期ポイントのロールバックで説明しているように、日時は「WCSキュー・サポート情報」表から取得できます。

- 「アセットID」列には、親がないアセットがWebCenter SitesアセットIDによってリストされます。

- 「参照元」列には、(親がないアセットを参照している)依存アセットがリストされます。

- 「注釈」列には、親がないアセットの追加情報(ある場合)がリストされます。

3. 「コネクタの親がないコンテンツ」表を使用して、WebCenter Content内の親がないアセットを見つけます。削除されたコンテンツ・アイテムの詳細は、WebCenter Contentで確認できます。

34.14 同期ポイントのロールバック

WebCenter SitesおよびWebCenter Contentは生成されたトークンを介して同期され、コンテンツ同期プロセスが確立された後は、このトークンはほとんどリセットされません。

注意:

トークンは、システムの設定時に、同期関連オブジェクト(ルールなど)を構成、テストおよび再構成する場合にのみリセットしてください。システムが実稼働に向けて構成された後は、トークン値を変更しないでください。

ただし、システムの設定時、ルールまたはアセット・タイプの再構成に応じて、同期ポイントを元の開始ポイントまたは特定の更新にロールバックする必要が生じることがあります。ロールバックにはトークンのリセットが含まれます。

この項では、トークンのリセットについて説明する前に、トークンの詳細と、トークンがWebCenter ContentおよびWebCenter Sitesの間でどのように更新されるかについて簡単に説明します。

1. WebCenter Contentに初めて接続する際、WebCenter SitesはWebCenter Contentからトークンを受け取ります。トークン値の形式は次のとおりです。

トークン値の形式:

ClientID:Internally_used_database_identifier:update_number

例:

c10013:1344632434389:10012

2. 更新を確認する際、WebCenter SitesはこのトークンをWebCenter Contentに渡し、update_numberを使用して前回のコール以降に変更が行われたかどうかを判断します。更新には、「サイトに同期化」オプションが有効な(または有効であった)コンテンツ・アイテムが含まれます。更新が行われた場合、WebCenter Contentは新しいupdate_numberを生成し、更新されたトークンをWebCenter Sitesに返します。

次に説明するように、トークン値を元の値(元の同期ポイント)または特定の更新にロールバックできます。

注意:

確立されたコンテンツ同期プロセスのトークンはリセットしないでください。

- トークン値を空の値で置き換えると、同期ポイントが元の開始ポイントにロールバックされます。コネクタの次回実行時、「サイトに同期化」オプションが有効な(または以前有効であった)すべてのコンテンツ・アイテムが再調査されて再同期されます。

注意:

コネクタで、以前有効であった(現在は「サイトに同期化」オプションが有効でない)コンテンツ・アイテムを再調査するのは、念のために、対応するアセットをWebCenter Sitesから削除する必要がないかどうか確認するためです。

- トークンのupdate_numberを以前生成されたupdate_numberで置き換えると、同期ポイントが以前の更新にロールバックされます。コネクタの次回実行時、コンテンツ・アイテムのバージョンが新しい同期ポイントでポーリングされます。「サイトに同期化」オプションが有効な(または以前有効であった)すべてのコンテンツ・アイテムが再調査されて再同期されます。コネクタで、以前有効であった(現在は「サイトに同期化」オプションが有効でない)コンテンツ・アイテムを再調査するのは、念のために、対応するアセットをWebCenter Sitesから削除する必要がないかどうか確認するためです。

トークン値とupdate_numbersの履歴は、WebCenter Contentの「WCSキュー・サポート情報」ページで確認できます。

トークン値の詳細は、生成されたトークン値についてを参照してください。

この項には次のトピックが含まれます:

- 元の開始ポイントへのロールバック

- 特定の更新へのロールバック

34.14.1 元の開始ポイントへのロールバック

トークンを空の値にリセットすると、現在の同期ポイントが元の開始ポイントにロールバックされます。

元の開始ポイントに再同期するには::

1. WebCenter Sites Adminインタフェースで、「コネクタ管理者」タブを開きます。

2. 「コンソール」を選択します。

3. 「コネクタ・コンソール」フォーム(図34-12 )で、トークン値(「次のトークンで実行」ボタンの横)を削除します。

図34-12 「コネクタ・コンソール」フォーム

34.14.2 特定の更新へのロールバック

トークンのupdate_numberを以前生成された値にリセットすると、現在の同期ポイントがその特定の更新にロールバックされます。

特定の更新にロールバックするには::

1. ロールバックするトークン値を検索します。

a. WebCenter Contentに管理者としてログインします。

b. 「管理」→「WCS管理」の順に選択します。
「WCSキュー・サポート情報」ページが開きます(図34-13 )。

図34-13 WebCenter Contentサーバーの「WCSキュー・サポート情報」の表

c. ページ上部に「WCSキュー・サポート情報」の表が表示されます。「QueueId」 列(「コンテンツID」に相当)を調べて、更新されたアイテムを見つけます。「トークン」列を調べ、アイテムのupdate_numberを取得します。

2. WebCenter Sitesでトークン値をリセットします。

a. WebCenter Sites Adminインタフェースで、「コネクタ管理者」タブを開きます。

b. 「コンソール」を選択して「コネクタ・コンソール」フォームを開き、トークンのupdate_number(前回の数値セット)を新しいupdate_numberで置き換えます。

34.15 生成されたトークン値について

生成されたトークン値には3つの部分があります。各部分はコロン(:)で区切られています。

ClientID:Internally_used_database_identifier:update_number

この項では、次の例を使って各部分について説明します。

c10013:1344632434389:10012

- トークン値の最初の部分はClientIDです(例ではc10013)。
この値は、WebCenter Sitesクライアントの初回接続時にWebCenter Contentによって生成されます。この値はクライアントに返され、クライアントでそれ以降のすべてのコールに使用されます。空のトークンで再接続すると、クライアントは新しいClientIDを取得します。

- トークン値の中央部分はWebCenter Contentのデータベース表の一意の識別子です(例では1344632434389)。

注意:

トークン値の中央の部分は、編集しないでください。クライアント/サーバー再同期のために内部的に使用されます。

- トークン値の最後の部分はupdate_numberです(例では10012)。
WebCenter Contentは、次のようにコンテンツ・アイテムにupdate_numberを生成します。

- 新しくチェックインされたコンテンツ・アイテムの「サイトに同期化」オプションが有効な場合、そのコンテンツ・アイテムはupdate_numberを受け取ります。アイテムのコンテンツIDとupdate_numberはWCSキュー表に記録されます。その情報は、アイテムが削除された後も表に保持されます。

- コンテンツ・アイテムの「サイトに同期化」オプションが有効な場合、そのコンテンツ・アイテムは新しいupdate_numberを受け取り、その値がWCSキュー表に記録されます。記録された情報は、コンテンツ・アイテムが削除された後も常に表に残ります。

- コンテンツ・アイテムが更新されるか、その「サイトに同期化」オプションがリセットされると、そのコンテンツ・アイテムは新しいupdate_numberを受け取り、その値がWCSキュー表に記録されます。

- 「サイトに同期化」オプションが有効であったコンテンツ・アイテムが削除されると、そのコンテンツ・アイテムは新しいupdate_numberを受け取ります。アイテムは削除されますが、そのContentIdと新しいupdate_numberはWCSキュー表に残ります。これにより、削除されたコンテンツの通知が提供されるようになります。

35 WCCコネクタ構成ファイルの使用

次の各トピックでは、WCC統合機能によって使用される構成ファイルについて説明し、ユーザー設定可能なパラメータが含まれるwcc-integration.iniに関する詳細な情報を提供します。

- WCCコネクタの構成ファイルについて

- ユーザー構成可能なパラメータ

35.1 WCCコネクタの構成ファイルについて

WCCコネクタの構成ファイルは、WebCenter Sitesインストールの/Shared/clustersynch/ucm/iniディレクトリにある複数のINIファイルで構成されています。編集の必要な唯一のファイルはwcc-integration.iniファイルで、ユーザー構成可能なパラメータで説明しているように、WCCコネクタの状態の最適化およびトラブルシューティングに使用されます。

注意:

次の構成ファイルは編集しないでください。これらはデータ・ストレージ用に内部で使用されます。

- wcc-matchers.ini: WebCenter Sitesの「コネクタ管理者」タブでルール・ウィザードを使用して作成されたルール文が含まれます。各ルールは名前別にリストされ、有効または無効によって識別されます。ここには、そのルールの説明と文のロジックも含まれます。このファイルはwcc-mappers.iniファイルと対になっています。

- wcc-mappers.ini: ルール・ウィザードで定義されたルールの詳細が含まれます。このファイルはwcc-matchers.iniファイルと対になっています。

- wcc-token.ini: サーバーがWebCenter Sitesと同期された最終時刻を示す、WebCenter Contentから受け取ったトークンが含まれます。

35.2 ユーザー構成可能なパラメータ

wcc-integration.ini構成ファイルには、ユーザー構成可能ないくつかのシステム・パラメータが含まれています。これらのパラメータは、WebCenter Sites Adminインタフェースでは構成できません。

wcc-integration.ini構成ファイルはWebCenter Sitesインストールの/Shared/clustersynch/ucm/iniディレクトリにあり、次の例に示すとおり、Javaプロパティ・ファイル形式を使用しています。

#wcc-integration.ini
wcc.batch.size=50
wcc.batch.autorepeat=true
wcc.download.dir=C\:\\Oracle\\WebCenter\\Sites\\tomcat\\temp
wcc.download.autoclean=true
wcc.keyfield=name
wcc.rule.case-sensitive=true

これらのパラメータはユーザー構成可能であり、次のように定義されます。

- wcc.batch.size=[50]
大量のコンテンツをバッチで処理する場合、このパラメータがバッチの最大サイズを指定します。

wcc-integration.ini構成ファイルの作成時、デフォルトのバッチ・サイズは50に設定されます。この値は変更できますが、パラメータを空白のまま残すことはできず、有効な値を入力する必要があります。

- wcc.batch.autorepeat=[true | false]
コネクタの実行時、処理アイテムの合計数がwcc.batch.sizeパラメータに定義した数を超える応答を受信した場合に、バッチの処理後にコネクタを自動的に再実行するか(true)、次の手動実行または予定された実行まで待機するように(false)、コネクタを設定できます。

wcc-integration.ini構成ファイルの作成時、このパラメータはデフォルト値のtrueに設定されます。この値は変更できますが、パラメータを空白のまま残すことはできず、有効な値を入力する必要があります。有効な値はtrueまたはfalseです。

- wcc.download.dir=[temporary_zip_file_location]
このパラメータは、WebCenter Contentから転送されたZIPファイルの一時ダウンロード場所を定義します。

- wcc.download.autoclean=[true | false]
このパラメータは、処理の完了後にZIPファイルを削除するかどうかを定義します。これは、一時ファイルを強制的にクリーンアップするか(true)、ファイルを分析用にディスクに残しておく(false)デバッグ・パラメータです。

wcc-integration.ini構成ファイルの作成時、このパラメータはデフォルト値のtrueに設定されます。この値は変更できますが、パラメータを空白のまま残すことはできず、有効な値を入力する必要があります。有効な値はtrueまたはfalseです。

- wcc.keyfield=[name]
このパラメータは、WebCenter ContentのdDocNameメタデータ・フィールドの値を受け取るアセット・タイプ属性の名前を指定します。デフォルトでは、wcc.keyfieldの値はnameです。これは、nameがすべてのアセット・タイプで使用可能なデフォルト属性であるためです。この値を変更することは一般的ではありません。

新しいシステムでは、ルールが作成されコンテンツ同期が開始される前に、1回これを変更できます。同期が開始されたら、この値は編集しないでください。編集すると、アセットが重複することがあります。デフォルト値を変更する状況の例として、nameフィールドが使用されている場合があります。dDocNameの詳細は、コンテンツ識別子属性を参照してください。

- wcc.rule.case-sensitive=[true | false]
このパラメータは、コネクタ・ルールに指定された文字列メタデータ値とコンテンツ・アイテムの実際のメタデータ値を比較するために使用されます。パラメータがtrueに設定されている場合、大文字と小文字の区別が有効になります。

wcc-integration.ini構成ファイルの作成時、このパラメータはデフォルト値のtrueに設定されます。有効な値はtrueまたはfalseです。

第XII部 リファレンス

次の各トピックでは、WebCenter Sitesデータベース、システム・デフォルトおよびLDAPサーバーを使用するサイト管理など、WebCenter Sitesのリファレンス情報を提供します。データベース情報は、特にデータベース内の動的な表を参照します。システムのデフォルト情報では、日常的に使用されるデフォルト・データ(たとえばACL、ロール、アセット・タイプおよびツリー・タブ)について説明します。

- システム・デフォルト

- WebCenter Sitesのデータベース表

- LDAP統合Sitesシステムでのユーザー、サイト、およびロール

- 代替パブリッシュ方法

36 システム・デフォルト

この章では、日常的に使用するWebCenter Sitesのシステム・デフォルトについて説明します。

この章の内容は次のとおりです。

- ACL

- システムACLとその権限

- デフォルト・ユーザーのACL

- カスタム・ユーザー用の必須のACL

- システム・ロール

- システム・アセット・タイプ

- デフォルトのツリー・ノード

36.1 ACL

WebCenter Sitesとそのアプリケーションは、複数のデフォルトACLを使用して、各機能に対するユーザー・アクセスを制御します。この項では、ACLで指定できる権限をまとめ、デフォルトのシステムACLについて説明します。

この項の内容は次のとおりです。

- 権限

- ACLへのアクセス

36.1.1 権限

ACLによって一連の権限を指定します。ACLをデータベース表に割り当てると、データベース表ではACLで指定された権限のみを行使できるようになります。これらの権限を行使できるのは、表と同じACLを持つユーザーのみです。

表36-1に、ACLで指定できるすべての権限をリストします。

表36-1 WebCenter Sitesによってサポートされる権限

権限

ビット・マスク(注1参照)

アクション

読取り

1

表からデータを読み取ります。

書込み

2

表に情報を書き込みます。(注2参照)

作成

4

表を作成します。

削除

8

表から情報を削除します。

取得

16

URL列(アップロード・フィールドとも呼ばれている)のコンテンツを取得します。URL列の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

リビジョン追跡監査

32

追跡される表の行(レコード)のすべてのリビジョン追跡情報にアクセスします。

リビジョン追跡管理

64

表に対してリビジョン追跡を割り当てるか削除します。

注意:

1. ACLが作成されると、ACLに割り当てられている各権限のビット・マスク番号が相互に加算され、その合計がSystemACL表にACLとともに表示されます。

2. 表に行を追加するには、作成権限が必要です。

36.1.2 ACLへのアクセス

ACLとその権限は、リストまたは個別のエントリとしてアクセスできます。

- ACLとその権限のリストを取得するには、SystemACL表を直接開きます。

- 個別のACLとその権限を取得するには、次のように管理者インタフェースを使用します。

1. 「管理」タブで、「ユーザー・アクセス管理」を開き、「ACL」をダブルクリックします。

2. ドロップダウン・メニューで、作業対象のACLを選択します。

3. 「ACLの修正」を選択し、「OK」をクリックします。

注意:

デフォルトのシステムACLは変更できません。システム表に割り当てられているSCLは変更できません。

システムACLの詳細は、システムACLとその権限を参照してください。

36.2 システムACLとその権限

表36-2はシステムACLとその権限を示します。各システムACLは、データベース表の特定の部分や、さらに、これらの表を使用する製品機能へのアクセスを制御するために存在しています。デフォルトACLの多くは同じ権限のセットを持っていますが、これらのACLは別々の表に割り当てられるものなので、すべて必要です。

表36-2 システムACLとその権限

ACL名

読取り

取得

書込み

作成

削除

リビジョン追跡監査

リビジョン追跡管理

Browser

あり

なし

なし

なし

なし

なし

なし

ContentEditor

あり

あり

あり

あり

あり

あり

なし

ElementEditor

あり

あり

あり

あり

あり

あり

なし

ElementReader

あり

なし

なし

なし

なし

なし

なし

PageEditor

あり

あり

あり

あり

あり

あり

なし

PageReader

あり

なし

なし

なし

なし

なし

なし

RemoteClient

あり

あり

あり

あり

あり

あり

あり

SiteGod

あり

あり

あり

あり

あり

あり

あり

TableEditor

あり

あり

あり

あり

あり

あり

なし

UserEditor

あり

あり

あり

あり

あり

あり

なし

UserReader

あり

なし

なし

なし

なし

なし

なし

Visitor

あり

あり

あり

あり

あり

あり

なし

VisitorAdmin

あり

あり

あり

あり

あり

あり

あり

WsAdmin

なし

なし

なし

なし

なし

なし

なし

WSEditor

なし

なし

なし

なし

なし

なし

なし

WSUser

なし

なし

なし

なし

なし

なし

なし

xceladmin

あり

あり

あり

あり

あり

あり

あり

xceleditor

あり

あり

あり

あり

あり

あり

なし

xcelpublish

あり

あり

あり

あり

あり

あり

なし

表36-3は、各ACLの機能と、Oracle WebCenter SitesおよびWebCenter Sitesコンテンツ・アプリケーションによる各ACLの使用方法を示しています。

表36-3 システムACLとその説明

ACL名

説明

Browser

WebCenter Sitesデータベース内のコンテンツに対して読取り専用アクセスを許可します。システム・デフォルトとサンプル・サイトのユーザーのほとんどに割り当てられます。

WebCenter Sitesでは、管理するオンライン・サイトへのすべての訪問者にユーザー・アカウントが必要です。このため、WebCenter SitesはDefaultReaderという名前のデフォルトのユーザー・アカウント付きで配信されます。これはすべての認証されていないユーザー、つまり独自のユーザー・アカウントを持たないユーザーに割り当てられます。

Browser ACLはDefaultReaderユーザー・アカウントに割り当てられます。このユーザー・アカウントによって、認証されていない訪問者にはWebCenter Sitesデータベースのコンテンツに対する読取り専用アクセス権が付与されます。

ContentEditor

サンプルのWebCenter Sitesサイトで使用されます。

このACLは、サンプル・サイトをサポートする表に割り当てられます。

ElementEditor

ユーザーがElementCatalog表とSystemSQL表にデータを書き込めるようになります。

サイト・デザイナや、テンプレート、CSElementおよびSiteEntryアセットの作成者には、このACLが必要です。

ElementReader

ユーザーがElementCatalog表とSystemSQL表のデータを読み取れるようになります。

WebCenter Sitesユーザーが、そのアセットに割り当てられたテンプレートを調査できるようにするには、このACLが必要です。

PageEditor

ユーザーがSiteCatalog表にページ・エントリを作成できるようになります。

サイト・デザイナや、テンプレート、CSElementまたはSiteEntryアセットの作成者には、このACLが必要です。

PageReader

ユーザーがSiteCatalog表からエントリを読み取れるようになります。

WebCenter Sitesユーザーが、そのアセットに割り当てられたテンプレートを調査できるようにするには、このACLが必要です。

RemoteClient

リモート・クライアントを介して、ユーザーがWebCenter Sites管理システムにログインできるようになります。

SiteGod

WebCenter Sitesデータベースのすべての表に完全にアクセスできます。

管理システムの少なくとも1人のユーザー(通常は管理者)に、SiteGod ACLが必要です。

TableEditor

ユーザーがWebCenter Sitesデータベースの表を作成および削除できます。

データベース表を作成したり、(表の作成を引き起こす)アセット・タイプを作成するサイト・デザイナには、このACLが必要です。

管理者や、ミラーリング先の初期化機能を使用するその他のユーザーにも、このACLが必要です。

UserEditor

ユーザーがユーザー・アカウントを管理できるようになります。

管理者にはこのACLが必要です。

UserReader

WebCenter Sitesによってユーザー・アカウント情報を認識できるようにします。WebCenter SitesはこのACLを使用して、どのユーザーがどのサイト上でどのロールを持っているのか確認します。割当て先のコンテンツ管理サイトにアクセスできるようにするため、すべてのユーザーにこのACLが必要です。

Visitor

ユーザーが、訪問者データが格納されているOracle WebCenter Sites: Engage表にデータを書き込んで、推奨アセットを作成できるようにします。

- 推奨アセットを作成する必要のあるEngageユーザーはすべて、このACLが必要です。

- 配信システム上でそのデータが収集されている(Engageアセットの)認可された訪問者は、このACLがユーザー・アカウントに割り当てられている必要があります。

- オンライン・サイトの認可されていない訪問者にはすべて、このACLが(DefaultReaderユーザー・アカウントで)自動的に割り当てられます。DefaultReaderアカウントの詳細は、DefaultReader、secure.CatalogManagerおよびsecure.TreeManagerの理解を参照してください。

VisitorAdmin

ユーザーが訪問者属性、履歴属性、履歴タイプを作成できるようにします。これらのタイプのアセットを作成する必要のあるEngageユーザーはすべて、このACLが必要です。

WSUser

Webサービス機能のSiteCatalogページ・エントリに割り当てられます。ユーザーがWebCenter SitesのWebサービスによりWebCenter Sitesにアクセスできるようにします。

WSEditor

Webサービス機能のSiteCatalogページ・エントリに割り当てられます。ユーザーがWebCenter SitesのWebサービスによりWebCenter Sitesにアクセスできるようにします。

WSAdmin

Webサービス機能のSiteCatalogページ・エントリに割り当てられます。ユーザーがWebCenter SitesのWebサービスによりWebCenter Sitesにアクセスできるようにします。

xceladmin

ユーザーがユーザー・プロファイル、ロール、サイト、アセット・タイプなどを作成できるようにします。つまり、「管理」、「サイト管理者」、「ワークフロー」の各タブのすべての機能を使用できるようにします。

システム管理者、サイト管理者およびワークフロー管理者にはこのACLが必要です。また、「管理」タブには管理機能とサイト設計機能の両方が含まれているので、サイト・デザイナにもこのACLが必要です。

xceleditor

ユーザーがWebCenter Sitesコンテンツ・アプリケーションにログインできます。ログイン・リクエスト・コードによって、ユーザーがこのACLを持っているかどうかが検証されます。

管理システムのすべてのユーザーに、このACLが必要です。

xcelpublish

ユーザーがパブリッシュ・コンソールを表示できるようにします。

36.3 デフォルト・ユーザーのACL

表36-4は、どのACLがデフォルト・ユーザーに割り当てられるかを示しています。

表36-4 デフォルト・ユーザーとそのACL

ユーザー名

Browser

説明

fwadmin

Browser

ElementEditor

PageEditor

PageReader

RemoteClient

TableEditor

UserEditor

UserReader

Visitor

VisitorAdmin

xceladmin

xceleditor

xcelpublish

wsadmin

wseditor

wsuser

WebCenter Sitesコンテンツ・アプリケーションの構成を開始できるようにするためにWebCenter Sitesによって作成される基本的な管理者ユーザー。

同一のACLを持つ別のユーザーが存在する状態になるまで、このユーザーを削除しないでください。

WebCenter Sites

(インストールのユーザー・アカウント)

Browser

ContentEditor

ElementEditor

ElementReader

PageEditor

PageReader

SiteGod

TableEditor

UserEditor

UserReader

製品のインストール時にインストール・プログラムによって作成されるユーザー・アカウント。

このアカウントの名前は、インストーラによって選択されている任意の名前です。

DefaultReader

Browser

Visitor

Browserは、配信システム上の認証されていないサイト訪問者に対して、WebCenter Sitesによって割り当てられるACLです。Visitor ACLも自動的に割り当てられます。

36.4 カスタム・ユーザー用の必須のACL

表36-5は、一般的なユーザー記述に基づいて、ユーザーが必要とするACLのリストです。

表36-5 ユーザーに必要とされるシステムACL

ユーザー

必須のACL

すべてのユーザー

Browser、Element Reader、PageReader、UserReader、xceleditor

ワークフロー管理者

サイト管理者

xceladmin

一般管理者

xceladmin、TableEditor、UserEditor、VisitorAdmin (Engage用)

サイト・デザイナ

xceladmin、ElementEditor、PageEditor、TableEditor、Visitor (Engage用)、Visitor Admin (Engage用)

Engageユーザー

Visitor

Oracle WebCenter Sites: ContributorインタフェースのWebモードのユーザー

Browser、ElementReader、PageReader、RemoteClient、UserReader、Visitor (Engage用)、xceleditor

36.5 システム・ロール

表36-6は、WebCenter Sitesのシステム・ロールと、ロールが持つアクセス権を示しています。

表36-6 システム・ロール

ロール

説明

GeneralAdmin

グローバルWebCenter Sites管理者のデフォルト・システム・ロール。

ツリーの「管理」タブ(およびその他の可能な機能すべて)にアクセスする必要があるユーザーに必須のロールです。

注意: GeneralAdminロールを持つユーザーは、「管理」タブの機能を使用するために、xceladmin ACLも所有する必要があります。

SiteAdmin

サイト管理者のデフォルト・システム・ロール。

選択されたサイトの管理者であり、そのため「サイト管理者」タブ(「管理」タブの機能のサブセットが表示される)にアクセスする必要があるユーザーに必須のロールです。

SiteAdminロールは、他のサイト・ユーザーを管理する一方で、それらのユーザーを作成しないユーザーに割り当てます。

注意: SiteAdminロールのユーザーが「サイト管理者」タブの機能を使用するためには、xceladmin ACLも必要です。

WorkflowAdmin

ワークフロー管理者のデフォルト・システム・ロール。

ツリーの「ワークフロー」タブにアクセスする必要があるユーザーに必須のロールです。

注意: WorkflowAdminロールのユーザーが「ワークフロー」タブの機能を使用するためには、xceladmin ACLも必要です。

AdvancedUser

WebCenter SitesユーザーがAdminインタフェースにアクセスできるようにします。

SitesUser

WebCenter SitesユーザーがContributorインタフェースにアクセスできるようにします。

36.6 システム・アセット・タイプ

表36-7 には、デフォルトのアセット・タイプがリストされています。カスタム・アセット・タイプと異なり、システム・アセット・タイプは削除できません。

表36-7 システム・アセット・タイプ

アセット・タイプ

説明

属性エディタ

属性エディタは、フレックス・アセットまたはフレックス親アセットに対してフレックス属性が「新規」フォームまたは「編集」フォームに表示されるときに、その属性に対してデータ入力方法を指定する属性エディタです。これはテンプレート・アセットに類似しています。ただし、テンプレート・アセットとは異なり、属性値をオンライン・サイトに表示するときではなく、Oracle WebCenter Sitesインタフェースに属性を表示するときにWebCenter Sitesが使用するコードを特定する場合に使用されれます。

CSElement

アセットをレンダリングしないコード(XMLまたはJSPおよびJava)を格納します。通常は、複数のテンプレート(バナーなど)からコールする共通のコードに対してCSElementを使用します。また、CSElementは、EngageでDynamicList推奨の作成に必要な問合せを提供する場合にも使用します。

コレクション

1つのタイプのアセットの順序付けリストを格納します。コレクションの構築は、1つ以上の問合せを実行し、その結果セットからアイテムを選択し、選択したアイテムをランキングする(順序付ける)ことによって行います。このランキングされ、順序付けられたリストがコレクションです。たとえば、前夜の選挙結果に関する記事が1位になるように政治関連記事のコレクションをランキングできます。

ディメンション

サイト内のロケールを表現しています。ディメンション・アセットは、管理システム上で有効にするロケールごとに作成する必要があります。特定のロケールでコンテンツをパブリッシュできるようにするには、対応するディメンション・アセットを配信システムにパブリッシュして、サイトのディメンション・セットでそのロケールを有効にする必要があります。

ディメンション・セット

オンライン・サイトで有効にするロケールとロケール・フィルタを定義します。配信システムでロケール・フィルタが動作するようにするには、配信システムに対して少なくとも1つのディメンション・セット・アセットを作成してパブリッシュする必要があります。管理システムには何も影響しません。

履歴属性

Engageで単一レコードとして扱われる情報のベクターを作成するためにグループ化した個々の情報タイプです。データのこのベクターが履歴定義です。たとえば、購買という履歴タイプは、SKU、アイテム名、数量および価格という履歴属性で構成できます。Engageで使用可能です。

履歴定義

履歴属性内のデータのベクター。データのこのベクターが履歴定義です。たとえば、購買という履歴タイプは、SKU、アイテム名、数量および価格という履歴属性で構成できます。Engageで使用可能です。

リンク

外部WebサイトのURLを格納します。このアセットは、外部リンクを別のアセット内に埋め込むために使用します。

ページ

他のアセットに対する参照を格納します。ページ・アセットの配置と設計によって、組織の表示方法やサイトのデザインが決まります。ページ・アセットの設計は、適切なコレクション、記事、イメージ・ファイル、問合せなどをページ・アセット用に選択して行います。さらに、WebCenter Sitesインタフェースの左側にサイトをツリー表示する「サイト・プラン」タブにページ・アセットを配置します。

プロモーション

サイト訪問者が購入しようとしているフレックス・アセット(たとえば製品)と訪問者が資格を有するセグメントに基づいて、ある種の価値または割引を訪問者に提供するマーチャンダイジング・アセットです。Engageで使用可能です。

問合せ

選択したパラメータまたは基準に基づいてアセットのリストを取得する問合せが格納されます。問合せアセットはページ・アセット、コレクション、および推奨で使用します。データベース問合せは、問合せアセットに対してSQL問合せとして「新規」フォームまたは「編集」フォームに直接書き込むか、「新規」フォームまたは「編集」フォームで特定されたエレメント(WebCenter Sitesの問合せタグが付いているもの、または検索エンジン問合せ)に書き込むことができます。

推奨

これはコレクションの拡張版と考えられます。これは、フレックス・アセット(製品や記事など)を収集、評価、ソートし、現在の訪問者が属するセグメントに基づいて、その訪問者に最適なものを推奨します。Engageで使用可能です。

セグメント

共通の特性(訪問者属性および履歴タイプ)に基づいて訪問者をグループに分けるアセットです。セグメントの作成は、セグメントの基となる訪問者データ・アセットを決定し、その基準に対して適格値を設定することによって行います。たとえば、アラスカの住民でフライ・フィッシングの道具一式を所有している人々や、過去6か月以内にパソコンを購入した人々などをセグメントで定義できます。Engageで使用可能です。

SiteEntry

WebCenter Sitesのページまたはページレットを表すものであり、そのページを生成したルート・エレメントとしてCSElementが割り当てられています。テンプレート・アセットは、エレメントとWebCenter Sitesのページの両方を表すため、SiteEntryアセットは関連付けられていません。

テンプレート

他のアセットをWebCenter Sitesのページおよびページレットにレンダリングするコード(XMLまたはJSPおよびJava)を格納します。開発者は、同一タイプのアセットがすべて同じように書式設定されるように、テンプレートの標準セットを(CSElementおよびSiteEntry以外の)アセット・タイプごとにコーディングします。コンテンツ・プロバイダは、コード自体にアクセスしたりコーディングする必要もなく、テンプレートを選択してコンテンツ・アセットをプレビューできます。

訪問者属性

1つの特性のみ(スカラー値)を指定する情報のタイプを保持します。たとえば、経験年数、肩書き、子供の数のような名前の訪問者属性を作成できます。Engageで使用可能です。

36.7 デフォルトのツリー・ノード

表36-8には、WebCenter Sites Adminインタフェースのツリーのデフォルト・ノードをリストしています。これらのノードは、WebCenter Sitesにとって重要です。WebCenter Sitesによって提供されるすべての機能に、インストール時に自動的に作成されるこれらのノードを介してアクセスできます。

表36-8 WebCenter Sites Adminインタフェースのデフォルトのツリー・ノード

タブ

説明

管理

システム内のすべてのCMサイトに影響する管理機能が表示されます。デフォルトでは、GeneralAdminというデフォルトのシステム・ロールのあるユーザーのみが、このタブにアクセスできます。

ブックマーク

ブックマークされたすべてのページのリストを保持します。よく使用されるページをマークしておくと、このタブから簡単に見つけてアクセスできます。

コネクタ管理者

WCCコネクタを管理するための管理機能を表示します。

履歴

現在のセッションで使用したアセットが表示されます。このタブは、すべてのユーザーに対して、最初のアセットの作成、調査、編集またはコピー直後に表示されます。

モビリティ

モバイル・デバイスとそのグループ化の管理上の配置が表示されます。モバイル・デバイスの管理は、ここから行われます。

サイト管理者

システム規模の管理機能のサブセットを保持します。このサブセットは、SiteAdminがログインしているCMサイトのみに適用されます。デフォルトでは、SiteAdminというデフォルトのシステム・ロールのあるユーザーのみが、このタブにアクセスできます。このタブは、個々のCMサイトへのアクセス権限は管理するが、ユーザーまたはサイトを作成する必要のないユーザーにとって役立ちます。

Dev

サイトでページを作成するためのソースです。これらのソースには、テンプレート、製品定義、コンテンツ定義、およびページ作成のためのその他のソースがあります。

サイト・ナビゲーション

サイトのレイアウトと概要を表現します。このタブには、WebCenter Sitesによって制御されている各サイトが表示されます。配置済ページと未配置ページをリストしています。配置済ページは、作成され、ライブ・サイトに統合されたページです。未配置ページは、完成しているが、ライブ・サイトに統合されていないページです。

ワークフロー

ワークフロー構成機能がリストされます。デフォルトでは、Workflow Adminロールのあるユーザーのみが、このタブにアクセスできます。

37 WebCenter Sitesのデータベース表

この章では、WebCenter Sitesデータベース内の動的な表と、その拡大の仕組みについて説明します。データベース管理者はこの情報を使用して、WebCenter Sitesデータベースのサイズを適切に設定する方法を決定できます。

WebCenter Sitesデータベース表の詳細は、次の各トピックを参照してください。

- キャッシュ管理の表

- 承認システムの表

- パブリッシュ・システムの表

- ワークフローの表

- ベーシック・アセットの表

- フレックス・アセットの表

- 訪問者の表(Engage)

37.1 キャッシュ管理の表

WebCenter SitesではCacheManagerが提供されます。これは、WebCenter Sitesのページ・キャッシュとSatellite Serverのキャッシュの両方を管理するページ・キャッシング・ユーティリティです。

キャッシュされたページを期限切れにする必要があるのは、有効期限が切れた場合となんらかの方法でそのページが参照するアセットが変更された場合の両方なので、CacheManagerは、有効期限だけでなく、キャッシュ内に格納されているページとページレットの間に存在する依存性を追跡する必要があります。この情報は、SystemPageCache表とSystemItemCache表に格納されます。

どのWebCenter SitesシステムもCacheManagerを使用します。つまり、これらの表はシステムの開発時、管理時、配信時に動的に拡大します。表37-1は、キャッシュ追跡表がどのように増大するかを示しています。

表37-1 キャッシュ管理の表

表

行数

SystemPageCache

キャッシュされたページごとに1行。

ページの有効期限が切れたら、行は削除されます。

SystemItemCache

SystemPageCache表にあるキャッシュされたページによって参照されるアセット、ページレット、その他のアイテムごとに1行。たとえば、キャッシュされたページが、3つの記事アセットに対するアソシエーションを持つページ・アセットから作成されたものである場合、そのキャッシュされたページに対して4行が存在することになります。

37.2 承認システムの表

WebCenter Sitesの承認システムは、承認された各アセット、その承認されたセットの他のアセットに対する依存性、アセットの承認ターゲットを追跡します。この情報は、ApprovedAssets表とApprovedAssetDeps表に格納されます。

これらの表は、管理システム上で非常に大きくなる可能性がありますが、配信システムでは使用されません。表37-2は、承認システム表がどのように増大するかを示しています。

表37-2 承認システムの表

表

行数

ApprovedAssets

承認ターゲットのそれぞれについて、承認されたアセットごとに1行。つまり、1つのアセットが2つのターゲットに対して承認された場合、表にはこのアセットに対して2行が存在することになります。

ApprovedAssetDeps

承認ターゲットのそれぞれについて、承認された各アセットの依存性ごとに1行。

たとえば、承認されたアセットが他の4つのアセットに依存している場合、この表には4行が存在することになります。その同じアセットが2つのターゲットに対して承認された場合、各ターゲットの各依存性ごとに1行が存在することになります。

37.3 パブリッシュ・システムの表

WebCenter Sitesのパブリッシュ・システムは、アセットのパブリッシュされた日時とパブリッシュ先を追跡します。この情報は、PubKey表とPublishedAssets表に格納されます。

WebCenter Sites管理システムのアセット数が増加すると、これらの表の行数も増加します。表37-3は、パブリッシュ・システム表がどのように増大するかを示しています。

表37-3 パブリッシュ・システムの表

表

行数

PubKey

ミラー・パブリッシュの場合: ターゲット宛先のそれぞれについて、ミラーリングされるアセットごとに1行。

エクスポート・パブリッシュの場合: エクスポート時に作成されるページごとに1行。つまり、14のアセットが1ページにレンダリングされた場合、この表には、(14行ではなく)アセットのグループ全体に対する1行のみが存在することになります。

PublishedAssets

ミラー・パブリッシュの場合: ターゲット宛先のそれぞれについて、ミラーリングされるアセットごとに1行。

エクスポート・パブリッシュの場合: エクスポートされるアセットごとに1行。前述の例を続けるなら、14アセットが1ページにレンダリングされた場合、表にはそのページについてアセットごとに1行が存在することになります。

37.4 ワークフローの表

ワークフロー・システムは、あらゆる時点でワークフロー・プロセスに関与したすべてのアセットを追跡します。この情報は、Assignment表とWorkflowObject表に格納されます。

ワークフロー・プロセスに配置されたアセット数が増加すると、これらの表の行数も増加します。表37-4は、ワークフロー表がどのように増大するかを示しています。

表37-4 ワークフローの表

表

行数

Assignment

ワークフローの割当てごとに1行。たとえば、ワークフロー・プロセスの過程で1つのアセットが4人のユーザーに割り当てられた場合、表にはそのアセットについて4行が存在することになります。

これらの行は、そのアセットに対してワークフロー・プロセスが完了しても削除されません。

WorkflowObjects

ワークフロー内のアセットごとに1行。

アセットがワークフローを離れると、この行は削除されます。

37.5 ベーシック・アセットの表

ベーシック・アセット・タイプには、1つのプライマリ・ストレージ表があります。たとえば、articleアセット・タイプのプライマリ・ストレージ表の名前はArticleで、HelloArticleアセット・タイプのプライマリ・ストレージ表の名前はHelloArticleになります。

1つのタイプのアセットの数が増加すると、そのタイプのアセットを保持している表のサイズも増大します。ベーシック・アセットのプライマリ・ストレージ表には、そのタイプのアセットごとに1行が存在しています。

37.6 フレックス・アセットの表

フレックス・ファミリ内のアセット・タイプには、それぞれ複数のデータベース表があります。非常に大きくなる可能性のあるフレックス・ファミリ内の3つのタイプの表は次のとおりです。

- フレックス・アセット・タイプのプライマリ・ストレージ表。たとえば、avisportsサンプル・サイトで、articleという名前のアセット・タイプのプライマリ・ストレージ表の名前はAVIArticleになります。

- フレックス・アセットまたはフレックス親アセット・タイプの_AMap表。(例: AVIArticle_AMap。)

- フレックス親アセット・タイプの_Group表。(例: ArticleCategory_Group。)

- フレックス・アセット・タイプの_Mungo表。(例: AVIArticle_Mungo。)

- フレックス親アセット・タイプの_Mungo表。(例: ArticleCategory_Mungo。)

- Mungo_Blobs表。

表37-5は、フレックス・アセット表がどのように増大するかを示しています。

表37-5 フレックス・アセットの表

表

行数

FlexAssetType

(例: AVIArticle)

このタイプのすべてのアセットに対してアセットごとに1行。

FlexAssetType_AMap

(例: AVIArticle_AMap)

そのタイプのアセットそれぞれについて、(属性値が継承されたものでも、直接割り当てられたものでも)属性値ごとに1行。

FlexAssetType_Group

(例: ArticleCategory_Group)

フレックス親アセットとフレックス・アセットの間の親子関係ごとに1行(親の親、さらにその親などの関係を含む)。

FlexAssetType_Mungo

(例: AVIArticle_Mungo)

このタイプの各アセットのすべての属性値に対して属性値ごとに1行。

場合によっては、この等式の結果が1000万行を超えることもあります。

FlexParent_Mungo

(例: ArticleCategory_Mungo)

このタイプのすべての親アセットのすべての属性値に対して属性値ごとに1行。

Mungo_Blobs

blobタイプの属性に対して保存されたすべての属性値に対して属性値ごとに1行。

37.7 訪問者の表(Engage)

Oracle WebCenter Sites: Engageは訪問者情報をキャプチャして、訪問者データ表に格納します。これらの表には訪問者のセッションIDなどの情報が格納されており、これによって、以前のセッションや、収集しているデータを表す属性の値にリンクすることができます。

オンライン・サイトを訪問する訪問者の数が増加すれば、これらの表の行数も増加します。表37-6は、訪問者の表がどのように増大するかを示しています。

表37-6 Engageの訪問者の表

表

行数

scratch

訪問者に対して作成される訪問者コンテキスト・セッション・オブジェクトごとに1行。

訪問者コンテキスト・セッション・オブジェクトとは、プロモーション・リスト、セグメント・リスト、ショッピング・カートなどのようなものです。各セッションの各訪問者に対して、少なくとも5行がこの表に追加されます。

VMVISITOR

各ブラウザ・セッションの訪問者ごとに1行。

Engageでは、各セッションの各訪問者に対して一意の訪問者IDが作成されます。

VMVISITORALIAS

データベース中心の訪問者追跡では、返される訪問者についても、各ブラウザ・セッションの訪問者ごとに1行が作成されます。この方法では、訪問ごとに1行が作成されます。

メモリー中心の訪問者追跡では、返される訪問数に関係なく、訪問者ごとに1行が作成されます。

注意: 1行の中には、別名の名前/値のペアと、セッションをマークする訪問者ID (VMVISITORにもリストされているもの)が保持されています。

VMVISITORSCALARVALUE

保存されている訪問者の属性値(バイナリ・タイプの属性を除く)ごとに1行。

注意: メモリーベースの訪問者追跡が有効である場合は、この表には値が移入されません。

VMVISTORSCALARBLOB

保存されているバイナリ・タイプの訪問者属性値(スカラー・オブジェクトとも言われる)ごとに1行。

注意: メモリーベースの訪問者追跡が有効である場合は、この表には値が移入されません。

VMz ------------

動的に生成される表で、履歴属性の値が保存されたときに作成されます。

Engageによって履歴タイプごとに1つの表が作成され、この表には履歴タイプのレコードが保存されるたびに1行ずつ追加されます。

この項の内容は次のとおりです。

- 属性の表の管理

- セッション・オブジェクト(Scratch)表の管理

- 不要な.classファイルの削除

37.7.1 属性の表の管理

属性値を保持している表は急速に拡大する可能性があるので、非アクティブなデータを定期的にこの表から消去する必要があります。

これらの表から非アクティブなデータを削除するには、次に示すEngage XMLオブジェクト・メソッドか、これと同等のJSPを使用します。

<VDM.FLUSHINACTIVE STARTDATE="cutoffDate"/>

非アクティブな訪問者データとは、最新と考えられるデータに別名を介して接続されていない訪問者IDでマークされているデータのことです。使用するEngageに対してカットオフ日付(STARTDATE)を設定します。その日付より前の訪問者レコードはすべて、その日付より後に記録されたデータと別名を介してリンクされていないかぎり、以前リストされた訪問者表から削除されます。

VDM.FLUSHINACTIVEタグの使用方法は複数あります。例:

- タグを呼び出してカットオフ日付の入力を求める管理エレメントを作成できます。

- なんらかのパラメータに基づいてカットオフ日付を計算する等式をこのエレメントに指定して、このエレメントを定期的にスケジュールされた時間に自動的なイベントとして実行するように設定できます。自動的なイベントとして設定するには、WebCenter SitesのAPPEVENTタグ(kronのように機能する)を使用します。このタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスと『Oracle WebCenter Sitesでの開発』を参照してください。

STARTDATEパラメータに渡す値はイベント内の時間にする必要があります。WebCenter SitesのDATE.CONVERTタグを使用して、使用するイベント日付の値を取得できます。例:

<DATE.CONVERT VARNAME="flushtime"
YEAR="four digit year" MONTH="number in the range 1-12"
DAY="number in the range 1-31"
[HOUR="number in the range 0-11 where 0 is midnight" AMPM="am
or pm" MINUTE="number in the range 0-59" TIMEZONE="timezone"]/>
<VDM.FLUSHINACTIVE STARTDATE="Variables.flushtime"/>

これらのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

37.7.2 セッション・オブジェクト(Scratch)表の管理

各セッションの各訪問者に対して少なくとも5つのセッション・オブジェクトが格納されているため、scratch表は急速に拡大する可能性があります。各オブジェクトにはタイムスタンプがあるので、それぞれのタイムスタンプに基づいて、古いオブジェクトを定期的に消去する必要があります。

scratch表から古いセッション・オブジェクトを削除するには:

- 削除するには、次に示すEngage XMLオブジェクト・メソッドか、これと同等のJSPを使用します。

<SESSIONOBJECTS.FLUSH TIMESTAMP="cutoffTime"/>

セッション・オブジェクトにはカートが含まれているので、そのカートが放棄されたと見なされる時点を表すカットオフ時刻を設定する必要があります。

STARTDATEパラメータに渡す値はイベント内の時間にする必要があります。WebCenter SitesのDATE.CONVERTタグを使用して、使用するイベント日付の値を取得できます。たとえば、次の項に示すVDM.FLUSHINACTIVEタグのコード例を参照してください。

これらのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

注意:

このオブジェクト・メソッドはVMSCALARBLOB表には影響しません。つまり、バイナリ・タイプの訪問者属性(スカラー・オブジェクト)として格納したカートは削除されません。

37.7.3 不要な.classファイルの削除

EngageはJavaベースのアプリケーションなので、イベントが発生するたびにJavaの.classファイルが生成されます。

- セグメント、推奨またはプロモーションが作成されたとき。

- 関連アイテムの推奨用に製品が構成されたとき。

- セグメント、推奨またはプロモーションがEngageによって計算または起動されたとき。

通常、古い.classファイルは、セグメント、推奨、プロモーションまたは製品が更新されて新しい.classファイルによって置き換えられたときに削除されます。ただし、更新済バージョンがパブリッシュされたときに、セグメント、推奨、製品またはプロモーションが使用中の場合、古い.classファイルはロックされているために、Engageによって自動削除されません。

古い.class ファイルが積み重なってディスクを満たし、メモリーを占拠する可能性があります。したがって、実行中の開発作業の量と配信システムのパブリッシュ頻度に基づいて、これらの.classファイルを定期的にスケジュールされた時間に手動で削除する必要があります。

古い.classファイルを削除するには、次の手順を実行します。

1. プロパティ管理ツールを使用して、vis.genclasspathプロパティを調べ、パラメータによって指定されているディレクトリ名をメモします。これは、Engageによって.classファイルが格納されているディレクトリです。

2. サイトに動きがないときに、実行中のJREランタイムの各インスタンスをシャットダウンして再起動します。このプロセスによって、JREランタイムによってロックされた古い.classファイルが解放されます。

3. 任意のファイル管理ツールを使用して、.classファイルを保持しているディレクトリに移動し、このディレクトリのコンテンツを削除します。

必要なときには、Engageにより、どのような.classファイルでも再生成されます。

38 LDAP統合Sitesシステムでのユーザー、サイト、およびロール

この章では、どの操作がLDAPサーバーに伝播されるのか(LDAPサーバーのタイプ、操作、および読取り専用権限と読取り/書込み権限のどちらを持つユーザーとして接続しているのかで分けて記載)、どの操作によってエラーが生成されるのか、およびエラーの修正方法について説明します。この章は、ユーザー、ACL、サイトおよびロールをLDAP統合WebCenter Sitesシステムの管理者のインタフェースから管理し、その操作がWebCenter SitesデータベースとLDAPサーバーの両方にどのように影響するのかを把握する必要があるWebCenter Sites管理者を対象としています。

この章の内容は次のとおりです。

- LDAP統合WebCenter Sitesのシステム

- ユーザー管理操作

- サイトおよびロールの管理操作

38.1 LDAP統合WebCenter Sitesのシステム

WebCenter Sitesは、LDAP-2プロトコルまたは他の任意のプロトコルを使用するLDAPサーバーと統合できます(ただし、後者の場合、管理者のインタフェースからLDAPサーバーへの書込み操作はサポートされていません)。

この概要では、次について示します

- WebCenter SitesによってサポートされるLDAPスキーマのタイプ

- 各タイプのスキーマがデプロイされているときにWebCenter Sitesインタフェースから実行できる操作

- 操作の結果(LDAPサーバーに対するWebCenter Sites管理者の権限およびLDAPサーバーの性質で分けて記載)。

この項の内容は次のとおりです。

- LDAPスキーマ

- サイトおよびロール管理に対するLDAPの接続性

- LDAPユーザーとLDAPサーバーに対する彼らの権限

- LDAP統合操作

38.1.1 LDAPスキーマ

この章では、フラットスキーマLDAPと階層スキーマLDAPのLDAPスキーマ・シナリオについて説明します。次のように、各スキーマでは選択された操作とインストールがサポートされています。

- フラットスキーマおよび階層スキーマのどちらのLDAPも、WebCenter SitesにおけるACLおよびユーザー(ユーザー・アカウント、ユーザー・プロファイル、およびユーザー属性)に対する操作がサポートされています。

- フラットスキーマLDAPでは、WebCenter Sitesにおけるサイトおよびロールに対する操作がサポートされており、サイトおよびロールがフラット化され、それらの間に階層が存在しないようになります。

- 階層スキーマLDAPでは、WebCenter Sitesにおけるサイトおよびロールに対する操作がサポートされています。 このスキーマでは、LDAPユーザーが、LDAPサーバー内にロールがそれらの関連サイトに従属する必要があるサイト組織単位を定義する必要があります(例については、図38-1を参照してください)。

表38-1は、LDAPスキーマおよび使用可能な操作についてまとめられています。適切なスキーマを使用することで、サイトおよびロール管理に対するLDAPの接続性に要約されている条件に応じて、WebCenter Sites管理者は、WebCenter Sitesインタフェースで操作を実行し、それらをWebCenter SitesデータベースまたはLDAPサーバー、あるいはその両方に伝播させることができます。

表38-1 LDAPの統合シナリオ

作成/変更/削除操作の対象

フラットスキーマLDAP

階層スキーマLDAP

ACL、ユーザー、ユーザー・プロファイル、ユーザー属性

表38-2

表38-2

サイトおよびロール

表38-3

表38-4

図38-1 LDAP階層

38.1.2 サイトおよびロール管理に対するLDAPの接続性

ロールとサイトの操作がこの章に記載されているように機能するには、LDAPの接続性が有効である必要があります。Adminインタフェースのプロパティ管理ツールを使用して、wcs_properties.jsonファイルの2つのパラメータを設定します。

xcelerate.usermanagerclass
xcelerate.rolemanagerclass

これらのプロパティによって、サイトおよびロールをLDAPサーバーで直接(この付録で示すとおりに)管理するか、WebCenter Sitesデータベースのみで管理できます。

- このプロパティ値でLDAPが指定されている場合、LDAPの接続性が確立されています。サイトおよびロールはLDAPサーバー(およびWebCenter Sitesデータベース)で管理できます。

- 階層スキーマLDAPの場合、xcelerate.usermanagerclassプロパティでのみLDAPが指定されている必要があります。xcelerate.rolemanagerclassプロパティではデフォルト値が使用されます。例:

xcelerate.usermanagerclass=com.openmarket.xcelerate.user.LDAPSchemaUserManager
xcelerate.rolemanagerclass=com.openmarket.xcelerate.roles.RoleManager

- フラットスキーマLDAPの場合、両方のプロパティでLDAPが指定されている必要があります。例:

xcelerate.usermanagerclass=com.openmarket.xcelerate.user.FlatLDAPSchemaUserManager
xcelerate.rolemanagerclass=com.openmarket.xcelerate.roles.FlatLDAPSchemaRoleManager

- それらのプロパティ値でLDAPが指定されていない場合(たとえば、xcelerate.usermanagerclass=com.openmarket.xcelerate.user.usermanager)、サイトおよびロールは、WebCenter Sitesデータベースでのみ管理できます。

38.1.3 LDAPユーザーとLDAPサーバーに対する彼らの権限

LDAP統合WebCenter Sitesシステムでは、wcs_properties.jsonファイルのjndi.connectAsUserプロパティ(「ユーザー」カテゴリ)の値に応じて、WebCenter Sitesシステムの管理者がLDAPサーバーの管理ユーザーである場合とない場合があります。この値によって、WebCenter Sites管理者がLDAPサーバーにどのように接続されているかが決まり、したがってLDAPユーザーが定義されます。

- jndi.connectAsUserがtrueに設定されている場合、WebCenter Sitesでは、LDAPユーザーはWebCenter Sitesにログインしているユーザーと同じであると定義され、そのユーザーがLDAPサーバーに接続されます。

- jndi.connectAsUserがfalseに設定されている場合、WebCenter Sitesでは、LDAPユーザーは(wcs_properties.jsonの)jndi.loginプロパティ(「ユーザー」カテゴリ)で指定されているユーザーであると定義され、そのユーザーがLDAPサーバーに接続されます。

接続が行われるには、そのユーザーと彼の権限がLDAPサーバーでも定義されている必要があります。そのユーザーがLDAPサーバーに対して読取り専用権限を持っている場合、彼は管理LDAPユーザーではありません。そのユーザーがLDAPサーバーに対して読取り/書込み権限を持っている場合、彼は管理LDAPユーザー(簡単に言えばLDAP管理者)です。

注意:

LDAP関連のプロパティの詳細は、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

38.1.4 LDAP統合操作

WebCenter Sites管理者が、操作(WebCenter SitesデータベースとLDAPサーバーの両方でのACLの作成など)を正常に実行するには、WebCenter Sitesが適切にLDAPサーバーと統合されていることが重要です。統合に問題がない場合は、操作の結果は次の要因に応じて異なります。

- jndi.connectAsUserプロパティで定義されているLDAPユーザー(前の項を参照)。

- LDAPサーバーで定義されているLDAPユーザーの権限。
WebCenter Sites管理者が、管理権限を持たないユーザーとしてLDAPサーバーに接続している場合、その操作(WebCenter SitesデータベースからのACLの削除など)は、LDAPサーバーに書き込まれません。その操作はWebCenter Sitesデータベースに書き込まれるか、何も実行されません。操作は管理者のインタフェースで繰り返す必要があり、LDAP管理者によってLDAPサーバーで手動で実行する必要があります。

- 操作の性質。
管理者のインタフェースで実行される特定の操作(ACLの編集など)は、WebCenter Sites管理者が書込み権限を持って接続している場合でも、LDAPサーバーに書き込まれません。

- LDAPサーバーでLDAP-2プロトコルがサポートされているかどうか。
LDAPサーバーでLDAP-2プロトコルがサポートされていない場合、管理者のインタフェースからLDAPサーバーへの書込み操作はサポートされず、操作の結果は予測不能です。

表38-2、表38-3および表38-4には、読取り専用権限および読取り/書込み権限を持つユーザーとしてLDAPサーバーに接続しているWebCenter Sites管理者が実行できる操作の結果がまとめてあります。

38.2 ユーザー管理操作

表38-2は、フラットスキーマと階層スキーマのLDAP Web環境に適用され、ユーザー管理操作に対するシステム・レスポンスがまとめてあります。この操作は、それぞれ次のLDAPオプションのいずれかと統合されている3つのWebCenter Sitesシステムのインタフェースを使用して、WebCenter Sites管理者によって行われます。

- LDAPユーザーに対して読取り専用権限のあるLDAP-2サーバー(サイトおよびロール管理に対するLDAPの接続性で定義済)。

- LDAPユーザーに対して書込み権限のあるLDAP-2サーバー

- LDAP-2以外のLDAPサーバー(この場合、書込み操作はサポートされていません)

各ユーザー管理操作の結果は、表38-2 の左側の列に記載したページで説明しています。

注意:

この付録でのユーザー管理という用語には、ACL、ユーザー・アカウント、ユーザー・プロファイル、およびユーザー属性の管理が含まれます。

表38-2 WebCenter Sitesでのユーザー管理操作に対するシステム・レスポンス

WebCenter Sitesでの操作

結果

LDAP-2でのシステム・レスポンス: ユーザーは読取り専用権限を持つ(注1参照)

LDAP-2でのシステム・レスポンス: ユーザーは書込み権限を持つ(注2参照)

他のLDAPサーバーでのシステム・レスポンス: 書込みサポートなし(注3参照)

ACLを作成するためのLDAPサーバー・レスポンス

ACLが作成される

エラーが返される(注4参照)

LDAP + WebCenter Sitesデータベース

予測不能

ACLを編集するためのLDAPサーバー・レスポンス

ACLが変更される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ACLを削除するためのLDAPサーバー・レスポンス

ACLが削除される

エラーが返される

LDAP + WebCenter Sitesデータベース

予測不能

ACLを表に割り当てるためのLDAPサーバー・レスポンス

ACLが割り当てられる

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ACLをWebCenter Sitesページ(サイト・カタログ・ページ・エントリ)に割り当てるためのLDAPサーバー・レスポンス

ACLが割り当てられる

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ユーザーを作成する(アクセス権のためにACLを付与する)ためのLDAPサーバー・レスポンス

ユーザーが作成される

エラーが返される

LDAP

予測不能

ユーザーを編集するためのLDAPサーバー・レスポンス

ユーザーが変更される

エラーが返される

LDAP

予測不能

ユーザーを削除するためのLDAPサーバー・レスポンス

ユーザーが削除される

エラーが返される

LDAP

予測不能

ユーザー・プロファイルを作成/編集するためのLDAPサーバー・レスポンス

ユーザー・プロファイルが作成/編集される

エラーが返される

LDAP

予測不能

ユーザー・プロファイルを削除するためのLDAPサーバー・レスポンス

ユーザー・プロファイルが削除される

エラーが返される

LDAP

予測不能

ユーザー属性を作成するためのLDAPサーバー・レスポンス

ユーザー・プロファイルが作成される

エラーが返される

LDAP

予測不能

ユーザー属性を編集/削除するためのLDAPサーバー・レスポンス

ユーザー・プロファイルが削除される

エラーが返される

LDAP

予測不能

注意:

1. ACLおよびユーザーをLDAPサーバーに格納することはできません(WebCenter Sites管理者は、書込み権限のないユーザーとしてLDAPサーバーに接続されます)。

2. ACLおよびユーザーはLDAPサーバーに格納できます(WebCenter Sites管理者は書込み権限を持つユーザーとしてLDAPサーバーに接続されています)。

3. LDAPサーバーはLDAP-2プロトコルをサポートしません(Netscapeサーバーなど)。非準拠LDAPサーバーの場合、管理者のインタフェースからそのLDAPサーバーへの書込み操作はサポートされません。

4.エラーが返されるとは、その操作が実行されない(システムがエラーを返す)ことを意味します。

次のトピックでは、ユーザー管理オプションに関するリファレンス情報を提供します。

- ACLを作成するためのLDAPサーバー・レスポンス

- ACLを編集するためのLDAPサーバー・レスポンス

- ACLを削除するためのLDAPサーバー・レスポンス

- ACLを表に割り当てるためのLDAPサーバー・レスポンス

- ACLをWebCenter Sitesページ(サイト・カタログ・ページ・エントリ)に割り当てるためのLDAPサーバー・レスポンス

- ユーザーを作成する(アクセス権のためにACLを付与する)ためのLDAPサーバー・レスポンス

- ユーザーを編集するためのLDAPサーバー・レスポンス

- ユーザーを削除するためのLDAPサーバー・レスポンス

- ユーザー・プロファイルを作成/編集するためのLDAPサーバー・レスポンス

- ユーザー・プロファイルを削除するためのLDAPサーバー・レスポンス

- ユーザー属性を作成するためのLDAPサーバー・レスポンス

- ユーザー属性を編集/削除するためのLDAPサーバー・レスポンス

38.2.1 ACLを作成するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用してACLの作成を試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ACLを作成できません。LDAP管理者は、最初にLDAPサーバーに次にWebCenter Sitesデータベースに、ACLを手動で作成する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーとWebCenter Sitesデータベースの両方にACLが作成されます。

3. LDAP-2以外: 書込みサポートなし: レスポンスは予測できません。LDAP管理者は、最初にLDAPサーバーに次にWebCenter Sitesに、ACLを作成する必要があります。

38.2.2 ACLを編集するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用してACLの変更を試みます。

注意:

WebCenter Sites管理者は、ACLの記述とACLと関連付けられた権限のどちらも変更できますが、ACLの名前は変更できません。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: WebCenter SitesデータベースのACLが変更されます。LDAPと統合されていても、変更はデータベースにのみ格納されます。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.2.3 ACLを削除するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用してACLの削除を試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ACLを削除できません。LDAP管理者は、最初にLDAPサーバーから次にWebCenter Sitesデータベースから、ACLを削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーとWebCenter SitesデータベースからACLが削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、WebCenter SitesからのACLの削除を試みる前に最初にLDAPサーバーからACLを削除する必要があります。

38.2.4 ACLを表に割り当てるためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者がシステム表へのACLの割当てを試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: データベース表にACLが割り当てられます。ACLが割り当てられない場合、エラー・メッセージが返されます。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.2.5 ACLをWebCenter Sitesページ(サイト・カタログ・ページ・エントリ)に割り当てるためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者がWebCenter SitesページへのACLの割当てを試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: 指定されたWebCenter Sitesページに対して選択されているACLが追加されます。ACLが割り当てられない場合、エラー・メッセージが返されます。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.2.6 ユーザーを作成する(アクセス権のためにACLを付与する)ためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用してユーザーの作成を試みます。

注意:

WebCenter Sitesには、そのデータベースに格納されているACLのみが表示されます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ユーザーおよびそのユーザーに割り当てられたACLは追加できません。LDAP管理者は、LDAPサーバーを使用して、手動でそのLDAPサーバーにユーザーを追加し、そのユーザーにACLを割り当てる必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーにユーザーが作成され、そのユーザーにACLが割り当てられます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、LDAPサーバーを使用して、手動でそのLDAPサーバーにユーザーを追加し、そのユーザーにACLを割り当てる必要があります。

38.2.7 ユーザーを編集するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用して、ユーザーに割り当てられているACLの変更または、ユーザーのパスワードの変更を試みます。

注意:

「ユーザーの修正」操作では、ユーザー・パスワードおよびそのユーザーに関連付けられているACLのみ変更できます。

「ユーザー属性の修正」操作では、データベースおよびLDAPサーバーに格納されているすべての属性を変更できます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ユーザーのパスワードまたはACLを変更できません。LDAP管理者は手動でLDAPサーバー内のユーザーを変更する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバー内のユーザーのパスワードまたは割当て済ACL、あるいはその両方が変更されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は手動でLDAPサーバー内のユーザーを変更する必要があります。

38.2.8 ユーザーを削除するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードを使用してユーザーの削除を試みます。

ユーザーを削除する前に、管理者はそのユーザー・プロファイルを削除する必要があります。ユーザー・プロファイルが存在する場合、エラー・メッセージがトリガーされます。削除対象のユーザーのユーザー・プロファイルが存在しない場合は、次に説明する動作が予想されます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ユーザーを削除できません。LDAP管理者は、LDAPサーバーからユーザーを手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーからユーザーが削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、LDAPサーバーからユーザーを手動で削除する必要があります。

38.2.9 ユーザー・プロファイルを作成/編集するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「一般的な管理」ツリーにある「管理」ノードの「ユーザー・プロファイル」ノードを使用してユーザー・プロファイルの作成または変更を試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ユーザーのプロファイルまたはロケール設定を更新できません。LDAP管理者は、LDAPサーバーからユーザー・プロファイルを手動で更新する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーでユーザーのプロファイルまたはロケール設定が更新されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、LDAPサーバーからユーザー・プロファイルを手動で更新する必要があります。

38.2.10 ユーザー・プロファイルを削除するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・プロファイル」ノードを使用してユーザー・プロファイルの削除を試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、ユーザーのプロファイルを削除できません。LDAP管理者は、LDAPサーバーからユーザー・プロファイルを手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーからユーザーのプロファイルが削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、LDAPサーバーからユーザー・プロファイルを手動で削除する必要があります。

38.2.11 ユーザー属性を作成するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者は、「一般的な管理」ツリーの「管理」の下にある「ユーザー・アクセス管理」ノードから、ユーザーの属性を試みます。

注意:

ユーザー属性は、データベースかLDAPのどちらか1箇所にのみ格納されています。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、新しい属性をLDAPサーバーに追加できません。LDAP管理者は、手動でユーザーをLDAPサーバーに追加する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーにユーザーの新しい属性が追加されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、手動でユーザーをLDAPサーバーに追加する必要があります。

38.2.12 ユーザー属性を編集/削除するためのLDAPサーバー・レスポンス

ユーザー管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー・アクセス管理」ノードから、ユーザー属性の変更を試みます。

システム・レスポンス:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、LDAPサーバーからユーザーの属性を変更または削除できません。LDAP管理者は、手動でLDAPサーバーでユーザー属性を変更し、LDAPサーバーからユーザー属性を削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーのユーザー属性は変更され、LDAPサーバーから削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。LDAP管理者は、手動でLDAPサーバーでユーザー属性を変更し、手動でLDAPサーバーからユーザー属性を削除する必要があります。

38.3 サイトおよびロールの管理操作

次の各トピックでは、フラットスキーマおよび階層スキーマLDAPサーバーを使用した、サイトおよびロールの管理操作について説明します。

- フラットスキーマLDAPサーバーでの操作

- 階層スキーマLDAPサーバーでの操作

- サイトを作成するためのLDAPサーバー・レスポンス

- サイトを編集するためのLDAPサーバー・レスポンス

- サイトを削除するためのLDAPサーバー・レスポンス

- サイトへのユーザー・アクセスを付与するためのLDAPサーバー・レスポンス

- サイトへのユーザーのアクセス権を削除するためのLDAPサーバー・レスポンス

- ロールを作成するためのLDAPサーバー・レスポンス

- ロールを編集するためのLDAPサーバー・レスポンス

- ロールを削除するためのLDAPサーバー・レスポンス

38.3.1 フラットスキーマLDAPサーバーでの操作

表38-3に、サイトおよびロールの管理操作に対するシステム・レスポンスをまとめています。この操作は、それぞれ次のLDAPオプションのいずれかと統合されている3つのWebCenter Sitesシステムのインタフェースを使用して、WebCenter Sites管理者によって行われます。

- LDAPユーザーに対して読取り専用権限のあるLDAP-2サーバー(サイトおよびロール管理に対するLDAPの接続性で定義済)。

- LDAPユーザーに対して書込み権限のあるLDAP-2サーバー

- LDAP-2以外のLDAPサーバー(この場合、書込み操作はサポートされていません)

各操作の結果は、表38-3の左側の列に記載した項で説明しています。

表38-3 フラットスキーマLDAPでのサイトおよびロールの管理操作に対するシステム・レスポンス

WebCenter Sitesでの操作

結果

フラットスキーマLDAP-2でのシステム・レスポンス: ユーザーは読取り専用権限を持つ(注1参照)

フラットスキーマLDAP-2でのシステム・レスポンス: ユーザーは書込み権限を持つ(注2参照)

フラットスキーマLDAPサーバー(LDAP-2以外)でのシステム・レスポンス: 書込みサポートなし(注3参照)

サイトを作成するためのLDAPサーバー・レスポンス

サイトが作成される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

サイトを編集するためのLDAPサーバー・レスポンス

サイトが編集される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

サイトを削除するためのLDAPサーバー・レスポンス

サイトが削除される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ロールを作成するためのLDAPサーバー・レスポンス

ロールが作成される

エラーが返される(注4参照)

LDAP + WebCenter Sitesデータベース(注5参照)

予測不能

ロールを編集するためのLDAPサーバー・レスポンス

ロールが編集される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ロールを削除するためのLDAPサーバー・レスポンス

ロールが削除される

エラーが返される

LDAP + WebCenter Sitesデータベース

予測不能

サイトへのユーザー・アクセスを付与するためのLDAPサーバー・レスポンス

アクセス権限が付与される

エラーが返される

LDAP

予測不能

サイトへのユーザーのアクセス権を削除するためのLDAPサーバー・レスポンス

アクセス権限が削除される

エラーが返される

LDAP

予測不能

注意:

1. サイトおよびロールをLDAPサーバーに格納することはできません(WebCenter Sites管理者は、書込み権限のないユーザーとしてLDAPサーバーに接続されます)。

2. サイトおよびロールをLDAPサーバーに格納できます(WebCenter Sites管理者は、書込み権限のあるユーザーとしてLDAPサーバーに接続されます)。

3. LDAPサーバーはLDAP-2プロトコルをサポートしません(Netscapeサーバーなど)。非準拠LDAPサーバーの場合、管理者のインタフェースからそのLDAPサーバーへの書込み操作はサポートされません。

4.エラーが返されるとは、その操作が実行されない(システムがエラーを返す)ことを意味します。

5. LDAPサーバーとWebCenter Sitesデータベースの両方でロールが作成されるには、LDAPサーバーに1つ以上のサイトが存在している必要があります。サイトが存在しない場合、ロールはWebCenter Sitesデータベースでのみ作成されます。

38.3.2 階層スキーマLDAPサーバーでの操作

表38-4に、サイトおよびロールの管理操作に対するシステム・レスポンスをまとめています。この操作は、それぞれ次のLDAPオプションのいずれかと統合されている3つのWebCenter Sitesシステムのインタフェースを使用して、WebCenter Sites管理者によって行われます。

- LDAPユーザーに対して読取り専用権限のあるLDAP-2サーバー(定義済)

- LDAPユーザーに対して書込み権限のあるLDAP-2サーバー

- LDAP-2以外のLDAPサーバー(この場合、書込み操作はサポートされていません)

各操作の結果は、表38-4の左側の列に記載した項で説明しています。

表38-4 階層スキーマLDAP (WebCenter Sites Webアプリケーション)でのサイトおよびロールの管理操作に対するシステム・レスポンス

WebCenter Sitesでの操作

結果

階層スキーマLDAP-2でのシステム・レスポンス: ユーザーは読取り専用権限を持つ(注1参照)

階層スキーマLDAP-2でのシステム・レスポンス: ユーザーは書込み権限を持つ(注2参照)

階層スキーマLDAPサーバー(LDAP-2以外)でのシステム・レスポンス: 書込みサポートなし(注3参照)

サイトを作成するためのLDAPサーバー・レスポンス

サイトが作成される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

サイトを編集するためのLDAPサーバー・レスポンス

サイトが編集される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

サイトを削除するためのLDAPサーバー・レスポンス

サイトが削除される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ロールを作成するためのLDAPサーバー・レスポンス

ロールが作成される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ロールを編集するためのLDAPサーバー・レスポンス

ロールが編集される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

ロールを削除するためのLDAPサーバー・レスポンス

ロールが削除される

WebCenter Sitesデータベース

WebCenter Sitesデータベース

WebCenter Sitesデータベース

サイトへのユーザー・アクセスを付与するためのLDAPサーバー・レスポンス

アクセス権限が付与される

エラーが返される(注4参照)

LDAP

予測不能

サイトへのユーザーのアクセス権を削除するためのLDAPサーバー・レスポンス

アクセス権限が削除される

WebCenter SitesデータベースもLDAPサーバーも応答なし

WebCenter SitesデータベースもLDAPサーバーも応答なし

WebCenter SitesデータベースもLDAPサーバーも応答なし

注意:

1. サイトおよびロールをLDAPサーバーに格納することはできません(WebCenter Sites管理者は、書込み権限のないユーザーとしてLDAPサーバーに接続されます)。

2. サイトおよびロールをLDAPサーバーに格納できます(WebCenter Sites管理者は、書込み権限のあるユーザーとしてLDAPサーバーに接続されます)。

3. LDAPサーバーはLDAP-2プロトコルをサポートしません(Netscapeサーバーなど)。非準拠LDAPサーバーの場合、管理者のインタフェースからそのLDAPサーバーへの書込み操作はサポートされません。

4.エラーが返されるとは、その操作が実行されない(システムがエラーを返す)ことを意味します。

38.3.3 サイトを作成するためのLDAPサーバー・レスポンス

サイト管理操作:

WebCenter Sites管理者が、「管理」タブの「サイト」ノードを使用してサイトの作成を試みます。

注意:

LDAP統合システムでサイトを手動で作成する場合、データベースとLDAPサーバーが同期していることを確認する必要があります。同期していない場合、サイトはWebCenter Sitesインタフェースに適切にリストされません。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースにサイトが作成されます。LDAP管理者は、LDAPサーバーにサイト・エントリを作成する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAPサーバー: WebCenter Sitesデータベースにサイトが作成されます。管理者は、LDAPサーバーでロール名の前に各サイト名を付けることで、使用可能なロールすべてのエントリを作成する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.3.4 サイトを編集するためのLDAPサーバー・レスポンス

サイト管理操作:

WebCenter Sites管理者が、「管理」タブの「サイトの編集」オプションを使用してサイトの説明の編集を試みます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースでサイトの説明が編集されます。(LDAPと統合されていても、サイトの説明はWebCenter Sitesデータベースにのみ格納されます。)

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースでサイトの説明が編集されます。(LDAPと統合されていても、サイトの説明はWebCenter Sitesデータベースにのみ格納されます。)

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.3.5 サイトを削除するためのLDAPサーバー・レスポンス

サイト管理操作:

WebCenter Sites管理者が、「管理」タブの「サイトの編集」ノードを使用してサイトの説明の削除を試みます。

注意:

LDAPが統合されている場合にサイトを手動で削除する際は、データベースとLDAPサーバーが同期していることを確認する必要があります。同期していない場合、サイトはWebCenter Sitesインタフェースに適切にリストされません。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースからサイトが削除されます。LDAP管理者は、LDAPサーバーからサイト・エントリを手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースからサイトが削除されます。LDAP管理者は、LDAPサーバーからサイト・エントリを手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.3.6 サイトへのユーザー・アクセスを付与するためのLDAPサーバー・レスポンス

サイト管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー」ノードを使用してユーザーにサイトへのアクセス権を付与することを試みます。

注意:

WebCenter Sitesには、そのデータベースに格納されているロールのみが表示されます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: LDAPサーバーでは選択されたサイトの指定されたユーザーにロールを割り当てることはできないため、エラー・メッセージが返されます。LDAP管理者が手動でロールを割り当てる必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバー内で、選択されたサイトの指定されたユーザーにロールが割り当てられます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: LDAPサーバーでは選択されたサイトの指定されたユーザーにロールを割り当てることはできないため、エラー・メッセージが返されます。LDAP管理者が手動でロールを割り当てる必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバー内で、選択されたサイトの指定されたユーザーにロールが割り当てられます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。

38.3.7 サイトへのユーザーのアクセス権を削除するためのLDAPサーバー・レスポンス

サイト管理操作:

WebCenter Sites管理者が、「管理」タブの「ユーザー」ノードを使用してサイトへのユーザーのアクセス権を削除することを試みます。

注意:

WebCenter Sitesには、そのインタフェースに格納されているサイトのみが表示されます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: LDAP管理者は、サイトに対するユーザーの権限をLDAPサーバーで直接手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返されます。LDAP管理者は、サイトに対するユーザーの権限をLDAPサーバーで直接手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: LDAPサーバーでサイトに対するユーザーの権限が直接削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。

38.3.8 ロールを作成するためのLDAPサーバー・レスポンス

ロール管理操作:

WebCenter Sites管理者が、「管理」タブの「ロール」ノードを使用してロールの作成を試みます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースにロールが作成されます。LDAP管理者は、LDAPサーバーでロールを手動で作成する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: エラー・メッセージが返され、LDAPサーバーでもWebCenter Sitesデータベースでもロールを作成できません。LDAP管理者は、LDAPサーバーでロールを作成する必要があります。同じロールを、WebCenter Sitesデータベースで再作成する必要があります。

2. 書込み権限のあるLDAP-2サーバー: WebCenter Sitesデータベースにロールが作成されます。ロールの名前の前に各既存サイトの名前が付けられて(SiteA-Role、SiteB-Roleなど)、LDAPサーバーに、使用可能なすべてのサイトのロールも作成されます。

注意:

LDAPサーバーとWebCenter Sitesデータベースの両方でロールが作成されるには、LDAPサーバーに1つ以上のサイトが存在している必要があります。サイトが存在しない場合、ロールはWebCenter Sitesデータベースでのみ作成されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。エラー・メッセージが返されることがあります。

38.3.9 ロールを編集するためのLDAPサーバー・レスポンス

ロール管理操作:

WebCenter Sites管理者が、「管理」タブの「ロール」ノードを使用してロールの説明の変更を試みます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースでロールの説明が変更されます。(LDAPと統合されていても、ロールの説明はWebCenter Sitesデータベースにのみ格納されます。)

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースでロールの説明が変更されます。(LDAPと統合されていても、ロールの説明はWebCenter Sitesデータベースにのみ格納されます。)

2. 読取り専用権限のLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

38.3.10 ロールを削除するためのLDAPサーバー・レスポンス

ロール管理操作:

WebCenter Sites管理者が、「管理」タブの「ロール」ノードを使用してロールの削除を試みます。

システム・レスポンス: 階層スキーマ:

1. 読取り専用権限のLDAP-2サーバー: WebCenter Sitesデータベースからロールが削除されます。LDAP管理者は、LDAPサーバーからこのロールを手動で削除する必要があります。

2. 書込み権限のあるLDAP-2サーバー: 前述(シナリオ1)のとおり応答します。

3. LDAP-2以外: 書込みサポートなし: 前述(シナリオ1)のとおり応答します。

システム・レスポンス: フラット・スキーマ:

1. 読取り専用権限のLDAPサーバー: エラー・メッセージが返され、LDAPサーバーでもWebCenter Sitesデータベースでもロールを削除できません。LDAP管理者は、LDAPサーバーでサイトとロールを作成する必要があります。同じサイトとロールを、WebCenter Sitesデータベースで再作成する必要があります。

2. 読取り専用権限のLDAP-2サーバー: WebCenter SitesデータベースとLDAPサーバーの両方からロールが削除されます。

3. LDAP-2以外: 書込みサポートなし: 動作は予測できません。エラー・メッセージが返されることがあります。

39 代替パブリッシュ方法

次の各トピックでは、WebCenter Sitesを使用する代替パブリッシュ方法について説明します。推奨するパブリッシュ方法はリアルタイムです。リアルタイム・パブリッシュの使用を参照してください。これらの方法とは、オンデマンド・パブリッシュ、ディスクへのエクスポートのパブリッシュ、サーバーへのミラーリングのパブリッシュおよびXMLへのアセットのエクスポートです。

この章の内容は次のとおりです。

- 代替パブリッシュ方法について

- オンデマンド・パブリッシュの使用方法

- 選択したアセットをパブリッシュ・セッションに対して非承認にする

- ディスクへのエクスポートのパブリッシュの用語の詳細

- 承認およびディスクへのエクスポートのパブリッシュの使用

- ディスクへのエクスポートのパブリッシュの使用

- パブリッシュ・ディスクへのエクスポートのプロセスに関するよくある質問

- パブリッシュの動作と機能の調査

- 承認テンプレートとパブリッシュ時テンプレートが異なる場合

- サンプル・テンプレートの使用

- ディスクへのエクスポートのページのレンダリング

- ディスクへのエクスポートのパブリッシュの理解

- パスの命名規則の使用

- ディスクへのエクスポートのパブリッシュに対するシステム構成

- サーバーへのミラーリングのパブリッシュの理解

- サーバーへのミラーリングのパブリッシュを構成する前に

- サーバーへのミラーリングのパブリッシュに対するシステム構成

- 配信WebCenter Sitesシステムからのログの取得

- XMLへのアセットのエクスポートのパブリッシュ方法

- XMLへのアセットのエクスポートに対するシステムの構成

- あるシステムから別のシステムへのサイトの移行

- 複数アセットの承認

- 宛先の作成

- 宛先の編集

- 宛先の削除

- エクスポート開始ポイントの作成

39.1 代替パブリッシュ方法について

この項では、WebCenter Sitesがサポートするパブリッシュ方法について説明します。図39-1 、図39-2 および図39-3 にパブリッシュ方法をまとめます。

ディスクへのエクスポートのパブリッシュの場合、Webサーバーが配信システムになります。CMシステム・データベース内の承認済アセットは、テンプレートを使用して、HTMLファイルとしてレンダリングされます。レンダリングされたファイルはファイル・システムに保存された後、FTPなどの転送プロトコルを使用して管理者によりWebサーバーにパブリッシュされます。このHTMLファイルは、サイト訪問者がパブリッシュされたコンテンツをリクエストすると、ページとしてブラウザに表示されます。

図39-1 ディスクへのエクスポートのパブリッシュ

サーバーへのミラーリングのパブリッシュの場合、WebCenter Sitesシステムが配信システムになります。承認済アセットとそれらのデータベース表が、CMシステム・データベースから配信システム・データベースにミラーリングされます。パブリッシュ・セッションの間中、パブリッシュ・システムは配信システム上のCacheManagerと通信して動作します。CacheManagerは、システムのページ・キャッシュを管理するWebCenter Sitesサーブレットです。CacheManagerによって、ミラーリングされるアセットを参照するページレットまたはページがキャッシュされることが保証されます。パブリッシュ・セッションが終了すると、CacheManagerはそれらのページを再生成して更新されたコンテンツを表示し、新しいページおよびページレットをキャッシュします。

パブリッシュされたコンテンツがサイト訪問者からリクエストされると、すぐにこれが提供されます。コンテンツは、テンプレートにより配信システムのデータベースから取得され、ブラウザに提供されて、最終的にページとしてレンダリングされます。

図39-2 サーバーへのミラーリングのパブリッシュ

XMLへのアセットのエクスポートの場合、データベース、またはWebCenter Sites以外のアプリケーションを実行する外部システムが、配信システムになります。パブリッシュ方法は、XMLファイルを出力するデータ変換方法です。このパブリッシュ方法では、Webサーバーで表示可能なページを作成するのではなく、エクスポートAPIを使用して、承認済アセットごとにXMLファイルを1つ作成します。

パブリッシュされたコンテンツがサイト訪問者からリクエストされると、すぐにこれが提供されます。コンテンツは、テンプレートにより配信システムのデータベースから取得され、ブラウザに提供されて、最終的にページとしてレンダリングされます。

図39-3 XMLへのエクスポートのパブリッシュ

39.2 オンデマンド・パブリッシュの使用方法

パブリッシュする場合、承認済アセット・リストの任意のアセットを選択的かつ即座にパブリッシュできます。これは、アセットのオンデマンド・パブリッシュと呼ばれます。

スケジュール済リアルタイム・パブリッシュと同様に、アセットが、すべての依存アセットとともにパブリッシュされます。このため、依存アセットもオンデマンド・キューに配置されます。

承認済アセットのリストは検索可能であり、パブリッシュが必要なアセットを容易に見つけられるようになります。選択したアセットがパブリッシュされた後、それらは、次のパブリッシュ・セッションに向けて、承認済アセット・リストから削除されます。

注意:

オンデマンド・パブリッシュでは、完了モードと遅延モードのいずれかを選択できます。パブリッシュ・モードの詳細は、リアルタイム・パブリッシュの使用を参照してください。

承認済アセットを即時パブリッシュで選択するには::

1. ボタン・バーの「パブリッシュ」をクリックして、「パブリッシュ・コンソール」を開きます。

2. 「パブリッシュの宛先」ドロップダウン・リストから、次を実行します。

a. アセットのパブリッシュ先となる、リアルタイム・パブリッシュの宛先を選択します。

b. 「宛先の選択」をクリックします。

3. 「パブリッシュの宛先」フォームで、「x個のアセットをパブリッシュする準備ができました。」リンクをクリックします。

図39-4 「パブリッシュの宛先」フォーム

「オンデマンド・キュー」タブが開きます。「承認済アセット」タブには、次のパブリッシュ・セッションに対して承認されたすべてのアセットがリストされます。

4. (オプション)承認済アセット全体を検索します。

a. 「検索」テキスト・ボックスに検索語句を入力します。

- 検索が、アセット名と説明に対して実行されます。

- ワイルドカードおよびブール演算子は使用できません。

b. 「検索」をクリックします。
「検索結果」タブが開き、検索結果が表示されます。

5. 「オンデマンド・キュー」にアセットを追加します。

注意:

オンデマンドでは、即時パブリッシュがサポートされています。オンデマンド・キューに入れるための選択は、現在のWebCenter Sitesセッションが存続している間のみ維持されます。ログアウトすると(またはシステムによって強制的にログアウトされると)、オンデマンド・キューが消去されます。

「承認済アセット」タブまたは「検索結果」タブのどちらかで、オンデマンド・キューに追加するアセットを選択し、次に「オンデマンド・キューへ追加」をクリックします。

依存性が計算されている間に、メッセージが表示されます。選択したアセットが、「承認済アセット」タブ(および、開いている場合は「検索結果」タブ)から削除されます。オンデマンド・キューが、選択したアセットとそれらの依存アセットによって更新されます。

6. オンデマンド・キューをパブリッシュします。次のいずれかを実行します。

- 選択したアセットがパブリッシュ可能であるとわかっている場合には、「承認済アセット」タブの「オンデマンド・キューのパブリッシュ」をクリックします。

- アセットをパブリッシュする前に確認する場合は、「オンデマンド・キュー」タブをクリックして、オンデマンド・キューに切り替えます。

- アセットの依存性を表示するには、アセットの行の左端にあるプラス記号をクリックします。

- アセットをオンデマンド・キューに入れた後に、そのアセットをパブリッシュしないことを決定した場合は、そのアセットを選択し、「オンデマンド・キューから除去」をクリックします。アセットが、オンデマンド・キューから削除され、「承認済アセット」のリストに戻されます。(操作の確認を求めるダイアログ・ボックスが表示されます。)

図39-5 「オンデマンド・キュー」タブ

7. 「OK」をクリックします。
「パブリッシュ・コンソール」が開き、処理中のパブリッシュ・セッションが表示されます。

8. パブリッシュ・セッションを確認する手順は、リアルタイム・パブリッシュの使用を参照してください。

39.3 選択したアセットをパブリッシュ・セッションに対して非承認にする

承認済アセットをパブリッシュしないように決めた場合は、承認済アセット・リストから選択的に削除できます。

アセットを非承認にするには::

1. ボタン・バーの「パブリッシュ」をクリックして、「パブリッシュ・コンソール」を開きます。

2. 「パブリッシュの宛先」ドロップダウン・リストから、次を実行します。

a. アセットのパブリッシュ先にするリアルタイム・パブリッシュの宛先を選択します。

b. 「宛先の選択」をクリックします。

3. 「パブリッシュの宛先」フォームで、「x個のアセットをパブリッシュする準備ができました。」リンクをクリックします。
「オンデマンド・パブリッシュ」フォームが開きます。このフォームには、「承認済アセット」タブと「オンデマンド・キュー」タブが表示されます。「承認済アセット」タブには、次のパブリッシュ・セッションに対して承認されたすべてのアセットがリストされます。

4. (オプション)承認済アセット全体を検索します。

a. 「検索」テキスト・ボックスに検索語句を入力します。

- 検索が、アセット名のみに対して実行されます。

- ワイルドカードおよびブール演算子は使用できません。

b. 「検索」をクリックします。
「検索結果」タブが開き、検索結果が表示されます。

5. 「承認済アセット」タブと「検索結果」タブのいずれかで、非承認にするアセットを選択します。「非承認」をクリックします。
選択したアセットが「承認済アセット」リストから削除されます。非承認にしたアセットに依存アセットがあり、これが現在のパブリッシュ・セッションで承認されている場合、非承認にしたアセットは保留キューに入れられます。

6. (オプション)パブリッシュが保留になったアセットを承認します。

a. 「戻る」をクリックして、「パブリッシュの宛先」フォームに戻ります。テキストのリンクが2つになっています。1つはパブリッシュが保留されたアセットを示し、もう1つはパブリッシュの準備が完了したアセットを示します。「x個のアセットのパブリッシュが保留されています」リンクをクリックします。

図39-6 パブリッシュの宛先

保留キューが開きます。

図39-7 保留キューのアセット

b. パブリッシュ・セッションで承認するアセットの「保留」リンクをクリックします。

「宛先へAssetのパブリッシュができない原因となっているアセット」 フォームが開きます。

- アセットに依存性がない場合、アセットが承認されたことを示すメッセージが開きます。

- アセットに依存性がある場合、依存アセットのリストが表示されます。

図39-8 サイトのパブリッシュができない原因となっているアセットのフォーム

依存アセットのリストを確認したら、表の見出し行のチェック・ボックスを選択して、リストのすべてのアセットを選択します。次に「承認」をクリックします。

アセットが承認されパブリッシュ可能であることを示すメッセージが表示され、アセットとその依存アセットが承認済アセット・キューに配置されて、保留キューに戻ります。

c. (オプション)他の保留アセットを承認するには手順bを繰り返します。

39.4 ディスクへのエクスポートのパブリッシュの用語の詳細

承認およびパブリッシュ・ステージの依存性がアセット・モデルにより決定されるミラー・パブリッシュと比較すると、ディスクへのエクスポートのパブリッシュは全面的にテンプレートによるプロセスです。承認テンプレートとパブリッシュ・テンプレートが、指定する依存性の点で異なる(お薦めしません)場合、未承認コンテンツがパブリッシュされる見込みが増大します。

テンプレートは、開発者がコード化します。ただし、パブリッシュ・セッションに悪影響を及ぼさないために、管理者(およびパブリッシュを実行するユーザー)は、起動するテンプレートおよび期待される結果について理解する必要があります。

注意:

ここで説明する用語は、ディスクへのエクスポートのパブリッシュにのみ適用されます。パブリッシュ・キー、依存性およびリファレンスといった用語は、ミラー・パブリッシュではまったく異なる意味を持ちます。

この項の内容は次のとおりです。

- ページ

- パブリッシュ・キー

- パブリッシュ・キュー

- プライマリ・アセット

39.4.1 ページ

ディスクへのエクスポートのパブリッシュのコンテキストでは、ページは、通常は、ディスクにエクスポートされるHTMLファイルを指します。(このファイルをページ・アセット・タイプと混同しないでください。)エクスポートされた各ページは、ページによって表されます。

39.4.2 パブリッシュ・キー

パブリッシュ・キー(またはパブキー)は、完全にパブリッシュ時にのみ使用される用語です。パブキーは最小パブリッシュ単位を表します。ディスクへのエクスポートのパブリッシュでは、エクスポートされたファイルで、ページと同等です。ページ・アセット・タイプと混同しないでください。

パブキーは、アセットおよびパブリッシュ時テンプレート(承認テンプレートと混同しないでください)という2つの構成要素で定義されます。

ディスクへのエクスポートのパブリッシュでは、最初のパブキーが、パブリッシュ・セッションを開始するユーザーによって定義される開始ポイントです。他のパブキーはすべて、パブリッシュ中に検出されて記録されます。

39.4.3 パブリッシュ・キュー

パブリッシュ・キューは、パブリケーションの待機中のパブキーのリストです。パブリッシュ・キューにパブキーを追加するには、そのプライマリ・アセットを承認する必要があります。

39.4.4 プライマリ・アセット

プライマリ・アセットは、パブキーの定義に使用します。わかりやすく言うと、プライマリ・アセットのIDとタイプが、テンプレートのcidパラメータとcパラメータになります。プライマリ・アセットのページをエクスポートするには、プライマリ・アセットを承認する必要があります。

注意:

承認されていないと判断されたプライマリ・アセットのページは、エクスポートされません。その結果、使用する承認テンプレートおよびパブリッシュ・テンプレートによっては、パブリッシュの宛先で機能しないリンクが作成される可能性があります。

ターゲット宛先に存在することが予想される依存性を検証できるように承認テンプレートをコード化する責任は、開発者にあります。

39.5 承認およびディスクへのエクスポートのパブリッシュの使用

ページをエクスポートするには、まずページのプライマリ・アセットを承認する必要があります。プライマリ・アセットの承認は、その依存アセットの承認状態が条件になります。これは、プライマリ・アセットの承認テンプレートで記述されます。依存アセットの依存性は、それ自体の承認テンプレートによって詳細に記述されます。

注意:

この承認テンプレートは必ずしもアセットのレンダリングに使用されるものではないので、承認システムを経由しないでアセットをパブリッシュすることは可能です。この意味合いなどの詳細は、パブリッシュの動作と機能の調査と承認テンプレートとパブリッシュ時テンプレートが異なる場合を参照してください。

また、(ページの非プライマリ・アセットに関連する)構成依存性(ディスクへのエクスポートのパブリッシュの使用を参照)は、承認しなくても、エクスポートされたページに表示されます(非承認アセットのフィルタリングの詳細は、Oracle WebCenter Sitesタグ・リファレンスの<render:filterタグを参照)。

この項の内容は次のとおりです。

- 承認テンプレートの使用

- 承認キューの使用

- 承認依存性の使用

39.5.1 承認テンプレートの使用

ディスクへのエクスポートのパブリッシュにおける承認により、開発者が依存性を定義することによって正しいコンテンツが原型を維持したままパブリッシュされることを保証できます。

承認およびパブリッシュ・ステージの依存性がアセット・モデルにより決定されるミラー・パブリッシュと比較すると、ディスクへのエクスポートのパブリッシュは全面的にテンプレートによるプロセスです。結果として、承認動作(およびパブリッシュ時動作)は、承認テンプレート(およびパブリッシュ時テンプレート)を記述した開発者によって定義されます。その後で、WebCenter Sitesが承認テンプレートを使用して、アセットの依存性を検出します。アセットが承認テンプレートに基づいてパブリッシュされている場合、その承認依存性と構成依存性は同じであると考えられます。詳細は、構成依存性の使用を参照してください。

承認テンプレートの割当てには、「パブリッシュの宛先」フォームの「デフォルト・テンプレートの設定」機能を使用します。

- デフォルト・テンプレートが明示的に選択されていない場合、承認システムはアセットのデフォルト・テンプレートを選択します。

- 承認テンプレートとデフォルト・テンプレートがどちらも指定されていない場合、アセットは、承認テンプレートを使用しないで承認されます(すなわち、承認依存性はありません)。

承認テンプレートが複数サイト間で共有されている場合、承認システムは現在のサイトに対応するサイト・エントリを選択します。

39.5.2 承認キューの使用

承認キューは、承認表が最新の状態に維持されるように、アセット変更イベントを処理します。たとえば、アセットがパブリケーションを承認された後に変更された場合、承認キューでアセットを非承認にする、すなわちパブリッシュ・キューから拒否することによってこの変更を処理します。

管理者が承認キューを直接操作することは決してありません。キューは、デフォルトでは5分間隔で実行されます。ただし、承認機能を使用する機能(「パブリッシュ」タブなど)を起動すると、承認情報を最新の状態に維持するために、それがレンダリングされる前に承認キューが強制的に実行されます。

39.5.3 承認依存性の使用

アセットを承認する場合、その承認テンプレート(Using the Approval Templateを参照)を使用して、承認依存性を判断します。承認依存性は、次のタグによって作成されます。

- <asset:load>

- <asset:loadall>

- <assetset:setasset>

- <assetset:setlistedassets>

- <render:logdep>

- <render:getpageurl>

- <render:gettemplateurl>

- <render:gettemplateurlparameters>

アセットAを承認する場合、そのテンプレート(またはテンプレートでコールされている他のエレメント)で前述のタグを使用してアセットBを参照していると、AのBに対する承認依存性が作成されます。これは一般に、Aを承認する場合は、Bも承認する必要があることを意味します。

承認依存性のタイプ

承認依存性は、承認時に作成、使用されます。パブリッシュ時依存性と混同しないでください(同一の場合もあります)。ディスクへのエクスポートのパブリッシュの承認には、2種類の承認依存性が含まれます。

- テンプレート依存性

- 参照依存性

テンプレート依存性は、アセットの承認テンプレートで別のアセットを使用してコンテンツを定義している場合に作成されます。たとえば、アセットAの承認テンプレートでアセットBをロードしている場合、AはBに対するテンプレート依存性を持ちます。もっと実際的な用語で言えば、記事アセットを表示するページ・アセットの承認テンプレートがある場合、記事アセットがページで使用されているので、テンプレート依存性になります。テンプレート依存性は、次のタグによって作成されます。

- <asset:load>

- <asset:loadall>

- <assetset:setasset>

- <assetset:setlistedassets>

- <render:logdep>

参照依存性は、あるページから別のページへのリンクが作成される際に生成されます。これらは、2つのページのプライマリ・アセット間の参照依存性として登録されます。たとえば、アセットAの承認テンプレートから、アセットBがプライマリ・アセットであるページへのリンクを作成した場合、承認システムはこれをアセットAのBに対する参照依存性として登録します。このような依存性を生成するタグは次のとおりです。

- <render:getpageurl>

- <render:gettemplateurl>

- <render:gettemplateurlparameters>

(ディスクへのエクスポートのパブリッシュにおける)テンプレート依存性は、exact依存性がデフォルトです。Bが変更されている場合、Aを承認するにはBを承認する必要があります。参照依存性は、常にexists依存性です。Bを一度承認してパブリッシュした場合、Aを再パブリッシュするためにBを再承認する必要はありません。

いずれかのタグでdeptype="none"が設定されている場合は例外です。その場合、そのタグによって承認依存性は一切作成されません。このことは、そのレコードが承認中に作成されないことを意味します。ディスクへのエクスポートのパブリッシュおよびライブ・サイトなど、他のすべてのコンテキストでは、deptype属性は無視されます。

39.6 ディスクへのエクスポートのパブリッシュの使用

ディスクへのエクスポートのパブリッシュ・プロセスでは、3つの主なコンポーネントを使用します。

- パブリッシュ時テンプレートの使用

- 開始ポイントの使用

- 構成依存性の使用

39.6.1 パブリッシュ時テンプレートの使用

パブリッシュ時テンプレートの目的は、コンテンツをファイルとしてレンダリングすることです。通常は、パブリッシュ時テンプレートは承認テンプレートと同一です。両者が異なる場合は、事前に承認しなくてもコンテンツをパブリッシュできます。承認システムをバイパスするには、パブリッシュ可能なコンテンツを検証できる手段を開発者が提供する必要があります。

39.6.2 開始ポイントの使用

開始ポイントは、パブリッシュ時にエクスポートを開始するパブキーです。通常、開始ポイントは、サイトで、すべてのページではなくても、最も多くのページにリンクするように選択されます。(このページは、必ずしもホームページではありません。たとえば、多数のリンクが設定されているサイドバーにすることもできます。)ディスクへのエクスポートのパブリッシュ・システムは、開始ポイントを起点にしてサイトをクロールし、新しいパブキーを検出すると、それを記録します。

39.6.3 構成依存性の使用

構成依存性は、アセットを使用して生成されたページのアセットに対する依存性です。これらはページのパブリッシュ時テンプレートの使用のロジックによって決まります。構成依存性は、エクスポートされたページにレンダリングする内容をテンプレートの指示に従って決定し、その際deptype属性は完全に無視されます。承認テンプレートでテンプレート依存性と参照依存性を作成したタグと同じタグで、パブリッシュ時の構成依存性も作成します。タグのリストは、承認依存性の使用を参照してください。

39.7 パブリッシュ・ディスクへのエクスポートのプロセスに関するよくある質問

承認テンプレートはどのように選択すればよいですか。

承認テンプレート(指定されている場合)は、特定のアセットを検証するために承認システムが使用する唯一のテンプレートです。このテンプレートは、開始ポイントの設定内容によっては、パブリッシュ時に使用されない場合もあります。最善策として、想定するアセットの依存性が最もよく表現されている承認テンプレートを設定することをお薦めします。

依存性の最も代表的な組合せが含まれるテンプレートが、アセットをパブリッシュする際に必要なテンプレートと異なる場合はどうなるでしょうか。そのテンプレートはそのタイプのアセットの承認テンプレートとして設定し、必要なテンプレートは開始ポイントとして使用してください。

データ・モデル依存性は何か関係ありますか。

アソシエーション、属性などは、ディスクへのエクスポートのパブリッシュでは使用しません。重要なのはテンプレートで設定されている依存性のみです。

パブリッシュ時の構成依存性が追跡されるのはなぜですか。

ページをエクスポートした後、そのコンテンツは凍結されます。しかし、そのページの生成に使用したアセットが変化して、影響を受けるページが古くなる可能性があります。

WebCenter Sitesは、依存性を記録しているので、(古くなったページを再パブリッシュするという前提で)更新する必要があるページを管理者に通知できます。WebCenter Sitesには、再パブリッシュのオプションとして、自動リフレッシュと手動リフレッシュの2つが用意されています。

- 自動リフレッシュの場合、ページは自動的に次回のパブリッシュ・セッション用にキューに追加されるので、変更された構成依存性を承認する必要はありません。
このオプションを選択した場合、ページをパブリッシュのキューに追加するために、変更されたアセットを承認する必要はありません。つまり、イメージ・アセットを変更するとすぐに、記事ページが再パブリッシュされます。自動リフレッシュを設定するには、記事とイメージの間にexists依存性または依存性なしを指定します。これによって、承認システムがアセットの承認をユーザーに要求する処理が無効になります。

- 手動リフレッシュでは、更新されたページをパブリッシュする前に確認します。
このオプションを選択した場合、影響を受けるページは、承認されるまで「保留」になります。つまり、イメージが変更されるたびに、記事ページを再承認する必要があります。これが機能するには、exact依存性を設定する必要があります。

39.8 パブリッシュの動作と機能の調査

ここでは、ディスクへのエクスポートのパブリッシュの動作を示す簡単なシナリオについて説明します。

- テンプレート依存性の調査

- 参照依存性の調査

関連するアセット・タイプは、ページおよびHelloArticle (HelloAssetWorldより)です。テンプレートは、Ttemplate、RTemplateおよびdummyTemplateです。

わかりやすくするために、アセットIDはテンプレートにハードコードされています。通常はハードコードではなく、なんらかの方法でアセットがロードされます。したがって、開発者は、依存性を追加設定しない場合、タグにdeptype='none'属性を設定する必要があります。テンプレート・コードの詳細は、サンプル・テンプレートの使用を参照してください。

39.8.1 テンプレート依存性の調査

設定: ページPアセットは、承認およびパブリッシュの両方でTtemplateを使用します。TtemplateはHelloArticle Aをロードするので、テンプレート依存性が確立します。

開始ポイント: P+Ttemplate

パブキー(エクスポートされたファイル): P+Ttemplate

承認依存性: ページPには、<render:logdep>によるTtemplateに対するテンプレート依存性および<asset:load>によるHelloArticle Aに対するテンプレート依存性があります。Ttemplateはリンクを作成しないので、参照依存性はありません。

パブリッシュ依存性: 開始ポイントが唯一のパブキーなので、1つのファイルのみエクスポートされます。

エクスポートされるページは、テンプレートで実際に使用されることがないので、パブリッシュ時の構成依存性がありません。Pを承認する必要がある唯一の理由は、Pがエクスポートされるページのプライマリ・アセットだからです。したがって、パブリッシュ時に決定される唯一の構成依存性は、エクスポートされるページのAおよびTtemplateに対する依存性です。

表39-1 テンプレート依存性

アクション

承認ステータス

パブリッシュ・ステータス

コメント

初期

承認済: P、A、Ttemplate

パブリッシュ済: AおよびTtemplate

Pは、テンプレートによって参照されていないので、パブリッシュされませんでした。

Pの編集

PのステータスがChangedになります。

変更による影響はありません。

Pに対する構成依存性がないため、変更による影響はありません。

Aの編集

PのステータスがHeldになります。

AのステータスがChangedになり、Pの再承認が必要になります。

承認後にページが再パブリッシュされます。

Pは、Aに対してテンプレート依存性を持つので保留されますが、後で承認されることによって再びパブリッシュ可能になります。

39.8.2 参照依存性の調査

設定: ページPアセットは、承認およびパブリッシュの両方でRtemplateを使用します。RtemplateはHelloArticle Aを参照し、AはdummyTemplateによってレンダリングされます。

開始ポイント: P+Rtemplate

パブキー(エクスポートされたファイル): P+Rtemplate、A+dummyTemplate

承認依存性: ページPは、そのRtemplateに対して所定の<render:logdep>テンプレート依存性があります。また、<render:getpageurl>によりAに対して参照依存性を持ちます(ただし、dummyTemplateに対する依存性はありません。これは、ページ間の依存性は、それらのプライマリ・アセット間でのみ記録されるからです)。dummyTemplateはどのタグからも参照されないので、承認依存性には関与しません。

パブリッシュ依存性: 関連するタグは<render:logdep>および<render:getpageurl>です。これらのタグにより、RtemplateおよびAとしてパブリッシュ時の構成依存性が決定します。前述したように、ページPは、どのテンプレートからも使用されていないので、構成依存性がありません。エクスポートで<render:getpageurl>を検出することによって、別のページが必要であることがわかるので、すぐにA+dummyTemplateパブキーを作成し、dummyTemplateを実行してそのコンテンツを生成します。dummyTemplateは、どのタグからも使用されないので、正式な構成依存性はなく、パブキー・メンバーとしてのみ関与します。したがって、dummyTemplateが変更されても、承認およびパブリッシュ・サイクルではそのことが認識されません。そのため、新しく作成するすべてのテンプレートに出現する<render:logdep>は、変更しないことをお薦めします。

表39-2 参照依存性

アクション

承認ステータス

パブリッシュ・ステータス

コメント

初期

承認済: P、A、Rtemplate

パブリッシュ済: AおよびRtemplate

Pは、テンプレートによって参照されていないので、パブリッシュされません。その結果、 P+Ttemplateおよび A+dummyTemplateの2つのHTMLファイルが生成されます。

Pの編集

PのステータスはChangedになり、承認によって現状に戻ります。

変更による影響はありません。

Pに対する構成依存性がないため、変更による影響はありません。

Aの編集

AのステータスはChangedになります。Pは、Aに対するexists依存性のみがある(Pを保留する理由はありません)のでApprovedのままであり、Heldにはなりません。

<render:getpageurl> によって構成依存性が生成されるので、P+Rtemplateは自動的に再パブリッシュ用にキューに追加されました。(理由が不明な場合は読み進めてください)。

A+dummyTemplateは、Aを使用していないので、影響を受けません。

A+dummyTemplateは、Aを使用するタグが存在しないので、影響を受けません。

39.9 承認テンプレートとパブリッシュ時テンプレートが異なる場合

一般に、承認とパブリッシュに同じテンプレートを使用する場合は、承認依存性と構成依存性が一致するので、問題は発生しません。承認とパブリッシュに使用するテンプレートが異なる場合、問題が発生するきっかけになります。テンプレートの不一致は様々な状況で発生する可能性があります。テンプレート・コードの詳細は、サンプル・テンプレートの使用を参照してください。

この項の内容は次のとおりです。

- テンプレートの区別: 例1

- テンプレートの区別: 例2

- テンプレートの区別: 例3

39.9.1 テンプレートの区別: 例1

アセットAで承認にT1を使用します。T1はどのアセットも参照しません。アセットAは、パブリッシュにT2を使用します。T2は、<asset:load>を使用してアセットBを参照します。T2がアセットBをロードすると、一度も承認されていないにもかかわらず、BはエクスポートされるA+T2ページに表示されます。

これは、一度も承認されていないアセットをパブリッシュできることを意味するのでしょうか。

そのとおりです。この方法を選択するユーザーも存在しますが、結局はパブリッシュする前にアセットを承認する手間を省いているにすぎません。承認は負担の多い作業になる可能性があります。なぜなら、exact依存性を持つ場合、依存アセットが変化することでプライマリ・アセットにHeldステータスが割り当てられるからです。その結果、そのようなプライマリ・アセットが含まれるページはエクスポートできなくなります。このような状況では、deptype属性で値としてexistsまたはnoneを使用して、不要な承認依存性を避ける方法が適しています。

ここで、アセットBをパブリッシュした後にBを変更するとどうなるでしょうか。この場合、アセットAとアセットBの間に、承認依存性はありませんが、構成依存性があります。アセットBが変化するたびに、影響を受けるページは自動的に再パブリッシュされます。(依存性がないので、自動リフレッシュ・オプションが選択されます)。したがって、アセットBが未承認のまま保存されるとすぐに、A+T2が自動的にパブリッシュ・キューに追加されます。再パブリケーション・オプションの詳細は、パブリッシュ・ディスクへのエクスポートのプロセスに関するよくある質問を参照してください。

39.9.2 テンプレートの区別: 例2

アセットAで承認にT1を使用します。T1は、exact依存性に従って、<asset:load>を使用してアセットBを参照します。アセットAは、パブリッシュにT2を使用します。T2は、アセットBを参照しません。

この場合、アセットAとアセットBの間に、承認依存性はありますが、構成依存性はありません。アセットBが変更されるたびに、アセットAを承認できるようにするには、パブリッシュされるページでアセットBを使用していなくても、アセットBを承認する必要があります。

39.9.3 テンプレートの区別: 例3

アセットAで承認にT1を使用します。T1はどのアセットも参照しません。アセットAは、パブリッシュにT2を使用します。T2は、<asset:getpageurl>を使用してアセットBを参照します。

この場合、承認依存性はないので、Aは単なる承認済アセットです。A+T2のパブリッシュ中に、Bをプライマリ・アセットとする別のページが作成されることに気づきます。ここで、プライマリ・アセットは、そのページがエクスポートされる前に承認される必要があることを思い出してください。しかし、Bは承認されていないので、そのページはエクスポートされません。A+T2はエクスポートされますが、機能しないリンクが発生します。

不明な依存性が存在する場合のディスクへのエクスポートのパブリッシュ。<render:unknowndeps>を使用し始めると、状況が複雑になります。このタグは、構成依存性を削除し、パブキーに不明な依存性を記録します。したがって、アセットはパブリッシュ・キューに恒久的に残ります(つまり、アセットはパブリッシュ・サイクルのたびにリフレッシュされます)。これは予想される動作です。なぜなら、不明な依存性が存在する場合(すなわち、問合せの結果のように、依存性がいつでも変化する可能性がある場合)、特定のアセットがどのアセットに依存するかが判断できないからです。大事をとって、常にアセットが再パブリッシュされます。

多数のexact依存性が存在する場合。必ず避けられるわけではありませんが、プライマリ・アセットが他のアセットに対してexact依存性を持つ場合、いずれかの依存アセットが変更されると、承認システムはプライマリ・アセットのステータスをHeldに変更することに留意してください。プライマリ・アセットのページは、再承認されなければ、パブリッシュ可能になりません。変更されたアセットが多数のページで使用されている場合、それらのページをすべて再承認する必要があります。deptypeをexistsに設定することも考えられます。その場合、依存ページは自動的にパブリッシュ可能になります。ただし、変更されたアセットは、パブリッシュ・セッションが開始するときは準備が完了している必要があります。

注意:

(simplenameを使用しないで)エクスポートURLをカスタマイズする望ましい方法は、<render:getbloburl>および<render:getpageurl>のパラメータとしてPREFERREDFILEおよびPREFERREDDIRを使用して任意の名前を指定する方法です。例:

<render:getbloburl blobtable='MungoBlobs'
blobcol='urldata' blobkey='id'
blobwhere='1088466917821'  outstr='pagelogoURL'
csblobid='1088466917821'>

<render:argument name='PREFERREDFILE'
value='myBlob.out'/>
<render:argument name='PREFERREDDIR' value='myDir'/>
</render:getbloburl>

このコードは、1088466917821のBLOBをmyDir/myBlob.outにエクスポートします。

39.10 サンプル・テンプレートの使用

この項では、パブリッシュの動作と機能の調査および承認テンプレートとパブリッシュ時テンプレートが異なる場合の例で使用されているテンプレート実装を示します。Taglib定義とimport定義は省略されています。

Ttemplate:

<%-- Record dependencies for the Template --%>
<ics:if
condition='<%=ics.GetVar("tid")!=null%>'><ics:then><render:logdep
cid='<%=ics.GetVar("tid")%>' c="Template"/></ics:then></ics:if>
<asset:load name='myArticle' type='HelloArticle'
objectid='1156878442427'/>

Rtemplate:

<%-- Record dependencies for the Template --%>
<ics:if
condition='<%=ics.GetVar("tid")!=null%>'><ics:then><render:logdep
cid='<%=ics.GetVar("tid")%>' c="Template"/></ics:then></ics:if>
<render:getpageurl outstr="myURL" pagename='HelloAssetWorld/
dummyTemplate' cid='1156878442427' c='HelloArticle'/>
Got URL: <a href='<%=ics.GetVar("myURL")%>'> Click here</a><br/>

dummyTemplate:

空白です。logDepはありません。

39.11 ディスクへのエクスポートのページのレンダリング

簡単に言うと、WebCenter Sitesは、ディスクへのエクスポートのページを次のようにレンダリングします。

- クライアント・ブラウザがページ名をWebCenter Sitesに(HTTPまたは別のプロトコルを使用して)送信します。

- WebCenter SitesはSiteCatalog表でページを検索し、ルート・エレメントを起動し、ページをHTMLファイルとしてレンダリングします。

- オンライン・サイトをホストするWebサーバーに(FTPまたは別のファイル転送プロトコルを使用して)ファイルをパブリッシュします。
ディスクへのエクスポートのパブリッシュ方法を使用する管理ユーザーは通常、配信システムのWebサーバーに移動する前にレンダリングされたファイルをテストする品質保証プロセスを設定します。図39-9にこのレンダリングを示します。

図39-9 ディスクへのエクスポートのレンダリング

39.12 ディスクへのエクスポートのパブリッシュの理解

ディスクへのエクスポートを使用してコンテンツをパブリッシュする際、承認システム、パブリッシュ・スケジュールおよび宛先構成はすべて、承認済アセットの静的HTMLファイルへのエクスポートに寄与します。

ディスクへのエクスポートのパブリッシュ・セッションが実行されると、次のようになります。

1. パブリッシュ・システムは、特定の宛先に対するセッションを開始しようとしていることを、CacheManagerサーブレットに通知します。CacheManagerは、その宛先に対してこれまでにエクスポートされたすべてのページを、ソース・システムのページ・キャッシュから消去します。
パブリッシュ・セッション中は、エクスポートされたファイルがページ・キャッシュにキャッシュされます。構成されているキャッシュの消去間隔(有効期限)よりも短い間隔でパブリッシュ・セッションが発生する場合、キャッシュ内のエクスポート済ページと同じ名前のページが新しくエクスポートされる可能性があります。これを防止するため、CacheManagerサーブレットは、新しいパブリッシュ・セッションが開始される前にページ・キャッシュを消去します。

2. WebCenter Sitesは、エクスポート・キューを作成し、パブリッシュ可能な参照をすべてキューに追加します。パブリッシュできる参照は、次のとおりです。

- エクスポート開始ポイントとして指定されているパブキー。詳細は、エクスポート開始ポイントの使用を参照してください。
サイトには開始ポイントが必要であり、そのアセットを承認する必要があります。そうしないと、エクスポート・セッションを開始できません。エクスポートするサイトにはすべて、少なくとも1つのエクスポート開始ポイントを指定する必要があります。

- 以前エクスポートされたが、この宛先への前回のパブリッシュ・セッションの後にアセットが変更され、再承認されたページまたはページレット(参照)。(サイトがパブリッシュされると、パブリッシュ・システムはパブリッシュされている参照を認識します。PublishedAssets表のデータを読み取り、アセットが変更され、再度この宛先に対して承認された参照があれば、それをエクスポート・キューに追加します。)

- テンプレートでRENDER.UNKNOWNDEPSタグを使用しているアセット。
このタグは、テンプレートによってレンダリングされるアセットの依存性が不明なので計算できないことを、承認システムに通知します。通常は、問合せに使用します。依存性が不明な場合、システムは、依存性の変化によりアセットをパブリッシュする必要があるかどうかを判断できません。このタグが存在することは、セッションのたびにアセットをパブリッシュする必要があることを意味します。

- まだパブリッシュされたことがなく、RENDER.GETPAGEURLタグによって別のページまたはページレットに接続しているページまたはページレット(参照)。(つまり、別のページから参照され、まだパブリッシュされていないページまたはページレット。)

- RENDER.SATELLITEPAGEタグまたはsatellite.pageタグで指定されているページまたはページレット(参照)。

3. WebCenter Sitesは、最初のエクスポート開始ポイントでそのアセットが承認済かどうかを判断します。

- アセットが承認済ではない場合、パブリッシュ・セッションは終了します。

- WebCenter Sitesにより、アセットが承認済である場合、アセットに割り当てられているテンプレートのページ名を決定します。

4. WebCenter Sitesは、次の情報をWebCenter Sitesに渡すことによって、エクスポート開始ポイントをレンダリングします。

- 開始ポイントのテンプレートのページ名。

- export[destinationID]に設定されているrendermode変数。

- レンダリングされるファイルが保存されるエクスポート・ディレクトリの名前と場所。

5. WebCenter Sitesはページ名のルート・エレメントを起動し、そのエクスポート開始ポイントに参照として接続されているすべての承認済アセットのレンダリングを開始します。WebCenter Sitesでは、レンダリングしたページをブラウザにポストするのではなく、ファイルに書き込みます。

6. WebCenter Sitesは、ファイルをレンダリングするたびに、その参照に関するメッセージを、現在のセッションのパブリッシュ・ログに書き込みます。

7. エクスポート開始ポイントが複数存在する場合は、この説明の手順3から繰り返します。

8. パブリッシュ・セッションが正常に完了したら、WebCenter Sitesはパブリッシュした参照に関する情報をPubKey表とPublishedAssets表に書き込んで、セッションを終了します。

9. WebCenter Sitesはさらに、パブリッシュされたアセットに関する情報を、ApprovedAssets表とApprovedAssetDeps表に書き込みます。アセットがパブリッシュされた時点の最新のアセットのフィールドから取得した日付が記録されるので、アセットが次に承認されるときに、承認システムが正しく依存性を計算できます。

39.13 パスの命名規則の使用

WebCenter Sitesは、パブリッシュするアセットのタイプおよびアセットに設定されている可能性があるパス情報に応じて、エクスポートするファイルへのパスを命名します。エクスポート・パスには、1つのディレクトリのような単純なパスも、複数のディレクトリによるパスも使用でき、オペレーティング・システムでサポートされている文字数によってのみ制限されます。

エクスポート・パスの命名規則は次のとおりです。

<cs.pgexportfolder>/<DIR>/<file_dir>

<cs.pgexportfolder>は、必須ディレクトリです。サブディレクトリは条件付きです。<file_dir>を使用するかどうかは、パブリッシュ引数SIMPLEDIRによって決まります。

この後は、エクスポート・パス変数およびパブリッシュ引数SIMPLEDIRについて定義した後、使用可能なエクスポート・パスについてまとめます。

この項の内容は次のとおりです。

- エクスポート・パス変数とSIMPLEDIRの使用

- エクスポート・パスの構成の使用

- エクスポートされたファイル内のリンクのパスの使用

- ファイルの命名規則の使用

- エクスポート開始ポイントの使用

39.13.1 エクスポート・パス変数とSIMPLEDIRの使用

エクスポート・パス変数は、次のように定義されます。

- <cs.pgexportfolder>は、エクスポートされるすべてのファイルのルート・ディレクトリを定義します。<cs.pgexportfolder>は、wcs_properties.jsonファイルのcs.pgexportfolderプロパティの値です。これは必要な値であり、ディスクへのエクスポートのパブリッシュのすべての宛先に適用されます。
通常、<cs.pgexportfolder>は、直接配信システムの場所ではなく、テスト用の場所(エクスポートされたファイルの検証が行われるファイル・システム)を指定します。

- <DIR>は、パブリッシュ引数DIRの値であり、ルート・ディレクトリ(cs.pageportfolderで指定)にサブディレクトリを作成するために使用します。<DIR>が指定されている場合、WebCenter Sitesによって<cs.pgexportfolder>/<DIR>が作成されます。

注意:

管理者は、「新規宛先の追加」フォームの「ベース・ディレクトリ」フィールドとしてパブリッシュ引数DIRを使用できます(エクスポート先の構成参照)。この項で<DIR>と記述する場合、「ベース・ディレクトリ」を意味します。

この引数は、通常は、サイトに複数のエクスポート先が存在する場合に、ルート・エクスポート・ディレクトリのコンテンツを整理するために使用します。

注意:

<cs.pgexportfolder>または<cs.pgexportfolder>/<DIR>で指定されているディレクトリは、宛先ディレクトリと呼ばれます。

- <file_dir>には、次のリストのいずれかの値を設定します。どの値を設定するかは、エクスポートされるアセットがページ・アセットかどうか、およびパス情報が使用可能かどうかによって決まります。WebCenter Sitesはリストの順序に従って値を調べるので、<file_dir>は階層的に決まります。これは、SIMPLEDIR=falseが設定されていると想定しています。

表39-3 設定可能なfile_dirの値

設定可能な<file_dir>の値

説明

<ForDestination:Path>

「宛先: パス」フィールドの値(このフィールドは特定の宛先の「宛先のパス/ファイル名の指定」フォームに表示されます)。

「宛先: パス」フィールドに値を設定すると、指定された宛先にエクスポートされたアセットに指定されたパスが強制的に与えられます。

WebCenter Sitesにより、<ForDestination:Path>が設定されていない場合は<parent_page's_path>を使用します。

<parent_page's_path>

エクスポートしたアセットの親ページの「パス」フィールドの値。

ページ・アセットの注意: エクスポートされたページ・アセットには、それ自体に設定されているパスではなく、その親ページに設定されているパスが与えられます。(一般に、ページ・アセットの「パス」は子アセットにのみ適用されます。)

WebCenter Sitesにより、<parent_page's_path>が設定されていない場合は<ID_of_parent_page>を使用します。

<asset's_path>

エクスポートしたアセットの「パス」フィールドの値。

注意: <asset's_path>は、ページ・アセットを除くアセットの場合のみ使用します。WebCenter Sitesにより、<asset's_path>が設定されていない場合は、<file_dir>の値として<ID_of_parent_page>を使用します。WebCenter Sitesにより、<parent_page's_path>と<asset's_path>がどちらも設定されていない場合は<ID_of_parent_page>を使用します。

<ID_of_parent_page>

アセットの親ページのID。この値は、<parent_page's_path>と<asset's_path>がどちらも不明な場合に使用します。

- SIMPLEDIR。このパブリッシュ引数は、エクスポート・パスを明示的に構成するのではなく、パス情報が設定されていない場合に<file_dir>を使用するかどうかを決定します。この決定は、次のように行われます。

- SIMPLEDIRがtrueに設定され、さらにパス情報が設定されていない場合、エクスポート・パスでは<file_dir>が省略されます。パスを設定すると、SIMPLEDIRはオーバーライドされます。

- SIMPLEDIRがfalseに設定され、さらにパス情報が設定されていない場合、<file_dir>の値として<ID_of_parent_page>を使用します。

注意:

管理者は、「新規宛先の追加」フォームの「ディレクトリに単純な名前を使用」チェック・ボックスとしてパブリッシュ引数SIMPLEDIRを使用できます(エクスポート先の構成を参照)。

39.13.2 エクスポート・パスの構成の使用

この項では、WebCenter Sitesが次の規則に従って構成可能なエクスポート・パスについてまとめます。

<cs.pgexportfolder>/<DIR>/<file_dir>

この規則の詳細は、パスの命名規則の使用を参照してください。この項のすべての例で、変化するのは<file_dir>のみです

この項の内容は次のとおりです。

- エクスポート・パスの強制指定の使用

- ページ・アセットのエクスポート・パスの使用

- ページ以外のアセットのエクスポート・パスの使用

- サンプルのエクスポート・パスの使用

39.13.2.1 エクスポート・パスの強制指定の使用

<ForDestination:Path> (エクスポート・パス変数とSIMPLEDIRの使用で定義)が指定されている場合、指定された宛先にパブリッシュされるアセットには、他のパス情報が設定されているとしても、ここで指定されているパスが強制的に与えられます。アセットのフル・エクスポート・パスは次のとおりです。

<cs.pgexportfolder>/<DIR>/<ForDestination:Path>

39.13.2.2 ページ・アセットのエクスポート・パスの使用

<ForDestination:Path>が設定されていない場合、WebCenter Sitesは次のようにエクスポート・パスを構成します(例は表39-4を参照)。

- <parent_page's_path>が指定されている場合、ページ・アセットのエクスポート・パスは次のように構成されます。

<cs.pgexportfolder>/<DIR>/<parent_page's_path>

(<asset's_path>が指定されている場合も同じ)。

注意:

エクスポートされたページ・アセットには、それ自体に設定されているパスではなく、その親ページに設定されているパスが与えられます(つまり、<file_dir>の値が<parent_page's_path>になります)。

一般に、ページ・アセットの「パス」情報は子アセットにのみ適用されます。

- <parent_page's_path>が指定されていない場合:

- SIMPLEDIR=falseである場合、WebCenter Sitesは<ID_of_parent_page>を使用します。

<cs.pgexportfolder>/<DIR>/<ID_of_parent_page>

- SIMPLEDIR=trueである場合、WebCenter Sitesは<file_dir>を省略します。

<cs.pgexportfolder>/<DIR>

39.13.2.3 ページ以外のアセットのエクスポート・パスの使用

ページ以外のアセットの場合、WebCenter Sitesは、使用可能な情報に応じてエクスポート・パスを構成します(例は表39-5を参照)。

- <asset's_path>が指定されている場合、エクスポート・パスは次のように構成されます。

<cs.pgexportfolder>/<DIR>/<asset's_path>

- <asset's_path>が指定されていない場合、WebCenter Sitesは<parent_page's_path>を使用します。

<cs.pgexportfolder>/<DIR>/<parent_page's_path>

- <asset's_path>と<parent_page's_path>がどちらも指定されていない場合、次のように構成されます。

- SIMPLEDIR=falseである場合、WebCenter Sitesは<ID_of_parent_page>を使用します。

<cs.pgexportfolder>/<DIR>/<ID_of_parent_page>

- SIMPLEDIR=trueである場合、WebCenter Sitesは<file_dir>を省略します。

<cs.pgexportfolder>/<DIR>

39.13.2.4 サンプルのエクスポート・パスの使用

次の各表は、アセットのサンプルのエクスポート・パスを示します。

表39-4 SIMPLEDIR=falseの場合のページ・アセットのサンプルのエクスポート・パス

ページ・アセット

cs.pgexportfolder

DIR

file_dir

エクスポート・パス

該当なし

該当なし

該当なし

asset's_path

parent_page's_path

ID_of_parent_page

該当なし

ホーム

/export

該当なし

/abstracts

該当なし

該当なし

/export

ホーム

/export

/Japan

/abstracts

該当なし

該当なし

/export/Japan

世界のニュース

/export

/Japan

/abstracts

/news/

998877665

/export/Japan/news

世界のニュース

/export

該当なし

/abstracts

/news/

998877665

/export/news

世界のニュース

/export

/Japan

/abstracts

該当なし

998877665

/export/Japan/998877665

世界のニュース

/export

該当なし

/abstracts

該当なし

998877665

/export/998877665

表39-5 SIMPLEDIR=falseの場合のページ以外のアセットのサンプルのエクスポート・パス

ページ以外のアセット

cs.pgexportfolder

DIR

file_dir

エクスポート・パス

該当なし

該当なし

該当なし

asset's_path

parent_page's_path

ID_of_parent_page

該当なし

石油価格

/export

/Japan

/energy

該当なし

997766554

/export/Japan/energy

石油価格

/export

/Japan

/energy

/news/

997766554

/export/Japan/energy

石油価格

/export

該当なし

/energy

/news/

997766554

/export/energy

石油価格

/export

/Japan

該当なし

/news/

997766554

/export/Japan/news

石油価格

/export

/Japan

該当なし

該当なし

997766554

/export/Japan/997766554

石油価格

/export

該当なし

該当なし

該当なし

997766554

/export/997766554

39.13.3 エクスポートされたファイル内のリンクのパスの使用

エクスポートされたファイル内のHREFリンクに記述されるURLには、宛先ディレクトリ(<cs.pgexportfolder>/<DIR>)を示す値は含まれていません。かわりに、宛先ディレクトリ内から始まる相対ディレクトリとして記述されます。

宛先構成フォームの「URL接頭辞」フィールドで配信システム上のファイルの場所を指定することによって、URLを解決します。つまり、エクスポートされたファイル内のリンクのURLは、次のように作成されます。

<URLPREFIX>/<path_of_parent_page>

「URL接頭辞」の値は、ファイルが置かれているディレクトリを指定するWeb別名の値と一致する必要があります。cs.pgexportfolderのみを使用して宛先ディレクトリを作成している場合、「URL接頭辞」が表すWeb別名でその場所が指定されている必要があります。さらに、宛先構成フォームの「ベース・ディレクトリ」フィールドを設定してcs.pgexportfolderで指定されるルート・ディレクトリにサブディレクトリを追加している場合は、「URL接頭辞」が表すWebルートまたはWeb別名でこのディレクトリが指定されるようにします。

39.13.4 ファイルの命名規則の使用

WebCenter Sitesがエクスポートされたファイルに付ける名前は、アセットがファイル名を(「調査」フォームで)提供するかどうか、および「宛先構成」フォームで「ファイルに単純な名前を使用」が選択されているかどうかによって異なります。この設定の詳細は、ディスクへのエクスポートのパブリッシュに対するシステム構成を参照してください。可能なファイル名を、表39-6に示します。命名規則の説明は、表の後にあります。

表39-6 ファイルの命名規則

ファイル名

説明

<pagename>_ <packedargs(if any)>_ <filename>.<SUFFIX>

「ファイル名」フィールドに値が入力済で、「ファイルに単純な名前を使用」が選択されていないアセットに使用します。

<packedargs(if any)>_ <filename>.<SUFFIX>

「ファイル名」フィールドに値が入力済で、「ファイルに単純な名前を使用」が選択されているアセットに使用します。

<pagename>_ <packedargs(if any)>_ <assetID>.<SUFFIX>

「ファイル名」フィールドが空で、「ファイルに単純な名前を使用」が選択されていないアセットに使用します。

<packedargs(if any)>_ <assetID>.<SUFFIX>

「ファイル名」フィールドが空で、「ファイルに単純な名前を使用」が選択されているアセットに使用します。

注意:

エクスポート・ファイルに名前を付ける際、次の構文変更が行われます。

- ページ名に含まれるスラッシュ文字(/)は、ファイル名ではハイフン(-)に変換されます。

- パックされた引数に含まれる等号記号(=)は、ファイル名ではハイフン(-)に変換されます。

- パックされた引数に含まれるアンパサンド文字(&)は、ファイル名ではアンダースコア(_)に変換されます。

- <pagename>は、アセットのレンダリングに使用するテンプレートのSiteCatalogページ・エントリの名前です。(SiteCatalogページ・エントリはすべてのテンプレート・アセットに含まれます。)

注意:

<pagename>は、「宛先構成」フォームで「ファイルに単純な名前を使用」パラメータが選択されている場合は省略されます。「ファイルに単純な名前を使用」オプションは選択的に使用します。アセットが複数のテンプレートでレンダリングされる場合は、「ファイルに単純な名前を使用」を選択しないでください。「ファイルに単純な名前を使用」の詳細は、ディスクへのエクスポートのパブリッシュに対するシステム構成を参照してください。

- <packedargs(if any)>は、ページ・エントリのルート・エレメントから渡されます。アセットのレンダリング・テンプレートのルート・エレメントからパックされた引数が渡された場合、アセットに対して生成されるファイルの名前にも、その引数の値が含まれます。
パックされた引数およびそれらがどのようにURLに関連するのかについては、『Oracle WebCenter Sitesでの開発』を参照してください。

- <filename>は、アセットの「ファイル名」フィールドの値です。WebCenter Sitesにより、「ファイル名」フィールドが空の場合、アセットで指定されているasset_IDが使用されます。

注意:

「宛先のパス/ファイル名の指定」フォームで特定の宛先用にアセットに設定されているファイル名は、アセットがその宛先にエクスポートされる場合は、アセットの「新規」フォームまたは「編集」フォームの「ファイル名」フィールドに入力されているファイル名よりも優先されます。

- <asset_ID> は、アセットで指定されているIDです。<asset_ID>は、アセットの「ファイル名」フィールドが空の場合または次の注意に該当する場合に使用されます。

注意:

WebCenter Sitesでは、ファイル名がアセットで指定されているかどうかを判断するには、アセットのIDとタイプの両方が必要です。アセットのタイプのIDが指定されていない場合、ファイル名は使用できません。その場合は、WebCenter Sitesにより、ファイル名のかわりにアセットのオブジェクトIDが使用されます。

- <SUFFIX>は、ファイル名の拡張子を指定する宛先構成オプションです。suffixパラメータの詳細は、ディスクへのエクスポートのパブリッシュに対するシステム構成を参照してください。

表39-7に、ディスクへのエクスポートのパブリッシュ中に作成されるファイル名の例を示します。これは、宛先構成で「ファイルに単純な名前を使用」が選択されていない場合の例です。

表39-7 エクスポート・ファイルの命名規則

アセット名

SiteCatalogPagename

packedargs

filename

asset_ID

SUFFIX

エクスポートされるファイル名

ホーム

BF/Page/Home

cid=123

c=Page

123

BF-Page-Home_123.html

ホーム

BF/Page/Home

cid=123

c=Page

123

.htm

BF-Page-Home_123.htm

ホーム

BF/Page/Home

cid=123

c=Page

home.html

123

BF-Page-Home_home.html

ホーム

BF/Page/Home

cid=123

c=Page

home.html

123

.htm

BF-Page-Home_home.html

ホーム

BF/Page/Home

cid=123

c=Page

PACKEDARGS="topicword=oil"

home.html

123

BF-Page-Home_topicword_ oil_home.htm

39.13.5 エクスポート開始ポイントの使用

ディスクへのエクスポートのパブリッシュ方法では、どこから開始するかが不明な場合、ファイルのレンダリングを開始できません。どこから開始するかを指示するには、開始ポイント、すなわちページ・アセットとそれをレンダリングするために使用する必要があるテンプレートを、少なくとも1つ指定します。WebCenter Sitesはテンプレートのページ名のルート・エレメントを起動し、そのエクスポート開始ポイントに接続されているすべての承認済アセット、すなわちアソシエーション、リンク、ナビゲーション・バー、問合せなどを通じて接続されているアセットの、レンダリングを開始します。

注意:

エクスポートするサイトには、少なくとも1つのエクスポート開始ポイントが必要です。通常は、ホーム・ページを使用します。ただし、オンライン・サイトの設計方法によっては、複数のエクスポート開始ポイントが必要になる可能性があります。なぜなら、サイトのあるセクションがサイトの他の部分に接続されていない場合、このセクションはレンダリングされないからです。例:

- オンライン・サイトに複数の最上位ページ・アセットが存在する場合、それぞれに対応するエクスポート開始ポイントが必要です。

- 静的ページと動的ページが混在するサイトで、動的に生成されるページのHREFに静的URLがハードコードされている場合、そのURLで指定されるアセットをエクスポート開始ポイントとして指定する必要があります。

39.14 ディスクへのエクスポートのパブリッシュに対するシステム構成

ディスクへのエクスポートのパブリッシュを使用するようにシステムを構成する主な手順は次のとおりです。

- エクスポート・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- ルート・エクスポート・ディレクトリの指定

- エクスポート先の構成

- WebサーバーのURL接頭辞のマッピング

- WebサーバーのURL接頭辞のマッピング

- エクスポート開始ポイントの作成

- ディスクへのエクスポートのパブリッシュのためのアセットの承認

- スケジュールの設定

39.14.1 エクスポート・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

構成しているパブリッシュの宛先の数やタイプに関係なく、この手順はソース・システムごとに1回のみ実行する必要があります。

バッチ・ユーザー・アカウントを作成していない場合、これを作成します。手順については、バッチ・ユーザー・アカウントの作成(存在しない場合)を参照してください。

アカウントがインストールに存在する場合は、ルート・エクスポート・ディレクトリの指定にスキップしてください。

バッチ・ユーザー・アカウントの作成には、次の2つの目的があります。

- ソース上のパブリッシュ・システムが使用するバッチ・ユーザー・アカウントを構成する。

- パブリッシュ・ログを保存する場所を指定する。

この項の手順では、wcs_properties.jsonファイルにいくつかのプロパティを設定する必要があります。それ以外に、システム構成を微調整するために使用可能なプロパティもあります。プロパティの完全なリストは、『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

39.14.2 ルート・エクスポート・ディレクトリの指定

この章で説明しているように、WebCenter Sitesがファイルをエクスポートするディレクトリは、wcs_properties.jsonファイルのcs.pgexportfolderプロパティによって決まります。(このディレクトリにサブディレクトリを追加する場合は、「宛先構成」フォームの「ベース・ディレクトリ」フィールドに値を入力します。)

注意:

エクスポート・パブリッシュ・セッションを実行する前に、このルート・エクスポート・ディレクトリが存在し、作成されるHTMLページ用に十分な領域があることを確認します。

エクスポートされるファイルのルート・ディレクトリを設定するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「名前」フィールドに、cs.pgexportfolderと入力します。

3. 「検索」をクリックします。

4. フォームの「プロパティ」セクションで、プロパティの名前を選択します。その値を、すべてのファイルをエクスポートするファイル・ディレクトリ(場所)に設定します。

これは、システムのグローバル設定です。複数の宛先があり、それぞれの宛先にパブリッシュされたファイルがこのディレクトリ内の対応するサブディレクトリに保存されるようにする場合は、(エクスポート先の構成で)それらの宛先を構成する際に「ベース・ディレクトリ」フィールドに値を入力します。

エクスポート・ディレクトリの詳細は、パスの命名規則の使用を参照してください。

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

6. アプリケーション・サーバーを再起動します。

39.14.3 エクスポート先の構成

エクスポート先を作成するには::

1. ソースWebCenter SitesシステムのAdminインタフェースにログインします。

2. 「管理」タブで、「パブリッシュ」、「宛先」の順に開いて、「新規追加」をダブルクリックします。

「新規宛先の追加」フォームが表示されます。

3. 「新規宛先の追加」フォームの各フィールドに次のように値を入力します。

- 「名前」フィールドに、一意の宛先の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

- 「配信タイプ」ドロップダウン・リストで「ディスクへのエクスポート: ディスクへのWebファイルのエクスポート」を選択します。フォームの入力可能なフィールドが多少変わります。

- ベース・ディレクトリ: このエクスポート先にパブリッシュされるファイルのサブディレクトリ名を入力します。ベース・ディレクトリは、cs.pgexportfolderプロパティで指定されているルート・ディレクトリの子ディレクトリとして作成されます。
このフィールドに値を入力した場合、パブリッシュの宛先のエクスポート・パスは、次のようになります。

<cs.pgexportfolder>/<DIR>

<DIR>はベース・ディレクトリです。

注意:

エクスポートされたファイルに記述されるURLには、この宛先ディレクトリ・パスは含まれません。エクスポートされるファイルのURLは、宛先ディレクトリ内で、このレベルの下位レベルから始まります。したがって、このフィールドに値を入力し、さらに「URL接頭辞」フィールドにも値を入力する場合は、「URL接頭辞」フィールドで表されるWebルートまたはWeb別名がこのディレクトリを指定するようにしてください。

このパラメータは、通常は、サイトに複数のエクスポート先が存在する場合に、ルート・エクスポート・ディレクトリのコンテンツを整理するために使用します。

- URL接頭辞: エクスポートされるファイル内でリンク(HREF)として使用されるURLの先頭にエクスポート・プロセスで追加する接頭辞を入力します。生成されるファイルの名前にはこの接頭辞は含まれません。ファイル内のリンクでのみ使用されます。
HTMLファイルが配信システムに移動されたときにファイル内のリンクが解決されるように、URLには、配信システムのWebサーバー別名を指定します。このフィールドを空白のままにすると、URLは相対形式で記述されます。

テスト・システムのWeb別名の名前は、必ず、配信システムのWeb別名の名前と同じにしてください。

- 接尾辞: このテキスト・ボックスには、アセットの「ファイル名」フィールドを使用しない場合またはそのフィールドで接尾辞を指定しない場合に、生成されるファイルに適用するファイル接尾辞を指定します。デフォルトはhtmlです。

- ファイルに単純な名前を使用: このパラメータが選択されている場合、WebCenter Sitesは、アセットのレンダリングに使用するテンプレートのSiteCatalogページ・エントリを無視することによって、通常のファイルの命名規則を無視して、アセットの「ファイル名」フィールドにファイル名として入力された値のみを使用します。アセットにファイル名が指定されていない場合は、WebCenter Sitesにより、かわりにアセットのIDを使用します。ファイルの命名規則の詳細は、ファイルの命名規則の使用を参照。
このルールには例外が1つあり、アップロード・フィールドを持つアセット(BLOBであるアセット)には、この値がtrueに設定されていても、常に標準の(長い)ファイル名が使用されます。

注意:

「ファイルに単純な名前を使用」パラメータは、注意して使用する必要があります。個々のアセットを複数のテンプレートでレンダリングするように設計されているサイトでは、このパラメータを使用しないでください。ファイル名でSiteCatalogページ・エントリが使用されていない場合、1つのアセットを複数のテンプレートでレンダリングすると、ファイル名が一意であることを保証できません。

- ディレクトリに単純な名前を使用: このパラメータが選択されている場合、通常のディレクトリの命名規則は無視されます。ファイルの命名規則の詳細は、パスの命名規則の使用を参照。
「ディレクトリに単純な名前を使用」が選択されている場合、親アセットからパス情報を取得できないときは、WebCenter Sitesは、レンダリングされたHTMLファイルを直接デフォルトのエクスポート・ディレクトリに書き込みます。(通常は、WebCenter Sitesは、パス情報がないときはページ・アセットのIDを使用します。)アセットの親ページ・アセットのPathパラメータに値が設定されている場合は、この選択は無視されます。

- 古いテンプレート: この製品の3.5以前のバージョンの標準のレンダリング方法を使用するには、このパラメータを選択します。

注意:

配信システム上で公開しているサイトが3.6より前のバージョンのWebCenter Sitesで使用されているレンダリング・モデル用に設計されていて、まだ3.6のレンダリング・モデル用に再設計されていない場合、このパラメータを選択する必要があります。

このパラメータを選択する場合は、サイトにエクスポート開始ポイントを設定しないでください。エクスポート開始ポイントは、テンプレート自体で決まります。

- 失敗時の電子メールの送信: パブリッシュが失敗し、その結果を電子メールで通知する必要がある場合、このオプションを選択します。フィールドが追加表示されます。

- 電子メール・アドレス: 受信者の電子メール・アドレスを入力し、「追加」をクリックします。(このフィールドは、「失敗時の電子メールの送信」を選択した場合にのみ表示されます。)失敗時に電子メールを受信するすべての電子メール・アドレスが表示されます。

- 詳細出力: パブリッシュ・プロセス中の詳細なエラー・ロギングをアクティブ化します。これを選択した場合、エラー・メッセージの追加のメッセージがPubMessage表に書き込まれます。追加情報によりパブリッシュ・プロセスが長くなるため、このオプションはトラブルシューティングの場合にのみ選択するようにしてください。

- 他の引数: この場合は、他の引数は指定できません。

- サイト: アセットを承認し、この宛先に対してパブリッシュすることが可能なサイトを選択します。

- ロール(パブリッシュの承認): 承認権限を割り当てるロールを選択します。これらのロールが割り当てられるすべてのユーザーがアセットを承認できます。

4. 「新規宛先の追加」をクリックします。

「パブリッシュの宛先」フォームが開きます。新しい宛先がフォームに表示されます。

図39-10 「パブリッシュの宛先」フォーム

5. 追加のエクスポート先ごとに、手順2から4を繰り返します。

39.14.4 WebサーバーのURL接頭辞のマッピング

エクスポートされたコンテンツを最終宛先(配信システム)で公開するには、Webサーバーの構成でURLパス接頭辞をファイルの配置場所にマップして、URLを解決できるようにします。

WebサーバーでURL接頭辞をマップする適切な手順の詳細は、Webサーバーのベンダーのドキュメントを参照してください。この接頭辞に指定する名前は、この宛先の「URL接頭辞」宛先構成パラメータに指定した名前と一致する必要があることに留意してください。「URL接頭辞」に入力した場合、入力したディレクトリがWebルートまたはWeb別名に含まれるようにしてください。

39.14.5 エクスポート開始ポイントの作成

エクスポート開始ポイントを作成するには::

1. ソース・システムの管理者インタフェースを使用して、エクスポート開始ポイントとして指定するアセットを見つけます。

2. 見つけたアセットをその「ステータス」フォームで開き、「パブリッシュの宛先」セクションにスクロールします。

3. 次のいずれかを実行します。

- アセットが現在構成している宛先に対してまだ承認されていない場合、ツールバーの「パブリッシュの承認」(緑のチェック・マーク・アイコン)を選択し、手順4に進みます。

- アセットが現在構成している宛先に対して承認済である場合、手順6に進みます。

4. パブリッシュの承認フォームで、アセットを承認する宛先を選択し、「承認」をクリックします。
WebCenter Sitesにより、このアセットにリンクされているすべてのアセットの依存性が計算され、結果が表示されます。

5. 承認結果が表示されたら、ツールバーの「ステータス」アイコン(緑のチェック・マーク付きの時計の文字盤)をクリックします。

6. 「ステータス」フォームで、選択した宛先が表示されているセクションにスクロールします。

7. 「ファイル/パス」フィールドで、「パス/ファイル名と開始ポイントの指定」(図39-11参照)をクリックします。
「ファイル」および「パス」フィールドが、「コンテンツ属性」フォーム(図39-12)で使用可能になります。

図39-11 「コンテンツ属性」フォーム

図39-12 「コンテンツ属性」フォーム

注意:

選択した開始ポイントがページの場合、テンプレートは検出されず、続いて「保存」をクリックすると、結果は「このアセットをパブリッシュ開始ポイントにするには、$template$を選択する必要があります。」というエラーになり、enableAssetFormsプロパティをtrueに設定する必要があります。

プロパティ管理ツールから、advancedUI.enableAssetForms=trueを設定し、続いて「コンテンツ属性」フォームでページを開始ポイントとして設定します(図39-11)。

8. 「コンテンツ属性」フォームで、次のようにフィールドに入力します。

a. (オプション)「宛先」セクション:
パス: この宛先にパブリッシュするアセットに一意のパス情報を指定するには(このアセットのパス情報はここ以外に指定する場所はありません)、「パス」フィールドにパスを入力します。

ファイル名: この宛先に固有のファイル名情報を指定するには、「ファイル名」フィールドに入力します。このフォームで入力したこの宛先用のファイル名は、アセットに対して他の場所で指定されたあらゆるファイル名情報より優先されます。

b. 「このアセットがエクスポート開始ポイントですか。」で「はい」を選択します。

c. (オプション)「使用するテンプレート」セクションで次のように選択します。
テンプレートを選択します。

ラッパー・ページを選択します。

このアセットを「宛先」セクションで指定されているパスに強制的にエクスポートする場合、「指定パスの強制使用」を選択します。

「宛先」セクションで指定されているファイル名を強制的に使用する場合、「指定ファイル名の強制使用」を選択します。

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

10. サイト内の最上位ページ・アセットごとに手順1から9を繰り返します。

39.14.6 ディスクへのエクスポートのパブリッシュのためのアセットの承認

構成の簡単なテストを実行するには、依存アセットの数が最も少ないエクスポート開始ポイントを選択して、各アセットを承認します。

サイト全体のテスト・パブリッシュを実行するには、そのサイトのすべてのアセットを承認します。多数のアセットの一括承認のヘルプは、複数アセットの承認を参照してください。

39.14.7 結果のパブリッシュとテスト

選択した宛先にパブリッシュするアセットが承認されたら、テスト・パブリッシュ・セッションを実行します。

1. ソース・システム上のAdminインタフェースで、ボタン・バーの「パブリッシュ」をクリックします。

2. 「パブリッシュ・コンソール」で、ドロップダウン・リストから宛先を選択し、「宛先の選択」をクリックします。

WebCenter Sitesに、この宛先にパブリッシュする準備のできているアセットに関する情報が表示されます。(この宛先に対するエクスポート開始ポイントをまだ作成していない場合、フォームにそのことを通知するメッセージが表示されます。パブリッシュ・セッションを開始する前に、少なくとも1つのエクスポート開始ポイントを作成する必要があります。)

3. 「パブリッシュ」をクリックします。

確認メッセージが表示されます。「はい」をクリックしてパブリッシュを続行します。

パブリッシュ・システムは、この宛先に対して承認されたすべてのアセットをファイルにエクスポートします。

4. 「パブリッシュ・コンソール」の「アクティブ」タブで、セッションの動作を監視できます。

5. セッションが完了したら、「履歴」タブをクリックすると、このセッションのセッション・サマリーを表示できます。

セッション情報の上にマウスを移動すると、サマリー情報が表示されます。

6. 「パブリッシュ・コンソール」の「履歴」タブで、パブリッシュの宛先へのリンクを選択します。

セッション・サマリーには、エクスポート・プロセス中に作成されたすべてのファイルのリストが表示されます。

7. サイトの最上位ページを表すファイルの横にある「プレビュー」(双眼鏡)アイコンをクリックします。

ページが新しいブラウザ・ウィンドウで開きます。

8. ページ全体をざっと見てエラーを探し、すべてのリンクをテストします。必ず、生成された他のすべてのファイルへのリンクをテストしてください。

9. レンダリングされたホーム・ページのURLをブラウザに直接入力し、サイト全体を移動して、リンク結果をテストします。そのためには、まずWebCenter Sites管理システム上でWebサーバー・ルートをエクスポート・ディレクトリに設定する必要があります。

10. ファイルが配信の準備ができていると判断したら、ファイルを配信システムにコピーします。

39.14.8 スケジュールの設定

次のことを確認します。

- 宛先が正しく構成されている。

- 必要なファイル名とディレクトリ名が作成されている。

- Webサーバーがファイルを正しく配信している。

これらのことを確認できたら、ソース・システムで次の手順を実行することによって、パブリッシュ・システムの構成を完了できます。

1. 宛先に対してスケジュールされたパブリッシュ・イベントを作成します。この手順の詳細は、パブリッシュ・イベントのスケジュールを参照してください。

2. 生成されたファイルを、テスト領域と配信システムの両方のWebサーバーにコピーする方法を計画します。たとえば、パブリッシュ・セッション完了後にFTPを使用してファイルを自動的にテスト領域にコピーするスクリプトを設定できます。

39.15 サーバーへのミラーリングのパブリッシュの理解

サーバーへのミラーリングのパブリッシュ方法では、承認システム、パブリッシュのスケジュールおよび宛先構成から情報を収集し、データを宛先へコピーし、そのデータを宛先システムで解凍した後、CacheManagerサーブレットを起動して新コンテンツの利用のために再生成が必要な任意のページをリフレッシュします。

図39-13 サーバーへのミラーリングのパブリッシュ

WebCenter Sites配信システムがコンテンツを動的に配信するかどうかに関係なく、多くの場合、サーバーへのミラーリングのパブリッシュ方法を使用して、開発システムから管理システムへデータを移動します。このプロセスの詳細は、トラブルシューティングを参照してください。

サーバーへのミラーリングのパブリッシュ・セッションが実行されると、図39-14のようになります。

図39-14 ミラーリングのパブリッシュ・プロセス

1. ソース・システムでは、サーバーへのミラーリングのパブリッシュは、宛先に対するミラーリング・キューを作成するために、パブリッシュ・システムによって渡された承認済アセット一覧を使用します。
ベーシック・アセット用のミラーリング・キュー

ベーシック・アセットの場合、次の情報がキューに追加されます。

- アセットのメイン表の行。たとえば、ページ・アセットの場合は、Page表のアセットの行です。

- AssetPublication表の該当する行。これらの行はサイトおよびサイトに属するアセットを一覧表示します。

- パブリッシュされているアセットと関連付けられている任意のアセットを参照するAssetRelationTree表の行。

- AssetRelationTree表の行が参照する、関連付けられたアセット。アセット表の行、AssetPublicationの行および任意の依存アセットの関連付けられたアセットも、承認済でパブリッシュされていない場合はミラーリングされます。

フレックス・アセットおよびコンプレックス・アセット用のミラーリング・キュー

フレックス・アセット・タイプとその他の複数表のアセット・タイプ(テンプレートとCSElementなど)の場合、それらすべての表の該当する行情報が、1つのオブジェクトにシリアライズされ、そのアセット・タイプの_Publish表に格納されます。

たとえば、テンプレートがパブリッシュされると、Template表、SiteCatalog表およびElementCatalog表が1つのオブジェクトにシリアライズされ、Template_Publish表に格納されます。

_Publish表の各アイテムはミラーリング・キューに追加されます。

2. WebCenter SitesがAssetPublishList表を使用し、ミラーリング・キューにあるすべてのアセットのリストを作成します。

3. ミラーリング処理が開始されます。
最初に、AssetPublishListがソースから宛先へミラーリングされます。

4. ミラーリング・キューが配信され、パブリッシュ・システムは、キューにあるアセットを解凍します。
フレックス・アセットの場合、サーバーへのミラーリングのパブリッシュによって、_Publish表のオブジェクトがデシリアライズされ、該当する表に結果が挿入されます。

ベーシック・アセットの場合、キューの各行がコピーされます。

5. ミラーリング・キューのアイテムが解凍されると、パブリッシュ・システムは、ミラー・パブリッシュが正常に完了したというメッセージを送信します。宛先システムは、次のように応答します。

- 新しくパブリッシュされたアセットは、宛先システム上では変更済としてマークされます。これは、そのシステムから別の宛先にパブリッシュするには、その前にそれを承認する必要があることを意味します。この機能はデフォルトで有効になっていることに注意してください。必要があれば無効にできます。詳細は、配信システムでのアセットの無効化の解除を参照してください。

- 宛先のCacheManagerサーブレットは、今パブリッシュされたアセットを参照するすべてのページが更新されるように、キャッシュ内の適切なページを再生成します。不明な構成依存性を持つどのページも再構築します。

- 次に、CacheManagerは、宛先システム上のsatellite.iniファイルで指定される各Satellite Serverに対して、リフレッシュが必要なページに関するメッセージを伝えます。共存するバージョンおよび、このWebCenter Sitesシステムに属すると識別されているすべてのリモート・インスタンスと通信します。その後、Satellite Serverアプリケーションが、その情報を使用してSatellite Serverのページ・キャッシュをリフレッシュします。

- AssetPublishList表が消去され、次のパブリッシュ・セッションに対して準備されます。

6. ソース・システムで、パブリッシュ・システムは、パブリッシュ・ログ・ファイルを更新します。各アセットがエクスポートされた後にパブリッシュ・ログへ書き込む、ディスクへのエクスポートのパブリッシュ方法とは異なり、サーバーへのミラーリングのパブリッシュは、ミラーリング・キュー全体が正常にミラーリングされるまで待機してからパブリッシュ・ログへ結果を書き込みます。

7. パブリッシュ・セッションが正常に完了すると、WebCenter Sitesは、パブリッシュした参照に関する情報をPubKey表とPublishedAssets表に書き込み、ソース・システムでAssetPublishList表を消去することで、そのセッションを終了します。

8. WebCenter Sitesはさらに、次回アセットが承認されるときに承認システムが適切に依存性を計算できるように、パブリッシュされたアセットに関する情報を、ApprovedAssets表とApprovedAssetDeps表に書き込みます。

39.16 サーバーへのミラーリングのパブリッシュを構成する前に

サーバーへのミラーリングのパブリッシュ・プロセスを構成する前に、この項で提示されるトピックを考慮してください。事前に次の情報について知っておくと、円滑に構成プロセス行うために役立ちます。

- ユーザーとサーバーへのミラーリングのパブリッシュの使用

- CacheManagerの使用

- ミラーリング先の構成

- ミラーリング先の構成を使用する場合の決定

39.16.1 ユーザーとサーバーへのミラーリングのパブリッシュの使用

パブリッシュ・イベントがパブリッシュ・セッションの処理に使用するソース・システム上のバッチ・ユーザー・アカウントに加えて、サーバーへのミラーリングのパブリッシュ方法では、別のユーザー・アカウント(宛先サーバーにあるミラー・ユーザー・アカウント)が必要となります。これは、パブリッシュ・システムが宛先システムでミラーリング・キューの解凍に使用するユーザー・アカウントです。

サーバーへのミラーリングのパブリッシュの宛先を設定する際に、宛先が示す宛先システム上にミラー・ユーザー・アカウントを作成する必要があります。

39.16.2 CacheManagerの使用

CacheManagerは、管理システムを含む、動的WebCenter Sitesシステム上のページ・キャッシュを保持するWebCenter Sitesのサーブレットです。

CacheManagerが重要なのは、ミラー・パブリッシュ・セッションの際に宛先で適切なアセットをロックし、ミラー・パブリッシュ・セッションの前後のページ・キャッシュの整合性を保証するからです。

CacheManagerの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

39.16.3 ミラーリング先の構成

サーバーへのミラーリングのパブリッシュ方法では、承認済アセットに関する情報が、WebCenter Sitesデータベース同士でコピーされます。この情報を、ミラーリング先に対して構成する必要があります。ミラーリング先の構成には、宛先の初期化および宛先に対するデータの構成の2つの手順があります。

新しいミラーリング先を作成するときは必ず、ミラーリング先を初期化してからそこにパブリッシュする必要があります。ミラーリング先を初期化するには、次の情報を指定します。

- サイト。選択するサイトに基づいて、Publication表、SitePlanTree表およびPublicationTree表の該当する行が宛先へミラーリングされます。

- アセット・タイプをサポートするか、直接アセット・タイプに関連する任意のカスタム表。つまり、AssetMakerまたはフレックス・ファミリ・メーカーのいずれによっても作成されなかったアセットの表です。これらの例として、SourceとMimetypeがあげられます。これらの表は、補助表と呼ばれます。

ミラーリング先の構成とは、ターゲット宛先にミラーリングされるデータ(アセット・タイプ、アソシエーションおよびスタート・メニュー・アイテムなど)を示すプロセスのことです。ミラーリング先を構成すると、補助表(アセットの動的表示に使用されるアセット以外のデータベース表)の構成データと行が、WebCenter Sitesデータベース同士で移動します。

39.16.4 ミラーリング先の構成を使用する場合の決定

次のようないくつかの状況でミラーリング先の構成を使用します。

- 新しいミラーリング先を設定する場合。

- アセット・タイプ(スタート・メニュー・アイテム、アソシエーションなど)をサポートする構成アイテムを、開発システムから管理システムまたは配信システムへ移動する場合。

- ワークフロー構成データを開発システムから管理システムに移動する。

- 管理者または開発者が、別のサイト、アセット・タイプまたは補助表をシステムに追加する場合。

- 管理者または開発者が、既存のアセット・タイプにカテゴリまたはサブタイプを追加する場合。

- 構成をトラブルシューティングする必要がある場合。ミラーリング先を正常に初期化できれば、ソース・システムと宛先システム間での通信が行われています。

39.17 サーバーへのミラーリングのパブリッシュに対するシステム構成

サーバーへのミラーリングのパブリッシュを使用するようにシステムを構成する主な手順は次のとおりです。

- ミラーリング・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- 宛先システムの設定

- ソース・システムでのミラー・ユーザーの識別

- ソース・システムでのローカル・プロキシ・サーバーの識別(存在する場合)

- ミラーリング先の作成

- 宛先の初期化

- ミラーリング先の構成

- アセットの承認

- アセットのパブリッシュ

- 結果のテスト

- スケジュールの設定

- 配信システムでのアセットの無効化の解除

注意:

サーバーへのミラーリングのパブリッシュを使用するようにシステムを構成するには、独自のWebCenter Sitesのインストールおよびビジネス慣行に固有の情報を指定する必要があります。この項の手順を開始する前に、要求される情報を収集して確認するために、この手順を通読することをお薦めします。

39.17.1 ミラーリング・パブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

構成しているパブリッシュの宛先の数やタイプに関係なく、この手順はソース・システムごとに1回のみ実行する必要があります。

バッチ・ユーザー・アカウントを作成していない場合、これを作成します。手順については、バッチ・ユーザー・アカウントの作成(存在しない場合)を参照してください。

ソース・システムにバッチ・ユーザー・アカウントが存在する場合は、宛先システムの設定に進みます。

39.17.2 宛先システムの設定

WebCenter Sitesシステム同士の間でアセットをミラー・パブリッシュするためには、サイトとアセット・タイプが、ソース・システムと宛先システムの両方で同じであることを確認する必要があります。さらに、宛先システムで、ミラー・ユーザー(ソースに存在するバッチ・ユーザーとは異なります)という、別のユーザーを作成する必要もあります。このユーザーが、宛先システムでミラー・パブリッシュのデータベース・トランザクションを実行します。

注意:

ソース・システムと宛先システムのデータベース・プロパティは、完全には一致していなくても、特にデータベース・スキーマ・オプション(プロパティ管理ツールで設定)は互換性がある必要があります。データベース・プロパティを変更する場合は、必ずアプリケーション・サーバーを再起動します。

宛先システムを設定するには::

1. アセット・タイプのフィールドの参照表など、カスタム・サポート表が存在する場合は、宛先システムにそれらの表を作成します。

2. 宛先システム上で、ミラー・ユーザーを作成します。

注意:

ミラー・ユーザーは、リアルタイム・パブリッシュ用に構成されたリアルタイム・ユーザーと同じ権限を持ちます。リアルタイム・ユーザーがリアルタイム・パブリッシュ用に構成されている場合、同じユーザーをミラー・ユーザーとして使用できます。

- このユーザーは、次のACLを保持する必要があります。

- Browser

- ElementEditor

- PageEditor

- TableEditor

- Visitor

- VisitorAdmin

- xceladmin

- xceleditor

- ミラー・ユーザー・アカウントは、CacheManagerによってパブリッシュ・セッションの後にページ・キャッシュを再生成するために使用されるため、ミラー・ユーザーには、キャッシュ内のすべてのページを再生成するのに十分な権限が与えられる必要があります。したがって、ミラー・ユーザー・アカウントには、SiteCatalog表またはレンダリングされるデータを保持するデータベース表内のページ・エントリに割り当てられるすべてのACLが割り当てられる必要があります。

注意:

任意のサンプル・サイトが宛先システムにインストールされている場合は、mirroruserというユーザーがすでに存在しています。セキュリティ上の理由から、ミラー・ユーザーとしてこのユーザーを保持する場合、必ずこのユーザーのパスワードを変更してください。また別のミラー・ユーザーを作成する場合は、必ず、このサンプル・サイトのmirroruserを削除してください。

- ミラー・ユーザーの作成のヘルプが必要な場合、Adminインタフェースでのユーザーの作成を参照してください。

39.17.3 ソース・システムでのミラー・ユーザーの識別

次に、ソース・システムでwcs_properties.jsonファイルのプロパティ値を設定することで、宛先システムのミラー・ユーザーの名前とパスワードをソース・システムに指定します。

注意:

プロキシ・サーバーはサーバーへのミラーリングとリアルタイム・パブリッシュの両方で使用されるため、プロキシ・サーバーがリアルタイム・パブリッシュ用に設定されている可能性があります。このような場合、手順にあるプロパティを確認し、適切に設定されていることを確認します。

ミラー・ユーザーをソース・システムで識別するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「カテゴリ」ドロップダウン・メニューで、「パブリッシュ」を選択します。

3. 「検索」をクリックします。

4. 次のプロパティに対し値を設定して保存します。

- cs.mirroruser
このプロパティを、前述の手順にある宛先システムで作成したユーザーの名前に設定します。

- cs.mirrorpassword
このプロパティを、前述の手順にある宛先システムで作成したユーザーのパスワードに設定します。

5. 次のいずれかを実行します。

- ソース・システムと宛先システムを分離するファイアウォールがある場合、ソース・システムでのローカル・プロキシ・サーバーの識別(存在する場合)に進みます。

- ソース・システムと宛先システムを分離するファイアウォールがない場合、アプリケーション・サーバーを停止し、再起動します。次に、ミラーリング先の作成に進みます。

39.17.4 ソース・システムでのローカル・プロキシ・サーバーの識別(存在する場合)

注意:

構成しているパブリッシュの宛先の数やタイプに関係なく、この手順はソース・システムごとに1回のみ実行する必要があります。ローカル・プロキシがソース・システムで識別されているか、プロキシ・サーバーが使用されていない場合は、ミラーリング先の作成にスキップします。

ローカル・プロキシをソース・システムで識別するには:

1. Adminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。

2. 「カテゴリ」ドロップダウン・メニューで、「パブリッシュ」を選択します。

3. 「検索」をクリックします。

4. 次のプロパティに対し値を設定して保存します。

- cs.mirrorproxyserver
このプロパティを、ローカル・プロキシ・サーバーの名前かIPアドレスに設定します。

- cs.mirrorproxyserverport
このプロパティをローカル・プロキシ・サーバーのポート番号に設定します。

5. アプリケーション・サーバーを再起動します。

39.17.5 ミラーリング先の作成

パブリッシュ・プロセスの他の部分と同様に、ミラーリング先を構成する必要があります。

ミラーリング先を作成するには::

1. ソースWebCenter SitesシステムのAdminインタフェースにログインします。

2. 「管理」タブで、「パブリッシュ」、「宛先」の順に開きます。

3. 「宛先」で、「新規追加」をダブルクリックします。

「新規宛先の追加」フォームが表示されます。

図39-15 「新規宛先の追加」フォーム

4. このフォームで次のようにフィールドを構成します。

- 名前: 一意の宛先の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

- 配信タイプ: 「サーバーへのミラーリング: データベースの行をリモート・サーバーへコピー」を選択します。

- 宛先アドレス: 表示された形式でリモート・サーバーのURLを入力します。<targetserver:port>には、ターゲット・システムのホスト名またはIPアドレスおよび宛先で使用されるポートを入力します。URLは、動的に付加されるため、URLの後にスラッシュが必要です。

- リモート・ユーザー: 宛先システムの設定で作成したミラー・ユーザーの名前を入力します。このユーザーは、宛先システム上のミラーリング・キューを解凍するために、ターゲット・システムによって呼び出されます。

- リモート・パスワード: ミラー・ユーザーのパスワードを入力します。

- 失敗時の電子メールの送信: パブリッシュに失敗し、電子メールでその影響を通知する必要がある場合、このチェック・ボックスを選択します。

- 電子メール・アドレス: 受信者の電子メール・アドレスを入力します。(このフィールドは、「失敗時の電子メールの送信」を選択した場合にのみ使用可能になります。)

- 詳細出力: パブリッシュ・プロセス中に詳細エラー・ロギングを有効にするには、このオプションを選択します。これを選択した場合、エラー・メッセージの追加のメッセージがPubMessage表に書き込まれます。追加情報によりパブリッシュ・プロセスが長くなるため、このパラメータはトラブルシューティングの場合にのみ選択してください。

- 他の引数: このパラメータは将来使用するために予約されています。この時点で指定できる追加の引数はありません。

- サイト: アセットを承認し、この宛先に対してパブリッシュすることが可能なサイトを選択します。

- ロール(パブリッシュの承認): 承認権限を割り当てるロールを選択します。このロールが割り当てられたすべてのユーザーは、アセットを承認できるようになります。

- ロール(パブリッシュ): パブリッシュ権限を割り当てるロールを選択します。これらのロールが割り当てられるすべてのユーザーがパブリッシュできます。

5. 「新規宛先の追加」をクリックします。

WebCenter Sitesにより「パブリッシュの宛先」フォームが表示されます。

図39-16 「パブリッシュの宛先」フォーム

6. この宛先システムを初期化する準備ができたら(宛先システムへのパブリッシュを可能にするには初期化する必要があります)、「パブリッシュの宛先」フォームの「ミラーリング先の初期化」ボタンをクリックします。その先の手順の詳細は、宛先の初期化を参照してください(その手順の手順4から始めてください)。

さらにミラーリング先を作成する必要がある場合、ソース・システムで作成する必要があるミラーリング先を追加するたびに、手順1から5を繰り返します。

39.17.6 宛先の初期化

宛先システムへパブリッシュする前に、宛先システムを初期化する必要があります。これにより、宛先システムに基本的なサイト情報が作成されます。具体的に言うと、Publication表とPublication Tree表が、ターゲットにパブリッシュされたサイト名とアセット・タイプで更新されます。

宛先システムを初期化するには::

1. 「管理」タブで、「パブリッシュ」、「宛先」の順に開きます。

2. 「宛先」で、初期化する宛先をダブルクリックします。

3. 「パブリッシュの宛先」フォームで、「ミラーリング先の初期化」をクリックします。
「ミラーリング先の初期化」フォームが表示されます。

4. この宛先にパブリッシュするアセットを持つサイトを選択します。

5. 「補助表」フィールドで、次の表の名前を入力します。

- Source: いずれかのアセット・タイプに対してソース機能を使用している場合。

- MimeType: フレックス・フィルタ・アセット、ImageFileアセット・タイプを使用している場合、またはいずれかのカスタム・アセット・タイプに対してこの表を使用している場合。

- Filters: サイトでフレックス・フィルタを使用している場合。(Filters表には、フレックス・フィルタで使用するクラスがリストされます。jarファイルとクラスを手動でコピーする必要があります。)

- アセット・タイプのその他の補助表(参照表など)。

注意:

表名に指定するフィールドは5つのみです。6つ以上の表名を入力する必要がある場合、最初の5つの表に対してこの手順の6までを行い、次に残っている表に対して手順3から6を繰り返します。

6. 「ミラー」をクリックします。
初期化に成功した場合は、WebCenter Sitesに確認メッセージが表示され、不成功の場合はエラー・メッセージが表示されます。

手順4で選択したサイトに基づき、Publication、SitePlanTreeおよびAssetTypeの各表の対応する行が宛先にコピーされます。

さらに、補助表として指定した表のすべての行が、宛先にコピーされます。

注意:

パブリッシュ・コンソールからは、ターゲット宛先の初期化もできます。ボタン・バーで、「パブリッシュ」をクリックします。

a. 「パブリッシュ・コンソール」で、ドロップダウン・リストからミラーリング先を選択し、「宛先の選択」をクリックします。

b. 「ターゲットでのサイトの作成」ボタンをクリックします。確認フォームが表示されたら、「はい」をクリックします。これにより、宛先システムに基本的なサイト情報が作成されます。

39.17.7 ミラーリング先の構成

ここで、ターゲット宛先に配置するデータを構成する必要があります。この構成は、ターゲット宛先の目的に応じて異なります。たとえば、ターゲット宛先が完全に配信コンピュータである場合、ミラーリング時はアセット・タイプのみを含めることが適切です。宛先構成を進める前に、あるシステムから別のシステムへのサイトの移行を参照すると役立ちます。

注意:

リビジョン追跡がパブリッシュのターゲット宛先でElementCatalogまたはSiteCatalogのいずれかに対してオンになっている場合、テンプレートのパブリッシュは失敗し、テンプレートは壊れる可能性があります。

ターゲット宛先でリビジョン追跡を有効にすることはお薦めできません。

1. ソース・システムの「管理」タブで、「サイト」を開き、ターゲット宛先にデータをパブリッシュするサイトをダブルクリックします。

2. 「パブリッシュの宛先」(フォームの下部近く)で、宛先(動的)の「ミラー・サイト構成」をクリックします。この宛先はターゲット宛先です。

WebCenter Sitesにより、「ミラー・サイト構成」フォームが表示されます。

図39-17 「ミラー・サイト構成」フォーム

ターゲット宛先で使用可能にするデータを選択します。

- アセット・タイプ: ターゲット宛先で使用可能にするアセット・タイプを選択します。
アセット・タイプにサブタイプおよびカテゴリがある場合、「アセット・タイプ」セクションのリストから適切なオプションを選択し、対応するチェック・ボックスを選択します。たとえば、AssocNamed表には、アセット・タイプのアソシエーションに関する情報が含まれます。表は、「選択したアセット・タイプのアセットのアソシエーション」と関連するアセット・タイプを選択している場合にのみミラーリングされます。

- スタート・メニュー・アイテム: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意のスタート・メニュー・アイテムを選択します。

- ワークフロー・プロセス: アセット・タイプのワークフロー・プロセスがある場合、これらのプロセスおよび適切なワークフロー・アイテムを選択します。

- ワークフロー・グループ: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意のワークフロー・グループを選択します。

- ツリー・タブ: ターゲット宛先で使用可能にするツリー・タブを選択します。

注意:

「サイト・プラン」、「管理」、「サイト管理者」、「ワークフロー」、「ブックマーク」のツリー・タブのうち、いずれかがターゲット宛先に存在する場合、そのツリー・タブのミラーリングは失敗し、宛先でツリー・タブが破損する恐れがあります。

ターゲット宛先に存在するツリー・タブをミラーリングすることはお薦めしません。

- 保存済検索: 管理者または開発者がコンテンツ・プロバイダで使用するために設計した任意の保存済検索を選択します。

- ロール: ターゲット宛先に存在する必要があるロールを選択します。

3. 「ミラー」をクリックします。

手順1で選択したアセット・タイプの構成オプションを基に、AssocNamed、AssocNamed_SubtypesおよびCategoryの各表の該当する行が宛先にコピーされます。

「スタート・メニュー・アイテム」または「保存済検索」を選択した場合、これらの機能を実装する表の該当する行が、宛先にコピーされます。

手順1で選択したワークフロー構成オプションを基に、ワークフロー表の該当する行が宛先にコピーされます。

4. アセットをターゲット宛先でパブリッシュするサイトごとに手順1から3を繰り返します。

39.17.8 アセットの承認

パブリッシュされたサイトをテストするには、サイトのすべてのアセットを承認し、パブリッシュする必要があります。多数のアセットを一度に承認する方法の詳細は、複数アセットの承認を参照してください。

構成の単純なテストを実行するには、依存が数個のみのホームページ・アセットを一時的に作成します。

39.17.9 アセットのパブリッシュ

宛先にパブリッシュできるアセットを承認したら、テスト・パブリッシュ・セッションを実行できます。

1. ソース・システムのボタン・バーで「パブリッシュ」をクリックします。

2. 「パブリッシュ・コンソール」で、リストからミラーリング先を選択し、「宛先の選択」をクリックします。

WebCenter Sitesに、この宛先にパブリッシュする準備のできているアセットに関する情報が表示されます。

3. なんらかの理由により、ターゲット宛先が初期化されていない場合は、すぐに初期化しないとパブリッシュ・セッションが失敗します。宛先を初期化するには、「パブリッシュ・コンソール」で、「ターゲットでのサイトの作成」をクリックします。これにより、宛先システムに基本的なサイト情報が作成されます。

4. 「パブリッシュ」をクリックします。

確認メッセージが表示されます。「はい」をクリックしてパブリッシュを続行します。

パブリッシュ・システムにより、この宛先に対して承認されたすべてのアセットが、その宛先システムのWebCenter Sitesデータベースにミラーリングされます。

5. 「パブリッシュ・コンソール」の「アクティブ」タブで、セッションの動作を監視できます。

6. セッションが完了したら、「履歴」タブをクリックすると、このセッションのセッション・サマリーを表示できます。

セッション情報の上にマウス・ポインタを置いて、サマリー情報を表示します。「ログの表示」をクリックしてセッション・ログ・ファイルを表示します。宛先情報を表示するためのログの構成の詳細は、配信WebCenter Sitesシステムからのログの取得を参照してください。

39.17.10 結果のテスト

結果をテストするには、宛先システムでホームページ・アセットをブラウザからポイントし、サイトを確認します。

アセットのURLがまだ決定していない場合は、これを決定する必要があります。WebCenter SitesのURLは、次の値を連結して構成します。

- 宛先システムのホスト名またはIPアドレス(ポート番号の場合もあります)。

- CGIパス(wcs_properties.jsonファイルのft.cgipathプロパティからシステムが取得します)。たとえば、サーブレット・アーキテクチャを持つWebLogicなどのアプリケーション・サーバーの場合、このデフォルトのパスは、/servlet/です。

- 文字列ContentServer?pagename=

- SiteCatalogエントリのページ名

- WebCenter Sitesページの基準変数、c、cid、tidおよびpで渡される追加情報。(これらの変数の詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。)

次の手順を実行し、ホームページのURLを決定して、サイトをテストします。

1. Adminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「カテゴリ」ドロップダウン・メニューで、「コア」を選択します。

3. 「検索」をクリックします。

4. 次のプロパティの値を書きとめます。

- ft.cgipath

- ft.approot

5. テキスト・エディタを開きます。サーバー名、スラッシュ(/)およびcgipathを入力します。次の例のように、適切なプロトコル(http:// またはhttps://)をサーバー名の前に置きます。

Oracle WebLogic ServerおよびIBM WebSphereの場合の例:

http://bigfatsun.example.com:8080/servlet/

6. 文字列の末尾に、スラッシュを入力してから次のテキストを追記します。

ContentServer?pagename=your_home_page

これで、URLが次の例のようになります。

Oracle WebLogic ServerおよびIBM WebSphereの場合の例:

http://bigfatsun.example.com:8080/servlet/
ContentServer?pagename=ExampleSite/Page/Home

7. ブラウザが構成したURLをポイントするようにします。

8. エラーがないかページをスキャンし、すべてのリンクをテストしてこれらが機能することを確認します。

注意:

サイト全体を最初にミラーリングした後に、負荷がピークである条件で、またその後の標準的な時間帯で、システムの完全なテストを実施することをお薦めします。

39.17.11 スケジュールの設定

宛先が適切に構成されていることを確認後、ソース・システムで次の手順を完了することでパブリッシュ・システムの構成を終了できます。

1. 宛先に対してスケジュールされたパブリッシュ・イベントを作成します。この手順のヘルプは、トラブルシューティングを参照してください。

2. サイトのデザインにアセットでないイメージを使用している場合(つまり、サイト・デザイナがすべてのイメージをアセットとして管理するのではなくWebサーバーに格納している場合)、管理システム用Webサーバーから配信システム用Webサーバーへイメージ・ファイルを移動する方法を計画してください。たとえば、定期的なFTP送信を設定できます。

3. CSElementアセットやSiteEntryアセットではないエレメントおよびSiteCatalogページを使用している場合、CatalogMoverツールを使用してこれらを宛先システムにミラーリングする必要があります。CatalogMoverのヘルプは、『Oracle WebCenter Sitesでの開発』を参照してください。

39.17.12 配信システムでのアセットの無効化の解除

デフォルトでは、アセットがあるシステムから別のシステムへ(ソースから宛先へ)パブリッシュされると、パブリッシュ・システムがアセットを宛先システムで変更済として選択するように構成されています。その後、新しくパブリッシュされたアセットを他の宛先へパブリッシュできるようにするには、このアセットが宛先システムで承認される必要があります。

デフォルトの構成は、開発システムと管理システムに適しています。しかし、配信システムへパブリッシュする場合、パブリッシュ・システムがこの変更をマークするために時間をとられる必要はありません。アセットは配信システムへパブリッシュされますが、配信システムからではありません。

そのため、配信システムでは、次の手順を実行することでこのパブリッシュ機能をオフにします。

1. Adminインタフェースで、プロパティ管理ツールを開きます。(プロパティ管理ツールのアクセス手順は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「名前」フィールドに、xcelerate.publishinvalidateと入力します。

3. 「検索」をクリックします。

4. プロパティの名前を選択します。「値」フィールドで、値をfalseに設定します。

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

39.18 配信WebCenter Sitesシステムからのログの取得

WebCenter Sitesは、パブリッシュ関連のログ情報を配信システムから取得し、「パブリッシュ」コンソールに表示する方法を提供します。このために、WebCenter Sitesは、パブリッシュのセッションIDを関連する各ログ・エントリに挿入します。管理インタフェースには、パブリッシュ・セッションに関連するエントリを取得する機能があり、そのセッションの「ログ」フォームにそのエントリが表示されます。

リモート・パブリッシュのロギングを有効にするには::

1. ソースとターゲットの両方で、commons-logging.propertiesにある次のプロパティを設定し、ログ出力をアクティブにします。

org.apache.commons.logging.LogFactory=com.fatwire.cs.core.logging.ContextAwareLogFactory

2. ターゲット・システムで、次の行をweb.xmlに追加します。

<filter>
<filter-name>ContextHeaderFilter</filter-name>
<filter-class>
com.fatwire.cs.core.logging.context.filter.ContextHeaderFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>ContextHeaderFilter</filter-name>
<servlet-name>ContentServer</servlet-name>
</filter-mapping>

3. ターゲット・システムで、次のプロパティ(configフォルダ配下)を設定します。

log.file.location=<path to Sites log file>

39.19 XMLへのアセットのエクスポートのパブリッシュ方法

XMLへのアセットのエクスポートのパブリッシュ方法は、ディスクへのエクスポート方法と動的パブリッシュ方法を混合したものです。アセットはファイルにレンダリングされますが、このパブリッシュ方法は、ディスクへのエクスポートのパブリッシュ方法ではなく、動的な依存性の計算方法を使用します。

XMLへのアセットのエクスポートのパブリッシュ方法は、真のデータ変換方法であるという点で他の2つとは異なります。ディスクへのエクスポートのパブリッシュがページごとにHTMLファイルを1つ作成する(複数のアセットが1つのファイルにレンダリングされる)のに対して、XMLへのアセットのエクスポートは、このパブリッシュ方法を使用するために構成された宛先に対して承認されたアセットごとにXMLファイルを1つ作成します。

ディスクへのエクスポートのパブリッシュは、ディスクへのエクスポートのWebCenter Sites配信システムから配信されるディスクへのエクスポート・ファイルを作成します。それに対して、XMLへのアセットのエクスポートは、データベースまたはWebCenter Sites以外のシステムに配信するためのXMLファイルを作成します。

XMLへのアセットのエクスポートのパブリッシュ・セッションが実行されると、次のようになります。

- ソース・システムでは、承認システムにより、この宛先に対して承認されたアセットのリストが、XMLへのアセットのエクスポートに提供されます。

- XMLへのアセットのエクスポートは、リストの各アセットをXMLファイルにレンダリングします。出力ファイルにはアセットが記述され、すべてのアセット・フィールドのすべての値が明示されます。

XMLへのアセットのエクスポートのパブリッシュ方法を使用する場合、通常、品質保証プロセスを設定し、外部(WebCenter Sites以外の)システムに移動させる前に生成されたファイルをテストします。

次の各トピックでは、XMLへのアセットのエクスポートについて説明します。

- XML出力の理解

- XMLへのアセットのエクスポートに対するファイルの命名規則の理解

39.19.1 XML出力の理解

XMLへのアセットのエクスポートから出力されるのは、フィールド値に関してアセット・オブジェクトを記述する整形式のXMLです。フィールドは属性と呼ばれます。

各アセット・フィールドには、名前/値のペアがあります。値のステートメントには、フィールドのデータ型が含まれます。たとえば、Nameフィールドには文字が入ります。つまり、アセットのNameフィールドの名前/値のペアは次のように出力されます。

<attribute name="Name">
<string value="nameOfAsset"/>
</attribute>

フレックス属性は、フレックス・アセットのフィールドとして使用されます。フレックス・アセットの出力XMLでは、フレックス属性値はAttribute_に付加されます。サンプル・サイトの製品アセット価格に対する属性値の例を次に示します。

<attribute name="Attribute_price">
<decimal value="5.9"/>
</attribute>

XML出力は、各フィールド/属性のフィールド名ではなく列名を使用し、列名とフィールド名は異なる可能性があることに注意します。

次は、このパブリッシュ方法で作成されたXMLファイルの記述で、疑似DTDファイルとして表されています。:

<!-- ASSET:
-- ASSET defines an asset object
-- an asset is made up of attributes
-->
<!ELEMENT ASSET (ATTRIBUTE)*>
<!ATTLIST ASSET TYPE CDATA #REQUIRED>
<!ATTLIST ASSET ID CDATA #IMPLIED>
<!ATTLIST ASSET SUBTYPE CDATA #IMPLIED>

<!ELEMENT ATTRIBUTE (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)>
<!ATTLIST ATTRIBUTE NAME CDATA #REQUIRED>

<!ELEMENT STRING>
<!ATTLIST STRING VALUE CDATA #REQUIRED>

<!ELEMENT DATE>
<!ATTLIST DATE VALUE CDATA #REQUIRED>

<!ELEMENT INTEGER>
<!ATTLIST INTEGER VALUE CDATA #REQUIRED>

<!ELEMENT DECIMAL>
<!ATTLIST DECIMAL VALUE CDATA #REQUIRED>

<!ELEMENT BINARY>
<!ATTLIST BINARY VALUE CDATA #REQUIRED>

<!ELEMENT FILE (CDATA) >
<!ATTLIST FILE NAME CDATA #REQUIRED>

<!ELEMENT FILE>
<!ATTLIST FILE NAME CDATA #REQUIRED>

<!ELEMENT ASSETREFERENCE>
<!ATTLIST ASSETREFERENCE TYPE CDATA #REQUIRED>
<!ATTLIST ASSETREFERENCE VALUE CDATA #REQUIRED>

<!ELEMENT ARRAY (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)+>

<!ELEMENT STRUCT (FIELD)+>

<!ELEMENT FIELD (STRING | DATE | INTEGER | DECIMAL | BINARY | FILE | ASSETREFERENCE | ARRAY | STRUCT | LIST)+>
<!ATTLIST FIELD NAME CDATA #REQUIRED>

<!ELEMENT LIST (ROW)+>

<!ELEMENT ROW (COLUMN)+>

<!ELEMENT COLUMN ( STRING | INTEGER | DECIMAL | DATE | ASSETREFERNCE)>
<!ATTLIST COLUMN NAME CDATA #REQUIRED>

39.19.2 XMLへのアセットのエクスポートに対するファイルの命名規則の理解

エクスポートされるXMLファイルは次の規則に従って命名されます。

assetID.xml

たとえば、アセットIDが3344556677の場合、アセットのXMLファイルのファイル名は、次のようになります。

3344556677.xml

XMLへのアセットのエクスポートのパブリッシュ方法では、アセットのPathまたはFilenameフィールドに入力された任意の情報は使用しません。

39.20 XMLへのアセットのエクスポートに対するシステムの構成

XMLへのアセットのエクスポートの配信タイプ用に構成する際の主な手順は次のとおりです。

- XMLパブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

- ルート・エクスポート・ディレクトリの指定

- XMLへのアセットのエクスポートの宛先の構成

- XMLパブリッシュのためのアセットの承認

- 結果のパブリッシュとテスト

- スケジュールの設定

39.20.1 XMLパブリッシュでのバッチ・ユーザー・アカウントの作成(存在しない場合)

どのタイプのパブリッシュを実行する場合でも、あらかじめバッチ・ユーザー・アカウントの作成が必要です。作成するパブリッシュの宛先の数やタイプに関係なく、この手順は1回のみ実行する必要があります。

バッチ・ユーザー・アカウントを作成していない場合、これを作成します。手順については、バッチ・ユーザー・アカウントの作成(存在しない場合)を参照してください。

インストールにバッチ・ユーザー・アカウントが存在する場合は、ルート・エクスポート・ディレクトリの指定に進んでください。

39.20.2 ルート・エクスポート・ディレクトリの指定

この章で説明しているように、WebCenter Sitesがファイルをエクスポートするディレクトリは、wcs_properties.jsonファイルのcs.pgexportfolderプロパティによって決まります。

エクスポートされるファイルのルート・ディレクトリを設定するには::

1. Adminインタフェースで、プロパティ管理ツールを開きます。(詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

2. 「名前」フィールドに、cs.pgexportfolderと入力します。

3. 「検索」をクリックします。

4. プロパティの名前を選択します。「値」フィールドで、値を、ファイルのエクスポート先ディレクトリのフル・パスに設定します。これは、システムのグローバル設定です。

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

6. アプリケーション・サーバーを再起動します。

注意:

XMLへのエクスポートのパブリッシュ・セッションを実行する前に、この宛先ディレクトリが存在し、そこで作成されるXMLファイル用に十分な領域があることを確認します。

39.20.3 XMLへのアセットのエクスポートの宛先の構成

次に、次の手順を完了してXMLへのエクスポートの宛先を作成します。

1. ソースWebCenter Sitesシステムの「管理」タブで、「パブリッシュ」 を開き、次に「宛先」を開きます。

2. 「新規追加」をダブルクリックします。

「新規宛先の追加」フォームが表示されます。

次のようにフィールドに入力します。

- 名前: 一意の宛先の名前を入力します。

注意:

「名前」フィールドでは、次の文字は使用できません。一重引用符(')、二重引用符(")、セミコロン(;)、コロン(:)、小なり記号(<)、大なり記号(>)、パーセント記号(%)、疑問符(?)。さらに、名前の末尾にバックスラッシュ(\)は使用できません。

- 配信タイプ: 「XMLへのアセットのエクスポート: アセットごとにXMLファイルをエクスポート」を選択します。

- サイト: アセットを承認し、この宛先に対してパブリッシュすることが可能なサイトを選択します。

- ロール(パブリッシュの承認): アセットの承認権限を割り当てるロールを選択します。これらのロールが割り当てられるすべてのユーザーがアセットを承認できます。

- ロール(パブリッシュ): パブリッシュ権限を割り当てるロールを選択します。これらのロールが割り当てられるすべてのユーザーがパブリッシュできます。

3. ソース・システムに対して構成する必要がある追加のエクスポート先ごとに手順1を繰り返します。

39.20.4 XMLパブリッシュのためのアセットの承認

構成の簡易テストを実行するには、アセットを選択し、そのアセットと依存アセットを承認します。

サイト全体のテスト・パブリッシュを実行するには、そのサイトのすべてのアセットを承認します。多数のアセットを一度に承認する方法の詳細は、複数アセットの承認を参照してください。

39.20.5 結果のパブリッシュとテスト

宛先にパブリッシュできるアセットを承認したら、テスト・パブリッシュ・セッションを実行できます。

1. ソースWebCenter Sitesシステムのボタン・バーで「パブリッシュ」をクリックします。

2. 「パブリッシュ・コンソール」で、ドロップダウン・リストから宛先を選択し、「宛先の選択」をクリックします。

WebCenter Sitesに、この宛先にパブリッシュする準備のできているアセットに関する情報が表示されます。

3. 「パブリッシュ」をクリックします。

確認メッセージが表示されます。「はい」をクリックしてパブリッシュを続行します。

WebCenter Sitesは、この宛先に対して承認されたすべてのアセットをファイルにエクスポートします。ファイルは以前に指定したディレクトリに保存されます。

4. 「パブリッシュ・コンソール」の「アクティブ」タブで、セッションの動作を監視できます。

5. セッションが完了したら、「履歴」タブをクリックすると、このセッションのセッション・サマリーを表示できます。

セッション情報の上にマウス・ポインタを置いて、サマリー情報を表示します。「ログ」をクリックしてセッション・ログ・ファイルを表示します。

6. ログ・ファイルに結果として生成されるすべてのXMLファイルのリストが表示されるので、ファイルが正しいことを確認します。

39.20.6 スケジュールの設定

宛先が正しく構成されていることと、ディレクトリ名が必要に応じて作成されていることを確認後、ソース・システムで次の手順を実行してパブリッシュ・システムの構成を終了できます。

1. 宛先に対してスケジュールされたパブリッシュ・イベントを作成します。この手順のヘルプは、トラブルシューティングを参照してください。

2. 外部のWebCenter Sites以外のシステムに生成されたファイルを移動させる方法を計画します。たとえば、パブリッシュ・セッション完了後、ファイルを自動的にテスト領域に移動させる定期的なFTP送信を設定できます。

39.21 あるシステムから別のシステムへのサイトの移行

サイトの開発フェーズでは、サイト・デザイナおよび開発者は、サイトおよびアセット・タイプとそれをサポートするすべての構成(サブタイプ、アソシエーション、スタート・メニュー・アイテムなど)を開発し、テンプレートをコード化します。また、管理者が必要に応じてワークフローのエレメントを記述するなどしてユーザー・インタフェースをカスタマイズできるよう支援します。この作業は、開発システム上で行われます。

コンテンツ・プロバイダの準備が完了したサイトは、ミラーリング先構成機能を使用して、管理システムと配信システムの両方に移行できます。

この項の内容は次のとおりです。

- 開発システムから管理システムへのサイトの移動

- 配信システムへのサイトの移動

39.21.1 開発システムから管理システムへのサイトの移動

開発から管理へのサイトの移動の最初の部分では、サポート表とユーザーを設定し、および、使用されている場合、管理システム上でフレックス・ファミリを管理する必要があります。移動プロセスのこの部分は、1回のみ実行します。

次の手順を1回のみ実行します。

1. 管理(宛先)システムのWebCenter Sitesインタフェースにfwadminユーザーとしてログインします。

2. アセット・タイプのフィールドの参照表など、カスタム・サポート表が存在する場合は、管理(宛先)システムにそれらの表を作成します。

3. 管理システムで、すべてのユーザーを作成します。

4. ソース・システムで、WebCenter Sitesインタフェースにログインします。

5. パブリッシュ方法としてリアルタイムを使用する宛先システムのパブリッシュの宛先を作成します。

この手順および次の2つの手順の詳細は、リアルタイム・パブリッシュに対するシステムの構成を参照してください。

6. パブリッシュの宛先を初期化します。

7. パブリッシュの宛先を構成します。

8. 宛先(管理)システムで、サイトのユーザーを構成します。この手順の詳細は、ユーザーへのサイトのアクセス権限の付与(ユーザーへのロールの割当て)を参照してください。

9. フレックス・ファミリを作成した場合は、再度ソース・システムにログインします。データ構造のフレックス・アセットをすべて承認し、管理(宛先)システムにパブリッシュします。

アセットごとに承認するか、「管理」タブの「複数アセットの承認」機能を使用することができます。この機能の詳細は、複数アセットの承認を参照してください。

10. 宛先システムの他の適切なアセット(テンプレート、ページ、コレクション、問合せ、CSElementおよびSiteEntryなどの各アセット)をすべて承認し、パブリッシュします。

11. CSElementアセットやSiteEntryアセットではないSiteCatalog表にページ・エントリがある場合は、CatalogMoverを使用して、これらのアイテムを管理システムにミラーリングします。CatalogMoverのヘルプは、『Oracle WebCenter Sitesでの開発』を参照してください。

39.21.2 配信システムへのサイトの移動

配信システムにサイトを移動する際、スタート・メニュー・アイテム、ワークフロー、保存済の検索などをミラーリングする必要はありません。

配信システムにサイトを移動するには:

1. 配信(宛先)システムのWebCenter SitesAdminインタフェースにfwadminユーザーとしてログインします。

2. アセット・タイプのフィールドの参照表など、カスタム・サポート表が存在する場合は、配信(宛先)システムにそれらの表を作成します。

3. ソース・システムで、WebCenter Sitesインタフェースにログインします。

4. パブリッシュ方法としてサーバーへのミラーリングを使用する宛先システムのパブリッシュの宛先を作成します。

この手順の詳細は、ミラーリング先の作成を参照してください。

5. ミラーリング先を初期化します。

この手順の詳細は、宛先の初期化を参照してください。

6. ミラーリング先を構成します。

この手順の詳細は、ミラーリング先の構成を参照してください。

スタート・メニュー・アイテム、保存済の検索またはどのワークフロー・オプションも選択しないでください。

7. フレックス・ファミリを作成した場合は、再度ソース・システムにログインします。データ構造のフレックス・アセットをすべて承認し、管理(宛先)システムにパブリッシュします。

アセットごとに承認するか、「管理」タブの「複数アセットの承認」機能を使用することができます。この機能の詳細は、複数アセットの承認を参照してください。

8. 宛先(配信)システムの他の適切なアセット(テンプレート、ページ、コレクション、問合せ、CSElementおよびSiteEntryなどの各アセット)をすべて承認し、パブリッシュします。

9. CSElementアセットやSiteEntryアセットではないSiteCatalog表にページ・エントリがある場合は、CatalogMoverを使用して、これらのアイテムを管理システムにミラーリングします。CatalogMoverのヘルプは、『Oracle WebCenter Sitesでの開発』を参照してください。

10. オンライン・サイトにアセットではないイメージが存在する場合、それらは配信システムにコピーしてください。

39.22 複数アセットの承認

パブリッシュの各宛先には、複数のアセットを承認するオプションがあります。アップグレードの際、および宛先への最初のパブリッシュ・セッションで、特に役立ちます。

複数アセットの承認機能は、BulkApproverユーティリティではありません。BulkApproverユーティリティで承認するのは、BulkLoaderユーティリティを使用してWebCenter Sitesデータベースにインポートされたアセットのみです。BulkLoaderおよびBulkApproverの詳細は、『Oracle WebCenter Sitesでの開発』を参照してください。

複数アセットを承認するには::

1. 「管理」タブで、「パブリッシュ」、「宛先」の順に開き、アセットを承認する宛先を開きます。

2. その宛先の「複数アセットの承認」オプションをダブルクリックします。

アセットの承認フォームが表示されます。

図39-18 宛先へのパブリッシュに対するアセットの承認フォーム

3. 「アセット・タイプ」セクションの左側のリストで、承認するアセット・タイプを選択します。

4. 右側の「サンプル問合せ」リストで、問合せを選択します。必要な問合せと完全に一致する問合せが存在しない場合は、最も似ている問合せを選択します。

WebCenter Sitesにより、選択したアイテムに基づいてSQL問合せが作成され、「問合せ」ボックスに表示されます。

5. (オプション)必要であれば、SQL問合せを編集します。

6. 「次の単位で承認」フィールドをクリックし、数値を入力します。デフォルトは500です。

注意:

「パブリッシュの承認」ボタンをクリックすると、承認システムでアセットがバッチ単位で承認されます。バッチ当たりのアセットの数は、「次の単位で承認」フィールドの値によって決まります。承認プロセスはバックグラウンド・プロセスではないので、バッチの承認中にブラウザ・セッションがタイムアウトする可能性があります。

複数アセットの承認機能を使用する場合、セッションがタイムアウトしないようにするために、次の設定を調整します。

- wcs_properties.jsonファイルのcs.timeoutプロパティ。ブラウザ・セッション・タイムアウト値を設定します。まず、この値を1800 (30分に相当)に設定します。(『Oracle WebCenter Sitesプロパティ・ファイル・リファレンス』を参照してください。)

- 「次の単位で承認」フィールドで指定した値。まずデフォルトの500を使用して、必要であれば減らします。

7. 「以前に承認済のアセットの承認」オプションを次のように指定します。

- WebCenter Sitesによって、以前の承認がすべて無視され、選択したアセットがすべて再承認されるようにする場合、「はい」を選択します。その宛先のデフォルト・テンプレートが変更されるなど、なんらかの変更により、以前の承認が無効になっている可能性がある場合は、このようにします。

- WebCenter Sitesによって、未承認のアセットのみが承認されるようにする場合、「いいえ」を選択します。以前に承認されたアセットが今も有効であるという確信がある場合は、これが適切です。

8. 「パブリッシュの承認」をクリックします。

39.23 宛先の作成

宛先の作成手順は、前の項を参照してください。新しい宛先の作成の詳細は、必要に応じて次のリストの手順を参照してください。

- エクスポート先を作成するには、エクスポート先の構成を参照してください。

- ミラーリング先を作成するには、ミラーリング先の作成を参照してください。

- アセットのエクスポートの宛先を作成するには、XMLへのアセットのエクスポートの宛先の構成を参照してください。

39.24 宛先の編集

場合によっては、パブリッシュ宛先を作成した後でそれを変更する必要があります。すべてのタイプのパブリッシュ宛先の編集の基本手順については、ここで説明します。

宛先を編集するには::

1. 「管理」タブで、「パブリッシュ」を開き、さらに「宛先」を開きます。

2. 編集する宛先をダブルクリックします。

選択した宛先の「パブリッシュの宛先」フォームが表示されます。

3. 「編集」アイコンをクリックし、必要に応じて変更します。

このフォームのフィールドに入力可能な値の詳細は、これまでの項の配信タイプ固有の手順を参照してください。

- ディスクへのエクスポートの宛先の場合、エクスポート先の構成を参照してください。

- サーバーへのミラーリングの宛先の場合、ミラーリング先の作成を参照してください。

- XMLへのアセットのエクスポートの宛先の場合、XMLへのアセットのエクスポートの宛先の構成を参照してください。

39.25 宛先の削除

もうパブリッシュに必要でなくなった場合、宛先は簡単に削除できます。

宛先を削除するには::

1. 「管理」タブで、「パブリッシュ」を開き、さらに「宛先」を開きます。

2. 削除する宛先をダブルクリックします。

3. 「削除」アイコンをクリックします。

WebCenter Sitesに確認メッセージが表示されます。

4. 「宛先の削除」をクリックします。

39.26 エクスポート開始ポイントの作成

エクスポート開始ポイントの定義は、エクスポート開始ポイントの使用を参照してください。エクスポート開始ポイントの作成の詳細は、エクスポート開始ポイントの作成を参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。