ヘッダーをスキップ
Oracle® WebCenter Content Content Server開発者ガイド
11gリリース1(11.1.1)
B66702-01
  ドキュメント・ライブラリへ移動
ライブラリ		 目次へ移動
目次		 索引へ移動
索引
前
前へ 		 次
次		  

1 Oracle WebCenter Content Serverの概要

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

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

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

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

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

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

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

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

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

  • bin

  • config

  • components

  • resources

  • weblayout


    注意:

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

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

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

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

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

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

    • cs (Content Server)

    • ibr (Inbound Refinery)

    • urm (Records)

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

1.1.1.2 binディレクトリ

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

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

要素 説明

実行可能ファイル

サービス

  • IdcServer

  • IdcServerNT

アプレット

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

ユーティリティ

  • BatchLoader

  • Installer

  • IdcAnalyze

  • ComponentWizard

  • SystemProperties

  • IdcCommand

intradoc.cfgファイル

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


注意:

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

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

例1-1 lintradoc.cfgファイル

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

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

1.1.1.3 configディレクトリ

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

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

ファイル 説明

config.cfg

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

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

例1-2 config.cfgファイル

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

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

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

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

#IdcRefinery Variables

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

1.1.1.4 componentsディレクトリ

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

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

ファイル 説明

idcshort-product-id_components.hda

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

component.hda

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

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

例1-3 component.hdaファイル

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

1.1.1.5 resourcesディレクトリ

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

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

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

サブディレクトリ 説明

config

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

idoc

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

install

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

javascript

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

jspserver

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

lang

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

reports

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

resources

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

tables

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

templates

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

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

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

サブディレクトリ 説明

idoc

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

tables

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

templates

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

1.1.1.6 weblayoutディレクトリ

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

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

サブディレクトリ 説明

groups

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

images

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

resources

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

1.1.2 リソース

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

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

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

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

リソース・タイプ 説明 標準的なリソースの例

HTMLインクルード

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

IdcHomeDir/resources/core/idoc/std_page.idoc

動的データ表

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

IdcHomeDir/resources/core/idoc/std_data.idoc

文字列

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

IdcHomeDir/resources/core/lang/cs_strings.htm

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

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

IdcHomeDir/resources/core/templates/templates.hda

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

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

IdcHomeDir/resources/core/tables/std_locale.htm

問合せ

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

IdcHomeDir/resources/core/tables/query.htm

サービス

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

IdcHomeDir/resources/core/tables/std_services.htm

テンプレート

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

IdcHomeDir/resources/core/templates/checkin_new.htm

環境

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

IntradocDir/config/config.cfg

1.2 カスタマイズ・タイプ

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

1.3 カスタマイズ計画

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

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

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

  1. カスタマイズする理由を特定します。

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

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

  2. カスタマイズを慎重に計画します。

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

  3. 使用可能なソリューションがあるかどうかを確認します。

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

  4. 問題を評価し、その問題を解決することがどの程度必要であるかを評価します。

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

  5. 個別の環境でカスタマイズを完全にテストします。

    可能な場合は、エンド・ユーザーがテストに参加するように調整します。テストがリリースのすべての条件を満たすと、ユーザーに変更内容とその実装方法を通知します。

  6. 作成したカスタマイズをドキュメント化します。

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

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

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

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

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

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

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

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

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

1.5.1 起動動作

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

  1. 構成変数

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

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

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

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

図1-1の説明が続きます
「図1-1 コンテンツ・サーバーの起動動作」の説明

1.5.1.1 起動手順

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

  1. 内部初期化を行います。

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

  2. 構成変数をロードします。

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

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

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

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

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

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

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

  3. 標準的なリソース、テンプレートおよびレポートをロードします。

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

  4. カスタム・コンポーネントをロードします。

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

1.5.1.2 構成のロードの影響

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

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

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

  2. IntradocDir/config/config.cfg

  3. DomainHome/ucm/short-product-id/custom/component_name/*_environment.cfg

    このファイルがないコンポーネントもあれば、名前がenvironment.cfgになっているファイルもあります。

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

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

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

    このファイルは、起動の最後に再度読み取られ、他の設定より優先されるものが許可されます。

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

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

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

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

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

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

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

  • テンプレート・ページ、レポート・ページまたはHTMLインクルード・リソースを変更した場合、あるいは動的サーバー・ページに対するリビジョンにチェックインした場合は、変更内容は即座に有効となります。

    関連付けられたWebページに対する次回の要求、またはページのリフレッシュによって、変更内容が反映され、新しい情報がキャッシュされます。この処理が行われるのは、ページ要求ごとにページが動的にアセンブルされるためです。構成変数DisableSharedCacheCheckingを設定することによって、この動作を無効にして、パフォーマンスを向上させることができます。

  • それ以外のコンポーネント・ファイル(サービス、問合せ、環境変数、表、idcshort-product-id_components.hdaファイル、template.hdaファイルなど)を変更した場合は、コンテンツ・サーバーを再起動して、変更内容を有効にする必要があります。そのような変更が即座に実装された場合、コンテンツ・サーバーが正しく動作しなくなる可能性があります。

    文字列の変更後にコンテンツ・サーバーを再起動する必要はありません。ただし、「管理アクション」ページの「Webレイアウト公開」領域で、「文字列と動的ファイルのパブリッシュ」または文字列、静的ファイルおよび動的ファイルのパブリッシュをクリックして、ww_strings.jsファイルを再パブリッシュする必要があります。詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。

1.5.3 ページ・アセンブリ

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

  • Webページの構造と書式

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

  • テンプレートで参照されるリソース

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

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

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

  • ページの標準的な先頭

  • ページの標準的な末尾

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

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

1.5.4 データベースとの対話

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

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

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

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

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

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

1.5.6 アプリケーション統合

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

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

  前
前へ 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 目次へ移動
目次		 索引へ移動
索引