Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1(11.1.1.9.0) B52028-07 |
|
![]() 前 |
![]() 次 |
この章では、ADFタスク・フローのアクティビティの使用方法について説明します。この章では、コンポーネント・パレットおよびそのプロパティに表示される各タスク・フロー・アクティビティの詳細を説明します。
この章には次の項が含まれます:
アクティビティとは、タスク・フローの実行時に行われる作業を意味しています。タスク・フローの概要エディタにノードとして表示されます。ほとんどのアクティビティはバインド・タスク・フローとバインドなしタスク・フローの両方に追加できますが、アクティビティ・タイプによってはバインド・タスク・フローにのみ追加できるものもあります。
図15-1のバインド・タスク・フローには、アプリケーションをチェックアウトするために実行する次のアクティビティがあります。
ユーザーがログイン前に選択した可能性のあるアイテムを、ログイン後に選択したアイテムと同期化するメソッドのコール
ユーザーが現在選択しているアイテムを表示するページ(ビュー・アクティビティ)と注文をまとめた別のページ
コール元の無制限タスク・フロー(図15-1を参照)に制御を戻すアクティビティ
タスク・フローは、アクティビティ、およびアクティビティ間の遷移を定義する制御フロー・ケースで構成されます。表15-1に、タスク・フローに追加できるアクティビティのタイプと制御フローを示します。
表15-1 タスク・フロー・アクティビティと制御フロー
アイコン | コンポーネント名 | 説明 |
---|---|---|
![]() |
メソッド・コール |
メソッド(通常、マネージドBeanのメソッド)を起動します。メソッド・コール・アクティビティは、制御フロー・ルールに基づいてアプリケーション・ロジックを起動するために、アプリケーションの制御フロー内のどこにでも配置できます。詳細は、15.5項「メソッド・コール・アクティビティの使用」を参照してください。 |
|
親アクション |
バインド・タスク・フローで親ビュー・アクティビティに渡される結果を生成できるようにします。詳細は、15.9項「親アクション・アクティビティの使用」を参照してください。 |
![]() |
ルーター |
EL式を評価し、式の値に基づいて結果を戻します。たとえば、クレジット確認タスク・フローのルーターは、前のメソッド・コールの戻り値を評価し、様々なケースに基づいて成功、失敗または再試行の結果を生成します。その後、このような結果を使用して、タスク・フローの他のアクティビティに制御をルーティングします。詳細は、15.4項「ルーター・アクティビティの使用」を参照してください。 |
![]() |
セーブポイント・リストア |
後で使用するための保存の機能をサポートするアプリケーションで、アプリケーションの状態やデータなど、以前の永続保存ポイントをリストアします。詳細は、18.9項「タスク・フローのセーブポイントの使用」を参照してください。 |
![]() |
タスク・フロー・コール |
無制限タスク・フローまたは別のバインド・タスク・フローからバインド・タスク・フローをコールします。詳細は、15.6項「タスク・フロー・コール・アクティビティの使用」を参照してください。 |
|
タスク・フロー・リターン |
バインド・タスク・フローが完了し、コール元に制御が戻されるタイミングを指定します。(バインド・タスク・フローでのみ利用可能)。詳細は、15.7項「タスク・フロー・リターン・アクティビティの使用」を参照してください。 |
![]() |
URLビュー |
ADFリージョンのコンテキスト内からでも、ルート・ビュー・ポート(ブラウザ・ページなど)をURLにアドレス可能なリソースにリダイレクトします。詳細は、15.3項「URLビュー・アクティビティの使用」を参照してください。 |
![]() |
ビュー |
JSFページやページ・フラグメントを表示します。同じページやページ・フラグメントを、複数のビュー・アクティビティで表すことができます。詳細は、15.2項「ビュー・アクティビティの使用」を参照してください。ページおよびページ・フラグメントの詳細は、20.3項「Webページの作成」を参照してください。 |
|
制御フロー・ケース |
アプリケーション内で、あるアクティビティから次のアクティビティに制御を渡す方法を指定します。詳細は、14.1.3項「制御フロー」を参照してください。 |
|
ワイルドカード制御フロー・ルール |
IDがワイルドカード式と一致するアクティビティからの制御フロー・ケースを表します。たとえば、 |
表15-2に、タスク・フローに追加できる注釈(メモおよび添付ファイル)を示します。
タスク・フロー・アクティビティの第1のタイプはビューで、これはJSFページまたはページ・フラグメントを表示します。ページ・フラグメントとは、別のJSFページのコンテンツとしてレンダリングされるJSF JSPドキュメントです。ページ・フラグメントは通常、バインド・タスク・フローで使用されます。バインド・タスク・フローはリージョンとしてページに追加できます。詳細は、17.2項「ADFリージョンの作成」を参照してください。
図15-2に、Fusion Order Demoアプリケーション内のhome
ビュー・アクティビティを示します。
ヒント: ビュー・アクティビティの左上にある+アイコンをクリックして、参照したページまたはページ・フラグメントのサムネイル・プレビューを表示します。 |
ビュー・アクティビティは、メタデータで物理的なJSFページまたはページ・フラグメントに関連付けられます。ビュー・アクティビティはid
属性によって識別されます。ページまたはページ・フラグメント名は、タスク・フロー・メタデータ内の<page>
要素で識別されます。
<view id="home"> <page>/home.jspx</page> </view>
ビュー・アクティビティのIDとページ名は同じである必要はありません。
次に示すように、ページ・フラグメントのファイル拡張子は.jsff
です。
<view id="Home"> <page>WEB-INF/Home.jsff</page> </view>
ビュー・アクティビティ追加の手順は、タスク・フロー・ダイアグラムへのアクティビティの追加の手順とほぼ同じです。詳細は、14.3.1項「ADFタスク・フローへのアクティビティの追加方法」を参照してください。ビュー・アクティビティの追加後、アクティビティをダブルクリックして「JSF JSPページの作成」ウィザードを表示し、そこでページまたはページ・フラグメントを作成できます。また、このウィザードを使用してページまたはページ・フラグメントの特性を定義します。完成したページまたはページ・フラグメントは、自動的にビュー・アクティビティに関連付けられます。
既存のページまたはページ・フラグメントをアプリケーション・ナビゲータからドラッグして、ビュー・アクティビティの最上部にドロップすることもできます。
ページまたはページ・フラグメントをダイアグラムの他の場所にドラッグすると、そのページまたはページ・フラグメントに関連付けられた新しいビュー・アクティビティが自動的に作成されます。作成時には、ページまたはページ・フラグメントの名前に基づいて、そのビュー・アクティビティのデフォルトのid
が自動的に生成されます(例: Home
)。
遷移とは、あるビュー・アクティビティの制御が別なビュー・アクティビティに移ることを意味します。たとえば、ページ上のボタンやリンクなどのUIコンポーネントを選択することで、実行時に制御フローを起動できます。UIコンポーネントのAction属性は、対応する制御フロー・ケースfrom-outcome
に設定して、次のタスク・フロー・アクティビティに導く必要があります。UIコンポーネントのAction属性の定数値または動的値のいずれかを使用して、あるビュー・アクティビティから別なアクティビティに移動できます。
定数: コンポーネントのAction属性の値はアクション結果です(図15-3を参照)。アクション結果は、常に同じ制御フロー・ケースをトリガーする定数値です。エンド・ユーザーがコンポーネントをクリックすると、その制御フロー・ケースに指定されているアクティビティが実行されます。代替の制御フローはありません。
動的: コンポーネントのAction属性の値はマネージドBeanまたはメソッドにバインドされます。メソッド・バインディングの値により、実行される次の制御フロー・ケースが決定されます。
たとえば、メソッドはページのユーザー入力を検証し、入力が有効な場合はある値を、入力が無効な場合は別の値を戻します。これらの異なるアクション値はそれぞれ別個のナビゲーション・ケースをトリガーし、アプリケーションは2つのターゲット・ページのいずれかに移動します。
データ・コントロール操作にバインドされるコンポーネントの詳細は、28.2項「メソッドを実行するためのコマンド・コンポーネントの作成」を参照してください。
開始する前に、ターゲット・ビュー・アクティビティと、コンポーネントの追加先JSFページがすでに存在している必要があります。コンポーネントのアクションは、ターゲット・アクティビティにつながる制御フロー・ケースのfrom-outcome
に基づいています。
ビュー・アクティビティに遷移するには:
次のいずれかの方法で、UIコンポーネントをJSFページに追加します。
JSFページを開きます。コンポーネント・パレットの「ADF Faces共通コンポーネント」リストで、ボタンやリンクなどのナビゲーションUIコンポーネントをJSFページにドラッグします。
JSFページを開きます。「データ・コントロール」パネルから、操作またはメソッドをJSFページにドラッグ・アンド・ドロップし、ポップアップ・メニューから「リッチ・コマンド・ボタン」または「リッチ・コマンド・リンク」を選択します。
UIコンポーネントを選択して、「プロパティ・インスペクタ」を開きます。
「共通」ページでボタン・アクション・セクションを展開します。
「アクション」の隣のドロップダウン・メニューから、「編集」を選択します。
「アクション結果」を選択します。
「アクション結果」ドロップダウン・リストから値を選択します。
リストには、ページに関連付けられているビュー・アクティビティに定義済のfrom-outcome
制御フロー・ケースが含まれています。
ヒント: UIコンポーネントのaction 属性は、ナビゲーション・ケースをハードコードするリテラル文字列、または、引数なしでStringを戻すメソッドをポイントするメソッド・バインディング式のいずれかにバインドできます。その他のタイプのEL式にはバインドできません。 |
「OK」をクリックします。
例15-1は、バインド・タスク・フローまたはバインドなしタスク・フローのXMLソース・ファイルに定義された制御フロー・ケースの例です。
例15-1 XMLソース・ファイルで定義された制御フロー・ケース
<control-flow-rule> <from-activity-id>Start</from-activity-id> <control-flow-case> <from-outcome>toOffices</from-outcome> <to-activity-id>WesternOffices</to-activity-id> </control-flow-case> </control-flow-rule>
例15-2に示すように、Startビュー・アクティビティに関連付けられているJSFページ上のボタンで、action
属性としてtoOfficesが指定されます。ユーザーがボタンをクリックすると、制御フロー・メタデータでto-activity-id
として指定されたWesternOffices
アクティビティに制御フローが渡されます。
バインドなしタスク・フロー内のビュー・アクティビティにのみ、ブックマークを使用できます。
ビュー・アクティビティに関連付けられたページにエンド・ユーザーがブックマークを付けると、そのビューのブラウザのアドレス・フィールドに表示されているURLがブックマークとして保存されます。ほとんどの場合、このURLはビューに関連付けられているページの再表示に使用できません。たとえば、URLにはMicrosoftのWindows OSの状態情報が含まれることがあり、それを使用してページを再表示することはできません。
ブックマークのURLには、ページ上の動的コンテンツを再現するための情報が含まれている必要があります。たとえば、エンド・ユーザーが顧客の連絡先情報を表示するページにブックマークを付ける場合、ブックマークのURLには、ページに加えてその顧客を識別する情報も必要です。これにより、ユーザーがブックマークを使用してそのページに戻ったときに、同じ顧客の連絡先情報を表示できるようになります。
ブラウザに表示されているページのURLをブックマークとして使用できることを確認するには、そのページに関連付けられているビュー・アクティビティがブックマーク可能であることを識別します。
実行時に、無制限タスク・フロー内のビュー・アクティビティがブックマーク可能として指定されているかどうかをViewBookmarkable()
メソッドを使用して識別できます。メソッドはビュー・ポート・コンテキストとは離れて配置されています。
ビュー・アクティビティをブックマーク可能として指定すると、オプションで1つ以上のURLパラメータを指定できます。url-parameter
の値はEL式です。EL式は、ブックマーク可能なURLが生成されたときにURLに含めるパラメータの取得元を指定します。また、ブックマーク可能なURLが参照解除されたときにURLから値を格納します。ブックマーク可能なビュー・アクティビティのURLを介してパラメータが渡されたときに変換および検証を実行するメソッドは、converter
オプションで識別されます。
さらに、送信されたURLパラメータ値でアプリケーション・モデルが更新された後、およびビュー・アクティビティをレンダリングする前に起動されるメソッドをオプションで指定することもできます。このメソッドを使用して、URLパラメータのキー値に基づいて追加情報を取得できます。
ビュー・アクティビティをブックマーク可能として指定するかわりに、redirect
オプションを指定できます。redirect
によって、ADFコントローラはビュー・アクティビティ用に新規URLを作成します。ビュー・アクティビティの元のURLは使用されなくなります。詳細は、15.2.3.2項「HTTPリダイレクトの指定方法」を参照してください。
例15-3は、ブックマークを付けたビュー・アクティビティのURL構文を示しています。
例15-3 バインドなしタスク・フローのビュー・アクティビティのURL構文
<server root>/<app_context>/faces/<view activity id>?<param name>=<param value>&...
ブックマークを付けたビュー・アクティビティのURL構文は、次のとおりです。
<server root>
: サイト・レベルまたは管理レベルでカスタマイズして指定します(例: http://mycompany.com/internalApp
)。
<app context>
: Webアプリケーションのコンテキスト・ルートです(例: myapp
)。コンテキスト・ルートはWebアプリケーションのベース・パスです。たとえば、<app_context>
は、サーバー上のWEB-INFノードの物理的な場所にマップされます。
faces
: Facesサーブレット・マッピングです。faces
の値は、faces-config.xml
構成ファイルを含むノードを指します。
<view activity id>
: ブックマークを付けたビュー・アクティビティの識別子です(例: edit-customers.
)。
<param name>
: ブックマークを付けたビュー・アクティビティのURLパラメータの名前です(例: customer-id
)。
<param value>
: EL式から導出されたパラメータ値です(例: #{pageFlowScope.employee.id}
)。EL式の値は、文字列として表すことができる必要があります。
例15-4は、バインドなしタスク・フロー内のブックマーク可能なビュー・アクティビティ用のサンプルURLを示しています。
例15-4 ブックマーク可能なビュー・アクティビティのサンプルURL
http://mycompany.com/internalApp/MyApp/faces/edit-customers?customer-id=1234&...
ブックマーク可能なビュー・アクティビティを作成するには、ビュー・アクティビティをブックマーク可能として指定し、ブックマークにURLパラメータを指定して、ブックマークが参照解除された後に実行されるメソッドを指定します。
ビュー・アクティビティをブックマーク可能として指定するには:
バインドなしタスク・フロー・ダイアグラムで、ビュー・アクティビティを選択します。
「プロパティ・インスペクタ」で、「ブックマーク」をクリックします。
「ブックマーク」ドロップダウン・リストで、「True」を選択します。
「URLパラメータ」セクションを展開して、ブックマークを付けるビュー・アクティビティのURLに含めるURLパラメータをオプションで追加します。
name: パラメータの名前。
value: 評価時にパラメータ値を指定する、設定可能なEL式(例: #{pageFlowScope.employeeID}
)。この値は文字列として表すことができる必要があります。
「コンバータ」: (オプション)oracle.adf.controller.URLParameterConverter
を実装するオブジェクトに対するEL式。
「value」は、ブックマーク可能なURLが生成されたときにURLに含めるパラメータの取得元です。また、ブックマーク可能なURLが参照解除されたときにパラメータはここに格納されます。
値に入力されたEL式からNULL
が戻されると、そのパラメータはブックマークを付けたビュー・アクティビティのURLから削除されます。
「name」および「value」を使用して、例15-4に示すように、ブックマーク・パラメータをビュー・アクティビティURLに追加します。
「コンバータ」フィールドには、各ブックマークのURLパラメータ値(#{pageFlowScope.employee.idConverter}
など)に使用する値バインディングをオプションで入力できます。
URLパラメータ・コンバータのgetAsObject()
メソッドは、入力パラメータに単一文字列の値を取り、適切な型のオブジェクトを戻します。ADFコントローラでURLパラメータに対してコンバータ・メソッドが起動され、続いてパラメータ値がアプリケーションのモデル・オブジェクトに適用されます。同様に、コンバータのgetAsString()
メソッドは、入力パラメータにオブジェクトを取り、URLで使用される文字列表現を戻します。
JSFアプリケーションでは、送信ページのUIコンポーネントに指定されているコンバータおよびバリデータでデータ値が変換および検証されます。ブックマークURLを使用するFusion Webアプリケーションには、変換および検証を処理する送信ページがありません。そのため、各URLパラメータに使用するコンバータを指定するオプションが用意されています。
ビュー・アクティビティに指定されたredirect
オプションは、ADFコントローラでビュー・アクティビティ・リクエストに対してHTTPリダイレクトを発行する必要があることを示します。リダイレクトされたリクエストによって、ビュー・アクティビティ用に新しいブラウザのURLが作成されます。ビューの元のURLは使用できなくなります。
指定すると、クライアントのGET
リクエストによってリダイレクトが発生します。HTTP GET
の場合、#{bindings}
ELスコープは、ADFコントローラおよびADFモデル・レイヤーでページに新しいバインディング・コンテキストが設定されるまで無効です。そのため、リダイレクトされたビュー・アクティビティの入力パラメータはマップできません。
ビュー・アクティビティはブックマーク可能として識別するか、またはredirectオプションで識別しますが、両方で識別することはできません。
注意: http://www.mycompany.org/x.html でhttp://www.mycompany.org/y.html の内容をかわりに表示する場合、次のようなリフレッシュ方法は使用しないでください。
この方法は「戻る」ボタンの動作に悪影響を及ぼすことがあります。エンド・ユーザーがブラウザの「戻る」ボタンをクリックすると再度リフレッシュが行われ、予想どおり元のページに戻るのではなく次のページに進みます。 この場合は、かわりにHTTPリダイレクトを使用してください。 |
ビュー・アクティビティにHTTPリダイレクトを指定するには:
バインドなしタスク・フロー・ダイアグラムで、ビュー・アクティビティを選択します。
プロパティ・インスペクタで、「共通」をクリックします。
「リダイレクト」ドロップダウン・リストで、「True」を選択します。
ビュー・アクティビティをブックマーク可能として指定すると、例15-5に示すように、ビュー・アクティビティのメタデータにbookmark要素が追加されます。bookmark要素には、URLパラメータと、ブックマークが参照解除された後に実行されるメソッドを指定するメタデータをオプションで含めることができます。
例15-5 ブックマーク可能なビュー・アクティビティのサンプル・メタデータ
<view id="employee-view"> <page>/folderA/folderB/display-employee-info.jspx</page> <bookmark> <url-parameter> <name>employee-id</name> <value>#{pageFlowScope.employee.id}</value> <converter>#{pageFlowScope.employee.validateId}</converter> </url-parameter> <method>#{pageFlowScope.employee.queryData}</method> </bookmark> </view>
URLビュー・アクティビティを使用すると、ADFリージョンのコンテキスト内からでも、ルート・ビュー・ポート(ブラウザ・ページなど)をURLにアドレス可能なリソースにリダイレクトできます。URLアドレス可能なリソースには次が含まれます。
バインド・タスク・フロー
無制限タスク・フロー内のビュー・アクティビティ
現在のWebアプリケーションの外にあるアドレス(たとえばhttp://www.oracle.com
など)
リソースを表示するには、実行時の評価でそのリソースのURLが生成されるEL式を指定する必要があります。さらに、評価時にパラメータおよびパラメータ値としてURLに追加されるEL式を指定することもできます。
URLビュー・アクティビティでは、実行元のビュー・ポート(ルート・ビュー・ポートまたはADFリージョン)には関係なく、クライアントがリダイレクトされます。ビュー・アクティビティの<redirect>
要素は、そのビュー・アクティビティがルート・ビュー・ポート内にある場合のみ使用されることを除けば、同様の方法で実行されます。<redirect>
要素は、ADFリージョンのコンテキスト内では無視されます。詳細は、15.2.3.2項「HTTPリダイレクトの指定方法」を参照してください。
<redirect>
要素ではなくURLビュー・アクティビティを使用した同じアプリケーション内の他の場所へのリダイレクトは、タスク・フロー・スタックがクリーンアップされるため、「戻る」ボタンでの移動と同様に処理されます。Webアプリケーション外部へのリダイレクトは、アプリケーション外部のサイトのURLを参照解除する場合のように処理されます。
URLビュー・アクティビティをバインドまたはバインドなしタスク・フローに追加できます。
タスク・フローへのURLビュー・アクティビティの追加手順:
コンポーネント・パレットの「ADFタスク・フロー」ページから、URLビュー・アクティビティをダイアグラムにドラッグします。
タスク・フロー・ダイアグラムで、URLビュー・アクティビティを選択します。
プロパティ・インスペクタの「一般」ページで、「アクティビティID」フィールドにURLビュー・アクティビティを識別するIDを入力します。
「URL」フィールドの横のボタンをクリックして、「式ビルダー」を起動し、実行時にURLのレンダリングを行うEL式を記述します。
たとえば、図15-4は、Fusion Order Demoアプリケーションのmyorders-task-flow.xmlバインド・タスク・フロー内で、EL式(#{myOrdersBean.registerNav}
)を使用して実行時にURLを取得するURLアクティビティ(register
)を示しています。
「URLパラメータ」セクションを展開して、URLに含めるURLパラメータをオプションで追加します。
name: パラメータの名前。
value: 評価時にパラメータ値を生成するEL式。
「コンバータ」: 評価時に、ブックマーク可能なビュー・アクティビティのURLを介してパラメータが渡されたときに変換および検証を実行するメソッドを指定する、設定可能なEL式。詳細は、30.3項「ADFセキュリティの有効化」を参照してください。
ポートレットのコンテキスト内で使用可能なタスク・フローのURLビュー・アクティビティで使用するURLを作成する場合、そのURLは次のいずれかをコールして作成します。
ControllerContext.getLocalViewActivityURL()
ControllerContext.getGlobalViewActivityURL()
(ターゲットviewId
に渡す)
あるいは完全修飾された絶対URL、コンテキスト・パス相対URL、または現行のビューに対する相対URL。
注意: ControllerContext.getLocalViewActivityURL() またはControllerContext.getGlobalViewActivityURL() メソッドをコールしてリダイレクトURLを作成する場合は、ExternalContext.redirect() をコールする前に、ExternalContext.encodeActionURL() をレスポンス付きでコールしないでください。
これは、これらのメソッドが必要なURLのエンコーディングをすでに組み込んでいるためです。 |
URLビュー・アクティビティがポートレットのタスク・フロー内で使用される場合、次の動作が発生します。
リダイレクトURLがポートレット・アプリケーション内の場所を参照していて、値がtrue
に設定されたx_DirectLink
という名前のqueryString
パラメータを含まない場合、これを含むページ内のポートレットがこの新しいビューに移動します。
それ以外の場合はクライアント・リダイレクトが発行され、ユーザーはアプリケーション・ページまたは含むページからそのURLに移動します。
ルーター・アクティビティを使用して、EL式に指定するロジックに基づいて、アクティビティに対する制御を宣言的にルーティングできます。図15-5に示すように、ルーターは各種のアクティビティにつながる複数の制御フローに分岐するために使用することがあります。
各制御フローが異なるルーター・ケースに対応できます。各ルーター・ケースには次の要素があり、次に制御をルーティングするアクティビティを選択するために使用されます。
expression: true
またはfalse
に評価されるEL式(例: #{(pageFlowScope.welcomeUserRegistrationBean.userSelection eq 'Customer')}
)。
true
に評価された最初の式が、対応する結果の決定に使用されます。
outcome: EL式がtrue
に評価された場合にルーター・アクティビティから戻される値(例: newCustomer
)。
制御フロー・ケースでルーターの結果がfrom-outcome
と一致すると、制御フロー・ケースがポイントするアクティビティに制御が渡されます。ルーター・アクティビティの評価がtrue
になるケースがない場合、またはケースが指定されていない場合は、ルーターの「デフォルト結果」フィールドに指定されている結果があれば、それが使用されます。
たとえば、図15-5に示すように、welcomeUserRegistrationページ・フラグメントでユーザーが「Create a New Customer」
ボタンまたは「Create a New Employee」ボタンのどちらをクリックしたかに基づいた制御フローを考えるとします。
ユーザー登録ページ・フラグメントの入力テキスト・フィールドに入力したユーザーが新規ユーザーかどうかを評価するルーター・ケースのいずれかに、EL式を追加できます。次に、予想されるoutcome
を指定します(例: newCustomer
)。図15-5に示すように、式がtrue
に評価されると、制御フロー・ケースfrom-outcome
、つまりnewCustomer
に基づいて、customer-registration-task-flow
タスク・フロー・コール・アクティビティに制御が渡されます。
ベスト・プラクティス: ルーティング条件をEL式で表すことができる場合は、ルーターを使用します。 ルーターを使用すると、それを含むタスク・フローの設計時により多くのことができるようになります。ルーター・アクティビティによって条件に関する詳細をタスク・フロー上に表示できるようになるため、ダイアグラムを参照する他のユーザーにとってさらに読みやすくなり、役に立ちます。 また、ルーター・アクティビティを使用すると、後でアプリケーションを変更しやすくなります。たとえば、ルーティング条件を後で変更または追加できます。 |
ルーター・アクティビティを使用して制御フローを定義するには:
コンポーネント・パレットの「ADFタスク・フロー」ページから、「ルーター」アクティビティをタスク・フロー・ダイアグラムにドラッグします。
タスク・フロー・ダイアグラムで、ルーター・アクティビティを選択します。
メイン・メニューから、「表示」→「プロパティ・インスペクタ」を選択します。
「プロパティ・インスペクタ」の「共通」ページで、「id」を入力します。
このIDは、メタデータ内のルーター・アクティビティを参照するために使用される識別子です(例: router1
)。
「ケース」の横の「追加」アイコンをクリックします。
各ルーターのケースに値を指定します。
ケースは、true
に評価された場合に結果を戻す条件です。各ケースに次の内容を入力する必要があります。
expression: true
またはfalse
に評価するEL式。
式では、ビュー・アクティビティの入力テキスト・フィールドを参照できます。たとえば、フィールドの値が#{pageFlowScope.value}
であるとします。この場合、式を#{pageFlowScope.value=='view2'}
にして、ユーザーがフィールドにview2
を入力した場合に、指定した結果が戻されるようにできます。
outcome: 対応する式がtrueに評価される場合に、ルーター・アクティビティから戻される値。
タスク・フロー・ダイアグラムの一致する制御フロー・ケースまたはワイルドカード制御フロー・ルールについてそれぞれoutcomeを指定する必要があります。たとえば、各ケースのoutcome
について、ダイアグラム内のルーター・アクティビティから導かれる制御フロー・ケース要素に指定された対応するfrom-outcome
があることを確認できます。図15-5では、ケースの結果および制御フロー・ケース要素のfrom-outcomeの両方の値がnewCustomer
です。これにより、制御フロー要素のターゲットであるnewCustomer
アクティビティに制御フローが渡されるようになります。
「プロパティ・インスペクタ」で、default-outcomeと入力します。
この結果は、ルーター・アクティビティのケースでtrue
に評価されるものがない場合、またはケースが指定されていない場合に戻されます。
例15-6では、toRegion3
というデフォルトの結果を指定しています。制御フローは結果がto Region3
のケースに移動します。ケースの評価結果がいずれもtrue
でない場合、Router1
がルーター・アクティビティから戻されます。
例15-6 デフォルトの結果を定義するルーターのメタデータ
<router id="Router1"> <case> <expression>#{binding.Region.InputValue='1'}</expression> <outcome>toRegion1</outcome> </case> <case> <expression>#{binding.Region.InputValue='2'}</expression> <outcome>toRegion2</outcome> </case> <case> <expression>#{binding.Region.InputValue='3'}</expression> <outcome>toRegion3</outcome> </case> <default-outcome>toRegion3</default-outcome> </router>
標準のJSFアプリケーションでは、JSFページのマークアップ内で指定されたアクションからのみアプリケーション・ロジックを起動できます。メソッド・コール・アクティビティを使用すると、アプリケーションの制御フロー内のどこからでもアプリケーション・ロジックを起動する、カスタム・メソッドまたは組込みメソッドをコールできるようになります。ページ表示前の初期化、ページ終了後のクリーンアップ、例外処理などのタスクを実行するメソッドを指定できます。
図15-6に示すように、Fusion Order Demoアプリケーションでは、従業員登録バインド・タスク・フローでメソッド・コール・アクティビティが使用されています。このアクティビティでは、StoreServiceAM
データ・コントロールで公開されているuserRegistrationCreate
メソッドがコールされます。
制御フロー・ケースを指定してメソッドの終了後に制御を渡すメソッドに対して結果を設定できます。詳細は、14.1.3項「制御フロー」を参照してください。結果には次のいずれかを指定できます。
fixed-outcome
: 正常完了時に、メソッドから常に戻される単一の結果(例: success
)。メソッドが正常に完了しないと結果は戻されません。メソッド・タイプがvoidの場合、to-string
ではなくfixed-outcome
を指定する必要があります。
to-string
: trueとして指定されると、メソッドによって戻されたJavaオブジェクトに対してtoString()
メソッドがコールされ、それに基づく結果が得られます。たとえば、toString()
からeditBasicInfo
が戻された場合、図15-6
に示すように、ナビゲーションはeditBasicInfo制御フロー・ケースに移動します。
例15-7に示すように、メソッドのoutcomeとメソッドのresultは2つの別個の値です。<return-value>
要素は、calculateSalesTax
メソッドのresultを配置する場所を指定します。<outcome>
要素は、メソッドの終了後に使用する制御フロー・ケースを示します。
例15-7 return要素とoutcome要素の指定されたメソッド・コール・アクティビティのメタデータ
<method-call id="calculateSalesTax"> <method>#{pageFlowScope.taxService.calculateSalesTax}</method> <return-value>#{pageFlowScope.result}</return-value> <outcome> <fixed-outcome>gotoError</fixed-outcome> </outcome> </method-call
作業を始める前に、バインド・タスク・フローまたは無制限タスク・フローを作成しておく必要があります。詳細は、14.2項「タスク・フローの作成」を参照してください。コンポーネント・パレットからタスク・フロー・ダイアグラムにメソッド・コール・アクティビティをドラッグします。メソッド・コール・アクティビティは、「データ・コントロール」パネルからタスク・フロー・ダイアグラム内のメソッド・コール・アクティビティにデータ・コントロール操作を直接ドロップして、既存のメソッドに関連付けることができます。
たとえばFusion Order Demoアプリケーションでは、データ・コントロール・イテレータからsetCurrentRowWithKey
またはsetCurrentRowWithKeyValues
操作をダイアグラムにドラッグして、表内の現在行を表示または選択できます。
注意: データ・コントロール・メソッドのパラメータは、ADFコントローラのメタデータ内ではなく、対応するページのページ定義に定義されます。詳細は、28.3項「コマンド・コンポーネントを使用したパラメータ値の設定」を参照してください。 |
メソッドおよび操作はタスク・フロー・ダイアグラムにも直接ドラッグできます。ダイアグラム上にドロップすると、新しいメソッド・コール・アクティビティが自動的に作成されます。メソッドにEL式およびその他のオプションを指定できます。
ヒント: メソッド・コール・アクティビティが起動するメソッドを識別するには、タスク・フロー・ダイアグラム内で任意のアクティビティを右クリックし、「メソッドに移動」を選択します。JDeveloperはメソッド・コール・アクティビティが起動するメソッドに移動します。 |
タスク・フローへのメソッド・コール・アクティビティの追加手順:
コンポーネント・パレットで、「ADFタスク・フロー」ページからタスク・フローのダイアグラムにメソッド・コール・アクティビティをドラッグします。
メソッド・コール・アクティビティには、オプションでデフォルトのIDであるmethodCall
n
、およびメソッドのEL式がまだ指定されていないことを示す警告アイコンが表示されます。
警告アイコンの有効化の詳細は、14.3.1項「ADFタスク・フローへのアクティビティの追加方法」を参照してください。
デフォルトのIDを変更する場合、タスク・フロー・ダイアグラムでメソッド・コール・アクティビティの下に表示されるテキストをクリックします。
メソッド・コールの名前をaddItemToCart
のように入力できます。
タスク・フロー・ダイアグラムで、メソッド・コール・アクティビティを選択します。
「プロパティ・インスペクタ」の「一般」ページで、「メソッド」フィールドにメソッドのEL式を入力します。
たとえば、#{bindings.addItemstoCart.execute}
のようなELバインディング式を入力できます。
注意: EL式のバインディング変数は、現在のバインディング・コンテナからのADFモデル・バインディングを示します。バインディング変数を指定するには、バインディング・コンテナ定義またはページ定義を指定する必要があります。詳細は、12.6項「ページ定義ファイルでの作業」を参照してください。 |
図15-7に示す「プロパティの編集」ダイアログ・ボックスを使用して、次のメソッドのEL式を作成することもできます。
プロパティ・インスペクタの「一般」ページで、「メソッド」フィールドの隣のドロップダウン・メニューから「式ビルダー」を選択します。
「式ビルダー」ダイアログで、「ADFバインディング」などのノードを展開して、メソッドを選択します。または、「ADFマネージドBean」ノードの下で、コールするメソッドを含むマネージドBeanに移動し、メソッドを選択します。
「式に挿入」をクリックします。
「式ビルダー」ダイアログは図15-7のようになります。たとえば図15-7では、addItemToCart
メソッドとshoppingCartBean
を組み合せて、「式ビルダー」の最上部に表示されるEL式を作成します。
「OK」をクリックします。
ヒント: メソッド・コール・アクティビティでマネージドBeanメソッドを起動する場合は、タスク・フローのダイアログでメソッド・コール・アクティビティをダブルクリックします。これによってダイアログが呼び出され、そこで起動するマネージドBeanメソッドを指定できます。 |
プロパティ・インスペクタの「一般」ページで、「結果」セクションに次のいずれかを指定します。
固定結果: 正常完了時に、メソッドから常に戻される単一の結果(例: success
)。メソッドが正常に完了しないと結果は戻されません。メソッド・タイプがvoidの場合、to-stringではなくfixed-outcomeを指定する必要があります。
tostring(): 「True」を選択すると、メソッドから戻されたJavaオブジェクトに対してtoString()
メソッドがコールされ、それに基づく結果が得られます。
メソッドのパラメータや戻り値を指定することができます。図15-8は、calculateSalesTax
というメソッドに唯一定義されているパラメータを示しています。「value」フィールドにはパラメータ値に評価されるEL式が示されています。
メソッド・コール・アクティビティを既存のメソッドに関連付けてパラメータを作成していない場合は、各自パラメータを追加します。
メソッド・パラメータを追加するには:
15.5.1項の手順を実行して、タスク・フロー・ダイアグラムにメソッド・コール・アクティビティを追加します。
タスク・フロー・ダイアグラムで、メソッド・コール・アクティビティを選択します。
「プロパティ・インスペクタ」で、「パラメータ」をクリックします。
「パラメータ」ページで、「パラメータ」セクションを展開します。
プラスの「追加」アイコンをクリックします。
「class」フィールドに、パラメータのクラスを入力します(例: java.lang.Double
)。
「value」フィールドに、パラメータの値が取得される場所を示すEL式を入力します(例: #{pageFlowScope.shoppingCart.totalPurchasePrice}
)。
ヒント: 「value」フィールドの横にあるアイコンをクリックして「式ビルダー」を選択すると、メソッド・パラメータを検索できます。 |
return-valueフィールドに、メソッドの戻り値を格納する場所を示すEL式を入力します(例: #{pageFlowScope.Return}
)。
「OK」をクリックします。
前述の各手順を繰り返してさらにパラメータを追加します。
メソッドのパラメータや戻り値の指定後、XMLソース・ファイルが更新されます。例15-8に、バインド・タスク・フローのXMLソース・ファイルでuserRegistrationCreate
へのメソッド・コールがどのように記述されるかを示します。
タスク・フロー・コール・アクティビティを使用すると、無制限タスク・フローまたはバインド・タスク・フローのいずれかからバインド・タスク・フローをコールできます。タスク・フロー・コール・アクティビティによって、同じアプリケーション内または別のアプリケーション内にあるバインド・タスク・フローをコールできます。
コールされたバインド・タスク・フローでは、デフォルト・アクティビティが最初に実行されます。バインド・タスク・フロー・コールの数に制限はありません。たとえば、バインド・タスク・フローからは別のバインド・タスク・フローをコールでき、さらにそのバインド・タスク・フローからも次々にコールできます。
バインド・タスク・フローにパラメータを渡すには、タスク・フロー・コール・アクティビティに入力パラメータの値を指定する必要があります。これらの値は、コール先のバインド・タスク・フローの入力パラメータ定義と一致している必要があります。詳細は、15.6.3項「タスク・フロー・コール・アクティビティでの入力パラメータの指定方法」を参照してください。
タスク・フロー・コール・アクティビティの「入力パラメータ」の値は、コール元のタスク・フロー内で値が取得される場所を指定します。
コール先のタスク・フローの「入力パラメータの定義」の値は、値が渡されたときにコール先のバインド・タスク・フローで値が格納される場所を指定します。
ヒント: バインド・タスク・フローがタスク・フロー・コール・アクティビティに関連付けられると、バインド・タスク・フローで定義されている入力パラメータ定義に基づいて、入力パラメータが自動的にタスク・フロー・コール・アクティビティに挿入されます。したがって、アプリケーション開発者が実行する必要があるのは、タスク・フロー・コール・アクティビティの入力パラメータへの値の割当てのみです。 |
デフォルトでは、すべてのオブジェクトは参照渡しされます。プリミティブ・タイプ(int、long、booleanなど)は常に値渡しされます。
バインド・タスク・フローからコール元に戻り値が渡される方法は、入力パラメータが渡される方法と類似しています。詳細は、16.4項「戻り値の指定」を参照してください。
コール側のバインドまたはバインド・タスク・フローまたはバインドなしタスク・フローにタスク・フロー・コール・アクティビティを追加し、バインド・タスク・フローをコールします。
バインド・タスク・フローをコールする手順:
ダイアグラム・エディタでコール側のタスク・フローを開きます。
コンポーネント・パレットの「ADFタスク・フロー」ページで、「タスク・フロー・コール」アクティビティをドラッグし、コール側のタスク・フローにドロップします。
次のいずれかの方法を使用して、コール先のタスク・フローを特定します。
タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティをダブルクリックします。
「バインド・タスク・フローの作成」ダイアログが表示され、そこで新規バインド・タスク・フロー作成のオプションを指定できます。
アプリケーション・ナビゲータから既存のバインド・タスク・フローをドラッグし、タスク・フロー・コール・アクティビティにドロップします。
ヒント: バインド・タスク・フローをページまたはページ・フラグメントにドロップできます。バインド・タスク・フローが(ページ・フラグメントではなく)ページから構成されている場合、タスク・フローをドロップするページに実行リンクまたは実行ボタンのどちらのUIコンポーネントを追加するか選択できます。エンド・ユーザーは、ボタンまたはリンクをクリックしてタスク・フローをコールできます。ページがタスク・フローの既存のビュー・アクティビティに関連付けられている場合、このようにするとタスク・フロー・コール・アクティビティが同様に自動的に作成されます。たとえ両方のアプリケーションがアプリケーション・ナビゲータ内に表示されているとしても、アプリケーション・ナビゲータで、あるアプリケーションから別なアプリケーション内のタスク・フロー・ダイアグラムにバインド・タスク・フローをドロップすることはできません。さらに、あるプロジェクトのバインド・タスク・フローを、別なプロジェクトのタスク・フロー・ダイアグラムにドロップすることはできません。 そのかわり、バインド・タスク・フローをADFライブラリにパッケージ化して、現在のアプリケーションまたはプロジェクトで再利用できます。これにより、ライブラリのインポート時に作成される「リソース・カタログ」ページまたは「コンポーネント・パレット」ページから、バインド・タスク・フローをドラッグできるようになります。詳細は、33.1.2項「リソース・パレットの使用」を参照してください。 |
起動するバインド・タスク・フローの名前がわかっている場合は、次の手順を実行します。
タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。
プロパティ・インスペクタの「一般」ページで、「タスク・フロー参照」ドロップダウン・リストから「static」を選択します。
「ドキュメント」フィールドに、コールするバインド・タスク・フローのソース・ファイル名を入力します。たとえば、called-task-flow-definition.xml
。
「ID」フィールドには、たとえばtargetTaskFlow
など、コール先のバインド・タスク・フローのXMLソース・ファイルに含まれているバインド・タスク・フローIDを入力します。
起動するバインド・タスク・フローの名前がわからない場合、実行時のエンド・ユーザーによって異なる場合は、次の手順を実行します。
タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。
プロパティ・インスペクタの「一般」ページで、「タスク・フロー参照」ドロップダウン・リストから「動的」を選択します。
「動的タスク・フロー参照」プロパティの右側に表示されているドロップダウン・メニューから、「式ビルダー」を選択します。
実行時に起動するバインド・タスク・フローのIDを識別するEL式を記述します。
図15-9に、Fusion Order Demoアプリケーション内のバインドなしタスク・フローのcheckout-task-flowタスク・フロー・コール・アクティビティを示します。このタスク・フロー・コール・アクティビティは、checkout-task-flow.xml
ファイル内のcheckout-task-flowを起動します。
JDeveloperはバインド・タスク・フローをコールするタスク・フローのソース・ファイルに、メタデータ・エントリを生成します。例15-9は、チェックアウト・バインド・タスク・フロー(checkout-task-flow.xml
)を参照する、Fusion Order Demoアプリケーションのadfc-config.xml
の例です。実行時に、タスク・フロー・コール・アクティビティが、チェックアウト・バインド・タスク・フローをコールします。
タスク・フロー・コール・アクティビティとそのコール先のバインド・タスク・フローの間でパラメータをマップするには、まずコール先のバインド・タスク・フローの入力パラメータ定義を指定する方法をお薦めします。その後、アプリケーション・ナビゲータからバインド・タスク・フローをドラッグして、タスク・フロー・コール・アクティビティにドロップできます。タスク・フロー・コール・アクティビティの入力パラメータは、バインド・タスク・フローの入力パラメータ定義に基づいて自動的に作成されます。詳細は、16.3項「ADFバインド・タスク・フローへのパラメータの渡し方」を参照してください。
当然ながら、最初にタスク・フロー・コール・アクティビティに入力パラメータを指定することも可能です。最初に定義した場合にも、コール先のバインド・タスク・フローの入力パラメータ定義がタスク・フロー・コール・アクティビティに関連付けられた時点で、その入力パラメータ定義に基づいて自動的に置換されます。
コール先のバインド・タスク・フローをまだ作成していない場合にも、タスク・フロー・コール・アクティビティに入力パラメータを指定する方法は便利です。この時点で指定することで、バインド・タスク・フローのコール時にタスク・フロー・コール・アクティビティが最終的にマップされる予定の入力パラメータを特定できます。
入力パラメータをタスク・フロー・コール・アクティビティに指定するには:
タスク・フロー・ダイアグラムで、タスク・フロー・コール・アクティビティを選択します。
プロパティ・インスペクタの「パラメータ」セクションを展開し、「追加」アイコンをクリックしてパラメータ名を入力します。
ヒント: バインド・タスク・フローをダイアグラムのタスク・フロー・コール・アクティビティにドロップするとname フィールドが自動的に移入されます。 |
パラメータの値を入力します(例: #{pageFlowScope.callingTaskflowParm}
)。
この値は、コール元のタスク・フロー内でパラメータ値が取得される場所を指定します。
デフォルトでは、すべてのオブジェクトは参照渡しされます。プリミティブ型(int
、long
、boolean
など)は常に値で渡されます。
入力パラメータを指定すると、対応する入力パラメータ定義をコール先のバインド・タスク・フローに指定できます。詳細は、16.3項「ADFバインド・タスク・フローへのパラメータの渡し方」を参照してください。
URLを使用して、別のWebアプリケーションにあるページ・フラグメント(.jsff
)を使用しないバインド・タスク・フローをコールできます。タスク・フロー・コール・アクティビティを使用して、起動するバインド・タスク・フローをコールします。タスク・フロー・コール・アクティビティのremote-app-url
プロパティ(評価されるとURLを返す)のEL式を記述します。
remote-app-url
プロパティの値を記述するだけでなく、コールするバインド・タスク・フローを識別するタスク・フロー参照・プロパティの値も指定します。タスク・フロー参照およびremote-app-url
プロパティが実行時に組み合せられて、リモートWebアプリケーションで、コール先のバインド・タスク・フローのURLが生成されます。
リモートWebアプリケーションでは、コールするバインド・タスク・フローの「可視性」プロパティを設定し、コール側のタスク・フローでタスク・フロー・コール・アクティビティから生成されたURLを受信すると、起動するようにしておく必要もあります。
JSFポートレットは同じWebアプリケーションからすべてのコンテンツを提供する点に注意してください。したがって、JSFポートレットでWebアプリケーションを使用する場合は、WebアプリケーションがURLを使用してリモート・タスク・フローを起動するような設定は行わないでください。
URLを使用してバインド・タスク・フローをコールする手順:
リモートWebアプリケーションでのバインド・タスク・フロー起動用に設定するWebアプリケーション内のタスク・フローを開きます。
コンポーネント・パレットの「ADFタスク・フロー」ページで、「アクティビティ」パネルから、「タスク・フロー・コール」アクティビティをドラッグし、タスク・フローのダイアグラムにドロップします。
プロパティ・インスペクタで「一般」セクションを展開し、プロパティ値を記述して、バインド・タスク・フローを起動します。
詳細は、15.6.1項「タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法」を参照してください。
「リモート・アプリケーションのURL」プロパティについては、「式ビルダー」を使用して、評価時にリモートWebアプリケーションのURL作成に必要な部分を含む文字列を返すEL式を記述します。
たとえば次のEL式は、URLの作成に必要な部分を含む文字列を返すマネージドBeanを起動します。
#{myOrdersBean.createOrder}
ステップ3で値を指定したバインド・バスク・フローを開きます。
注意: 指定するバインド・タスク・フローは、ページ・フラグメント (.jsff )を使用できません。 |
「構造」ウィンドウで、バインド・タスク・フロー(タスク・フロー定義)のノードを右クリックし、「プロパティに移動」を選択します。
プロパティ・インスペクタで「一般」カテゴリを展開し、次のプロパティ値を設定します。
URL起動: URLによるバインド・タスク・フローの起動を許可する場合は、ドロップダウン・リストからurl-invoke-allowed
を選択します。URLによるバインド・タスク・フローの起動を許可しない場合は、url-invoke-disallowed
を選択します。この値を選択しておくと、URLがバインド・タスク・フローを起動しようとすると、HTTP 403のステータス・コードが返されます。デフォルト値(calculated
)では、バインド・タスク・フローがイニシャライザを指定しておらず、ビュー・アクティビティがデフォルト・アクティビティである場合に、URLによるバインド・タスク・フローの起動を許可します。バインド・タスク・フローがこの条件を満たしていない場合は、HTTP 403のステータス・コードが返されます。url-invoke-allowed
またはurl-invoke-disallowed
を選択すると、デフォルト動作がオーバーライドされます。
ライブラリ内部:ADFライブラリJAR内にパッケージした場合に、内部のバインド・タスク・フローにしたい場合は、true
に設定します。デフォルト値はfalse
です。
ADFライブラリJAR内でのバインド・タスク・フローのパッケージの詳細は、33.2項「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。
バインド・タスク・フローを保存して閉じます。
JDeveloperはリモートWebアプリケーション内でバインド・タスク・フローに対するタスク・フロー・コール・アクティビティを起動するタスク・フローのソース・ファイルに、メタデータ・エントリを生成します。例15-10に、タスク・フロー・コール・アクティビティのエントリ例を示します。
例15-10 バインド・タスク・フローに対するタスク・フロー・コール・アクティビティのメタデータ・エントリ
<task-flow-call id="createOrder"> <task-flow-reference> <document id="__6">myorders-task-flow.xml</document> <id id="__5">myorders-task-flow</id> </task-flow-reference> <remote-app-url id="__7">#{myOrdersBean.createOrder}</remote-app-url> </task-flow-call>
例15-10
のcreateOrderメソッドは、バインド・タスク・フローの起動に必要なURL構文とともに文字列を返します。返される文字列に必要な部分の説明とURLの例を含むURL構文の詳細は、15.6.6項「URLを使用したバインド・タスク・フローのコールに関する必知事項」を参照してください。
JDeveloperはバインド・タスク・フローのソース・ファイル構成時にも、そこにエントリを生成し、URLでコールできるようにします。例15-11に、URLによるバインド・タスク・フローの起動を許可するメタデータ・エントリ例を示します。
ローカル・アプリケーションのデプロイメント記述子にコンテキスト・パラメータを追加することで、リモートWebアプリケーションとの対話管理が容易になります。
リモートWebアプリケーションのコンテキスト・パラメータ
URLを使用して別なFusion Webアプリケーション(リモート・アプリケーション)内のバインド・タスク・フローを起動する場合は、Fusion Webアプリケーション(ローカル・アプリケーション)のデプロイメント記述子(web.xml
)へのコンテキスト・パラメータの追加をお薦めします。コンテキスト・パラメータ値をリモート・アプリケーションのURLに設定します。ローカル・アプリケーションでEL式を記述する際は、次の例のようにコンテキスト・パラメータ名を使用します。ここでremoteAppUrl
はコンテキスト・パラメータ名です。
#{initParam.remoteAppUrl}
リモート・アプリケーションのURLが変更した場合は、コンテキスト・パラメータを更新して、変更後のURLを参照させます。
バインド・タスク・フローを起動するURL構文
一般的には、マネージドBeanメソッドを参照し、URLの必要な部分を取得するEL式を記述します。または、例15-12のようにURLのレンダリングを直接行うEL式を記述することもできます。
例15-12 バインド・タスク・フローを起動するURLの例
http://somecompany.com/internalApp/MyApp/faces/adf.task-flow?adf.tfId=displayHelp& adf.tfDoc=%2FWEB-INF%2Fdisplayhelp.xml&topic=createPurchaseOrder
例15-13では、バインド・タスク・フローを起動するURL構文部分を説明します。
例15-13 名前付きパラメータを使用してバインド・タスク・フローをコールするURL構文
<server root>/<app_context>/faces/adf.task-flow?adf.tfid=<task flow definition ID>&adf.tfDoc=<document name>&<named parameter>=<named parameter value>
次のリストで、例15-13のURL構文の各部分を説明します。
<server root>
: サイトまたは管理者レベルでカスタマイズして提供されます。例:
http://mycompany.com/internalApp
<server root>
の値は、バインド・タスク・フローをデプロイするアプリケーション・サーバーによって異なります。バインド・タスク・フローのURLは、JSFサーブレットのURLパス内のリソースです。
<app context>
: Webアプリケーションのコンテキスト・ルートです(例: MyApp
)。コンテキスト・ルートはWebアプリケーションのベース・パスです。
faces
: Facesサーブレット・マッピングです。
adf.task-flow
: リモートWebアプリケーションのADFコントローラを識別する予約キーワードです。
adf.tfId
: コールするタスク・フローのIDを提供するURLパラメータ。
<task flow ID>
: コール先のバインド・タスク・フローの識別子(例: displayHelp
など)。これは、ローカルでコールするときに使用するタスク・フローIDと同じIDです。この識別子はタスク・フロー・コール・アクティビティのインスタンスIDとは異なることに注意してください。このパラメータ値は文字列で表される必要があります。
adf.tfDoc
: コールするバインド・タスク・フローのIDが含まれたドキュメント名を提供するURLパラメータ。
<document name>
: コール先のバインド・タスク・フローのIDを含むドキュメントの名前(例: %2FWEB-INF%2FtoUppercase%2FdisplayHelp.xml
)。バインド・タスク・フローのURLを自分で作成する場合、適切なエンコーディングを設定します。
<named parameter>
: (オプション)コール先のバインド・タスク・フローの入力パラメータ定義の名前(例: topic
)。必要な入力パラメータ定義をすべて指定する必要があります。
<named parameter value>
: (オプション)入力パラメータの値です。
注意: アンダースコア(_)で始まるURLパラメータ名は、内部用に限定されているため、使用しないでください。ADFコントローラによって生成されたURLにこれらの名前が表示されても、使用または依存しないでください。 |
パラメータ・コンバータのオブジェクト型
パラメータ・コンバータを指定している場合は、そのコンバータを使用して、URLで使用されている文字列表現とタスク・フロー・パラメータ値の間で変換が行えます。パラメータ・コンバータは以下の型のオブジェクトを評価するEL式です。
oracle.adf.controller.UrlParameterConverter
パラメータ・コンバータを指定しない場合は、デフォルト・コンバータがパラメータにcross-site-scripting (XSS)攻撃がないことを確認します。アプリケーション内で使用されているパラメータに特殊文字が含まれていることがわかっている場合は、UrlParameterConverter
を独自に実装し、タスク・フロー・パラメータ値の変換に使用する必要があります。
タスク・フロー・コール・アクティビティのBefore ListenerとAfter Listenerを使用して、バインド・タスク・フローの開始と終了を識別します。タスク・フロー・コール・アクティビティにリスナーを指定すると、コール先のバインド・タスク・フローの特定の使用方法に対してそのリスナーが実行されます。
リスナーは、バインド・タスク・フローの開始時と終了時にコールされるメソッドのEL式として、<before-listener>#{global.showState}</before-listener}>
のように指定します。このメソッドにパラメータは指定できません。
Before listener: バインド・タスク・フローの開始前にコールされるJavaメソッドのEL式。コール元で、バインド・タスク・フローの開始時を把握する必要がある場合に使用されます。
After listener: バインド・タスク・フローから戻った後にコールされるJavaメソッドのEL式。コール元で、バインド・タスク・フローを終了してコール元に制御フローが戻ったときを認識する必要がある場合に使用されます。
複数のbefore listenerまたはafter listenerを指定した場合、バインドなしタスク・フローまたはバインド・タスク・フローのソース・ドキュメントにおける記述順でコールされます。タスク・フロー・コール・アクティビティは、before listenerとafter listenerを1つずつしか保持できません。
タスク・フロー・コールのafter listenerをコールするには、制御フロー・ルールを使用してバインド・タスク・フローから制御フローが戻される必要があります。エンド・ユーザーが、ブラウザの「戻る」ボタンまたは他のURLを使用してバインド・タスク・フローから離れた場合、タスク・フロー・コールのafter listenerはコールされません。バインド・タスク・フローのファイナライザを使用して、取得しているリソースをすべて解放し、エンド・ユーザーがブラウザの「戻る」ボタンをクリックして離れたバインド・タスク・フローのクリーンアップを実行する必要があります。詳細は、18.2項「イニシャライザとファイナライザの使用」を参照してください。
タスク・フロー・コール・アクティビティにbefore listenerまたはafter listenerを指定するには:
コール元のバインド・タスク・フローのダイアグラムで、タスク・フロー・コール・アクティビティを選択します。
プロパティ・インスペクタで、「リスナー」をクリックします。
before-listenerまたはafter-listenerの横にあるボタンをクリックします。
「式ビルダー」ダイアログで、リスナーのメソッドを含むJavaクラスまでドリルダウンします。
クラスのノードを開いてリスナー・メソッドを選択します。
選択後のEL式は#{pageFlowscope.managedBean.methodListener}
のようになります。
「OK」をクリックします。
タスク・フロー・コール・アクティビティをタスク・フロー・ダイアグラムに追加した後、15.6.1項「タスク・フロー・コール・アクティビティを使用したバインド・タスク・フローのコール方法」で説明したいずれかの方法で、コール先のバインド・タスク・フローへの参照を指定する必要があります。たとえば、既存のバインド・タスク・フローをタスク・フロー・コール・アクティビティにドロップすると、JDeveloperではタスク・フロー参照が自動的に生成されます。タスク・フロー参照は、コール先のバインド・タスク・フローを起動するために使用されます。
タスク・フロー参照が静的の場合は、各タスク・フロー参照は次から構成されます。
id: コール先のバインド・タスク・フローのXMLソース・ファイルに記述されているバインド・タスク・フローのIDです。たとえば、コール先のタスク・フローにはtargetFlow
というidがある場合があります。同じXMLソース・ファイルには複数のバインド・タスク・フローを含めることができ、各タスク・フローが一意のIDで識別されます。
注意: JDeveloperを使用してバインド・タスク・フローを作成した場合、バインド・タスク・フローは各ドキュメントに1つのみです。 |
document: コール先のバインド・タスク・フローのIDを記述したXMLソース・ファイルの名前。documentを指定しない場合、adfc-config.xml
であると判断されます。
このドキュメントは物理XMLファイルで、MDSを介してアクセスできなければなりません。
例15-14は、タスク・フロー・コール・アクティビティ内の静的なタスク・フロー参照の例を示しています。バインド・タスク・フローを起動するには、そのフローのIDと、IDが記述されているファイルの名前を把握している必要があります。
例15-14 静的なタスク・フロー参照
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2" id="__1"> ... <task-flow-definition id="task-flow-definition"> <default-activity>view1</default-activity> <task-flow-call id="taskFlowCall"> <task-flow-reference> <document>/WEB-INF/called-task-flow-definition.xml</document> <id>called-task-flow-definition</id> </task-flow-reference> </task-flow-call> </task-flow-definition> ... </adfc-config>
例15-15は、タスク・フロー・コール・アクティビティ内の動的タスク・フロー参照用にJDeveloperが生成するメタデータを示しています。
例15-15 動的なタスク・フロー参照
<?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="bounded_tf"> <default-activity id="__2">taskFlowCall1</default-activity> <task-flow-call id="taskFlowCall1"> <dynamic-task-flow-reference id="__3">#{EL_Expression_Retrieve_ TaskflowID}</dynamic-task-flow-reference> </task-flow-call> </task-flow-definition> </adfc-config>
ADFコントローラでは、タスク・フロー・コール・アクティビティを使用してバインド・タスク・フローがコールされたときに次の手順が実行されます。
ユーザーにバインド・タスク・フローをコールする権限があることを確認します。
指定した場合、タスク・フロー・コール・アクティビティのbefore listener (1つ以上)を起動します(15.6.7項「Before ListenerとAfter Listenerの指定方法」を参照)。
バインド・タスク・フローの入力パラメータ値を評価します。
コール先のバインド・タスク・フローをスタックに格納して、そのページ・フロー・スコープを初期化します。
コール先のバインド・タスク・フローのコンテキストに入力パラメータ値を設定します。
指定されている場合、バインド・タスク・フローのイニシャライザ・メソッドを起動します(詳細は、18.2項「イニシャライザとファイナライザの使用」を参照)。
バインド・タスク・フローのデフォルト・アクティビティを実行します。
タスク・フロー・リターン・アクティビティは、アプリケーションの制御フロー内で、バインド・タスク・フローが完了してコール元に制御フローが戻される場所を識別します。タスク・フロー・リターン・アクティビティは、バインド・タスク・フロー内でのみ使用できます。
タスク・フロー・リターン・アクティビティ・アイコンを囲むグレーの円は、そのアクティビティがバインド・タスク・フローの終了ポイントであることを示します。各バインド・タスク・フローには、ゼロから複数のタスク・フロー・リターン・アクティビティを指定できます。図15-10に、LoginおよびaddNewCustという名前のタスク・フロー・リターン・アクティビティが指定されたバインド・タスク・フローを示します。
各タスク・フロー・リターン・アクティビティには、コール元のタスク・フローに戻されるoutcome
を指定します。たとえば、Fusion Order Demoアプリケーションの顧客登録バインド・タスク・フローにおけるrollbackReturn
タスク・フロー・リターン・アクティビティのoutcome
は、cancelCreateCust
です。
図15-11は、顧客登録バインド・タスク・フロー(customer-registration-task-flow.xml
)からの抜粋です。このタスク・フローには、2つのタスク・フロー・リターン・アクティビティ(rollbackReturn
およびcommitReturn
)が含まれています。rollbackReturn
タスク・フロー・リターン・アクティビティのoutcome
はcancelCreateCust
です。一方、commitReturn
タスク・フロー・リターン・アクティビティのoutcome
はglobalhome
を返します。
顧客登録を起動するタスク・フローに戻されるoutcome
は、エンド・ユーザー・アクションによって異なります。起動元のタスク・フローによって次のアクションを決定するように、起動元のタスク・フローの制御フロー・ケースを構成できます。制御フローのfrom-outcome
要素をタスク・フロー・リターン・アクティビティのoutcome
からの戻り値に設定し、結果に基づくアクションを起動します。これによって、顧客登録タスク・フローから戻った後の制御フローが決まります。
「セーブポイントのリストア」プロパティの値を設定して、バインド・タスク・フローの終了時に、タスク・フロー・リターン・アクティビティを使用して、バインド・タスク・フロー内で行われたモデル変更を保存または破棄するように指定します。true
に設定すると、Fusion Webアプリケーションが最初にバインド・タスク・フローを開始した際に作成された、ADFモデルのセーブポイントまでロールバックします。デフォルト値はfalse
です。このプロパティ値は、タスク・フロー・リターン・アクティビティがあるバインド・タスク・フローの開始時に新しいトランザクションが開始されない場合にのみ指定できます。詳細は、18.4.1項「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。
タスク・フロー・リターン・アクティビティをバインド・タスク・フローに追加するには:
コンポーネント・パレットの「ADFタスク・フロー」ページからバインド・タスク・フローのダイアグラムに、タスク・フロー・リターン・アクティビティをドラッグします。
タスク・フロー・ダイアグラムで、タスク・フロー・リターン・アクティビティを選択します。
「プロパティ・インスペクタ」の「共通」ページで、「結果」セクションを展開します。
「名前」フィールドに結果を入力します(例: preferredCustomer
)。
これを指定することで、バインド・タスク・フローの終了時にコール元に結果が戻されるようになります。タスク・フロー・リターン・アクティビティごとに1つのみ結果を指定できます。コール元のタスク・フローには、戻された時点の制御フローを処理する制御フロー・ルールを定義する必要があります。詳細は、14.3.3項「制御フローの追加方法」を参照してください。
プロパティ・インスペクタで「動作」セクションを展開します。
「再入力」ドロップダウン・リストから、次のオプションのいずれかを選択します。
reentry-allowed: バインド・タスク・フロー内の任意のビュー・アクティビティについて再開が許可されます。
reentry-not-allowed: バインド・タスク・フローの再開は許可されません。
バインド・タスク・フローにreentry-not-allowedを指定しても、エンド・ユーザーはブラウザの「戻る」ボタンをクリックするとバインド・タスク・フロー内のページに戻れます。ただし、ユーザーがそのページでボタンのクリックなどなんらかの操作を行うと、バインド・タスク・フローを不正に再開したことを示す例外(InvalidTaskFlowReentry
など)がスローされます。実際の再開の条件は再開したページの送信時に識別されます。
この選択により、エンド・ユーザーがブラウザの「戻る」ボタンをクリックして、バインド・タスク・フローを再度開始したときのデフォルトの動作を定義します。この選択は、タスク・フロー・リターン・アクティビティがあるバインド・タスク・フローにreentry-outcome-dependentが設定されている場合にのみ適用されます。詳細は、18.5項「バインド・タスク・フローの再開」を参照してください。
「トランザクションの終了」ドロップダウン・リストから、次のいずれかのオプションを選択します。
commit: 選択すると、既存のトランザクションをデータベースにコミットします。
rollback: 選択したトランザクションをコール先のタスク・フローの以前のエントリまでロールバックします。これを指定すると、新しいトランザクションはバインド・タスク・フローに入って開始された当初の状態までロールバックされるため、トランザクションを取り消すのと同じ効果があります。
commitとrollbackのいずれも指定しないと、トランザクションはコール元のバインド・タスク・フローによって閉じられるまで開いたままになります。
In the R「セーブポイントのリストア」ドロップダウン・リストで、次のいずれかの条件に一致した場合に、trueを選択します。
タスク・フロー・リターン・アクティビティがあるバインド・タスク・フロー上で、「常に新規トランザクションを開始」(new-transaction
)が選択されていない場合があります。
バインド・タスク・フロー内で行われたADFモデル変更を、フロー終了時にタスク・フロー・コール・アクティビティを使用して破棄する必要がある場合。トランザクションは、バインド・タスク・フローの開始時に作成されているセーブポイントまでロールバックされます。
詳細は、18.4.1項「バインド・タスク・フローでトランザクションを有効化する方法」を参照してください。
セーブポイント・リストア・アクティビティを使用すると、後で使用するための保存の機能がサポートされているアプリケーションで、以前の永続的なセーブポイントをリストアできます。セーブポイントでは、特定のインスタンスでFusion Webアプリケーションのスナップショットが取得されます。セーブポイント・リストア機能を使用すると、セーブポイントが最初に作成されたときに取得された状態までアプリケーションをリストアできます。
セーブポイントがリストアされると、ADFコントローラで保存されたアプリケーションが終了し、エンド・ユーザーが保存を実施したときに実行されていたアプリケーションが再起動されます。アプリケーションでエンド・ユーザーが最初にいた場所が表示されます。ave-point-id
は一度リストアされると、その永続メソッド(データベースまたはJavaオブジェクト・キャッシュ)から削除されます。
セーブポイント・リストア・アクティビティは、後で使用するための保存の機能がサポートされている個々のアプリケーションすべてに必要なわけではありません。以前の永続的なsave-point-ids
をリストアするアプリケーション内でのみ必要です。たとえば、経費報告書作成アプリケーションではセーブポイント・リストア・アクティビティは必要ありませんが、以前に保存された経費報告書を今後更新するように選択する場合に使用されるアプリケーションでは必要となります。
タスク・フロー内で後で使用するための保存の機能を有効化する方法の詳細、および保存されたアプリケーションの状態およびデータをセーブポイント・リストア・アクティビティを使用して取得する方法の例は、18.9項「タスク・フローでのセーブポイントの使用」で説明しています。
ADFリージョンで実行するバインド・タスク・フローでは、親ビュー・アクティビティのナビゲーションのトリガーが必要な場合があります。親アクション・アクティビティにより、バインド・タスク・フローでその親のビュー・アクティビティに渡される結果を生成できるようになります。この結果を使用して、ADFリージョンのタスク・フローではなく、親ビュー・アクティビティを含むタスク・フローに移動します。
parent-outcome: 親アクション・アクティビティが定義されているリージョンのタスク・フローではなく、包含ビューのタスク・フローに移動するために、親ビュー・ポートに渡される値を指定します。
outcome: 親結果が親のキューに入れられた後に、リージョン内に制御フローの結果を指定します。
これは、リージョンによって送信されたparent-outcomeの結果として親が移動せず、続けて同じビューをリージョンに表示しない場合に便利です。結果の値を指定しない場合は、リージョンのviewId
は変化しません。
詳細は、17.7.1,項「ADFリージョンのタスク・フロー外でのナビゲーションのトリガー方法」を参照してください。
ページ定義ファイルは、実行時にデータを移入するバインディング・オブジェクトを定義します。通常、Fusion Webアプリケーションで、UIコンポーネントとデータ・コントロールをバインドするために使用されます。いくつかのタスク・フロー・アクティビティでも、ページ定義を使用してデータ・コントロールへのバインドが可能です。これらのオプションは次のとおりです。
メソッド・コール
「データ・コントロール」パネルからタスク・フローにデータ・コントロール操作をドラッグ・アンド・ドロップして、メソッド・コール・アクティビティを作成するか、既存のメソッド・コール・アクティビティにドロップすることができます。いずれの場合も、メソッド・コール・アクティビティが、データ・コントロール操作にバインドされます。
ルーター
ルーター・アクティビティにページ定義ファイルを関連付けることで、バインド・コンテナが作成されます。このバインド・コンテナは実行時にルーター・アクティビティ・ケースのEL式を評価し、ルーター・アクティビティが正しいバインド値を参照していることを確認します。各ルーター・アクティビティ・ケースは、EL式の評価結果がtrue
かどうかを、outcome
に戻すように指定します。そのため、ページ定義ファイルには、true
またはfalse
の評価結果となるデータ・コントロール操作だけを追加します。
タスク・フロー・コール
タスク・フロー・コール・アクティビティにページ定義ファイルを関連付けることで、バインド・コンテナが作成されます。実行時にタスク・フロー・コール・アクティビティから入力パラメータが渡されると、バインド・コンテナが起動します。バインド・コンテナはタスク・コール元のタスク・フローからコール先のタスク・フローに入力パラメータが渡される際に、フロー・コール・アクティビティがバインド値を参照する場合は、正しい値を参照していることを確認します。
ビュー
ビュー・アクティビティをページ定義ファイルに直接関連付けることはできません。かわりに、ビュー・アクティビティが参照するページを関連付けます。
タスク・フローのダイアグラマ内で、上記のタスク・フロー・アクティビティ(ビュー・アクティビティを除く)のいずれかを右クリックすると、JDeveloperがコンテキスト・メニューにオプションを表示します(「ページ定義の作成」) 。ページ定義ファイルが作成されていない場合は、このオプションを使用して作成できます。ページ定義ファイルがある場合は、JDeveloperはページ定義ファイルに移動するためのすべてのタスク・フロー・アクティビティのコンテキスト・メニュー・オプション(「ページ定義に移動」)を表示します。ページ定義ファイルに関連付けられたメソッド・コール・アクティビティを右クリックして、JDeveloperでコンテキスト・メニュー・オプション(「バインディングの編集」)を表示することもできます。
ページ定義ファイルに関連付けられたタスク・フロー・アクティビティでは、タスク・フロー・アクティビティ・アイコンの右下にアイコンが表示されます。図15-12は、各タスク・フロー・アクティビティの例を示しています。
JDeveloperにはタスク・フロー・アクティビティからアクセスできるコンテキスト・メニュー・オプションがあります。このコンテキスト・メニュー・オプションを使用して、タスク・フロー・アクティビティをページ定義ファイルに関連付けます。
タスク・フロー・アクティビティにページ定義ファイルを関連付ける手順
タスク・フローのダイアグラマで、ページ定義ファイルを作成するタスク・フロー・アクティビティを右クリックします。
表示されるコンテキスト・メニューから、「ページ定義の作成」を選択します。
作成されたページ定義ファイルに、タスク・フロー・アクティビティの実行時に参照させたいバインドを追加します。
ページ定義ファイルの詳細は、12.6項「ページ定義ファイルでの作業」を参照してください。
設計時に、JDeveloperはタスク・フロー・アクティビティのページ定義ファイルを生成します。ページ定義ファイルのファイル名は、元のタスク・フローおよびタスク・フロー・アクティビティまたは起動するデータ・コントロール操作から構成されます。たとえば、taskflowName_taskflowName_methodCall1PageDef.xml
またはtaskflowName_taskflowName_CreateInsertPageDef.xml
のような名前が付けられます。
JDeveloperは作成されたページ定義ファイル内で、タスク・フロー・アクティビティからバインドへのEL式も生成します。例15-16に、CreateInsert
アクション・バインドを参照するメソッド・コール・アクティビティを示します。
例15-16 アクション・バインドを参照するタスク・フロー・アクティビティ
<method-call id="CreateInsert"> <method>#{bindings.CreateInsert.execute}</method> <outcome> <fixed-outcome>CreateInsert</fixed-outcome> </outcome> </method-call>
実行時にバインド・コンテナは、タスク・フロー・アクティビティのEL式が正しい値を参照していることを確認します。