Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
![]() 前 |
![]() 次 |
この章の内容は次のとおりです。
ADFタスク・フローは、アクティビティ・ノード間の接続のグラフィカル表現です。この方法では、再利用可能なタスク・フローのモジュール型セットを作成し、制御フロー・ケースを使用して結合して、アプリケーションを表すことができます。タスク・フローの2つのタイプは、バインドなしタスク・フローとバインド・タスク・フローです。
ADFタスク・フローでは、Fusion Webアプリケーションの制御フローを定義するためのモジュール・アプローチが提供されます。アプリケーションを1つの大きなJSFページフローとして表すかわりに、再利用可能なタスクフローの集合として分類することができます。各タスクフローにはアプリケーションのナビゲーショナル・グラフの一部が含まれます。タスクフロー内のノードはアクティビティです。アクティビティ・ノードでは、ページの表示、アプリケーション・ロジックの実行または別のタスク・フローのコールなど、シンプルな論理的操作が表示されます。アクティビティ間のトランザクションは制御フロー・ケースと呼ばれます。
図23-1には、Create
とConfirm
と呼ばれる2つのビュー・アクティビティが示されています。これらのビュー・アクティビティは、JSFページ・フロー内部のページ・ノードに類似しています。
図23-1 ADFタスク・フロー
ADFタスク・フローには次の2つの種類があります。
バインドなしタスク・フロー: ユーザーがタスクを完了できるように対話する一連のアクティビティ、制御フロー・ルールおよびマネージドBeanです。バインドなしタスク・フローは、バインド・タスク・フローに含まれていない、アプリケーション内のすべてのアクティビティおよび制御フローで構成されています。
バインド・タスク・フロー: タスク・フローの特殊な形式であり、バインドなしタスク・フローとは異なり、単一エントリ・ポイント(ブラウザからの直接の要求が可能なビュー・アクティビティ)と0以上の終了ポイントがあります。プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットが含まれています。バインド・タスク・フローでは、再利用、パラメータ、トランザクション管理および再開が可能なほか、JSFページにあるADFリージョン内へのレンダリングも可能です。
バインドなしタスク・フローまたはバインド・タスク・フローに追加可能なアクティビティ・タイプの詳細は、「タスク・フロー・アクティビティの使用」を参照してください。
デフォルトでは、JDeveloperはバインド・タスク・フローのソース・ファイルに対して次のファイル名を使用します。
task-flow-definition
N
.xml
ここでN
は新しいバインド・タスク・フローを作成するたびに増分する番号です。バインド・タスク・フローのファイル名を選択できます。たとえば、バインド・タスク・フローの目的が顧客によるショッピング・アプリケーションのチェックアウトを可能にすることであれば、checkout-task-flow.xml
を使用できます。
ソース・ファイルには、バインド・タスク・フローのメタデータが含まれています。次のメタデータを使用して、複数のバインド・タスク・フローを同一ソース・ファイル内に追加できます。
<task-flow-definition id="TaskFlowID1"> ... </task-flow-definition> <task-flow-definition id="TaskFlowID2"> ... </task-flow-definition>
ただし、JDeveloperのビジュアル・エディタではファイルごとに1つのバインド・タスク・フローが表示されるため、2つ以上のバインド・タスク・フローを同一ソース・ファイル内に追加しなければ、バインド・タスク・フローの変更が容易になります。
通常のアプリケーションでは、バインドなしタスク・フローと1つまたは複数のバインド・タスク・フローが組み合されています。たとえば、Fusion Webアプリケーション・テンプレートを使用してアプリケーションを作成する場合、JDeveloperでは、空のバインドなしタスク・フロー(ソース・ファイル名はadfc-config.xml
)がデフォルトで作成されます。実行時、Fusion Webアプリケーションでは、バインドなしタスク・フローに追加したアクティビティからバインド・タスク・フローをコールできます。
図23-2に示すように、アプリケーションで実行する最初のアクティビティは、多くの場合、バインドなしタスク・フロー内のビュー・アクティビティです。ビュー・アクティビティは、アプリケーションの一部として表示するJSFページを表します。図23-2に示すアクティビティは、Home
ビュー・アクティビティで始まり、バインド・タスク・フローをコールします。calltoLogin_taskFlow
アクティビティは、ユーザーのアプリケーションへのログインを可能にするバインド・タスク・フローをコールします。
図23-2 バインド・タスク・フローをコールするバインドなしタスク・フロー
また、バインドなしフロー内にすべてのアプリケーション・アクティビティが含まれているアプリケーションを設計できます。これは、JSFアプリケーションを模倣していますが、バインド・タスク・フローの機能の利点が活用されていません。タスク・フロー機能を十分に活用するには、バインド・タスク・フローを使用します。
表23-1では、JSFページ・フローが提供する制御フローと比較して、ADFタスク・フローが提供する制御フローがもたらす利点について説明します。シナリオによっては、JSFページ・フローの使用が必要な場合もあります。たとえば、「ADFページ・ライフサイクルのカスタマイズ」の説明のように、フェーズ・リスナーを使用するには、JSFページ・フローのfaces-config.xml
構成ファイルを使用する必要があります。一般には、アプリケーションでJSFページ・フローとADFタスク・フローを併用することをお薦めしません。
表23-1 ADFタスク・フローの利点
JSFページ・フロー | ADFタスク・フロー |
---|---|
アプリケーション全体を単一のページ・ナビゲーション・ファイルに配置する必要があります( |
アプリケーションは、相互にコールする一連のモジュール型のフローに分割できます。 |
JSFページ・フロー内のすべてのノードは、JSFページである必要があります。他のタイプのオブジェクトは、JSFページ・フロー内には存在しません。 |
ビュー、メソッド・コールおよび他のタスク・フローへのコールなどのタスク・フロー・ダイアグラム・ノードに追加できます。 |
ナビゲーションはページ間のみです。 |
ナビゲーションは複数のページや、ルーターを含む他のアクティビティにも及びます。「ルーター・アクティビティの使用方法」を参照してください。 |
アプリケーション・フラグメントを再利用できません。 |
ADFタスク・フローは、同一、または完全に別のアプリケーション内で再利用可能です。 アプリケーションをタスク・フローに分割した後で、一般機能を備えたタスク・フローを再利用できます。 「アプリケーション・コンポーネントの再利用」を参照してください。 |
セッション・スコープを除き、複数のリクエスト間では共有メモリー・スコープがありません。 |
タスク・フロー内のアクティビティ間でのデータ渡しを可能にする共有メモリー・スコープ(ページ・フロー・スコープなど)があります。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。 |
Fusion Webアプリケーションには常にADFバインドなしタスク・フローが組み込まれており、アプリケーションへのエントリ・ポイントが含まれています。エントリ・ポイントは、ブラウザからの直接の要求が可能なビュー・アクティビティです。Fusion Webアプリケーションには、1つのバインドなしタスク・フローのみが含まれます。デフォルトでは、バインドなしタスク・フローのソース・ファイルはadfc-config.xml
ファイルです。バインドなしタスク・フローに対して追加ソース・ファイルを作成できますが、アプリケーションでは、実行中のすべてのソース・ファイルがadfc-config.xml
ファイルにまとめられます。図23-3は、アプリケーションからのバインドなしタスク・フローのダイアグラムを示しています。このタスク・フローにはいくつかのビュー・アクティビティが含まれており、いずれもアプリケーションへのエントリ・ポイントになっています。
図23-3 バインドなしタスク・フロー
次の場合には、バインド・タスク・フローではなく、バインドなしタスク・フローを使用します。
ビュー・アクティビティのブックマークなど、バインド・タスク・フローでは提供されないADFコントローラ機能を利用する場合。詳細は、「ビュー・アクティビティのブックマーク」を参照してください。
タスク・フローが別のタスク・フローによってコールされない場合。
アプリケーションに複数のエントリ・ポイントがある場合。図23-3では、バインドなしタスク・フロー上にビュー・アクティビティ・アイコンで表されるどのページからでも、タスク・フローを開始できます。
バインドなしタスク・フローではパラメータを宣言的に指定できません。さらにここでは、デフォルト・アクティビティ、つまりバインドなしタスク・フローで最初に実行するよう設計されたアクティビティも含まれません。これは、バインドなしタスク・フローには単一エントリ・ポイントがないためです。これらのいずれかを実行するには、バインド・タスク・フローが必要です。
完全に宣言的なADFコントローラ・トランザクションおよび再開サポートの利点を活用するには、バインドなしタスク・フローではなくバインド・タスク・フローを使用します。
ADFバインド・タスク・フローを使用して、アプリケーションの再利用可能な部分をカプセル化します。バインド・タスク・フローは、次のようなJavaメソッドに類似しています。
単一エントリ・ポイントがある。
入力パラメータを受け入れることができる。
戻り値を生成できる。
アクティビティおよび制御フロー・ルールの独自のコレクションがある。
独自のメモリー・スコープおよびマネージドBeanの存続期間(ページ・フロー・スコープ・インスタンス)がある。
メモリー・スコープの詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。
独立したデータ・コントロール・フレームがあるのかどうかを判別できます。
データ・コントロール・フレームへのアクセスの詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。
アクティビティを例外処理アクティビティとして定義できます。
バインド・タスク・フローの例外処理の詳細は、「タスク・フローの例外処理」を参照してください。
図23-3のcreateOrder
アクティビティはバインド・タスク・フローのコールです。バインドなしタスク・フローは、バインド・タスク・フローをコールできますが、別のタスク・フローからコールできません。バインド・タスク・フローからは別のバインド・タスク・フローをコールでき、さらにそのバインド・タスク・フローからも次々にコールできます。コールに深さ制限はありません。
図23-4は、バインド・タスク・フローを示しています。
図23-4は、バインド・タスク・フローを示しています。
バインド・タスク・フローを作成する理由は次のとおりです。
バインド・タスク・フローでは、常にバインド・タスク・フローの開始直後に実行する必要のある単一エントリ・ポイントとなる、デフォルト・アクティビティを指定します。
図23-4では、これはreconcileOrdersとラベル付けされたメソッド・コール・アクティビティです。メソッド・コール・アクティビティはデフォルトのアクティビティであるため、常にバインド・タスク・フローがorderビュー・アクティビティにより参照されるページをレンダリングする前に起動されます。
再利用可能です。たとえば、注文を管理またはチェックアウトするプロセスを必要とする他のアプリケーションに組み込むことができます。バインド・タスク・フローは、同じアプリケーション内でも再利用できます。
バインド・タスク・フロー内で使用するマネージドBeanは、ページ・フロー・スコープで指定できるため、残りのアプリケーションからは分離されます。これらのマネージドBean(およびページ・フロー・スコープ)は、タスク・フローが完了した際に自動的に解放されます。
表23-2に、バインド・タスク・フローの要約を示します。
表23-2 バインド・タスク・フローの機能
機能 | 説明 |
---|---|
明確に定義された境界 |
バインド・タスク・フローは、プライベート制御フロー・ルール、アクティビティおよびマネージドBeanの独自のセットで構成されます。コール元は、バインド・タスク・フロー境界内におけるページ名、メソッド・コール、子バインド・タスク・フロー、マネージドBean、制御フロー・ルールの内部知識を必要としません。入力パラメータをバインド・タスク・フローに渡すことが可能なほか、バインド・タスク・フローの終了時に戻り値を返すことが可能です。データ・コントロールはタスク・フロー間で共有できます。 |
単一エントリ・ポイント |
バインド・タスク・フローには、タスク・フロー内の他のすべてのアクティビティの前に実行されるデフォルト・アクティビティである、単一のエントリ・ポイントがあります。詳細は、「バインド・タスク・フローのデフォルト・アクティビティに関する必知事項」を参照してください。 |
ページ・フロー・メモリー・スコープ |
バインド・タスク・フロー内のアクティビティ間でデータを受け渡すためのメモリー・スコープとしてページ・フロー・スコープを指定できます。ページ・フロー・スコープは、バインド・タスク・フローの各インスタンスに対する一意の記憶域を定義します。その存続期間はバインド・タスク・フローであり、requestスコープより長く、sessionスコープより短くなっています。詳細は、「タスク・フローのメモリー・スコープに関する必知事項」を参照してください。 |
アドレス可能 |
バインド・タスク・フローにアクセスするには、バインド・タスク・フローのXMLソース・ファイルに記述されている一意の識別子とXMLソース・ファイルのファイル名を指定します。詳細は、「タスク・フロー・コール・アクティビティ追加時の処理」を参照してください。 |
再利用 |
アクティビティ・グループ全体を単一のエンティティ、つまりバインド・タスク・フローとして識別し、そのバインド・タスク・フローをADFリージョン内の別のアプリケーションで再利用できます。 また、既存のバインド・タスク・フローは、コールするのみで再利用できます。たとえば、あるタスク・フローは、タスク・フロー・コール・アクティビティまたはURLを使用して別のバインド・タスク・フローをコールできます。 さらに、タスク・フロー・テンプレートを使用して、様々なバインド・タスク・フローで再利用するための共通の動作を取得できます。詳細は、「タスク・フロー・テンプレートの作成」を参照してください。 |
パラメータおよび戻り値 |
コール元は、バインド・タスク・フローに入力パラメータを渡し、戻り値を取得します。詳細は、「バインド・タスク・フローへのパラメータ渡し」を参照してください。 また、バインド・タスク・フロー間でデータ・コントロールを共有できます。詳細は、「タスク・フロー間のデータ・コントロールの共有」を参照してください。 |
トランザクション管理 |
バインド・タスク・フローは、作業のトランザクション単位を示すことができます。タスク・フローの開始時に、新規のトランザクションを作成するか、既存のものを結合するか、または既存のトランザクションの一部ではないかどうかを決定するオプションをバウンド側のタスク・フローに宣言的に指定できます。詳細は、「タスク・フローのトランザクションの管理」を参照してください。 |
再開 |
再開できるかどうかを決定するオプションを、バインド側のタスク・フローで指定できます。詳細は、「バインド・タスク・フローの再開」を参照してください。 |
メタデータのオンデマンド・ロード |
バインド・タスク・フロー・メタデータは、バインド・タスク・フローの開始時にオンデマンドでロードされます。 |
セキュリティ |
バインド・タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。 |
表23-3にリストされている前提条件および制約を理解すると、ADFタスク・フロー、アクティビティおよび関連するADF Controller機能を正しく使用する上で役立ちます。
表23-3 ADFコントローラ機能の前提条件および制約
機能領域 | 前提条件/制約 | 説明 |
---|---|---|
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
JSFビュー・レイヤー |
ADFコントローラはJSF環境で動作します。OracleのWebベースのFusion Webアプリケーション戦略は、唯一のビュー・レイヤー・テクノロジとしてJSFに焦点を当てています。 |
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
Oracle ADF Faces依存 |
ADFコントローラの拡張機能はOracle ADF Faces上に実装されています。この機能はADF Facesライブラリに依存しますが、これらのライブラリが存在する場合はJSF実装に対して実行できます。 |
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
カプセル化されたナビゲーションおよび状態管理 |
ADFコントローラでは、ナビゲーションと(ある程度までの)状態管理もカプセル化します。JSFおよびサーブレットAPIは、現在もアプリケーション、セッションおよびリクエストのレベルでの基本の状態管理に利用できます。 |
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
モデル・レイヤー |
ADFモデル・レイヤーは、アプリケーションのモデル・レイヤーの実装に使用されます。 |
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
MDSへの依存 |
ADFコントローラ・メタデータはMDSに保存されます。ただし、MDSは現在 MDSが提供しているカスタマイズ機能が必要な場合は、ADFタスク・フローを占有使用してマネージドBeanと制御フロー・ルールの定義を行う必要があります。 |
ADFコントローラ・オブジェクトおよびダイアグラムのUI |
StrutsまたはModel 1からの移行パスのサポートなし |
StrutsまたはModel 1からADF Controllerへの移行はサポートされていません。 しかし、JSFページ・フローで選択したページに基づいて、新規のバインド・タスク・フローを作成できます。詳細は、「JSFページからのタスク・フローの作成方法」を参照してください。 |
バインド・タスク・フロー |
ページ・フロー・スコープ状態として公開 |
ADFコントローラは、ページ・フロー・スコープの状態の実装を管理します。フレームワークによって提供される自動管理機能(「戻る」ボタンのサポート、状態のクリーンアップ機能など)は、ページ・フロー・スコープのデータを想定しています。アプリケーションでそのページのすべてに対してこのような機能を完全実装するために、必要に応じてネストされたバインド・タスク・フローを使用して、アプリケーション全体をADFバインド・タスク・フローとして公開します。アプリケーションには、ページ・フロー・スコープ内にバージョニングを必要とする状態が格納されます。 |
バインド・タスク・フロー |
トランザクション境界 |
開発者は、ADFバインド・タスク・フローを使用してトランザクション境界を管理します。 |
ページ・フロー・スコープ |
ADFライフサイクル内のアクセスの可用性 |
ADFコントローラでアクセス準備ができる前のADFライフサイクルの初期段階では、アプリケーションによるページ・フロー・スコープへのアクセスは試行できません。 ページ・フロー・スコープは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerが実行されるまでは、アクセス可能になるとは保証されていません。ADFコントローラは、ビューのリストア・フェーズでBefore ListenerおよびAfter Listenerを使用して、サーバー側の状態をリクエストと同期化させます。ここでは、ブラウザの「戻る」ボタン検出やブックマーク参照解除などが処理されます。 |
ナビゲーション |
ナビゲーション |
ADFコントローラの使用時、 ADFコントローラはADFコントローラ・メタデータ内に一致する制御フロー・ケースがない場合にナビゲーション処理を委譲しますが、ADF以外コントローラ以外の |
タスク・フローは、アクティビティ、およびアクティビティ間の遷移を定義する制御フロー・ケースで構成されます。図23-5は、制御フロー・ルール、つまりラベル付けしたtoView2
を示しています。ここでは、ViewActivity1
およびViewActivity2
のビュー・アクティビティ間の遷移が定義されています。図23-5のタスク・フローが実行されると、ViewActivity1
ビュー・アクティビティがViewActivity2
ビュー・アクティビティの前に表示されます。
図23-5 アクティビティおよび制御フロー・ケースのあるタスク・フロー
また、図23-5のタスク・フローにはメソッド・コール・アクティビティ(methodCall1
)が含まれており、ViewActivity2
ビュー・アクティビティの後およびtaskflowCall1
タスク・フロー・コール・アクティビティの前に呼び出されます。タスク・フローでは、ページのレンダリング前後のメソッド・コール・アクティビティなどのアクティビティを呼び出します。特定のページの外部でメソッド・コール・アクティビティを呼び出すことによって再利用を促進できます。これは、そのメソッドを必要としない他のコンテキスト(別のタスク・フローなど)でページを再利用できるからです。制御フロー・ルールの詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。
ワイルドカード制御フロー・ルールは制御フローのfrom-activity-id
を表し、これには、後方ワイルドカード(foo*
)または単一ワイルドカード文字(*
)が含まれます。タスク・フロー内の任意のアクティビティからワイルドカード制御フロー・ルールに制御を渡す場合は、単一ワイルドカード文字を使用します。あるいは、ワイルドカード制御フロー・ルールに制御を渡すアクティビティを制限する場合は、後方ワイルドカードを使用します。
図23-6では、ワイルドカード制御フロー・ルールに単一ワイルドカード文字が含まれており、タスク・フロー内のどのアクティビティからでもタスク・フロー・ダイアグラムで接続先となっているアクティビティに制御を渡せることを示しています。
図23-6 単一ワイルドカードのあるワイルドカード制御フロー・ルール
図23-7の後方ワイルドカードは、activity-id
がsummit
という文字で始まる有効なソース・アクティビティからloginPage
ビューに制御フローを渡せることを示しています。
図23-7 後方ワイルドカードのあるワイルドカード制御フロー・ルール
ワイルドカード制御フロー・ルールの詳細は、「ワイルドカード制御フロー・ルールの追加方法」を参照してください。
図23-8は、Summitサンプル・アプリケーションのADFタスク・フローの画面を示しています。画面のエンド・ユーザーは、顧客のリストを表示するタスク・フローを起動します。画面に公開されるコントロールを使用して、エンド・ユーザーは注文の作成または編集を可能にするタスク・フローを起動することもできます。
図23-8 データを作成または編集するタスク・フロー
また、タスク・フローを使用して、エンド・ユーザーに公開するアクセス・ポイントの数を減らすことによって、Fusion Webアプリケーションのセキュリティを確保できます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローの「URL起動」プロパティをurl-invoke-disallowed
に設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。「URL起動」プロパティの詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。Fusion Webアプリケーションのセキュリティ保護の詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
ADFタスク・フローを構成または使用する前に、他のOracle ADF機能を理解しておくことは有効だと思われます。さらに、タスク・フローの構成で可能な機能について読むことが必要な場合もあります。次に、関連する他の機能へのリンクを示します。
タスク・フローはマネージドBeanを起動します。タスク・フローで使用するマネージドBeanの定義、サポートしているメモリー・スコープ、その他の関連する情報の詳細は、「タスク・フロー用のメモリー・スコープに関する必知事項」および「Fusion WebアプリケーションでのマネージドBeanの使用」を参照してください。
タスク・フローは再利用が可能です。アプリケーションの機能の再利用の詳細は、「アプリケーション・コンポーネントの再利用」を参照してください。
タスク・フローのセキュリティは、利用するユーザーに必要な権限を定義することによって確保できます。詳細は、「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
カスタム・コードを記述することでタスク・フローで実行される機能を拡張できます。たとえば、タスク・フロー・アクティビティでの例外発生時にタスク・フローが制御を渡すカスタム例外ハンドラを記述できます。詳細は、「例外ハンドラとしてカスタム・コードを指定する方法」を参照してください。
次の例のように、内部としてマークされていないパッケージをインポートしないようにカスタム・コードを記述していることを確認します。
import oracle.adfinternal.controller.*;
カスタム・コードの記述に使用できるAPIの詳細は、次のドキュメントを参照してください。
Oracle ADF ControllerのJava APIリファレンス
Oracle ADF FacesのJava APIリファレンス
ADFタスク・フローを作成するには、アクティビティ・ノードおよびそれらの間の制御フロー・ルールを識別する必要があります。また、複数のタスク・フローを結合することでタスク・フローを作成することもできます。タスク・フローでの分岐にはルーター・アクティビティを使用でき、リターン・アクティビティを使用してタスク・フローを終了できます。
タスク・フローはタスク・フロー自体と、複数のアクティビティ、そしてそれらのアクティビティ間の制御フロー・ルールで構成されています。ほとんどの場合は、アクティビティの多くがフロー内の異なるページを示すビュー・アクティビティです。たとえば、ページのレンダリング前などに一部のメソッドや操作をコールする必要がある場合は、メソッド・コール・アクティビティをそのアクティビティから次の適切なアクティビティまでの制御フロー・ケースとともに使用します。別なタスク・フローをコールする場合は、タスク・フロー・コール・アクティビティを使用します。フローになんらかのブランチ化が必要な場合は、ルーター・アクティビティを使用します。バインド・タスク・フローの最後で、リターン・アクティビティを使用してフローを終了し、そのバインド・タスク・フローをコールしたフローに制御を戻します。
各アクティビティ用のメタデータと設定可能な追加構成を含む、タスク・フローの各アクティビティの詳細および手順は、「タスク・フローへのアクティビティの追加」を参照してください。
バインド・タスク・フローとバインドなしタスク・フローを作成するプロセスは類似しています。主な相違は、「タスク・フローの作成」ダイアログの「バインド・タスク・フローとして作成」チェック・ボックスを選択してバインド・タスク・フローを作成する点です。
注意:
プロジェクトの作成時は、バインドなしタスク・フローを必ずしも作成する必要はありません。「プロジェクト・プロパティ」ダイアログの「機能」ページで、「ADFページ・フロー」を指定している場合は、プロジェクト内で新しいadfc-config.xml
ファイルが自動的に作成されます。adfc-config.xml
ソース・ファイルは、バインドなしタスク・フローの主要なファイルです。
始める前に:
タスク・フローの構成内容を理解しておくと役に立つ場合があります。詳細は、「タスク・フローの作成」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
タスク・フローを作成する手順は次のとおりです。
「アプリケーション」ウィンドウで、タスク・フローを作成するプロジェクトを右クリックし、「新規」→「ADFタスク・フロー」の順に選択します。
「タスク・フローの作成」ダイアログでは、デフォルトで「バインド・タスク・フローとして作成」チェック・ボックスが選択されています。アプリケーションのバインドなしタスク・フローに組み込まれるソース・ファイルを作成するには、チェック・ボックスの選択を解除します。
チェック・ボックスの選択を解除すると、「ファイル名」フィールドのデフォルト値が自動的に変更されます。この値は、作成するタスク・フローのXMLソース・ファイルに名前を付けるために使用されます。XMLソース・ファイルには、タスク・フローのアクティビティおよび制御フロー・ルールを記述するメタデータが含まれます。
ヒント:
バインドなしタスク・フローのデフォルト名は、adfc-config.xml
です。バインド・タスク・フローのデフォルトのソース・ファイル名は、「タスク・フローID」フィールドに指定された値と一致します。
1つのプロジェクトには複数のタスク・フローを含めることができるので、ソース・ファイルに一意の名前を付けるために、「ファイル名」フィールドのデフォルト値に数字が追加されます(task-flow-definition3.xml
など)。
「タスク・フローの作成」ダイアログでは、「ページ・フラグメントを使用して作成」チェック・ボックスがデフォルトで選択されます。
タスク・フローに追加するビュー・アクティビティが必要な場合はこのチェック・ボックスを選択解除して、メインのブラウザ・ウィンドウにレンダリングするJSFページをルート・ページとして参照します。タスク・フローに追加するビュー・アクティビティが必要な場合は、「ページ・フラグメントを使用して作成」チェック・ボックスを選択したままにして、実行時にADFリージョンでタスク・フローが表示するページ・フラグメント・ファイル(.jsff
)を参照します。このような区別はビュー・アクティビティから起動するダイアログには適用されず、「ページ・フラグメントを使用して作成」を選択した場合、ビュー・アクティビティを定義して、JSFページまたはページ・フラグメント・ファイルのどちらも参照できます。
「OK」をクリックします。
タスク・フローを表すダイアグラムがエディタに表示されます。
ヒント:
タスク・フロー・ダイアグラム全体のサムネイルは、ダイアグラムをクリックし、メイン・メニューで「ウィンドウ」→「サムネイル」を選択すると表示できます。
タスク・フローの作成後、ダイアグラム、概要およびソース・エディタを使用して更新できます。タスク・フローの更新には、「構造」ウィンドウも使用できます。
ヒント:
タスク・フローの作成には、既存のタスク・フローの内容を新規のタスク・フローにリファクタするなど、別の方法もあります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「アクティビティ」グループから、アクティビティをドラッグして、ダイアグラムへドロップします。
通常は、ビュー・アクティビティから開始します。すべての種類のアクティビティを追加する手順の詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。
ダイアグラム上にビュー・アクティビティをドラッグする場合は、そのアクティビティをダブルクリックすると、タスク・フローで起動するように構成されているJSFページまたはページ・フラグメントのウィザードを表示できます。このウィザードを使用してページまたはページ・フラグメントの特性を定義します。詳細は、「ビュー・アクティビティの使用方法」を参照してください。
注意:
「アプリケーション」ウィンドウからタスク・フローのダイアグラム上にページをドラッグ・アンド・ドロップして、タスク・フローにビュー・アクティビティを追加することもできます。
ルーター・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して式を作成し、その式の評価によりどの制御フロー・ルールに従うかを決定できます。詳細は、「ルーター・アクティビティの使用方法」を参照してください。
コール・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して、コールするメソッドを構成できます。詳細は、「メソッド・コール・アクティビティの使用」を参照してください。
ダイアグラム上にタスク・フロー・アクティビティをドラッグすると、アクティビティをダブルクリックして、新しいバインド・タスク・フローの設定を定義できる「バインド・タスク・フローの作成」ウィザードを表示できます。詳細は、「タスク・フロー・コール・アクティビティの使用」を参照してください。
バインド・タスク・フローを作成しており、タスク・フロー・リターン・アクティビティをダイアグラム上にドラッグすると、「プロパティ」ウィンドウを使用して、アクティビティを構成できます。詳細は、「タスク・フロー・リターン・アクティビティの使用」を参照してください。
アクティビティ間の制御フロー・ケースを作成します(詳細および詳細な手順は、「タスク・フローに制御フロー・ルールを追加する方法」を参照)。
「コンポーネント」ウィンドウの「ADFタスク・フロー」ページで、「コンポーネント」パネルの「制御フロー」グループから、「制御フロー・ケース」を選択します。
ダイアグラムで、ビューなどのソース・アクティビティをクリックし、次にターゲット・アクティビティをクリックします。たとえば図23-14では、制御フローに2つのアクティビティがリンクされています。ソースとターゲットの両方(view1
およびview2
)のアクティビティがリンクされています。
「プロパティ」ウィンドウで、「一般」セクションを開き、「アクション(自)」属性(結果がメソッドによって決定する場合)または「結果(自)」属性(結果をString
として設定可能な場合)を使用して結果値を選択します。
バインド・タスク・フローを作成する場合、いずれかのアクティビティをデフォルトに指定できます。それにより、バインド・タスク・フローの実行中は常にこの特定のアクティビティを最初に実行できます。デフォルトでは、JDeveloperはタスク・フローに追加した最初のアクティビティをデフォルトにします。別なアクティビティに変更する場合は、ダイアグラム内で該当するアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択します。詳細は、「バインド・タスク・フローのデフォルト・アクティビティに関する必知事項」を参照してください。
新規のバインドなしタスク・フローまたはバインド・タスク・フローを作成するたびに、新しいXMLソース・ファイルが作成されます。デフォルトでは、バインドなしタスク・フローのXMLソース・ファイルはadfc-config.xml
と呼ばれます。
次の例に示すように、すべてのADFコントローラXMLソース・ファイルでは、最上位の要素として<adfc-config>
が最初に出現します。バインド・タスク・フロー、アクティビティおよび制御フロー・ルールは、<adfc-config>
要素の内部に定義されます。バインド・タスク・フローは、ソース・ファイル内で<task-flow-definition>
メタデータ要素によって識別されます。
<?xml version="1.0" encoding="windows-1252" ?> <adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1"> <task-flow-definition id="task-flow-definition"> <use-page-fragments/> </task-flow-definition> </adfc-config>
バインド・タスク・フローは、識別子とドキュメント名の一意な組合せで構成されたタスク・フロー参照によって識別されます。例23-1は、タスク・フロー・コール・アクティビティ内のタスク・フロー参照の例を示しています。
注意:
JDeveloperを使用してバインド・タスク・フローを作成する場合は、各ドキュメントに1つのID (1つのバインド・タスク・フローを示す)のみを指定します。
バインド・タスク・フローを作成する場合は、識別子とドキュメント名の両方を割り当てます。例23-1に示すように、識別子は、「タスク・フローID」フィールドの値です。ドキュメント名は、「ファイル名」フィールドの値です。
例23-1 タスク・フロー参照
<adfc-config xmlns="http://xmlns.oracle.com/adf/Controller" version="1.2"> <task-flow-definition id="task-flow-definition"> <use-page-fragments/> ... <task-flow-call id="taskFlowCall"> <task-flow-reference> <document>/WEB-INF/target-task-flow-definition.xml</document> <id>my-task-flow</id> </task-flow-reference> </task-flow-call> ... </task-flow-definition> </adfc-config>
デフォルト・アクティビティは、バインド・タスク・フローで実行される最初のアクティビティです。たとえば、タスク・フロー・コール・アクティビティからバインド・タスク・フローに制御が渡される場合は、デフォルト・アクティビティは常に最初に実行されます。
バインドなしタスク・フローにはデフォルト・アクティビティはありません。
図23-9に示すように、緑の円はタスク・フロー・ダイアグラムのデフォルト・アクティビティを示します。
図23-9 バインド・タスク・フローのデフォルト・アクティビティ
新しいバインド・タスク・フロー・ダイアグラムに最初に追加するアクティビティはデフォルト・アクティビティとして自動的に識別されます。タスク・フロー・ダイアグラム内の任意のアクティビティを右クリックし、「アクティビティのマーク」→「デフォルト・アクティビティ」の順に選択することもできます。このデフォルトはすべてのアクティビティ・タイプで指定可能で、バインド・タスク・フローの制御フロー内でどの位置にも配置できます。デフォルト・アクティビティを検索するには、タスク・フロー・ダイアグラム上の任意の場所で右クリックし、「デフォルト・アクティビティに移動」を選択します。
バインド・タスク・フローで使用できるデフォルト・アクティビティは1つのみです。デフォルトとして2つ目のアクティビティをマークすると、最初のマークが自動的に解除されます。アクティビティのマークを手動で解除するには、タスク・フロー上の任意のアクティビティを右クリックし、「アクティビティのマーク解除」→「デフォルト・アクティビティ」を選択します。
トレインの途中で、デフォルト・アクティビティとしてトレイン・ストップを指定しないでください。詳細は、「バインド・タスク・フローでのトレイン・コンポーネントの使用」を参照してください。
例23-2に、バインド・タスク・フローのSurveyPrompt
というデフォルト・アクティビティのメタデータの例を示します。
例23-2 バインド・タスク・フローのデフォルト・アクティビティ・メタデータ
<task-flow-definition id="survey"> <default-activity>SurveryPrompt</default-activity> <view id="SurveryPrompt"> <page>/SurveryPrompt.jsff</page> </view> <use-page-fragments/> </task-flow-definition>
Fusion Webアプリケーション内の各タスク・フローでは、状態を管理するためにpageFlowスコープを定義しています。pageFlowスコープはタスク・フローの開始時に始まり、タスク・フローの終了時に終わります。pageFlowスコープで定義する一意の記憶域は、タスク・フローのアクティビティ間でのデータの受渡しに使用するアプリケーション内でタスク・フローのインスタンスごとに定義されます。あるタスク・フローが別なタスク・フローをコールする際、呼出し側のタスク・フローは呼出される側のpageFlowスコープにアクセスします。したがって、たとえば、タスク・フローのビュー・アクティビティが参照するページ上のUIコンポーネントでは、たとえこのタスク・フローがUIコンポーネントと同じページに組み込まれたADFリージョンであっても、別のタスク・フローのpageFlowスコープにアクセスできません。
タスク・フローで複数のマネージドBeanを定義できます。図23-10は、バインド・タスク・フロー(customers-task-flow-definition.xml
)が、スコープがbackingBeanであるマネージドBeanを参照する、Summit ADFタスク・フロー・サンプル・アプリケーションの例です。マネージドBeanに割り当てられたスコープを特定できます。
表23-4は、マネージドBeanに使用可能なスコープを示しています。また、タスク・フローで定義したマネージドBeanの各スコープの使用に適したタイミングも説明しています。この表はスコープを存続期間順に示しています。たとえば、アプリケーション・スコープは、リクエスト・スコープよりも存続期間が長くなっています。オブジェクト・スコープの存続期間の詳細は、「オブジェクト・スコープ・ライフサイクルについて」を参照してください。
表23-4 ADFマネージドBeanのメモリー・スコープ
スコープ | 説明 |
---|---|
application |
アプリケーション・スコープはアプリケーション終了時まで続行します。このスコープのマネージドBeanに保存する値は、そのアプリケーションを使用する各セッションと各リクエストで使用できます。 タスク・フローに使用すると、タスク・フローが終了しても存続してしまうので、避けてください。 |
session |
セッション・スコープはユーザーがアプリケーション内のページに最初にアクセスしたときに始まり、非アクティブ状態になった場合、またはアプリケーションによるセッション認証が失敗した場合に、ユーザー・セッションがタイムアウトしたときに終了します。 このスコープは、セッション全体に関連する情報(ユーザー情報やコンテキスト情報など)にのみ使用します。タスク・フロー間で値を渡すためにセッション・スコープを使用しないでください。タスク・フロー間での値のやり取りには、パラメータを使用します。パラメータを使用すると、タスク・フローは、コール元あるいはコール先となる他のタスク・フローと明確に結ばれます。セッション・スコープの使用を避けるもう1つの理由は、タスク・フローが終了しても存続する可能性がある点です。最後に、同じセッション内でエンド・ユーザーが複数のブラウザ・ウィンドウを開いた場合は、ブラウザ・ウィンドウ間でセッション・スコープの値が共有されます。これらのブラウザ・ウィンドウ間では競合が発生する可能性もあります。 |
pageFlow |
タスク・フロー内のアクティビティ全体でマネージドBeanにアクセスできるようにしたい場合は、このスコープを選択します。pageFlowがあるマネージドBeanは、それにアクセスするタスク・フローのページと同じ状態にあります。pageFlowがあるマネージドBeanは、タスク・フローの存続期間中に存在します。 |
view |
このスコープは、現在のビュー・アクティビティ内でのみ必要とされ、ビュー・アクティビティ間をまたがっていないマネージドBeanオブジェクトに使用します。 このスコープの存続期間は、ビュー・ポートの現在の JSFとOracle ADFにはこのスコープが実装されています。Fusion Webアプリケーションでは、1つのEL式にビュー・スコープを使用すると、Oracle ADF実装に解決されます。 |
request |
リクエスト・スコープは、現在のリクエストより長期間、マネージドBeanが存続する必要がない場合に使用します。 |
backingBean |
バッキングBeanは、JSFページ上のUIコンポーネントのアクセッサとイベント処理コードを保存するマネージドBeanの記述規則です。リクエストが終了するまで存続するもので、状態の維持には使用しないでください。 タスク・フローが同じJSFページの複数のADFリージョンに表示される可能性がある場合に、ADFリージョンの各インスタンスを分離するために使用します。 複数のタスク・フローの存在するシナリオでは、各マネージドBeanに一意の名前を割り当てる命名規則を使用することを検討してください。このアプローチを使用すると、異なるタスク・フローから同じ名前を持つ2つのマネージドBeanをbackingBeanスコープに入れてしまうことを防げます。 |
タスク・フローでマネージドBeanを定義すると、JDeveloperではタスク・フローのソース・ファイル内にある次のようなエントリが生成されます。
<managed-bean id="__15">
<managed-bean-name id="__16">egBackingBean</managed-bean-name>
<managed-bean-class id="__13">oracle....egBackingBean</managed-bean-class>
<managed-bean-scope id="__14">backingBean</managed-bean-scope>
</managed-bean>
<managed-bean-scope>
要素には、マネージドBeanのスコープの値(例ではbackingBean
)が含まれています。
UIコンポーネントをマネージドBeanにバインドすると、JDeveloperはマネージドBeanの参照用に生成するEL式のスコープ名にScope
を付加します。たとえば、マネージドBeanを参照する表コンポーネントのバインド属性には次のEL式があります。
<af:table id="cartTab"
...
binding="#{backingBeanScope.egBackingBean.table}"
...
</af:table>
UIコンポーネントのバインド属性で参照するマネージドBeanのスコープを、backingBeanまたはリクエスト・スコープに限定します。UIコンポーネントのインスタンスはシリアライズできません。backingBeanとリクエスト以外のスコープのオブジェクトは、シリアライズ可能と考えられています。そのため、backingBeanまたはリクエスト以外のスコープのマネージドBeanに、UIコンポーネントをバインドしてはなりません。JDeveloperでは、UIコンポーネントのバインディング属性およびリージョン・フラグメントが、backingBeanスコープを使用するようにデフォルト設定されています。
注意:
Oracle ADF固有のカスタム・スコープ(pageFlow、backingBean、ビュー・スコープなど)にアクセスするEL式を記述する場合、アクセスするスコープを明示的に指定するEL式を記述します。たとえばpageFlowスコープにアクセスするEL式は次のように記述します。
#{pageFlowScope.inpTxtBB.uiComponent}
単一のアプリケーションで、複数のバインドなしタスク・フローXMLソース・ファイルと複数のバインド・タスク・フローXMLソース・ファイルを持つことができます。バインドなしタスク・フローの生成のために組み合せたファイル・セットは、アプリケーションのADFコントローラ・ブートストラップ構成ファイルと呼ばれています。バインドなしタスク・フローは、1つ以上のADFコントローラ・ブートストラップ構成ファイルを組み合せて、実行時にアセンブルされます。バインド・タスク・フロー内に含まれないブートストラップ構成ファイルのすべてのアクティビティは、バインドなしタスク・フロー内にあるとみなされます。
1つのアプリケーション内のソース・ファイル名は、異なる名前である必要があります。図23-11の例には、2つのバインドなしタスク・フロー(adfc-config
、adfc-config1
)と、1つのバインド・タスク・フロー(task-flow-definition
)があります。
ADFアプリケーションで作成したADFタスク・フローは変更できます。「コンポーネント」パネルのアクティビティ・グループからドラッグし、ダイアログにドロップすることで、アクティビティを追加できます。
タスク・フローの作成後、タスク・フローにアクティビティを追加し、アクティビティ間の制御フローを構成します。「コンポーネント」ウィンドウに、使用可能なアクティビティおよび制御フローが表示されます。「コンポーネント」ウィンドウからタスク・フロー・ダイアグラムに、アクティビティおよび制御フローをドラッグ・アンド・ドロップします。次にアクティビティ間の制御フローを構成し、タスク・フローが必要なタスクを実行できるようにします。
タスク・フローを作成すると、タスク・フロー・ダイアグラムと「コンポーネント」が自動的に表示されます。タスク・フロー・ダイアグラムはビジュアル・エディタであり、そこでタスク・フローのアクティビティおよび制御フローを追加できます。「コンポーネント」からそれらをドラッグして、ダイアグラムに追加できます。
始める前に:
タスク・フローに追加可能なアクティビティを理解しておくと役に立つ場合があります。詳細は、「タスク・フローへのアクティビティの追加」を参照してください。
また、他のOracle ADF機能を使用してタスク・フローに追加可能な機能について理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
タスク・フローにアクティビティを追加するには:
ヒント:
タスク・フロー・ダイアグラムに各アクティビティをドラッグすると、アクティビティに関する追加情報を提供するオプションのステータス・アイコンとツールチップを表示できます。たとえば、タスク・フロー・ダイアグラムにビュー・アクティビティをドラッグすると、それをJSFページに関連付けるまで警告アイコンが表示されることがあります。
アイコンをオンにするには、タスク・フロー・ダイアグラムの上部にある「表示」を選択し、続いて「ステータス」と次のいずれかを選択します。
エラー: タスク・フロー・メタデータの実行を妨げる問題がある場合に表示されます。たとえば、メタデータ内のビュー・アクティビティには<bookmark>
または<redirect>
要素を組み込めますが、両方を組み込むことはできません。
警告: タスク・フローの実行を妨げない問題がタスク・フロー・メタデータにある場合に表示されます。
不完全: アクティビティが不完全な場合に表示されます。たとえば、物理ページの関連付けが行われていないビュー・アクティビティ、またはタスク・フロー参照の関連付けがないタスク・フロー・コールは、ともに不完全なアクティビティとみなされます。その結果発生するタスク・フロー・メタデータは、実行が妨げられることがあります。
2次アイコンの上にマウスをドラッグすると、アイコンの意味を説明するツールチップを表示できます。
ADF制御フロー・ルールでは、タスク・フローで、あるアクティビティから次のアクティビティに渡される制御のパスが定義されます。条件付きナビゲーション、値に基づくナビゲーションを定義したり、複数の制御フローをマージして単一の制御フローを生成することもできます。
ADFコントローラ制御フロー・ルールでは、タスク・フローで、あるアクティビティから次のアクティビティに制御を渡す方法が定義されています。制御フロー・ルールには、1つまたは複数の制御フロー・ケースを含めることができます。制御フロー・ケースでは、制御フローを渡すアクティビティが特定されます。また、制御ケースでは、オプションで、条件付きナビゲーション(<if>
要素を使用)、または制御フローの発生元から取得したアクション値に基づく制限ナビゲーション(from-action
要素を使用)を構成できます。
ADF Controller制御フロー・ルールは、JSFナビゲーション・ルールに基づきますが、その他の情報を取得します。JSFナビゲーションは常にページ間のものですが、制御フロー・ルールはアクティビティ間の遷移を示します。たとえば、制御フロー・ルールは、ビュー・アクティビティとそれ以降のメソッド・コール・アクティビティ間の遷移を示します。または、そのページ(ビュー・アクティビティ)から別のタスク・フローに制御を渡すように指定できます。
次のタスク・フロー・アクティビティは、制御フロー・ルールのソースになることはありません。
セーブポイント・リストア
タスク・フロー・リターン
URLビュー
制御フロー・ルールの基本構造は、JSFナビゲーション・ルールを模倣したものです。表23-5には、JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのメタデータのマップ方法が示されています。
表23-5 JSFナビゲーション・ルールからADFコントローラ制御フロー・ルールへのマッピング
JSFナビゲーション・ルール | ADFコントローラ制御フロー・ルール |
---|---|
ナビゲーション・ルール |
制御フロー・ルール |
ビューID(自) |
アクティビティID(自) |
ナビゲーション・ケース |
制御フロー・ケース |
アクション(自) |
アクション(自) |
結果(自) |
結果(自) |
条件 |
条件 |
ビューID(至) |
アクティビティID(至) |
ADFタスク・フローの使用時、faces-config.xml
ファイルのJSFナビゲーション・ルールを使用するかわりに、ADFコントローラ制御フロー・ルールを使用してすべてのアプリケーション・ナビゲーションを実行します。ADFコントローラは、メタデータ内に一致する制御フロー・ケースが見つからない場合はナビゲーション処理を委譲します。ただし、ADF以外のコントローラのナビゲーション・ハンドラによってナビゲーションが実行された場合は、すべてのADFコントローラ機能の正常動作が保証されるとは限りません。ADFコントローラによる制御フロー・ルールの評価方法の詳細は、「実行時に行われる処理: タスク・フローで制御フロー・ルールを評価する方法」を参照してください。
アクティビティ間の基本的な制御フロー作成の開始ポイントとして、タスク・フロー・ダイアグラムを使用します。その後、タスク・フロー・ダイアグラムの「構造」ウィンドウ、「プロパティ」ウィンドウまたは概要エディタで制御フロー・プロパティを編集できます。
ヒント:
アクティビティを既存の制御フローにドラッグ・アンド・ドロップできます。これによって既存の制御フローが、アクティビティを中心として2つに分割されます。
制御フロー・ルールを作成するには、「コンポーネント」ウィンドウの「ADFタスク・フロー」ページから「制御フロー・ケース」をソース・タスク・フロー・アクティビティおよびターゲット・タスク・フロー・アクティビティにドラッグ・アンド・ドロップします。
始める前に:
タスク・フロー・ルールの内容を理解しておくと有効な場合があります。詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
制御フロー・ルールをタスク・フローに追加するには:
バインドなしまたはバインド・タスク・フローにワイルドカード制御フロー・ルールを追加できます。追加の手順は、タスク・フロー・ダイアグラムへのアクティビティの追加の手順とほぼ同じです。
始める前に:
使用可能な制御フロー・ルールのオプションを理解しておくと有効な場合があります。詳細は、「タスク・フローへの制御フロー・ルールの追加」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
ワイルドカード制御フロー・ルールを追加するには:
タスク・フローのソース・ファイルのルールを定義する要素を理解すると、タスク・フロー・ダイアグラム、タスク・フローの概要エディタまたは「構造」ウィンドウで制御フロー・ルールを直接作成する際、あるいは制御フロー・ルールをXMLソース・ファイルに直接追加する際に役に立ちます。例23-3に、タスク・フロー・ソース・ファイルの制御フロー・ルール要素の一般的な構文を示します。
制御フロー・ルールは、次のメタデータで構成されます。
control-flow-rule
: 制御フロー・ケース要素の必須ラッパー要素。
from-activity-id
: 制御フロー・ルールの発生元となるアクティビティの識別子(source
など)。
from-activity-id
の後方ワイルドカード(*)文字がサポートされています。ルールは、ワイルドカードのパターンに一致するすべてのアクティビティに適用されます。たとえば、login*
は、リテラルlogin
で始まるすべての論理アクティビティID名と一致します。メタデータに(後方ワイルドカードではなく)単一のワイルドカード文字を指定すると、ダイアグラムで、制御フローが自動的にワイルドカード制御フロー・ルール・アクティビティに変換されます。詳細は、「ワイルドカード制御フロー・ルールの追加方法」を参照してください。
control-flow-case
: 制御フロー・ルールの各ケースの必須ラッパー要素。それぞれのケースで、同じソース・アクティビティに対して異なる制御フローを定義します。制御フロー・ルールには、少なくとも1つの制御フロー・ケースが必要です。
from-action
: 指定されたアクション・メソッドからの結果のみにルールの適用を制限する任意の要素。アクション・メソッドは、ELバインディング式(#{backing_bean.cancelButton_action}
など)として指定されます。
例23-3では、outcome
がactionmethod
から返された場合にのみ制御がdestinationActivity
に渡されます。
from-action
の値は、ビュー・アクティビティから発生する制御フローのみに適用され、その他のアクティビティ・タイプからのものには適用されません。from-actionでは、ワイルドカードはサポートされていません。
from-outcome
: 特定の元のアクティビティ結果に基づき、続いて起こる制御フロー・ケースを識別する要素。考えられるすべての元のアクティビティの結果は、制御フロー・ケースと適合する必要があります。
from-action
要素とfrom-outcome
要素の両方を空のままにすると、ケースはアクティビティに対して定義されたその他の制御フロー・ケースでは識別されないすべての結果に適用されるため、アクティビティのデフォルト・ケースが作成されます。from-outcome
では、ワイルドカードはサポートされていません。
to-activity-id
: 制御フロー・ケースが実行される場合にナビゲーションのルーティング先となるアクティビティの完全な識別子が含まれる必須要素。各制御フロー・ケースは、異なるto-activity-id
を指定できます。
if
: EL式の値を受け取るオプション要素です。実行時にEL式の値がtrue
の場合は、to-activity-id
要素によって識別されたアクティビティに制御フローを渡します。
例23-3 ソース・ファイルの制御フロー・ルールの構文
<control-flow-rule> <from-activity-id>from-view-activity</from-activity-id> <control-flow-case> <from-action>actionmethod</from-action> <from-outcome>outcome</from-outcome> <to-activity-id>destinationActivity</to-activity-id> <if>#{myBean.someCondition}</if> </control-flow-case> <control-flow-case> .... </control_flow-case> </control-flow-rule>
実行時、タスク・フローは、最も具体的な一致から最も具体的でない一致まで制御フロー・ルールを評価して、アクティビティ間の次の遷移を決定します。評価は次の優先度に基づきますが、これはJSFナビゲーション・ルールと類似しています。
from-activity-id
、from-action
、from-outcome
from-activity-id
、from-outcome
from-activity-id
ADFコントローラは、最初にfrom-activity-id
、from-action
、from-outcome
の3つの要素すべての一致を検索します。一致がない場合は、from-activity-id
およびfrom-outcome
要素のみの一致を検索します。最後に、from-activity-id
要素のみの一致を検索します。
ADFコントローラのメタデータ内でリクエストと一致する制御フロー・ルールを検出できない場合は、標準JSFナビゲーション・ハンドラによる一致の検出が許可されます。
バインドなしタスク・フローには、複数のADFコントローラXMLソース・ファイルを含めることができます。複数のADFコントローラXMLソース・ファイルに制御フロー・ルールを定義できるため、似たようなルールが異なるファイルに定義される場合もあります。2つ以上のケースに同じfrom-activity-id
、from-action
またはfrom-outcome
の値が存在するといった競合がある場合は、(adfc-config.xml
、ブートストラップまたはバインド・タスク・フローのソース・ファイルで記述される順序で)最後のケースが使用されます。異なるソース・ファイルに定義されたルール間で競合がある場合は、最後にロードされるソース・ファイルのルールが使用されます。
また、ADFコントローラには、次の複数の制限を使用して次のインタフェースを実装します。
javax.faces.application.ConfigurableNavigationHandler
制限は次のとおりです。
getNavigationCases()
によって返されたMap
オブジェクトは変更できません。制御フロー・ルールを実行時に変更するには、必ずMDSフレームワークを実装したカスタマイズ機能で実行される必要があります。詳細は、「MDSによるアプリケーションのカスタマイズ」を参照してください。
JSFアプリケーション起動フェーズ後は、performNavigation()
メソッドを起動してはいけません。これは、ADFレンダリング準備フェーズとJSFレスポンス・レンダリング・フェーズとの間でビューIDが変更されていないことを確認するためです。ページ・リクエストのライフサイクルでのJSFフェーズとADFフェーズの統合方法の詳細は、「Fusionページ・ライフサイクルの理解」を参照してください。
タスク・フロー・ビュー・アクティビティのブックマークおよびリダイレクトのプロパティに対するメタデータの値には、getNavigationCases()
によって返されるナビゲーション・ケース・オブジェクトに対応する情報が移入されます。
他のアプリケーションでの場合と同様に、ADFタスク・フローをテストして問題やテスト・ケースをデバッグし、問題を解決したりパフォーマンスを向上させることができます。タスク・フローをテストしてからWebLogic Serverまたはテスト・フローにデプロイすることも、WebLogic Serverでの実行中に実行を中断することなくタスク・フローをテストすることもできます。実行およびデバッグ・プロセスは、タスク・フローのタイプが異なると異なります。
タスク・フローを実行してデバッグするプロシージャは、タスク・フローがバインドかバインドなしか、ページまたはページ・フラグメントのどちらを含んでいるか、入力パラメータを受け入れるかどうかに応じて異なります。
JDeveloperおよびOracle ADFには、作成したタスク・フローのテストに役立つ多くの機能があります。その1つとして、タスク・フロー・アクティビティにADF宣言ブレークポイントを設定する機能があります。「タスク・フロー・アクティビティ・ブレークポイントの設定方法および使用方法」を参照してください。また、統合WebLogic Serverで現在実行されているアプリケーションのタスク・フローのメタデータを変更することもできます。タスク・フローに対する変更をアプリケーションにデプロイする作業は、アプリケーションを停止し、統合WebLogic Serverに再デプロイしなくても実行できます(ホット・リロードとも呼ばれます)。これを行うには、変更されたタスク・フロー上で作成用のコマンドを起動します(タスク・フローを右クリックし、「メイク」を選択します)。これにより、変更されたタスク・フローが統合WebLogic Serverで実行中のアプリケーションにデプロイされます。ホット・リロードの詳細は、「統合WebLogic ServerのOracle ADFのメタデータのリロード」を参照してください。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
ページであるビュー・アクティビティを含むバインド・タスク・フローを実行またはデバッグできます。
ページ・フラグメントであるビュー・アクティビティを含むバインド・タスク・フローの実行方法の詳細は、「ページ・フラグメントを使用するバインド・タスク・フローの実行方法」を参照してください。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
ページを使用するバインド・タスク・フローを実行またはデバッグするには:
タスク・フロー・ダイアグラムで、タスク・フローを右クリックし、「実行」または「デバッグ」を選択します。
ブラウザにURLを入力してタスク・フローを直接実行することもできます。次に例を示します。
http://somecompany.com/internalApp/MyApp/faces/adf.task-flow?adf.tfId=displayHelp&adf.tfDoc=%2FWEB-INF%2Fdisplayhelp.xml&topic=createPurchaseOrder
詳細は、「URLを使用したバインド・タスク・フローのコールに関する必知事項」を参照してください。
「アプリケーション」ウィンドウで、WEB-INFノードを開き、バインド・タスク・フローを右クリックして、「実行」または「デバッグ」を選択します。
ページ・フラグメントを使用するバインド・タスク・フローは、ADFリージョン内でのみ実行することを目的としています。ページ・フラグメントは、別のJSFページのコンテンツとしてレンダリングされるJSFドキュメントです。詳細は、「ページ・フラグメントおよびADFリージョンについて」を参照してください。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
次のタスクを完了する必要があります。
ページ・フラグメントを使用するバインド・タスク・フローを実行またはデバッグするには:
「アプリケーション」ウィンドウまたはタスク・フロー・ダイアグラムでビュー・アクティビティを右クリックし、「実行」を選択します。
パラメータのあるバインド・タスク・フローを実行する前に、ページを含むバインド・タスク・フローを実行する必要があります。詳細は、「ページ・フラグメントを使用するバインド・タスク・フローの実行方法」を参照してください。
入力パラメータが定義されたバインド・タスク・フローを実行またはデバッグしようとすると、図23-16に示すように、「実行構成の設定」ダイアログが表示されます。このダイアログで、バインド・タスク・フローに渡す値を入力し、「OK」をクリックします。バインド・タスク・フローに入力パラメータを定義する方法の詳細は、「タスク・フローのパラメータの使用」を参照してください。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
入力パラメータ定義を含むバインド・タスク・フローを実行またはデバッグするには:
JSFページは、「アプリケーション」ウィンドウでページを右クリックし、「実行」を選択して実行できます。ただし、ボタンやリンクなどのナビゲーションUIコンポーネントがページに含まれている場合は、ナビゲーションが機能する保証はありません。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
次のタスクを完了する必要があります。
バインド・タスク・フローまたはバインドなしタスク・フローを作成します。
詳細は、「タスク・フローの作成方法」を参照してください。
タスク・フローにビュー・アクティビティを追加します。
詳細は、「タスク・フローにアクティビティを追加する方法」を参照してください。
ナビゲーションを完全に機能させてJSFページを実行するには:
バインドなしタスク・フローを実行またはデバッグするには、バインドなしタスク・フローの起動に使用する特定のビュー・アクティビティを選択します。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
バインドなしタスク・フローでビュー・アクティビティを実行するには:
タスク・フロー・ダイアグラムで、ビュー・アクティビティを右クリックし、「実行」または「デバッグ」を選択します。
選択したビュー・アクティビティからバインドなしタスク・フローが実行されます。
単一のビュー・アクティビティ以外を選択している(あるいは何も選択していない)場合、「実行構成の設定」ダイアログで1つ選択するように求められます。
実行構成には、タスク・フローで実行する最初のアクティビティなど、プロジェクトの実行方法を決定する設定が含まれます。1つのプロジェクトに対して1つ以上の実行構成を定義できます。実行構成内では、デフォルトの実行ターゲットとしてADFコントローラのソース・ファイルを指定できます。プロジェクトを実行すると、ソース・ファイルが最初に実行されます。
始める前に:
タスク・フローのテスト方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「タスク・フローのテスト」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
デフォルトのタスク・フロー実行ターゲットを定義するには:
ADFタスク・フローにより、既存のアクティビティ、JSFページ・フローおよびJSFページを再利用することでタスク・フローおよびタスク・フロー・テンプレートを作成できます。タスク・フロー・ダイアグラムに抽出する新規のバインド・タスク・フローが表示されます。
既存のアクティビティ、JSFページ・フローおよびJSFページを、新規のADFコントローラ・コンポーネント(バインド・タスク・フローおよびタスク・フロー・テンプレートなど)に変換できます。
新規のバインド・タスク・フローは、既存のバインドまたはバインドなしタスク・フローで選択したアクティビティに基づいて作成できます。
始める前に:
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
既存のタスク・フローからバインド・タスク・フローを抽出するには:
タスク・フロー・ダイアグラムに抽出する新規のバインド・タスク・フローが表示されます。表23-6は、JDeveloperにより自動設定される、新規のバインド・タスク・フローのプロパティについて説明しています。
表23-6 新規バインド・タスク・フローで更新されるプロパティ
プロパティ | 値 |
---|---|
タスク・フロー定義ID |
「バインド・タスク・フローの抽出」ダイアログの「ファイル名」フィールドに入力した値です。 |
デフォルト・アクティビティ |
すべての受信制御フロー・ケースのターゲットとして指定。複数のターゲットが存在する場合、エラーのフラグが立てられ、操作全体がロールバックされます。 |
制御フロー・ルール |
選択されたソース・アクティビティのある制御フロー・ケースは、新規のバインド・タスクに組み込まれます。ソース・アクティビティは、制御フローの発生元のアクティビティです。新規のバインド・タスク・フローには、次のタイプの制御フロー・ケースがあります。
|
元のタスク・フロー(新規タスク・フローの基礎として選択したアクティビティを含むタスク・フロー)で次のような変更が自動的に実行されます。
新規タスク・フロー・コール・アクティビティが、元のタスク・フローに追加されます。タスク・フロー・コール・アクティビティは、新規のバインド・タスク・フローをコールします。
選択されたアクティビティが元のタスク・フローから削除されます。
選択したアクティビティに関連付けられた既存の制御フロー・ケースが、元のタスク・フローから削除されます。これは新規の制御フロー・ケースに置き換えられます。
古いアクティビティに対する受信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティにリダイレクトされます。
古いアクティビティからの送信制御フロー・ケースは、新規タスク・フロー・コール・アクティビティからリダイレクトされます。
JSFページ・フローで選択したページに基づいて、新規のバインド・タスク・フローを作成できます。JDeveloperでは、フローの一部であるJSFページ(つまり、JSFナビゲーション・ケースによってリンクされたページ)が新規タスク・フローのビュー・アクティビティに変換されます。
始める前に:
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
ページ・フローで選択したJSFページから新規のタスク・フローを作成するには:
既存のバインド・タスク・フローをバインドなしタスク・フローに変換したり、そこに含まれるビューがページまたはページ・フラグメントのいずれかを変更できます。表23-7に、それぞれの変換結果を示します。
表23-7 バインド・タスク・フローの変換
変換 | 結果 |
---|---|
バインド・タスク・フローからバインドなしタスク・フローへの変換 |
パラメータ定義やトランザクションなど、バインドなしタスク・フローに対して無効なすべてのメタデータが失われます。 |
JSFページを使用するためのバインド・タスク・フローの変換 |
タスク・フロー内の任意のビュー・アクティビティに関連付けられたページ・フラグメントをJSFページに変換します。「ページ・フラグメントを保持」チェックボックスを選択している場合、古いページ・フラグメントは保存されます。新規のJSFページ名は、デフォルトで古いページ・フラグメント名になります。 |
ページ・フラグメントを使用するためのバインド・タスク・フローの変換 |
バインド・タスク・フロー内のビュー・アクティビティに関連付けられたすべてのページをページ・フラグメントに変換します。「ページを保持」チェックボックスを選択している場合、古いページは保存されます。新規のページ・フラグメント名は、デフォルトで古いページ名になります。 |
始める前に:
タスク・フローのリファクタ方法に影響を与える要因を理解しておくと有効な場合があります。詳細は、「新規タスク・フローおよびタスク・フロー・テンプレート作成のためのリファクタ」を参照してください。
また、他のタスク・フローの機能を使用して追加可能な機能を理解しておくと有効な場合があります。詳細は、「ADFタスク・フローの追加機能」を参照してください。
バインド・タスク・フローを変換するには: