この章の内容は次のとおりです。
トラブルシューティング機能については、「トラブルシューティング」を参照してください。
カスタマイズ・プロジェクトを開始する前に、WebCenter Contentのアーキテクチャとその動作について理解しておく必要があります。カスタマイズを効率的かつ効果的に作成するには、WebCenter Contentのディレクトリとファイル、利用可能なリソースおよびコンテンツ・サーバーの動作を理解しておく必要があります。
WebCenter ContentのWebユーザー・インタフェースであるコンテンツ・サーバーは、アプリケーションとしてOracle WebLogic Serverのドメインにデプロイされています。コンテンツ・サーバーの機能については、「コンテンツ・サーバーの動作」を参照してください。
カスタム・コンポーネントまたは動的サーバー・ページを作成する場合は、次の各ディレクトリに格納されているWebCenter Contentのファイルを主に操作します。
bin/
config/
components/
custom/
resources/
weblayout/
注意:
これらのファイルでデフォルトの変数を変更すると、WebCenter Contentが正常に動作しなくなる可能性があります。構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』の構成変数に関する項を参照してください
Oracle WebCenter Contentのドキュメントでは、Oracle WebCenter Contentのインストール、構成およびデプロイに関連付けられたディレクトリ内の変数を指すときに、次の用語を使用しています。
IdcHomeDir
: この変数は、WebCenter ContentのOracleホームにあるucm/idc/
ディレクトリを参照しており、このディレクトリには、コンテンツ・サーバー・メディアが置かれています。サーバー・メディアは、コンテンツ・サーバー、Oracle WebCenter Content: Inbound RefineryまたはOracle WebCenter Content: Recordsを実行できます。これは、基本的に読取り専用のディレクトリです。デフォルトの場所はORACLE_HOME
/wccontent/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アプリケーションの一部であるコンテンツ・サーバーのインスタンスに固有の構成ファイルおよびデータファイル用のルート・ディレクトリ。コンテンツ・サーバー・インスタンスのいずれかのタイプ(コンテンツ・サーバー(cs
)、Inbound Refinery (ibr
)またはRecords (urm
))用に、このIdocスクリプト変数を構成します。IntradocDir
のデフォルトの場所はDomainHome
/ucm/
short-product-id
/
ですが、IntradocDir
ディレクトリは、(intradoc.cfg
ファイルで定義されているように)別の場所にあってもかまいません。指定したディレクトリは、インスタンス・ディレクトリへの絶対パスで、特定のサーバーまたはノードに一意である必要があります。このディレクトリにはbin/
ディレクトリがあり、ここには起動ファイル(intradoc.cfg
および実行可能ファイル)が格納されています。
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
)をコマンドラインから起動しようとすると、このポートはリスニングできず、すでに使用中です
というエラー・メッセージが表示されます。
intradoc.cfg
ファイルは、ディレクトリ、インターネット、Inbound Refineryの設定など、コンテンツ・サーバーのシステム変数を定義するために使用します。これらの変数のうちのいくつかは、WebCenter Contentのシステム・プロパティ・ユーティリティを使用して設定できます。次の例は、一般的なintradoc.cfg
ファイルを示しています。
intradoc.cfg File <?cfg jcharset="Cp1252"?> #Server System Properties IDC_Id=UCM_server1 #Server Directory Variables IdcHomeDir=ORACLE_HOME/wccontent/ucm/idc/ FmwDomainConfigDir=ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/ AppServerJavaHome=JRE_HOME AppServerJavaUse64Bit=true IntradocDir=ORACLE_HOME/user_projects/domains/base_domain/ucm/cs/ VaultDir=ORACLE_HOME/user_projects/domains/base_domain/ucm/cs/vault/ WeblayourDir=ORACLE_HOME/user_projects/domains/base_domain/ucm/cs/weblayout/ #Server Classpath variables #Additional Variables UserProfilesDir=ORACLE_HOME/user_projects/domains/base_domain/ucm/cs/data/users/profiles/
config/
ディレクトリは、IntradocDir
/config/
にあります。IntradocDir
のデフォルトの場所はDomainHome
/ucm/
short-product-id
/ですが、IntradocDir
/
ディレクトリは、(intradoc.cfg
ファイルで定義されているように)別の場所にあってもかまいません。config/
ディレクトリの内容を表1-2に示します。
表1-2 configディレクトリの内容
ファイル | 説明 |
---|---|
|
システム構成変数を定義します。 |
config.cfg
ファイルは、コンテンツ・サーバー・システムのグローバル変数を定義するために使用します。これらの変数のうちのいくつかは、WebCenter Contentのシステム・プロパティ・ユーティリティを使用するか、または「管理」、「管理サーバー」、「一般構成」メニュー・オプションからアクセスできる一般構成ページで変数を変更して設定できます。次の例は、一般的なconfig.cfg
ファイルを示しています。
Example - config.cfg File <?cfg jcharset="Cp1252"?> #Server System Properties IDC_Name=InstanceName IdcProductName=idccs InstanceMenuLabel=InstanceName InstanceDescription=Instance InstanceName SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1 #Database Variables SystemDatabase:DataSource=CSDS SystemDatabase:UseDataSource=true #Internet Variables HttpServerAddress=host:16200 MailServer=mail SysAdminAddress=sysadmin@example.com HttpRelativeWebRoot=/cs/ UseSSL=No #General Option Variables IsAutoNumber=Yes AutoNumberPrefix=ContentIDPrefix #Additional Variables UseAccounts=true registerStartMenuActions=1 WebServer=javaAppServer FileEncoding=UTF8
IntradocDir
/data/components/
ディレクトリには、システム・コンポーネントを構成するためにコンテンツ・サーバーが使用するファイルが含まれています。components/
ディレクトリの内容を表1-3に示します。
Table 1-3 componentsディレクトリの内容
ファイル | 説明 |
---|---|
|
コンテンツ・サーバー・システムに追加されているコンポーネント、およびそれらが有効になっているか無効になっているかを識別します。例: |
|
コンポーネントの構成ステータスを識別します。 |
help
というコンポーネントの構成ステータスを定義するcomponent
.hda
ファイルを次の例に示します。
Example - component.hda File <?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
IdcHomeDir
/resources/
ディレクトリには、admin/
とcore/
という2つのディレクトリが含まれています。
resources/core/
ディレクトリには、Webページをアセンブルするためにコンテンツ・サーバーが使用するファイルが含まれています。resources/core/
ディレクトリのサブディレクトリを表1-4に示します。
表1-4 resources/coreディレクトリの内容
サブディレクトリ | 説明 |
---|---|
|
コンテンツ・サーバーのベース構成ファイルを格納しています。 |
|
Idoc Scriptの |
|
インストーラおよび関連アプリケーションによって使用されるファイルを格納しています。 |
|
公開エンジンによって処理され、 |
|
コンテンツ・サーバーの、ローカライズされた文字列定義を格納しています。 |
|
コンテンツ・サーバーのレポートのテンプレートを格納しています。 |
|
Idoc Scriptのリソース表定義(問合せ、サービスなどの表リソース・データ)を格納しています。 |
|
コンテンツ・サーバーのすべてのページ(レポートは除く)のテンプレートを保持しています。 |
resources/admin/
ディレクトリのサブディレクトリを表1-5に示します。
表1-5 resources/adminディレクトリの内容
サブディレクトリ | 説明 |
---|---|
|
Idoc Scriptの |
|
Idoc Scriptのリソース表定義を格納しています。 |
|
コンテンツ・サーバーのすべてのページ(レポートは除く)のテンプレートを保持しています。 |
DomainHome
/ucm/
short-product-id
/weblayout/
ディレクトリには、コンテンツ・サーバーのWebサイトの各種ページで表示するためにWebサーバーで利用可能なファイルが含まれています。weblayout/
ディレクトリのサブディレクトリを表1-6に示します。
表1-6 weblayoutディレクトリの内容
サブディレクトリ | 説明 |
---|---|
|
Web で表示可能なコンテンツ・アイテムおよび動的サーバー・ページを格納しています。 |
|
アイコンやホーム・ページのグラフィックなどのイメージを格納しています。 |
|
レイアウト、スキンおよびスキーマ情報を格納しています。 |
リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。これには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。
リソースはコンテンツ・サーバー・ソフトウェアの重要な部分なので、カスタム・コンポーネントまたは動的サーバー・ページを作成しようとする前に精通しておく必要があります。リソース・ファイルは、コンポーネント・ウィザードを使用して作成、編集または削除できます。コンポーネント・ウィザードは、カスタム・リソースを作成するときの開始ポイントとして使用することもできます。
リソースは異なる8つのカテゴリに分類され、これについては表1-7で説明します。この表に一覧表示されている最初の5つのタイプは、リソース・タイプのリソースとも呼びます。
表1-7 リソース・タイプ
リソース・タイプ | 説明 | 標準的なリソースの例 |
---|---|---|
HTMLインクルード |
コンテンツ・サーバーの複数のWebページで使用されるHTMLマークアップおよびIdocスクリプト・コードの断片を定義します。 |
|
動的データ表 |
HTML表定義、インタフェース・メニュー・アクション、またはメタデータ・フィールドに関する情報をロードするIdoc Script内から、あるいは、SharedObjectsにロードされた静的表に対する代替としてJavaコード内から、 |
|
文字列 |
ユーザー・インタフェースおよびエラー・メッセージ用にローカライズされた文字列を定義します。 |
|
動的表(HDAフォーマット) |
動的な(頻繁に変更される)コンテンツをコンテンツ・サーバーに表形式で提供します。 |
|
静的表(HTMLフォーマット) |
静的な(めったに変更されない)コンテンツをコンテンツ・サーバーに表形式で提供します。 |
|
問合せ |
データベース問合せを定義します。 |
|
サービス |
コンテンツ・サーバーで実行できるサービスのスクリプトを定義します。 |
|
テンプレート |
特定のWebページをアセンブルするためにコンテンツ・サーバーが使用するコードを含むテンプレートを定義します。 |
|
環境 |
コンテンツ・サーバーの構成設定を定義します。 |
|
コンテンツ・サーバーでは、主に3種類の変更を行うことができます。
製品のルック・アンド・フィールの変更
コンテンツ・サーバー・インタフェースのルック・アンド・フィールをカスタマイズして、組織の仕様に合わせることができます。インタフェースの変更は、標準のコンテンツ・サーバーWebページに表示されるアイコンを置換するような簡単なものから、インタフェース全体を再設計するような複雑なものまで可能です。
製品の機能の変更
製品の機能を変更することによって、コンテンツ・サーバーをビジネスや組織の機能に合わせることができます。たとえば、デフォルトの日付やタイムスタンプを変更したり、チェックイン動作の機能を変更したりできます。
環境への製品の統合
シェル・スクリプト、SOAP、J2EEおよびクラスタを使用して、コンテンツ・サーバーをサイトの現在の環境により緊密に統合できます。
カスタマイズを開始する前に、カスタマイズを行う理由を明確にすることが重要です。たとえば、企業ブランドを追加するには、「レイアウト・サンプルの変更」を使用して追加できます。また、セキュリティ機能を変更するには、デフォルトのセキュリティ設定を変更するためのコンポーネントを使用できます。
多くの場合、カスタマイズは、コンテンツ・サーバーを組織のビジネス・プラクティスに適合させるために行います。ビジネス・プロセスを評価した後、コンテンツ・サーバーをカスタマイズする前にプロシージャに軽微な変更を加えたほうが効率的だとわかることもよくあります。
カスタマイズは、主に次の6つの手順で行います。
コンテンツ・サーバーでは、高度な機能を提供するために様々なテクノロジが組み合されています。コンテンツ・サーバーを変更するには、これらのテクノロジの一部またはすべてについて一定の経験およびスキルが必要です。
コンテンツ・サーバーをカスタマイズするために必要な技術的なスキルは、カスタマイズの複雑さによって異なる場合があります。たとえば、多くのカスタマイズは、HTMLおよびIdocスクリプトの知識で実行できます。
このリストでは、コンテンツ・サーバーの変更に必要となる可能性のあるテクノロジおよび経験を、重要度の高いものから順に説明します。
コンテンツ・サーバーのアーキテクチャ
システムのカスタマイズを開始する前に、コンテンツ・サーバーの動作とコンポーネントおよび動的サーバー・ページの機能を十分に理解しておく必要があります。
HTMLおよびカスケード・スタイル・シート(CSS)
コンテンツ・サーバーWebページのテンプレートを変更するには、HTMLおよびCSSについて十分に理解する必要があります。テンプレートでHTMLを使用する場合、作業は複雑ではありませんが、テンプレートではHTML表を常時使用し、フォームを頻繁に使用します。std_page.idoc
ファイルとstd_css.idoc
ファイルには、デフォルトのテンプレートのルック・アンド・フィール(フォントやレイアウトなど)を制御するためのカスケード・スタイルシートが含まれています。
Idocスクリプト
Idocスクリプトは、コンテンツ・サーバーのカスタム・サーバー側スクリプト言語です。ほぼすべてのコンテンツ・サーバーWebページにはIdocスクリプト・コードが含まれており、様々なページ要素を処理するためのメソッドが提供されています。
JavaScript
コンテンツ・サーバーのほとんどのページの内部コンテンツではJavaScriptを使用していませんが、「検索」「チェックイン」「更新」の各ページは顕著な例外です。これらのページのかわりに呼び出されるカスタマイズを作成する前に、JavaScriptについて理解しておく必要があります。また、レイアウトを変更するには、JavaScriptを理解する必要があります。レイアウトの変更は、設計およびナビゲーションにおいてJavaScriptおよびカスケーディング・スタイルシートに大きく依存します。
Structured Query Language(SQL)
コンテンツ・サーバーでは、データベースに対する問合せを実行するためにSQLを使用しています。SQLの知識があれば、標準的な問合せの理解および独自のカスタム問合せの作成に役立つ場合があります。
Javaプログラミング
コンテンツ・サーバーはJavaクラスとともに実装されます。基礎となる機能を変更する前に、Javaおよびコンテンツ・サーバーのJavaクラス・ファイルについて十分に理解しておく必要があります。ただし、Javaを使用しなくても、製品を広範にカスタマイズできます。
その他のプログラミング
複雑なカスタマイズまたはWebCenter Contentと他のシステムとの統合を行う場合、Visual Basic、COM、.Net、C++、VBScriptなどの他のツールの経験が役立つ場合があります。
コンテンツ・サーバーをカスタマイズする場合、次のツールが有用な場合があります。
テキスト・エディタ
ほとんどの製品カスタマイズは、Microsoft WordPadやviなどの通常のテキスト・エディタを使用して実行できます。
HTMLエディタ
注意:
グラフィカルHTMLエディタではソースのHTMLを頻繁に変更するため、Idocスクリプトのタグが、コンテンツ・サーバーで認識されなくなった文字列に変換される可能性があります。グラフィカル・エディタを使用する場合は、非グラフィカル・モードで編集してください。
HTMLページの操作にはグラフィカルHTMLエディタのほうを使用する場合は、非グラフィカル・モードを使用して編集します。
複数のブラウザ
コンテンツ管理システムとのインタフェースで使用される可能性があるWebブラウザの複数のバージョンで、カスタマイズをテストする必要があります。Internet Explorer、FirefoxおよびChromeでは、コンテンツの表示は同じではなく、同じブラウザの異なるバージョンで異なる動作が示される場合があります。
JavaScriptデバッガ
JavaScriptデバッガによって、JavaScript開発のタスクが簡略化される場合があります。数多くのJavaScriptデバッガがインターネットからダウンロード可能です。
Java用の統合開発環境(IDE)
カスタマイズの際にJavaコードの開発が必要になる場合は、適切なJava開発環境が必要です。
WebCenter Contentをカスタマイズする前に、コンテンツ・サーバーの動作について理解しておく必要があります。
コンテンツ・サーバーの管理の概要は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のOracle WebCenter Contentの管理の概要に関する項を参照してください。
起動時に、コンテンツ・サーバーのインスタンスでは内部初期化が実行され、次のアイテムがロードされます。
構成変数
標準的なテンプレート、リソースおよびレポート
カスタム・コンポーネント(テンプレート、リソース、構成変数、レポートなど)
図1-1に、起動時にコンテンツ・サーバーで実行される4つのステップを示します。これらのステップの詳細は、起動ステップで説明します。
複数の構成ファイルのロードの順序が持つ影響を理解しておくことが重要です。それは、1つの変数が複数のファイルで設定されている場合、最後にロードされた変数が優先されるためです。たとえば、IntradocDir
/data/components/
component_name
/config.cfg
ファイルより前にIntradocDir
/config/config.cfg
ファイルがロードされた場合、config/config.cfg
ファイルで設定された変数の値が、component_name
/config.cfg
によって変更されることがあります。
ファイルは、次に示す順序でロードされます(各コンポーネントにすべてのファイルが存在しているわけではありません)。
DomainHome
/ucm/
short-product-id
/bin/intradoc.cfg
IntradocDir
/config/config.cfg
DomainHome
/ucm/
short-product-id
/custom/
component_name
/*_environment.cfg
このファイルがないコンポーネントもあれば、名前がenvironment.cfg
になっているファイルもあります。
IntradocDir
/data/components/
component_name
/install.cfg
IntradocDir
/data/components/
component_name
/config.cfg
DomainHome
/ucm/
short-product-id
/bin/intradoc.cfg
このファイルは、起動の最後に再度読み取られ、他の設定に対するオーバーライドが許可されます。
たとえば、リストにあるファイルのそれぞれで同じ変数が設定された場合、intradoc.cfg
ファイルが最後にロードされたため、そのファイルにある変数の値が優先されます。
構成を表示する場合は、GET_SYSTEM_AUDIT_INFO
サービスを使用して、すべての構成エントリ、およびそれらが設定された場所を表示できます。
コンポーネントの変数を変更する場合は、拡張コンポーネント・マネージャの「コンポーネント構成の更新」領域を使用できます。この領域には、component_name
/config.cfg
ファイルで編集可能な構成のあるコンポーネントのドロップダウン・リストが表示されます。コンポーネントを選択して「更新」をクリックすると、コンテンツ・サーバーの「コンポーネント構成の更新」ページに進みます。
構成ファイルは手動で編集することもできます。拡張コンポーネント・マネージャの「コンポーネント構成の更新」リストにコンポーネントが表示されていない場合は、構成ファイルのいずれかで直接変更できます。
コンテンツ・サーバーでは、テンプレート・ページおよびリソースのキャッシングが次のように処理されます。
テンプレート・ページおよびリソースは、コンテンツ・サーバーにロードされると、ページ表示が迅速になるようにメモリーにキャッシュされます。
テンプレート・ページ、レポート・ページまたはHTMLインクルード・リソースを変更した場合、あるいは動的サーバー・ページに対するリビジョンにチェックインした場合は、変更内容は即座に有効となります。
関連付けられたWebページに対する次回の要求、またはページのリフレッシュによって、変更内容が反映され、新しい情報がキャッシュされます。この処理が行われるのは、ページ要求ごとにページが動的にアセンブルされるためです。構成変数DisableSharedCacheChecking
を設定することによって、この動作を無効にして、パフォーマンスを向上させることができます。
それ以外のコンポーネント・ファイル(サービス、問合せ、環境変数、表、idc
short-product-id
_components.hda
ファイル、template.hda
ファイルなど)を変更した場合は、コンテンツ・サーバーを再起動して、変更内容を有効にする必要があります。そのような変更が即座に実装された場合、コンテンツ・サーバーが正しく動作しなくなる可能性があります。
文字列の変更後にコンテンツ・サーバーを再起動する必要はありません。ただし、「管理アクション」ページの「Webレイアウト公開」領域で、「文字列と動的ファイルのパブリッシュ」または「文字列、静的ファイルおよび動的ファイルのパブリッシュ」をクリックして、ww_strings.js
ファイルを再パブリッシュする必要があります。詳細は、『コンテンツ・サーバーのコンポーネントのスタート・ガイド』を参照してください。
コンテンツ・サーバーでは、動的Webページをアセンブルするために、IdcHomeDir
/resources/
ディレクトリに格納されているファイルにある次の情報を使用します。
Webページの構造と書式
この構造と書式は、特定のHTMLテンプレート・ファイルで定義されています。テンプレート・ファイルは、主にresources/core/templates
ディレクトリに格納されていますが、resources/core/reports
ディレクトリおよびresources/admin/templates
ディレクトリに格納されているテンプレートもあります。
テンプレートで参照されるリソース
これらのリソースは、resources
ディレクトリのサブディレクトリ内の.htm
ファイルおよび.idoc
ファイルにあります。リソースには、HTMLおよびIdocスクリプトのマークアップ、ローカライズされた文字列、データベースからデータを収集する問合せ、および情報を条件付きで書式設定する特殊コードが考えられます。
原則として、それぞれのWebページには、次のリソースが含まれます。
ページの標準的なヘッダー
ページの標準的な先頭
ページの標準的な末尾
コンテンツ・サーバーのリソースはすべて起動時にメモリーにキャッシュされるため、コンテンツ・サーバーには、ページに表示される標準的な断片の定義があります。さらにコンテンツ・サーバーでは、標準的なリソースと、テンプレートで指定された一意のリソースを組み合せて、Webページを作成します。
動的サーバー・ページの場合は、テンプレート・ページとカスタム・リソース・ファイルがコンテンツ・サーバーにチェックインされます。これらのページのいずれかがWebブラウザによって要求されると、コンテンツ・サーバーでは、ファイル拡張子が動的サーバー・ページと認識され、それによって特殊な処理が可能となります。その時点では、ページ・アセンブリ・プロセスは、標準的なプロセスと本質的に同じです。ただし例外として、そのページでは、resources
ディレクトリ内の標準的なリソースと、コンテンツ・サーバーにチェックインされたカスタム・リソースの両方が使用できます。
Oracle Databaseなど、一部のデータベースでは、すべての列名が大文字で返されます。したがって、コンテンツ・サーバーがこれらのデータベースから問合せ結果を受け取ると、大文字からコンテンツ・サーバーで使用される値に、列名をマップする必要があります。
このケース・マッピング問題では、あるデータベースを使用するコンテンツ・サーバーのインスタンス用に作成されたカスタム・コンポーネントが、別のデータベースを使用するコンテンツ・サーバーのインスタンスでは正しく機能しない場合が考えられます。
列名をマップするために、IdcHomeDir
/resources/core/resources/upper_clmns_map.htm
ファイルには、ColumnTranslation
というマッピング表が含まれています。WebCenter Contentデータベースのフィールドでないフィールドにアクセスするコンポーネントを作成するとき(たとえば、WebCenter Contentデータベース内のカスタム表にアクセスするコンポーネントを作成する場合)に、このファイルに問合せ値を追加します。
upper_clmns_map.htm
ファイルの使用については、「システム設定の変更」を参照してください。
ローカライズされた文字列とは、ユーザー・インタフェースとエラー・メッセージを、ユーザーのロケールで指定された言語で表示する手段です。コンテンツ・サーバーでは、ベース言語の文字列リソース・ファイルをロードし、サポートされているあらゆる言語のリソース・ファイルもロードします。ハードコード化されたテキストを表示するかわりに、テンプレート・ページ、アプレットおよびエラー・メッセージがこれらのリソース・ファイル内の文字列IDを参照し、この文字列IDはさらに、ユーザーのロケール情報を含むExecutionContextを使用して解決されます。
コンテンツ・サーバーは、コンテンツ中心のWebサイトに向けたコンテンツ管理ソリューションの役割を果たすだけでなく、スケーラブルなコンテンツ管理インフラストラクチャも提供しており、このインフラストラクチャは、数多くの多様な環境やプラットフォームで複数のエンタープライズ・アプリケーションをサポートします。この統合ソリューションにより、他のエンタープライズ・アプリケーションは、コンテンツ管理システムで管理されているコンテンツにアクセスできます。また、これらのアプリケーションには、全文検索やメタデータ検索、ライブラリ・サービス、ワークフロー、サブスクリプション通知、幅広く品揃えされている統合メソッドを通じたコンテンツ変換機能などの重要なコンテンツ管理機能が提供されています。
コンテンツ・サーバーとエンタープライズ・アプリケーションの統合については、『環境へのWebCenter Contentの統合のスタート・ガイド』を参照してください。