| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
 前へ |
 次 |
ホーム > Content Server開発者ガイド > コンテンツ・サーバーのコンポーネントの開始
| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
前へ |
次 |
ホーム > Content Server開発者ガイド > コンテンツ・サーバーのコンポーネントの開始
この章では、Oracle WebCenter Content Serverのコンポーネント(コンテンツ・サーバーの機能変更に使用されるプログラム)を操作する方法について説明します。
この章では、次の項目について説明します。
コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンテンツ・サーバーのコアな標準機能を追加または変更するために、コンテンツ・サーバーには、標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントが含まれています。
カスタム・コンポーネントを定義するときには、次のファイルを作成または変更します。
idcshort-product-id_components.hdaファイル: どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。
コンポーネント定義(またはglue)ファイル: カスタム・コンポーネントのリソースがどこにあるかをコンテンツ・サーバーに伝えます。
異なるカスタム・リソース・ファイル: コンテンツ・サーバーの標準リソースに対するカスタマイズを定義します。
テンプレート・ファイル: カスタム・テンプレート・ページを定義します。
その他のファイル: コンテンツ・サーバーのグラフィック、Javaコード、ヘルプ・ファイルなどに対するカスタマイズが含まれています。
これらのファイルの詳細は、第9.1.3項「ディレクトリおよびファイルについて」を参照してください。
コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。
HDA
HTM
CFG
Java CLASS
コンポーネント・ウィザードでコンポーネントを構築または解凍する場合、あるいはコンポーネント・マネージャでコンポーネントをアップロードおよびダウンロードする場合は、次のファイルを使用します。
圧縮されたZIPファイル: 他のコンテンツ・サーバーのインスタンスにコンポーネントをデプロイするために使用されます。
manifest.hdaファイル: コンポーネントZIPファイルから解凍またはアップロードされたファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。
コンポーネントとは、実行時にOracle WebCenter Content Serverと対話するように設計されたモジュール式のプログラムです。コンポーネント・アーキテクチャ・モデルは、オブジェクト指向のテクノロジから派生したもので、巨大ですべてを包括した(ただし扱いにくい)アプリケーションを作成するのではなく、小さなモジュールを使用して、必要に応じてOracle WebCenter Content Serverをカスタマイズすることを促進しています。
|
注意: 必要なファイルとリソースを手動で作成することによって、カスタム・コンポーネントを作成できます。ただし、コンポーネント・ウィザードは、手動の方法に比べて制限がなく、これを使用すると、よくある誤りが多く発生することはありません。 |
コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。
HDA
HTM
CFG
Java CLASS
コンポーネントは通常、Oracle WebCenter Content Serverのコアな機能を変更するために使用されます。たとえば、コンポーネントは、次のタスクのいずれかを実行するために使用できます。
標準的なセキュリティ機能を変更する
検索結果が要求され、返されるやり方を変更する
(Macintoshクライアントや専用のCADプログラムなど)特定のシステムとOracle WebCenter Content Serverが提携できるようにする
Oracle WebCenter Content Serverとともにコンポーネント・アーキテクチャを使用すると、次のメリットが得られます。
製品の整合性を損なわずにソース・コードを変更できます。
Oracle WebCenter Content Serverでは、そのリソースの多くが外部のテキスト・ファイルからロードされるため、ファイルを表示してシステムの状況を分析し、そのファイルを要件に合わせてコピーおよび変更できます。
複数のプラットフォームにわたり、複数のインスタンスでカスタム・コンポーネントを使用できます。
カスタム・コンポーネントを作成してある場合は、それをZIPファイルとしてパッケージ化し、他のOracle WebCenter Content Serverのインスタンスにロードできます。数多くのカスタム・コンポーネントは、元の開発プラットフォーム以外のOracle WebCenter Content Serverプラットフォームで機能できます。
トラブルシューティングのために、個別のコンポーネントの有効と無効を切り替えることができます。
カスタマイズをグループ化して、各コンポーネントがOracle WebCenter Content Serverの特定の関数または領域をカスタマイズするようにできます。障害が発生した場合は、コンポーネントを1つずつ無効にすると、トラブルを迅速に隔離できます。
Oracle WebCenter Content Serverのインスタンスは、カスタマイズを損なわずに再インストールまたはアップグレードできます。
カスタム・コンポーネントは、既存の製品リソースを置換するのではなく、無効にします。Oracle WebCenter Content Serverの標準ファイルを置換しても、カスタマイズに影響が発生しない場合もあります。
カスタム・コンポーネントを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。
カスタム・コンポーネントによって、システム全体の動作とルック・アンド・フィールが変更されます。変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。
カスタム・コンポーネントは、Oracle WebCenter Content Serverのコアな機能に対する変更の影響を受ける場合があります。新機能によってコンポーネントの動作が変わる場合があるので、Oracle WebCenter Content Serverの将来のリリースでカスタマイズが機能するという保証はありません。アップグレードするたびに、カスタム・コンポーネントを調べてテストする必要があります。
単純なカスタマイズでは、コンポーネントが不要な場合もあります。単純なコンポーネントの数が多いと、管理が難しくなる可能性があります。
コンポーネントをインストールして、Oracle WebCenter Content Serverによる使用を有効にする必要があります。Oracle WebCenter Content Serverに付属しているコンポーネントは自動的にインストールされ、デフォルトで有効か無効になります。カスタム・コンポーネントをインストールして、使用可能にする必要があります。コンポーネントの操作に際しては、次のいくつかのツールが利用可能です。
コンポーネント・ウィザードを使用すると、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、コンポーネントの新規作成や既存のコンポーネントの変更を行う場合、およびコンポーネントをパッケージ化して他のOracle WebCenter Content Serverのインスタンスで使用できるようにする場合に使用できます。詳細は、第9.2.1項「コンポーネント・ウィザード」を参照してください。
拡張コンポーネント・マネージャは、Oracle WebCenter Content Serverでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、新規コンポーネントを追加したり、コンポーネントをOracle WebCenter Content Serverで有効または無効にできます。詳細は、第9.2.2項「拡張コンポーネント・マネージャ」を参照してください。
ComponentToolは、Oracle WebCenter Content Serverに、コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ユーティリティです。
コンポーネントのアーキテクチャおよび作成の詳細は、第9章「コンテンツ・サーバーのコンポーネントの開始」を参照してください。
HDAファイル
カスタム・リソース・ファイル
manifestファイル
その他のファイル(サイト用にカスタマイズされたファイル、コンポーネントZIPファイル、カスタム・インストール・パラメータ・ファイルなど)
WebCenter Contentの典型的なディレクトリ構造では、コンポーネントのファイルは、DomainHome/ucm/short-product-id/customディレクトリのcomponentディレクトリに格納されています。
コンテンツ・サーバーでは、変数値や参照キーなどのデータをキャッシュするために、データ・バインダを使用します。
HyperData(HDA)ファイルは、構造化された単純なASCIIファイル形式で、プロパティおよび表データを定義するために使用されます。これは、どのコンポーネントが有効および無効になっているか、またそのコンポーネントの定義ファイルがどこにあるかを判別するために、コンテンツ・サーバーによって使用されるテキスト・ファイルです。
HDAファイル形式が役立つのは、頻繁に変わるデータです。それは、サイズがコンパクトで形式が単純であれば、コンテンツ・サーバーでデータ通信が、より高速かつ簡単になるからです。
HDAファイル・タイプは、次のコンポーネント・ファイルの定義に使用されます。
コンポーネント・ファイル(idcshort-product-id_components.hda)
コンポーネント定義ファイル
manifestファイル
動的表リソース・ファイル
テンプレート・リソース・ファイル
例9-1は、customhelpというコンポーネントを指すidccs_components.hdaファイルを示しています。
例9-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などの構成ファイルで、グローバルな環境変数を定義することをお薦めします。
例9-2は、HDAファイルのPropertiesセクションを示しています。
例9-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という形式を使用して、この表を終了しています。
例9-3は、列が4つ、行が3つあるScoresというResultSetを示しています。
例9-3 HDAファイルのResultSetセクション
@ResultSet Scores4namematch1match2match3Margaret686772 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をいくつか、次の名前で使用します。それらの名前は、カスタム・コンポーネントの表には使用しないでください。
idcshort-product-id_components.hdaファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えるテキスト・ファイルです。
idcshort-product-id_components.hdaファイルは常に、IntradocDir/data/componentsディレクトリに格納されています。必要に応じてこのファイルを変更するために、コンポーネント・ウィザード、コンポーネント・マネージャおよびComponentToolを使用できます。
|
注意: リリース11gR1では、components.hdaファイルとedit_components.hdaファイルが、idcshort-product-id_components.hdaという1つのファイルに結合されました。管理サーバーでidcshort-product-id_components.hdaファイルが見つからず、レガシー・ファイルが見つかった場合は、そのレガシー・ファイルのデータが移行され、適切なデータを含むidcshort-product-id_components.hdaファイルが作成されます。 |
例9-4は、スキーマ・コンポーネント、構成の移行コンポーネント、SOAPコンポーネントなど、いくつかの有効なコンポーネントをリストしたidccs_components.hdaファイルを示しています。
コンポーネント定義ファイルは、定義したカスタム・リソースを指します。このファイルでは、カスタム・リソース、ResultSetおよびマージ・ルールに関する情報を指定します。このコンポーネント定義ファイルは、コンポーネントをまとめる「glue(接着剤)」の役割を果たすので、glueファイルと呼ばれることもあります。
コンポーネントの定義ファイルは通常、component_name.hdaという名前であり、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。
|
注意: idcshort-product-id_components.hdaファイルとcomponent_name.hdaファイルを混同しないでください。idcshort-product-id_components.hdaファイルは、インストールされているすべてのコンポーネントの追跡に使用されます。component_name.hdaファイルには、1つのコンポーネントに固有の情報が含まれます。 |
カスタム・リソース・ファイルでは、コンテンツ・サーバーのカスタマイズを定義します。通常はHDAファイルですが、HTMファイルの場合もあります。
コンポーネントのカスタム・リソース・ファイルは通常、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。リソース・ファイルの中には、resources/core/templatesのようなサブディレクトリに配置されるものもあります。
これらのリソースを表9-1に示します。
表9-1 カスタム・リソース・ファイル
| リソース・タイプ | ファイル・タイプ | 目次 |
|---|---|---|
|
HTMLインクルード |
HTM |
インクルードの定義 |
|
文字列 |
HTM |
ローカライズされた文字列の定義 |
|
動的表 |
HDA |
頻繁に変化するデータの表 |
|
静的表 |
HTM |
めったに変化しないデータの表 |
|
問合せ |
HTM |
問合せを定義する表 |
|
サービス |
HTM |
サービス・スクリプトを定義する表 |
|
テンプレート |
HDA |
テンプレート・ページの場所とファイル名を定義する表 |
|
環境 |
CFG |
構成変数の名前と値のペア |
これらのファイルの詳細は、第9.4項「Webページをアセンブルするためのリソース」を参照してください。
また、Webページをアセンブルするために、コンテンツ・サーバーによってtemplate.htmページが使用されます。template.hdmファイルの詳細は、第15.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スクリプトの関数を使用して変更できます。詳細は、Oracle WebCenter Content Idocスクリプト・リファレンス・ガイドを参照してください。
HDAファイル内の@Properties LocalDataセクションは、データ・バインダのLocalDataカテゴリにマップされます。LocalData情報は、名前と値のペアで構成されています。
LocalData情報が保持されるのは、コンテンツ・サーバーのリクエストとレスポンスが有効になっている期間のみです。めったに変化しないサーバー環境に関する情報と異なり、各リクエストのLocalData情報は動的です。
HTTPリクエストの観点で見ると、LocalDataの初期情報は、REQUEST_METHOD、CONTENT_LENGTH、QUERY_STRINGの各HTTP環境変数から収集されます。サービス・リクエストを処理するときに、LocalDataの名前と値のペアを追加または変更できます。
HDAファイルの各@ResultSetセクションは、DataBinderオブジェクトにおける名前付き結果にマップされます。いくつかの結果セットがアクティブになって、値検索時に他の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ファイルのエントリのタイプを定義しています。
| エントリ・タイプ | 説明 | デフォルトのパス |
|---|---|---|
Classes |
Javaクラス・ファイル | DomainHome/ucm/short-product-id/classes |
Common |
共通ファイル | DomainHome/ucm/short-product-id/weblayout/common |
Component |
コンポーネント・リソース・ファイル | DomainHome/ucm/short-product-id/custom |
ComponentExtra |
関連付けられているファイル(readmeなど) | DomainHome/ucm/short-product-id/custom |
Help |
オンライン・ヘルプ・ファイル | DomainHome/ucm/short-product-id/weblayout/help |
Images |
グラフィック・ファイル | DomainHome/ucm/short-product-id/weblayout/images |
Jsp |
JavaServer Pages | DomainHome/ucm/short-product-id/weblayout/jsp |
|
注意: エントリ・タイプCommon、Help、ImagesおよびJspの使用は避けてください。これらは、WebCenter Content 11gでは非推奨になっているからです。WebCenter Contentには、コンポーネントからweblayoutディレクトリにファイルをプッシュする公開エンジンがあります。以前のリリースと同じ動作を望む場合は、公開エンジンを使用します。そうしないと、公開エンジンによって、カスタム・コンポーネントからweblayoutディレクトリにファイルが直接配置され、既存のファイルが上書きされる場合があります。上書きされたファイルは、永続的に失われる可能性があります。 |
location列では、エントリに関連付けられているファイルがインストールされているディレクトリを定義し、一部のエントリ・タイプのファイル名を指定しています。
Componentエントリ・タイプの場合、場所は定義ファイルのパスとファイル名です。次に定義ファイルは、どのリソース・ファイルがコンポーネントに含まれるかを、コンテンツ・サーバーに伝えます。
その他のエントリ・タイプの場合、場所は、ファイル名なしのパス(特定のサブディレクトリ内のファイルをすべて指定するとき)、またはファイル名付きのパス(個別のファイルを指定するとき)になります。
場所は、DomainHome/ucm/short-product-id/customディレクトリからの相対パスを指定する必要があります。絶対パスを使用することもできますが、その場合は、コンポーネントをインストールできる場所が、インストール・ディレクトリのパスが同じコンテンツ・サーバーのインスタンスのみとなります。
例9-5は、manifest.hdファイルを示しています。
カスタム・コンポーネントには、機能のために、またはそのルック・アンド・フィールを生成するために、コンテンツ・サーバーが使用する任意のタイプのファイルを含めることができます。
自社サイト用にカスタマイズされたファイルを追加して、コンテンツ・サーバーの外観またはアクションを変更できます。たとえば、カスタム・リソースでは、次のタイプのファイルが頻繁に参照されます。
グラフィック
標準的なコンテンツ・サーバー・インタフェースを構成するアイコン、背景およびロゴを置換します。
ヘルプ
コンサルティング・サービスの助けがあれば、コンテンツ管理システム用にヘルプ・ファイルをカスタマイズできます。
クラス
Javaコードでは、コンテンツ・サーバーの機能を変更または拡張できます。Javaクラス・ファイルは、DomainHome/ucm/short-product-id/classesディレクトリに配置するために、ディレクトリにパッケージ化する必要があります。
|
注意: グラフィック・ファイルとヘルプ・ファイルは、weblayoutディレクトリに手動で配置することは避けてください。WebCenter Content 11gの公開エンジンがコンポーネントからweblayoutディレクトリにファイルをプッシュして、ファイルを上書きする場合があるからです。以前のリリースと同じ動作を望む場合は、公開エンジンを使用します。そうしないと、公開エンジンによって、カスタム・コンポーネントからこのディレクトリにファイルが直接配置され、既存のファイルが上書きされる場合があります。上書きされたファイルは、永続的に失われる可能性があります。これらのファイルをweblayoutディレクトリに手動で配置する必要がある場合は、Oracle Consulting Servicesにご連絡ください。 |
コンポーネント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 WebCenter Content Content Serverシステム管理者ガイド』またはオンライン・ヘルプを参照してください。
コンテンツ・サーバーの機能のうち、既存のコンポーネントでは提供されていないものが、自社のサイトで必要になった場合、コンテンツ・サーバーのインスタンスにカスタム・コンポーネントを作成できます。
定義ファイルにカスタム・コンポーネントを作成し、そのコンポーネントを有効にしてコンテンツ・サーバーに適用できます。
カスタム・コンポーネントを作成して有効にする手順は次のとおりです。
定義ファイルを作成します。
定義ファイルへの参照をidcshort-product-id_components.hdaファイルに加えて、このコンポーネントを有効にします。
コンテンツ・サーバーを再起動して、このコンポーネントを適用します。
リソースなどのファイルを作成して、カスタマイズを定義します。カスタム・リソース・ファイルを作成するには、コンテンツ・サーバーの標準ファイルをコピー、名前変更および変更することをお薦めします。
必要に応じて、カスタマイズをテストして改定します。変更内容を適用するには、コンテンツ・サーバーの再起動が必要になる場合もあります。
後で使用したり他のコンテンツ・サーバーのインスタンスにデプロイできるように、コンポーネントをパッケージ化する場合は、コンポーネントを構築してコンポーネントZIPファイルを作成します。
コンポーネント・ファイルの操作に際しては、次のツールが利用可能です。
コンポーネント・ウィザードは、コンテンツ・サーバーのユーティリティの1つで、コンポーネント・ファイルの作成と編集に役立ちます。コンポーネント・ウィザードは、コンポーネントのパッケージ化、解凍、有効化および無効化にも使用できます。このユーティリティの使用の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
ほとんどのコンポーネント・ファイルはプレーン・テキスト・ファイルなので、ファイルの作成と編集はお好みのテキスト・エディタでできます。
カスタム・コンポーネントを操作するときは、できるだけコンポーネント・ウィザードを使用してください。
コンポーネント・ウィザードはいくつものタスクをユーザーにかわって行うので、テキスト・エディタでユーザーが行う必要のある作業が最小限に抑えられます。コンポーネント・ウィザードを使用すると、推奨されるファイル構造とネーミング規則を遵守しやすくなります。コンポーネント・ウィザードでは、コンポーネントの構築時にreadmeテキスト・ファイルが自動的に追加され、カスタマイズをドキュメントに残す作業がやりやすくなります。コンポーネント・ファイルにはコメントも含める必要があります。
コンポーネント・ウィザードの使用によるコンポーネント作成の詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
コンテンツ・サーバーをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。本番コンテンツ・サーバーに定義したのと同じカスタム・メタデータ・フィールドを、本番コンテンツ・サーバーに忘れずに含めてください。
開発コンテンツ・サーバーで変更のテストが成功したら、コンポーネント・ウィザードを使用してコンポーネントZIPファイルを構築し、本番システムでコンポーネントを解凍します。
コンポーネントを有効または無効にした後で、コンテンツ・サーバーを忘れずに再起動してください。
カスタム・コンポーネントのインストール後にコンテンツ・サーバーに問題が発生した場合は、そのコンポーネントを無効にしてコンテンツ・サーバーを再起動します。これで問題が解決した場合はおそらく、コンポーネントのトラブルシューティングが必要になります。問題が解決しない場合は、コンポーネント・ウィザードを使用してコンポーネントを完全に除去して、問題がコンポーネントにあるのかコンテンツ・サーバーにあるのかを判別することが必要になると考えられます。
カスタム・コンポーネントを整理するには、次のファイル構造ガイドラインを遵守します。詳細は、第9.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
コンポーネント・ウィザード・ユーティリティでは、カスタム・コンポーネントに必要なすべてのファイルの作成や編集など、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、既存のコンポーネントを変更する場合や、コンテンツ・サーバーで使用できるようにコンポーネントのパッケージ化と解凍を行う場合にも使用できます。
図9-1は、コンポーネント・ウィザードへのインタフェースを示しています。詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネント・ウィザードの使用に関する項を参照してください。
コンポーネント・ウィザードにアクセスする手順は次のとおりです。
UNIXオペレーティング・システム: DomainHome/ucm/short-product-id/bin/に格納されているComponentWizardを実行します。
コンポーネント・ウィザードのメイン・ページが表示されます。
Windowsオペレーティング・システム: 「スタート」メニューからインスタンス名を選択し、「ユーティリティ」、「コンポーネント・ウィザード」の順に選択します。
コンポーネント・ウィザードのメイン・ページが表示されます。
拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、コンポーネントを有効または無効にしたり、コンテンツ・サーバーに新規コンポーネントを追加することが簡単にできます。
拡張コンポーネント・マネージャを使用する手順は次のとおりです。
「管理」トレイまたはメニューで、「管理サーバー」を選択します。
管理サーバーにコンポーネント・マネージャ・ページが表示されます。
コンポーネント・マネージャ・ページの最初の段落で、「拡張コンポーネント・マネージャ」をクリックします。
管理サーバーに、図9-2に示す拡張コンポーネント・マネージャ・ページが表示されます。このページには、有効なコンポーネントと無効なコンポーネントのリストがあります。
拡張コンポーネント・マネージャ・ページで、次のタスクを実行できます。
カテゴリなどのフィルタ別に、有効なコンポーネントと無効なコンポーネントのリストを表示する
コンポーネントを選択して、その詳細を表示する
コンポーネントを有効化する
コンポーネントを無効化する
カスタム・コンポーネントをインストールする
カスタム・コンポーネントをアンインストールする
詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』のコンポーネント・ウィザードの使用に関する項を参照してください。
idcshort-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ディレクトリに格納されています。
これらのファイルは、手動で作成しないでください。コンポーネント・ファイルの作成には、必ずコンポーネント・ウィザードを使用します。
idcshort-product-id_components.hdaファイルには常に、各定義ファイルの名前とファイル・パスを定義するComponentsというResultSetが含まれます。コンポーネントのHDAファイルを変更するには、コンポーネント・ウィザードまたはコンポーネント・マネージャを使用できます。詳細は、第10章「コンテンツ・サーバーのコンポーネントの有効化と無効化」を参照してください。
例9-6は、コンテンツ・サーバーで有効にされている2つのコンポーネント、MyComponentとCustomHelpを指定しているidccs_components.hdaファイルを示しています。
例9-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列では、各コンポーネントの定義ファイルの場所を定義しています。この場所は、絶対パス、またはコンテンツ・サーバーのインストール・ディレクトリを基準とした相対パスで指定できます。
|
注意: locationパスでは、必ずスラッシュを使用してください。 |
コンポーネント定義ファイル、すなわちglueファイルは、定義したカスタム・リソースを指します。コンポーネントの定義ファイルはcomponent_name.hdaという名前であり、通常はDomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。定義ファイルの作成と変更には、コンポーネント・ウィザードを使用できます。
定義ファイルにはResourceDefinition ResultSetが含まれており、MergeRules ResultSet、Filters ResultSet、ClassAliases ResultSet、またはこれらのResultSetの任意の組合せが含まれる場合もあります。例9-7は、一般的なコンポーネント定義ファイルを示しています。
例9-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表では、タイプ、ファイル名、表の名前、およびカスタム・リソースのロード順序が定義されます。例9-8に、ResourceDefinition ResultSetの構造を示します。
例9-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インクルード、文字列、環境の各リソースでは、必須ではありません。
例9-9に、MergeRules ResultSetを示します。
例9-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コードの実行に使用されるフィルタを定義します。例9-10は、標準的なFilters ResultSetを示しています。
ClassAliases ResultSet表は、コンテンツ・サーバーのJavaクラス全体の機能を拡張するために使用されるカスタムJavaクラス・ファイルを指します。例9-11は、標準的なClassAliases ResultSetを示しています。
リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。リソースには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。
コンポーネントのカスタム・リソース・ファイルは通常、DomainHome/ucm/short-product-id/custom/component_nameディレクトリの中にあります。コンポーネントに含まれるリソースが多い場合は、コンポーネント・ディレクトリ内のサブディレクトリ(component_name/resourcesやcomponent_name/templatesなど)にファイルを配置すると、維持がしやすくなります。
リソースの作成には、必ずコンポーネント・ウィザードを使用します。リソース・ファイルは手動で作成しないでください。リソース・ファイルの作成後に編集するやり方には、次の2つがあります。
リソース・ファイルは、コンポーネント・ウィザードを使用して追加、編集、またはコンポーネントから削除できます。コンポーネント・ウィザードでは、事前定義されたリソースに対して、カスタム・リソースを作成するときの開始ポイントとして使用できるコードが用意されています。リソース・ファイルは、コンポーネント・ウィザード内からテキスト・エディタで開くこともできます。
テキスト・エディタでの手動編集
リソース・ファイルは、コンポーネント・ウィザードで作成した後に、必要に応じて、テキスト・エディタで開いてコードを手動で編集できます。
詳細は、第15.2項「コンポーネントのリソースの作成」を参照してください。
|
注意: リソース・ファイルを変更したら、コンテンツ・サーバーを再起動する必要があります。 |
