この章では、Oracle WebCenter Content Serverのコンポーネント(コンテンツ・サーバーの機能変更に使用されるプログラム)を操作する方法について説明します。
この章の内容は次のとおりです。
コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンテンツ・サーバーのコアな標準機能を追加または変更するために、コンテンツ・サーバーには、標準コンポーネント、システム・コンポーネントおよびカスタム・コンポーネントが含まれています。
カスタム・コンポーネントを定義するときには、次のファイルを作成または変更します。
idc
short-product-id
_components.hda
ファイル: どのコンポーネントが有効になっているか、また各コンポーネントの定義ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。これらのファイルの詳細は、「ディレクトリおよびファイルについて」を参照してください。
コンポーネントにはどのようなタイプのファイルを含めることもできますが、最も頻繁に使用されるファイル形式は次のとおりです。
コンポーネント・ウィザードでコンポーネントを構築または解凍する場合、あるいはコンポーネント・マネージャでコンポーネントをアップロードおよびダウンロードする場合は、次のファイルを使用します。
manifest.hda
ファイル: コンポーネントZIPファイルから解凍またはアップロードされたファイルをどこに配置するかを、コンテンツ・サーバーに伝えます。コンポーネントとは、実行時にコンテンツ・サーバーと対話するように設計されたモジュール式のプログラムです。コンポーネント・アーキテクチャ・モデルは、オブジェクト指向のテクノロジから派生したもので、巨大ですべてを包括した(ただし扱いにくい)アプリケーションを作成するのではなく、小さなモジュールを使用して、必要に応じてコンテンツ・サーバーをカスタマイズすることを促進しています。
注意:
必要なファイルとリソースを手動で作成することによって、カスタム・コンポーネントを作成できます。ただし、コンポーネント・ウィザードは、手動の方法に比べて制限がなく、これを使用すると、よくある誤りが多く発生することはありません。
コンポーネントは通常、コンテンツ・サーバーのコアな機能を変更するために使用されます。たとえば、コンポーネントを使用して、次のタスクのいずれかを実行することもできます。
標準的なセキュリティ機能を変更する
検索結果が要求され、返されるやり方を変更する
(Macintoshクライアントや専用のCADプログラムなど)特定のシステムとコンテンツ・サーバーが提携できるようにする
コンテンツ・サーバーとともにコンポーネント・アーキテクチャを使用すると、次のメリットが得られます。
コンテンツ・サーバーでは、そのリソースの多くが外部のテキスト・ファイルからロードされるため、ファイルを表示してシステムの状況を分析し、そのファイルを要件に合わせてコピーおよび変更できます。
カスタム・コンポーネントを作成してある場合は、それをZIPファイルとしてパッケージ化し、他のコンテンツ・サーバーのインスタンスにロードできます。数多くのカスタム・コンポーネントは、元の開発プラットフォーム以外のコンテンツ・サーバー・プラットフォームで機能できます。
カスタマイズをグループ化して、各コンポーネントがコンテンツ・サーバーの特定の関数または領域をカスタマイズするようにできます。障害が発生した場合は、コンポーネントを1つずつ無効にすると、トラブルを迅速に隔離できます。
カスタム・コンポーネントは、既存の製品リソースを置換するのではなく、無効にします。コンテンツ・サーバーの標準ファイルを置換しても、カスタマイズに影響が発生しない場合もあります。
カスタム・コンポーネントを使用するかどうかを判断する際には、次の制約事項を頭に入れてください。
カスタム・コンポーネントによって、システム全体の動作とルック・アンド・フィールが変更されます。 変更内容を、限定された状況にのみ適用する場合は、動的サーバー・ページを検討してみてください。
カスタム・コンポーネントは、コンテンツ・サーバーのコアな機能に対する変更の影響を受ける場合があります。新機能によってコンポーネントの動作が変わる場合があるので、コンテンツ・サーバーの将来のリリースでカスタマイズが機能するという保証はありません。アップグレードするたびに、カスタム・コンポーネントを調べてテストする必要があります。
単純なカスタマイズでは、コンポーネントが不要な場合もあります。単純なコンポーネントの数が多いと、管理が難しくなる可能性があります。
コンポーネントをインストールして、コンテンツ・サーバーによる使用を有効にする必要があります。コンテンツ・サーバーに付属しているコンポーネントは自動的にインストールされ、デフォルトで有効か無効になります。カスタム・コンポーネントをインストールして、使用可能にする必要があります。コンポーネントの操作に際しては、次のいくつかのツールが利用可能です。
コンポーネント・ウィザードを使用すると、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、コンポーネントの新規作成や既存のコンポーネントの変更を行う場合、およびコンポーネントをパッケージ化して他のコンテンツ・サーバーのインスタンスで使用できるようにする場合に使用できます。詳細は、「コンポーネント・ウィザード」を参照してください。
拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、新規コンポーネントを追加したり、コンポーネントをコンテンツ・サーバーで有効または無効にできます。詳細は、「拡張コンポーネント・マネージャを使用したコンポーネントの管理」を参照してください。
ComponentToolは、コンテンツ・サーバーに、コンポーネントのインストール、有効化および無効化を行うためのコマンドライン・ユーティリティです。
コンポーネントのアーキテクチャおよび作成の詳細は、「コンテンツ・サーバーのコンポーネントの開始」を参照してください。
コンポーネントの作成に使用されるファイルは次のとおりです。
WebCenter Contentの標準的なディレクトリ構造では、コンポーネントのファイルは、DomainHome
/ucm/
short-product-id
/custom
ディレクトリのcomponent
ディレクトリに格納されています。
コンテンツ・サーバーでは、変数値や参照キーなどのデータをキャッシュするために、データ・バインダを使用します。
HyperData (HDA)ファイルは、構造化された単純なASCIIファイル形式で、プロパティおよび表データを定義するために使用されます。これは、どのコンポーネントが有効および無効になっているか、またそのコンポーネントの定義ファイルがどこにあるかを判別するために、コンテンツ・サーバーによって使用されるテキスト・ファイルです。
HDAファイル形式が役立つのは、頻繁に変わるデータです。それは、サイズがコンパクトで形式が単純であれば、コンテンツ・サーバーでデータ通信が、より高速かつ簡単になるからです。
HDAファイル・タイプは、次のコンポーネント・ファイルの定義に使用されます。
コンポーネント・ファイル(idc
short-product-id
_components.hda
)
コンポーネント定義ファイル
manifestファイル
動的表リソース・ファイル
テンプレート・リソース・ファイル
{例 - コンポーネントのidccs_components.hdaファイル}は、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
などの構成ファイルで、グローバルな環境変数を定義することをお薦めします。
{例 - HDAファイルのPropertiesセクション}は、HDAファイルのProperties
セクションを示しています。
Properties Section of an HDA File @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
という形式を使用して、この表を終了しています。
{例 - HDAファイルのResultSetセクション}は、列が4つ、行が3つあるScores
というResultSetを示しています。
ResultSet Section of an HDA File@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では、components.hda
ファイルとedit_components.hda
ファイルが、idc
short-product-id
_components.hda
という1つのファイルに結合されました。コンテンツ・サーバーでidc
short-product-id
_components.hda
ファイルが見つからず、レガシー・ファイルが見つかった場合は、そのレガシー・ファイルのデータが移行され、適切なデータを含むidc
short-product-id
_components.hda
ファイルが作成されます。
{例 - 複数の有効なコンポーネントのidccs_components.hdaファイル}は、スキーマ・コンポーネント、構成の移行コンポーネント、SOAPコンポーネントなど、いくつかの有効なコンポーネントをリストしたidccs_components.hda
ファイルを示しています。
idccs_components.hda File for Multiple Enabled Components @properties LocalData blDateFormat=M/d/yy @end @ResultSet Components 2 name location SchemaDCL custom/SchemaDCL/SchemaDCL.hda ConfigMigrationUtility custom/ConfigMigrationUtility/Cmu.hda Soap custom/Soap/Soap.hda @end
コンポーネント定義ファイルは、定義したカスタム・リソースを指します。このファイルでは、カスタム・リソース、ResultSetおよびマージ・ルールに関する情報を指定します。このコンポーネント定義ファイルは、コンポーネントをまとめる「glue(接着剤)」の役割を果たすので、glueファイルと呼ばれることもあります。
コンポーネントの定義ファイルは通常、component_name
.hda
という名前であり、DomainHome
/ucm/
short-product-id
/custom/
component_name
/
ディレクトリに置かれています。
注意:
idc
short-product-id
_components.hda
ファイルとcomponent_name
.hda
ファイルを混同しないでください。idc
short-product-id
_components.hda
ファイルは、インストールされているすべてのコンポーネントの追跡に使用されます。component_name
.hda
ファイルには、1つのコンポーネントに固有の情報が含まれます。
カスタム・リソース・ファイルでは、コンテンツ・サーバーのカスタマイズを定義します。通常は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 |
構成変数の名前と値のペア |
これらのファイルの詳細は、「Webページをアセンブルするためのリソース」を参照してください。
また、Webページをアセンブルするために、コンテンツ・サーバーによってtemplate.htm
ページが使用されます。template.hdm
ファイルの詳細は、「テンプレート」を参照してください。
ResultSet HTM表ファイルが、その他のリソースによって使用されます。HTMファイルのResultSet表は、データのレイアウトにHTML表のタグを使用することを除き、HDAファイルのResultSetに似ています。静的表リソース、サービス・リソースおよび問合せリソースはすべて、この表形式を使用しています。
HTMファイルのResultSet表は、先頭が<@table
table_name
@>
で末尾が<@end@>
です。開始タグと終了タグの間にあるマークアップがHTML表です。HDAファイル内のResultSetとは異なり、表のタグによって列の数が暗示されています。
データ構造を定義していないHTML構文があれば、表のロード時に無視されます。そのため、HTMファイルの表の中ではHTMLコメントが許可されており、Webブラウザでのデータの表示を向上させるために、HTMLのstyle属性を使用できます。
コンテンツ・サーバーでは、(変数の値や参照キーなどの)データが、データ・バインダに内部でキャッシュされます。データ・バインダ内のデータはすべて、どこから来たか、またどのように作成されたかに従って分類されます。サービス・リクエストを満たすために値が必要な場合は、データ・バインダ内のデータが、次に示すデフォルトの順序で評価されます。
この優先順位は、Idocスクリプトの関数を使用して変更できます。詳細は、「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 Pages |
|
注意:
エントリ・タイプCommon
、Help
、Images
およびJsp
の使用は避けてください。これらは、WebCenter Content 11gでは非推奨になっているからです。WebCenter Contentには、コンポーネントからweblayout
ディレクトリにファイルをプッシュする公開エンジンがあります。以前のリリースと同じ動作を望む場合は、公開エンジンを使用します。そうしないと、公開エンジンによって、カスタム・コンポーネントからweblayout
ディレクトリにファイルが直接配置され、既存のファイルが上書きされる場合があります。上書きされたファイルは、永続的に失われる可能性があります。
location
列では、エントリに関連付けられているファイルがインストールされているディレクトリを定義し、一部のエントリ・タイプのファイル名を指定しています。
Component
エントリ・タイプの場合、場所は定義ファイルのパスとファイル名です。次に定義ファイルは、どのリソース・ファイルがコンポーネントに含まれるかを、コンテンツ・サーバーに伝えます。
その他のエントリ・タイプの場合、場所は、ファイル名なしのパス(特定のサブディレクトリ内のファイルをすべて指定するとき)、またはファイル名付きのパス(個別のファイルを指定するとき)になります。
場所は、DomainHome
/ucm/
short-product-id
/custom
ディレクトリからの相対パスを指定する必要があります。絶対パスを使用することもできますが、その場合は、コンポーネントをインストールできる場所が、インストール・ディレクトリのパスが同じコンテンツ・サーバーのインスタンスのみとなります。
{例 - manifest.hdaファイル}は、manifest.hda
ファイルを示しています。
例12-2 manifest.hdaファイル
@ResultSet Manifest 2 entryType location component MyComponent/MyComponent.hda componentExtra MyComponent/readme.txt images MyComponent/ @end
カスタム・コンポーネントには、機能のために、またはそのルック・アンド・フィールを生成するために、コンテンツ・サーバーが使用する任意のタイプのファイルを含めることができます。
自社サイト用にカスタマイズされたファイルを追加して、コンテンツ・サーバーの外観またはアクションを変更できます。たとえば、カスタム・リソースでは、次のタイプのファイルが頻繁に参照されます。
グラフィック
標準的なコンテンツ・サーバー・インタフェースを構成するアイコン、背景およびロゴを置換します。
ヘルプ
コンサルティング・サービスの助けがあれば、コンテンツ管理システム用にヘルプ・ファイルをカスタマイズできます。
クラス
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 Fusion Middleware Oracle WebCenter Contentの管理』、またはオンライン・ヘルプを参照してください。
コンテンツ・サーバーの機能のうち、既存のコンポーネントでは提供されていないものが、自社のサイトで必要になった場合、コンテンツ・サーバーのインスタンスにカスタム・コンポーネントを作成できます。定義ファイル内にカスタム・コンポーネントを作成してから、コンポーネントを有効化し、コンテンツ・サーバーに適用できます。
カスタム・コンポーネントを作成して有効にする手順は次のとおりです。
idc
short-product-id
_components.hda
ファイルに加えて、このコンポーネントを有効にします。コンポーネント・ファイルの操作に際しては、次のツールが利用可能です。
コンポーネント・ウィザード
コンポーネント・ウィザードは、コンテンツ・サーバーのユーティリティの1つで、コンポーネント・ファイルの作成と編集に役立ちます。コンポーネント・ウィザードは、コンポーネントのパッケージ化、解凍、有効化および無効化にも使用できます。このユーティリティの使用に関する詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
テキスト・エディタ
ほとんどのコンポーネント・ファイルはプレーン・テキスト・ファイルなので、ファイルの作成と編集はお好みのテキスト・エディタでできます。
カスタム・コンポーネントを操作するときは、できるだけコンポーネント・ウィザードを使用してください。
コンポーネント・ウィザードはいくつものタスクをユーザーにかわって行うので、テキスト・エディタでユーザーが行う必要のある作業が最小限に抑えられます。コンポーネント・ウィザードを使用すると、推奨されるファイル構造と命名規則を遵守しやすくなります。コンポーネント・ウィザードでは、コンポーネントの構築時にreadmeテキスト・ファイルが自動的に追加され、カスタマイズをドキュメントに残す作業がやりやすくなります。コンポーネント・ファイルにはコメントも含める必要があります。
コンポーネント・ウィザードの使用に関する詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
コンテンツ・サーバーをカスタマイズする場合は常に、開発作業を本番システムから切り離してください。本番コンテンツ・サーバーに定義したのと同じカスタム・メタデータ・フィールドを、本番コンテンツ・サーバーに忘れずに含めてください。
カスタム・コンポーネントを整理するには、次のファイル構造ガイドラインを遵守します。詳細は、「一般的なディレクトリ構造」を参照してください。
注意:
コンポーネント・ウィザードを使用した場合は、コンポーネント・ディレクトリが作成され、適切なディレクトリにコンポーネント・ファイルが配置されます。
それぞれのカスタム・コンポーネントは、DomainHome
/ucm/
short-product-id
/custom/
というディレクトリ内の専用のディレクトリに置いてください。リソース・タイプまたはテンプレート・タイプ、あるいはその両方のリソースがカスタム・コンポーネントに含まれている場合、component
ディレクトリには、IdcHomeDir
/data/resources/core/
ディレクトリの構造を遵守したサブディレクトリが必要です。
resources/
: HTMLインクルードと表リソース・ファイルを保持resources/lang/
: 文字列リソース・ファイルを保持templates/
: テンプレート・ファイルを保持reports/
: レポート・ファイルを保持ファイルとその編成を検討する際には、次の点を頭に入れてください。
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)も使用する必要があります。詳細は、「ローカライズされた文字列の解決」を参照してください。
コンポーネントの管理に使用できるツールは次のとおりです。
コンポーネント・ウィザード・ユーティリティでは、カスタム・コンポーネントに必要なすべてのファイルの作成や編集など、カスタム・コンポーネントの作成プロセスが自動化されます。コンポーネント・ウィザードは、既存のコンポーネントを変更する場合や、コンテンツ・サーバーで使用できるようにコンポーネントのパッケージ化と解凍を行う場合にも使用できます。
図12-1は、コンポーネント・ウィザードへのインタフェースを示しています。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のコンポーネント・ウィザードを使用したコンポーネントの作成に関する項を参照してください。
コンポーネント・ウィザードにアクセスする手順は次のとおりです。
DomainHome
/ucm/
short-product-id
/bin/
に格納されているComponentWizardを実行します。コンポーネント・ウィザードのメイン・ページが表示されます。
コンポーネント・ウィザードのメイン・ページが表示されます。
拡張コンポーネント・マネージャは、コンテンツ・サーバーでカスタム・コンポーネントを管理する手段です。拡張コンポーネント・マネージャを使用すると、コンポーネントを有効または無効にしたり、コンテンツ・サーバーに新規コンポーネントを追加することが簡単にできます。
拡張コンポーネント・マネージャを使用する手順は次のとおりです。
詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のコンポーネントの管理に関する項を参照してください。
idc
short-product-id
_components.hda
ファイルは、どのコンポーネントが有効になっているか、また各コンポーネントの定義(glue)ファイルがどこにあるかを、コンテンツ・サーバーに伝えます。12c (12.2.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ファイルを変更するには、コンポーネント・ウィザードまたはコンポーネント・マネージャを使用できます。詳細は、「コンテンツ・サーバーのコンポーネントの有効化と無効化」を参照してください。
例12-3は、コンテンツ・サーバーで有効にされている2つのコンポーネント、MyComponent
とCustomHelp
を指定しているidccs_components.hda
ファイルを示しています。
例12-3 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の任意の組合せが含まれる場合もあります。例12-4は、一般的なコンポーネント定義ファイルを示しています。
例12-4 コンポーネント定義ファイル
<?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表では、タイプ、ファイル名、表の名前、およびカスタム・リソースのロード順序が定義されます。{例 - ResourceDefinition ResultSet}に、ResourceDefinition
ResultSetの構造を示します。
例12-5 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インクルード、文字列、環境の各リソースでは、必須ではありません。
{例 - MergeRules ResultSet}に、MergeRules
ResultSetを示します。
例12-6 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コードの実行に使用されるフィルタを定義します。{例 - Filters ResultSet}は、一般的なFilters
ResultSetを示しています。
例12-7 Filters ResultSet
@ResultSet Filters 4 type location parameter loadOrder loadMetaOptionsLists intradoc.server.ExecuteSubServiceFilter GET_CHOICE_LIST_SUB 1 @end
ClassAliases
ResultSet表は、コンテンツ・サーバーのJavaクラス全体の機能を拡張するために使用されるカスタムJavaクラス・ファイルを指します。{例 - ClassAliases ResultSet}は、一般的なClassAliases
ResultSetを示しています。
例12-8 ClassAliases ResultSet
@ResultSet ClassAliases 2 classname location WorkflowDocImplementor WorkflowCheck.CriteriaWorkflowImplementor @end
リソースとは、コンテンツ・サーバーに対して実際に行うカスタマイズを定義および実装するファイルです。リソースには、HTMLコードの断片、動的ページの要素、データベースからデータを収集する問合せ、コンテンツ・サーバーのアクションを実行するサービス、または情報を条件付きで書式設定する特殊コードが考えられます。
コンポーネントのカスタム・リソース・ファイルは通常、DomainHome
/ucm/
short-product-id
/custom/
component_name
ディレクトリの中にあります。コンポーネントに含まれるリソースが多い場合は、コンポーネント・ディレクトリ内のサブディレクトリ(component_name
/resources
やcomponent_name
/templates
など)にファイルを配置すると、維持がしやすくなります。
リソースの作成には、必ずコンポーネント・ウィザードを使用します。リソース・ファイルは手動で作成しないでください。リソース・ファイルの作成後に編集するやり方には、次の2つがあります。
コンポーネント・ウィザード
リソース・ファイルは、コンポーネント・ウィザードを使用して追加、編集、またはコンポーネントから削除できます。コンポーネント・ウィザードでは、事前定義されたリソースに対して、カスタム・リソースを作成するときの開始ポイントとして使用できるコードが用意されています。リソース・ファイルは、コンポーネント・ウィザード内からテキスト・エディタで開くこともできます。
テキスト・エディタでの手動編集
リソース・ファイルは、コンポーネント・ウィザードで作成した後に、必要に応じて、テキスト・エディタで開いてコードを手動で編集できます。
詳細は、「コンポーネントのリソースの作成」を参照してください。
注意:
リソース・ファイルを変更したら、コンテンツ・サーバーを再起動する必要があります。