Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1 (11.1.1) B72427-04 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > コンテンツ・サーバーのコンポーネントのスタート・ガイド
この章では、Oracle WebCenter Content Serverのコンポーネント(コンテンツ・サーバーの機能変更に使用されるプログラム)を操作する方法について説明します。
この章の内容は次のとおりです。
コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンテンツ・サーバーのコアな標準機能を追加または変更するために、コンテンツ・サーバーには、標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントが含まれています。
カスタム・コンポーネントを定義するときには、次のファイルを作成または変更します。
idc
short-product-id
_components.hda
ファイル: どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。
コンポーネント定義(またはglue)ファイル: カスタム・コンポーネントのリソースがどこにあるかをコンテンツ・サーバーに伝えます。
異なるカスタム・リソース・ファイル: コンテンツ・サーバーの標準リソースに対するカスタマイズを定義します。
テンプレート・ファイル: カスタム・テンプレート・ページを定義します。
その他のファイル: コンテンツ・サーバーのグラフィック、Javaコード、ヘルプ・ファイルなどに対するカスタマイズが含まれています。
これらのファイルの詳細は、第12.1.3項「ディレクトリおよびファイルについて」を参照してください。
コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。
HDA
HTM
CFG
Java CLASS
コンポーネント・ウィザードでコンポーネントを構築または解凍する場合、あるいはコンポーネント・マネージャでコンポーネントをアップロードおよびダウンロードする場合は、次のファイルを使用します。
圧縮されたZIPファイル: 他のコンテンツ・サーバーのインスタンスにコンポーネントをデプロイするために使用されます。
manifest.hda
ファイル: コンポーネントZIPファイルから解凍またはアップロードされたファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。
コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンポーネント・アーキテクチャ・モデルは、オブジェクト指向のテクノロジから派生したもので、巨大ですべてを包括した(ただし扱いにくい)アプリケーションを作成するのではなく、小さなモジュールを使用して、必要に応じてコンテンツ・サーバーをカスタマイズすることを促進しています。
注意: 必要なファイルとリソースを手動で作成することによって、カスタム・コンポーネントを作成できます。ただし、コンポーネント・ウィザードは、手動の方法に比べて制限がなく、これを使用すると、よくある誤りが多く発生することはありません。 |
コンポーネントは通常、コンテンツ・サーバーのコアな機能を変更するために使用されます。たとえば、コンポーネントを使用して、次のタスクのいずれかを実行することもできます。
標準的なセキュリティ機能を変更する
検索結果が要求され、返されるやり方を変更する
(Macintoshクライアントや専用のCADプログラムなど)特定のシステムとコンテンツ・サーバーが提携できるようにする
コンテンツ・サーバーとともにコンポーネント・アーキテクチャを使用すると、次のメリットが得られます。
製品の整合性を損なわずにソース・コードを変更できます。
コンテンツ・サーバーでは、そのリソースの多くが外部のテキスト・ファイルからロードされるため、ファイルを表示してシステムの状況を分析し、そのファイルを要件に合わせてコピーおよび変更できます。
複数のプラットフォームにわたり、複数のインスタンスでカスタム・コンポーネントを使用できます。
カスタム・コンポーネントを作成してある場合は、それをZIPファイルとしてパッケージ化し、他のコンテンツ・サーバーのインスタンスにロードできます。数多くのカスタム・コンポーネントは、元の開発プラットフォーム以外のコンテンツ・サーバー・プラットフォームで機能できます。
トラブルシューティングのために、個別のコンポーネントの有効と無効を切り替えることができます。
カスタマイズをグループ化して、各コンポーネントがコンテンツ・サーバーの特定の関数または領域をカスタマイズするようにできます。障害が発生した場合は、コンポーネントを1つずつ無効にすると、トラブルを迅速に隔離できます。
コンテンツ・サーバーのインスタンスは、カスタマイズを損なわずに再インストールまたはアップグレードできます。
カスタム・コンポーネントは、既存の製品リソースを置換するのではなく、無効にします。コンテンツ・サーバーの標準ファイルを置換しても、カスタマイズに影響が発生しない場合もあります。
カスタム・コンポーネントを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。
カスタム・コンポーネントによって、システム全体の動作とルック・アンド・フィールが変更されます。変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。
カスタム・コンポーネントは、コンテンツ・サーバーのコアな機能に対する変更の影響を受ける場合があります。新機能によってコンポーネントの動作が変わる場合があるので、コンテンツ・サーバーの将来のリリースでカスタマイズが機能するという保証はありません。アップグレードするたびに、カスタム・コンポーネントを調べてテストする必要があります。
単純なカスタマイズでは、コンポーネントが不要な場合もあります。単純なコンポーネントの数が多いと、管理が難しくなる可能性があります。
コンポーネントをインストールして、コンテンツ・サーバーによる使用を有効にする必要があります。コンテンツ・サーバーに付属しているコンポーネントは自動的にインストールされ、デフォルトで有効か無効になります。カスタム・コンポーネントをインストールして、使用可能にする必要があります。コンポーネントの操作に際しては、次のいくつかのツールが利用可能です。
コンポーネント・ウィザードを使用すると、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、コンポーネントの新規作成や既存のコンポーネントの変更を行う場合、およびコンポーネントをパッケージ化して他のコンテンツ・サーバーのインスタンスで使用できるようにする場合に使用できます。詳細は、第12.2.1項「コンポーネント・ウィザード」を参照してください。
拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、新規コンポーネントを追加したり、コンポーネントをコンテンツ・サーバーで有効または無効にできます。詳細は、第12.2.2項「拡張コンポーネント・マネージャ」を参照してください。
ComponentToolは、コンテンツ・サーバーに、コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ユーティリティです。
コンポーネントのアーキテクチャおよび作成の詳細は、第12章「コンテンツ・サーバーのコンポーネントのスタート・ガイド」を参照してください。
HDAファイル
カスタム・リソース・ファイル
manifestファイル
その他のファイル(サイト用にカスタマイズされたファイル、コンポーネントZIPファイル、カスタム・インストール・パラメータ・ファイルなど)
WebCenter Contentの標準的なディレクトリ構造では、コンポーネントのファイルは、DomainHome
/ucm/
short-product-id
/custom
ディレクトリのcomponent
ディレクトリに格納されています。
コンテンツ・サーバーでは、変数値や参照キーなどのデータをキャッシュするために、データ・バインダを使用します。
HyperData (HDA)ファイルは、構造化された単純なASCIIファイル形式で、プロパティおよび表データを定義するために使用されます。これは、どのコンポーネントが有効および無効になっているか、またそのコンポーネントの定義ファイルがどこにあるかを判別するために、コンテンツ・サーバーによって使用されるテキスト・ファイルです。
HDAファイル形式が役立つのは、頻繁に変わるデータです。それは、サイズがコンパクトで形式が単純であれば、コンテンツ・サーバーでデータ通信が、より高速かつ簡単になるからです。
HDAファイル・タイプは、次のコンポーネント・ファイルの定義に使用されます。
コンポーネント・ファイル(idc
short-product-id
_components.hda
)
コンポーネント定義ファイル
manifestファイル
動的表リソース・ファイル
テンプレート・リソース・ファイル
例12-1は、customhelp
というコンポーネントを指すidccs_components.hda
ファイルを示しています。
例12-1 コンポーネントのidccs_components.hdaファイル
<?hda charset=Cp1252 encoding=iso-8859-1?> @Properties LocalData blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM @end @ResultSet Components 2 name location customhelp custom/customhelp/customhelp.hda @end
それぞれのHDAファイルには、ヘッダー行と、1つ以上のセクションが含まれます。ヘッダー行では、コンテンツ・サーバーのバージョン、文字セット、およびHDAファイルのJavaエンコーディングが特定されます。HDAファイルにダブルバイト(アジア言語)の文字が含まれている場合は、正しい文字セットとエンコーディングを指定して、コンテンツ・サーバーがファイルを適切に読み取れるようにする必要があります。ヘッダー行はシングルバイト文字には不要ですが、HDAファイルに含めておくことをお薦めします。
Properties
とResultSet
という2種類のセクションは、コンポーネント開発に該当します。これらのセクションは、ファイルのプロパティ(名前や場所など)や、データの表または列および行を定義するResultSetを定義する場合に使用されます。ResultSetは、問合せの結果を表すことがよくあります。それ以外のセクションのタグはすべて、内部アプリケーションでの使用に目的が限定されています。
HDAファイル内のセクションではコメントは使用できません。ただし、HDAファイルの最初のセクションの前、セクションの間、または最後のセクションの後であればコメントを挿入できます。HDAファイルのセクション内の空白行はNULL値として解釈されます。最初のセクション、セクション間または最後のセクションの後の空白行は無視されます。HDAファイルには、必須のセクション・タイプがないため、未使用のセクションは削除できます。
Properties
セクションには、名前と値のペアのグループが含まれます。カスタム・コンポーネントの場合、Properties
セクションで最も一般的な名前はLocalData
であり、これは、名前と値のペアが、現在のHDAファイルに対してのみ有効という意味です。
Environment
というProperties
セクションで、名前と値のグローバルなペアを定義することもできますが、このセクションが使用されることはめったにありません。config.cfg
などの構成ファイルで、グローバルな環境変数を定義することをお薦めします。
例12-2は、HDAファイルのProperties
セクションを示しています。
例12-2 HDAファイルのPropertiesセクション
@Properties LocalData PageLastChanged=952094472723 LocationInfo=Directory,Public, IsJava=1 refreshSubMonikers= PageUrl=/intradoc/groups/public/pages/index.htm LastChanged=-1 TemplatePage=DIRECTORY_PAGE IdcService=PAGE_HANDLER LinkSelectedIndex=0 PageName=index HeaderText=This is a sample page. The Page Name must remain index. The Page Properties for this index page should be customized. PageFunction=SavePage dSecurityGroup=Public restrictByGroup=1 PageType=Directory PageTitle=Content Server Index Page @end
HDAファイルの各ResultSet
セクションでは、データの表または列および行を定義します。ResultSetは、データベースに情報を渡すか、またはデータベース問合せの結果を表すために使用できます。ResultSet
セクションの構造を次に示します。
最初の行では、@ResultSet
resultset_nameという形式を使用して、ResultSet表の名前を定義します。
2番目の行では、列の数を定義します。
次のn行では、列名を定義します。
残りの行では、表の各セルの値を定義します。
セクションの最後の行は、@end
という形式を使用して、この表を終了しています。
例12-3は、列が4つ、行が3つあるScores
というResultSetを示しています。
例12-3 HDAファイルのResultSetセクション
@ResultSet Scores
4
name
match1
match2
match3Margaret
68
67
72 Sylvia 70 66 70 Barb 72 71 69@end
次の表は、ResultSetデータを列形式で示しています。ResultSetには、どのような名前でも指定できます。
name | match1 | match2 | match3 |
---|---|---|---|
Margaret |
68 |
67 |
72 |
Sylvia |
70 |
66 |
70 |
Barb |
72 |
71 |
69 |
コンテンツ・サーバーでは、事前定義されたResultSetをいくつか、次の名前で使用します。それらの名前は、カスタム・コンポーネントの表には使用しないでください。
ResultSet名 | 場所 | 目的 |
---|---|---|
|
作成した任意のカスタム・コンポーネントの名前と場所を定義します。 |
|
|
コンテンツ・サーバーのデフォルトのレポート・テンプレートを指定します。 |
|
|
コンテンツ・サーバーのデフォルトのテンプレートをすべて指定します(検索結果テンプレートとレポート・テンプレートは除く)。 |
|
|
カスタム・コンポーネントのリソースを定義します。 |
|
|
コンテンツ・サーバーのデフォルトの検索結果テンプレートを指定します。 |
idc
short-product-id
_components.hda
ファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えるテキスト・ファイルです。
idc
short-product-id
_components.hda
ファイルは常に、IntradocDir
/data/components
ディレクトリに格納されています。必要に応じてこのファイルを変更するために、コンポーネント・ウィザード、コンポーネント・マネージャおよびComponentToolを使用できます。
注意: リリース11gR1では、 |
例12-4は、スキーマ・コンポーネント、構成の移行コンポーネント、SOAPコンポーネントなど、いくつかの有効なコンポーネントをリストしたidccs_components.hda
ファイルを示しています。
コンポーネント定義ファイルは、定義したカスタム・リソースを指します。このファイルでは、カスタム・リソース、ResultSetおよびマージ・ルールに関する情報を指定します。このコンポーネント定義ファイルは、コンポーネントをまとめる「glue(接着剤)」の役割を果たすので、glueファイルと呼ばれることもあります。
コンポーネントの定義ファイルは通常、component_name
.hda
という名前であり、DomainHome
/ucm/
short-product-id
/custom/
component_name
/
ディレクトリに置かれています。
注意:
|
カスタム・リソース・ファイルでは、コンテンツ・サーバーのカスタマイズを定義します。通常はHDAファイルですが、HTMファイルの場合もあります。
コンポーネントのカスタム・リソース・ファイルは通常、DomainHome
/ucm/
short-product-id
/custom/
component_name
/
ディレクトリに置かれています。リソース・ファイルの中には、resources/core/templates/
のようなサブディレクトリに置かれるものもあります。
これらのリソースを表12-1に示します。
表12-1 カスタム・リソース・ファイル
リソース・タイプ | ファイル・タイプ | 目次 |
---|---|---|
HTMLインクルード |
HTM |
インクルードの定義 |
文字列 |
HTM |
ローカライズされた文字列の定義 |
動的表 |
HDA |
頻繁に変化するデータの表 |
静的表 |
HTM |
めったに変化しないデータの表 |
問合せ |
HTM |
問合せを定義する表 |
サービス |
HTM |
サービス・スクリプトを定義する表 |
テンプレート |
HDA |
テンプレート・ページの場所とファイル名を定義する表 |
環境 |
CFG |
構成変数の名前と値のペア |
これらのファイルの詳細は、第12.4項「Webページをアセンブルするためのリソース」を参照してください。
また、Webページをアセンブルするために、コンテンツ・サーバーによってtemplate.htm
ページが使用されます。template.hdm
ファイルの詳細は、第18.2.8項「テンプレート」を参照してください。
ResultSet HTM表ファイルが、その他のリソースによって使用されます。HTMファイルのResultSet表は、データのレイアウトにHTML表のタグを使用することを除き、HDAファイルのResultSetに似ています。静的表リソース、サービス・リソースおよび問合せリソースはすべて、この表形式を使用しています。
HTMファイルのResultSet表は、先頭が<@table
table_name
@>
で末尾が<@end@>
です。開始タグと終了タグの間にあるマークアップがHTML表です。HDAファイル内のResultSetとは異なり、表のタグによって列の数が暗示されています。
データ構造を定義していないHTML構文があれば、表のロード時に無視されます。そのため、HTMファイルの表の中ではHTMLコメントが許可されており、Webブラウザでのデータの表示を向上させるために、HTMLのstyle属性を使用できます。
コンテンツ・サーバーでは、(変数の値や参照キーなどの)データが、データ・バインダに内部でキャッシュされます。データ・バインダ内のデータはすべて、どこから来たか、またどのように作成されたかに従って分類されます。サービス・リクエストを満たすために値が必要な場合は、データ・バインダ内のデータが、次に示すデフォルトの順序で評価されます。
この優先順位は、Idocスクリプトの関数を使用して変更できます。詳細は、付録A「Idoc Scriptの関数と変数」を参照してください。
HDAファイル内の@Properties LocalData
セクションは、データ・バインダのLocalData
カテゴリにマップされます。LocalData
情報は、名前と値のペアで構成されています。
LocalData
情報が保持されるのは、コンテンツ・サーバーのリクエストとレスポンスが有効になっている期間のみです。めったに変化しないサーバー環境に関する情報と異なり、各リクエストのLocalData
情報は動的です。
HTTPリクエストの観点で見ると、LocalData
の初期情報は、REQUEST_METHOD
、CONTENT_LENGTH
、QUERY_STRING
の各HTTP環境変数から収集されます。サービス・リクエストを処理するときに、LocalData
の名前と値のペアを追加または変更できます。
HDAファイルの各@ResultSet
セクションは、DataBinder
オブジェクトにおける名前付き結果にマップされます。いくつかのResultSetがアクティブになって、値検索時に他のResultSetより優先される場合があります。ResultSetは、ページのアセンブリ中にループされたときにアクティブになります。アクティブなResultSetは、DataBinder
オブジェクトの値検索時に、他のいずれのResultSetより優先されます。サービス・リクエストにデータが必要で、LocalDataにもアクティブなResultSetにも値が見つからなかった場合は、(アクティブでない)残りのResultSetが次に検索されます。
manifestファイルは、コンテンツ・サーバーにコンポーネントZIPファイルをアップロードまたは展開するために使用されます。このファイルは、コンポーネントZIPファイルに含まれている個別のファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。manifestファイルは、コンポーネント・ウィザードでコンポーネントを構築したときや、拡張コンポーネント・マネージャを使用してコンポーネントをダウンロードしたときに、自動的に作成されます。
manifestファイルはすべて、manifest.hda
と呼ぶ必要があります。manifest.hda
ファイルは、他のコンポーネント・ファイルとともに、コンポーネントZIPファイルに含まれています。これは、ZIPファイル・ディレクトリ構造の最上位のレベルにある必要があります。
manifest.hda
ファイルには、Manifest
というResultSet
表が含まれており、この表は次の2つの列で構成されています。
entryType
列では、manifestファイルのエントリのタイプを定義しています。
エントリ・タイプ | 説明 | デフォルト・パス |
---|---|---|
|
Javaクラス・ファイル |
|
|
共通ファイル |
|
|
コンポーネント・リソース・ファイル |
|
|
関連付けられているファイル(readmeなど) |
|
|
オンライン・ヘルプ・ファイル |
|
|
グラフィック・ファイル |
|
|
JavaServerページ |
|
注意: エントリ・タイプ |
location
列では、エントリに関連付けられているファイルがインストールされているディレクトリを定義し、一部のエントリ・タイプのファイル名を指定しています。
Component
エントリ・タイプの場合、場所は定義ファイルのパスとファイル名です。次に定義ファイルは、どのリソース・ファイルがコンポーネントに含まれるかを、コンテンツ・サーバーに伝えます。
その他のエントリ・タイプの場合、場所は、ファイル名なしのパス(特定のサブディレクトリ内のファイルをすべて指定するとき)、またはファイル名付きのパス(個別のファイルを指定するとき)になります。
場所は、DomainHome
/ucm/
short-product-id
/custom
ディレクトリからの相対パスを指定する必要があります。絶対パスを使用することもできますが、その場合は、コンポーネントをインストールできる場所が、インストール・ディレクトリのパスが同じコンテンツ・サーバーのインスタンスのみとなります。
例12-5は、manifest.hda
ファイルを示しています。
カスタム・コンポーネントには、機能のために、またはそのルック・アンド・フィールを生成するために、コンテンツ・サーバーが使用する任意のタイプのファイルを含めることができます。
自社サイト用にカスタマイズされたファイルを追加して、コンテンツ・サーバーの外観またはアクションを変更できます。たとえば、カスタム・リソースでは、次のタイプのファイルが頻繁に参照されます。
Graphics
標準的なコンテンツ・サーバー・インタフェースを構成するアイコン、背景およびロゴを置換します。
Help
コンサルティング・サービスの助けがあれば、コンテンツ管理システム用にヘルプ・ファイルをカスタマイズできます。
Classes
Javaコードでは、コンテンツ・サーバーの機能を変更または拡張できます。Javaクラス・ファイルは、DomainHome
/ucm/
short-product-id
/classes/
ディレクトリに配置するために、ディレクトリにパッケージ化する必要があります。
注意: グラフィック・ファイルとヘルプ・ファイルは、 |
コンポーネントZIPファイルには、コンテンツ・サーバーのコンポーネントを定義するファイルがすべて含まれます。これを解凍すると、他のコンテンツ・サーバーのインスタンスにコンポーネントをデプロイできます。
カスタム・インストール・パラメータを1つ以上定義すると、コンポーネント・ファイルの基本構造を構成するファイル以外に、追加のファイルがいくつか作成されます。
コンポーネントのインストール・パラメータが作成された場合は、コンポーネントのインストール・プロセス中に、コンポーネント・インストーラによって、data/components/
ディレクトリ内のコンポーネントのディレクトリに、2つのファイルが自動的に配置されます。これらのファイルには、次のようなプリファレンス・データが保持されています。
config.cfg
ファイル: インストール後に認識可能となるパラメータが含まれます。
install.cfg
ファイル: プリファレンス・データ定義とプロンプトへの応答が含まれます。
バックアップZIPファイル: コンポーネントが現在インストールされているか、または再インストール中の場合に作成されるバックアップ・ファイル。
コンポーネント・ウィザードを使用してカスタム・コンポーネントを作成した場合は、適切なディレクトリにファイルが格納されます。
カスタム・コンポーネントごとに異なるコンポーネント・ディレクトリが、DomainHome
/ucm/
short-product-id
/custom/
ディレクトリに確立されます。各コンポーネント・ディレクトリ内に、レポート、テンプレートおよびリソースに個別のサブディレクトリが確立され、それぞれに適切な名前が付けられます(たとえば、component_name
/resources/
)。component_name
.hda
ファイル(定義ファイル)は、component_name
ディレクトリに格納されます。
次の各項では、カスタム・コンポーネントの開発を支援するためのガイドラインをいくつか提供します。
コンポーネントの作成または変更の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』、またはオンライン・ヘルプを参照してください。
コンテンツ・サーバーの機能のうち、既存のコンポーネントでは提供されていないものが、自社のサイトで必要になった場合、コンテンツ・サーバーのインスタンスにカスタム・コンポーネントを作成できます。
定義ファイルにカスタム・コンポーネントを作成し、そのコンポーネントを有効にしてコンテンツ・サーバーに適用できます。
カスタム・コンポーネントを作成して有効にする手順は次のとおりです。
定義ファイルを作成します。
定義ファイルへの参照をidc
short-product-id
_components.hda
ファイルに加えて、このコンポーネントを有効にします。
コンテンツ・サーバーを再起動して、このコンポーネントを適用します。
リソースなどのファイルを作成して、カスタマイズを定義します。カスタム・リソース・ファイルを作成するには、コンテンツ・サーバーの標準ファイルをコピー、名前変更および変更することをお薦めします。
必要に応じて、カスタマイズをテストして改定します。変更内容を適用するには、コンテンツ・サーバーの再起動が必要になる場合もあります。
後で使用したり他のコンテンツ・サーバーのインスタンスにデプロイできるように、コンポーネントをパッケージ化する場合は、コンポーネントを構築してコンポーネントZIPファイルを作成します。
コンポーネント・ファイルの操作に際しては、次のツールが利用可能です。
コンポーネント・ウィザードは、コンテンツ・サーバーのユーティリティの1つで、コンポーネント・ファイルの作成と編集に役立ちます。コンポーネント・ウィザードは、コンポーネントのパッケージ化、解凍、有効化および無効化にも使用できます。このユーティリティの使用に関する詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
ほとんどのコンポーネント・ファイルはプレーン・テキスト・ファイルなので、ファイルの作成と編集はお好みのテキスト・エディタでできます。
カスタム・コンポーネントを操作するときは、できるだけコンポーネント・ウィザードを使用してください。
コンポーネント・ウィザードはいくつものタスクをユーザーにかわって行うので、テキスト・エディタでユーザーが行う必要のある作業が最小限に抑えられます。コンポーネント・ウィザードを使用すると、推奨されるファイル構造と命名規則を遵守しやすくなります。コンポーネント・ウィザードでは、コンポーネントの構築時にreadmeテキスト・ファイルが自動的に追加され、カスタマイズをドキュメントに残す作業がやりやすくなります。コンポーネント・ファイルにはコメントも含める必要があります。
コンポーネント・ウィザードの使用に関する詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
コンテンツ・サーバーをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。本番コンテンツ・サーバーに定義したのと同じカスタム・メタデータ・フィールドを、本番コンテンツ・サーバーに忘れずに含めてください。
開発コンテンツ・サーバーで変更のテストが成功したら、コンポーネント・ウィザードを使用してコンポーネントZIPファイルを構築し、本番システムでコンポーネントを解凍します。
コンポーネントを有効または無効にした後で、コンテンツ・サーバーを忘れずに再起動してください。
カスタム・コンポーネントのインストール後にコンテンツ・サーバーに問題が発生した場合は、そのコンポーネントを無効にしてコンテンツ・サーバーを再起動します。これで問題が解決した場合はおそらく、コンポーネントのトラブルシューティングが必要になります。問題が解決しない場合は、コンポーネント・ウィザードを使用してコンポーネントを完全に除去して、問題がコンポーネントにあるのかコンテンツ・サーバーにあるのかを判別することが必要になると考えられます。
カスタム・コンポーネントを整理するには、次のファイル構造ガイドラインを遵守します。詳細は、第12.1.3.6項「一般的なディレクトリ構造」を参照してください。
注意: コンポーネント・ウィザードを使用した場合は、コンポーネント・ディレクトリが作成され、適切なディレクトリにコンポーネント・ファイルが配置されます。 |
それぞれのカスタム・コンポーネントは、DomainHome
/ucm/
short-product-id
/custom/
というディレクトリ内の専用のディレクトリに置いてください。リソース・タイプまたはテンプレート・タイプ、あるいはその両方のリソースがカスタム・コンポーネントに含まれている場合、component
ディレクトリには、IdcHomeDir
/data/resources/core/
ディレクトリの構造を遵守したサブディレクトリが必要です。
resources/
: HTMLインクルードと表リソース・ファイルを保持
resources/lang/
: 文字列リソース・ファイルを保持
templates/
: テンプレート・ファイルを保持
reports/
: レポート・ファイルを保持
ファイルとその編成を検討する際には、次の点を頭に入れてください。
各カスタム・コンポーネントの定義ファイルは、コンポーネントのディレクトリの最上位レベルに配置します。
コンポーネント内の他のファイルを参照するときには、絶対パス名ではなく相対パス名を使用します。相対パス名を使用すると、コンポーネント内のファイルのすべてを編集する必要なしに、コンポーネントを別の場所に移動できます。
コンテンツ・サーバーはJavaベースのアプリケーションなので、すべてのパス名にスラッシュを使用する必要があります。
カスタム・コンポーネントをコンテンツ・サーバーと同じコンピュータに格納する必要はありませんが、すべてのコンポーネント・ファイルは、コンテンツ・サーバーのインスタンスからアクセス可能である必要があります。
コンテンツ・サーバーのWebページによって参照されるイメージとその他のオブジェクトは、DomainHome
/ucm/
short-product-id
/weblayout/
ディレクトリ内に常駐している必要があります(Webサーバーからこれらのオブジェクトにアクセスできるようにするためです)。
コンポーネント・ファイルを整理して、コンテンツ・サーバーでファイルが適切に動作するようにするには、ディレクトリ、個別ファイルおよびファイルの内容に対して、次の命名規則を遵守します。
コンポーネント・ディレクトリおよびコンポーネント・ファイルのすべてに対して、一意で意味のある名前を指定する必要があります。各コンポーネントがコンテンツ・サーバーにロードされたときに、同じファイル名を持つリソースがあればオーバーライドされるため、重複するファイル名は、特定のコンポーネントを優先させたい場合に限り使用すべきであることを頭に入れてください。
コンテンツ・サーバーの標準ファイルをコピーする場合、元のファイル名の前に接頭辞としてcustom_
を配置することが一般的な手法です。これにより、デフォルトのテンプレートが上書きされることはいっさいなく、カスタマイズは容易に特定できます。
HTMファイル・タイプの拡張子は.htm
、HDAファイル・タイプの拡張子は.hda
とします。
ワードパッドのようなテキスト・エディタでコンポーネント・ファイルを新規作成した場合には、引用符の内側のファイル名を「保存」ダイアログ・ボックスに配置して、適切なファイル拡張子が割り当てられるようにします(たとえば、myfile.hda
)。ファイル名を定義する際に引用符の使用に失敗すると、ファイル名がmyfile.hda.txt
のようになる場合があります。
大文字と小文字は、ファイル・システムで区別されていなくても、コンテンツ・サーバーでは区別されます。たとえば、ファイル名がMy_Template
の場合、コンテンツ・サーバーでは、my_template
やMY_TEMPLATE
のような、大文字と小文字のバリエーションは認識されません。
ローカライズされた文字列リソースの場合は、コンテンツ・サーバーで文字列が認識されるようにするために、ファイルの標準命名規則を遵守する必要があります。カスタム文字列の名前を付けるときには、標準的な2文字接頭辞(cs、sy、apまたはww)も使用する必要があります。詳細は、第1.5.5項「ローカライズされた文字列の解決」を参照してください。
コンポーネントの管理に使用できるツールは次のとおりです。
コンポーネント・ウィザード
コンポーネント・マネージャ
拡張コンポーネント・マネージャ
ComponentTool
コンポーネント・ウィザード・ユーティリティでは、カスタム・コンポーネントに必要なすべてのファイルの作成や編集など、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、既存のコンポーネントを変更する場合や、コンテンツ・サーバーで使用できるようにコンポーネントのパッケージ化と解凍を行う場合にも使用できます。
図12-1は、コンポーネント・ウィザードへのインタフェースを示しています。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のコンポーネント・ウィザードを使用したコンポーネントの作成に関する項を参照してください。
コンポーネント・ウィザードにアクセスする手順は次のとおりです。
UNIXオペレーティング・システム: DomainHome
/ucm/
short-product-id
/bin/
に格納されているComponentWizardを実行します。
コンポーネント・ウィザードのメイン・ページが表示されます。
Windowsオペレーティング・システム: 「スタート」メニューからインスタンス名を選択し、「ユーティリティ」、「コンポーネント・ウィザード」の順に選択します。
コンポーネント・ウィザードのメイン・ページが表示されます。
拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、コンポーネントを有効または無効にしたり、コンテンツ・サーバーに新規コンポーネントを追加することが簡単にできます。
拡張コンポーネント・マネージャを使用する手順は次のとおりです。
「管理」トレイまたはメニューから、「管理サーバー」→「コンポーネント・マネージャ」を選択します。
「コンポーネント・マネージャ」ページが表示されます。
「コンポーネント・マネージャ」ページの最初の段落で、「拡張コンポーネント・マネージャ」をクリックします。
「拡張コンポーネント・マネージャ」ページが開きます。図12-2はこのページを示しており、有効なコンポーネントと無効なコンポーネントのリストがあります。
「拡張コンポーネント・マネージャ」ページで、次のタスクを実行できます。
カテゴリなどのフィルタ別に、有効なコンポーネントと無効なコンポーネントのリストを表示する
選択したコンポーネントに関する詳細の表示
コンポーネントを有効化する
コンポーネントを無効化する
カスタム・コンポーネントをインストールする
カスタム・コンポーネントをアンインストールする
詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のコンポーネントの管理に関する項を参照してください。
idc
short-product-id
_components.hda
ファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義(glue)ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。11gリリース1 (11.1.1)では、このファイルには3つのフォームがあり、idccs_components.hda
(Content Server用)、idcibr_components.hda
(Inbound Refinery用)、idcurm_components.hda
(Records用)というように、WebCenter Contentアプリケーションのそれぞれに1つずつです。このファイルは常に、IntradocDir
/data/components/
ディレクトリに格納されています。
これらのファイルは、手動で作成しないでください。コンポーネント・ファイルの作成には、必ずコンポーネント・ウィザードを使用します。
idc
short-product-id
_components.hda
ファイルには常に、各定義ファイルの名前とファイル・パスを定義するComponents
というResultSetが含まれます。コンポーネントのHDAファイルを変更するには、コンポーネント・ウィザードまたはコンポーネント・マネージャを使用できます。詳細は、第13章「コンテンツ・サーバーのコンポーネントの有効化と無効化」を参照してください。
例12-6は、コンテンツ・サーバーで有効にされている2つのコンポーネント、MyComponent
とCustomHelp
を指定しているidccs_components.hda
ファイルを示しています。
例12-6 idccs_components.hdaファイル
<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?> @Properties LocalData blDateFormat=M/d{/yy} {h:mm[:ss] {aa}[zzz]}!tAmerica/Chicago!mAM,PM blFieldTypes= @end @ResultSet Components 2 name location MyComponent custom/MultiCheckin/my_component.hda CustomHelp custom/customhelp/customhelp.hda @end
Components
ResultSetにコンポーネントがリストされている順序によって、コンテンツ・サーバーの起動時にコンポーネントがロードされる順序が決まります。ResultSetで後にリストされたコンポーネントに、それより前にリストされたコンポーネントと同じ名前のリソースがある場合は、後のコンポーネントのリソースが優先されます。
Components
ResultSetには、次の2つの列があります。
name
列には、各コンポーネントの内容を記述した名前が提供されており、この名前は、コンポーネント・ウィザード、コンポーネント・マネージャおよびコンテンツ・サーバーのエラー・メッセージに使用されます。
location
列では、各コンポーネントの定義ファイルの場所を定義しています。この場所は、絶対パス、またはコンテンツ・サーバーのインストール・ディレクトリを基準とした相対パスで指定できます。
注意:
|
コンポーネント定義ファイル、すなわちglueファイルは、定義したカスタム・リソースを指します。コンポーネントの定義ファイルはcomponent_name
.hda
という名前であり、通常はDomainHome
/ucm/
short-product-id
/custom/
component_name
ディレクトリの中にあります。定義ファイルの作成と変更には、コンポーネント・ウィザードを使用できます。
定義ファイルにはResourceDefinition ResultSetが含まれており、MergeRules ResultSet、Filters ResultSet、ClassAliases ResultSet、またはこれらのResultSetの任意の組合せが含まれる場合もあります。例12-7は、一般的なコンポーネント定義ファイルを示しています。
例12-7 コンポーネント定義ファイル
<?hda jcharset=UTF8 encoding=utf-8?> @Properties LocalData classpath=$COMPONENT_DIR/classes.jar ComponentName=Custom DCL Component serverVersion=7.3 version=2010_10_22 @end @ResultSet ResourceDefinition 4 type filename tables loadOrder template dcl_templates.hda DCLCustomTemplates 1 resource dcl_resource.htm null 1 resource dcl_upper_clmns_map.htm DCLColumnTranslationTable 1 resource dcl_data_sources.htm dclDataSources 1 service dcl_services.htm CustomServices 1 query dcl_query.htm CustomQueryTable 1 resource dcl_checkin_tables.hda null 1 @end @ResultSet MergeRules 3 fromTable toTable column DCLCustomTemplates IntradocTemplates name DCLColumnTranslationTable ColumnTranslation alias DCLDataSources DataSources name CustomDCLServiceQueries ListBoxServiceQueries dataSource @end @ResultSet Filters 4 type location parameter loadOrder loadMetaOptionsLists intradoc.server.ExecuteSubServiceFilter GET_CHOICE_LIST_SUB 1 @end
ResourceDefinition
ResultSet表では、タイプ、ファイル名、表の名前、およびカスタム・リソースのロード順序が定義されます。例12-8に、ResourceDefinition
ResultSetの構造を示します。
例12-8 ResourceDefinition ResultSet
@ResultSet ResourceDefinition 4 type filename tables loadOrder template dcl_templates.hda DCLCustomTemplates 1 resource dcl_resource.htm null 1 resource dcl_upper_clmns_map.htm DCLColumnTranslationTable 1 resource dcl_data_sources.htm dclDataSources 1 service dcl_services.htm CustomServices 1 query dcl_query.htm CustomQueryTable 1 resource dcl_checkin_tables.hda null 1 @end
ResourceDefinition
ResultSetは、次の4つの列で構成されています。
type
列ではリソース・タイプを定義しており、その値は次のいずれかである必要があります。
resource
: HTMLインクルード(HTM)、文字列(HTM)、動的表(HDA)または静的表(HTM)のリソース・ファイルを指します。
environment
: 環境のリソース(CFG)ファイルを指します。
template
: テンプレートのリソース(HDA)ファイルを指します。
query
: 問合せのリソース(HTM)ファイルを指します。
service
: サービスのリソース(HTM)ファイルを指します。
filename
列では、カスタム・リソース・ファイルのパスとファイル名を定義しています。これには、絶対パスと相対パスのどちらを指定してもかまいません。相対パスは、DomainHome
/ucm/
short-product-id
/custom/
component_name/
ディレクトリを基準にしています。
tables
列では、リソース・ファイルからロードするResultSet表を定義しています。ResultSet名はカンマで区切られています。リソース・ファイルにResultSetが含まれていない場合は、この値はNULLになります。たとえば、HTMLインクルード・リソースには表定義が含まれていないため、HTMLインクルード・ファイルでは、tables
列の値は常にNULLとなります。
loadOrder
列では、リソースがロードされる順序を定義しています。リソースは、loadOrderが1のリソースを最初に、昇順でロードされます。loadOrder
の同じリソースが複数ある場合、リソースは、ResourceDefinition ResultSetにリストされている順にロードされます。名前の同じリソースが複数ある場合、最後にロードされるリソースは、システムによって使用されるリソースです。通常の場合、あるリソースを常に他のリソースの後にロードする特別な理由がある場合を除き、loadOrder
は1に設定してください。
MergeRules
ResultSet表では、カスタム・コンポーネントで定義されている新規の表を特定し、既存の表のうち、新規のデータがいずれの表にロードされるかを指定します。MergeRulesは、カスタム・テンプレートのリソースでは必須ですが、カスタムの動的表および静的表のリソースではオプションです。MergeRulesは、サービス、問合せ、HTMLインクルード、文字列、環境の各リソースでは、必須ではありません。
例12-9に、MergeRules
ResultSetを示します。
例12-9 MergeRules ResultSet
@ResultSet MergeRules 4 fromTable toTable column loadOrder DCLCustomTemplates IntradocTemplates name 1 DCLColumnTranslationTable ColumnTranslation alias 1 DCLDataSources DataSources name 1 CustomDCLServiceQueries ListBoxServiceQueries dataSource 1 @end
MergeRules
ResultSetは、次の3つの列で構成されています。
fromTable
列では、カスタム・リソースによってロードされ、既存のデータとマージされる新規データを含む表を指定します。マージを適切に実行するには、toTable
表と同じ数の列および同じ列名が、fromTable
表にある必要があります。
toTable
列では、新規データのマージ先となる既存の表の名前を指定します。通常、toTable
の値は、IntradocTemplates
やQueryTable
など、コンテンツ・サーバーの標準的な表のいずれかです。
column
列では、データの比較と更新にコンテンツ・サーバーが使用する表の列の名前を指定します。
コンテンツ・サーバーでは、fromTable
とtoTable
のcolumn
の値を比較します。toTable
の現在値と同一のfromTable
の値ごとに、toTable
の行がfromTable
の行に置換されます。toTable
の現在値と同一でないfromTable
の値ごとに、toTable
に新規の行が追加され、fromTable
の行のデータが移入されます。
column
の値は通常、name
です。この値をNULLに設定すると、デフォルトに設定されるのは最初の列であり、それは一般的にname
列です。
Filters
ResultSet表では、新規コンテンツがチェックインされたりサーバーが最初に起動するなど、コンテンツ・サーバーの特定のイベントがトリガーされたときにカスタムJavaコードの実行に使用されるフィルタを定義します。例12-10は、標準的なFilters
ResultSetを示しています。
ClassAliases
ResultSet表は、コンテンツ・サーバーのJavaクラス全体の機能を拡張するために使用されるカスタムJavaクラス・ファイルを指します。例12-11は、標準的なClassAliases
ResultSetを示しています。
リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。リソースには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。
コンポーネントのカスタム・リソース・ファイルは通常、DomainHome
/ucm/
short-product-id
/custom/
component_name
ディレクトリの中にあります。コンポーネントに含まれるリソースが多い場合は、コンポーネント・ディレクトリ内のサブディレクトリ(component_name
/resources
やcomponent_name
/templates
など)にファイルを配置すると、維持がしやすくなります。
リソースの作成には、必ずコンポーネント・ウィザードを使用します。リソース・ファイルは手動で作成しないでください。リソース・ファイルの作成後に編集するやり方には、次の2つがあります。
リソース・ファイルは、コンポーネント・ウィザードを使用して追加、編集、またはコンポーネントから削除できます。コンポーネント・ウィザードでは、事前定義されたリソースに対して、カスタム・リソースを作成するときの開始ポイントとして使用できるコードが用意されています。リソース・ファイルは、コンポーネント・ウィザード内からテキスト・エディタで開くこともできます。
テキスト・エディタでの手動編集
リソース・ファイルは、コンポーネント・ウィザードで作成した後に、必要に応じて、テキスト・エディタで開いてコードを手動で編集できます。
詳細は、第18.2項「コンポーネントのリソースの作成」を参照してください。
注意: リソース・ファイルを変更したら、コンテンツ・サーバーを再起動する必要があります。 |