22 複雑なタスク・フローの作成

この章では、ADFアプリケーションでADFタスク・フローの拡張機能を使用する方法を説明します。

この章の内容は次のとおりです。

22.1項「複雑なタスク・フローの作成」
22.2項「タスク・フロー間のデータ・コントロールの共有」
22.3項「タスク・フローのトランザクションの管理」
22.4項「バインド・タスク・フローの再開」
22.5項「タスク・フローでの例外の処理」
22.6項「セーブポイントを使用するためのアプリケーションの構成」
22.7項「タスク・フローでのセーブポイントの使用」
22.8項「バインド・タスク・フローでのトレイン・コンポーネントの使用」
22.9項「タスク・フロー・テンプレートの作成」
22.10項「タスク・フローを使用したページ階層の作成」

22.1 複雑なタスク・フローの作成

作成したタスク・フローにアクティビティを追加して、そのアクティビティ間に制御フローを構成した場合は、次のリストで説明する機能の一部を追加することで、タスク・フローの機能を拡張できます。

基礎となるデータ・コントロールの機能に加えて、追加のトランザクション管理機能を含むようにバウンド・タスク・フローを構成すると、タスク・フローのアクティビティにグループとして関連付けられているデータ・コントロールをFusion Webアプリケーションでコミットまたはロールバックできます。
バインド・タスク・フローにオプションの再開を構成すると、ユーザーがブラウザの「戻る」ボタンをクリックした場合のレスポンスを決定できます。
タスク・フローには、あらかじめ例外を処理できる機能が数多くあります。さらに、タスク・フローによってスローされる例外を処理するカスタム・コードを記述できます。
また、タスク・フローを構成すると、セーブポイントを使用してFusion Webアプリケーションの特定のインスタンスの状態を把握できます。これにより、たとえばユーザーがタスクを完了せずにそのページから移動した場合に、アプリケーションの状態を保存できます。
トレイン・コンポーネントは、ナビゲーション・アイテムをレンダリングするADF Facesコンポーネントで、マルチステップ・プロセスを使用してユーザーをガイドします。バインド・タスク・フローを構成することで、これらのナビゲーション・アイテムをタスク・フローのビュー・アクティビティ用にデフォルトでレンダリングできます。
タスク・フロー・テンプレートは、共通の要素を共有するタスク・フロー作成の開始ポイントとして機能できます。
アプリケーションのデフォルトのバインドなしタスク・フロー(およびアプリケーションの追加のタスク・フロー)が参照するビュー・アクティビティからページ階層を作成します。
バインド・タスク・フローの入力時および終了時にイニシャライザとファイナライザを起動します。イニシャライザは、バインド・タスク・フローの入力時に起動されるカスタム・コードです。ファイナライザは、タスク・フロー・リターン・アクティビティを使用したタスク・フローの終了時、または例外の発生によって起動されるカスタム・コードです。ファイナライザはマネージドBeanのメソッドです。一般的なファイナライザのタスクには、バインド・タスク・フローで取得したすべてのリソースの解放、およびタスク・フローを終了する前のクリーンアップの実行などがあります。

イニシャライザとファイナライザは両方とも、次の例のように、マネージドBeanのメソッドにEL式として指定します。

#{pageFlowScope.modelBean.releaseResources}

バインド・タスク・フローの開始時にイニシャライザのコードを実行するには2つの方法があり、ブラウザの「戻る」ボタンでそのタスク・フローを再開できるかどうかによって次のように異なります。
- 「戻る」ボタンでの再開が想定されない場合: バインド・タスク・フロー内で(最初に実行する)デフォルト・アクティビティとしてメソッド・コール・アクティビティを指定します。そのメソッド・コール・アクティビティにより、イニシャライザのコードを含むカスタム・メソッドがコールされます。詳細は、19.5項「メソッド・コール・アクティビティの使用」および26.4.4項「ブラウザの「戻る」ボタンおよびレコード間の移動について」を参照してください。
- 「戻る」ボタンでの再開が可能な場合: バインド・タスク・フローのメタデータのオプションで、イニシャライザ・メソッドを指定します詳細は、18.2項「タスク・フローの作成」を参照してください。ユーザーにブラウザの「戻る」ボタンを使用してタスク・フローを再開させる場合は、この手法を使用します。このような場合には、バインド・タスク・フローに指定したデフォルト・アクティビティがコールされずに、イニシャライザ・メソッドで指定されたメソッドがコールされることがあります。

22.1.1 複雑なタスク・フローのユース・ケースと例

図22-1は、Fusion Order Demoアプリケーションにある顧客登録タスク・フローの構造ウィンドウが示されています。このタスク・フローには、22.1項「複雑なタスク・フローの作成について」で説明したユース・ケースが数多く実装されています。ここでは、たとえば、エラー処理用のエラー・ページが指定され、ナビゲーション・アイテムのレンダリングにADF Facesのtrainコンポーネントが使用されるほか、トランザクション管理の一部としてタスク・フローによる変更がコミットまたはロールバックされる2つのタスク・フロー・リターン・アクティビティが指定されます。このタスク・フローを含むFusion Order Demoアプリケーションの詳細は、第2章「ADFサンプル・アプリケーションの概要」を参照してください。

図22-1 構造ウィンドウの顧客登録タスク・フロー

22.1.2 複雑なタスク・フローの追加の機能

タスク・フローを構成または使用する前に、他のADF機能を理解しておくと役に立つ場合があります。また、タスク・フローで実行できる機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。

タスク・フローの実行時に発生したエラーを管理する例外ハンドラを指定できます。エラー処理の詳細は、16.3項「エラー処理のカスタマイズ」を参照してください。
タスク・フローのセーブポイントでは、アプリケーション状態を保存できます。アプリケーション状態管理の詳細は、43項「アプリケーション状態管理」を参照してください。
バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、第35項「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
次を実行するには、タスク・フローとともにBusiness Process Execution Language (BPEL)を使用できます。
- バインドなしタスク・フローまたはバインド・タスク・フローからBPELプロセスを起動して、関数を実行したり、サービスを使用すること
- Webインタフェースとのユーザーの対話をモデル化するために、BPELプロセスからバインド・タスク・フローをコールすること
BPELプロセスと対話するマネージドBeanメソッドまたはWebサービスを起動するには、タスク・フロー・メソッド・コール・アクティビティを使用できます。タスク・フロー・メソッド・コール・アクティビティの詳細は、19.5項「メソッド・コール・アクティビティの使用」を参照してください。
タスク・フローを開くカスタム・コードを記述できます。たとえば、22.5.3項「例外ハンドラとしてカスタム・コードを指定する方法」の説明のように、タスク・フローによる例外のスロー時に起動するカスタム・コードを記述できます。カスタム・コードの記述に使用できるAPIの詳細は、次のリファレンス・ドキュメントを参照してください。
- Oracle Fusion Middleware Oracle ADF Controller Java APIリファレンス
- Oracle Fusion Middleware Java APIリファレンス for Oracle ADF Faces

22.2 タスク・フロー間のデータ・コントロールの共有

タスク・フロー間ではデータ・コントロールを共有できます。コール先のバインド・タスク・フローは、そのコール元のタスク・フローによって所有されるデータ・コントロールの値を参照および変更できます。これにより、コール先のタスク・フローはその親と同じデータ・コントロール・インスタンスを共有できます。どちらのタスク・フローも同じ場所(データ・コントロール・フレーム)を調べて、データ・コントロール・インスタンスを取得します。

データ・コントロール・フレームは、1つ以上のタスク・フローとそのデータ・コントロールを関連付けるメカニズムです。コミットまたはロールバック時にタスク・フロー・トランザクション管理オプションを使用するタスク・フローでは、どのデータ・コントロールに対してトランザクション操作を実行するかを判断するためにデータ・コントロール・フレームが使用されます。data-control-scopeの値がisolatedに設定されている場合、アプリケーションのバインドなしタスク・フローおよびすべてのバインド・タスク・フローに対応するデータ・コントロール・フレームが実行時に作成されます。タスク・フローのdata-control-scopeの値にsharedが指定されている場合は、コール先のタスク・フローでは独自のデータ・コントロール・フレームは作成されず、コール元のデータ・コントロール・フレームが使用されます。これにより、データ・コントロール・フレームに添付されたデータ・コントロール・インスタンスをコール先のタスク・フローと共有できるようになります。または、コール先のタスク・フローでdata-control-scopeの値にisolatedが指定されている場合は、新しいデータ・コントロール・フレームが作成され、バウンド・タスク・フローで使用されるすべてのデータ・コントロールの新しいインスタンスが、新規に作成されたデータ・コントロール・フレームに添付されます。

コール元のタスク・フローとコール先のタスク・フローの間でデータ・コントロールを共有するかどうかを指定するには、コール先のバインド・タスク・フローでsharedまたはisolatedのいずれかのdata-control-scopeの値を設定する必要があります。デフォルト値はsharedです。

コール元のバインド・タスク・フローとコール先のバインド・タスク・フローの両方でdata-control-scopeがsharedに設定されている場合は、使用されるデータ・コントロール・フレームはコール元のタスク・フロー用のデータ・コントロール・フレームになります。例22-1では、Bounded Task Flow Aのデータ・コントロール・フレームがBおよびCでも使用されています。コール元とコール先の両方のバインド・タスク・フローでdata-control-scopeがisolatedに設定されている場合は、それぞれのタスク・フローで独自のデータ・コントロール・フレームが使用されます。

例22-1 データ・コントロールの共有

Bounded Task Flow A - isolated
  Bounded Task Flow B - shared
    Bounded Task Flow C - shared

注意:

コール元のタスク・フローがコール先のタスク・フローを起動するURLを使用している場合は、タスク・フローでデータ・コントロールの共有が構成されていても、コール元のタスク・フローとデータ・コントロールを共有できません。このケースが発生した場合、ADFコントローラでは例外がスローされます。

コール先のバインド・タスク・フローでは、そのコール元のデータ・コントロールを任意の深さで共有できます。たとえば、Task Flow Aは、コール先のバインドTask Flow Bとデータ・コントロールを共有できます。コール先のTask Flow Cは、同じデータ・コントロールを共有できます。

data-control-scopeをsharedに指定し、ADFリージョン内で使用されるバインド・タスク・フローでは、親ビュー・ポートにあるタスク・フローのデータ・コントロールが共有されます。ビュー・ポートの詳細は、21.1.2項「ビュー・ポートおよびADFリージョンについて」を参照してください。

新しいデータ・コントロール・フレームは、各RootViewPortのコール・スタックにあるバインドなしタスク・フロー用に作成されます。各ブラウザ・ウィンドウは、同じHTTPセッション内では残りのブラウザ・ウィンドウから分離されます。ブラウザ・ウィンドウではデータ・コントロールを共有しません。ただし、エンド・ユーザーがセカンダリ・ブラウザ・ウィンドウでモーダル・ダイアログを開いた場合は、プライマリ・ブラウザ・ウィンドウとセカンダリ・ブラウザ・ウィンドウでサーバー側の状態が同じになり、データ・コントロールも共有されます。モーダル・ダイアログの使用の詳細は、23.2項「モーダル・ダイアログ内でのバインド・タスク・フローの実行」を参照してください。

データ・コントロールは必要になるまでインスタンス化されません。data-control-scopeにshared(デフォルト)が指定され、Dというデータ・コントロールを参照する子タスク・フローを親タスク・フローで呼び出すと、次の2つのいずれかの処理が行われます。

Dというデータ・コントロールが親タスク・フローのデータ・コントロール・フレームにすでに存在する場合は、子タスク・フローのDへの参照はスコープ内に存在するDというデータ・コントロールへのものとして解決されます。
Dというデータ・コントロールが親タスク・フローのデータ・コントロール・フレームに存在しない場合は、Oracle ADFによってDという最初のデータ・コントロールがインスタンス化されます。このデータ・コントロールは、Oracle ADFがタスク・フロー・コール・スタックのDataBindings.cpxファイルをトップダウン検索する際に特定されます。

前の例では、親タスク・フローはADFライブラリJARに基づいており、ADFライブラリJARの親タスク・フローのDataBindings.cpxファイル内にデータ・コントロールDの使用方法が定義されていることを想定しています。また、子タスク・フローでも、独自のDataBindings.cpxファイルにDというデータ・コントロールの使用方法が定義されていることを想定しています。

親タスク・フローで子タスク・フローを呼び出した際に、親タスク・フローのADFライブラリJARに基づくデータ・コントロールDがすでにインスタンス化されている場合は、子タスク・フローではそのデータ・コントロールが使用されます。まだインスタンス化されていない場合は、親タスク・フローに基づくデータ・コントロールDがインスタンス化され、子タスク・フローで使用されます。具体的に言うと、このようなタスク・フロー呼出しのシナリオでは、子タスク・フローのデータ・コントロールDはインスタンス化されません。

データ・コントロールの詳細は、13.3項「Oracle ADFデータ・コントロールを使用したアプリケーション・モジュールの公開」を参照してください。

22.2.1 タスク・フロー間のデータ・コントロールの共有方法

コール先のタスク・フローのdata-control-scope要素の値を指定することで、タスク・フロー間でデータ・コントロールを共有できます。

作業を始める前に、次のようにします。

タスク・フロー間でのデータ・コントロールの共有方法を決定するプロパティについて理解しておくと役に立つ場合があります。詳細は、22.2項「タスク・フロー間のデータ・コントロールの共有」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、22.1.2項「複雑なタスク・フローの追加の機能」を参照してください。

タスク・フロー間でデータ・コントロールを共有する手順:

「アプリケーション」ウィンドウで、コール先のタスク・フローをダブルクリックします。

「プロパティ」ウィンドウで「動作」セクションを展開し、「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックスを選択します。

注意:

「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックスを選択した場合は、タスク・フローでのトランザクション・オプションの構成が必要な場合があります。詳細は、22.3.3項「データ・コントロールの共有およびトランザクションの管理について」を参照してください。

22.2.2 タスク・フロー間でのデータ・コントロールの共有時の処理

例22-2で示すように、「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックスを選択すると、JDeveloperではコール先のタスク・フローのソース・ファイルにあるエントリが記述されます。

実行時に、コール先のタスク・フローは、コール元のタスク・フローとデータ・コントロールを共有します。

例22-2 タスク・フロー間でのデータ・コントロールを共有するメタデータ

<task-flow-definition id="task-flow-definition">
    ...
    <data-control-scope id="__1">
      <shared/>
    </data-control-scope>
    ...
  </task-flow-definition>

22.3 タスク・フローのトランザクションの管理

トランザクションとは、1つのグループとしてコミットまたはロールバックできる永続的な作業の集まりです。バインド・タスク・フローを使用して、トランザクションを表したり、トランザクションの境界を宣言的に管理できます。Fusion Order Demoアプリケーションには、顧客登録と従業員登録の両タスク・フローがタスク・フロー・リターン・アクティビティを使用して実装されています。「取消」ボタンにより、タスク・フローにロールバックが実装されます。reviewCustomerInfo.jsffおよびreviewEmployeeInfo.jsffのページ・フラグメント・ファイル上にある「登録」ボタンにはコミット機能が実装されています。

エンド・ユーザーはショッピング・カートから移動して、在庫切れ品目のバックオーダー・リクエストを開始できます。バックオーダー・リクエスト・アプリケーションは、開始時に新しいトランザクションを開始するバインド・タスク・フローとして実装されます。

コールされるバインド・タスク・フローのトランザクション・オプションにより、コール先のバインド・タスク・フローを既存のトランザクションに結合するか、新しいトランザクションを作成するか、または既存のトランザクションがない場合にのみ新しいトランザクションを作成するかが指定されます。

コール先のバインド・タスク・フローで(選択したtransactionオプションに基づいて)新しいトランザクションを開始できる場合は、タスク・フローがそのコール元に戻ったときにトランザクションをコミットまたはロールバックするかどうかを指定できます。コミットおよびロールバック・オプションは、コール元のタスク・フローに制御を戻すタスク・フロー・リターン・アクティビティで設定されます。トランザクションを開始する同じタスク・フローでも、トランザクションを解決できる必要があります。

コール先のバインド・タスク・フローには、結果としてコール先のバインド・タスク・フローでトランザクションをコミットまたはロールバックする2つ異なるのタスク・フロー・リターン・アクティビティを指定できます。それぞれのタスク・フロー・リターン・アクティビティから、同じコール元タスク・フローに制御が戻されます。ただし、一方のタスク・フロー・リターン・アクティビティはコミット・オプションを指定し、他方はロールバック・オプションを指定する点が異なります。図22-2に示すように、トランザクションの処理が正常に終了した場合は、成功タスク・フロー・リターン・アクティビティに制御フローが渡され、トランザクションをコミットするオプションが指定されます。トランザクションが完了前に取り消された場合、取消タスク・フロー・アクティビティによりトランザクションをロールバックするオプションが指定されます。

図22-2 コール先バインド・タスク・フローにおけるタスク・フロー・リターン・アクティビティ

トランザクション・オプションが指定されていない場合、コール先のバインド・タスク・フローの開始時にトランザクションが開始されません。バインド・タスク・フローがトランザクション・サービスにアクセスしようとすると、実行時例外がスローされます。

コール先のバインド・タスク・フローの終了時に、コール先のバインド・タスク・フロー内でエンド・ユーザーが行った変更を破棄する場合は、タスク・フロー・リターン・アクティビティでrestore-save-pointオプションを使用します。ADF Controllerによって、バインド・タスク・フローの開始時に作成された、前のADFモデルのセーブポイントまでロールバックされます。restore-save-pointオプションの適用は、既存のトランザクションを結合してバインド・タスク・フローを開始した場合(また、requires-existing-transactionまたはrequires-transactionのいずれかのオプションが指定された場合)、および開始時にセーブポイントを作成した場合にのみ行われます。

タスク・フロー・トランザクション管理機能を使用して、現在のタスク・フローのデータ・コントロール・フレームに関連付けられているデータ・コントロールをコミットまたはロールバックする場合は、「トランザクションの終了」プロパティをcommitまたはrollbackに設定してタスク・フロー・リターン・アクティビティを使用するか、関連付けられているデータ・コントロール・フレームをプログラムによってコミットする必要があります。または、<コントローラ・トランザクションなし>設定を使用する場合や、1つのデータ・コントロールのみをコミットまたはロールバックする場合は、関連付けられたコミットまたはロールバック操作を「データ・コントロール」パネルで使用するか、関連付けられたコミットまたはロールバックのバインディングをプログラムによって実行します。

22.3.1 バインド・タスク・フローでトランザクションを有効化する方法

別のタスク・フローによってコールされるバインド・タスク・フローのトランザクション・オプションを定義します。コール先バインド・タスク・フローで、バインド・タスク・フローをコールするタスク・フローに制御を戻すタスク・フロー・リターン・アクティビティを追加します。

作業を始める前に、次のようにします。

トランザクションの概要とその構成方法を理解しておくと役に立つ場合があります。詳細は、22.3項「タスク・フローのトランザクションの管理」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが必要な場合もあります。詳細は、22.1.2項「複雑なタスク・フローの追加の機能」を参照してください。

バインド・タスク・フローをトランザクションとして実行可能にする手順:

「アプリケーション・ナビゲータ」で、コール先のバインド・タスク・フローのソース・ファイルをダブルクリックします。
概要エディタで、「動作」ナビゲーション・タブをクリックし、「トランザクション」セクションを開きます。

ドロップダウン・リストから次のいずれかを選択します。

<コントローラ・トランザクションなし>: コール先のバインド・タスク・フローでは、タスク・フローに添付され、データ・コントロール・フレームに関連付けられているすべてのデータ・コントロールをコミットまたはロールバックする場合、タスク・フロー・トランザクション管理機能は使用されません。かわりに、タスク・フローに関連付けられているデータ・コントロールを個別にコミットまたはロールバックする必要があります。
常に既存のトランザクションを使用: バインド・タスク・フローは、コール時にすでに進行中の既存のトランザクションに追加されます。
可能であれば既存のトランザクションを使用: バインド・タスク・フローは、コール時に既存のトランザクションがある場合はそれに追加されますが、既存のトランザクションがない場合はそのバインド・タスク・フローの開始時に新しいトランザクションが開始されます。
常に新規トランザクションを開始: トランザクションが進行中かどうかに関係なく、バインド・タスク・フローの開始時に新しいトランザクションが開始されます。この新しいトランザクションは、バインド・タスク・フローを終了した時点で完了します。

注意:

トランザクション・オプションを選択した後は、これらのオプション間で相互作用があるかどうかを決定するために、そのバインド・タスク・フローの「タスク・フローのコールとデータ・コントロールを共有」オプションの選択も必要になる場合があります。詳細は、22.3.3項「データ・コントロールの共有およびトランザクションの管理について」を参照してください。

手順3で次のいずれかのオプションを選択した場合は、必要に応じて、「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックスを選択解除して、データ・コントロールがコール元のタスク・フローと共有されないようにします。
- 可能であれば既存のトランザクションを使用
- 常に新規トランザクションを開始
デフォルトの動作では、データ・コントロールが共有されます。詳細は、22.3.3項「データ・コントロールの共有およびトランザクションの管理について」を参照してください。
手順3で次のいずれかのオプションを選択した場合は、必要に応じて、「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択して、タスク・フローの開始時にADFモデルのセーブポイントが作成されないようにします。
- 常に既存のトランザクションを使用
- 可能であれば既存のトランザクションを使用
ADF Modelのセーブポイントとは、ADF Modelの状態を保存したスナップショットのことです。「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択すると、セーブポイントに関連付けられたオーバーヘッドはトランザクション用に作成されません。
コール先のバインド・タスク・フロー内のタスク・フロー・リターン・アクティビティを選択します。
プロパティ・インスペクタで「動作」セクションを展開します。
コール先のバインド・タスク・フローで新しいトランザクションの作成がサポートされている場合(バインド・タスク・フローで「可能であれば既存のトランザクションを使用」または「常に新規トランザクションを開始」オプションが指定されている場合)、「トランザクションの終了」ドロップダウン・リストから次のいずれかを選択します。
- commit: 選択すると、既存のトランザクションをデータベースにコミットします。
- ロールバック: タスク・フローの開始時に新しいトランザクションを初期状態までロールバックする場合に選択します。これには、トランザクションの取消しと同じ効果があります。
コール先のバインド・タスク・フロー内でユーザーが行った変更をタスク・フロー終了時に破棄する場合は、「セーブポイントのリストア」ドロップダウン・リストで「true」を選択します。タスク・フローの開始時に作成されたセーブポイントがリストアされます。

22.3.2 Transactionオプション指定時の処理

例22-3は、コール先のバインド・タスク・フローのトランザクション・オプションのメタデータを示しています。この<new-transaction>要素は、コール先のバインド・タスク・フローの起動時に新しいトランザクションが常に開始されることを示しています。

例22-3 コール先のバインド・タスク・フローのメタデータ

 <task-flow-definition id="trans-taskflow-definition">     
    <default-activity>taskFlowReturn1</default-activity>
    <transaction>
      <new-transaction/>
    </transaction>
    <task-flow-return id="taskFlowReturn1">
      <outcome>
        <name>success</name>
        <commit/>
      </outcome>
    </task-flow-return>
  </task-flow-definition>

例22-3は、コール先のタスク・フローのタスク・フロー・リターン・アクティビティ上にあるトランザクション・オプションのメタデータも示しています。<commit/>要素は、既存のトランザクションをデータベースにコミットします。<outcome>要素は、バインド・タスク・フローの終了時にコール元に戻される結果を、リテラルで指定します(例: success)。コール元のADFタスク・フローでは、この結果に基づいて制御フロー・ルールを定義できます。戻された時点の制御フローの定義に関する詳細は、19.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。

22.3.3 データ・コントロールの共有およびトランザクションの管理について

複数のトランザクション間ではデータ・コントロールを同時に共有できません。タスク・フローがトランザクションの管理を行う場合は、data-control-scopeオプションに選択する値が、バインド・タスク・フローのtransactionオプション設定に影響を与えることがあります。表22-1で、これらのオプションの対話について説明します。

ADFモデル・レイヤーでは、フレーム内のデータ・コントロールが追加されるトランザクションを管理するためのDataControlFrameインタフェースが公開されます。DataControlFrameインタフェースによって、次のようなメソッドが公開されます。

beginTransaction()
commit()
rollback()

同様に、ADF Controllerを使用すると、トランザクションの境界を定めること、タスク・フローの開始時にトランザクションを開始すること、およびタスク・フローの終了時にトランザクションをコミットまたはロールバックすることがタスク・フローで可能になります。そのために、ADFモデル・レイヤーのDataControlFrameインタフェースで公開されるメソッドが起動されます。

ADFコントローラでは、表22-1にリストするトランザクション・オプションがサポートされます。これらのトランザクション・オプションの動作は、タスク・フローの概要エディタで「タスク・フローのコールとデータ・コントロールを共有」チェック・ボックス(XML要素: <data-control-scope>)が選択されているかどうかで異なります。

表22-1 トランザクション設定の動作

トランザクション設定	共有データ・コントロール・スコープ	独立データ・コントロール・スコープ
<コントローラ・トランザクションなし>	開いているトランザクションがなくてもフレームで`DataControlFrame`が共有されます。	開いているトランザクションなしで新しい`DataControlFrame`が作成されます。
常に新規トランザクションを開始 XML要素: `<new-transaction/>`	まだトランザクションを開いていない場合は新しいトランザクションを開始し、すでに開いている場合は例外をスローします。	常に新しいトランザクションを開始します。
常に既存のトランザクションを使用 XML要素: `<requires-existing-transaction/>`	まだトランザクションを開いていない場合は、例外がスローされます。	無効です。このチェック・ボックスは選択解除できません。
可能であれば既存のトランザクションを使用 XML要素: `<requires-transaction/>`	まだトランザクションを開いていない場合は、新しいトランザクションを開始します。	常に新しいトランザクションを開始します。

22.4 バインド・タスク・フローの再開

エンド・ユーザーが「戻る」ボタンをクリックして、終了後のバインド・タスク・フローに戻るケースを処理するには、バインド・タスク・フローにtask-flow-reentryオプションを指定できます。このオプションでは、バインド・タスク・フロー内のページを再開できるかどうかを指定します。

再開時には、バインド・タスク・フローの各入力パラメータが、バインド・タスク・フローの最初の開始時のアプリケーションの状態ではなく、現在のアプリケーションの状態によって評価されます。

注意:

ブラウザの「戻る」ボタンの処理は、それぞれに異なります。「戻る」ボタンのナビゲーションがすべてのブラウザ間で適切に検出されるようにするには、タスク・フロー内のビュー・アクティビティを正しく構成する必要があります。タスク・フローでreentry-not-allowedまたはreentry-outcome-dependentオプションを使用する場合は、タスク・フロー内の各ビュー・アクティビティでredirect属性をtrueに設定する必要があります。ビュー・アクティビティの構成方法の詳細は、19.3項「URLビュー・アクティビティの使用」を参照してください。

22.4.1 再開動作の設定方法

task-flow-reentryオプションを指定することで、バインド・タスク・フロー上の再開動作を設定できます。

作業を始める前に、次のようにします。

バインド・タスク・フローでの再開オプションの構成内容を理解しておくと役に立つ場合があります。詳細は、22.4項「バインド・タスク・フローの再開」を参照してください。

再開動作を設定する手順:

「アプリケーション・ナビゲータ」で、バインド・タスク・フローのソース・ファイルをダブルクリックします。
概要エディタで、「動作」ナビゲーション・タブをクリックします。
「タスク・フローの再入力」ドロップダウン・リストで、次のいずれかを選択します。
- reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。
- reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。
  
  例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。
- reentry-outcome-dependent: ブラウザの「戻る」ボタンを使用したバインド・タスク・フローの再開は、同じバインド・タスク・フローの前回終了時にタスク・フロー・リターン・アクティビティを介して受け取った結果に基づいて行われます。指定する場合、コール先のバインド・タスク・フローのタスク・フロー・リターン・アクティビティにもreentry-allowedまたはreentry-not-allowedのいずれかを指定し、結果に基づいた再開動作を定義する必要があります。
  
  このオプションを選択した場合、ユーザーは自身が初めにタスク・フローを終了した方法にのみ基づいて、そのタスク・フローに「戻る」ボタンで移動できます。たとえば、ショッピング・カートを表すタスク・フローの再開は、ユーザーが注文を取り消してそのフローを終了した場合には可能ですが、ユーザーが注文を完了してフローを終了した場合には不可能です。

22.4.2 結果依存オプションの設定方法

22.4.1項「再開動作の設定方法」で説明したように、reentry-outcome-dependentオプションを指定したバインド・タスク・フローに対して、結果依存のオプションを設定できます。

作業を始める前に、次のようにします。

結果依存オプションの設定手順:

バインド・タスク・フローのタスク・フロー・ダイアグラムで、タスク・フロー・リターン・アクティビティを選択します。

タスク・フロー・リターン・アクティビティの追加に関する詳細は、19.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。
プロパティ・インスペクタで、「一般」セクションを開きます。
「名前」フィールドに、結果の名前をリテラルで入力します(例: success、failure)。
「動作」セクションを開きます。
「再入力」ドロップダウン・リストから、次のオプションのいずれかを選択します。
- reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。
- reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。
  
  例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。

22.4.3 タスク・フロー再開時のマネージドBeanの値について

エンド・ユーザーがブラウザの「戻る」ボタンを使用してバインド・タスク・フローを再開し、再開が許可された場合は、エンド・ユーザーがバインド・タスク・フローを終了する前のマネージドBeanの値までマネージドBeanの値がリセットされます。マネージドBeanの値は、再開されたバインド・タスク・フローのビュー・アクティビティがレンダリングされる前にリセットされます。バインド・タスク・フローの再開前に行った変更は、すべて失われます。この動作を変更するには、再開されるバインド・タスク・フローのビュー・アクティビティに<redirect>要素を指定します。エンド・ユーザーが「戻る」ボタンを使用してバインド・タスク・フローを再開すると、マネージドBeanは、再開された子タスク・フローからの元の値ではなく、親タスク・フローからの新しい値を保持します。

22.5 タスク・フローでの例外の処理

タスク・フローの実行時には、なんらかの例外処理を必要とする、次のような例外が発生する場合があります。

メソッド・コール・アクティビティからスローされる例外。
タスク・フローのイニシャライザまたはファイナライザとして記述したカスタム・メソッドからスローされる例外。
アクティビティの実行権限がないユーザー。

アクティビティからスローされる例外や、ADF Controllerのその他のタイプのエラーから生じる例外を処理するために、バインド・タスク・フローまたはバインドなしタスク・フローの1つのアクティビティを、例外ハンドラとして指定できます。

タスク・フローが例外をスローすると、制御フローは指定された例外処理アクティビティに渡されます。たとえば、例外処理アクティビティは、エラー・メッセージを表示するビュー・アクティビティである場合があります。また、例外のタイプを評価するEL式に基づいてメソッドに制御フローを渡すルーター・アクティビティである場合もあります。たとえば、次のように入力します。

#{controllerContext.currentViewPort.exceptionData.class.name == 'oracle.adf.controller.ControllerException'}

制御フローが例外処理アクティビティに渡された後、その例外処理アクティビティからのフローには、標準の制御フロー・ルールが使用されます。たとえば、例外処理アクティビティとしてルーター・アクティビティを指定するとします。実行時、例外に反応して、タスク・フローから例外処理アクティビティ(この場合はルーター・アクティビティ)に制御が渡されます。例外ハンドラとしてルーター・アクティビティを指定した上で、処理の対象となる例外のタイプに基づいてルーターが起動するタスク・フロー制御ケースを定義できます。これにより、例外発生時にエンド・ユーザーのアプリケーション・セッションを適切に管理できます。詳細は、18.1.3項「制御フローについて」を参照してください。

オプションで、バインド・タスク・フローおよびバインドなしタスク・フローの両方に対する例外ハンドラを指定できます。各タスク・フローは、例外ハンドラを1つのみ保持できます。ただし、別のタスク・フローからコールされるタスク・フローは、コール元の例外ハンドラ以外に別の例外ハンドラを1つ保持できます。さらに、ページ上のリージョンは、ページを含むタスク・フローとは別の例外ハンドラを保持できます。例外ハンドラのアクティビティとしては、ビュー・アクティビティやルーター・アクティビティなど、サポートされる任意のアクティビティ・タイプを使用できます。

バインド・タスク・フローに指定されている例外ハンドラのアクティビティがない場合、コール元のタスク・フローがあり、そこに例外ハンドラのアクティビティがあれば、コール元バインド・タスク・フローの例外ハンドラのアクティビティに制御が渡されます。例外は、例外ハンドラのアクティビティまたは最上位のバインドなしタスク・フローに到達するまで、タスク・フローのスタックに伝播されます。例外ハンドラが見つからない場合、例外はWebコンテナに伝播されます。

バインド・タスク・フローに例外ハンドラ・アクティビティが指定されている場合は、その例外ハンドラ・アクティビティによって例外が処理された後も、アプリケーションが有効なままになるようにしてください。その方法の1つは、例外ハンドラ・アクティビティの後、同じタスク・フローのビュー・アクティビティにリダイレクトすることです。

また、ADF Modelなどの他のモジュールには例外処理機能が実装されています。一部では、アプリケーションでの例外の処理方法を決定できるケースもあります。たとえば、データバインド・メソッド・アクティビティは、ページ定義とEL式を次の形式で有するメソッド・アクティビティです。

#{bindings.somebindingname.execute}

ここで、somebindingnameは、ページ定義で設定されたメソッド・バインディングです。

どのタイプのバインディングが例外をスローしても、reportException()メソッドをコールし、バインディング・コンテナに例外を格納するADF Modelによって取得されます。その後、ページのレンダリング時に、ページにエラーが表示されます。

メソッド・アクティビティがメソッド・バインディングを起動すると、例外により発生したエラーを表示するページがなくなるのは、2つのページ間の移動時に例外が発生するからです。アプリケーションにエラーを認識させるには、Oracle ADFに例外を再スローさせて、例外ハンドラ・アクティビティがあればそこに移動するADFコントローラ例外ハンドラ・メカニズムによってその例外を取得します。

16.3項「エラー処理のカスタマイズ」の説明のとおり、特に、reportException()メソッドなど、メソッドの上書きを決定した場合に注意が必要なのは、このケースではADFコントローラとADF Modelの例外ハンドラの両方がコールされるからです。

22.5.1 例外ハンドラとしてアクティビティを指定する方法

ADFリージョンとして実行されるバインド・タスク・フローに対して例外ハンドラ・アクティビティを指定できます。バインド・タスク・フローで発生した例外がタスク・フローの例外ハンドラで処理されない場合、その例外は親ページのタスク・フローのスタックには伝播されません。かわりに、その例外は未処理の例外となります。

作業を始める前に、次のようにします。

タスク・フローで構成可能な例外処理オプションの内容を理解しておくと役に立つ場合があります。詳細は、22.5項「タスク・フローでの例外の処理」を参照してください。

タスク・フローの例外ハンドラとしてアクティビティを指定する手順:

タスク・フロー・ダイアグラム内のアクティビティを右クリックして、「アクティビティのマーク」→「例外ハンドラ」の順に選択します。

タスク・フロー内のアクティビティ上に、例外ハンドラであることを示す赤い感嘆符が表示されます。図22-3に例を示します。

図22-3 例外ハンドラとして指定されたアクティビティの例
アクティビティのマークを外すには、タスク・フロー・ダイアグラム内のアクティビティを右クリックして、「アクティビティのマーク解除」→「例外ハンドラ」の順に選択します。

指定された例外ハンドラがすでに存在するタスク・フロー内で、アクティビティを例外ハンドラとしてマークすると、古いハンドラのマークは解除されます。

22.5.2 例外ハンドラとしてアクティビティを指定した場合の処理

あるアクティビティをタスク・フローの例外処理アクティビティとして指定すると、例22-4に示すように、アクティビティのIDを指定する<exception-handler>要素を使用してタスク・フローのメタデータが更新されます。

例22-4 <exception-handler>要素

<exception-handler id="__8>activityID</exception-handler>

22.5.3 例外ハンドラとしてカスタム・コードを指定する方法

起動するアクティビティとしてタスク・フロー・アクティビティを指定するかわりに、タスク・フローによる例外のスロー時に起動するカスタム・コードを記述できます。これには次の処理が必要です。

次のパッケージのクラスExceptionHandlerを拡張するJavaクラスを記述します。

oracle.adf.view.rich.context.ExceptionHandler
Fusion Webアプリケーションの.adf\META-INFディレクトリ内のサービスとして記述するJavaクラスを登録します。

例22-5は、タスク・フローによってスローされる例外が特定のタイプのエラー・メッセージ(ADF_FACES-30108)に対応するかどうかをチェックするカスタム・コードを示しています。対応する場合は、カスタム・コードによって、タスク・フローがfaces/SessionExpired.jspxページにリダイレクトされます。

例22-5 例外ハンドラのカスタム・コード

package oracle.fodemo.frmwkext;

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseId;
import oracle.adf.view.rich.context.ExceptionHandler;
 
public class CustomExceptionHandler extends ExceptionHandler {
 
    public CustomExceptionHandler() {
        super();
    }
 
    public void handleException(FacesContext facesContext, Throwable throwable,
                                PhaseId phaseId) throws Throwable {
        
        String error_message;
        error_message = throwable.getMessage();
        
        if (error_message != null &&
            error_message.indexOf("ADF_FACES-30108") > -1) {
            ExternalContext ectx = facesContext.getExternalContext();
            ectx.redirect("faces/SessionExpired.jspx");
        }
 
        else {
            //Code to execute if the if condition is not met
            throw Throwable
        }
    }
}

カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。

Oracle Fusion Middleware Oracle ADF Controller Java APIリファレンス
Oracle Fusion Middleware Java APIリファレンス for Oracle ADF Faces

作業を始める前に、次のようにします。

例外ハンドラとしてカスタム・コードを指定する手順:

アプリケーションの.adf\META-INFディレクトリで、servicesと呼ばれるディレクトリを作成して、次のディレクトリ・パスを取得します。

application_root\.adf\META-INF\services

ここで、application_rootは、アプリケーションのルート・ディレクトリを参照します。
servicesフォルダ内に、oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイルを作成します。
oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイルで例外を処理するには、記述したカスタム・コードのパッケージ名およびクラス名を記述します。

たとえば、例22-5のカスタム・コードを登録する場合は、次を記述します。

oracle.fodemo.frmwkext.CustomExceptionHandler
テキスト・ファイルを保存して閉じます。

22.5.4 例外ハンドラとしてカスタム・コードを指定した場合の処理

実行時にタスク・フローが例外をスローすると、制御は指定されたカスタム・コードに渡されます。

22.5.5 トランザクション中の例外の処理について

トランザクションとして実行可能なバインド・タスク・フローの例外処理アクティビティを指定します。トランザクションとして実行されるバインド・タスク・フローで、タスク・フロー・リターン・アクティビティの「トランザクションの終了」プロパティの値をcommitに設定した場合は、Fusion Webアプリケーションによってトランザクションのコミットが試行されます。Fusion Webアプリケーションによるトランザクションのコミット試行時に例外が発生した場合、例外処理アクティビティは制御を受け取り、エンド・ユーザーに例外を修正する機会を提供します。例外処理アクティビティ(たとえば、ビュー・アクティビティ)を使用して、例外の修正方法およびトランザクションの再コミット方法に関する情報を含む警告メッセージを、エンド・ユーザーに対して表示できます。トランザクションとしてバインド・タスク・フローを有効化する方法、および「トランザクションの終了」プロパティの値としてcommitを設定する方法の詳細は、22.3.1項「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。

22.5.6 検証エラーの処理について

JSFページの検証エラーの場合、検証エラー・メッセージのページ上の特定のコンポーネントまたはページ全体への添付を標準JSFに依存できます。コンポーネント・レベルのバリデータでは、通常、特定のUIコンポーネントにインラインでエラー・メッセージが添付されます。例外ハンドラのアクティビティに制御を渡す必要はありません。

また、使用するアプリケーションでは、検証ロジックをJSFライフサイクルのモデル更新検証フェーズで実行されるデータ・コントロールに定義する必要があります。このようにすると、最終的なコミットの試行まで待たずに、サーバーへの送信時にデータ・エラーが検出されます。

モデル更新検証フェーズで行われる検証は、通常、モデルの更新後にモデルを検証することを目的としているため、UIコンポーネントに直接アクセスすることはありません。このような検証の多くは、依存するフィールドが同期しているかどうかのチェックなどです。その場合、エラー・メッセージは通常、このロジックがアクセスするページ全体に添付されます。

モデル更新検証フェーズで検出されたエラーをJSFページに添付して、FacesContext.renderResponse()をコールする必要があります。これによって、このフェーズの後に現在の(送信)ページがレンダリングされ、添付されたエラー・メッセージが表示されます。例外ハンドラのアクティビティに制御を渡す必要はありません。

詳細は、第8章「プログラムによる検証とビジネス・ルールの実装」を参照してください。

22.6 セーブポイントを使用するためのアプリケーションの構成

22.7項「タスク・フローでのセーブポイントの使用」の説明に従ってタスク・フローにセーブポイントを追加し、関連する機能を構成するには、 Fusion Webアプリケーションでセーブポイントを使用できることを確認しておく必要があります。これを行うには、adf-config.xmlファイルの<savepoint-datasource>要素の値を定義して、セーブポイントのデータベース表を含むデータソースのJNDI名を指定します。また、22.6.3項「セーブポイントのデータベース表について」の説明に従ってSQLスクリプト(adfc_create_save_point_table.sql)を実行し、セーブポイントを格納するデータベース表を作成する必要があります。Fusion Webアプリケーションでセーブポイントの使用を開始した後は、別のSQLスクリプト(adfc_cleanup_save_point_table.sql)を使用して、期限切れのセーブポイントを削除できます。

22.6.1 セーブポイントを使用するためのFusion Webアプリケーションの構成方法

アプリケーションのadf-config.xmlファイルの<savepoint-datasource>要素の値を定義して、セーブポイントのデータベース表を含むデータソースのJNDI名を指定します。オプションとして、セーブポイントの有効期限も指定できます。

作業を始める前に、次のようにします。

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、22.6項「セーブポイントを使用するためのアプリケーションの構成」を参照してください。

セーブポイントを使用可能にするためのFusion Webアプリケーションの構成手順:

JDeveloperでFusion Webアプリケーションを開いた状態で、「アプリケーション・ナビゲータ」の「アプリケーション・リソース」ペインを開きます。
「ディスクリプタ」および「ADF META-INF」を展開します。
adf-config.xmlを右クリックし、ポップアップ・メニューから「開く」を選択します。
概要エディタの「コントローラ」ページで、セーブポイントのデータベース表が含まれているデータソースのJNDI名を指定するために、「データソース」プロパティの値を記述します。

たとえば、次のように記述します。

java:comp/env/jdbc/Connection1DS

Connection1はJDeveloper接続名です。
オプションとして、「存続時間」プロパティの値を秒単位で記述して、セーブポイントがタスク・フローで作成されてからセーブポイント・マネージャによって削除されるまでの時間を指定します。デフォルト値も86400秒です。

詳細は、22.7.9項「セーブポイントの存続時間について」を参照してください。
adf-config.xmlファイルを保存します。

22.6.2 セーブポイントを使用するためにFusion Webアプリケーションを構成した場合の処理

セーブポイントのデータベース表が含まれているデータソースのJNDI名を指定する例22-6のようなエントリが、adf-config.xmlファイル内に生成されます。

例22-6 adf-config.xml内のセーブポイントのデータソース定義

<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
    ...
    <savepoint-datasource>
      java:comp/env/jdbc/Connection1DS
    </savepoint-datasource>
    <savepoint-expiration>
      86399
    </savepoint-expiration>
  </adf-controller-config>

adf-config.xmlファイルの詳細は、A.11項「adf-config.xml」を参照してください。

22.6.3 セーブポイントのデータベース表について

ORADFCSAVPTという名前のデータベース表にセーブポイントが格納されます。このデータベース表が存在しない場合、使用するFusion Webアプリケーションにデータベース表の作成に必要な権限があれば、セーブポイントの初回作成時に作成されます。Fusion Webアプリケーションに必要な権限がない場合は、必要な権限を持つユーザーまたは管理者がSQLスクリプトを使用して、ORADFCSAVPTデータベース表を作成および管理できます。それらのSQLスクリプトは次のとおりです。

adfc_cleanup_save_point_table.sql

ORADFCSAVPTデータベース表内の各セーブポイントには、有効期限があります。このスクリプトを使用して、有効期限が切れたセーブポイントを削除します。
adfc_create_save_point_table.sql

このスクリプトを使用して、セーブポイントを格納するORADFCSAVPTデータベース表を作成します。

これらのSQLスクリプトは、JDeveloperインストールの次のディレクトリにあります。

jdev_install\oracle_common\common\sql

22.7 タスク・フローでのセーブポイントの使用

セーブポイントと呼ばれる機能を作成して、特定のインスタンスでFusion Webアプリケーションの状態を取得するタスク・フローを構成できます。これにより、たとえばユーザーがページを完了せずにそのページから移動する場合などに、アプリケーションの状態を保存できるようになります。アプリケーションの状態は、後でリストアできます。

表22-2に、セーブポイントでキャプチャされる情報を示します。

表22-2 保存されるアプリケーションの状態に関する情報

保存される状態情報	説明
ユーザー・インタフェースの状態	現在のページのUIの状態。選択中のタブ、選択中のチェック・ボックス、選択中の表の行、表の列のソート順など。この状態は、エンド・ユーザーがセーブポイントのリストアでブラウザの「戻る」ボタンを選択できない場合を想定しています。
マネージドBean	セッション・スコープやページ・フロー・スコープなど、使用可能な複数のメモリー・スコープに保存される状態の情報。マネージドBeanを保存するには、シリアライズ可能であることが必要です。シリアライズ可能でないページ・フロー・スコープBeanがある場合にセーブポイントを作成しようとすると、実行時例外が発生します。リクエスト・スコープは、存続期間が単一のHTTPリクエストであり、その存続期間をリクエスト間のアプリケーション状態の格納には使用できないため、サポートされません。アプリケーション・スコープのマネージドBeanは、フェイルオーバーのシナリオでは受動化されないため、セーブポイントによって保存およびリストアされません。したがって、アプリケーションでは必要なアプリケーション・スコープの状態を常にすべて使用可能にしておく必要があります。同じ名前を使用するマネージドBeanはアプリケーション内に複数実装できないため、リストア時にセッション・スコープ内の既存のマネージドBeanの名前が競合することはありません。
ナビゲーションの状態	実行時に、あるタスク・フローが別のタスク・フローをコールするとADFコントローラで保持されるタスク・フロー・コール・スタック。タスク・フロー・コール・スタックでは、アプリケーション内のエンド・ユーザーの位置、およびそこに至るまでのナビゲーション・パスが追跡されます。また、エンド・ユーザーが開始した永続データ・トランザクションの開始点も識別されます。
ADFモデルの状態	Fusion Webアプリケーションでは、永続データ・モデルやビジネス・ロジックのサービス・プロバイダがADFモデルで表されます。ADFモデルには、現在のバインド・タスク・フローの開始以降に行われたデータ・モデルの更新がすべて保持されます。保存された状態の存続期間に対する制限はモデル・レイヤーにより決定します。詳細は、第43章「アプリケーション状態管理」を参照してください。

createSavePointメソッドを起動するメソッド・コール・アクティビティをバインド・タスク・フローに追加して、セーブポイントを作成します。後でセーブポイント・リストア・アクティビティを使用して、作成したセーブポイントに関連付けられたアプリケーションの状態とデータをリストアします。

同一ブラウザ・ウィンドウ内の同一セッションで実行されるタスク・フロー・インスタンスにおいて、ユーザーが後で使用するための保存を繰り返し実行する場合、同じセーブポイントを使用できます。タスク・フローのページごとのナビゲーションに従って、ユーザーが後で使用するための保存を実行すると、既存のセーブポイントが新しいセーブポイントで上書きされます。セーブポイントのリストアの詳細は、22.7.3項「セーブポイントのリストア方法」を参照してください。

式ビルダーのADF ControllerオブジェクトのcurrentViewPortノードによって公開される、createSavePointメソッドを指定できます。もしくは、カスタム・メソッドで指定する属性の値を使用してセーブポイントを更新する、例22-7のようなカスタム・メソッドを記述できます。

例22-7 セーブポイントを作成するためのカスタム・メソッドの例

package viewController;
 
import java.io.Serializable;
 
import oracle.adf.controller.ControllerContext;
import oracle.adf.controller.savepoint.SavePointManager;
 
public class SaveForLater implements Serializable {
    public SaveForLater() {
        super();
    }
 
    public String saveTaskFlow() {
        ControllerContext cc = ControllerContext.getInstance();
        if (cc != null) {
            SavePointManager mgr = cc.getSavePointManager();
            if (mgr != null) {
                String id = mgr.createSavePoint();
                System.out.println("Save point is being set " + id);
            ...

SavePointListenerインタフェースは、セーブポイント・イベントの発生時にクライアントに通知するメソッドを公開します。SavePointListenerインタフェースは次のパッケージに含まれています。

oracle.adf.controller.savepoint

注意:

バインド・タスク・フロー内で作成されたすべてのセーブポイントは、バインド・タスク・フローの終了時に削除されます。

22.7.1 タスク・フローへのセーブポイントの追加方法

メソッド・コール・アクティビティをタスク・フローにドラッグ・アンド・ドロップして、createSavePointメソッドまたは(作成した場合は)カスタム・メソッドを起動するように構成します。

作業を始める前に、次のようにします。

タスク・フローで構成可能なセーブポイント・オプションの内容を理解しておくと役に立つ場合があります。詳細は、22.7項「タスク・フローでのセーブポイントの使用」を参照してください。

Fusion Webアプリケーションでセーブポイントを使用するには、jbo.locking.modeプロパティの値をデフォルト値optimisticのままにしておく必要があります。値pessimisticを使用すると、古いセッションはタイムアウトするまでロックされます。ペシミスティック・モードでは、アプリケーションを実行してデータを変更し、データベースに変更をコミットしなかった場合、セーブポイントを作成して後でリストアしようとするとエラーが発生する可能性があります。jbo.locking.modeプロパティの詳細は、43.11.1項「アプリケーションでのオプティミスティック・ロックの使用の確認方法」を参照してください。

タスク・フローへのセーブポイントの追加手順:

構成するバインド・タスク・フローを開いてダイアグラム・エディタに移動します。
「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルからダイアグラムへ「メソッド・コール」アクティビティをドラッグ・アンド・ドロップします。
プロパティ・インスペクタで「一般」ノードを開き、「メソッド」プロパティのEL式を記述して、メソッド・コール・アクティビティで起動するセーブポイント・メソッドを指定します。

式ビルダーを使用して、ADF ControllerオブジェクトのcurrentViewPortノードによって公開されるcreateSavePointメソッドを指定する場合は、次のようなEL式が生成されます。

#{controllerContext.currentViewPort.createSavePoint}
制御フローを使用して、メソッド・コール・アクティビティをバインド・タスク・フロー内の他のアクティビティに接続します。

詳細は、18.4.1項「タスク・フローに制御フロー・ルールを追加する方法」を参照してください。
オプションとして、Fusion Webアプリケーションのadf-config.xmlファイルでセーブポイント・オプションを構成して、そのアプリケーションに対して暗黙的なセーブポイントを作成できるかどうかなどを指定できます。

詳細は、22.7.7項「暗黙的なセーブポイントを有効化する方法」を参照してください。

22.7.2 タスク・フローにセーブポイントを追加した場合の処理

createSavePointメソッドを起動するためのメソッド・コール・アクティビティを構成すると、タスク・フローのソース・ファイルに例22-8のようなエントリが生成されます。

例22-8 createSavePointメソッドを起動するためのメソッド・コールのメタデータ

<method-call id="methodCall1">
      <method id="__3">#{controllerContext.currentViewPort.createSavePoint}</method>
    </method-call>

22.7.3 セーブポイントのリストア方法

セーブポイント・リストア・アクティビティを使用すると、アプリケーション用に以前に保持されたセーブポイントをリストアできます。セーブポイント・リストア・アクティビティでは、最初にcreateSavePointメソッドを起動して作成されたセーブポイントを使用して、リストアするセーブポイントが識別されます。

現在保持されているセーブポイントのリストは、createSavePointで取得できます。ただし、リストア対象のセーブポイントは自動的に判別されません。ユーザーがリストからセーブポイントを選択するか、アプリケーション開発者がプログラムでセーブポイントを選択する必要があります。その後、セーブポイントのIDが、リストアを実行するセーブ・ポイント・リストア・アクティビティに渡されます。

作業を始める前に、次のようにします。

セーブポイント・リストア・アクティビティをバインド・タスク・フローまたはバインドなしタスク・フローに追加する手順:

セーブポイント・リストア・アクティビティを追加するバインド・タスク・フローまたはバインドなしタスク・フローを開き、ダイアグラム・エディタに移動します。
「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルから「セーブポイントのリストア」アクティビティをドラッグして、タスク・フローのダイアグラムへドロップします。
プロパティ・インスペクタで「一般」ノードを開き、評価されるとcreateSavePointメソッドの起動時に最初に作成されたセーブポイントを取得する「セーブポイントID」プロパティのEL式を記述します。

式ビルダーを使用してADF ControllerオブジェクトのgetSavePointメソッドを指定する場合は、次のようなEL式が生成されます。

#{SessionScope.myBean.savepointID}

22.7.4 セーブポイントのリストア時の処理

セーブポイントIDを取得するセーブ・ポイント・リストア・アクティビティを追加すると、タスク・フローのソース・ファイルに例22-9のようなエントリが生成されます。

例22-9 タスク・フロー内のセーブポイント・リストア・アクティビティのメタデータ

<save-point-restore id="savePointRestore1">
      <save-point-id id="__4">#{sessionScope.myBean.savepointID}</save-point-id>
    </save-point-restore>

22.7.5 セーブポイント・リストア・ファイナライザの使用方法

セーブポイント・リストア・アクティビティの使用時には、アプリケーション状態のリストアの一部として、アプリケーション固有のロジックを起動することが必要な場合があります。ファイナライザ・メソッドを指定する、バインド・タスク・フローの「セーブポイントのリストア・ファイナライザ」プロパティのEL式を記述できます。バインド・タスク・フローの状態がリストアされた後、指定したメソッドがタスク・フローによって起動されます。リストアを続行する前に、アプリケーションの状態が正しいことを確認するために必要なロジックが実行されます。

作業を始める前に、次のようにします。

セーブポイント・リストア・ファイナライザの使用手順:

構造ウィンドウでバインド・タスク・フローのノード(task-flow-definition)を右クリックし、「プロパティに移動」を選択します。
プロパティ・インスペクタで「一般」タブを開き、「セーブポイントのリストア・ファイナライザ」ドロップダウン・メニューから「式ビルダー」を選択します。
起動するファイナライザ・メソッドを指定するEL式を記述します。

22.7.6 タスク・フローによるセーブポイント・リストア・ファイナライザ起動時の処理

「セーブポイントのリストア・ファイナライザ」プロパティのEL式を記述すると、タスク・フローのソース・ファイルに例22-10と類似するエントリが生成されます。

例22-10 セーブポイント・リストア・ファイナライザを起動するためのメタデータ

<task-flow-definition id="task-flow-definition1">
    <save-point-restore-finalizer id="__2">#{sessionScope.MyBean.invokeFinalizer}
      </save-point-restore-finalizer>
  </task-flow-definition>

22.7.7 暗黙的なセーブポイントを有効化する方法

タスク・フローのセーブポイントは、黙示的または明示的に分類できます。明示的セーブポイントをバインド・タスク・フローまたはバインドなしタスク・フローで作成するには、エンド・ユーザーのアクションが必要です。たとえば、エンド・ユーザーがボタンをクリックするとメソッド・コール・アクティビティが起動し、結果としてセーブポイントが作成されます。

暗黙的な保存は、バインド・タスク・フローからのみ実行できます。元のタスク・フローでセーブポイントが作成された時のあらゆるものが含まれます。これは、次の理由でデータが自動的に保存される場合に実行されます。

エンド・ユーザーが非アクティブ状態であったことによりセッションがタイムアウトした場合
エンド・ユーザーがデータを保存せずにログアウトした場合
エンド・ユーザーが唯一のブラウザ・ウィンドウを閉じて、アプリケーションをログアウトした場合
エンド・ユーザーがデータを保存せずに制御フロー・ルール(たとえば、外部URLに移動するためのgoLinkコンポーネント)を使用して現在のアプリケーションから移動した場合

暗黙的セーブポイントを有効化するには、使用するFusion Webアプリケーションのadf-config.xmlファイルに要素を追加して、そのバインド・タスク・フローを重要として指定する必要があります。

使用するアプリケーションのadf-config.xmlファイル、および暗黙的セーブポイントを作成するバインド・タスク・フローを構成します。暗黙的セーブポイントを有効化すると、Fusion Webアプリケーションで(有効化しない場合には行われない)追加の処理を行う必要があるため、パフォーマンス上のコストがかかります。そのため、アプリケーションで暗黙的セーブポイントを明示的に有効化し、適用されるタスク・フローを指定する必要があります。

作業を始める前に、次のようにします。

暗黙的セーブポイントの有効化の手順:

「アプリケーション・ナビゲータ」の「アプリケーション・リソース」パネルで、「ディスクリプタ」→「ADF META-INF」の順に開きます。
adf-config.xmlを右クリックし、ポップアップ・メニューから「開く」を選択します。
概要エディタの「コントローラ」ページで、「暗黙的セーブポイントの有効化」チェック・ボックスを選択します。

adf-config.xmlファイル内に次のエントリが生成されます。
```
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config">
    ...
    <enable-implicit-savepoints>true</enable-implicit-savepoints>
</adf-controller-config>
```
adf-config.xmlファイルの詳細は、A.9項「adfc-config.xml」を参照してください。
「アプリケーション・ナビゲータ」で、バインド・タスク・フローのソース・ファイルをダブルクリックします。
概要エディタで「動作」ナビゲーション・タブをクリックし、「クリティカル」チェック・ボックスを選択します。

22.7.8 暗黙的セーブポイントの有効化について

暗黙的セーブポイントの作成時に複数のウィンドウが開いている場合は、それぞれのブラウザ・ウィンドウに対して異なるセーブポイントが作成されます。これには、ブラウザ・ウィンドウのルート・ビュー・ポート以降のあらゆるものが含まれます。ADF Controllerオブジェクトの下にあるsavePointManagerノードを使用すると、暗黙的セーブポイントのリストを取得するメソッド・コール・アクティビティのメソッド・プロパティに対するEL式を記述できます。生成されるEL式は、次のようになります。

ControllerContext.savePointManager.listSavePointIds

暗黙的なセーブポイントは、現在のルート・ビュー・ポートの下のビュー・ポートに対するページ・フロー・スタックに重要なタスク・フローが存在する場合にのみ生成されます。次のようなADF Controllerリソースに対するリクエストでは、暗黙的なセーブポイントは生成されません。

タスク・フロー・コール・アクティビティ
タスク・フロー・リターン・アクティビティ
セーブポイント・リストア・アクティビティ
ダイアログ

スタックの最下位のタスク・フローが完了したときか、新しい暗黙的なセーブポイントが生成されたときのいずれか早い方で、暗黙的なセーブポイントは削除されます。

22.7.9 セーブポイントの存続時間について

adf-config.xmlファイルで定義されるアプリケーション・レベルのプロパティ(savepoint-expiration)は、セーブポイントがタスク・フローで作成されてからセーブポイント・マネージャによって削除されるまでの時間(存続時間)を決定します。デフォルト値は86400秒(24時間)です。

個々のセーブポイントの存続時間を変更するには、次のパッケージに含まれるSavePointMangerのインスタンスに対してsetSavePointTimeToLiveメソッドをコールします。

oracle.adf.controller.savepoint

SavePointManagerのインスタンスは、次のようにして取得できます。

SavePointManager mgr = ControllerContext.getInstance().getSavePointManager();

例22-11に、setSavePointTimeToLiveメソッドの構文を示します。

例22-11 setSavePointTimeToLiveメソッドの構文

    public void setSavePointTimeToLive(long timeInSeconds) {
       }

setSavePointTimeToLiveメソッドの引数 (例22-11ではtimeInSeconds)に対してゼロ以下の値を指定した場合は、デフォルト値(86400)が使用されます。

SavePointMangerは、セーブポイントの管理に役立つメソッドを定義します。たとえば、セーブポイントの取得および削除を実行できるgetSavePointおよびremoveSavePointメソッドを定義します。removeSavePointメソッドは、セーブポイントが期限切れになると自動的にコールされるものではありません。ORADFCSAVPTデータベース表からセーブポイント(期限切れのセーブポイントを含む)を削除するには、明示的にremoveSavePointメソッドをコールする必要があります。代替方法として、Oracle ADFには期限切れのセーブポイントを削除するSQLスクリプト(adfc_cleanup_save_point_table.sql)が用意されています。詳細は、22.6.3項「セーブポイントのデータベース表について」を参照してください。

セーブポイントを作成するためのメソッド(例22-7を参照)をコールするのと同時に、setSavePointTimeToLiveメソッドをコールすることを検討してください。SavePointMangerの詳細は、Oracle Fusion Middleware Oracle ADF Controller Java APIリファレンスを参照してください。

22.8 バインド・タスク・フローでのトレイン・コンポーネントの使用

タスク・フローをトレインとして作成できます。これにより、マルチステップ・プロセスを使用してエンド・ユーザーを移動するユーザー・インタフェースを作成できます。たとえば、Fusion Order Demoアプリケーションの顧客登録タスク・フローでは、複数のトレイン・ストップを使用してエンド・ユーザーを移動するトレインをレンダリングし、図22-4に示すように顧客登録プロセスを完了します。

ADF Facesには、エンド・ユーザーに表示されるタスク・フロー・ビュー・アクティビティのトレイン機能をレンダリングするユーザー・インタフェース・コンポーネントが実装されています。これらのコンポーネントは、trainコンポーネントおよびtrainButtonBarコンポーネントです。図22-4は、trainコンポーネントおよびtrainButtonBarコンポーネントを使用したdefineAddresses.jsffページ(タスク・フロー・ビュー・アクティビティ)が示されており、ここでは顧客登録タスク・フローのアドレス作成手順を使用してエンド・ユーザーを移動します。

図22-4 顧客登録タスク・フローでのトレイン・コンポーネントおよびトレイン・ボタン・バー・コンポーネント

図22-4のtrainコンポーネントでは、4つのトレイン・ストップがレンダリングされます。各ストップは、顧客登録タスク・フローのページ・フラグメントに対応しており、ここではエンド・ユーザーが情報の入力と確認を行い、登録プロセスを完了できます。図22-4は、エンド・ユーザーが郵便用アドレスを入力するアドレス・トレイン・ストップを示しています。他のストップは次のようになります。

基本情報
支払方法
確認

図22-4で示したトレイン・ボタン・バー・コンポーネントはオプションで、トレイン・ストップ間を移動する追加のコントロールが実装されています。このコンポーネントをトレイン・コンポーネントと併用すると、トレイン・ストップ間を複数の方法で移動できます。

JDeveloperによって提供されるダイアログ上で「トレインの作成」チェック・ボックスを選択し、バインド・タスク・フローまたはタスク・フロー・テンプレートを作成した場合は、バインド・タスク・フローおよびタスク・フロー・テンプレートではこれらのトレイン・コンポーネントを利用できます。バインド・タスク・フローまたはタスク・フロー・テンプレートでは1つのトレインのみをレンダリングできます。複数のトレインの使用が必要な場合は、各トレインで別にバインド・タスク・フローまたはタスク・フロー・テンプレートを作成します。

図22-5は、顧客登録タスク・フローの設計時のビューから取得した抜粋が表示されています。ここでは、図22-4でBasic InformationおよびAddressとして実行時にレンダリングされたビュー・アクティビティのbasicInformationおよびdefineAddressesを確認できます。

goNextとラベル付けされた点線は、basicInformationビュー・アクティビティをdefineAddressesビュー・アクティビティに接続し、ビュー・アクティビティがトレイン・ストップとしてレンダリングされたときに、エンド・ユーザーがビュー・アクティビティ間を移動する順序を示します。

図22-5 顧客登録タスク・フローの詳細

図22-6で示したように、トレイン・ストップとして構成されたビュー・アクティビティまたはタスク・フロー・コール・アクティビティを右クリックすると、JDeveloperではアクティビティの場所を変更するコンテキスト・メニューのオプションが表示されます。

図22-6 トレイン・ストップを編集するコンテキスト・メニュー

複数のアクティビティを1つのトレイン・ストップとしてグループ化するか、または子トレイン・ストップをコールする場合は、タスク・フロー・コール・アクティビティをトレイン・ストップとして構成します。たとえば、ルーターやメソッド・コール・アクティビティなどの他のタスク・フロー・アクティビティを、対応するビュー・アクティビティとともにトレイン・ストップの一部とみなす場合があります。初期化のため、メソッド・コール・アクティビティをビュー・アクティビティの前に配置する場合もあります。このようにグループ化することで、トレイン・ストップにアクセスするたびに一連のアクティビティがセットとして実行されるように指定できます。詳細は、22.8.3項「トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化」を参照してください。

ルーター・アクティビティや制御フロー・ケースによるブランチ化は、トレインを含むタスク・フロー・ダイアグラムでも、そのトレインからコールされる子バインド・タスク・フローでもサポートされます。

22.8.1 タスク・フローのトレインとしての作成

22.8項「バインド・タスク・フローでのトレイン・コンポーネントの使用」で説明した機能が実装可能になる前にトレイン・コンポーネントを使用するには、バインド・タスク・フローを構成する必要があります。次のリストで説明するメソッドのいずれかを使用して、トレイン・コンポーネントを使用するバインド・タスク・フローを構成します。

新しいバインド・タスク・フローまたはタスク・フロー・テンプレートを作成する場合は、JDeveloperで表示されるダイアログの「トレインの作成」チェック・ボックスを選択します。

詳細は、18.2項「タスク・フローの作成」または22.9項「タスク・フロー・テンプレートの作成」を参照してください。
ダイアグラムで既存のバインド・タスク・フローを右クリックして、JDeveloperで表示されるコンテキスト・メニューから、「トレイン」→「トレインの作成」を選択します。
概要エディタで既存のバインド・タスク・フローを開き、「動作」ナビゲーション・タブをクリックして、「トレイン」チェック・ボックスを選択します。

バインド・タスク・フローを構成し、トレイン・コンポーネントを使用している場合は、トレインでレンダリングが必要なタスク・フロー・アクティビティをバインド・タスク・フローのダイアグラムにドラッグ・アンド・ドロップします。

22.8.1.1 バインド・タスク・フローでのトレインの作成方法

トレインでレンダリングが必要なタスク・フロー・アクティビティをバインド・タスク・フローのダイアグラムにドラッグ・アンド・ドロップします。

作業を始める前に、次のようにします。

22.8項「バインド・タスク・フローでのトレイン・コンポーネントの使用」の説明に従って、バインド・タスク・フローでトレイン・コンポーネントを使用するように構成していることを確認します。

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、22.8.1項「タスク・フローのトレインとしての作成」を参照してください。

バインド・タスク・フローでトレインを作成する手順:

トレイン・ストップのレンダリングが必要なバインド・タスク・フローまたはタスク・フロー・テンプレートを開きます。
トレインで追加が必要なビュー・アクティビティまたはJSFページをそれぞれバインド・タスク・フローのダイアグラムにドラッグします。
- JSFページをドラッグすると、ビュー・アクティビティがダイアグラムに自動的に追加されます。
- ダイアグラムにドラッグするすべてのビュー・アクティビティをダブルクリックしてダイアログを起動し、新しいJSFページを作成します。
後で、トレイン・ストップの順序をレンダリングできます。詳細は、22.8.4項「トレインでのトレイン・ストップの順次動作の無効化」を参照してください。
バインド・タスク・フローのダイアグラムで、トレイン・ストップとして定義が必要な各ビュー・アクティビティをダブルクリックします。

ビュー・アクティビティがJSFページとまだ関連付けられていない場合は、JDeveloperでは新規のJSFページを作成するダイアログが表示されます。このダイアログを使用して新しいJSFページを作成します。

ビュー・アクティビティがJSFページとすでに関連付けられている場合は、JDeveloperでそのページが開きます。
「コンポーネント・パレット」の「ADF Faces」ページで、「位置」グループにある「トレイン」コンポーネントおよび必要に応じて「トレイン・ボタン・バー」コンポーネントをドラッグして、JSFページにドロップします。

タスク・フロー・ビュー・アクティビティで表示が必要な「トレイン」コンポーネントおよび「トレイン・ボタン・バー」コンポーネントはそれぞれ手動で追加する必要があります。ページ・テンプレートの使用を検討します。詳細は、24.2項「ページ・テンプレートの使用」を参照してください。

22.8.1.2 トレインとしてのタスク・フローの作成時の処理

22.8.1項「トレインとしてのタスク・フローの作成」で説明したメソッドのいずれかを使用して、JDeveloperでは、トレインとして有効化するバインド・タスク・フローまたはタスク・フロー・テンプレートのソース・ファイルに<train/>要素を記述します。

JDeveloperでは、trainコンポーネントおよびtrainButtonBarコンポーネントを追加するJSFページにエントリを記述します。例22-12は、Fusion Order DemoアプリケーションのdefineAddresses.jsffページ・フラグメントにあるコード・スニペットを示しています。どちらのタイプのトレイン・コンポーネントもトレイン・モデル・オブジェクト(trainModel)のインスタンスにバインドされます。

例22-12 Fusion Order Demoアプリケーションでのトレイン・コンポーネントのメタデータ

 <af:train value="#{controllerContext.currentViewPort.taskFlowContext.trainModel}"
         id="t1"/>
  ...
  <af:trainButtonBar value="#{controllerContext.currentViewPort.taskFlowContext.trainModel}"
        id="tbb1"/>

図22-5に示すとおり、バインド・タスク・フローに追加し、トレイン・ストップとして定義する各ビュー・アクティビティ間には点線が表示されます。点線は、トレイン・ストップをバインド・タスク・フローが移動する順序を示します。JDeveloperでは、バインド・タスク・フローにビュー・アクティビティを追加する順番にシーケンスを定義します。このシーケンスは変更できます。詳細は、22.8.4項「トレインでのトレイン・ストップの順次動作の無効化」を参照してください。トレイン・ストップは省略することもできます。詳細は、22.8.6項「トレイン・ストップを省略するトレインの構成」を参照してください。

22.8.2 トレイン・ストップの子バインド・タスク・フローの起動

22.8.3項「トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化」の説明のとおり、タスク・フロー・アクティビティを1つのトレイン・ストップにグループ化する方法の代替としては、現在のバインド・タスク・フローから起動するトレインとして別のバインド・タスク・フローを作成する方法があります。このバインド・タスク・フローは子バインド・タスク・フローとして参照されます。親バインド・タスク・フローをタスク・フロー・コール・アクティビティを使用して起動するように構成します。この機能を実装するには、次を実行します。

子バインド・タスク・フローをトレインとして作成します。
親バインド・タスク・フロー上のトレイン・ストップから子バインド・タスク・フローに渡って存在する、エンド・ユーザーのアクセスが必要なタスク・フロー・アクティビティを追加します。
子バインド・タスク・フローを起動する親バインド・タスク・フローのトレイン・ストップとしてアクティビティをコールするタスク・フローを指定します。
子バインド・タスク・フローによる実行の終了時に、親バインド・タスク・フローに制御を戻す子バインド・タスク・フローにタスク・フロー・リターン・アクティビティを追加します。

エンド・ユーザーが初めてトレイン・ストップを訪問するのか、または後で戻るのかとは無関係に、子バインド・タスク・フローのタスク・フロー・アクティビティはまとめて実行されます。子バインド・タスク・フローの非ビュー・タスク・フロー・アクティビティは通常、子バインド・タスク・フローのフロー制御にあるビュー・アクティビティより優先されます。別のバインド・タスク・フローの子であるバインド・タスク・フローから子バインド・タスク・フローを起動できます。

22.8.2.1 トレイン・ストップから子バインド・タスク・フローを起動する方法

トレインとして作成したバインド・タスク・フローにタスク・フロー・アクティビティを追加し、そのアクティビティを起動する親バインド・タスク・フロー上にタスク・フロー・コール・アクティビティを構成します。

作業を始める前に、次のようにします。

トレインから起動する子バインド・タスク・フローに構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、22.8.2項「トレイン・ストップの子バインド・タスク・フローの起動」を参照してください。

また、他のタスク・フローの機能を使用して追加可能な機能について読むことが役に立つ場合もあります。詳細は、22.1.2項「複雑なタスク・フローの追加の機能」を参照してください。

トレイン・ストップから子バインド・タスク・フローを起動する手順:

子バインド・タスク・フローをトレインとして作成します。詳細は、22.8.1項「タスク・フローのトレインとしての作成」を参照してください。
子バインド・タスク・フローによる起動が必要なタスク・フロー・アクティビティを子バインド・タスク・フローに追加します。子バインド・タスク・フローによる実行の終了時は特に、親バインド・タスク・フローに制御を戻す子バインド・タスク・フローにタスク・フロー・リターン・アクティビティを確実に追加します。

詳細は、19.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。
実行時に子バインド・タスクを起動するトレイン・ストップとしてレンダリングされる親タスク・フローにはタスク・フロー・コール・アクティビティを追加します。

詳細は、19.6項「タスク・フロー・コール・アクティビティの使用」を参照してください。

22.8.3 トレイン・ストップ間で実行するタスク・フロー・アクティビティのグループ化

単一のトレイン・ストップを形成するタスク・フロー・アクティビティをまとめてグループ化できます。たとえば、実行時に「アドレス」としてレンダリングされるFusion Order Demoアプリケーションのトレイン・ストップでは、次のタスク・フロー・アクティビティがまとめてグループ化されます。

defineAddressビュー・アクティビティ
createAddressメソッド・コール・アクティビティ
addressDetailsビュー・アクティビティ

実行中の「アドレス」トレイン・ストップにユーザーがアクセスするたびに、顧客登録タスク・フローでは、前述でリストしたタスク・フロー・アクティビティにアクセスできます。defineAddressesビュー・アクティビティでは、トレイン・ストップおよび関連付けられたdefineAddresses.jsffページ・フラグメントが動的にレンダリングされます。次に、defineAddresses.jsffページ・フラグメントでは、createAddressメソッド・コール・アクティビティを起動するコマンド・ボタンが公開されます。メソッド・コール・アクティビティでは、「アドレス」ページのユーザー入力が検証され、addressDetailsビュー・アクティビティに制御を(任意に)渡す結果が定義されます。addressDetailsビュー・アクティビティでは、実行時にエンド・ユーザーが追加アドレスの入力を選択できる「アドレス」情報ページがレンダリングされます。

図22-7 1つのトレイン・ストップにグループ化されるタスク・フロー・アクティビティ

トレインでは、最初の非ビュー・アクティビティから次のビュー・アクティビティに渡るすべてのタスク・フロー・アクティビティがトレインの一部であるとみなされます。ビューおよびタスク・フロー・コール・アクティビティを除いた、トレイン・ストップのすべてのタスク・フロー・アクティビティが、トレイン・ストップとして定義したビューまたはタスク・フロー・コール・アクティビティの後に続くことを確認します。

また、トレイン・ストップ間で実行するタスク・フロー・アクティビティをグループ化できます。図22-8は、制御フローがpage2に渡される前に、メソッド・コール・アクティビティ(doSomethingBeforePage2)の起動が可能な構成を示しています。ワイルドカード制御フロー・ルールのcallMethodBeforePage2では、メソッド・コール・アクティビティのdoSomethingBeforePage2に制御が渡されます。このメソッド・コール・アクティビティでは、トレインの次のトレイン・ストップ(page2)に制御を渡す固定結果(continue)が定義されます。

図22-8 トレイン・ストップ間のメソッド・コール・アクティビティ

22.8.4 トレインでのトレイン・ストップの順次動作の無効化

デフォルトでは、トレイン・ストップは順次ストップです。つまり、エンド・ユーザーがトレイン・ストップを選択できるのは、トレインで前のトレイン・ストップにアクセスした場合のみです。図22-9は、顧客登録タスク・フローがレンダリングするコンポーネントを示しています。エンド・ユーザーは、最初に「アドレス」トレイン・ストップにアクセスするまで、「支払」オプションおよび「確認」トレイン・ストップにアクセスできません。このトレインのすべてのトレイン・ストップは順次ストップです。

図22-9 顧客登録タスク・フローの順次トレイン・ストップ

トレイン・ストップをレンダリングするビュー・アクティビティを構成して非順次ストップにすることで、このデフォルトの動作を変更(トレイン・ストップを非順次ストップに)できます。

22.8.4.1 トレインの順次動作の無効化方法

タスク・フロー・ビュー・アクティビティで、実行時に値がfalseになるsequentialプロパティの値を記述します。

作業を始める前に、次のようにします。

トレインで構成可能な構成オプションを理解しておくと役に立つ場合があります。詳細は、22.8項「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。

トレイン・ストップの順次動作を無効化する手順:

「アプリケーション・ナビゲータ」で、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローのソース・ファイルをダブルクリックします。
バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。
「プロパティ・インスペクタ」で、「トレイン・ストップ」を開いて、「順次」フィールドの値を記述し、トレイン・ストップが順次または非順次のいずれであるかを決定します。

falseを記述するか、または実行時にfalseに解決されるEL式を記述して、トレイン・ストップを非順次にします。たとえば、次のようなEL式を記述します。

#{myTrainModel.isSequential}

22.8.4.2 トレイン・ストップの順次動作の無効化時の処理

例22-13で示すとおり、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

例22-13 トレイン・ストップの順次動作を無効化するメタデータ

<view id="paymentOptionDetails">
      <page>/account/paymentOptionDetails.jsff</page>
      <train-stop id="__1">
        <sequential>#{myTrainModel.isSequential}</sequential>
      </train-stop>
    </view>

図22-10は、sequentialに指定した値がfalseに評価されるときに対応するランタイム・ビューを示しています。ここで、エンド・ユーザーは、支払オプショントレイン・ストップをクリックして、支払オプションに直接移動できます。

図22-10 非順次トレイン・ストップを持つトレイン

22.8.5 トレイン・ストップのラベルの変更

トレイン・ストップを構成して定義したラベルを表示できます。定義したラベルは、EL式を使用して参照可能な静的値またはリソース・バンドル内の値などになることがあります。ローカライズされた文字列の使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「ページの国際化およびローカライズ」を参照してください。

22.8.5.1 トレイン・ストップのラベルの変更方法

ビュー・アクティビティの「表示名」プロパティの値を構成することで、トレイン・ストップのラベルを変更できます。

作業を始める前に、次のようにします。

トレイン・ストップのラベルの変更手順:

「アプリケーション・ナビゲータ」で、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローのソース・ファイルをダブルクリックします。
バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。
「プロパティ・インスペクタ」で、「説明」セクションを開いて「表示名」の値を記述し、実行中にトレイン・ストップがレンダリングするラベルを指定します。

リテラル値を記述するか、またはリソース・バンドルの値を参照するEL式を記述して、実行中にレンダリングします。

22.8.5.2 トレイン・ストップのラベル変更時の処理

例22-14で示すとおり、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

例22-14 トレイン・ストップのラベルを変更するメタデータ

<view id="basicInformation">
      <display-name>Basic Information</display-name>
      <page>/account/basicInformation.jsff</page>
      <train-stop>
        <display-name>Basic Information</display-name>
      </train-stop>
    </view>

実行時に、Fusion Webアプリケーションでは、トレイン・ストップのラベルとしてdisplay-nameプロパティに指定した値が表示されます。

22.8.6 トレイン・ストップを省略するトレインの構成

トレインを構成して、個々のトレイン・ストップを省略できるようにします。実行時に、Fusion Webアプリケーションでは、省略するように構成したトレイン・ストップが無効化されます。エンド・ユーザーは、トレイン内で次のトレイン・ストップにのみ移動できます。

最初のトレイン・ストップ以外のトレイン・ストップでトレインを実行する必要がある場合は、この機能を実装します。たとえば、トレイン・ストップ3を最初に実行する場合は、トレイン・ストップの1と2を省略するように構成します。18.2.3項「バインド・タスク・フローのデフォルト・アクティビティについて」の説明のとおり、デフォルト・アクティビティとしてトレイン・ストップと関連付けられたビュー・アクティビティを定義するよりも、この手法を使用します。

22.8.6.1 トレイン・ストップを省略するトレインの構成方法

実行時に値がtrueに評価される、ビュー・アクティビティのskipプロパティの値を記述します。

作業を始める前に、次のようにします。

トレイン・ストップを省略するトレインの構成手順:

「アプリケーション・ナビゲータ」で、トレイン・ストップをレンダリングするビュー・アクティビティを含むバインド・タスク・フローのソース・ファイルをダブルクリックします。
バインド・タスク・フローのダイアグラムで、ビュー・アクティビティを選択します。
「プロパティ・インスペクタ」で、「トレイン・ストップ」を開いて、「スキップ」フィールドの値を記述し、トレインがトレイン・ストップに移動するか、またはトレイン・ストップを省略するかのいずれかを決定します。

実行時にtrueを記述するか、またはtrueに解決されるEL式を記述して、トレインにトレイン・ストップを省略させます。たとえば、次のようなEL式を記述します。

#{myTrainModel.shouldSkip}

22.8.6.2 トレイン・ストップを省略するトレインの構成時の処理

例22-15で示すとおり、JDeveloperでは、バインド・タスク・フローのソース・ファイルに対してエントリを記述します。

例22-15 トレインにトレイン・ストップを省略させるメタデータ

 <view id="defineAddresses">
      <display-name>Address</display-name>
      <page>/account/defineAddresses.jsff</page>
      <train-stop>
        <display-name>Address</display-name>
         <skip>#{myTrainModel.shouldSkip}</skip>
      </train-stop>
    </view>

例22-15は、skipに指定した値がtrueに評価されるときに対応するランタイム・ビューを示しています。トレインが順次ストップであれば、エンド・ユーザーは、トレイン内の次のトレイン・ストップ(「支払」オプション)に移動する必要があります。

図22-11 トレイン・ストップの省略が構成されたトレイン

22.9 タスク・フロー・テンプレートの作成

新しいバインド・タスク・フローの作成時に、タスク・フロー・テンプレートをユーザー自身または他のアプリケーションの開発者のために作成し、出発点として使用できます。バインドなしタスク・フローは、タスク・フロー・テンプレートを使用して作成できません。タスク・フロー・テンプレートから作成したバインド・タスク・フローには、タスク・フロー・テンプレートと同じタスク・フロー・アクティビティ、制御フロー、入力パラメータおよびマネージドBeanがセットで定義されています。

タスク・フロー・テンプレートのユース・ケースの例では、バインド・タスク・フローの例外ハンドラとしてタスク・フロー・アクティビティを定義しています。タスク・フロー・アクティビティは、例外の発生時にエンド・ユーザーに表示するページに関連付けられたビュー・アクティビティになる場合があります。このビュー・アクティビティは、各バインド・タスク・フローではなく、タスク・フロー・テンプレートで定義し、新しいバインド・タスク・フローの作成時にはそのタスク・フロー・テンプレートを選択します。例外ハンドラの詳細は、22.5項「タスク・フローの例外ハンドラ」を参照してください。

新しいタスク・フロー・テンプレートを、既存のタスク・フロー・テンプレートに基づいて作成できます。また、既存のバインド・タスク・フローをリファクタして新しいタスク・フロー・テンプレートを作成することも可能です。詳細は、18.6.3項「バインド・タスク・フローの変換方法」を参照してください。

タスク・フロー・テンプレートに基づいてバインド・タスク・フローまたは別のタスク・フロー・テンプレートを作成する場合は、タスク・フロー・テンプレートに対して行う後続の変更がバインド・タスク・フローおよびテンプレートに自動的に伝播されるように指定できます。これを行うには、使用するダイアログで「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択し、バインド・タスク・フローまたはテンプレートを作成します。タスク・フロー・テンプレートに対して行う後続の変更(新しいビュー・アクティビティの追加など)はバインド・タスク・フローに伝播されます。子バインド・タスク・フローまたはタスク・フロー・テンプレートの親タスク・フロー・テンプレートは、子の開発中のどの段階でも変更、更新、関連付けの解除が可能です。

子側の作成時に「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択した場合は、実行時に、子バインド・タスク・フローまたは子タスク・フロー・テンプレートの内容が親タスク・フロー・テンプレートの内容と結合されます。子タスク・フローまたは子タスク・フロー・テンプレートの作成時に「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択した場合でも、競合の発生時には、子タスク・フローおよび子タスク・フロー・テンプレートによって親タスク・フロー・テンプレートが上書きされます。たとえば、22.8項「バインド・タスク・フローでのトレイン・コンポーネントの使用」の説明に従って、トレインとして使用する親タスク・フロー・テンプレートを作成し、そのタスク・フロー・テンプレートに基づいてバインド・タスク・フローを作成します。その後、親タスク・フロー・テンプレート上のトレイン・コンポーネントを無効にします。親タスク・フロー・テンプレートを上書きした子タスク・フローがトレインとして引き続き実行されます。

表22-3は、親タスク・フロー・テンプレートと子タスク・フローおよび子タスク・フロー・テンプレートの間の競合をADFコントローラによって解決する方法の詳細を説明しています。

表22-3 親テンプレートと子タスク・フロー間の競合の解決

バインド・タスク・フローのメタデータ	組合せアルゴリズム
デフォルト・アクティビティ	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
トランザクション	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートを(すべての下位要素を含む)メタデータのブロック全体としてオーバーライドします。
タスク・フローの再開	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートを(すべての下位要素を含む)メタデータのブロック全体としてオーバーライドします。
制御フロー・ルール	組合せアルゴリズムは、制御フロー・ルールのレベルではなく、制御フロー・ケースのレベルで発生します。制御フロー・ケースは次のカテゴリに分類されます。アクションおよび指定された結果からの場合指定されたアクションからのみの場合指定された結果からのみの場合アクションおよび指定された結果からではない場合これらの各カテゴリは付加的にマージされます。子バインド・タスク・フローまたはテンプレートが親タスク・フロー・テンプレートをオーバーライドして、4つの各カテゴリ内で完全に一致するようにします。
入力パラメータの定義	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、入力パラメータ定義の名前が同一になるようにします。
戻り値の定義	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、戻り値の定義の名前が同一になるようにします。
アクティビティ	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、アクティビティのIDが同一になるようにします。
マネージドBean	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、マネージドBeanの名前が同一になるようにします。
イニシャライザ	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
ファイナライザ	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
重要	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
ページ・フラグメントの使用	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
例外ハンドラ	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
セキュリティ - 権限	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。権限のマップは付加的なものです。子バインド・タスク・フローまたは子タスク・フロー・テンプレートが親タスク・フロー・テンプレートをオーバーライドして、権限マップ操作が同一になるようにします。
セキュリティ - 転送保証	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。
トレイン	子バインド・タスク・フローまたは子タスク・フロー・テンプレートが、親タスク・フロー・テンプレートをオーバーライドします。

設計時および実行時の両方の検証で、結果として作成される親/子の拡張階層に同一のタスク・フロー・テンプレートのサイクルが含まれないことを検証してください。

22.9.1 タスク・フロー・テンプレートの作成方法

JDeveloperの「新規ギャラリ」から「ADFタスク・フロー・テンプレート」を選択して、タスク・フロー・テンプレートを作成します。

作業を始める前に、次のようにします。

構成可能なタスク・フロー・テンプレートのオプションの内容を理解しておくと役に立つ場合があります。詳細は、22.9項「タスク・フロー・テンプレートの作成」を参照してください。

タスク・フロー・テンプレートの作成手順:

アプリケーション・ナビゲータで、タスク・フローを作成するプロジェクトを右クリックして、「新規」を選択します。
「新規ギャラリ」で、「Web層」を開いて、「JSF/Facelets」→「ADFタスク・フロー・テンプレート」を選択し、「OK」をクリックします。
「ADFタスク・フロー・テンプレートの作成」ダイアログで、適切なオプションを選択します。
- ファイル名: JDeveloperにより提示されるデフォルト値を受け入れるか、新しいファイル名を入力します。この値は、作成するタスク・フロー・テンプレートのXMLソース・ファイルに名前を付けるために使用されます。ソース・ファイルには、タスク・フロー・テンプレートにあるアクティビティおよび制御フロー・ルールが含まれます。XMLソース・ファイルのデフォルト名はtask-flow-template.xmlです。
- ページ・フラグメントを使用して作成: テンプレートに基づくバインド・タスク・フローをADFリージョンとして使用する場合は、このチェック・ボックスを選択した(デフォルト)のままにします。タスク・フロー・テンプレートに基づくタスク・フローに、JSFページ・フラグメントではなくJSFページを追加する場合は、このチェック・ボックスを選択解除します。
「OK」をクリックします。

22.9.2 タスク・フロー・テンプレートの作成時の処理

例22-16に示すように、JDeveloperで新しいタスク・フロー・テンプレートを作成するたびに、XMLファイルが作成されます。「アプリケーション・ナビゲータ」では、このXMLファイルは「ADFタスク・フロー・テンプレートの作成」ダイアログの「ディレクトリ」フィールドで指定した場所にあります(例: .../WEB-INF)。

タスク・フロー・テンプレートのXMLソース・ファイルの内容は、バインド・タスク・フローの内容に類似しています。<task-flow-template>タグが含まれているという点のみが異なります。

例22-16 タスク・フロー・テンプレートのソース・ファイル

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1">
  <task-flow-template id="task-flow-template">
     <default-activity>view1</default-activity>
     <view id="view1">view1.jsff</view>
  </task-flow-template>
</adfc-config>

22.9.3 タスク・フロー・テンプレートについて

バインディングを含むタスク・フロー・テンプレートを使用する場合、そのタスク・フロー・テンプレートを基盤とするタスク・フローのコンポーネントIDを変更する必要があります。これにより、IDが一意であることを確認します。テンプレートから生成されるタスク・フローでは、テンプレートと同じIDが継承されます。そのため、実行時に例外が発生します。詳細は、24.2.1項「ADFページ・テンプレートでのADFデータ・バインディングの使用方法」を参照してください。

Fusion WebアプリケーションにADFセキュリティが構成されている場合は、タスク・フロー・テンプレートおよびそのテンプレートを使用するタスク・フローの両方に権限を付与する必要があります。通常、タスク・フロー・テンプレート上の権限はアプリケーション・ロールのanonymous-roleに付与されるため、実際に重要な権限はタスク・フロー上に付与されますが、必ずそのようになるとは限りません。ADFセキュリティの詳細は、35項「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

22.10 タスク・フローを使用したページ階層の作成

ページ階層の作成は、エンド・ユーザーがアプリケーション内をより簡単に移動できるようにFusion WebアプリケーションのJSFページを構成する方法として便利です。エンド・ユーザーは、リンクのパスに移動してページの情報にアクセスします。図22-12に、サンプルのページ階層を示します。

図22-12 ページ階層

エンド・ユーザーがこの階層内を移動するには、各ページのリンクをクリックして、階層の別のレベルまでドリルダウンまたはドリルアップします。たとえば、Fusion Appのホームページの人事をクリックすると、図22-12の人事ページの階層が表示されます。給付金タブのリンクをクリックすると、図22-13のページ階層が表示されます。

図22-13 給付金ページ

ユーザーがBenefitsページのリンクをクリックすると、Medical、Dental、Visionのような他のページを表示できます。各ページのブレッドクラムに、階層における現在のページの位置が示されます。ユーザーがブレッドクラム内の各ノードをクリックすると、階層の他のページに移動できます。太字で表示されるタブのラベルが、ブレッドクラムに示されている現在のページのパスと一致します。

生成するすべてのページ階層には、バインド・タスク・フローのビュー・アクティビティによって参照されるページも含めることができます。図22-14は、バインド・タスク・フローによって参照されるビュー・アクティビティをレンダリングするページ階層の実行時ビューを示しています。

図22-14 バインド・タスク・フローを含む実行時のメニュー階層

ADF ControllerをXMLMenuModel実装とともに使用して、前述のページ階層を作成できます。これを行うと、JDeveloperによって次のものが生成されます。

エンド・ユーザーがメニュー項目を選択すると表示されるビューまたはページを決定する制御フロー・メタデータ
XMLMenuModelメタデータ・ファイル
デフォルトのナビゲーション・ウィジェット(「前へ」ボタン、「次へ」ボタンなど)
ブレッドクラム
マネージドBeanの構成

ADF Controllerを使用しない場合は、XMLMenuModel実装を使用してページ階層を作成できます。この方法によるページ階層の作成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のメニュー・モデルを使用したページ階層の作成に関する項を参照してください。

22.10.1 ページ階層の作成方法

バインドなしタスク・フローを作成するか、既存のものを開きます。バインドなしタスク・フローに、ビュー・アクティビティまたはバインド・タスク・フローを追加します。バインドなしタスク・フローに追加したそれぞれのビュー・アクティビティまたはバインド・タスク・フローには、指定されたページ階層に表示されるページへの参照が含まれます。JDeveloperの「ADFメニュー・モデルの作成」ダイアログを使用して、XMLMenuModelメタデータ・ファイルを生成します。生成したXMLMenuModelメタデータ・ファイルの項目ノードを構成し、目的のページ階層を作成します。サブメニューを親メニューに接続して階層を完成させます。

図22-15は、ビュー・アクティビティで構成されるページ階層の例を示しています。

最上位のメニュー(Home Page)は、ルートの親ページです。これには、Human Resourcesサブメニューへリンクする1つのタブが含まれています。

JDeveloperでは、Home Pageページは項目ノードとして、またHuman Resourcesページは共有ノードとして表示されます。
Human Resourcesには4つのタブがあり、それぞれがPayroll、Time、LaborおよびBenefitsの各ページへリンクします。

このメニューの中で、Human Resourcesは、子項目ノード(Payroll、Time、Labor)およびBenefitsサブメニューを参照する共有ノード(Benefits)を参照する、グループ・ノードです。
Benefitsは、子項目ノード(Medical、DentalおよびVision)のページを参照するグループ・ノードです。

図22-15 メニュー階層

注意:

1つのメニュー・モデル内にメニュー階層全体を作成することも可能です。ただし、メニュー階層を複数のサブメニューに分割した方が、管理は容易になります。また、メニュー階層をより小さなサブメニュー・モデルに分割することで、各開発組織が個別にその担当メニューを開発できるようになります。その後、各個別メニューを共有ノードで組み合せ、完全なメニュー階層を作成できます。

図22-16は、図22-14に示したページ階層をレンダリングするバインドなしタスク・フローおよびバインド・タスク・フローに対応する、JDeveloperの設計時ビューを示しています。バインドなしタスク・フロー(adfc-config.xml)には、図22-16の下部に表示されているバインド・タスク・フロー(task-flow-definition.xml)を起動する、ビュー・アクティビティ(view1)およびタスク・フロー・コール・アクティビティ(task-flow-definition)が含まれています。

図22-16 バインド・タスク・フローを含む設計時のメニュー階層

22.10.1.1 XMLMenuModelメタデータ・ファイルの作成方法

最終的なページ階層に表示するメニュー(バインドなしタスク・フロー)およびノード(ページ)を定義したら、JDeveloperの「ADFメニュー・モデルの作成」ダイアログを使用して、XMLMenuModelメタデータ・ファイルを生成します。

作業を始める前に、次のようにします。

構成可能なページ階層のオプションの内容を理解しておくと役に立つ場合があります。詳細は、22.10項「タスク・フローを使用したページ階層の作成」を参照してください。

XMLMenuModelメタデータ・ファイルの作成手順:

最終的なページ階層の各メニューに対して、バインドなしタスク・フローを作成します。

たとえば、図22-15のページ階層を実現するには、2つのバインドなしタスク・フロー(Human ResourcesメニューおよびBenefitsメニュー)を作成します。

バインドなしタスク・フローの作成に関する詳細は、18.2.1項「タスク・フローの作成方法」を参照してください。

ヒント:

作成したバインドなしタスク・フローのファイル名に接頭辞adfc-を付けて、そのファイルがバインド・タスク・フローではなくバインドなしタスク・フローのソースであることを簡単に識別できるようにします。

各バインドなしタスク・フローに、ページを参照するビュー・アクティビティを追加します。ビュー・アクティビティによって参照されるページは、メニュー内のメニュー・ノードに対応します。

たとえば、Benefitsメニューには1つのグループ・ノード(benefits)および3つの項目ノード(medical、dentalおよびvision)が含まれているため、Benefitsメニューのバインドなしタスク・フローには、図22-17のように4つのビュー・アクティビティを追加する必要があります。

図22-17 タスク・フローのビュー・アクティビティ

共有ノードを使用して他のメニューが含まれているメニューについては、ビュー・アクティビティを追加しないでください。たとえば、図22-15のHuman Resourcesメニューには、共有ノードを使用してBenefitsメニューを参照するBenefitsというタブがあります。Benefitsメニューのバインド・タスク・フローにはBenefitsのビュー・アクティビティがすでに含まれているため、Human Resourcesメニューのバインド・タスク・フローにビュー・アクティビティを追加する必要はありません。

ビュー・アクティビティの詳細は、19.2項「ビュー・アクティビティの使用」を参照してください。

注意:

バインド・タスク・フローによって参照されるページがページ階層に含まれる場合は、そのバインド・タスク・フローをコールするバインドなしタスク・フローにタスク・フロー・コール・アクティビティを追加します。

「アプリケーション・ナビゲータ」で、手順 1で作成したそれぞれのバインドなしタスク・フローのファイルを右クリックして、「ADFメニュー・モデルの作成」を選択します。
「ADFメニュー・モデルの作成」ダイアログで、XMLMenuModelメタデータ・ファイルのファイル名および保存先ディレクトリを入力ます。
「OK」をクリックします。

22.10.1.2 グループ・ノードおよび子ノードの階層でのサブメニューの作成方法

作成したXMLMenuModelメタデータ・ファイルを開き、グループ・ノードにする項目ノードをグループ・ノードに変換します。その後、グループ・ノードが1つ以上の項目ノードの親となる階層を作成します。

作業を始める前に、次のようにします。

グループ・ノードおよび項目ノードの階層でサブメニューを作成する手順:

「アプリケーション・ナビゲータ」でXMLMenuModelメタデータ・ファイルを選択し、開きます。

構造ウィンドウに、バインドなしタスク・フローの各ビュー・アクティビティに対して1つの項目ノードが表示されます。デフォルトでは、定義されている階層はありません。
これらの項目ノードをドラッグ・アンド・ドロップして、グループ・ノードに変換する項目ノードの子ノードにします。

グループ・ノードに変換する各項目ノードには、少なくとも1つの子項目ノードが必要です。たとえば、図22-15のメニュー階層を作成するには、Benefitsの項目ノードをグループ・ノードに変換し、Medical、DentalおよびVisionの項目ノードをドラッグ・アンド・ドロップしてBenefit項目ノードの子ノードにします。
構造ウィンドウで親項目ノードを右クリックし、「groupNodeへの変換」を選択します。
表示される「groupNodeのプロパティ」ダイアログの「ID」フィールドで、新しい識別子を入力するか、デフォルト値を受け入れます。

識別子は、すべてのXMLMenuModelメタデータ・ファイルのすべてのノードで一意であることが必要です。ノードを識別する値を指定することをお薦めします。たとえば、Benefitsノードをグループ・ノードに変更する場合、デフォルトIDであるitemNode_benefitsをgroupNode_benefitsに更新できます。
「groupNodeのプロパティ」ダイアログのidrefフィールドに、メニュー内にある他のいずれかのノードのID(例: itemNode_Medical)を入力します。

入力する値は、グループ・ノードまたは項目ノードである、子項目ノードのIDでもかまいません。
labelフィールドに値を入力するか既存のデフォルト値を変更して、実行時に表示する値を指定します。

たとえば、label_benefitsをBenefitsなどに変更できます。
フィールドの残りのデフォルト値を受け入れて、「終了」をクリックします。

「変換の確認」ダイアログに、groupNode要素のaction属性およびfocusViewID属性を削除するかどうかを確認するメッセージが表示されます。グループ・ノードではこれらの属性は使用されないため、常に「OK」をクリックします。
「OK」をクリックします。

22.10.1.3 メニュー階層を別のメニュー階層に添付する方法

共有ノード要素を使用して、2つのメニューを1つにリンクできます。たとえば、図22-15のメニュー階層に示したHuman Resourcesメニューには、4つのサブメニュー(Payroll、Time、LaborおよびBenefits)が含まれています。Benefitsサブメニューは、それ自体がサブメニュー・エントリを持つメニューです。Human ResourcesメニューのXMLMenuModelメタデータ・ファイルで、Benefitsサブメニューの項目ノードを共有ノードに変換します。BenefitsメニューのXMLMenuModelメタデータ・ファイルを参照する、新しく作成した共有ノードの属性(ref)のEL式を記述します。

作業を始める前に、次のようにします。

共有ノードを使用してメニュー階層を別の階層に添付する手順:

「アプリケーション・ナビゲータ」で、他のメニューを参照させるメニューのXMLMenuModelメタデータ・ファイルを選択して開きます。
構造ウィンドウで、ノードを選択して右クリックし、sharedNode要素を挿入する、適切なメニュー・オプションを選択します。
表示される「sharedNodeの挿入」ダイアログのrefフィールドに、もう1つのメニューのXMLMenuModelメタデータ・ファイルを参照するためのEL式を入力します。

「OK」をクリックします。

注意:

ページ階層に複数のバインドなしタスク・フローがある場合は、追加したそれぞれのバインドなしタスク・フローのファイル名が、<metadata-resources>要素の値としてadfc_config.xmlファイルに含まれていることを確認してください。詳細は、22.10.2項「ページ階層の作成時の処理」を参照してください。

22.10.2 ページ階層の作成時の処理

ページ階層を作成すると、様々なファイルで変更が発生します。

adfc-config.xmlの変更内容

新しいバインドなしタスク・フローを作成すると、その新規作成バインドなしタスク・フローのソース・ファイルにadfc-config.xmlファイルの参照が自動的に追加されます。例22-17のadfc-unbounded_tflow.xmlは、新しく作成されたバインドなしタスク・フローのソース・ファイルの名前です。

例22-17 adfc-config.xmlによって参照されるバインドなしタスク・フロー

<?xml version="1.0" encoding="windows-1252" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"
             id="__1">
  <metadata-resource id="__2">/WEB-INF/adfc-unbounded_                tflow.xml</metadata-resource>
</adfc-config>

adfc-config.xmlの詳細は、A.9項「adfc-config.xml」を参照してください。

実行時に、Fusion Webアプリケーションでは、その初回起動時にadfc-config.xmlファイルがロードされます。adfc-config.xmlファイルには次が含まれる可能性があります。

バインドなしタスク・フローのADFナビゲーション・メタデータ
バインドなしタスク・フローのADFアクティビティ・メタデータ
ADFアクティビティによって使用されるマネージドBean

XMLMenuModelメタデータ・ファイル

JDeveloperにより、バインドなしタスク・フローに追加した各ビュー・アクティビティのノードを使用して、XMLMenuModelメタデータ・ファイルが生成されます(例22-4を参照)。

例22-18 XMLMenuModelメタデータ・ファイルの例

<?xml version="1.0" encoding="windows-1252" ?>
<menu xmlns="http://myfaces.apache.org/trinidad/menu">
  <groupNode id="groupNode_benenfits" label="Benefits" idref="itemNode_medical">
    <itemNode id="itemNode_medical" label="label_medical"
              action="adfMenu_medical" focusViewId="/medical"/>
    <itemNode id="itemNode_dental" label="label_dental" action="adfMenu_dental"
              focusViewId="/dental"/>
    <itemNode id="itemNode_vision" label="label_vision" action="adfMenu_vision"
              focusViewId="/vision"/>
  </groupNode>
</menu>

バインドなしタスク・フローのダイアグラム

バインドなしタスク・フローのファイルは、ページ階層の移動に使用される制御フロー・ルールおよびマネージドBeanを使用して、JDeveloperによって更新されます。図22-18は、図22-17のバインドなしタスク・フローに対応する更新後のバインドなしタスク・フローをダイアグラマで示しています。

図22-18 更新されたバインドなしタスク・フロー