| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.2.0) E82735-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.2.0) E82735-01 |
|
|
前 |
次 |
この章のトピックは、次のとおりです:
ほとんどの業界では、様々な顧客および分野で役に立つようにエンタープライズ・アプリケーションをカスタマイズします。サイトレベルでアプリケーションを変更すると問題が発生する可能性があります。たとえば、アプリケーション・レベルのカスタマイズでアプリケーションをアップグレードすると、データの損失またはデータ・マージ・エラーが発生する場合があります。結果として、すべてのマージ競合を解決するまで新しいバージョンのアプリケーションをデプロイできません。
メタデータ・ドメインでは、MDSにこのような問題に対処するカスタマイズ機能が用意されています。このカスタマイズ機能を使用すると、ベースのアプリケーション定義の上に適用される、元の状態に干渉しないカスタマイズ・レイヤーを作成できます。カスタマイズ・レイヤー(またはレイヤー化された変更)は、独自のドキュメントに記述され、ベースのアプリケーション定義から隔離されて格納されます。実行時、適用可能なカスタマイズは、メタデータ・ストアからロードされ、ベースのメタデータ定義の上にレイヤー化され、目的の効果を実現します。製品のアップグレードおよびパッチは、ベースのメタデータ定義にのみ影響するため、カスタマイズは正しい動作を継続します。
カスタマイズ・レイヤー
MDSでは、クライアントは複数のカスタマイズ・タイプを指定できます。たとえば、カスタマイズを実行時モード、アプリケーション・ロール、ユーザー・ロール、アプリケーションの状態またはクライアント指定の条件に追加できます。このようなカスタマイズ・タイプそれぞれは、カスタマイズ・レイヤーと呼ばれ、CustomizationClassを使用して描写されます。CustomizationClassはインタフェースMDSで、ベース定義でオーバーレイされるカスタマイズ・レイヤーを特定するために使用されます。たとえば、アプリケーションを構成して、ユーザーが属している部門に基づいてカスタマイズを保存できます。DepartmentCCというカスタマイズ・レイヤーを作成でき、そこで異なる部門のユーザーによって行われたアプリケーションのカスタマイズは、レイヤー内の異なるフォルダに格納されます。その他の例は、MDSを構成して表示モードの変更をユーザー・カスタマイズとしてあるレイヤーで保存し、編集モードの変更をアプリケーション・カスタマイズとして別のレイヤーで保存する場合(またはこの逆)です。
カスタマイズ・レイヤーは、優先順位の順番で適用されます。つまり、同じ変更が、指定のユーザーおよびセッションに適用される2つの異なるレイヤーで行われた場合、高い優先順位のレイヤーで定義された変更がまず適用されます。
CustomizationClassを実装する場合、これをMDSで登録する必要があります。MDSには、CustomizationClassタイプのリストを単一のMetadataObjectと関連付ける方法が用意されています。これは、ファイングレイン関連付けと呼ばれます。MDSには、CustomizationClassタイプのリストを一連のMetadataObjectsと関連付ける方法も用意されています。これは粗密な関連付けと呼ばれます。CustomizationClassおよびカスタマイズ・レイヤーの作成の詳細は、「カスタマイズ・レイヤーの表示モードおよび編集モードへの追加: 例」を参照してください。
コンポーザのサンドボックス
通常、Frameworkアプリケーションでは、実行時カスタマイズはJDEV_HOME/jdev/system_directory/o.mds.dt/adrs/application_name/AutoGeneratedMar/mds_adrs_writedirディレクトリにすぐに保存されます。表示モードと編集モードの両方で行われた変更はこの方法で保存されます。ただし、特定の状況では、ユーザーは、変更をバック・エンドに実際に保存する前に、まず独自のビューでカスタマイズを適用してその変更を保持するか取り消すかを評価する必要がある場合があります。データベース・リポジトリを使用してカスタマイズを格納する場合は、コンポーザを構成してサンドボックスを作成できます。サンドボックスの作成の詳細は、「コンポーザのサンドボックスの使用」を参照してください。
サンドボックスは、実行時のページ・カスタマイズをバック・エンドにコミットするまで保存する一時ストレージ・レイヤーです。サンドボックスを構成すると、コンポーザのツールバーに「保存」ボタンが表示され、ユーザーは変更を保存できます。サンドボックス対応のアプリケーションでは、ユーザーが変更の保存前に「閉じる」をクリックすると、クローズ確認ダイアログによって、コンポーザを終了する前に変更を保存するか、取り消すかの確認を求められます。
表示モードで行われたユーザー・カスタマイズはすぐに保存されます。このような変更はページを変更したユーザーに対してのみ使用可能であるため、保存する前に変更を確認する特定の値はありません。
編集モードのカスタマイズはページにアクセスするすべてのユーザーが使用できるため、サンドボックスを有効にして、変更をコミットする前にユーザーがページ・カスタマイズを確認し、これを評価できます。アプリケーションでサンドボックスを有効にした場合、ページの編集モードでコンポーザのツールバーに「保存」ボタンが表示されます。
この項では、サンドボックスの作成を有効にする手順およびサンドボックス対応アプリケーションの実行時の動作を説明します。次のサブセクションが含まれます:
アプリケーションがデータベース・ストアを使用している場合のみサンドボックスを有効にできます。したがって、この項の手順を実行する前にデータベース・ストアが構成されていることを確認する必要があります。Oracle RACデータ・ソースの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理』の概要とロードマップに関する項を参照してください。
この項では、コンポーザのサンドボックスの作成を有効にする方法を説明します。次のサブセクションが含まれます:
デフォルトでは、サンドボックスの作成は、(adf-config.xmlファイルの<mds-config>セクションで定義された)デフォルトのカスタマイズ・ストアにマップされたすべてのネームスペースに対して有効になっています。ただし、選択した数のネームスペースに対してのみサンドボックスを有効にできます。これを行うには、<pe:sandbox-namespaces>要素をadf-config.xmlファイルに追加してから、サンドボックスの作成をサポートするネームスペースを定義する必要があります。
注意:
adf-config.xmlで設定できるコンポーザ固有の構成の詳細は、「adf-config.xml」を参照してください。
adf-config.xmlでサンドボックスの作成を構成するには:
例28-1 adf-config.xmlファイルでのメタデータ・ストア構成
<metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jdbc-userid" value="userone"/>
<property name="jdbc-password" value="userone123"/>
<property name="jdbc-url" value="jdbc:oracle:thin:@host_name:1521:orcl"/>
<property name="partition-name" value="partitionName"/>
</metadata-store>
<!-- <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
<property name="metadata-path" value="C:\JDeveloper\mywork\Application2\ViewController\public_html"/>
</metadata-store> -->
ページの編集モードからサンドボックスが構成されたことを確認するには、アプリケーションのweb.xmlファイルでフィルタを作成し、適切なフィルタ・マッピングを設定する必要があります。すべてのリクエストがこのフィルタを通るようにルーティングされ、サンドボックスがすべての編集モードのカスタマイズに対して作成されます。ファイル・システムのメタデータ・ストアを使用している場合、フィルタされたリクエストに対して実行される処理はありません。
注意:
web.xmlで設定できるコンポーザ固有の構成の詳細は、「web.xml」を参照してください
この項では、コンポーザ固有のフィルタおよびその関連フィルタ・マッピングをアプリケーションのweb.xmlファイルで定義する例を提供します。ここでは、フィルタ(WebCenterComposerFilter)を追加する方法を説明します。
コンポーザ固有のフィルタおよびフィルタ・マッピングを定義するには:
ターゲット・サーバーでデータベース・ストアを使用していない場合は、まず、メタデータ・サービス(MDS)を使用して、ファイル・システムからデータベース・ストアにアプリケーション・メタデータを移行しておく必要があります。
これが必要になる理由は、アプリケーションのメタデータがデータベース・ストアに保存されている場合にのみ、コンポーザはサンドボックスを作成できるようになるためです。アプリケーションにデータベース・メタデータ・ストアが構成されていないと、サンドボックスは作成されなくなり、ページに加えたカスタマイズはMDSバックエンドにすぐにコミットされます。
MDSは、ファイル・システムからデータベース・ストアにカスタマイズを移行するためのmdstransferツールを提供しています。このツールを使用するには、例5-14に示すように、まず、ソース・ストアとターゲット・ストアに関する情報が含まれているパラメータ・ファイルを作成しておく必要があります。
例28-2 移行に使用するパラメータ・ファイル
<parameters version="11.1.1.000" xmlns="http://xmlns.oracle.com/mds/config">
<source-store>
<metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
<property name="metadata-path" value="C:\JDeveloper\mywork\Application2\ViewController\public_html"/>
</metadata-store>
</source-store>
<target-store>
<metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jdbc-userid" value="composerqa"/>
<property name="jdbc-password" value="composerqa"/>
<property name="jdbc-url" value="jdbc:oracle:thin:@10.177.254.62:1521:orcl"/>
<property name="partition-name" value="partitionName"/>
</metadata-store>
</target-store>
</parameters>
このファイル名は、次の例に示すように、mdstransferツールの実行時にソース・ディレクトリの名前とともに渡します。
mdstransfer "/test/**" --paramfile ToolsParamFile1.xml
testは、アプリケーション・メタデータのファイルとフォルダを格納しているディレクトリの名前です。
詳細は、MDSのドキュメントを参照してください。
注意:
mdstransferツールは、MDSのドキュメントを参照して実行するようにしてください。このツールを実行するためのいくつかの前提条件が、ここでは説明されていない可能性があるためです。
ランタイム・リソース・カタログのメタデータをデータベースに移行する場合は、移行するソースディレクトリにmds\oracle\webcenter\rc\default-catalog.xmlファイルを移動してください。たとえば、application_root/ViewController/public_html/test/。
サンドボックスの作成を有効にするには、アプリケーションを構成しデータベース・ストアを使用する必要があります。したがって、アプリケーションをWebLogic管理対象サーバーにデプロイするときに、データベース・リポジトリを選択し、そのアプリケーションのパーティション名を指定します。
アプリケーションでサンドボックスの作成を有効にするとき、ページ編集モードに入るときとそのモードを終了するときにフル・ページ・リフレッシュが実行されるようにする必要があります。実行手順の詳細は、「サーブレットをリダイレクトしてMDSカスタマイズ・レイヤー間の切替えを有効にする方法」を参照してください。
ユーザーがページ編集モードに切り替えたときに、コンポーザのツールバーに「保存」ボタンが表示されることで、そのアプリケーションはサンドボックスの作成が有効であるとわかります。ページまたはページの共有コンポーネントに対して行われた変更は、ユーザーが「保存」をクリックするまで保存されません。保存されると、すべてのアプリケーション・ユーザーがこのカスタマイズを使用できます。「保存」ボタンがレンダリングされない場合、サンドボックスを使用できず、各変更はすぐにコミットされます。
「コンポーネント・プロパティ」ダイアログでコンポーネント・プロパティを編集するとき、「適用」をクリックすると次のようになります。
サンドボックスを使用できない場合、ページがリフレッシュされてコンポーネント・プロパティに対して行われた変更が表示され、変更はバック・エンドに保存されます。
サンドボックスを使用できる場合、ページがリフレッシュされてコンポーネント・プロパティに対して行われた変更が表示されます。変更を保存するには、ユーザーは「保存」をクリックする必要があります。
ページで「保存」または「閉じる」をクリックすると、次のイベントが実行されます。
「保存」をクリックすると、サンドボックスがコミットされ、新しいサンドボックスが作成されます。ページは編集モードのままです。
「閉じる」をクリックすると、次の2つのイベントのいずれかが発生します。
最後の保存操作以降の変更がない場合は、サンドボックスが破棄され、コンポーザが閉じられて、ユーザーは表示モードに戻ります。
保存されていない変更がある場合、図28-1に示すように、クローズ確認ダイアログにページ名および保存されていないタスク・フロー名がリストされます。
ユーザーは、次のオプションから選択できます。
「保存」をクリックして、サンドボックスをコミットし、コンポーザを閉じます。
「保存しない」をクリックして、サンドボックスを破棄し、コンポーザを閉じます。
「取消」をクリックして、ダイアログを閉じ、変更を保存せずにコンポーザに戻ります。
注意:
ユーザーがページを編集中にページ外にナビゲートし、そのページに戻った場合、保存されていない変更は失われます。
並行編集時の処理
複数のユーザーが同じカスタマイズ・レイヤーを使用して同じページまたはタスク・フローを編集している場合、図28-2に示すように、別のユーザーがページまたはタスク・フローを編集しているというメッセージが、それぞれのユーザーのページに表示されます。
複数のユーザーが同じカスタマイズ・レイヤーで同時にタスク・フローにズームインし、それを編集している場合、図28-3に示すように、並行処理メッセージが表示されます。
注意:
ユーザーがタスク・フローにズームインし、いくつかのカスタマイズを行い、タスク・フローからズームアウトした場合、そのユーザーがカスタマイズを保存するまで、タスク・フローの並行処理メッセージが他のユーザーに対して継続して表示されます。
最後に保存された変更は前の変更を上書きします。たとえば、ユーザーAとBがページまたはタスク・フローを同時に編集している場合、並行性の問題は次のように処理されます。
Aが最初にページまたはタスク・フローを保存すると、Aの変更がMDSにコミットされます。その後、Bがページまたはタスク・フローを保存すると、Aの変更はBの変更で上書きされます。
Bが表示モードでコンポーネントをパーソナライズ(たとえば移動)しようとしている間にAがその同じコンポーネントを削除すると、WebCenterのエラー・ページがBに表示されます。Bは、元のページにナビゲートして戻る必要があります。削除されたコンポーネントは表示されず、Bは他のコンポーネントで作業を継続できます。
変更がすぐにバック・エンドにコミットされるようにするために、サンドボックスを無効にできます。
サンドボックスを無効にするには:
adf-config.xmlファイルを開きます。これは、「アプリケーション・リソース」パネルの「ディスクリプタ」の下のADF META-INFフォルダにあります。<pe:page-editor-config>要素の下に<pe:disable-sandbox>属性を追加し、これをtrueに設定します。adf-config.xmlを保存します。ユーザーが実行時にページを編集するとき、ブラウザが予期せずに閉じた場合またはユーザーがページ外にナビゲートした場合、そのセッションで使用されていたサンドボックスは使用可能なままです。同じページにアクセスしている他のユーザーには、同じページを別のユーザーが編集しているという並行処理メッセージが表示されたままになります。このような失効したサンドボックスを破棄して、データベース・ストアの領域を解放し、パフォーマンスを向上できます。
失効したサンドボックスが次の場合に破棄されるようにできます。
セッションがタイムアウトした場合。
アプリケーションのweb.xmlファイルの<session-timeout>要素は、サンドボックスが破棄されるまでの期間を定義できます。これが確実に起こるようにするためには、アプリケーションのweb.xmlファイルでWebCenterComposerSessionListenerを構成する必要があります。このリスナーは、セッションがタイムアウトになるとコールされます。これは、同じユーザーがページ編集モードに入るときに新しいサンドボックスを作成します。
ユーザーがページの編集モードに同じユーザー名で再ログインした場合。
この場合、同じユーザーが編集モードに切り替えると、新しいサンドボックスが作成されます。
WebCenterComposerSessionListenerを構成するには:
web.xmlで設定できるコンポーザ固有の構成の詳細は、「web.xml」を参照してください
カスタマイズをクライアント定義の条件に基づいてメタデータ・オブジェクトに適用できます。たとえば、エンド・ユーザーの権限、アプリケーションのデプロイ場所(ローカライゼーションとも呼ばれる)または特定の産業分野に基づいて使用するアプリケーションおよびメタデータ・オブジェクトをカスタマイズできます。このような各カテゴリ(権限、ローカライゼーションおよび分野)は、カスタマイズ・レイヤーを指し、それぞれがCustomizationClassを使用して描写されます。CustomizationClassはインタフェースMDSで、ベース定義でオーバーレイされるカスタマイズ・レイヤーを特定するために使用されます。例については、「カスタムUserCCヒント・レイヤーの作成方法」を参照してください。
CustomizationClassを実装する場合、これをMDSで登録する必要もあります。MDSには、CustomizationClassタイプのリストを単一のMetadataObjectと関連付ける機能が用意されています。これは、ファイングレイン関連付けと呼ばれます。MDSには、CustomizationClassタイプのリストを一連のMetadataObjectsと関連付ける機能も用意されています。これは粗密な関連付けと呼ばれます。
カスタマイズ可能アプリケーションは、複数のカスタマイズ・レイヤーを持つことができます。カスタマイズを適用するレイヤーを選択できます。カスタマイズ先として選択したレイヤーは、ヒント・レイヤーと呼ばれます。コンポーザ・コンポーネントをJSFページにドロップすると、ADFは、アプリケーションにデフォルトのSiteCC (site)ヒント・レイヤーを構成します。その結果、adf-config.xmlファイルが更新され、SiteCCカスタマイズ・クラスを組み込みます。このヒント・レイヤーは、ページに対して行われたすべてのカスタマイズを格納します。
この項では、例を使用して、カスタマイズ・ヒント・レイヤーを表示実行時モードおよび編集実行時モードに追加すると、ユーザーのカスタマイズ機能がすべてのユーザーにどのように提供され、アプリケーションのカスタマイズ機能が選択したユーザーにどのように提供されるかを説明します。アプリケーションのカスタマイズを編集モードで有効にするために、siteヒント・レイヤーが追加されます。ユーザーのカスタマイズを表示モードで有効にするために、userヒント・レイヤーが追加されます。デフォルトでは、userヒント・レイヤーはsiteヒント・レイヤーの上に適用されます。userヒント・レイヤーは、表示モードで行われたすべてのユーザーのカスタマイズ内容を、カスタマイズを行ったユーザー用に作成された特定の場所に格納します。このような変更はそのユーザーにしか表示されません。siteヒント・レイヤーは、編集モードで行われたすべてのアプリケーションのカスタマイズを格納し、すべてのユーザーに対して表示されます。
実行時にヒント・レイヤーを有効にするために、コンポーザはWebCenterComposerFilterフィルタを提供し、MDS SessionOptionsオブジェクトを作成するための抽象ファクトリを定義する方法を提供しています。このオブジェクトでは、実行時に適用可能なカスタマイズ・レイヤーが提供され、ユーザーはロールに基づいてユーザーのカスタマイズ(表示モード)およびアプリケーションのカスタマイズ(編集モード)を実行できます。新しいMDSセッションを作成するとき、このオブジェクトのMDSSession.createSessionメソッドを使用して、セッションのオプションを指定します。
この項では、カスタマイズ・レイヤーを作成、実装および登録し、WebCenterComposerFilterを構成し、MDSカスタマイズ・レイヤー間で切り替える例を提供します。次のサブセクションが含まれます:
この項では、JSFページにPage Customizableコンポーネントを追加する方法を説明します。この演習の目的は、adminユーザーがサイト・レベルでカスタマイズを実行できるように、実行時に編集モードのコンポーザを提供することです。この項では、実行時に表示モードから編集モードへの切替えを可能にするために、Change Mode Linkを追加します。
JSFページにコンポーザを追加するには:
この項では、編集モードで実行されたすべてのアプリケーション・レベルのカスタマイズ内容が格納される、カスタムSiteCCヒント・レイヤー(site)を作成する方法を説明します。このサンプル・アプリケーションでは、アプリケーション・レベルのカスタマイズ内容は、/mds/mdssys/cust/site/webcenter/pagename.jspx.xmlディレクトリに格納されます。
siteヒント・レイヤーを作成するには:
この項では、ユーザーscott用のカスタムuserヒント・レイヤーを作成する方法を示す例を説明します。このレイヤーはsiteレイヤーの上に適用されます。表示モードでユーザーが実行するユーザーのカスタマイズは、ログイン・ユーザー専用に作成されたフォルダのこのuserヒント・レイヤーに保存されます。この例では、表示モードで実行したユーザーのカスタマイズ内容は、/mds/mdssys/cust/user/scott/pagename.jspx.xmlディレクトリに格納されます。
注意:
説明上の目的のため、この例では、UserCCヒント・レイヤーが1人のユーザー(scott)のみのために作成される単純なシナリオを説明します。実際のアプリケーションでは、UserCCレイヤーを構成して、このページをリクエストしたユーザーの名前を返すことができます。
userヒント・レイヤーを作成するには:
この項では、ADFが提供するComposerSessionOptionsFactoryクラスが実装され、MDS SessionOptionsを各HTTPリクエストに提供します。
ComposerSessionOptionsFactoryクラスを実装するには:
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」を開き、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログが開きます。
「名前」フィールドにAppsSessionOptionsFactoryImplと入力します。
「OK」をクリックします。
AppsSessionOptionsFactoryImpl.javaファイルが「ソース」ビューにレンダリングされます。
次のライブラリをインポートします。
import oracle.adf.view.page.editor.mds.ComposerSessionOptionsFactory; import oracle.adf.view.page.editor.mode.ModeContext; import oracle.mds.config.CustClassListMapping; import oracle.mds.config.CustConfig; import oracle.mds.core.SessionOptions; import oracle.mds.cust.CustClassList; import oracle.mds.cust.CustomizationClass;
次のコードを追加してComposerSessionOptionsFactoryクラスを実装し、SessionOptionsを渡します。
public class AppsSessionOptionsFactoryImpl
implements ComposerSessionOptionsFactory
{
public SessionOptions createSessionOptions(SessionOptions defaultSessionOptions, String mode)
{
CustomizationClass[] custLayer;
CustConfig custConfig = null;
if (ModeContext.EDIT_MODE.equals(mode))
{
//Mode is Edit, change to SiteCC
custLayer = EDIT_LAYER;
}
else
{
//Mode is View, change to UserCC + SiteCC
custLayer = VIEW_LAYER;
}
try
{
CustClassList custClassList = new CustClassList(custLayer);
CustClassListMapping custClassListMapping =
new CustClassListMapping("/", null, null, custClassList);
custConfig = new CustConfig(new CustClassListMapping[]
{ custClassListMapping });
}
catch (Exception e)
{
e.printStackTrace();
}
if(defaultSessionOptions.getServletContextAsObject() != null){
return new SessionOptions(defaultSessionOptions.getIsolationLevel(),
defaultSessionOptions.getLocale(), custConfig,
defaultSessionOptions.getVersionContext(),
defaultSessionOptions.getVersionCreatorName(),
defaultSessionOptions.getCustomizationPolicy(),
defaultSessionOptions.getServletContextAsObject());
}
else
{
return new SessionOptions(defaultSessionOptions.getIsolationLevel(),
defaultSessionOptions.getLocale(), custConfig,
defaultSessionOptions.getVersionContext(),
defaultSessionOptions.getVersionCreatorName(),
defaultSessionOptions.getCustomizationPolicy());
}
}
//Edit mode SiteCC
private static final CustomizationClass[] EDIT_LAYER =
new CustomizationClass[]
{ new SiteCC() };
//View mode SiteCC + USerCC
private static final CustomizationClass[] VIEW_LAYER =
new CustomizationClass[]
{ new SiteCC(), new UserCC() };
}
AppsSessionOptionsFactoryImpl.javaファイルを保存します。
siteカスタマイズ・レイヤーおよびuserカスタマイズ・レイヤーを機能させるには、コンポーザにComposerSessionOptionsFactoryクラスを登録する必要があります。たとえば、具体的なクラスがview.AppsSessionOptionsFactoryImplの場合、次のスニペットをアプリケーション・ディレクトリの/.adf/META-INFフォルダにあるadf-config.xmlファイルに追加する必要があります。
<pe:page-editor-config xmlns="http://xmlns.oracle.com/adf/pageeditor/config"> <pe:session-options-factory>view.AppsSessionOptionsFactoryImpl</pe:session-options-factory> </pe:page-editor-config>
アプリケーション・ディレクトリのPortal/public_html/WEB-INFフォルダにあるweb.xmlファイルのWebCenterComposerFilterフィルタを構成する必要があります。このフィルタは、すべてのHTTPリクエストについてコンポーザの具体的なSessionOptionsFactoryをADFに登録します。フィルタがADFからコールを受信すると、リクエストをアプリケーションに転送し、新しくカスタマイズされたレイヤーでSessionOptionsを取得します。SessionOptionsでSandboxまたはVersionContextを設定していない場合、コンポーザは専用のサンドボックスを設定して、それをADFに返します。サンドボックスの詳細は、「コンポーザのサンドボックスの作成を有効にする方法」を参照してください。
composerFilterとそのフィルタ・マッピングは、ADFBindingFilterより前に構成する必要があります。たとえば、次のweb.xmlファイルを参照してください。
....
<!-- WebCenterComposerFilter goes here -->
<filter>
<filter-name>composerFilter</filter-name>
<filter-class>oracle.adf.view.page.editor.webapp.WebCenterComposerFilter</filter-class>
</filter>
<filter>
<filter-name>adfBindings</filter-name>
<filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
</filter>
.....
<!-- WebCenterComposerFilter mapping goes here -->
<filter-mapping>
<filter-name>composerFilter</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>adfBindings</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
....
注意:
フィルタの定義順序が重要です。リクエストがこれらのフィルタで順番に渡されるので、適切な順序で定義されていないと、アプリケーションは設計されたように実行されません。web.xmlファイルではWebCenterComposerFilterを最初に実装してから、その後でAdfBindingFilterを実装する必要があります。
web.xmlで設定できるコンポーザ固有の構成の詳細は、「web.xml」を参照してください。
サーブレットをリダイレクトする、つまり実行時にフル・ページをリフレッシュするには、次のものを作成する必要があります。
AppNavigationUtils.redirectToSamePage()メソッドをコールするAppNavigationUtilsクラス
AppNavigationUtilsクラスを使用するAppCloseHandler CloseListener
編集モードを表示するAppModeBean
この項では、これらのオブジェクトの作成方法を説明します。次のサブセクションが含まれます:
AppCloseHandlerの作成後、これをコンポーザ拡張ファイルpe_ext.xmlに登録する必要があります。
このイベント・ハンドラを登録するには:
イベント・ハンドラの詳細は、「コンポーザUIイベントのイベント・ハンドラの構成」を参照してください。
siteカスタマイズ・レイヤーの機能を確認するには、まずブラウザでJSFページを実行します。次に、ページにadminとしてログインし、「編集」リンクをクリックして編集モードに切り替えます。実行時、ページをカスタマイズします。たとえば、Webページ、移動可能ボックスまたはイメージをページにドロップします。ページは図28-4のようになります。
アプリケーション・ディレクトリの/mds/mdssys/cust/site/webcenterに移動し、pagename.jspx.xmlファイルを開きます。これは、ページに対して実行したアプリケーション・レベルのカスタマイズが格納される場所です。
userカスタマイズ・レイヤーを使用するには、ページにscottとしてログインし、表示モードでページをパーソナライズします。次にアプリケーション・ディレクトリの/mds/mdssys/cust/user/scottに移動し、pagename.jspx.xmlファイルを開きます。これは、ページに対して実行したユーザーレベルのカスタマイズが格納される場所です。
この項では、コンポーザの使用中に発生する可能性のあるMDS関連の問題をトラブルシューティングする際に役立つ情報を提供します。
ロギングの構成の詳細は、「コンポーザのADFロギングの構成」を参照してください。
問題
アプリケーションはMDSサンドボックスを使用するように構成されています。アプリケーションを実行すると、サンドボックスは動作せず、また例外も生成しません。
解決策
次の点を確認してください。
データベース・リポジトリが使用されています。サンドボックスは、データベース・ベースのリポジトリでのみ動作し、ファイルベースのリポジトリでは動作しません。
web.xmlのフィルタの順序が正確です。サンドボックスが正しく動作するためには、<filter>エントリが正しい順序である必要があります。
詳細は、「コンポーザのサンドボックスの使用」を参照してください。
