Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1 (11.1.1) B72427-04 |
|
![]() 前 |
![]() 次 |
ホーム > Oracle WebCenter Contentでの開発 > Oracle WebCenter Contentでの開発の概要
この章ではOracle WebCenter Contentの概要を示し、Oracle WebCenter Content Serverのカスタマイズに必要なスキル、ツールおよびリソースについて説明します。
この章の内容は次のとおりです。
トラブルシューティングのヒントについては、付録C「トラブルシューティング」を参照してください。
カスタマイズ・プロジェクトを開始する前に、WebCenter Contentのアーキテクチャとその動作について理解しておく必要があります。カスタマイズを効率的かつ効果的に作成するには、WebCenter Contentのディレクトリとファイル、利用可能なリソースおよびコンテンツ・サーバーの動作を理解しておく必要があります。
WebCenter ContentのWebユーザー・インタフェースであるコンテンツ・サーバーは、アプリケーションとしてOracle WebLogic Serverのドメインにデプロイされています。コンテンツ・サーバーの機能については、第1.5項「コンテンツ・サーバーの動作」を参照してください。
WebCenter Contentは、IBM WebSphere Application Serverにデプロイすることもできます。詳細は、『Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイド』のIBM WebSphereでのOracle WebCenter Contentの管理に関する項を参照してください。
カスタム・コンポーネントまたは動的サーバー・ページを作成する場合は、次の各ディレクトリに格納されているWebCenter Contentのファイルを主に操作します。
bin/
config/
components/
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を実行できます。これは、基本的に読取り専用のディレクトリです。デフォルトの場所はWCC_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アプリケーションの一部であるコンテンツ・サーバーのインスタンスに固有の構成ファイルおよびデータファイル用のルート・ディレクトリ。コンテンツ・サーバー・インスタンスのいずれかのタイプ(コンテンツ・サーバー(cs
)、Inbound Refinery (ibr
)またはRecords (urm
))用に、このIdocスクリプト変数を構成します。IntradocDir
のデフォルトの場所はDomainHome
/ucm/
short-product-id
/
ですが、IntradocDir
ディレクトリは、(intradoc.cfg
ファイルで定義されているように)別の場所にあってもかまいません。指定したディレクトリは、インスタンス・ディレクトリへの絶対パスで、特定のサーバーまたはノードに一意である必要があります。このディレクトリには、起動ファイル(intradoc.cfg
および実行可能ファイル)を含む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ディレクトリの内容
要素 | 説明 |
---|---|
実行可能ファイル |
|
|
コンテンツ・サーバーのサービス、アプレットおよびユーティリティの設定を含む構成ファイル |
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
config/
ディレクトリは、IntradocDir
/config/
にあります。IntradocDir
のデフォルトの場所はDomainHome
/ucm/
short-product-id
/ですが、IntradocDir
/
ディレクトリは、(intradoc.cfg
ファイルで定義されているように)別の場所にあってもかまいません。config/
ディレクトリの内容を表1-2に示します。
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
IntradocDir
/data/components/
ディレクトリには、システム・コンポーネントを構成するためにコンテンツ・サーバーが使用するファイルが含まれています。components/
ディレクトリの内容を表1-3に示します。
Table 1-3 componentsディレクトリの内容
ファイル | 説明 |
---|---|
コンテンツ・サーバー・システムに追加されているコンポーネント、およびそれらが有効になっているか無効になっているかを識別します。例: |
|
|
コンポーネントの構成ステータスを識別します。 |
help
というコンポーネントの構成ステータスを定義するcomponent
.hda
ファイルを例1-3に示します。
IdcHomeDir
/resources/
ディレクトリには、admin/
とcore/
という2つのディレクトリが含まれています。
resources/core/
ディレクトリには、Webページをアセンブルするためにコンテンツ・サーバーが使用するファイルが含まれています。resources/core/
ディレクトリのサブディレクトリを表1-4に示します。
表1-4 resources/coreディレクトリの内容
サブディレクトリ | 説明 |
---|---|
コンテンツ・サーバーのベース構成ファイルを格納しています。 |
|
Idoc Scriptの |
|
インストーラおよび関連アプリケーションによって使用されるファイルを格納しています。 |
|
公開エンジンによって処理され、 |
|
|
|
コンテンツ・サーバーの、ローカライズされた文字列定義を格納しています。 |
|
コンテンツ・サーバーのレポートのテンプレートを格納しています。 |
|
コンテンツ・サーバーのリソース定義(問合せ、ページ・リソース、サービスなどのリソース・データ)を格納しています。 |
|
Idoc Scriptのリソース表定義を格納しています。 |
|
コンテンツ・サーバーのすべてのページ(レポートは除く)のテンプレートを保持しています。 |
resources/admin/
ディレクトリのサブディレクトリを表1-5に示します。
DomainHome
/ucm/
short-product-id
/weblayout/
ディレクトリには、コンテンツ・サーバーのWebサイトの各種ページで表示するためにWebサーバーで利用可能なファイルが含まれています。weblayout/
ディレクトリのサブディレクトリを表1-6に示します。
リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。これには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。
リソースはコンテンツ・サーバー・ソフトウェアの重要な部分なので、カスタム・コンポーネントまたは動的サーバー・ページを作成しようとする前に精通しておく必要があります。リソース・ファイルは、コンポーネント・ウィザードを使用して作成、編集または削除できます。コンポーネント・ウィザードは、カスタム・リソースを作成するときの開始ポイントとして使用することもできます。
リソースは異なる8つのカテゴリに分類され、これについては表1-7で説明します。この表に一覧表示されている最初の5つのタイプは、リソース・タイプのリソースとも呼びます。
表1-7 リソース・タイプ
コンテンツ・サーバーでは、主に3種類の変更を行うことができます。
製品のルック・アンド・フィールの変更
コンテンツ・サーバー・インタフェースのルック・アンド・フィールをカスタマイズして、組織の仕様に合わせることができます。インタフェースの変更は、標準のコンテンツ・サーバーWebページに表示されるアイコンを置換するような簡単なものから、インタフェース全体を再設計するような複雑なものまで可能です。
製品の機能の変更
製品の機能を変更することによって、コンテンツ・サーバーをビジネスや組織の機能に合わせることができます。たとえば、デフォルトの日付やタイムスタンプを変更したり、チェックイン動作の機能を変更したりできます。
環境への製品の統合
シェル・スクリプト、SOAP、J2EE、JSPおよびクラスタを使用して、コンテンツ・サーバーをサイトの現在の環境により緊密に統合できます。
カスタマイズを開始する前に、カスタマイズを行う理由を明確にすることが重要です。たとえば、企業ブランドを追加するには、「レイアウト・サンプルの変更」を使用して追加できます。また、セキュリティ機能を変更するには、デフォルトのセキュリティ設定を変更するためのコンポーネントを使用できます。
多くの場合、カスタマイズは、コンテンツ・サーバーを組織のビジネス・プラクティスに適合させるために行います。ビジネス・プロセスを評価した後、コンテンツ・サーバーをカスタマイズする前にプロシージャに軽微な変更を加えたほうが効率的だとわかることもよくあります。
カスタマイズする理由を特定します。
企業パーソナライズを行いますか。ナビゲーション・オプションや素材を表示する、より適切な方法があるかどうかを検討します。明らかになったニーズのタイプに応じて、どのツールを使用するのが最適であるかを判断できます。
多くの場合、表示に関する詳細を変更することで、ユーザーの満足度を高めることができます。レイアウト、色、イメージなどのアイテムを変更することによって、ユーザーの要望に対応できることがよくあります。
カスタマイズを慎重に計画します。
カスタマイズによってコンテンツ・サーバー環境がどのように変更されるかについて、周辺的な影響も含めて検討します。すべてのカスタマイズは、サイトの本番環境とは切り離してテスト環境で行う必要があります。
使用可能なソリューションがあるかどうかを確認します。
サポートWebサイトのサンプルに、様々なタイプのカスタマイズが用意されています。既存のコンポーネントを少し編集すると、使用できるようになる場合があります。そのままの状態で使用できるサンプルが数多く提供されています。これらは、WebCenter Contentの機能を例示、強化または拡張するコンポーネントやファイルです。
問題を評価し、その問題を解決することがどの程度必要であるかを評価します。
問題によっては、解決に要する労力が結果に見合わないほど大きい場合があります。カスタマイズでなく、ビジネス・プラクティスに軽微な変更を加えることが必要となることがあります。
個別の環境でカスタマイズを完全にテストします。
可能な場合は、エンド・ユーザーがテストに参加するように調整します。テストがリリースのすべての条件を満たすと、ユーザーに変更内容とその実装方法を通知します。
作成したカスタマイズをドキュメント化します。
すべての変更は、実際のカスタマイズ内においても(たとえば、動的サーバー・ページやコンポーネント内にコメントなどとして)、個別のREADME
ドキュメントとしても、できるかぎり完全にドキュメント化する必要があります。このドキュメントには、後になってカスタマイズに追加するために必要となる可能性のある人のために、履歴監査証跡が記載されています。
コンテンツ・サーバーでは、高度な機能を提供するために様々なテクノロジが組み合されています。コンテンツ・サーバーを変更するには、これらのテクノロジの一部またはすべてについて一定の経験およびスキルが必要です。
コンテンツ・サーバーをカスタマイズするために必要な技術的なスキルは、カスタマイズの複雑さによって異なる場合があります。たとえば、多くのカスタマイズは、HTMLおよびIdocスクリプトの知識で実行できます。
このリストでは、コンテンツ・サーバーの変更に必要となる可能性のあるテクノロジおよび経験を、重要度の高いものから順に説明します。
コンテンツ・サーバーのアーキテクチャ
システムのカスタマイズを開始する前に、コンテンツ・サーバーの動作とコンポーネントおよび動的サーバー・ページの機能を十分に理解しておく必要があります。
コンテンツ・サーバーWebページのテンプレートを変更するには、HTMLおよびCSSについて十分に理解する必要があります。テンプレートでHTMLを使用する場合、作業は複雑ではありませんが、テンプレートではHTML表を常時使用し、フォームを頻繁に使用します。std_page.idoc
ファイルとstd_css.idoc
ファイルには、デフォルトのテンプレートのルック・アンド・フィール(フォントやレイアウトなど)を制御するためのカスケード・スタイルシートが含まれています。
Idocスクリプトは、コンテンツ・サーバーのカスタム・サーバー側スクリプト言語です。ほぼすべてのコンテンツ・サーバーWebページにはIdocスクリプト・コードが含まれており、様々なページ要素を処理するためのメソッドが提供されています。
コンテンツ・サーバーのほとんどのページの内部コンテンツではJavaScriptを使用していませんが、「検索」「チェックイン」「更新」の各ページは顕著な例外です。これらのページのかわりに呼び出されるカスタマイズを作成する前に、JavaScriptについて理解しておく必要があります。また、レイアウトを変更するには、JavaScriptを理解する必要があります。レイアウトの変更は、設計およびナビゲーションにおいてJavaScriptおよびカスケーディング・スタイルシートに大きく依存します。
Structured Query Language (SQL)
コンテンツ・サーバーでは、データベースに対する問合せを実行するためにSQLを使用しています。SQLの知識があれば、標準的な問合せの理解および独自のカスタム問合せの作成に役立つ場合があります。
コンテンツ・サーバーはJavaクラスとともに実装されます。基礎となる機能を変更する前に、Javaおよびコンテンツ・サーバーのJavaクラス・ファイルについて十分に理解しておく必要があります。ただし、Javaを使用しなくても、製品を広範にカスタマイズできます。
複雑なカスタマイズまたはWebCenter Contentと他のシステムとの統合を行う場合、Visual Basic、COM、.Net、C++、VBScriptなどの他のツールの経験が役立つ場合があります。
コンテンツ・サーバーをカスタマイズする場合、次のツールが有用な場合があります。
ほとんどの製品カスタマイズは、Microsoft WordPadやviなどの通常のテキスト・エディタを使用して実行できます。
注意: グラフィカルHTMLエディタではソースのHTMLを頻繁に変更するため、Idocスクリプトのタグが、コンテンツ・サーバーで認識されなくなった文字列に変換される可能性があります。グラフィカル・エディタを使用する場合は、非グラフィカル・モードで編集してください。 |
HTMLページの操作にはグラフィカルHTMLエディタのほうを使用する場合は、非グラフィカル・モードを使用して編集します。
コンテンツ管理システムとのインタフェースで使用される可能性があるWebブラウザの複数のバージョンで、カスタマイズをテストする必要があります。Internet Explorer、FirefoxおよびChromeでは、コンテンツの表示は同じではなく、同じブラウザの異なるバージョンで異なる動作が示される場合があります。
JavaScriptデバッガによって、JavaScript開発のタスクが簡略化される場合があります。数多くのJavaScriptデバッガがインターネットからダウンロード可能です。
カスタマイズの際にJavaコードの開発が必要になる場合は、適切なJava開発環境が必要です。
WebCenter Contentをカスタマイズする前に、コンテンツ・サーバーの動作について理解しておく必要があります。
起動動作
リソースのキャッシング
ページ・アセンブリ
データベースとの対話
ローカライズされた文字列の解決
アプリケーション統合
コンテンツ・サーバーの管理の概要は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のシステム管理タスクの概要に関する項を参照してください。
起動時に、コンテンツ・サーバーのインスタンスでは内部初期化が実行され、次のアイテムがロードされます。
構成変数
標準的なテンプレート、リソースおよびレポート
カスタム・コンポーネント(テンプレート、リソース、構成変数、レポートなど)
図1-1に、起動時にコンテンツ・サーバーで実行される4つの手順を示します。これらの手順の詳細は、第1.5.1.1項「起動手順」で説明します。
起動時にコンテンツ・サーバーで実行される手順は次の4つです。
コンテンツ・サーバーで初期化が行われると、コンテンツ・サーバーのJavaクラス・ファイルが読み取られ、Java仮想マシン(JVM)が起動します。DomainHome
/ucm/
short-product-id
/intradoc.cfg
ファイル内に変数があれば、それも初期化されます。
初期化後、コンテンツ・サーバーでは、IntradocDir
/config/
ディレクトリにあるconfig.cfg
ファイルがロードされます。このファイルには、システム・プロパティと構成変数が格納されており、それらは名前と値のペア(SystemLocale=English-US
など)で定義されています。
構成ファイル内に含まれているデフォルト情報は、Oracle WebCenter Contentのインストール・プロセスで提供されたものですが、このファイルは次のような様々な方法で変更できます。
「管理」→「管理サーバー」→「一般構成」メニュー・オプションからアクセスできる、「一般構成」ページを使用する
Oracle WebCenter Contentインストール(UNIXオペレーティング・システム)のbin/
ディレクトリ内にある実行可能ファイルSystemProperties
を実行する
構成ファイルを直接編集する
カスタム・コンポーネントを使用する
config.cfg
ファイルを変更するたびに、コンテンツ・サーバーを再起動して変更内容を有効にする必要があります。
標準的なリソース、テンプレートおよびレポートをロードします。
コンテンツ・サーバーが正しく機能するようにするには、数多くの標準的なリソース、テンプレートおよびレポートをロードする必要があります。構成設定のロード後、コンテンツ・サーバーでは、IdcHomeDir
/resources/core/templates/templates.hda
ファイルおよびIdcHomeDir
/resources/core/reports/reports.hda
ファイルのエントリが読み取られます。これらのファイルからコンテンツ・サーバーに、どのテンプレートをロードすべきかが指示されます。テンプレートおよびレポートのページで標準的なリソースが参照されれば、ロードしたテンプレートによって、そのリソースがロードされます。
コンテンツ・サーバーは、IntradocDir
/data/components/idc
short_product_id
_components.hda
に一覧表示されているコンポーネントのすべてをロードし、さらに、IdcHomeDir
/components/
ComponentName
/
ComponentName
.hda
にあるシステム・コンポーネント、またはIntradocDir
/custom/
ComponentName
/
ComponentName
.hda
にあるカスタム・コンポーネントをロードします。
複数の構成ファイルのロードの順序が持つ影響を理解しておくことが重要です。それは、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
ファイルを再パブリッシュする必要があります。詳細は、第12章「コンテンツ・サーバーのコンポーネントのスタート・ガイド」を参照してください。
コンテンツ・サーバーでは、動的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
ファイルの使用については、第8章「システム設定の変更」を参照してください。
ローカライズされた文字列とは、ユーザー・インタフェースとエラー・メッセージを、ユーザーのロケールで指定された言語で表示する手段です。コンテンツ・サーバーでは、ベース言語の文字列リソース・ファイルをロードし、サポートされているあらゆる言語のリソース・ファイルもロードします。ハードコード化されたテキストを表示するかわりに、テンプレート・ページ、アプレットおよびエラー・メッセージがこれらのリソース・ファイル内の文字列IDを参照し、この文字列IDはさらに、ユーザーのロケール情報を含むExecutionContextを使用して解決されます。
コンテンツ・サーバーは、コンテンツ中心のWebサイトに向けたコンテンツ管理ソリューションの役割を果たすだけでなく、スケーラブルなコンテンツ管理インフラストラクチャも提供しており、このインフラストラクチャは、数多くの多様な環境やプラットフォームで複数のエンタープライズ・アプリケーションをサポートします。この統合ソリューションにより、他のエンタープライズ・アプリケーションは、コンテンツ管理システムで管理されているコンテンツにアクセスできます。また、これらのアプリケーションには、全文検索やメタデータ検索、ライブラリ・サービス、ワークフロー、サブスクリプション通知、幅広く品揃えされている統合メソッドを通じたコンテンツ変換機能などの重要なコンテンツ管理機能が提供されています。
コンテンツ・サーバーとエンタープライズ・アプリケーションの統合については、第25章「環境へのWebCenter Contentの統合のスタート・ガイド」を参照してください。