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

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

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

• 18.1項「複雑なタスク・フローの概要」

• 18.2項「イニシャライザとファイナライザの使用」

• 18.3項「トランザクションの管理」

• 18.4項「バインド・タスク・フローの再開」

• 18.5項「JSFページからのバインド・タスク・フローの直接的実行」

• 18.6項「タスク・フローでの例外の処理」

• 18.7項「セーブポイントを使用するためのアプリケーションの構成」

• 18.8項「タスク・フローでのセーブポイントの使用」

• 18.9項「トレインの作成」

• 18.10項「複数のタスク・フローの実行」

• 18.11項「タスク・フロー・テンプレートの作成」

• 18.12項「ページ階層の作成」

• 18.13項「タスク・フローでのBPELの使用」

18.1 複雑なタスク・フローの概要

基本的なバインドなしタスク・フローまたはバインド・タスク・フローを作成し、タスク・フロー・アクティビティを追加した後、トランザクション管理や再開などの特殊なタスクを実行できます。

タスク・フロー・アクティビティに関する基本情報は、第15章「タスク・フロー・アクティビティの使用」を参照してください。

ADFリージョンでの処理を行う場合は、第17章「リージョンとしてのタスク・フローの使用」を参照してください。

パラメータの使用に関する詳細は、第16章「タスク・フローのパラメータの使用」を参照してください。

18.2 イニシャライザとファイナライザの使用

イニシャライザとは、バインド・タスク・フローを開始したときに呼び出されるカスタム・コードです。ファイナライザとは、タスク・フロー・リターン・アクティビティ経由、または例外の発生によって、バインド・タスク・フローを終了したときに呼び出されるカスタム・コードです。ファイナライザはマネージドBeanのメソッドです。一般的なファイナライザのタスクには、バインド・タスク・フローで取得したすべてのリソースの解放、およびタスク・フローを終了する前のクリーンアップの実行などがあります。

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

#{pageFlowScope.modelBean.releaseResources}

バインド・タスク・フローの開始時にイニシャライザのコードを実行するには2つの方法があり、ブラウザの「戻る」ボタンでそのタスク・フローを再開できるかどうかによって次のように異なります。

• 「戻る」ボタンでの再開が想定されない場合: バインド・タスク・フロー内で(最初に実行する)デフォルト・アクティビティとしてメソッド・コール・アクティビティを指定します。そのメソッド・コール・アクティビティにより、イニシャライザのコードを含むカスタム・メソッドがコールされます。詳細は、15.5項「メソッド・コール・アクティビティの使用」および22.4.5項「ブラウザの「戻る」ボタンおよびレコード間の移動について」を参照してください。

• 「戻る」ボタンでの再開が可能な場合: バインド・タスク・フローのメタデータのオプションで、イニシャライザ・メソッドを指定します詳細は、14.2項「タスク・フローの作成」を参照してください。ユーザーがブラウザの「戻る」ボタンでタスク・フローを再開する可能性がある場合、この方法を使用してください。このような場合には、バインド・タスク・フローに指定したデフォルト・アクティビティがコールされずに、イニシャライザ・メソッドで指定されたメソッドがコールされることがあります。

18.3 トランザクションの管理

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

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

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

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

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

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

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

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

ヒント: リターン・アクティビティを使用してcommitアクションをコールするか、commitアクションにバインドされたボタンを使用できます。可能な場合は、タスク・フロー・リターン・アクティビティを使用します。タスク・フロー・リターン・アクティビティを使用すると、ADFタスク・フローで使用されるすべてのデータ・コントロールがコミットされます。また、アプリケーションがコミットおよびロールバックしている場所が簡単にわかるようになるため、メンテナンスがしやすくなります。 次の場合は、invokeActionを使用する必要があります。 タスク・フローが終わる前にコミットする場合 ADFコントローラを使用していない場合 タスク・フローで複数のデータ・コントロールを使用し、それら全部をコミットしない場合

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

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

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

1. コール先のバインド・タスク・フローの概要エディタで、「動作」をクリックして「トランザクション」セクションを開きます。

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

   • <コントローラ・トランザクションなし>: コール先のバインド・タスク・フローは、いずれのトランザクション管理にも追加されません。

   • 常に既存のトランザクションを使用: バインド・タスク・フローは、コール時にすでに進行中の既存のトランザクションに追加されます。

   • 可能であれば既存のトランザクションを使用: バインド・タスク・フローは、コール時に既存のトランザクションがある場合はそれに追加されますが、既存のトランザクションがない場合はそのバインド・タスク・フローの開始時に新しいトランザクションが開始されます。

   • 常に新規トランザクションを開始: トランザクションが進行中かどうかには関係なく、バインド・タスク・フローの開始時に新しいトランザクションが作成されます。この新しいトランザクションは、バインド・タスク・フローを終了した時点で完了します。

   
   

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

   
   

3. 手順2で次のいずれかのオプションを選択した場合は、必要に応じて、「タスク・フローのコールとデータ・コントロールを共有」 チェック・ボックスを選択解除して、データ・コントロールがコール元のタスク・フローと共有されないようにします。

   • 可能であれば既存のトランザクションを使用

   • 常に新規トランザクションを開始

   デフォルトの動作では、データ・コントロールが共有されます。詳細は、18.3.3項「タスク・フローでのデータ・コントロール・スコープについて」を参照してください。

4. 手順2で次のいずれかのオプションを選択した場合は、必要に応じて、「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択して、タスク・フローの開始時にADFモデルのセーブポイントが作成されないようにします。

   • 常に既存のトランザクションを使用

   • 可能であれば既存のトランザクションを使用

   ADF Modelのセーブポイントとは、ADF Modelの状態を保存したスナップショットのことです。「タスク・フロー・エントリでのセーブ・ポイントなし」チェック・ボックスを選択すると、セーブポイントに関連付けられたオーバーヘッドはトランザクション用に作成されません。

5. コール先のバインド・タスク・フロー内のタスク・フロー・リターン・アクティビティを選択します。

6. プロパティ・インスペクタで「動作」セクションを展開します。

7. コール先のバインド・タスク・フローで新しいトランザクションの作成がサポートされている場合(バインド・タスク・フローで「可能であれば既存のトランザクションを使用」または「常に新規トランザクションを開始」オプションが指定されている場合)、「トランザクションの終了」ドロップダウン・リストから次のいずれかを選択します。

   • commit: 既存のトランザクションをデータベースにコミットする場合に選択します。

   • rollback: タスク・フローの開始時に新しいトランザクションを初期状態までロールバックする場合に選択します。これには、トランザクションの取消しと同じ効果があります。

8. コール先のバインド・タスク・フロー内でユーザーが行った変更をタスク・フロー終了時に破棄する場合は、「セーブポイントのリストア」ドロップダウン・リストで「true」を選択します。タスク・フローの開始時に作成されたセーブポイントがリストアされます。

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

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

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

 <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>

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

18.3.3 タスク・フローでのデータ・コントロール・スコープについて

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

• beginTransaction()

• commit()

• rollback()

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

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

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

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

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

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

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

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

18.4.1 再開動作の設定方法

バインド・タスク・フローの再開動作を設定できます。

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

1. 概要エディタで、バインド・タスク・フローを開きます。

2. 「動作」をクリックします。

3. 「タスク・フローの再入力」リストで、次のいずれかを選択します。

   • reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。

   • reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。

     例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。

   • reentry-outcome-dependent: ブラウザの「戻る」ボタンを使用したバインド・タスク・フローの再開は、同じバインド・タスク・フローが前回終了したときにタスク・フロー・リターン・アクティビティを介して受け取った結果に基づいて決定されます。指定する場合、コール先のバインド・タスク・フローのタスク・フロー・リターン・アクティビティにもreentry-allowedまたはreentry-not-allowedのいずれかを指定し、結果に基づいた再開動作を定義する必要があります。

     このオプションを選択した場合、ユーザーは自身が初めにタスク・フローを終了した方法にのみ基づいて、そのタスク・フローに「戻る」ボタンで移動できます。たとえば、ショッピング・カートを表すタスク・フローの再開は、ユーザーが注文を取り消してそのフローを終了した場合には可能ですが、ユーザーが注文を完了してフローを終了した場合には不可能です。

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

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

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

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

   タスク・フロー・リターン・アクティビティの追加に関する詳細は、15.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。

2. プロパティ・インスペクタで、「一般」セクションを開きます。

3. 「名前」フィールドに、結果の名前をリテラルで入力します(例: success、failure)。

4. 「動作」セクションを開きます。

5. 「再入力」ドロップダウン・リストから、次のオプションのいずれかを選択します。

   • reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。

   • reentry-not-allowed: バインド・タスク・フローの再開は許可されません。バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentryなど)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。

     例外の表示と制御フローのルーティングを処理する例外ハンドラを設定して、コール先のバインド・タスク・フローのデフォルト・アクティビティに移動するようにできます。バインド・タスク・フローが別のバインド・タスク・フローからコールされたものでない場合は、通常のWebエラーがポストされ、web.xmlファイルでの指定に従って処理されます。

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

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

18.5 JSFページからのバインド・タスク・フローの直接的実行

「アプリケーション・ナビゲータ」からJSFページへ、バインド・タスクを直接ドラッグ・アンド・ドロップできます。バインド・タスク・フローにページ・フラグメントであるビュー・アクティビティが含まれている場合は、このタスク・フローがADFリージョンとしてJSFページに追加されます。たとえば、Fusion Order Demoアプリケーションのホームページには、エンド・ユーザーがFusion Order Demoアプリケーションのショッピング・カート・ページに追加した品目の合計を表示するバインド・タスク・フローが含まれています。このバインド・タスク・フローのビュー・アクティビティはすべてページ・フラグメントであるため、このバインド・タスク・フローは、Fusion Order Demoアプリケーションのホームページにリージョンとしてドロップされます。ショッピング・カートの合計の内容は、Fusion Order Demoアプリケーションのホームページの物理リージョン内に表示されます。詳細は、第17章「リージョンとしてのタスク・フローの使用」を参照してください。

一方、バインド・タスク・フローにページであるビュー・アクティビティが含まれている場合は、タスク・フローをボタンまたはリンクとして追加する選択肢が提示されます。エンド・ユーザーは、実行時にボタンまたはリンクをクリックして、バインド・タスク・フローを起動できます。

ページを含むバインド・タスク・フローをJSFページに追加する手順:

1. 「アプリケーション・ナビゲータ」で、ADFバインド・タスク・フローのソース・ファイルをページにドラッグして、ボタンまたはリンクを配置する場所にドロップします。

   タスク・フローは、アプリケーション・ナビゲータのPage FlowsノードまたはWEB-INFノードの下にあります。

2. 「作成」、次に「ボタンとしてのタスク・フロー・コール」または「リンクとしてのタスク・フロー・コール」を選択します。

   図18-2に示すように、バインド・タスク・フローは、ボタンまたはリンクのUIコンポーネントとしてJSFページに表示されます。

   図18-2 ボタンおよびリンクのUIコンポーネント

   
   

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

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

• メソッド・コール・アクティビティからスローされる例外。

• タスク・フローのイニシャライザまたはファイナライザとして記述したカスタム・メソッドからスローされる例外。

• アクティビティの実行権限がないユーザー。

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

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

#{someException == "oracle.adf.controller.ControllerException"}

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

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

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

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

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

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

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

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

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

   図18-3 例外ハンドラとして指定されたアクティビティの例

   
   

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

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

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

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

例18-2 <exception-handler>要素

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

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

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

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

  oracle.adf.view.rich.context.ExceptionHandler

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

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

例18-3 例外ハンドラのカスタム・コード

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 {
            super.handleException(facesContext, throwable, phaseId);
        }
    }
}

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

タスク・フローでの例外の処理に使用される他のオプションについて理解しておくと役立ちます。詳細は、18.6項「タスク・フローでの例外の処理」を参照してください。

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

• Oracle Fusion Middleware Java API Reference for Oracle ADF Controller

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

タスク・フロー機能を使用して追加できる機能についても理解しておくと役立ちます。詳細は次の項を参照してください。

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

1. 「アプリケーション・ナビゲータ」で、カスタムを記述するプロジェクトを開き、Application Sources/META-INFノードに移動します。

2. META-INFノードの下にservicesという名前のフォルダを作成します。

3. servicesフォルダ内に、oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイルを作成します。

4. oracle.adf.view.rich.context.ExceptionHandlerという名前のテキスト・ファイル内に、例外処理用に記述したカスタム・コードのパッケージ名およびクラス名を記述します。

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

   oracle.fodemo.frmwkext.CustomExceptionHandler

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. JDeveloperでFusion Webアプリケーションを開いた状態で、「アプリケーション・ナビゲータ」の「アプリケーション・リソース」ペインを開きます。

2. 「ディスクリプタ」および「ADF META-INF」を展開します。

3. adf-config.xmlを右クリックし、ポップアップ・メニューから「開く」を選択します。

4. 概要エディタの「コントローラ」ページで、セーブポイントのデータベース表が含まれているデータソースのJNDI名を指定するために、「データソース」プロパティの値を記述します。

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

   java:comp/env/jdbc/Connection1DS

   Connection1はJDeveloper接続名です。

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

   詳細は、18.8.9項「セーブポイントの存続時間について」を参照してください。

6. adf-config.xmlファイルを保存します。

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

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

例18-4 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」を参照してください。

18.7.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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 構成するバインド・タスク・フローを開いてダイアグラム・エディタに移動します。

2. 「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルからダイアグラムへ「メソッド・コール」アクティビティをドラッグ・アンド・ドロップします。

3. プロパティ・インスペクタで「一般」ノードを開き、「メソッド」プロパティのEL式を記述して、メソッド・コール・アクティビティで起動するセーブポイント・メソッドを指定します。

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

   #{controllerContext.currentViewPort.createSavePoint}

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

   詳細は、14.3.3項「制御フローの追加方法」を参照してください。

5. オプションとして、Fusion Webアプリケーションのadf-config.xmlファイルでセーブポイント・オプションを構成して、そのアプリケーションに対して暗黙的なセーブポイントを作成できるかどうかなどを指定できます。

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

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

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

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

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

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

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

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

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

1. セーブポイント・リストア・アクティビティを追加するバインド・タスク・フローまたはバインドなしタスク・フローを開き、ダイアグラム・エディタに移動します。

2. 「コンポーネント・パレット」の「ADFタスク・フロー」ページで、「コンポーネント」パネルから「セーブポイントのリストア」アクティビティをドラッグして、タスク・フローのダイアグラムへドロップします。

3. プロパティ・インスペクタで「一般」ノードを開き、評価されるとcreateSavePointメソッドの起動時に最初に作成されたセーブポイントを取得する「セーブポイントID」プロパティのEL式を記述します。

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

   #{SessionScope.myBean.savepointID}

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

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

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

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

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

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

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

1. 構造ウィンドウでバインド・タスク・フローのノード(task-flow-definition)を右クリックし、「プロパティに移動」を選択します。

2. プロパティ・インスペクタで「一般」タブを開き、「セーブポイントのリストア・ファイナライザ」ドロップダウン・メニューから「式ビルダー」を選択します。

3. 起動するファイナライザ・メソッドを指定するEL式を記述します。

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

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

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

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

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

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

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

• エンド・ユーザーが非アクティブ状態であったことによりセッションがタイムアウトした場合

• エンド・ユーザーがデータを保存せずにログアウトした場合

• エンド・ユーザーが唯一のブラウザ・ウィンドウを閉じて、アプリケーションをログアウトした場合

• エンド・ユーザーがデータを保存せずに制御フロー・ルール(たとえば、外部URLに移動するためのgoLinkコンポーネント)を使用して現在のアプリケーションから移動した場合

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

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

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

1. 「アプリケーション・ナビゲータ」の「アプリケーション・リソース」パネルで、「ディスクリプタ」→「ADF META-INF」の順に開きます。

2. adf-config.xmlを右クリックし、ポップアップ・メニューから「開く」を選択します。

3. 概要エディタの「コントローラ」ページで、「暗黙的セーブポイントの有効化」チェック・ボックスを選択します。

   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」を参照してください。

4. 「アプリケーション・ナビゲータ」で、バインド・タスク・フローのソース・ファイルをダブルクリックします。

5. 概要エディタで「動作」ナビゲーション・タブをクリックし、「クリティカル」チェック・ボックスを選択します。

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

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

ControllerContext.savePointManager.listSavePointIds

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

• タスク・フロー・コール・アクティビティ

• タスク・フロー・リターン・アクティビティ

• セーブポイント・リストア・アクティビティ

• ダイアログ

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

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

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

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

oracle.adf.controller.savepoint

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

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

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

例18-9 setSavePointTimeToLiveメソッドの構文

    public void setSavePointTimeToLive(long timeInSeconds) {
       }

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

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

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

18.9 トレインの作成

トレインは、エンド・ユーザーをタスクの完了まで導く一連の関連アクティビティを表します。エンド・ユーザーは、一連のトレイン・ストップをクリックしますが、それぞれのストップは特定のページにリンクされています。図18-4は、エンド・ユーザーが登録ページの「顧客として登録」リンクをクリックするとコールされる、Fusion Order Demoアプリケーションのトレインを示しています。

図18-4 Fusion Order Demoアプリケーションの自己登録トレイン

このトレインには、それぞれが1つのJSFページに対応する4つのストップが含まれており、エンド・ユーザーはこれらのページで登録情報の入力および確認を行えます。これらのトレイン・ストップは次のとおりです。

• 基本情報

• 住所

• 支払方法

• 確認

トレインの各JSFページには、図18-5のようなADF FacesのトレインUIコンポーネントが表示されます。これにより、基礎となるトレイン・モデルで指定された順序で、ユーザーがトレイン・ストップ間を移動できます。

図18-5 トレインUIコンポーネント

図18-6に示すオプションのトレイン・ボタン・バー・コンポーネントに含まれているボタンは、ストップを前後に移動するための追加の手段として使用できます。このコンポーネントをトレイン・コンポーネントと併用すると、トレイン・ストップ間を複数の方法で移動できます。

図18-6 トレイン・ボタン・バーUIコンポーネント

18.9.1 トレインとしてのバインド・タスク・フロー

メタデータに<train/>要素を指定するバインド・タスク・フロー内のアクティビティに基づいて、トレインを作成できます。バインドなしタスク・フロー内のアクティビティからは、トレインを作成できません。

ヒント: メタデータに<train/>要素があるタスク・フロー・テンプレートを作成し、そのテンプレートに基づいてバインド・タスク・フローを作成することもできます。

各バインド・タスク・フローに保持できるトレインは1つのみです。バインド・タスク・フローに論理的に複数のトレインが含まれる場合、各トレインを個別のバインド・タスク・フローに追加する必要があります。

図18-7は、Fusion Order Demoアプリケーションで図18-4に示した自己登録トレインの作成に使用されるバインド・タスク・フローを表しています。

図18-7 顧客登録タスク・フロー

図18-8に、customer-registration-task-flowの最初の2つのトレイン・ストップの詳細を簡略化して示します。この図では、アイコン(2つの青色の円)がトレイン内の各トレイン・ストップを表します。各ストップを結ぶ点線は、エンド・ユーザーがそれらのストップにアクセスする順序を示しています。詳細は、18.9.2項「トレインの順序」を参照してください。点線をドラッグして順序を変更することはできませんが、トレイン・ストップを右クリックして、トレイン・ストップの順序を前後に移動するためのオプションを選択できます。各トレイン・ストップは通常、JSFページに対応するビュー・アクティビティですが、タスク・フロー・コール・アクティビティをトレイン・ストップとして追加することもできます。

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

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

ルーター・アクティビティや制御フロー・ケースによるブランチ化は、トレインを含むタスク・フロー・ダイアグラムでも、そのトレインからコールされる子バインド・タスク・フローでもサポートされます。詳細は、18.9.7項「ブランチ化について」を参照してください。

18.9.2 トレインの順序

デフォルトでは、トレイン・ストップは順次ストップです。ユーザーが順次トレイン・ストップの1つを選択できるのは、その順序の1つ前のトレイン・ストップにアクセスした後に限られます。非順次トレイン・ストップはどのような順序でも実行できます。

1つのトレインに、順次および非順次の両方のストップを含めることができます。図18-9では、第1ステップが現在のトレイン・ストップです。2番目のストップは、ユーザーが最初のストップにアクセスした後にのみクリックできるため、順次ストップです。第3ステップは、ユーザーが最初のストップにアクセスした後に、2番目のストップにアクセスしなくても即座にクリックできるようになるため、非順次ストップです。

第1ステップが現在のストップの場合、エンド・ユーザーは第5ステップおよび第6ステップをクリックできないため、これらは順次ストップです。

図18-9 順次および非順次ストップを持つトレイン

各トレイン・ストップ用のビュー・アクティビティ(またはタスク・フロー・コール・アクティビティ)に順序オプションを設定すると、そのトレイン・ストップを順次ストップとして動作するか、または非順次ストップとして動作するかを指定できます。順序オプションには、エンド・ユーザーの入力またはその他の要因を評価するのEL式(例: #{myTrainModel.isSequential})を含めます。このEL式がtrueに評価されると、トレイン・ストップは順次ストップとして動作します。falseに評価されると、トレイン・ストップは非順次ストップとして動作します。

また、個々のトレイン・ストップをスキップすることでトレイン全体の順序を変更することもできます。トレイン・ストップに対応するアクティビティのスキップ・オプションでは、エンド・ユーザーの入力またはその他の要因を評価するEL式を使用して、そのトレイン・ストップをスキップするかどうかが決定されます。trueに評価されると、そのトレイン・ストップは無効として表示され、スキップされます。エンド・ユーザーはトレイン内の次の有効なストップに進みます。また、エンド・ユーザーが「次へ」ボタンまたは「前へ」ボタンをクリックしてもトレイン・ストップはスキップされます。

注意: デフォルトで、そのトレインで最初のトレイン・ストップ以外のストップから実行されるようにするには、スキップ・オプションを使用します。たとえば、トレインをトレイン・ストップ3から開始する必要がある場合、トレイン・ストップ1および2にスキップを指定します。トレイン・ストップに関連付けられたビュー・アクティビティをバインド・タスク・フローのデフォルト・アクティビティとしてマーキングすると予期しない結果を招く場合があるため、この方法をお薦めします。詳細は、14.2.3項「ADFバインド・タスク・フローのデフォルト・アクティビティについて」を参照してください。

18.9.3 トレインの作成方法

バインド・タスク・フローをトレインとして使用するには、そのメタデータに<train/>要素が含まれている必要があります。この要素をメタデータに含めるには、複数の方法があります。

• 「タスク・フローの作成」ダイアログ・ボックスで「トレインの作成」チェック・ボックスを選択します。詳細は、14.2項「タスク・フローの作成」を参照してください。

• 「ADFタスク・フロー・テンプレートの作成」ダイアログ・ボックスで「トレインの作成」チェック・ボックスを選択し、テンプレートを使用して新しいバインド・タスク・フローを作成します。詳細は、18.11項「タスク・フロー・テンプレートの作成」を参照してください。

• エディタで既存のバインド・タスク・フロー・ダイアグラムを右クリックして、「トレイン」→「トレインの作成」の順に選択します。

• 概要エディタで既存のバインド・タスク・フローを開き、「動作」をクリックして「トレイン」チェック・ボックスを選択します。

トレインを作成する手順:

1. エディタで、トレインとして使用できるバインド・タスク・フローを開きます。

   前述のいずれかの方法に従って、バインド・タスク・フローのメタデータに<train/>要素を含める必要があります。

2. トレインに含めるそれぞれのビュー・アクティビティまたはJSFページを、「アプリケーション・ナビゲータ」からバインド・タスク・フロー・ダイアグラムにドラッグします。

   • JSFページをドラッグすると、ビュー・アクティビティがダイアグラムに自動的に追加されます。

   • ビュー・アクティビティをドラッグすると、後でそれをダブルクリックして新しいJSFページを作成できます。

   
   

   ヒント: ページまたはビュー・アクティビティのダイアグラムへの追加は、特定の順序で行う必要はありません。トレインの順序は後で調整可能です。

   
   

3. トレイン・ストップの順序を並べ替えるには、ダイアグラム内でアクティビティに対応するストップを右クリックします。「トレイン」を選択し、順序内で「右に移動」や「左に移動」などの、トレイン・ストップを移動するメニュー項目を選択します。

4. デフォルトでは、トレイン・ストップは順次ストップです。トレイン・ストップの動作を非順次ストップにするかどうかはオプションで定義できます。

   1. バインド・タスク・フロー・ダイアグラムで、非順次トレイン・ストップに関連付けられているアクティビティを選択します。

   2. アクティビティのプロパティ・インスペクタで、「トレイン・ストップ」をクリックします。

   3. 「順次」フィールドに#{myTrainModel.isSequential}などのEL式を入力します。

      また、trueなどのリテラル値を指定することもできます。

      このEL式がtrueに評価されると、トレイン・ストップは順次ストップになります。falseの場合、トレイン・ストップは非順次ストップになります。

5. デフォルトでは、トレイン・ストップはスキップされません。また、EL式の結果に基づいてトレイン・ストップをスキップするようにも指定できます。

   1. バインド・タスク・フロー・ダイアグラムで、非順次トレイン・ストップに関連付けられているアクティビティを選択します。

   2. 「プロパティ・インスペクタ」で、「トレイン・ストップ」をクリックします。

   3. 「スキップ」フィールドに#{myTrainModel.shouldSkip}などのEL式を入力します。

      このEL式がtrueに評価されると、トレイン・ストップはスキップされます。falseの場合、トレイン・ストップはスキップされません。

6. ダイアグラム内で、トレイン・ストップとして使用されるそれぞれのビュー・アクティビティをダブルクリックします。

   ビュー・アクティビティをダブルクリックすると、新しいJSFページを作成するダイアログが開きます。JSFページがすでにビュー・アクティビティと関連付けられている場合、既存のページが表示されます。

7. JSFページをエディタで開きます。

8. トレイン内の各JSFページについて、コンポーネント・パレットでADF Facesページの「共通コンポーネント」セクションから「トレイン」と、(オプションで)「トレイン・ボタン・バー」UIコンポーネントを選択します。UIコンポーネントをJSFページにドラッグします。

   トレインおよびトレイン・ボタン・バーUIコンポーネントは、トレインのバインド・タスク・フロー内のビュー・アクティビティに対応するページまたはページ・フラグメントに対して自動的には追加されません。それぞれのページまたはページ・フラグメントに手動で追加する必要があります。ページのテンプレートを使用して追加することも可能です。

   ページに追加すると、コンポーネントは自動的にトレイン・モデルにバインドされます。トレイン・モデルの作成に関する詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。

18.9.4 アクティビティのグループ化について

ルーターおよびメソッド・コールなどのアクティビティは、ビュー・アクティビティでグループ化して、1つのトレイン・ストップにすることができます。図18-7の顧客登録バインド・タスク・フローでは、createAddressメソッド・コール・アクティビティおよびaddressDetailsビュー・アクティビティがdefineAddressビュー・アクティビティでグループ化されて、トレインの2番目のストップを形成しています。トレイン・ストップへのアクセス時には、毎回これらのアクティビティがセットとして実行されます。createAddressは、「住所」ページでのユーザー入力を検証するもので、defineAddressは、エンド・ユーザーが追加の住所情報を入力できるオプションのページです。これはオプションのページであり、「住所」ページにあるリンクからアクセスされるため、バインド・タスク・フローに別個のトレイン・ストップとして含められません。かわりに、createAddressトレイン・ストップのアクティビティの1つとしてグループ化されます。

注意: 一連のアクティビティをグループ化してトレイン・ストップを形成する方法として、子バインド・タスク・フローを使用します(18.9.5項「子タスク・フローでのアクティビティのグループ化について」を参照)。この方法では、トレイン・ストップに最初にアクセスしたか、後で戻ったかどうかは関係なく、常にグループ内のすべてのアクティビティがまとめて実行されるので便利です。 子バインド・タスク・フローを使用しない場合、先行する非ビュー・アクティビティから次のビュー・アクティビティまでのすべてのアクティビティがトレイン・ストップ実行の一部とみなされます。

この方法では子バインド・タスク・フロー内でトレイン・ストップ用の一連のアクティビティがグループ化されますが、子バインド・タスク・フローをコールせずに同様の機能を提供することもできます。その場合、図18-10のように、親バインド・タスク・フローでアクティビティをグループ化できます。最初の非ビュー・アクティビティから次のビュー・アクティビティまでのすべてのアクティビティが、暗黙的なトレイン・ストップ実行の一部とみなされます。

子バインド・タスク・フローを使用せずにアクティビティをグループ化するには、次の条件を満たしている必要があります。

• ルーターやメソッド・コールなど、そのトレイン・ストップのすべての非ビュー・アクティビティおよび非タスク・フロー・コール・アクティビティが、トレイン・ストップとして使用されるビュー・アクティビティやタスク・フロー・コール・アクティビティの後に続くこと。

  これにより、アクティビティはトレイン・ストップと関連付けられ、トレイン内の前のストップとは関連付けられません。

• ワイルドカード制御フローによりトレイン・ストップの最初のアクティビティに進むこと。

  このワイルドカード制御フローから導かれる制御フローでは、from-outcomeに値を指定する必要があります(例: gotoCollateSurveryAnswers)。この値は、トレイン・ストップとして使用されるビュー・アクティビティのトレインのoutcomeに指定する値と一致する必要があります。

  こうすることで、エンド・ユーザーが以前にアクセスしたトレイン・ストップに戻った場合に、ワイルドカード制御フローがポイントするアクティビティを開始地点として、すべてのアクティビティが実行されるようになります。

図18-10のSurveyPage2トレイン・ストップを構成するアクティビティのグループと、実行される順序について次に示します。

図18-10 タスク・フロー・コール・アクティビティを使用しない場合のアクティビティのグループ化

1. トレイン・ストップの最初のアクティビティに導くワイルドカード制御フローであるCollateSurveyAnswers。

   
   

   注意: トレイン・ストップのoutcome要素は、メソッド・コール・アクティビティやルーターなどのアクティビティがビュー・アクティビティ・トレイン・ストップよりも前に配置されている場合のみ使用されます。この要素を使用すると、トレイン・ストップに移動するカスタムのoutcomeを指定できるようになります。

   
   

2. CollateSurveyAnswersメソッドへのメソッド・コール。

3. SurveyPage2ビュー。

18.9.5 子タスク・フローでのアクティビティのグループ化について

子バインド・タスク・フロー内で、関連するアクティビティ群を対応するビュー・アクティビティと一緒にグループ化することも可能です。その後、トレイン内でトレイン・ストップとしてタスク・フロー・コール・アクティビティを指定できます。詳細は、15.6項「タスク・フロー・コール・アクティビティの使用」を参照してください。このタスク・フロー・コール・アクティビティで子バインド・タスク・フローをコールします。アクティビティのグループは、トレイン・ストップに最初にアクセスしたか後で戻ったかどうかには関係なく、常にまとめて実行されます。

ベスト・プラクティス: コール先の子バインド・タスク・フロー内でアクティビティをグループ化した場合、通常、ルーターやメソッド・コールなどの非ビュー・アクティビティは制御フロー内のビュー・アクティビティに先行します。子バインド・タスク・フローには複数のビュー・アクティビティを含めることができますが、ほとんどの場合は1つのみ存在します。

コール先の子バインド・タスク・フロー内でアクティビティをグループ化するには、次の条件を満たしている必要があります。

• ルーターやメソッド・コールなど、トレイン・ストップのあらゆる非ビュー・アクティビティが、子バインド・タスク・フローの制御フロー内のビュー・アクティビティに先行すること。

• ビュー・アクティビティが主要トレイン・ストップのビュー・アクティビティからアクセスされるダイアログやヘルプ・ページである場合を除き、子タスク・フローにビュー・アクティビティが1つのみ含まれていること。

図18-11に、子バインド・タスク・フローをコールするタスク・フロー・コール・アクティビティであるSurveyTaskFlowトレイン・ストップを示します。

図18-11 タスク・フロー・コール・アクティビティのトレイン・ストップ

図18-21に、子バインド・タスク・フローを示します。

図18-12 コール先の子バインド・タスク・フロー

子バインド・タスク・フロー内のあらゆるアクティビティは、エンド・ユーザーが最初にアクセスしたか後でアクセスしたかに関係なく、SurveyTaskFlowトレインにアクセスするたびにまとめて実行されます。

子バインド・タスク・フローを使用して一連のアクティビティをグループ化する場合は、子タスク・フローにタスク・フロー・リターン・アクティビティを追加する必要があります。このタスク・フロー・リターン・アクティビティにより、親バインド・タスク・フローに戻ってトレインが続行されます。タスク・フロー・リターン・アクティビティでは、outcomeに、親トレインに戻る際に使用される値(例: done)を指定する必要があります。また、子タスク・フローから戻った後、トレイン内のコントロール・フローを続行するために使用される制御フローを、親タスク・フローに手動で追加する必要があります。

図18-11および図18-12のように、制御フロー・ケースのfrom-outcomeに指定した値(done)は、タスク・フロー・リターン・アクティビティのoutcomeの値と一致します。

18.9.6 子トレインの使用について

トレインでは、タスク・フロー・コール・アクティビティをトレイン・ストップとして使用して、別のトレインを表す子バインド・タスク・フローを呼び出せます。この子バインド・タスク・フローはその独自のトレインとして作成する(つまり、そのメタデータ内に<train/>要素を指定する)必要があり、また独自のトレイン・ストップを含める必要があります。子トレインのコールに深さ制限はありません。

18.9.7 ブランチ化について

単一のトレイン・ストップを表すようにグループ化したアクティビティのグループ内では、ルーター・アクティビティや制御フロー・ケースを使用したブランチ化が可能で、たとえば、図18-13では、ステップ2の下にあるワイルドカード制御フロー・ルール・ルーターや各メソッド・コールがこれに該当します。

トレイン内の各トレイン・ストップを表すアクティビティ間をブランチ化することはできません。たとえば、図18-13の場合にstep1、2および3の間でブランチ化することはできません。

図18-13 単一のトレイン・ストップ用にグループ化されたアクティビティ内でのブランチ化

18.10 複数のタスク・フローの実行

Fusion Webアプリケーション内および同じHTTPセッション内で、複数のタスク・フローを同時に実行できます。多くの場合、各タスク・フローを別々のブラウザ・ウィンドウで実行できます。たとえば、顧客サポート担当者は、顧客ごとに専用のブラウザ・ウィンドウを使用して、複数の顧客の状況に同時に対応できます。

アプリケーションまたはブラウザによるリクエストからタスク・フローを開始して、新しいブラウザ・ウィンドウに表示できます。

• アプリケーションによる新規ウィンドウのリクエスト

  アプリケーション自体が新しいブラウザ・ウィンドウをリクエストする場合があります。これは、新しいブラウザ・ウィンドウを起動するボタン、表の行、またはリンクをエンド・ユーザーがクリックした場合に発生します。UIコンポーネントのJavaScriptにより、ロードするURLが指定されます。

• ブラウザによる新規ウィンドウのリクエスト

  [Ctrl]キーを押しながら[N]キー(Mozilla FireFoxの場合は[Ctrl]キーを押しながら[T]キー)を押して、または「ファイル」→「新規ウィンドウ」の順に選択して、新しいブラウザ・ウィンドウをエンド・ユーザーが開始することもできます。

  Microsoft Internet Explorerの場合は、[Ctrl]キーを押しながら[N]キーを押すと、web.xmlファイルで定義されているアプリケーションのホームページが開きます。新しいウィンドウのサーバーの状態は、元のウィンドウから分離されます。

アプリケーションでは、異なるフレーム、複数のポートレットまたはADFリージョンを単一のブラウザ・ウィンドウ内で使用することもできます。ビュー・ポートは、ビューを表示する領域およびその独立したナビゲーションを表します。ビュー・ポートは、フル・ブラウザ・ウィンドウ、フレーム、ポートレットまたはADFリージョンになる可能性があります。

各ビュー・ポートでは、エンド・ユーザーの現在のナビゲーション状態を表すタスク・フローのスタックが保持されます。ビュー・ポートのタスク・フローのスタックは、アプリケーションのトップ・レベル・タスク・フローをスタックの最初のエントリとして開始されます。エンド・ユーザーがバインド・タスク・フローに移動すると、バインド・タスク・フローを表す追加のエントリがスタックに格納されます。エンド・ユーザーがバインド・タスク・フローの外へ移動すると、エントリはスタックから削除されます。エンド・ユーザーが親ページの外へ移動した場合は、子モードおよびモーダル・ダイアログがすべて閉じます。

ベスト・プラクティス: 必須ではありませんが、フレームワークの設計上、ブラウザ・ウィンドウが閉じた場合にADF Controllerに通知することをお薦めします。そうすることで、ブラウザ・ウィンドウのビュー・ポートに割り当てられたリソース(マネージドBeanや、開いている未解決のトランザクションなど)を、ADF Controllerでクリーンアップすることが可能になります。

18.10.1 ADFリージョンでのViewPortInstanceの動作について

バインド・タスク・フロー・リージョンを含むページがレンダリングされる際にビュー・ポートを作成することもできます。Fusion Webアプリケーションの最初のアクティビティに対するリクエストを受信すると、ADF Controllerによって、メイン・ブラウザ・ウィンドウに対応するビュー・ポートおよびViewPortContextが作成されます。各ADFリージョンにはViewPortContextインスタンスが関連付けられています。ViewPortContextインスタンスは、JSFライフサイクルのビューのリストア・フェーズで作成されます。

ADF Controllerでは、JSF RIのFacesContextとの相互作用が必要になるたびに、ViewPortContextインスタンスが使用されます。ViewPortContextには、直接FacesContextへ、またはADFビューのAPIへ、すべてのコールをディスパッチする役割があります。たとえば、ADF Controllerによってビュー・ポートの新しいビュー・アクティビティが検出されると、ViewPortContext.setRootViewIdがコールされます。ルート・ページを表すバインド・タスク・フローでは、このコールの結果、FacesContext.setRootViewIdがコールされます。ADFリージョン内に埋め込まれているバインド・タスク・フローでは、ViewPortContextによってルート・ビューIDが追跡されます。ADFビューは、ルート・ページのページ・マークアップの作成準備が完了すると、ViewPortContextに格納されているADFリージョン・コンポーネントのビューIDにアクセスできます。

たとえば、ADFリージョンを含むページがレンダリングされると、エンド・ユーザーがADFリージョン内のボタンをクリックし、それによってフォームが発行されます。

1. ADF Controllerによって、ADFリージョン用に作成されたビュー・ポートのコンテキストで、リクエストが処理されます。

2. ADF ControllerのNavigationHandlerがコールされる前に、ADFリージョンによって正しいViewPortContextが設定されます。

3. from-actionおよびfrom-outcomeの値に基づいて、ADF Controllerによってバインド・タスク・フロー・リージョンの次のビュー・アクティビティのIDが生成され、ViewPortContextに設定されます。

4. ADFビューでは、ADFリージョンの新しいマークアップを取得するために、JSFライフサイクルのレスポンス・レンダリング・ステージでビュー・アクティビティIDが使用されます。NavigationHandlerはリージョンのコンテキストでコールされるため、メイン・ページのルート・ビューIDはリセットされません。

5. エンド・ユーザーがページの外へ移動すると、バインド・タスク・フロー・リージョンは破棄されます。ビュー・レイヤーは、ADFリージョンに割り当てられたリソースが解放されるように、再度ADF Controllerに通知します。

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

他の開発者が新しいバインド・タスク・フローを作成する際の起点として使用できる、タスク・フロー・テンプレートを作成できます。

注意: タスク・フロー・テンプレートは、新しいバインドなしタスク・フローの作成のベースとしては使用できません。

タスク・フロー・テンプレートに基づくすべてのバインド・タスク・フローには、そのテンプレートに含まれるアクティビティ、制御フロー、入力パラメータおよびマネージドBean定義の同一セットが含まれるため、タスク・フロー・テンプレートを使用すると、再利用が可能になります。また、テンプレートに対する変更が、そのテンプレートに基づいて作成されたあらゆるタスク・フローまたはテンプレートに自動的に伝播されるように指定することもできます。

たとえば、バインド・タスク・フローの例外ハンドラとして使用するアクティビティ(グローバルな例外を処理するためのページに関連付けられたビュー・アクティビティなど)を設定したとします。または、タスク・フローでの発生が一般的に予測される例外を処理するために、例外ハンドラが設定されているとします。複数のバインド・タスク・フローを同じエラー・ハンドラに依存させる場合は、このエラー・ハンドラをタスク・フロー・テンプレートに追加することを検討できます。テンプレートに基づいて作成された新しいタスク・フローには、テンプレートに追加された例外処理アクティビティが自動的に組み込まれます。詳細は、18.6項「タスク・フローでの例外の処理」を参照してください。

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

「ADFタスク・フローの作成」または「ADFタスク・フロー・テンプレートの作成」ダイアログの「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択すると、そのテンプレートは参照で再利用されます。テンプレートに対するすべての変更は、そのテンプレートに基づいて作成されたすべてのバインド・タスク・フローまたはタスク・フロー・テンプレートに伝播されます。

18.11.1 タスク・フロー・テンプレートのコピーおよび参照方法

タスク・フロー・テンプレートの再利用には2つの方法があります。

• コピーによる再利用

  新しいバインド・タスク・フローの作成時に「テンプレートの変更時にタスク・フローを更新」チェック・ボックスの選択を解除します(図18-14を参照)。このチェック・ボックスの選択を解除すると、そのバインド・タスク・フローはテンプレートに依存しなくなります。テンプレートに加えた変更は、そのバインド・タスク・フローには伝播されません。

  たとえば、複数のJSFページに関連付けられた複数のビュー・アクティビティをテンプレートに追加すると、新しいバインド・タスク・フローにはそのビュー群やビュー間のすべての制御フローが表示され、ビューとJSFページの関連付けは保持されます。タスク・フロー・テンプレートにトレインを追加すると、それに基づいて作成されたすべてのバインド・タスク・フローにそのトレインのページ・ナビゲーションが含まれます。

• 参照による再利用

  新しいバインド・タスク・フローの作成時、または新しいタスク・フロー・テンプレートの作成時に、「テンプレートの変更時にタスク・フローを更新」チェック・ボックスを選択します(図18-14を参照)。親タスク・フロー・テンプレートに対する変更は、そのテンプレートに基づいて作成されたあらゆるバインド・タスク・フローまたはテンプレートに伝播されます。

  子バインド・タスク・フローまたはタスク・フロー・テンプレートの親タスク・フロー・テンプレートは、子の開発中のどの段階でも変更、更新、関連付けの解除が可能です。

実行時には、参照によって再利用された子バインド・タスク・フローまたは子テンプレートの内容が、親テンプレートの内容に付加的に組み合されます。親テンプレートと子タスク・フローまたは子テンプレートが衝突した場合、必ず子が優先されます。たとえば、トレインを含む親タスク・フロー・テンプレートを作成してから、その親テンプレートに基づいて子バインド・タスク・フローを作成するとします。その後で、バインド・タスク・フローの概要エディタの「動作」ページにある「トレイン」チェック・ボックスを選択解除します。この場合、親テンプレートと子タスク・フローでの「トレイン」チェック・ボックスの設定の違いが、衝突となります。

表18-3に、各要素に対して使用される固有の組合せアルゴリズムを示します。この表に示すように、トレインの設定間における衝突では、子タスク・フローが親タスク・フロー・テンプレートをオーバーライドします。

表18-3 親テンプレートと子の間における衝突の解決

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

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

18.11.2 別のタスク・フローからタスク・フロー・テンプレートを作成する方法

既存のテンプレートから新しいタスク・フロー・テンプレートを作成するプロセスは、テンプレートに基づいてバインド・タスク・フローを作成するプロセスに類似しています。詳細は、14.2項「タスク・フローの作成」を参照してください。

18.11.3 タスク・フロー・テンプレートの使用方法

タスク・フロー・テンプレートの作成後は、そのテンプレートに基づいて新しいバインド・タスク・フローや新しいタスク・フロー・テンプレートを作成できます。図18-14に示すように、「タスク・フローの作成」ダイアログには、テンプレート・ファイルの名前およびIDに基づいてバインド・タスク・フローを作成するためのフィールドがあります。テンプレートのファイル名とIDの両方を指定する必要があります。これらのフィールドは、「バインド・タスク・フローとして作成」チェック・ボックスを選択した場合にのみ使用できます。

図18-14 「タスク・フローの作成」ダイアログ

既存のテンプレートに基づいて新しいテンプレートを作成できます。「ADFタスク・フロー・テンプレートの作成」ダイアログ・ボックスには、既存のタスク・フロー・テンプレートのファイル名およびテンプレートIDに基づいてタスク・フロー・テンプレートを作成するためのフィールドがあります。

タスク・フロー・テンプレートはそのままでは実行できません。詳細は、14.4項「ADFタスク・フローのテスト」を参照してください。

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

新しいタスク・フロー・テンプレートの作成プロセスは、バインド・タスク・フローの作成プロセスに類似しています。この項では、新しいタスク・フロー・テンプレートの作成方法を説明します。既存のバインド・タスク・フローをタスク・フロー・テンプレートに変換することや、その逆の処理も可能です。詳細は、18.11.2項「別のタスク・フローからタスク・フロー・テンプレートを作成する方法」を参照してください。

タスク・フロー・テンプレートを最初から作成する手順:

1. アプリケーション・ナビゲータで、タスク・フローを作成するプロジェクトを右クリックして、「新規」を選択します。

2. 「新規ギャラリ」で「Web層」を開きます。

3. 「JSF」→「ADFタスク・フロー・テンプレート」の順に選択して「OK」をクリックします。

   作成するタスク・フロー・テンプレートのXMLソース・ファイルの名前には、「ファイル名」の値が使用されます。ソース・ファイルには、タスク・フロー・テンプレートにあるアクティビティおよび制御フロー・ルールが含まれます。XMLソース・ファイルのデフォルト名はtask-flow-template.xmlです。

4. 「ADFタスク・フロー・テンプレートの作成」ダイアログでは、デフォルトで「ページ・フラグメントを使用して作成」チェック・ボックスが選択されています。テンプレートに基づくバインド・タスク・フローをADFリージョンとして使用する場合は、このオプションを選択します。

   タスク・フロー・テンプレートにJSFページ・フラグメントではなくJSFページを追加する場合は、このチェック・ボックスの選択を解除します。

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

   エディタで、タスク・フロー・テンプレートのダイアグラムが自動的に開きます。

6. アクティビティ、制御フローおよびその他の項目をテンプレートに追加できます。

   バインド・タスク・フローに追加できるものは、すべてタスク・フロー・テンプレートに追加できます。

7. 終了したら、作業内容を保存します。

   テンプレートは、バインド・タスク・フローやタスク・フロー・テンプレートの作成時に使用できます。

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

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

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

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

<?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>

18.11.6 バインディングを使用するタスク・フロー・テンプレートについて

バインディングを含むタスク・フロー・テンプレートを使用する場合、そのタスク・フロー・テンプレートを基盤とするタスク・フローのコンポーネントIDを変更する必要があります。これにより、IDは一意になります。テンプレートから生成されるタスク・フローでは、テンプレートと同じIDが継承されます。そのため、実行時に例外が発生します。

詳細は、20.2.1項「ADFページ・テンプレートでのADFデータ・バインディングの使用方法」を参照してください。

18.12 ページ階層の作成

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

図18-15 ページ階層

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

図18-16 給付金ページ

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

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

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

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

• エンド・ユーザーがメニュー項目を選択すると表示されるビューまたはページを決定する制御フロー・メタデータ

• XMLMenuModelメタデータ・ファイル

• デフォルトのナビゲーション・ウィジェット(「前へ」ボタン、「次へ」ボタンなど)

• ブレッドクラム

• マネージドBeanの構成

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

18.12.1 ページ階層の作成方法

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

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

• 最上位のメニュー(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)のページを参照するグループ・ノードです。

図18-18 メニュー階層

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

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

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

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

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

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

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

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

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

   
   

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

   
   

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

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

   図18-20 タスク・フローのビュー・アクティビティ

   
   

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

   ビュー・アクティビティの追加に関する詳細は、15.2.1項「ビュー・アクティビティの追加」を参照してください。

   
   

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

   
   

3. 「アプリケーション・ナビゲータ」で、手順 1で作成したそれぞれのバインドなしタスク・フローのファイルを右クリックして、「ADFメニュー・モデルの作成」を選択します。

4. 「ADFメニュー・モデルの作成」ダイアログで、XMLMenuModelメタデータ・ファイルのファイル名および保存先ディレクトリを入力ます。

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

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

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

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

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

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

2. これらの項目ノードをドラッグ・アンド・ドロップして、グループ・ノードに変換する項目ノードの子ノードにします。

   グループ・ノードに変換する各項目ノードには、少なくとも1つの子項目ノードが必要です。たとえば、図18-18のメニュー階層を作成するには、Benefitsの項目ノードをグループ・ノードに変換し、Medical、DentalおよびVisionの項目ノードをドラッグ・アンド・ドロップしてBenefit項目ノードの子ノードにします。

3. 構造ウィンドウで親項目ノードを右クリックし、「groupNodeへの変換」を選択します。

4. 表示される「groupNodeのプロパティ」ダイアログの「ID」フィールドで、新しい識別子を入力するか、デフォルト値を受け入れます。

   識別子は、すべてのXMLMenuModelメタデータ・ファイルのすべてのノードで一意であることが必要です。ノードを識別する値を指定することをお薦めします。たとえば、Benefitsノードをグループ・ノードに変更する場合、デフォルトIDであるitemNode_benefitsをgroupNode_benefitsに更新できます。

5. 「groupNodeのプロパティ」ダイアログのidrefフィールドに、メニュー内にある他のいずれかのノードのID(例: itemNode_Medical)を入力します。

   入力する値は、グループ・ノードまたは項目ノードである、子項目ノードのIDでもかまいません。

6. labelフィールドに値を入力するか既存のデフォルト値を変更して、実行時に表示する値を指定します。

   たとえば、label_benefitsをBenefitsなどに変更できます。

7. フィールドの残りのデフォルト値を受け入れて、「終了」をクリックします。

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

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

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

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

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

1. 「アプリケーション・ナビゲータ」で、他のメニューを参照させるメニューのXMLMenuModelメタデータ・ファイルを選択して開きます。

2. 構造ウィンドウで、ノードを選択して右クリックし、sharedNode要素を挿入する、適切なメニュー・オプションを選択します。

3. 表示される「sharedNodeの挿入」ダイアログのrefフィールドに、もう1つのメニューのXMLMenuModelメタデータ・ファイルを参照するためのEL式を入力します。

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

   
   

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

   
   

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

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

adfc-config.xmlの変更内容

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

例18-11 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メタデータ・ファイルが生成されます(例18-2を参照)。

例18-12 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によって更新されます。図18-21は、図18-20のバインドなしタスク・フローに対応する更新後のバインドなしタスク・フローをダイアグラマで示しています。

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

18.13 タスク・フローでのBPELの使用

Business Process Execution Language (BPEL)は、複数のサービスを構成して1つのエンドツーエンド・ビジネス・プロセスにするための言語です。タスク・フローでBPELを使用して、次のことを行えます。

• バインドなしタスク・フローまたはバインド・タスク・フローからBPELプロセスを起動して、関数を実行したり、サービスを使用すること

• BPEL Process Managerからバインド・タスク・フローをコールして、ユーザーとWebインタフェースの相互作用をモデル化すること

BPELの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

18.13.1 タスク・フローからのBPELプロセスの起動方法

次のいずれの方法でも、バインドなしタスク・フローまたはバインド・タスク・フローからBPELプロセスをコールできます。

• タスク・フロー・ダイアグラムの既存のメソッド・コール・アクティビティを、BPELプロセス・コールをJavaコンポーネントとしてラップするマネージドBeanメソッドにバインドします。詳細は、15.5項「メソッド・コール・アクティビティの使用」を参照してください。

• タスク・フロー・ダイアグラムの既存のメソッド・コール・アクティビティを、BPELプロセス・コールをWebサービスとして実行するアクション・バインディングにバインドします。詳細は、15.5項「メソッド・コール・アクティビティの使用」を参照してください。Webサービスとしてコールする場合は、Webサービス・データ・コントロールを使用する方法をお薦めします。

実行時には、BPELプロセスへのリクエストがペイロードの形で配置されます。BPELプロセスはペイロードを受け取り、アプリケーションがリクエストした情報を含むペイロードとともにレスポンスを返します。BPELプロセスの結果、バインドなし・タスク・フローまたはバインド・タスク・フロー内の制御フローが続行されます。

18.13.2 BPELからのバインド・タスク・フローのコール方法

BPELワークフロー・サービスを使用すると、エンドツーエンドのフロー内で、タスクの間にユーザーの操作を割り込ませることができます。BPELプロセス・フローの中で、タスクがユーザーまたはロールに割り当てられ、レスポンスを待機します。ユーザーは、BPELワークリスト・アプリケーションを使用してタスクを操作します。このワークリスト・アプリケーションでは、ユーザーのタスクの一部として割り当てられているバインド・タスク・フローを開始できます。BPELプロセスのユーザー操作フレームワーク(通知、エスカレーション・ポリシー、ワークリストなど)を利用すると同時に、バインド・タスク・フロー機能を使用できます。