| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
|
前 |
次 |
この章の内容は次のとおりです。
カスタマイズしたアプリケーションのデプロイ方法の詳細は、「アプリケーションのデプロイ」を参照してください。
Oracle Metadata Services (MDS)は、ADFアプリケーション・カスタマイズを処理するためのフレームワークです。カスタマイズはメタデータ・リポジトリに格納され、実行時にベース・メタデータとマージされます。
MDSのカスタマイズ機能を使用して、次のカスタマイズ・パターンのアプリケーションを作成できます。
シード・カスタマイズ
アプリケーションのシード・カスタマイズとは、汎用化されたアプリケーションを特定のグループ(特定の産業やサイトなど)のニーズにあわせて変更するプロセスです。シード・カスタマイズはデプロイされたアプリケーションの一部として存在し、特定のデプロイ期間中保持されます。この章では、カスタマイズ可能なアプリケーションを作成し、JDeveloperを使用してそのアプリケーションをカスタマイズする方法について説明します。
ユーザー・カスタマイズ(変更永続性)
ユーザー・カスタマイズでは、エンド・ユーザーは実行時に個々の設定(表にどの列を表示するかなど)にあわせてアプリケーションの内容を変更できます。変更内容は、次回そのアプリケーションを開くときに記憶されます。ユーザー・カスタマイズの詳細は、「実行時のユーザー・カスタマイズの許可」を参照してください。
実行時のデザインタイム
Oracle WebCenter Portalの機能を使用して、実行時にカスタマイズ可能なアプリケーションを作成できます。これにより、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。実行時のカスタマイズの詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のOracle WebCenter Portalの開発の概要に関する項を参照してください。
MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。
カスタマイズしたアプリケーションは、ベース・アプリケーションとカスタマイズを含む1つ以上のレイヤーで構成されます。MDSは、カスタマイズをメタデータ・リポジトリに格納し、実行時にこのカスタマイズを取得してベース・メタデータにマージし、カスタマイズ済アプリケーションを公開します。カスタマイズはベースとは別個に保存されるため、アップグレードの際にカスタマイズが保護されます。つまり、新しいパッチをベースに適用する場合でも、カスタマイズに影響を与えずに行えるということです。カスタマイズ済アプリケーションが起動されると、カスタマイズの内容がベース・アプリケーションに適用されます。
たとえば、給与フィールドを4000に制限する検証規則を持つ、一般的な給与アプリケーションがあるとします。次に、給与フィールドを3300に制限する、この検証規則のカスタマイズを作成します。実行時に、ベース・アプリケーションにカスタマイズが適用され、給与フィールドの検証規則によりフィールドは3300に制限されます。
カスタマイズ可能なアプリケーションには、複数のカスタマイズ・レイヤーを設定できます。カスタマイズ・レイヤーには、業種やサイトなどがあります。各レイヤーには複数のカスタマイズ・レイヤー値を設定できますが、通常、実行時には、各レイヤーからこのようなレイヤー値が1つだけ適用されます。たとえば、カスタマイズ可能なアプリケーションのindustryレイヤーには、healthcareやfinancialなどの業種の値を格納できます。一方、デプロイ対象のカスタマイズ済アプリケーションで一度に使用されるのは、このレイヤー値のいずれか1つのみです。
複数のカスタマイズ・レイヤーからのレイヤー値を、指定の優先順位に従ってベース・メタデータの最上位に適用できます。たとえば、カスタマイズされたアプリケーションでは、industryレイヤーのfinancialレイヤー値とsiteレイヤーのFinancial Company #1レイヤー値にカスタマイズを含めることができます。各カスタマイズ・レイヤーは、基礎となるメタデータを変更する一連の指示を含んだカスタマイズ・ドキュメントに対応します。
カスタマイズしたアプリケーションのカスタマイズ・コンテキストは、適用された一連のカスタマイズ・レイヤー値により定義されます。
図51-1に、カスタマイズしたアプリケーションにレイヤーを適用する方法を示します。
これをサポートするために、JDeveloperを使用してカスタマイズ・クラスを作成し、レイヤーと値を定義して、優先順位を指定します。これらのプロセスの詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。
カスタマイズは、静的なものと動的なものに分類できます。動的なカスタマイズでは、アプリケーションの実行コンテキストによって変化する値を指定できるのに対し、静的なカスタマイズでは、アプリケーションのすべての実行で有効な1つのレイヤー値のみを指定できます。アプリケーションを実行する様々なユーザーによってカスタマイズが変化する可能性がある場合、それは動的なカスタマイズです。アプリケーションを実行するすべてのユーザーでカスタマイズの値が同じである場合、それは静的なカスタマイズです。
ADFビジネス・コンポーネント・オブジェクトにカスタマイズを実装する場合、カスタマイズはアプリケーションの実行時全体にわたって変化しません。これらのオブジェクトはアプリケーションに対して1回だけロードされ、アプリケーションの継続中再利用されるためです。たとえば、サイト・レイヤーのHealthcare Company #1値で、そのサイトの給与フィールドを3300に制限するカスタマイズされた検証規則を持つことができます。これは静的なカスタマイズ・コンテンツです。
ただし、ユーザー・ロール(職責)または他のアプリケーション固有の条件に基づいて実行時にレイヤー値を決定できるカスタマイズを、コントローラ・レベルまたはビュー・レベルで実装することもできます。たとえば、組織が異なるユーザーには画面上で異なるフィールドを表示するように、アプリケーションを設計できます。これは動的なカスタマイズ・コンテンツです。
カスタマイズが静的か動的かの判断は、カスタマイズ・クラスで行われます。カスタマイズ・クラスで、getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。
カスタマイズ・クラスの実装方法によっては、すべてのオブジェクトが静的なカスタマイズ・レイヤーを持つことができます。ただし、ADFビジネス・コンポーネント・オブジェクトの場合、静的なカスタマイズしか使用できません。
カスタマイズを使用し始める前に、他の機能を理解することが役立つ場合があります。次に、関連する他の機能へのリンクを示します。
MDSアーキテクチャとメタデータ・リポジトリ(データベース・ベースおよびファイル・ベース)およびアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項を参照してください。
ADF Faces変更永続性フレームワークを使用して、ユーザーが実行時にカスタマイズ可能なJSFページを作成できます。「実行時のユーザー・カスタマイズの許可」を参照してください。
Oracle WebCenter Portalの機能により、ビジネス・アナリストや管理者はWebブラウザ・インタフェースを使用して、エンド・ユーザー向けにアプリケーションをカスタマイズできます。実行時のカスタマイズの詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のOracle WebCenter Portalの開発の概要に関する項を参照してください。
ADFアプリケーションをカスタマイズする場合は、ベース・アプリケーションの作成後に特定の手順に従う必要があります。
カスタマイズ可能なアプリケーションを作成するには、ベース・アプリケーションを作成して次の手順を実行します。
カスタマイズ用にアプリケーションを準備するには:
adf-config.xmlファイルでカスタマイズ・クラスを指定します。カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。各カスタマイズ・クラスでカスタマイズ・レイヤー(industryやsiteなど)を定義して、複数のレイヤー値を含めることができます。アプリケーションで使用するカスタマイズ・クラスは、アプリケーションのカスタマイズ時にJDeveloperで使用できる必要があります。また、デプロイされたアプリケーションに含める必要があります。
カスタマイズ・クラスでは、現在のコンテキストが評価されてStringの結果が戻されます。このStringの結果を使用してカスタマイズ・レイヤーが検索されます。
カスタマイズ・クラスによって、次の情報が提供されます。
レイヤー名を表す名前。
カスタマイズ・レイヤー値を表す値の配列通常、各レイヤーで値が1つ戻されます。複数の値が戻される場合、MDSリポジトリでこれらの値に使用可能なカスタマイズが、配列に表示された順序で適用されます。null値や、空の文字列("")を含む配列は、適用するカスタマイズ・レイヤーが存在しないことを示します。詳細は、「カスタマイズ・クラスでのgetValue()メソッドの実装」を参照してください。
レイヤーで作成されたオブジェクトのIDPrefix。カスタマイズ・レイヤーで新しいオブジェクトを作成する場合、一意のIDが必要です。オブジェクトの自動生成IDにIDPrefixが追加されて、新たに追加されたオブジェクトのIDが作成されます。異なるカスタマイズ・レイヤーで作成されたオブジェクトに一意のIDを指定するために、各レイヤーに一意のIDPrefixを指定する必要があります。
カスタマイズ・クラスによって定義されたレイヤーのキャッシュ・ヒント。キャッシュ・ヒントは、レイヤーが静的か動的かを定義します。getCacheHint()メソッドがALL_USERSを戻す場合、カスタマイズ・レイヤーは静的です。動的なカスタマイズの詳細は、「静的および動的なカスタマイズ・コンテンツ」を参照してください。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。
カスタマイズを使用して、特定の業種ドメインにあわせてアプリケーションを調整できます(垂直統合)。このようなドメインはそれぞれカスタマイズ・レイヤーを表しており、カスタマイズ・クラスを使用して示されます。
カスタマイズ・クラスを使用してシード・カスタマイズを実装するには:
adf-config.xmlのcust-configセクション(mds-configの下)に、カスタマイズ・クラスへの参照を含める必要があります(「adf-config.xmlファイルの構成方法」を参照)。
カスタマイズ構成(cust-config)セクションでは、カスタマイズしたアプリケーションのカスタマイズ・クラスと優先順位が指定されます。「adf-config.xmlファイルの構成方法」を参照してください。
カスタマイズ・クラスをアプリケーションに含め、シード・カスタマイズをサポートする必要があります。
詳細は、「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」を参照してください。実行時に、EARレベルのアプリケーション・クラス・ローダーで、該当のカスタマイズ・クラスを使用できる必要があります。
レイヤー値が、CustomizationLayerValues.xmlファイルにリストされている必要があります。
このファイルは、jdev_install\jdevディレクトリにあります。このファイルのレイヤーの名前は、カスタマイズ・クラスと一致する必要があります。(詳細は、「カスタマイズ・レイヤーの構成方法」を参照。)JDeveloperは、このファイルを使用して、設計時にレイヤー値を取得します。
「カスタマイズ開発者」ロールでJDeveloperが起動されると、「カスタマイズ・コンテキスト」ウィンドウに使用可能なカスタマイズ・レイヤーとレイヤー値が表示されます。「カスタマイズ・コンテキスト」ウィンドウで、カスタマイズを適用するレイヤーと値を選択します。「カスタマイズ開発者」ロールでの作業の詳細は、「「カスタマイズ開発者」ロールの概要」を参照してください。カスタマイズ先として選択したレイヤーは、ヒント・レイヤーと呼ばれます。詳細は、「ヒント・レイヤーの概要」を参照してください。
次の例は、サンプルのカスタマイズ・クラスを示しています。すべてのカスタマイズ・クラスは、単一の引数なしのコンストラクタを持っている必要があります。
package mycompany;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import oracle.mds.core.MetadataObject;
import oracle.mds.core.RestrictedSession;
import oracle.mds.cust.CacheHint;
import oracle.mds.cust.CustomizationClass;
public class IndustryCC extends CustomizationClass {
private static final String DEFAULT_LAYER_NAME = "industry";
private String mLayerName = DEFAULT_LAYER_NAME;
public IndustryCC() {
}
public CacheHint getCacheHint() {
return CacheHint.ALL_USERS;
}
public String getName() {
return mLayerName;
}
public String generateIDPrefix(RestrictedSession sess, MetadataObject mo) {
return "I";
}
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
// This needs to return the appropriate value at runtime.
return new String[] {"financial"};
}
}
この例では、カスタマイズ・クラスの動作を定義する4つのメソッドgetCacheHint()、getName()、generateIDPrefix()およびgetValue()を示しています。
getCacheHint()の戻り値は、このカスタマイズによりメタデータ・オブジェクトの可視性が広がり、その結果メモリー内での存続期間が長くなることを、MDSに示します。また、レイヤーが静的か動的かも定義します。この例では、getCacheHint()メソッドはALL_USERSを戻すため、カスタマイズ・レイヤーは静的です。CacheHint値の詳細は、「カスタマイズ・クラスに関する必知事項」を参照してください。
getName()メソッドは、カスタマイズ・レイヤーの名前を戻します。たとえば、SiteCCカスタマイズ・クラスはsiteを戻します。この例では、getName()メソッドはindustryを戻します。
generateIDPrefix()メソッドは、IDPrefixを作成します。IDPrefixはレイヤーの名前と値を識別する、一意の省略形の文字列です。カスタマイズ・レイヤーで作成されたオブジェクトのIDの接頭辞として使用されます。デフォルト実装では(IDPrefixが指定されていない場合)、カスタマイズ値と連結されたレイヤー名が戻されます。パフォーマンス上の理由により、IDPrefixは短くする必要があります(4文字以下)。このため、デフォルト実装をオーバーライドする必要があります。関連するgetIDPrefix()メソッドは、カスタマイズ・レイヤーのIDPrefixを戻します。この例では、getIDPrefix()メソッドはI (industryの場合)を戻します。
getValue()メソッドは、カスタマイズ・クラスのカスタマイズ値(複数可)を戻します。この例では、getValue()メソッドは単一値financialを戻し、レイヤー名と組合せてカスタマイズ・コンテキストを定義します。「カスタマイズ・クラスでのgetValue()メソッドの実装」で、getValue()メソッドを使用するその他の手法について説明します。
注意:
レイヤー名に対応する有効なレイヤー値は、JDeveloperによってCustomizationLayerValues.xmlファイルから「カスタマイズ開発者」ロールで取得されます。レイヤーの優先順位は、adf-config.xmlファイルで指定されたカスタマイズ・クラスの順序によって定義されます。レイヤーの名前は、これらのファイルおよびカスタマイズ・クラスで一貫性がある必要があります。
getValue()メソッドを使用して、アプリケーションのコンテキストとメタデータに基づいて、カスタマイズ・クラスのレイヤー値が取得されます。たとえば、SiteCCカスタマイズ・クラスでgetValue()を呼び出すと、単一エントリheadquartersを持つ配列が戻されます。一般に、getValue()メソッドは単一値を持つ配列を戻します(「カスタマイズ・クラス」を参照)。
getValue()メソッドから複数の値を戻すこともできます(次の例を参照)。
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
return new String[]{"North America", "US", "CA"}
}
複数の値が戻される場合、すべての値に適用できるカスタマイズが適用されます。カスタマイズは、配列に表示された順序で適用されます。この例では、North Americaカスタマイズがベース・アプリケーションに適用され、次にUSカスタマイズが適用され、最後にCAが適用されます。
注意:
カスタマイズ・レイヤーに複数の値を戻すことは高度な概念で、通常は必要とされません。
getValue()メソッドは、現行ユーザーの現在の実行コンテキストに基づいてレイヤー値を戻すことができます。この値は、クライアントが保持する静的またはスレッド・ローカル状態から、またはMDSセッションでメタデータ・オブジェクト名に基づいてクライアントによって設定されたプロパティから取得されます。次の例は、このタイプの実装を示しています。
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
if (mo.getName().equals("/sample/abc.jspx"))
{
return new String[]{"Headquarters"};
}
else
{
return new String[]{"RemoteSite"};
}
}
この例では、getValue()メソッドはメタデータ・オブジェクトでgetName()メソッドを使用して、メタデータ・ドキュメントの名前が/sample/abc.jspxかどうかを判断します。この名前である場合、getValue()はHeadquartersを戻して、headquartersカスタマイズを適用します。この名前でない場合、RemoteSiteを戻して、リモート・サイトのカスタマイズを適用します。
注意:
getValue()メソッドをコーディングし、メタデータ・オブジェクトに基づいて値を戻すことは、高度な概念で通常は必要とされません。動的なレイヤーのカスタマイズ・コンテキストは、通常、ユーザー名や職責などアプリケーション・コンテキストのファセットよって決定されます。
開発サイクル中に有効なその他の手法として、外部プロパティ・ファイルを使用してレイヤー値を指定する手法があります。次の例は、レイヤー値を格納するプロパティ・ファイル(customization.properties)を参照しています。
public String[] getValue(RestrictedSession sess, MetadataObject mo) {
Properties properties = new Properties();
String configuredValue = null;
Class clazz = IndustryCC.class;
InputStream is = clazz.getResourceAsStream("/customization.properties");
if (is != null){
try {
properties.load(is);
String propValue = properties.getProperty(mLayerName);
if (propValue != null){
configuredValue = propValue;
}
} catch (IOException e) {
e.printStackTrace();
}
finally {
try {
is.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
return new String[] {configuredValue};
}
この手法を使用するアプリケーションがJDeveloperで実行されている場合、プロパティ・ファイルでレイヤー値を変更し、ブラウザをリフレッシュして、適用される新しいカスタマイズを確認できます。このカスタマイズ・クラスとプロパティ・ファイルの組合せによって、レイヤー値を別のファイルに保持できるため、特定のデプロイメントのためにJavaコードを修正およびリコンパイルしてレイヤー値を変更する必要はありません。customization.propertiesファイルを使用する場合は、同じクラス・ローダーからロードされるように、カスタマイズ・クラスとともにパッケージ化する必要があります。
次の例は、customization.propertiesファイルのサンプルを示しています。このプロパティ・ファイルでIndustryCCクラスがロードされる場合、レイヤー値healthcareが適用されます。
#Configured values for the default layer values industry=healthcare site=headquarters
カスタマイズ・クラスを作成したら、別個のプロジェクトに配置します。これにより、これらをJARにデプロイし、JARをカスタマイズ可能なアプリケーションにインポートできます。このアプローチによってモジュール性が高まり、カスタマイズ・クラスを社内の複数のアプリケーションに容易に組み込み、一元的にパッチを適用できます。このアプローチの詳細は、「カスタマイズ・クラスの使用方法」を参照してください。
また、1つのアプリケーションのみで使用するカスタマイズ・クラスを作成している場合、単純にJDeveloperからアプリケーションをローカルで実行する場合またはMDS構成を使用してリモートにデプロイする場合、カスタマイズ・クラスをデータ・モデル・プロジェクトに配置できます。
アプリケーションにカスタマイズ・クラスのコピーが1つしかないことおよびEARレベルのアプリケーション・クラス・ローダーからロードできるようにJARファイルにパッケージ化されていること、を確認してください。デフォルトでは、プロジェクトの依存性を追加すると、カスタマイズ・クラスがWARプロファイルに追加されます。これは、アプリケーションをパッケージ化してデプロイした後は正しく機能しません。デプロイ用にアプリケーションをパッケージ化する方法の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。
カスタマイズ・クラスを作成するには、次の手順を使用します。
始める前に:
カスタマイズ・クラスの機能に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ・クラスを保持するアプリケーションを開く(または作成する)必要があります。
カスタマイズ・クラスを作成するには:
これでカスタマイズ・クラスが作成されます。サンプル・コードではパッケージ名mycompanyとクラス名IndustryCCが使用されています。これらを、アプリケーションにあわせて変更する必要があります。
「カスタマイズ・クラス」で説明したように、カスタマイズ・クラスではカスタマイズ・レイヤーでのメタデータ・オブジェクトの可視性、およびその結果としてのメモリー内での存続期間を指定するCacheHintが定義されます。MDSはこの情報を使用して、カスタマイズをキャッシュするかどうか、およびどこにキャッシュするかを決定します。このカスタマイズ・クラスを使用して構築されたカスタマイズ・レイヤーは、このキャッシュ・ヒントを持ちます。
次の定数は、CacheHintでサポートされる値です。
ALL_USERS - カスタマイズは特定のデプロイメントでグローバルに適用されます(条件付きではない)。この定数は、静的なカスタマイズ・レイヤーで使用されます。
MULTI_USER - カスタマイズは複数のユーザーに適用されます。
REQUEST - カスタマイズは、リクエスト期間にのみ適用されます。
USER - カスタマイズは単一ユーザーに対して、ユーザーのアプリケーション・セッション中にアクセスされるドキュメントに適用されます。(Webアプリケーションでは、アプリケーション・セッションは通常サーブレット・セッションです。)
注意:
カスタマイズ・クラスは頻繁に実行されることが多いため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。
カスタマイズ・クラスを作成後、これらを設計時に「カスタマイズ開発者」ロールでおよび実行時にアプリケーションで使用できます。アプリケーションまたはJDeveloperで使用するには、クラスを適切にパッケージ化する必要があります。
カスタマイズ・クラスの作成後、JDeveloperでカスタマイズ・クラスを使用可能にして、カスタマイズの実装時に「カスタマイズ開発者」ロールで操作中に使用できるようにする必要があります。
カスタマイズ・クラスは再利用可能コンポーネントであるため、別個のプロジェクトを作成してこれにカスタマイズ・クラスを含めて、独自のJARファイルにパッケージ化できます。その後、使用するアプリケーションにJARをインポートし、カスタマイズ・クラスをJDeveloperで使用できます。別個のプロジェクトにカスタマイズ・クラスを作成する方法の詳細は、「カスタマイズ・クラスの作成」を参照してください。JARファイルにカスタマイズ・クラスをパッケージ化する方法の詳細は、「JARへのカスタマイズ・クラスの追加」を参照してください。
注意:
使用するアプリケーションのデータ・モデル・プロジェクトでカスタマイズ・クラスを作成した場合、この手順は不要です。
次の手順を使用してアプリケーションでカスタマイズ・クラスを表示できるようにしてから、「adf-config.xmlファイルの構成方法」の説明に従って、カスタマイズ・クラスをadf-config.xmlファイルのcust-configセクションに追加します。
始める前に:
カスタマイズ・クラスをパッケージ化する方法に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、外部プロジェクトでカスタマイズ・クラスを作成します。
「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
外部プロジェクトからカスタマイズ・クラスを使用するには:
カスタマイズしたアプリケーションをパッケージ化してデプロイする際、アプリケーションのクラス・パスで、アプリケーション・レベルでカスタマイズ・クラスを使用できる必要があります。
アプリケーションのデプロイメント・プロファイルを定義する際、カスタマイズ・クラスJARファイルをEARアセンブリに追加する必要があります。また、重複を避けるために、WARプロファイルにカスタマイズ・クラスJARファイルが含まれないようにする必要があります。詳細は、「アプリケーション・レベルのEARデプロイメント・プロファイルの作成」を参照してください。
すべてのカスタマイズ可能なコンポーネントと同様に、カスタマイズ可能なメタデータ・オブジェクトのXML要素はMDSによって一意に識別できる必要があるため、NULL以外の一意の識別子を指定する必要があります。このコンポーネントの識別子を使用して、カスタマイズ・レイヤー内のカスタマイズ指示の要素を参照します。IDプロパティは、ADF Faces .jspxまたは.jsffファイルの各タイプのコンポーネントの識別子です。
JSFページとJSPページでカスタマイズを可能にするには、ページの一部のデフォルト設定を受け入れずに、アプリケーションのユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効にする必要があります。これは、モデル・プロジェクトとコントローラ・プロジェクトでは不要です。
注意:
MDSでは、カスタマイズするにはこれらのページがXMLベースである必要があります。このため、.jspファイルではカスタマイズできません。かわりに.jspxファイルを使用してください。
さらに、Faceletファイルには、カスタマイズを可能にするために拡張子.jsfを付ける必要があります。MDSではこの拡張子を使用して、そのファイルをFaceletsファイルとして認識します。
始める前に:
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効にするには:
プロジェクトに前のバージョンのJDeveloperで作成されたページがある場合、これらの既存のページでもシード・カスタマイズを有効にする必要があります。これは、アプリケーションを前のバージョンのJDeveloperから移行して、移行中にIDを生成していない場合にのみ必要です。
始める前に:
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
既存のページでシード・カスタマイズを有効にするには:
監査プロファイルを作成して、ページのすべてのXMLオブジェクトにIDトークンを実装します。
メイン・メニューから、「ツール」→「プリファレンス」を選択します。
「プリファレンス」ダイアログで、「監査」→「プロファイル」を選択します。
「プロファイル」ページで、「ルール」をクリックして、すべてのルールを選択解除します。
アプリケーション開発→「ADF Faces」→「コンポーネントIDルール」の順に開きます。
ルール「ADF Facesが存在する場合、IDをチェックします」を選択します。
「デフォルト修正」ドロップダウン・リストで、「一意のIDの生成」を選択します。
「名前を付けて保存」をクリックし、プロファイルに識別可能な名前(「一意のIDの生成」など)を入力して「保存」をクリックします。
「OK」をクリックして「プリファレンス」ダイアログを閉じます。
「アプリケーション」ウィンドウで、シード・カスタマイズを有効にするページを選択します。プロジェクトを選択して、そのプロジェクトに含まれるすべてのファイルに対して監査を実行することもできます。
メイン・メニューから「ビルド」→「監査」を選択します。
「監査」ダイアログで、作成したプロファイルを選択してIDを生成し、「実行」をクリックします。
ログ・ウィンドウを使用して問題を確認し、修正を適用します。
監査が完了したら、変更内容を保存します。
カスタマイズの実装時に新しいリソース・キーを作成する予定がある場合、「アプリケーション・プロパティ」ダイアログを使用して影響を受けるリソース・バンドルを指定できます。
始める前に:
シード・カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
また、Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズ可能にするアプリケーションを開く必要もあります。
リソース・バンドルでカスタマイズを有効にするには:
アプリケーションのadf-config.xmlファイルでは、mds-configセクションで適切なcust-config要素が指定されている必要があります。クライアントはcust-config要素を使用して、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを定義できます。adf-config.xmlファイルの概要エディタを使用して、カスタマイズ・クラスを追加します(図51-3を参照)。
始める前に:
カスタマイズ・クラスを作成しパッケージ化する方法に関する知識が役立つ場合があります。詳細は、「カスタマイズ・クラス」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
adf-config.xmlファイルでカスタマイズ・クラスを識別するには:
図51-3は、2つのカスタマイズ・クラスが追加されたadf-config.xmlファイルの概要エディタを示しています。
customization-class要素の順序により、カスタマイズ・レイヤーの優先順位が指定されます。たとえば、次の例に示すコードでは、IndustryCCクラスはSiteCCクラスの前に表示されています。これは、industryレイヤーでのカスタマイズがベース・アプリケーションに適用されてから、siteレイヤーでのカスタマイズが適用されることを示します。
<adf-config xmlns="http://xmlns.oracle.com/adf/config">
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<cust-config>
<match path="/">
<customization-class name="com.mycompany.IndustryCC"/>
<customization-class name="com.mycompany.SiteCC"/>
</match>
</cust-config>
</mds-config>
</adf-mds-config>
</adf-config>
カスタマイズ可能アプリケーションを作成する際、カスタマイズしたアプリケーションの基礎として使用するために必要な部分を含むベース・アプリケーションがあります。
カスタマイズを実行するには、「アプリケーションのカスタマイズ」の説明に従って、「カスタマイズ開発者」ロールを使用してJDeveloperでアプリケーションを開く必要があります。
Oracle ADFコンポーネント(コントローラ、モデル、ビジネス・コンポーネント・オブジェクトなど)をカスタマイズするには、これらに一意の識別子を指定する必要があります。ユーザー・インタフェース・プロジェクトのJSPページとJSFページを除き、JDeveloperによって生成されるADFコンポーネントは、デフォルトでは識別子とともに作成されます。JDeveloperにユーザー・インタフェース・プロジェクトのページ上のコンポーネントの識別子を生成させるには、プロジェクト・レベルで明示的に指定する必要があります(「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」を参照)。
アプリケーションでカスタマイズを実装する前に、カスタマイズするすべてのオブジェクトに必要な識別子が指定されていることを確認します。多くの場合、監査ルールを実行し、欠落を把握して修正することができます(「既存のページでシード・カスタマイズを有効化する方法」を参照)。
また、カスタマイズ・クラスは頻繁に実行できるため(レイヤー名とレイヤー値を取得するために、アクセスされるドキュメントごとに1度)、効率性を確保するようにしてください。
カスタマイズは、Oracle JDeveloperの「カスタマイズ開発者」ロールで行われます。カスタマイズは定義されたレイヤーごとに行われ、既存のメタデータのみをカスタマイズできます。
「カスタマイズ開発者」ロールを使用して、カスタマイズ可能アプリケーションでカスタマイズを作成できます。
「カスタマイズ開発者」ロールを使用して、プロジェクトのメタデータをカスタマイズします。カスタマイズ機能は、このロールでのみ使用できます。「カスタマイズ開発者」ロールでは、次の作業を実行できます。
カスタマイズの作成および更新
カスタマイズしたアプリケーションのヒント・レイヤーの選択および編集
既存のカスタマイズの削除
「カスタマイズ開発者」ロールで作業する場合、ソース・エディタは読取り専用になり、次のJDeveloperの機能が無効になります。
ワークスペースの移行
アプリケーションおよびIDE接続の作成、削除および変更「カスタマイズ開発者」ロールでアプリケーションを開く前に、デフォルト・ロールで接続を構成する必要があります。
「カスタマイズ開発者」ロールでアプリケーションを使用する場合、新規オブジェクトは作成できず、カスタマイズ不能オブジェクトは変更できません。ただし、次のコンテンツ・タイプはカスタマイズ可能です。
ポータル・モジュール
ADFモジュール(ADF Faces、ADFモデル、ADFビジネス・コンポーネント、ADF Controllerなど)
注意:
ADFビジネス・コンポーネント・オブジェクトは、「カスタマイズ・コンテキスト」ウィンドウで静的カスタマイズ・クラスが選択されている場合のみカスタマイズ可能です。それ以外の場合、ビジネス・コンポーネント・オブジェクトは読取り専用です。
「カスタマイズ開発者」ロールで作業する場合、Javaクラス、リソース・バンドル、セキュリティ・ポリシー、デプロイメント・ディスクリプタ、構成ファイルなどのカスタマイズ不能ファイルは編集できません。「カスタマイズ開発者」ロールで作業している際、カスタマイズ不能ファイルはロック・アイコンで示されます。
注意:
Faceletファイルには、カスタマイズを可能にするために拡張子.jsfを付ける必要があります。MDSではこの拡張子を使用して、そのファイルをFaceletsファイルとして認識します。
プロジェクト設定の変更や、サービス・インタフェースやビジネス・イベント定義など特定のADFビジネス・コンポーネント機能のカスタマイズも制限されます。また、カスタマイズ不能ファイルの変更が必要になる場合は、カスタマイズ可能ファイルをリファクタまたは変更できません。
「カスタマイズ開発者」ロールでは、JDeveloperのカスタマイズ機能を使用できます。このロールで作業するには、JDeveloperの起動時に選択するか、JDeveloperがすでに実行されている場合は「ロールの切替え」メニューで「カスタマイズ開発者」ロールに切り替えます。
始める前に:
「カスタマイズ開発者」ロールの機能に関する知識が役立つ場合があります。詳細は、「「カスタマイズ開発者」ロールの概要」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
JDeveloperを起動する必要もあります。
JDeveloperで「カスタマイズ開発者」ロールに切り替えるには:
注意:
任意で「ツール」→「ロールの切替え」→「起動時にロール選択を常に要求」メニュー・アイテムを切り替え、JDeveloper起動時にロールを選択するかどうかを指定できます。この選択を解除すると、JDeveloperは、最後に閉じたときのロールで起動します。
「カスタマイズ開発者」ロールで作業する際、「カスタマイズ・コンテキスト」ウィンドウで選択したレイヤーとレイヤー値の組合せをヒント・レイヤーと呼びます。このレイヤーには、「カスタマイズ開発者」ロールで作業中に行った変更が適用されます。
注意:
「カスタマイズ開発者」ロールで作業している場合、「カスタマイズ・コンテキスト」ウィンドウが表示されない場合は、「ウィンドウ」メニューからアクセスできます。
JDeveloperのエディタに表示されるメタデータは、ベース・メタデータと(adf-config.xmlで設定された優先順位に従った)ヒント・レイヤーまでのカスタマイズ・レイヤーを組み合せたもので、各レイヤーの値は「カスタマイズ・コンテキスト」ウィンドウで指定したものです。
「カスタマイズ開発者」ロールでの作業時には、アプリケーションのカスタマイズされていない状態も確認できます。「カスタマイズ・コンテキスト」ウィンドウで「カスタマイズなしで表示」が選択されている場合、現在使用しているヒント・レイヤーはありません。したがって、表示されているのはカスタマイズされていない状態です。このビューでは、(「アプリケーション」ウィンドウの)カスタマイズ可能ファイルすべてにロック・アイコンが表示され、これらのファイルが読取り専用であることが示されます。
ヒント・レイヤーで行ったカスタマイズは、「プロパティ」ウィンドウではオレンジのアイコンで示されます。緑のアイコンは、ヒント以外のレイヤーのカスタマイズを示します。プロパティの横にオレンジのアイコンが表示されている場合、そのプロパティのドロップダウン・メニューから「カスタマイズ・アクションの削除」を選択して、そのカスタマイズを削除できます。
アプリケーションをカスタマイズするには、JDeveloperで認識できるように、CustomizationLayerValues.xmlファイルでカスタマイズ・レイヤーとその値を指定する必要があります。
カスタマイズ可能なアプリケーションを「カスタマイズ開発者」ロールで開くと、JDeveloperによりadf-config.xmlファイルが読み取られ、使用するカスタマイズ・クラスと優先順位が判別されます。また、CustomizationLayerValues.xmlファイルも読み取られ、「カスタマイズ・コンテキスト」ウィンドウで使用可能にするレイヤー値が判別されます。CustomizationLayerValues.xmlファイルで定義されたレイヤー値がカスタマイズ・クラス(adf-config.xmlファイルにリストされている)で定義されていない場合、これらは「カスタマイズ・コンテキスト」ウィンドウに表示されません。
したがって、CustomizationLayerValues.xmlファイルにすべてのカスタマイズ・プロジェクトの包括的なレイヤー値リストを含めて、現在のアプリケーションに適したもののみを「カスタマイズ・コンテキスト」ウィンドウに表示できます。逆に、アプリケーションの包括的なカスタマイズ・クラスのリストをadf-config.xmlファイルに含めて、作業するレイヤー値のサブセットのみをCustomizationLayerValues.xmlファイルに含めることもできます。
注意:
デザインタイムには、JDeveloperはCustomizationLayerValues.xmlファイルからカスタマイズ・レイヤー値を取得します。しかし、実行時には、レイヤー値はカスタマイズ・クラスから取得されます。
CustomizationLayerValues.xmlファイルに入力するレイヤー名およびレイヤー値は、カスタマイズ・クラスで指定されたものと一致する必要があります。次の例は、サンプルのCustomizationLayerValues.xmlファイルの内容を示しています。
<cust-layers xmlns="http://xmlns.oracle.com/mds/dt">
<cust-layer name="industry" id-prefix="i">
<cust-layer-value value="financial" display-name="Financial" id-prefix="f"/>
<cust-layer-value value="healthcare" display-name="Healthcare" id-prefix="h"/>
</cust-layer>
<cust-layer name="site" id-prefix="s">
<cust-layer-value value="headquarters" display-name="HQ" id-prefix="hq"/>
<cust-layer-value value="remoteoffices" display-name="Remote" id-prefix="rm"/>
</cust-layer>
</cust-layers>
各レイヤーとレイヤー値に、id-prefixトークンを追加できます。これにより、idの一意性を確保し、カスタマイズを正確に適用できます。カスタマイズ中に新規要素(コマンド・ボタンなど)をページに追加すると、(選択したヒント・レイヤーで決定された)レイヤーとレイヤー値のid-prefixが要素の自動生成識別子に追加され、カスタマイズ・メタデータ・ファイルで新たに追加された要素のidが作成されます。前述の例では、siteレイヤーにsというid-prefixが付けられ、headquartersレイヤー値にhqというid-prefixが付けられています。したがって、ヒント・レイヤーとしてsite/headquartersを選択して、コマンド・ボタンをページに追加すると、メタデータ・カスタマイズ・ファイルでコマンド・ボタンにshqcb1というidが設定されます。
各レイヤー値にdisplay-nameトークンを追加して、レイヤー値に人間が判読可能な名前を指定することもできます。「カスタマイズ開発者」ロールで作業する際、そのレイヤー値のdisplay-nameトークンの値が「カスタマイズ・コンテキスト」ウィンドウに表示されます。
レイヤーごとに、カスタマイズ・レイヤーに対する値セットのサイズを定義するvalue-set-sizeトークンを、オプションで設定できます。これは、たとえば、設計時にアプリケーション固有のCustomizationLayerValues.xmlファイルを使用する場合などに役立ちます。value-set-sizeを"no_values"に設定することで、設計時に実行時のみのレイヤーを除外できます。
<cust-layer name="runtime_only_layer" value-set-size="no_values"/>
カスタマイズ・レイヤー値はJDeveloper用にグローバルにまたはアプリケーション固有ファイルで定義できます。アプリケーション固有ファイルを使用する場合、このファイルはグローバル・ファイルより優先されます。JDeveloperのレイヤー値をグローバルに構成する方法の詳細は、「レイヤー値をグローバルに構成」を参照してください。アプリケーション固有のレイヤー値を構成する方法の詳細は、「Studio開発者ロールでのワークスペースレベルのレイヤー値の構成」を参照してください。
JDeveloper用にCustomizationLayerValues.xmlファイルをグローバルに構成する手順は、次のとおりです。
始める前に:
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
JDeveloper用にデザインタイム・カスタマイズ・レイヤー値をグローバルに構成するには:
アプリケーションのレイヤー値を構成する場合Studio開発者ロールまたは「カスタマイズ開発者」ロールのいずれかを使用できます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルのMDS DTノードの下にあります。
次に、Studio開発者ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。この手順は、「カスタマイズ開発者」ロールでも使用できます。
始める前に:
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
Studio開発者ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
Studio開発者ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
「カスタマイズ開発者」ロールでアプリケーションのレイヤー値を構成することもできます。アプリケーション固有のCustomizationLayerValues.xmlファイルを構成する場合、レイヤー値を作成および変更できますが、追加のカスタマイズ・レイヤーを作成できません。アプリケーション固有のレイヤー値に対して行った変更を適用するためにJDeveloperを再起動する必要はありません。
アプリケーション固有のCustomizationLayerValues.xmlファイルを作成すると、JDeveloperはこのファイルをアプリケーションレベルのディレクトリに格納します(workspace-directory\.mds\dt\customizationLayerValues\CustomizationLayerValues.xmlなど)。このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルのMDS DTノードの下にあります。
次に、「カスタマイズ開発者」ロールで特定アプリケーションのCustomizationLayerValues.xmlファイルを構成する手順について説明します。
始める前に:
レイヤーおよびレイヤー値について理解しておくと役に立つことがあります。詳細は、「カスタマイズ・レイヤーの構成方法」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
「カスタマイズ開発者」ロールからワークスペース・レベルでデザインタイム・カスタマイズ・レイヤー値を構成するには:
ベース・アプリケーションの開発時と同じ開発手順および開発手法を使用して、メタデータをカスタマイズします。ただし、カスタマイズを実装するには、メタデータを編集する前に、「カスタマイズ開発者」ロールを使用し、ヒント・レイヤーとレイヤー値を選択してカスタマイズ・コンテキストを指定する必要があります。カスタマイズ可能にできるアプリケーションに対して、プロジェクトでカスタマイズを有効にする必要があります。詳細は、「カスタマイズ可能なアプリケーションの開発」を参照してください。
始める前に:
カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
「adf-config.xmlファイルの構成方法」の説明に従って、adf-config.xmlファイルを更新します。
「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」および「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。
「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
JDeveloperでメタデータをカスタマイズするには:
図51-4に示すように、(「カスタマイズ・コンテキスト」ウィンドウの下部に表示される)「カスタマイズ・コンテキスト」が選択内容を反映して変更されます。
図51-4 site/headquartersがヒント・レイヤーとして選択された「カスタマイズ・コンテキスト」ウィンドウ
注意:
「カスタマイズ・コンテキスト」ウィンドウで選択された内容は、JDeveloperに実装するカスタマイズのコンテキストを示します。この選択内容が、アプリケーションの実行時に直接影響を及ぼすことはありません。実行時には、カスタマイズ・クラスからカスタマイズ・コンテキストが戻されます。詳細は、「カスタマイズ・クラスの作成方法」を参照してください。
カスタマイズの完了後、カスタマイズしたアプリケーションを実行してテストできます。
アプリケーションでカスタマイズを実装する場合、JDeveloperによりカスタマイズ用のメタデータ・ファイルとこれらを格納するサブパッケージが作成されます。
メタデータ・ファイルにはカスタマイズしたオブジェクトのカスタマイズが含まれ、これらは実行時にベース・メタデータに適用されます。新しいメタデータ・ファイルには、オブジェクトのベース・ファイルと同じ名前が付けられ、拡張子.xmlが付加されます。たとえば、browseOrders.jsffページのカスタマイズを実装する場合、カスタマイズ・メタデータ・ファイルの名前はbrowseOrders.jsff.xmlになります。また、OrderItemsエンティティ・オブジェクトにカスタマイズを実装する場合は、ベース・メタデータ・ファイルの名前はOrderItems.xmlになり、カスタマイズ・メタデータ・ファイルの名前はOrderItems.xml.xmlになります。
カスタマイズ・メタデータ・ファイルは、カスタマイズするオブジェクトと同じレベルで作成されたサブパッケージ階層に格納されます。第1レベルのパッケージ名はmdssysで、custという名前のパッケージが含まれます。custパッケージには、カスタマイズを実装した各カスタマイズ・レイヤーのパッケージが含まれます。
たとえば、エンティティ・オブジェクトを含むoracle.summit.model.entitiesというパッケージを持つベース・アプリケーションがあり、headquartersとremoteofficesの2つのレイヤー値を持つsiteという名前のカスタマイズ・レイヤーがあるとします。その後、headquartersレイヤー値でOrderItemsエンティティ・オブジェクトにカスタマイズを実装します。これらのカスタマイズを実装する場合、JDeveloperによりサブパッケージ階層oracle.summit.model.entities.mdssys.cust.site.headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。
同様にユーザー・インタフェース・プロジェクトのページ用に、ディレクトリ構造が作成されてカスタマイズ・メタデータ・ファイルが格納されます。たとえば、ユーザー・インタフェース・プロジェクトの「Webコンテンツ」ノードのBrowseOrders.jsffページをカスタマイズする場合、JDeveloperにより「Webコンテンツ」の下にディレクトリ構造mdssys/cust/site/headquartersが作成され、ここにカスタマイズ・メタデータ・ファイルが格納されます。
「カスタマイズ開発者」ロールでは、JDeveloperを使用してADFライブラリのアーティファクトをカスタマイズできます。これが必要になるのは、たとえば、ある開発チームがフレームワーク・サービスの一部としてタスク・フローを作成し、これを他のチームがADFライブラリとして使用できるようにする場合です。その後、他の開発チームがいずれかのタスク・フローを使用アプリケーションで使用して、アプリケーションの要件にあわせて調整する必要が生じます。
ADFライブラリのプロジェクトへの追加は、Studio開発者ロールで実行するのと同様に「カスタマイズ開発者」ロールで実行できます。ただし、 「カスタマイズ開発者」ロールでは、ADFライブラリのコンテンツは編集可能でカスタマイズを実装できるのに対し、Studio開発者ロールでは読取り専用になります。ADFライブラリの使用の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。
始める前に:
カスタマイズの動作方法に関する知識が役立つ場合があります。詳細は、「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ・クラスの作成」の説明に従って、カスタマイズ・クラスを作成します。
「JARへのカスタマイズ・クラスの追加」に記載されている手順でJARを作成します。
「設計時にJDeveloperでカスタマイズ・クラスを使用可能にする」の説明に従って、クラスをJDeveloperで使用できるようにします。
「adf-config.xmlファイルの構成方法」の説明に従って、adf-config.xmlファイルを更新します。
「ユーザー・インタフェース・プロジェクトでシード・カスタマイズを有効化する方法」および「既存のページでシード・カスタマイズを有効化する方法」の説明に従って、アプリケーションでシード・カスタマイズを有効化します。
「カスタマイズ・レイヤーの構成方法」の説明に従って、アプリケーション・カスタマイズ・レイヤーを構成します。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズするアプリケーションを開きます。
ADFライブラリ・アーティファクトをカスタマイズするには:
ADFライブラリのカスタマイズが保存される場所は、デフォルトではproject-dir\libraryCustomizationsです。ワークスペースに複数のプロジェクトが含まれる場合、この場所を各プロジェクトのワークスペースレベルの場所に変更する必要があります(workspace-dir\.mds\ADFLibraryCustomizationsなど)。
ADFライブラリのカスタマイズの場所は、「プロジェクト・プロパティ」ダイアログの「プロジェクトのソースパス」→「ADFライブラリのカスタマイズ」ページで変更できます。ADFライブラリでカスタマイズを実装後にこの場所を変更する場合は、カスタマイズ・メタデータ・ファイルを新しい場所に移動する必要があります。そのためには、ファイル・システムを使用してカスタマイズ・メタデータ(XML)ファイルを古いディレクトリから新しいディレクトリに移動します。
ワークスペースに、共通の場所に移動する必要がある既存のADFライブラリのカスタマイズを持つプロジェクトが複数存在する場合は、一度に1つのプロジェクトずつカスタマイズを新しい場所に移動します。プロジェクトごとに、「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更してから、カスタマイズ・メタデータ・ファイルを古い場所から新しい場所に移動します。複数のプロジェクトでADFライブラリ・アーティファクトにカスタマイズがある場合の競合を緩和するために、次のオプションが用意されています。
両方のプロジェクトで、カスタマイズが競合しているADFライブラリ・アーティファクトを開き、どちらが必要なカスタマイズかを決定します。保持するカスタマイズを残して、もう一方は削除します。
両方のカスタマイズが重要である場合は、最初のプロジェクトでADFライブラリ・アーティファクトを開き、前に2つめのプロジェクトで行われたカスタマイズを実装します。その後、最初のプロジェクトでカスタマイズを保存して、2つめのプロジェクトからカスタマイズを削除します。
複数のプロジェクトのADFライブラリ・カスタマイズ・メタデータ・ファイルをテキスト・エディタで開いて、そのコンテンツをマージすることはできません。これを行うと、カスタマイズ・メタデータ・ファイルが破損する可能性があります。
また、MARデプロイメント・プロファイルを作成すると、ADFライブラリのカスタマイズが保存されている場所が自動的に含められます。また、MARプロファイルの作成後にこの場所を変更する場合は、パッケージ化する前に、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの「ユーザー・メタデータ」ファイル・グループ・ページにあるコントリビュータ・リストで、対応するエントリを変更する必要があります。または、MARプロファイルを再作成して、この変更を取得することも可能です。MARデプロイメント・プロファイルの作成の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。
JDeveloperの「カスタマイズ開発者」ロールで作業している場合、エクスポートしたJARに含まれるADFライブラリ・アーティファクトに実装されたランタイム・カスタマイズを表示できます。
始める前に:
カスタマイズの動作方法に関する知識が役立つ場合があります。「カスタマイズおよびレイヤーのユースケースおよび例」および「アプリケーションのカスタマイズ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ可能なアプリケーションの開発」の説明に従って、カスタマイズ可能なアプリケーションを作成します。
アプリケーションをデプロイし、ランタイム・カスタマイズをこれに実装し、ランタイム・カスタマイズをJARファイルにエクスポートします。
「カスタマイズ開発者」ロールを使用してJDeveloperを起動し、カスタマイズ可能なアプリケーションを開きます。
ランタイム・カスタマイズをJDeveloperで表示できるようにするには:
これで、JARが使用可能になり、JDeveloperはADFライブラリ・アーティファクトのカスタマイズを検索できます。ADFライブラリ・アーティファクトを含むオブジェクトを開くと、JDeveloperはこのJARファイルでカスタマイズを検索し、必要に応じて表示します。JDeveloperは特定のカスタマイズ・コンテキストで特定のアーティファクトについて表示する内容を、次のように決定します。
アーティファクトにランタイム・カスタマイズもシード・カスタマイズも関連付けられていない場合、ADFライブラリのアーティファクトが表示されます。
アーティファクトにランタイム・カスタマイズまたはシード・カスタマイズのいずれかのみが関連付けられている場合、カスタマイズされたアーティファクトが表示されます。
アーティファクトにランタイム・カスタマイズとシード・カスタマイズの両方が関連付けられている場合、シード・カスタマイズが優先されて表示されます。
また、アプリケーションをJDeveloperからローカルに実行する場合は、ランタイム・カスタマイズが表示されます。ただし、ランタイム・カスタマイズはアプリケーションのデプロイメント用のパッケージには含められません。
エンタープライズ・アプリケーションを開発する際、複数のアプリケーションで再利用可能なアーティファクト(タスク・フローなど)が存在することがあります。再利用しやすいように、これらの共通アーティファクトをADFライブラリにパッケージ化して配布できます。これにより、使用アプリケーションが依存するライブラリ・リストにADFライブラリを追加できます。アプリケーションがパッケージ化されると、追加したすべてのADFライブラリのカスタマイズがMARに含められ、その後、MDSリポジトリにデプロイされます。ただし、そのADFライブラリのカスタマイズは、プロファイルの作成時にMARデプロイメント・プロファイルに追加されており、これは、プロファイルの作成後にカスタマイズを実装する際には自動更新されません。こうした後続のカスタマイズを適用するには、「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの「MARオプション」ページにある「プロファイルの更新」ボタンを使用します。
注意:
ADFライブラリ・プロバイダは、ライブラリのカスタマイズを原因とする名前の競合がないことを確認する必要があります。ADFライブラリにパッケージ化されたカスタマイズと使用プロジェクトのカスタマイズとの間で名前の競合が発生した場合、ADFライブラリのカスタマイズは無視されます。
ADFライブラリのオブジェクトにカスタマイズを実装すると、デフォルトでは、カスタマイズ・メタデータはlibraryCustomizationsというプロジェクトのサブディレクトリに格納されます。また、プロジェクト・レベルでADFライブラリのカスタマイズを作成しても、これらは実行時にアプリケーションで使用できるように、パッケージ化される際に一緒にマージされます。基本的に、ADFライブラリはプロジェクト・レベルで追加されるJARであり、プロジェクト・レベルで作成されるライブラリ・カスタマイズにマップされます。ただし、プロジェクトは実行時にWebアプリケーションにマップされますが、MAR(ライブラリのカスタマイズを含む)はEARレベルにあるため、すべてのWebアプリケーションからライブラリのカスタマイズを確認できます。
したがって、ある特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーおよびレイヤー値)では、アプリケーションの1箇所でしかADFライブラリ・アーティファクトをカスタマイズできません。同一ライブラリ・コンテンツをカスタマイズ・コンテキストが同一の複数のプロジェクトでカスタマイズすると、MARパッケージで重複が発生します。パッケージ化の失敗の原因となる重複を回避するには、アプリケーションの1つのプロジェクトにのみ特定ライブラリのカスタマイズを実装します。
注意:
アプリケーション内のすべてのプロジェクトに対して、ADFライブラリのカスタマイズに同じ場所を使用することで、重複カスタマイズを防止できます。詳細は、「ADFライブラリのカスタマイズの場所の指定」を参照してください。
たとえば、使用中のADFライブラリにページ・フラグメントtext.jsffが含まれるとします。使用アプリケーションで、このライブラリ・ページを1つのプロジェクトでのみカスタマイズします。これにより、実行時にこのライブラリを使用するアプリケーションのすべてのプロジェクトで、カスタマイズが使用可能になります。
プロジェクトに同じ名前のオブジェクトがすでに含まれる場合、ADFライブラリのオブジェクトをカスタマイズすることも制限されます。重複する場合は、重複するドキュメントの1つを削除するか、削除してから差異をもう一方に手動でマージして、プロジェクトを修正する必要があります。
同様に、ADFライブラリに特定のカスタマイズ・コンテキスト(カスタマイズ・レイヤーとレイヤー値)のアーティファクトのシード・カスタマイズが含まれる場合、同じカスタマイズ・コンテキストでそのアーティファクトにカスタマイズを実装することはできません。この場合、ADFライブラリ・アーティファクトは読取り専用になります。ただし、他のカスタマイズ・コンテキストでアーティファクトにカスタマイズを実装することはできます。
たとえば、使用中のADFライブラリに、SiteレイヤーのHeadquartersレイヤー値のシード・カスタマイズが含まれるとします。「カスタマイズ・コンテキスト」ウィンドウでこれをヒント・レイヤーとして選択すると、そのADFライブラリのカスタマイズ済オブジェクトは読取り専用になります。ただし、Site/Remote Site 1をヒント・レイヤーとして選択すると、オブジェクトはカスタマイズ可能になります。
注意:
使用アプリケーションでADFライブラリのコンテンツに対するカスタマイズが実装されると、カスタマイズはローカル・プロジェクトのディレクトリには書き込まれますが、パッケージ化する際にweb-app-rootで自動的に挿入されることはありません。詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。
実行時に、アプリケーションではadf-config.xmlファイルのcust-configセクションで定義された優先順位に従って、カスタマイズ・メタデータ・ファイルがベース・アプリケーション全体に適用されます。
レイヤー値は実行時にカスタマイズ・クラスから取得され、アプリケーションが実行されているコンテキストで評価されて、そのレイヤー値に適したカスタマイズが適用されます。
アプリケーションをカスタマイズする場合、統合ソース・コントロールを使用したり、リソース文字列をカスタマイズすることがあります。これらの機能を使用する場合に、知っておくべき追加情報があります。
「カスタマイズ開発者」ロールでの作業時には、ソース・コントロール統合によってカスタマイズ・プロセスが補完されます。自動的にチェックアウトして新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されている場合、ソース・コントロール・システムから使用可能なベース・ドキュメントをカスタマイズしようとすると、JDeveloperは次のように動作します。
該当するカスタマイズ・ファイルがまだ使用可能でない場合、ソース・コントロールで新しいカスタマイズ・ファイルが作成されてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在する場合、チェックアウトされてカスタマイズが書き込まれます。
該当するカスタマイズ・ファイルが存在し、すでにチェックアウトされている場合、またはまだバージョン・コントロールにない場合、バージョン・コントロール操作なしでカスタマイズが書き込まれます。
ベース・ドキュメントは「カスタマイズ開発者」ロールでは変更されないため、ベース・ドキュメントはチェックアウトされません。
自動的にチェックアウトしたり新規ファイルをソース・コントロールに追加するようにJDeveloperが構成されていない場合、手動でカスタマイズ・ファイルを編集可能にして、新たに作成したカスタマイズ・ファイルをソース・コントロールにチェックインする必要があります。JDeveloperでのソース・コントロールの使用の詳細は、「ソース・コントロール・システムの使用」の項を参照してください。
アプリケーションをカスタマイズする過程で、コンテンツをカスタマイズして、別のリソース・バンドル・キーを使用したり、新しいリソース・キーを定義して使用できます。
「カスタマイズ開発者」ロールでカスタマイズ可能なアプリケーションを開き、「プロパティ」ウィンドウを使用してリソース・バンドル文字列の使用方法をカスタマイズできます。ドキュメントを変更して、リソース・バンドルにすでに存在する別のリソース・キーを使用したり、新しいリソースを作成できます。リソース・バンドルの詳細は、「リソース・バンドルの使用」を参照してください。
新しいリソース・キー(「カスタマイズ開発者」ロールで作成された)は、アプリケーション・レベルのオーバーライド・バンドルに(XLIFF形式で)保存され、JDeveloperにより次の例に示すようなエントリがadf-config.xmlファイルに追加されて、アプリケーション・レベルのオーバーライド・バンドルが構成されます。
また、ベース・リソース・バンドルのオーバーライドをサポートするように、adf-config.xmlファイルを構成する必要があります。次の例に示すように、bundleId要素をoverride="true"とともにタグ付けしてオーバーライド可能にする必要があります。オーバーライド可能に指定すると、そのバンドルのカスタマイズはアプリケーションのオーバーライド・バンドルに格納されます。
<adf-resourcebundle-config xmlns="http://xmlns.oracle.com/adf/resourcebundle/config">
<applicationBundleName>
path-to-resource-bundle/bundle-name
</applicationBundleName>
<bundleList>
<bundleId override="true">
package.BundleID
</bundleId>
</bundleList>
</adf-resourcebundle-config>
注意:
アプリケーションがカスタマイズ用に構成されていない場合、「カスタマイズ開発者」ロールでアプリケーションを開き、メイン・メニューから「アプリケーション」→「リソース・バンドルの編集」を選択して新しいリソース・キーを定義できます。ただし、カスタマイズ用に構成されていない場合、ドキュメントを変更して新しいリソース・キーを使用することはできません。
必要なカスタマイズを行った後で、ADFアプリケーションをデプロイする必要があります。カスタマイズしたメタデータはMARファイルにパッケージ化され、デプロイの準備ができています。
アプリケーションをカスタマイズしたら、そのアプリケーションをデプロイできます。カスタマイズしたアプリケーションをデプロイする前に、『Oracle Fusion Middlewareの管理』のMDSリポジトリの管理に関する項の説明に従って、MDSリポジトリを設定するための構成手順を実行する必要があります。
エンタープライズ・アプリケーションにはモデル・プロジェクトおよびユーザー・インタフェース・プロジェクトを含めることができ、どちらのタイプのプロジェクトにもカスタマイズしたメタデータを含めることができます。カスタマイズしたメタデータは、デプロイのためにMARにパッケージ化されます。デフォルトでは、どちらのタイプのプロジェクトのカスタマイズも1つのMARに追加されます。MARプロファイルの作成方法の詳細は、「MARデプロイメント・プロファイルの作成」を参照してください。
JDeveloperを使用してFusion Webアプリケーションをパッケージ化する場合、次のいずれかの条件が満たされると、デフォルト・メタデータ(カスタマイズなど)を含む自動生成MARプロファイルが作成されます。
ユーザー・インタフェース・プロジェクトの「プロジェクト・プロパティ」ダイアログの「ADFビュー設定」ページで、「ユーザー・カスタマイズの有効化」→「MDSを使用したセッション間チェック・ボックスが選択されている。
adf-config.xmlファイルのMDS構成セクションに、次の例に示すようにdeploy-target="true"とマークされている<metadata-store-usage>要素が含まれる。
< . . . >
<persistence-config>
<metadata-namespaces>
<namespace path="/oracle/apps" metadata-store-usage="repos1"/>
</metadata-namespaces>
<metadata-store-usages>
<metadata-store-usage id="repos1" deploy-target="true">
. . .
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
< . . . >
JDeveloperで作成されたカスタマイズをデプロイ時にアプリケーションで有効にするには、これらのカスタマイズを実行時にアプリケーションで使用可能にする必要があります。そのために、2つの方法を使用できます。
MARプロファイルを使用して、カスタマイズをアプリケーションとともにパッケージ化します。
カスタマイズ・メタデータを含むMARプロファイルを作成します。デプロイしたEARファイルにMARプロファイルを含めて、実行時にカスタマイズを使用できるようにします。アプリケーションレベル・クラス・ローダーに配置されるように、カスタマイズ・クラスをEARファイルにパッケージ化する必要があります。
注意:
シード・カスタマイズしかない場合は、ランタイム・カスタマイズもサポートする場合を除き、MARプロファイルを作成してMDSリポジトリにインポートする必要はありません。シード・カスタマイズがあり、セッション間の永続性が有効でない場合、シード・カスタマイズはデフォルトでEARファイルにパッケージ化され、クラス・パスからロードされます。
カスタマイズを、アプリケーションで使用されるランタイム・リポジトリにインポートします。
この方法は一般に、ライブラリ・メタデータへのカスタマイズを、別個にデプロイされたアプリケーションに適用する必要がある場合に使用します。この方法を使用してカスタマイズをJARファイルにパッケージ化し、Oracle WebLogic Scripting Tool (WLST)とともにimportMetadataコマンドを使用してMDSランタイム・リポジトリにインポートします。このコマンドやその他のWLSTコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』を参照してください。
アプリケーションにADFライブラリのオブジェクトのカスタマイズがある場合、MARプロファイルの作成時にカスタマイズ・メタデータが暗黙的に含められます。「プロジェクト・プロパティ」ダイアログでADFライブラリのカスタマイズの場所を変更する場合は、パッケージ化する前に、MARプロファイルを再作成する必要があります。
実行時のデザインタイム機能を使用して、実行時にオーバーライド・バンドルでリソース・キーを追加または編集する予定がある場合は、オーバーライド・バンドルをMARプロファイルの一部としてパッケージ化する必要があります。デフォルトでは、アプリケーションにシード・カスタマイズが含まれる場合、オーバーライド・バンドルは自動生成MARプロファイルの一部としてパッケージ化されます。ただし、アプリケーションにシード・カスタマイズが含まれない場合は、MARデプロイメント・プロファイルを明示的に作成してオーバーライド・バンドルをパッケージ化する必要があります。MARプロファイルが明示的に作成される場合、オーバーライド・バンドルはデフォルトでユーザー・メタデータの一部として追加されて含められます。
完了したカスタマイズ済アプリケーションをパッケージ化してデプロイする場合、 「カスタマイズ開発者」ロールではなくStudio開発者ロールで行う必要があります。MARプロファイルの作成方法の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。
拡張メタデータは、Fusion Webアプリケーションのカスタマイズに追加設定を提供します。拡張メタデータ・プロパティを編集し、実行時に誰がメタデータをカスタマイズできるか、またメタデータのどの部分をカスタマイズできるかを識別できます。
拡張メタデータは、メタデータのコンテンツを説明するデータです。拡張メタデータ・ファイルには、メタデータ・ファイルについての追加情報が含まれます。この拡張情報を使用する目的の1つは、実行時にメタデータのどの部分をカスタマイズできるか(実行時のデザインタイムのカスタマイズ)および誰がカスタマイズできるか識別することです。拡張メタデータ・プロパティのこの用法の詳細は、「実行時のデザインタイムのカスタマイズを有効化する方法」を参照してください。
メタデータ・ファイル(.jspxファイルなど)をJDeveloperで開き、「プロパティ」ウィンドウを使用して拡張メタデータ・プロパティを表示および編集できます。メタデータ・ファイルを開くと、「プロパティ」ウィンドウに拡張メタデータ・プロパティが表示されます。これらのプロパティを編集して、次のいずれかのレベルでメタデータ情報を追加できます。
ファイルレベル: 構造ウィンドウでルート要素が選択されている場合、「プロパティ」ウィンドウにこれらのプロパティが表示されます。
要素レベル: 構造ウィンドウで要素が選択されている場合、「プロパティ」ウィンドウにこれらのプロパティが表示されます。選択した要素は、null以外の識別子を持つ必要があります。
拡張メタデータ・プロパティは、カスタマイズをサポートし、MARにパッケージ化できるファイル・タイプ(.jsffファイルや.jspxファイルなど)に対してサポートされます。
メタデータ・ドキュメントの拡張メタデータは、関連するリソース記述フレームワーク(RDF)ファイルに格納されます。RDFは、メタデータを定義するXMLフレームワークの定義に使用されるW3C標準です。メタデータ・ドキュメントに関連付けられるRDFファイルは、「プロパティ」ウィンドウを使用して最初のプロパティ値を指定するときに作成されます。JDeveloperがStudio開発者ロールの場合にのみ、拡張メタデータ・プロパティは編集できます。「カスタマイズ開発者」ロールでは、RDFファイルは読取り専用です。
RDFファイルは、mdssysディレクトリに格納されます。たとえば、記述されるメタデータが/myapp/data/page1.jspxとしてファイル・システムに格納される場合、対応する拡張メタデータ・ドキュメントは/myapp/data/mdssys/mdx/page1.jspx.rdfとして格納されます。その後、拡張メタデータ・ドキュメントを対応するメタデータ・ベース・ファイルとともにパッケージ化して、同じデプロイメント・プロファイルに追加する必要があります。MARデプロイメント・プロファイルの作成の詳細は、「デプロイメント・プロファイルの作成方法」を参照してください。
注意:
拡張メタデータ・ドキュメントを直接編集することはできません。「プロパティ」ウィンドウを使用してください。
拡張メタデータ・プロパティを使用して、メタデータ・ファイル(.jspxファイルなど)に含まれていない追加のメタデータ情報を提供できます。JDeveloperでメタデータ・ファイルを開くと、「プロパティ」ウィンドウに拡張メタデータ・プロパティが表示されます。JDeveloperをStudio開発者ロールで使用している場合は、プロパティ・インスペクタを使用してこれらのプロパティを編集できます。
たとえば、なんらかのフォームのメタデータ・ファイルを外部の顧客に配信するとします。メタデータ・ファイルとともに、作成者、題目、内容、形式、権利などファイルに関する追加情報を提供する必要があります。メタデータ・ファイルの拡張メタデータ・プロパティ・ファイルを作成することで、これらの情報を提供できます。
始める前に:
拡張メタデータの使用方法に関する知識が役立つ場合があります。詳細は、「拡張メタデータ・プロパティ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクを完了する必要もあります。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開きます。
拡張メタデータ・プロパティを編集するには:
メタデータ・ファイルの拡張メタデータ・プロパティを編集した場合は、アプリケーションのデプロイ時に、拡張メタデータ(またはRDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
拡張メタデータ・プロパティを使用して、実行時にメタデータのどの部分をカスタマイズできるか、および誰がメタデータのコンテンツをカスタマイズできるかについての情報を提供することもできます。
デフォルトでは、.jspxページに追加できるすべてのコンポーネントは、ランタイム・カスタマイズを許可するように事前構成されており、暗黙的なユーザー・カスタマイズをサポートしています(表の列順の変更など)。
作成するすべてのページおよびフラグメントもデフォルトではカスタマイズできるように構成されます。一部のWebCenter Portalコンポーネント(panelCustomizableなど)でも、タイプ定義のカスタマイズが許可されています。ユーザー・カスタマイズの詳細は、「実行時のユーザー・カスタマイズの許可」を参照してください。WebCenter Portalコンポーネントの詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のOracle WebCenter Portalの開発の概要に関する項を参照してください。
カスタマイズできるようにコンポーネントが事前構成されている場合、さらに変更を加えて実行時のデザインタイムのカスタマイズを可能にする必要はありません。このようなコンポーネントを.jspxページで使用する場合、デフォルトでカスタマイズ可能になっています。
アプリケーションの要件に応じて、次の状況でカスタマイズ・プロパティを変更する必要があります。
カスタマイズを許可するように構成されているコンポーネントの場合、デフォルト設定をオーバーライドしてカスタマイズを禁止できます。
カスタマイズを許可するように構成されていないコンポーネントおよびメタデータ・オブジェクト(.jspxページなど)の場合、設定をオーバーライドしてカスタマイズを許可できます。
カスタマイズを許可するように構成されているコンポーネントの場合、オプションで、実行時にカスタマイズを実行できるユーザーを制限することができます。
カスタマイズ・プロパティを編集する場合は、アプリケーションのデプロイ時に、拡張メタデータ(RDF)ファイルをメタデータ・ファイルとともにパッケージ化する必要があります。
また、サブツリーのルートをカスタマイズ禁止にマーキングすることによって、コンポーネントのサブツリー全体のカスタマイズを制限できます。そのサブツリーの個別のコンポーネントにカスタマイズ可能のマークを付けて、その特定のコンポーネントのカスタマイズを許可できます。
「プロパティ」ウィンドウのカスタマイズ・グループには、実行時にオブジェクトをカスタマイズできるかどうか、および誰がカスタマイズを実行できるかを指定する2つのプロパティがあります。任意の要素にCustomizationAllowedプロパティを設定して、カスタマイズできるかどうかを指定できます。CustomizationAllowedByプロパティは、要素をカスタマイズできるユーザーを制御します。JDeveloperを使用してシード・カスタマイズを実装する場合、これらの設定は強制されませんが、実行時にアプリケーションをカスタマイズする場合は強制されます(実行時のデザインタイムのカスタマイズ)。
たとえば、2つのパネルで構成される.jspxページがあり、パネル1のコンテンツにはランタイム・カスタマイズを許可する必要があり、パネル2のコンテンツには許可する必要がないとします。パネル1ではCustomizationAllowedにtrueを設定し、パネル2ではfalseを設定します。ページ全体でランタイム・カスタマイズを許可する必要がある場合は、.jspxページ・ルートのCustomizationAllowedにtrueを設定します。
始める前に:
拡張メタデータの使用方法に関する知識が役立つ場合があります。詳細は、「拡張メタデータ・プロパティ」を参照してください。
アプリケーションに追加できる追加のカスタマイズ機能を理解することも役立つ場合があります。詳細は、「カスタマイズの追加機能」を参照してください。
次のタスクも完了する必要があります。
「カスタマイズ可能なアプリケーションの開発」の説明に従って、カスタマイズ可能なアプリケーションを作成します。
Studio開発者ロールを使用してJDeveloperを起動し、アプリケーションを開きます。
カスタマイズ・プロパティを編集するには:
任意でスタンドアロン注釈ファイルを使用して、カスタマイズを指定のタイプのコンポーネントに対して許可するかどうかを指定できます。このファイルを使用すると、インスタンスではなく要素型に基づいてカスタマイズ・プロパティを設定できます。特定のインスタンスに対して明示的にtrueまたはfalseを設定して、指定のタイプの設定をオーバーライドできます。次の例は、サンプルのスタンドアロン注釈ファイルの内容を示しています。
<?xml version="1.0" encoding="UTF-8"?>
<grammarMetadata xmlns="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:md="http://xmlns.oracle.com/bali/xml/metadata"
xmlns:mmd="http://xmlns.oracle.com/bali/xml/metadata/model"
xmlns:mds="http://xmlns.oracle.com/mds"
namespace="http://www.oracle.com/mds/restrictCustomizations">
<elementMetadata elementName="orderDetail">
<attributeMetadata attributeName="itemTypeRef">
<mds:customizationAllowedBy>sales admin</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="description">
<mds:customizationAllowed>true</mds:customizationAllowed>
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
<attributeMetadata attributeName="title">
<mds:customizationAllowed>true</mds:customizationAllowed>
</attributeMetadata>
</elementMetadata>
<elementMetadata elementName="bankTransfer">
<mds:customizationAllowed>false</mds:customizationAllowed>
</elementMetadata>
<elementMetadata elementName="order">
<mds:customizationAllowed>true</mds:customizationAllowed>
<attributeMetadata attributeName="paymentRef">
<mds:customizationAllowedBy>sales</mds:customizationAllowedBy>
</attributeMetadata>
<elementMetadata elementName="itemDetail">
<attributeMetadata attributeName="itemsRef">
<mds:customizationAllowedBy>hr</mds:customizationAllowedBy>
</attributeMetadata>
</elementMetadata>
</elementMetadata>
</grammarMetadata>
スタンドアロン注釈ファイルを使用する場合、これをadf-config.xmlファイルのMDSに登録する必要があります。次の例に示すように、adf-config.xmlファイルのmdsc:type-configセクションにmdsc:standalone-definitionsセクションを作成します。
<?xml version="1.0"?>
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:mdsc="http://xmlns.oracle.com/mds/config">
<mdsdata>
<mdsc:mds-config version="11.1.1.000" >
<mdsc:type-config>
<mdsc:type-definitions>
<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>
<mdsc:mds>/oracle/mds/TypeSeven.xml</mdsc:mds>
<mdsc:mds>/oracle/mds/TypeEight.xml</mdsc:mds>
<mdsc:file>typefile7.xsd</mdsc:file>
<mdsc:file>typefile8.xsd</mdsc:file>
</mdsc:type-definitions>
<mdsc:standalone-definitions>
<mdsc:url>jar:file:/c:/jdev/lib/oafwk.jar!/oracle/apps/schemas/oa.xsd</mdsc:url>
<mdsc:mds>/oracle/mds/standAloneSeven.xml</mdsc:mds><mdsc:mds>/oracle/mds/standAloneEight.xml</mdsc:mds><mdsc:file>standAloneFile7.xsd</mdsc:file><mdsc:file>standAloneFile8.xsd</mdsc:file></mdsc:standalone-definitions></mdsc:type-config> .... </mdsc:mds-config> </mdsdata> </adf-config>
特定のセッションに対して、実行時にカスタマイズされた構成に変更を加えることができます。
カスタマイズしたアプリケーションで実行時にセッションごとにカスタマイズ構成(adf-config.xmlファイルのcust-configセクション)をオーバーライドできるようして、特定のセッション(またはWebリクエスト)にカスタマイズを適用する方法をユーザーが変更できるようにすることができます。
アプリケーションがsiteレイヤーとuserレイヤーで構成されていて、siteレイヤーに実行時のデザインタイムのカスタマイズを行うシナリオを考えてみます。アプリケーションのカスタマイズ構成(adf-config.xmlファイルで定義された)を使用する場合、実装するカスタマイズはすべてuserレイヤーに適用されます。このため、特定のセッションのカスタマイズ構成を調整して、カスタマイズをsiteレイヤーに適用できる必要があります。
または、管理者がsiteレイヤーのカスタマイズのみを持つベース・メタデータ・ドキュメントを確認できる必要があるとします。このような場合、アプリケーションのadf-config.xmlファイルで元々指定されている以外の、変更済のカスタマイズ構成を指定する必要があります。
Webリクエストごとに、Oracle ADFはMDSセッションを作成します。セッション(Webリクエスト)に適用するMDSカスタマイズ構成変更に対して、新しいカスタマイズ構成の変更済MDSセッション・オプションをOracle ADFにプログラムで提供できます。これは、MDSセッションの作成時に、元のMDS構成の上に適用されます。
この機能を実装するには、sessionOptionsFactoryの次のADFインタフェースを使用します。
oracle.adf.share.mds.SessionOptionsFactoryは、Fusion WebアプリケーションでWebリクエストの変更済MDSセッション・オプションを指定するためのインタフェースです。
SessionOptionsFactory :: oracle.mds.core.SessionOptions createSessionOptions(oracle.mds.core.SessionOptions defaultOptions)
このメソッドを実装すると、変更済MDS sessionOptionsがADFに戻されます。
oracle.adf.share.config.ConfigUtilsは、セッション・オプション・ファクトリをADFに登録するためのパブリック・クラスです。
ConfigUtils :: public static void setSessionOptionsFactory(ADFContext context, SessionOptionsFactory factory)
これらのインタフェースの詳細は、ADF APIドキュメントを参照してください。
注意:
Oracle WebCenter Portalのコンポーザ・コンポーネントを使用している場合、ComposerSessionOptionsFactoryインタフェースを使用して、Oracle WebCenter Portalのコンポーザの変更済MDSセッション・オプションを指定できます。
ComposerSessionOptionsFactory :: public SessionOptions createSessionOptions(SessionOptions defaultOptions, String mode);
oracle.adf.view.page.editor.webapp.WebCenterComposerFilterは、ComposerSessionOptionsFactory実装を現在のスレッド・コンテキストのクラス・ローダーからロードします。
sessionOptionsFactoryをOracle ADFに登録して、リクエストのライフサイクルでMDSセッションが作成される前に、ADFが実装から変更済セッション・オプションを取得できるようにします。
または、フィルタ実装でsessionOptionsFactoryをOracle WebCenter Portalのコンポーザに登録できます。
次の例は、sessionOptionsFactoryの実装方法を示しています。この例では、adf-config.xmlファイルで指定されたカスタマイズ構成に関係なく、siteカスタマイズ・レイヤーのみを使用する変更済カスタマイズ構成をセッションに設定します。詳細は、oracle.mdsのJavadocを参照してください。
package mycompany;
import oracle.adf.share.mds.SessionOptionsFactory;
import oracle.mds.config.CustClassListMapping;
import oracle.mds.config.CustConfig;
import oracle.mds.config.MDSConfigurationException;
import oracle.mds.core.SessionOptions;
import oracle.mds.cust.CustClassList;
import oracle.mds.cust.CustomizationClass;
public class MySessionOptionsFactory implements SessionOptionsFactory {
public MySessionOptionsFactory() {
super();
}
/**
* Called to allow the application code to create a new SessionOptions object.
* The application code should make sure to read the values from the
* defaultOptions object as part of contruction of their new object and make
* sure they only override the intended values.
* @param defaultOptions
* @return modified MDS session options
*/
public SessionOptions createSessionOptions(SessionOptions defaultOptions) {
// create new mds Customization configuration
CustConfig custconfig = null;
// create customization class array. Just put SiteCC implementation as we
// wish to apply site customizations alone.
CustomizationClass[] custclassarray = new CustomizationClass[] {new SiteCC()};
CustClassList custclasslist = new CustClassList(custclassarray);
// specify the base metdata package namespace mapping on which site
// customizations would apply
CustClassListMapping[] mappings =
new CustClassListMapping[] {new CustClassListMapping("mycompany/package",
null, null, custclasslist)};
// create new customization configuration
try{
custconfig = new CustConfig(mappings);
}
catch (Exception ex){
//do nothing
}
// now return modified sessionOptions to ADF with new mds customization
// configuration. Only use newly created customization configuration in here.
// For rest of option, use whatever available in defaultOptions.
return new SessionOptions(defaultOptions.getIsolationLevel(),
defaultOptions.getLocale(),
custconfig,
defaultOptions.getVersionContext(),
defaultOptions.getVersionCreatorName(),
defaultOptions.getCustomizationPolicy(),
defaultOptions.getServletContextAsObject());
}
}
