| Oracle Fusion Middleware Oracle SOA Suite開発者ガイド 11g リリース1（11.1.1） B56238-01 |
|
 戻る |
 次へ |
この章では、ヒューマン・タスクの設計方法について説明します。 ヒューマン・タスク・エディタを使用して、タスク・メタデータ、ルーティングおよび割当てポリシー、エスカレーション・ポリシー、有効期限ポリシーおよび通知設定をモデリングする方法を示します。
項目は次のとおりです。
ヒューマン・タスク・エディタを使用するには、次の内容も含めてヒューマン・タスクの設計概念を理解する必要があります。
タスクを割り当てるユーザーのタイプ
ユーザーをタスクに割り当てる方法（静的、動的またはルールベース）
ユーザーを割り当てるタスクのモデリングに使用可能なタスクの参加者タイプ
タスク参加者のリストを作成するためのオプション
タスクのライフ・サイクル全体に関与する参加者
ヒューマン・タスクの概念の詳細は、第24章「ヒューマン・ワークフローの開始」を参照してください。
Oracle SOA Suiteには、タスク・メタデータをモデリングするための、ヒューマン・タスク・エディタと呼ばれるグラフィカル・ツールが用意されています。 モデリング・プロセスは、次のタスクで構成されています。
SOAコンポジット・エディタでのヒューマン・タスク・サービス・コンポーネントの作成とモデリング
BPELプロセスとの関連付け
実行時にOracle BPM Worklistにヒューマン・タスクを表示するためのタスク・フォームの生成
この項では、これらのモデリング・タスクの概要について説明し、特定のモデリング手順の参照先を示します。
SOAコンポジット・エディタの使用方法の詳細は、第4章「SOAコンポジット・エディタの機能の概要」を参照してください。
使用可能なサンプルの詳細は、第24.3.2項「ヒューマン・タスク全体の設計」を参照してください。
ヒューマン・タスクのメタデータは、次の2つのいずれかの方法で定義します。
ヒューマン・タスクを「コンポーネント・パレット」からBPELプロセスにドラッグし、自動的に表示される「ヒューマン・タスクの作成」ダイアログで「追加」アイコンをクリックする方法。 この操作で、ヒューマン・タスク・サービス・コンポーネントを作成するためのダイアログが表示されます。 作成を完了すると、ヒューマン・タスク・エディタが表示されます。
ヒューマン・タスク・サービス・コンポーネントを「コンポーネント・パレット」からSOAコンポジット・エディタにドラッグする方法。 この操作で、ヒューマン・タスク・コンポーネントを作成するためのダイアログが表示されます。 作成を完了すると、ヒューマン・タスク・エディタが表示されます。
ヒューマン・タスク・エディタでは、ヒューマン・タスク・メタデータ（タスクの結果、ペイロード構造、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できます。この情報は、メタデータ・タスク構成ファイル（拡張子.task）に保存されます。 また、ワークフロー・パターンによっては、Oracle Business Rulesデザイナを使用して、タスクのルーティング・ポリシーまたは承認者のリストを定義する必要があります。
詳細は、第25.3項「ヒューマン・タスク・エディタでのヒューマン・タスク定義の作成」を参照してください。
ヒューマン・タスク設定を構成する.taskファイルは、Oracle BPELデザイナで、BPELプロセスに関連付けることができます。 図25-1に示すように、構成のためにBPELプロセス・フローにドラッグしたヒューマン・タスクとの関連が作成されます。
タスク定義、タスク起案者、タスク優先度、およびBPEL変数に入力データを渡すタスク・パラメータ・マッピングも指定します。さらに、拡張機能も定義できます。たとえば、スコープとグローバル・タスク変数名（デフォルト名をそのまま使用しない場合）、タスク所有者、識別キー、BPELコールバックのカスタマイズ、およびヒューマン・タスクを拡張して他のワークフロー・タスクを追加するかどうかなどです。
関連付けが完了すると、タスク・サービス・パートナ・リンクが作成されます。タスク・サービスでは、タスクの操作に必要な操作が公開されます。
SOAコンポジット・エディタでは、BPELプロセスに関連付けないスタンドアロン・コンポーネントとしてのヒューマン・タスクを作成することもできます。スタンドアロン・ヒューマン・タスク・サービス・コンポーネントは、アプリケーションで自動化されたアクティビティが必要のない環境で役に立ちます。スタンドアロンの場合、クライアントは自分でタスクを作成できます。
詳細は、第25.4項「ヒューマン・タスク・サービス・コンポーネントとBPELプロセスの関連付け」を参照してください。
タスク表示フォームは、Oracle Application Development Framework（ADF）を使用して生成できます。 このフォームは、実行時にOracle BPM Worklistで操作するタスクの詳細を表示するために使用されます。
タスク表示フォームの生成の詳細は、第26章「ヒューマン・タスク用のタスク表示フォームの設計」を参照してください。
ヒューマン・タスク・エディタを使用すると、タスクのメタデータを定義できます。エディタでは、ヒューマン・タスク設定（タスクの結果、ペイロード構造、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できます。
ヒューマン・タスク・サービス・コンポーネントは、SOAコンポジット・エディタまたはOracle BPELデザイナで作成します。作成後に、ヒューマン・タスク・エディタでコンポーネントを設計します。ヒューマン・タスク・サービス・コンポーネントを作成する方法によって、後でそのコンポーネントをBPELプロセス・サービス・コンポーネントに関連付けるのか、SOAコンポジット・エディタでスタンドアロン・コンポーネントとして存在するのかが決まります。
SOAコンポジット・エディタでヒューマン・タスク・サービス・コンポーネントを作成する手順は、次のとおりです。
SOAコンポジット・エディタでヒューマン・タスク・サービス・コンポーネントを作成するSOAプロジェクトに進みます。
「コンポーネント・パレット」から「SOA」を選択します。
リストからデザイナに「Human Task」をドラッグします。
「ヒューマン・タスクの作成」ダイアログが表示されます。
「名前」フィールドに、名前を入力します。
入力した名前は、.taskファイル名として追加されます。
「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスに注目します。 このチェック・ボックスの選択により、ヒューマン・タスク・サービス・コンポーネントの作成方法が決まります。
BPELプロセス・サービス・コンポーネントに関連付けるヒューマン・タスク・サービス・コンポーネントを後で作成する場合は、「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスを選択しないでください。ヒューマン・タスク・サービス・コンポーネントは、BPELプロセス・サービス・コンポーネントと明示的に関連付けるコンポーネントとして作成されます。 図25-2に詳細を示します。
ヒューマン・タスク・サービス・コンポーネントをSOAコンポジット・エディタでスタンドアロン・コンポーネントとして作成する場合は、「SOAPバインディングを持つコンポジット・サービスの作成」チェック・ボックスを選択します。 これにより、Simple Object Access Protocol（SOAP）Webサービスと自動的に接続されるヒューマン・タスク・サービス・コンポーネントが作成されます。 図25-3に詳細を示します。
このWebサービスは、外部の顧客に、SOAコンポジット・アプリケーションのヒューマン・タスク・サービス・コンポーネントへのエントリ・ポイントを提供します。
「終了」をクリックします。
Oracle BPELデザイナでヒューマン・タスクを作成する手順は、次のとおりです。
「コンポーネント・パレット」から「BPEL」を選択します。
リストからデザイナに「Human Task」をドラッグします。
「ヒューマン・タスクの作成」ダイアログが表示されます。
「追加」アイコンをクリックして、ヒューマン・タスクを作成します。
「名前」フィールドに、名前を入力します。
入力した名前は、.taskファイル名として追加されます。
「タイトル」フィールドに、タスクを入力します。
「OK」をクリックします。
ヒューマン・タスク・エディタが表示されます。
|
注意: 後でBPELプロセスに関連付けるヒューマン・タスクを作成する場合は、「ファイル」メイン・メニューから「新規」を選択し、「SOA層」→「サービス・コンポーネント」→「ヒューマン・タスク」の順に選択する方法もあります。 |
SOAコンポジット・エディタでのヒューマン・タスク・サービス・コンポーネントの作成方法の詳細は、第4章「SOAコンポジット・エディタの機能の概要」を参照してください。
ヒューマン・タスクが作成されると、次のフォルダとファイルが表示されます。
ヒューマン・タスク・エディタで指定したヒューマン・タスク設定が、メタデータ・サービス（MDS）リポジトリのメタデータ・タスク構成ファイル（拡張子.task）に保存されます。このファイルは、「アプリケーション・ナビゲータ」の「SOA_Project_Name」→ 「SOAコンテンツ」の下に表示されます。次をダブルクリックすると、このファイル内の設定を再編集できます。
SOAコンポジット・エディタまたはOracle BPELデザイナの「アプリケーション・ナビゲータ」にある.taskファイル
SOAコンポジット・エディタ、またはOracle BPELデザイナのBPELプロセスにある「ヒューマン・タスク」アイコン
作成したヒューマン・タスクを含むヒューマン・タスク・フォルダは、SOAコンポジット・エディタの「構造」ウィンドウに表示されます。
図25-4に、これらのフォルダとファイルを示します。
使用可能なサンプルの詳細は、第24.3.2項「ヒューマン・タスク全体の設計」を参照してください。
ヒューマン・タスク・エディタのセクションにアクセスする手順は、次のとおりです。
SOAコンポジット・エディタの「ヒューマン・タスク」アイコンをダブルクリックするか、Oracle BPELデザイナの「ヒューマン・タスク」アイコンをダブルクリックして、右上隅にある「編集」アイコンをクリックします。
ヒューマン・タスク・エディタは、図25-5に示す主要なセクションで構成されています。 これらのセクションを使用すると、ヒューマン・タスクのメタデータを設計できます。
表25-1に、ヒューマン・タスク・エディタのこれらの主要なセクションを使用してワークフロー・タスクを作成する方法を示します。
表25-1 ヒューマン・タスク・エディタ
| セクション | 説明 | 参照先 |
|---|---|---|
|
タスクのタイトル （「タイトル」、「説明」、「結果」、「カテゴリ」、「優先度」および「所有者」） |
タスクの詳細（タイトル、タスクの結果、所有者、その他の属性など）を定義できます。 |
第25.3.4項「タイトル、説明、結果、優先度、カテゴリおよび所有者の指定方法」 |
|
パラメータ |
タスク・ペイロード（タスクのデータ）の構造（メッセージ要素）を定義できます。 |
第25.3.5項「タスク・ペイロード・データ構造の指定方法」 |
|
割当ておよびルーティング・ポリシー |
参加者をタスクに割り当て、そのタスクをワークフローを使用してルーティングするためのポリシーを作成できます。 |
|
|
有効期限およびエスカレーション・ポリシー |
タスクの有効期間を指定できます。 |
第25.3.8項「タスクのエスカレート、期限更新または終了方法」 |
|
通知設定 |
ユーザーにタスクが割り当てられたとき、またはタスクのステータスが変化したときの通知を作成して送信できます。 |
|
|
詳細設定 次を指定します。 |
次のような詳細設定を指定できます。
|
|
|
注釈 |
タスク定義の様々な属性にラベル付けができます。 注釈はOracle Business Process Analysisで使用されます。 |
|
図25-6に、ヒューマン・タスク・エディタの「タスクのタイトル」セクションを示します。
このセクションでは、タスクのタイトル、説明、結果、カテゴリ、優先度、所有者などの詳細を指定できます。
表25-2に、「タスクのタイトル」セクションの各サブセクションの構成方法を示します。
タスクのタイトルを指定する手順は、次のとおりです。
タスクのタイトルを入力します（オプション）。 開始したタスクにタイトルが設定されていない場合のみ、この値がタイトルにデフォルト設定されます。 このタイトルによって、タスクが視覚的に識別されます。 タスクのタイトルはOracle BPM Worklistに表示されます。 タイトルは、Oracle BPM Worklistで検索することもできます。
タスクのタイトルの指定方法を選択します。
プレーン・テキスト: 名前（承認された休暇申請など）を手動で入力します。
テキストとXPath: 手動によるテキストと動的な式の組合せを入力します。 タイトルの一部（注文IDに必要な承認:など）を手動で入力した後、テキストの右側の空白にカーソルを置き、このフィールドの右側にあるアイコンをクリックします。 この操作によって、タイトルの残りの部分を動的に作成するための式ビルダーが表示されます。 名前の動的部分を完成した後は、「OK」をクリックし、このフィールドに戻ります。 完全な名前が表示されます。次に例を示します。
注文IDに必要な承認: <%/task:task/task:payload/task:orderId%>
式は、実行時にタスク・ペイロードからの正確な注文ID値を使用して解決されます。
第25.4.3.1項「タスクのタイトルの指定」の説明に従って、「ヒューマン・タスクの作成」ダイアログの「一般」タブで「タスクのタイトル」フィールドにタイトルを入力すると、ここで入力したタイトルは上書きされます。
必要に応じて、「説明」フィールドにタスクの説明を指定できます。 説明を使用すると、タスクに関する補足的な詳細を提供できます。 たとえば、タスクのタイトルがコンピュータのアップグレード・リクエストの場合、このフィールドには、コンピュータのモデル、CPUの能力、RAM容量などの補足的な詳細を記載できます。 この説明は、Oracle BPM Worklistには表示されません。
タスクの結果により、タスクに可能な結果が取得されます。 Oracle BPM Worklistには、ここで指定した結果が実行時に実行可能なタスク・アクションとして表示されます。 図25-7に詳細を示します。
次のタイプのタスクの結果を指定できます。
シード済結果の選択
カスタム結果の入力
タスクの結果には、ここで指定した実際の結果値とは異なる実行時の表示値を割り当てることもできます。 これにより、Oracle BPM Worklistでは、結果を異なる言語で表示できます。 国際化の詳細は、第25.3.10.4項「多言語設定の指定」を参照してください。
タスクの結果を指定する手順は、次のとおりです。
「タスクのタイトル」セクションの「結果」フィールドの右側にある「検索」アイコンをクリックします。
タスクに予想される結果が「結果ダイアログ」（図25-8を参照）に表示されます。「APPROVE」および「REJECT」はデフォルトで選択されています。
さらにタスクの結果を選択するか、デフォルトの結果の選択を解除します。
カスタム結果を追加するには、「追加」アイコンをクリックします。
「名前」フィールドにカスタム名を入力し、「OK」をクリックします。
|
注意: 「タスク・コンテンツ・アクセスの設定」ダイアログの「タスク・アクション」タブにリストされている名前と一致するカスタム名は指定しないでください（たとえば、削除を指定しないでください）。 「タスク・コンテンツ・アクセスの設定」ダイアログにアクセスするには、ヒューマン・タスク・エディタの「詳細設定」セクションにある「表示の構成」をクリックします。 同じ名前を指定すると、実行時に問題が発生する可能性があります。 |
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「結果」フィールドに表示されます。
ここで選択したシード済結果とカスタム結果が、パラレル参加者タイプの「多数決の結果」セクションに表示され、選択できます。
詳細は、第25.3.6.2.1項「投票結果の指定」を参照してください。
タスク・カテゴリは、必要に応じて、「カテゴリ」フィールドに指定できます。この指定によって、システムで作成されるタスクのカテゴリが決まります。 たとえば、ヘルプ・デスク環境では、顧客のリクエストをソフトウェア関連またはハードウェア関連として分類できます。 カテゴリはOracle BPM Worklistに表示されます。 カテゴリに基づいてタスクをフィルタ処理し、Oracle BPM Worklistでカテゴリのビューを作成できます。
タスク・カテゴリを指定する手順は、次のとおりです。
タスク・カテゴリの指定方法を選択します。
名前別: 名前を手動で入力します。
式別: このフィールドの右側にあるアイコンをクリックし、カテゴリを動的に作成するための式ビルダーを表示します。
タスクの優先度を指定します。優先度は、1から5までで、1が最高値です。タスクの優先度は、デフォルトで3に設定されています。 この優先度値は、「ヒューマン・タスクの作成」ダイアログの「一般」タブで優先度値を選択すると上書きされます。 優先度に基づいてタスクをフィルタ処理し、Oracle BPM Worklistで優先度のビューを作成できます。
タスク優先度を指定する手順は、次のとおりです。
「優先度」リストから、タスクの優先度を選択します。
「ヒューマン・タスクの作成」ダイアログでの優先度値の指定方法の詳細は、第25.4.3.2項「タスク起案者とタスク優先度の指定」を参照してください。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、割当て済タスクの参加者タイプのいずれかにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。 タスク所有者は、タスクのビジネス管理者と見なすことができます。 また、タスク所有者は、第25.4.4.2項「タスク所有者の指定」の説明に従って、「ヒューマン・タスクの作成」ダイアログの「詳細」タブでを指定することもできます。ここに入力したタスク所有者は、「詳細」タブで指定したタスク所有者によって上書きされます。
タスク所有者の詳細は、第24.2.1.3項「タスクのステークホルダ」を参照してください。
タスク所有者を指定する手順は、次のとおりです。
タスク所有者の指定方法を選択します。
アイデンティティ・サービスのユーザー・ディレクトリまたはアプリケーション・ロールのリストを介して静的に指定
XPath式を介して動的に指定
次に例を示します。
タスクに、ownerが格納されているpoという名前のペイロード・メッセージ属性がある場合は、/task:task/task:payload/po:purchaseOrder/po:ownerなどのXPath式を指定できます。
ids:getManager('jstein', 'jazn.com')
jsteinのマネージャがタスク所有者です。
ユーザー、グループおよびアプリケーション・ロールの詳細は、第24.2.1.1.3項「参加者の割当て」を参照してください。
タスク所有者は、Oracle SOA Suiteで使用するように構成されたユーザー・ディレクトリ（Oracle Internet Directory、Java AuthoriZatioN（JAZN）/XML、LDAPなど）またはアプリケーション・ロールのリストを参照することで選択できます。
ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介してタスク所有者を静的に指定する手順は、次のとおりです。
「タスクのタイトル」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。 図25-9に詳細を示します。
図25-9 ユーザー・ディレクトリまたはアプリケーション・ロールの参照によるタスク所有者の指定
「タスクのタイトル」セクションの「所有者」フィールドの右側にある2番目のリストで、「静的」を選択します。
選択した所有者のタイプに基づいて、表25-3の手順を参照してください。
「ユーザー」または「グループ」を選択した場合は、図25-10に示す「アイデンティティ・ルックアップ」ダイアログが表示されます。
ユーザーまたはグループを選択するには、最初にアプリケーション・サーバー接続を作成する必要があります。そのためには「追加」アイコンをクリックします。次の制限に注意してください。
アイデンティティ・サービス・レルムのリストを取得するOracle WebLogic管理サーバーに対して、アプリケーション・サーバー接続を作成しないでください。 これは、この管理サーバーには、実行するアイデンティティ・サービスがないためです。 したがって、「アイデンティティ・ルックアップ」ダイアログで検索パターンを使用して検索を実行した場合は、レルム情報もユーザーも表示されません。 かわりに、管理対象のOracle WebLogic Serverに対してアプリケーション・サーバー接続を作成してください。
完全なドメイン名（myhost.us.oracle.comなど）を使用して構成されているアプリケーション・サーバー接続を選択する必要があります。 ホスト名（myhostなど）のみで構成されている接続を選択すると、使用可能なレルムが「レルム」リストに表示されない可能性があります。 既存の接続にドメイン名が含まれていない場合は、次の手順を実行します。
「リソース・パレット」で、アプリケーション・サーバー接続を右クリックします。
「プロパティ」を選択します。
「構成」タブで、適切なドメインをホスト名に追加します。
「アイデンティティ・ルックアップ」ダイアログに戻り、接続を再度選択します。
アプリケーション・サーバー接続を選択または作成し、選択用のレルムを表示します。 レルムには、ユーザーおよびロール（グループ）のポリシー・ストアへのアクセスが用意されています。
検索文字列（jcooper、j*、*など）を入力して所有者を検索します。 「ユーザー名」フィールドの右側にある「ルックアップ」アイコンをクリックすると、検索基準と一致するすべてのユーザーがフェッチされます。 図25-11に詳細を示します。「選択」をクリックすると、1つ以上のユーザーまたはグループをハイライトして選択できます。
ユーザーをハイライトして「階層」をクリックし、そのユーザーの階層を表示します。同様に、「報告先」をクリックすると、選択したユーザーまたはグループの報告先が表示されます。 図25-12に詳細を示します。
ユーザーまたはグループをハイライトして「詳細」をクリックし、そのユーザーまたはグループの詳細を表示します。 図25-13に詳細を示します。
「OK」をクリックして「アイデンティティ・ルックアップ」ダイアログに戻ります。
「選択」をクリックして、ユーザーを「選択したユーザー」セクションに追加します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
「アプリケーション・ロール」を選択した場合は、「アプリケーション・ロールの選択」ダイアログが表示されます。
「アプリケーション・サーバー」リストで、アプリケーション・ロールが設定されているアプリケーション・サーバーのタイプを選択するか、「追加」アイコンをクリックして接続を作成するためのアプリケーション・サーバー接続の作成ウィザードを起動します。
「アプリケーション」リストで、アプリケーション・ロールが設定されているアプリケーションを選択します（カスタム・アプリケーションまたはSOAインフラストラクチャ・アプリケーション（soa-infra）など）。
「選択可能」セクションで、適切なアプリケーション・ロールを選択し、「>」ボタンをクリックします。 すべてを選択するには、「>>」ボタンをクリックします。 図25-14に詳細を示します。
「OK」をクリックします。
タスク所有者を「式ビルダー」ダイアログで動的に選択できます。
タスク所有者を動的に指定する手順は、次のとおりです。
「タスクのタイトル」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。 図25-15に詳細を示します。
「タスクのタイトル」セクションの「所有者」フィールドの右側にある2番目のリストで、「XPath」を選択します。
図25-16に示す「式ビルダー」ダイアログが表示されます。
使用可能な変数のスキーマおよび関数を参照してタスク所有者を作成します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
詳細は、次を参照してください。
「式ビルダー」ダイアログとXPathビルディング・アシスタントの使用手順については、「ヘルプ」をクリックしてください。
ワークフロー・サービスのDynamic Assignment Functionおよびアイデンティティ・サービス関数の詳細は、付録B「XPath拡張関数」を参照してください。
図25-17に、ヒューマン・タスク・エディタの「パラメータ」セクションを示します。
このセクションでは、XSDファイルに定義されているタスク・ペイロード（タスクのデータ）の構造（メッセージ要素）を指定できます。 XSDファイルの要素を表すパラメータを作成します。 これにより、ペイロード・データがワークフロー・タスクで使用できるようになります。次に例を示します。
ストアフロント・アプリケーションから注文するための注文ID要素に対してパラメータを作成します。
ヘルプ・デスク・リクエストを作成するための場所、タイプ、問題の説明、重大度、ステータスおよび解決の各要素に対してパラメータを作成します。
タスク・ペイロード・データは、1つ以上の要素またはタイプで構成されます。選択内容に基づいてタスク・ペイロードのXMLスキーマ定義が作成されます。
タスク・ペイロード・データ構造を指定する手順は、次のとおりです。
「パラメータ」セクションで、「追加」アイコンをクリックして「タスク・パラメータの追加」ダイアログ（図25-18を参照）を表示します。
表25-4に記載されている詳細を入力します。
表25-4 「タスク・パラメータの追加」ダイアログのフィールドと値
| フィールド | 説明 |
|---|---|
|
パラメータ・タイプ |
「タイプ」または「要素」を選択し、「検索」アイコンをクリックすると、タスク・パラメータ選択用の「タイプ・チューザ」ダイアログが表示されます。 |
|
パラメータ名 |
デフォルト名をそのまま使用するか、カスタムの名前を入力します。このフィールドが表示されるのは、パラメータ・タイプとして「タイプ」を選択した場合のみです。 |
|
ワークリストにより編集可能 |
このチェック・ボックスを選択すると、タスク・ペイロードのこの部分をOracle BPM Worklistで編集できます。 たとえば、融資承認タスクの場合、APR属性は、タスクをレビューするユーザーによる更新が必要な場合がありますが、SSNフィールドは編集できません。 参加者が表示および更新できるタスクの部分を決定するアクセス・ルールも指定できます。 詳細は、第25.3.10.8項「タスク・コンテンツへのアクセス・ポリシーの指定」を参照してください。 |
|
注意: Oracle BPM Worklistで定義できるのは、単純なXMLタイプ（文字列、整数など）または複雑なタイプ（注文書など）のペイロード・パラメータに対するペイロード・フレックス・フィールド・マッピングのみです。 キーワードを使用してタスクを検索する必要がある場合、またはタスク・コンテンツに基づいてビューまたは委任ルールを定義する必要がある場合は、単純なXMLタイプに基づいたペイロード・パラメータを使用する必要があります。 これらの単純タイプは、Oracle BPM Worklistでフレックス列にマップできます。 |
図25-19に示すように、タイプを選択します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「パラメータ」セクションに表示されます。
選択内容を編集する場合は、対象項目を選択して「パラメータ」セクションの右上にある「編集」アイコンをクリックします。
図25-20に、ヒューマン・タスク・エディタの「割当ておよびルーティング・ポリシー」セクションを示します。このセクションでは、ビジネス要件を満たす参加者タイプを選択できます。 参加者タイプを構成するときは、タスクを操作するユーザー、グループおよびアプリケーション・ロールのリストを作成します。
図25-20 ヒューマン・タスク・エディタ — 「割当ておよびルーティング・ポリシー」セクション
単純または複雑なワークフロー・ルーティング・ポリシーを作成するためには、参加者タイプを簡単に組み合せて調整できます。 以前に構成したヒューマン・タスクの機能を拡張して、より複雑なワークフローをモデリングすることもできます。
参加者タイプはステージの下のブロックにグループ化されます（たとえば、図25-20ではdefault.Participant1という名前です）。 ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。 1つ以上のステージを順番に、またはパラレルで指定できます。 各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。 参加者タイプ・ブロックの順序は、[↑]キーと[↓]キーを使用して再配置できます。
次に例を示します。
すべての参加者タイプ・ブロックを単一のステージに作成できます（たとえば、注文のすべての内容が全体として承認または却下される注文書リクエスト）。
より複雑な承認タスクを作成して、1つ以上のステージを含めることができます。 たとえば、最初のステージに参加者タイプ・ブロックのグループを配置し、2番目のステージに他のブロックを配置できます。 第1ステージに配置した参加者のリストでは明細入力の承認が処理され、第2ステージに配置した参加者のリストではヘッダー入力の承認が処理されます。
参加者タイプごとに、構成タスクに使用するエディタが関連付けられています。割当て先の追加順序は、実行順序を示します。
別のステージ名を指定する場合、または追加ステージの作成が必要なビジネス要件を指定する場合は、次の手順を実行します。 追加ステージの作成は高度な要件で、自社の環境には必要がない場合があります。
参加者タイプの詳細は、第24.2.1.1項「タスクの割当ておよびルーティング」を参照してください。
ステージ名を指定し、パラレルおよび順次ブロックを追加する手順は、次のとおりです。
デフォルトでは、ステージに「default」という名前が指定されます。 この名前は、必要に応じて変更できます。
名前をダブルクリックします。
図25-21に示す「編集」ダイアログが表示されます。
名前を入力し、「OK」をクリックします。
ステージとその参加者タイプ・ブロックをハイライト表示し、「追加」アイコンをクリックします。 図25-23に、表示されるリストを示します。
リストからオプションを選択します（たとえば、「パラレル・ステージ」）。
図25-23に示すように、第2ステージが第1ステージに対してパラレルに追加されます。
右側の第2ブロックをハイライト表示し、「追加」アイコンを選択します。
「順次ステージ」を選択します。
順次ステージが、選択したブロックの下に追加されます。
これらのブロック内に参加者タイプを作成します。
タスク参加者を割り当てる手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」セクションで、次のいずれかのタスクを実行します。
ステージ・ボックスの下のブロックをハイライト表示し、右上隅の「編集」アイコンをクリックします。 タスク参加者を初めて作成すると、このボックスには「<参加者なし>」のラベルが付きます。
または、
ステージ・ボックスの下の参加者ボックスをダブルクリックします。
「参加者タイプの編集」ダイアログが表示されます。 このダイアログでは、特定の参加者タイプを選択できます。
「タイプ」リストから、図25-25に示す参加者タイプを選択します。
選択内容に応じて、表25-5に示す項を参照してください。
図25-26に、単一参加者タイプの「参加者タイプの編集」ダイアログを示します。
単一参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル（Approval Manager、Primary Reviewersなど）は、タスク定義のすべての参加者の中で一意にする必要があります。
表25-6に、単一参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
表25-6 参加者タイプの編集 — 「単一」タイプ
| サブセクション | 参照先 |
|---|---|
|
参加者リスト |
|
|
割当て済期間の制限の設定（「詳細」セクション） |
第25.3.6.1.2項「タスクの操作に対する時間制限の指定」 |
|
この参加者による他の参加者の招待を許可（「詳細」セクション） |
|
|
スキップ・ルールの指定（「詳細」セクションの下） |
|
参加者のリストに割り当てられているユーザーは、タスクを操作できます。 このタイプの割当てリストでは、タスクの操作に必要なユーザーは1人のみです。 単一のユーザーか、このパターンのユーザー、グループまたはアプリケーション・ロールのリストを指定できます。 リストを指定した場合は、すべてのユーザーがタスクに割り当てられ、その中の1人がタスクを取得して操作する必要があります。 1人のユーザーがタスクを操作すると、そのタスクは、他の割当て先のタスク・リストから取り消されます。単一ユーザー参加者（およびパラレル、シリアル、FYIタイプのユーザー参加者）には、様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
これらのリストでは、ユーザー、グループまたはアプリケーション・ロールをタスク割当て先として静的または動的に選択できます。
値ベースの管理チェーンのリスト
管理チェーンは通常、管理チェーン階層内の複数のユーザーからシリアル承認を得るために使用されます。 したがって、このリストは多くの場合、シリアル参加者タイプに有効です。 通常は、階層内のすべてのユーザーがタスクを操作する場合に使用します。 管理チェーンは単一参加者タイプでも使用できます。 ただし、この場合は、階層内のすべてのユーザーにタスクが同時に割り当てられます。 1人のユーザーがタスクを操作すると、そのタスクは、他のユーザーから取り消されます。
たとえば、注文書がマネージャに割り当てられているとします。マネージャが承認した注文は、上位のマネージャに割り当てられます。そのマネージャが承認すると、さらに上位のマネージャに割り当てられ、3人のマネージャが注文を承認するまで上位へと順番にルーティングされます。 条件付き中途完了を指定した場合は、マネージャのいずれかがリクエストを却下するか、リクエストの期限が切れると、注文は却下されます。 それ以外の場合、タスク・フローは引き続きルーティングされます。
ルールベースの名前と式のリストおよび管理チェーンのリスト
ビジネス・ルールを使用すると、複雑な式でタスク参加者のリストを作成できます。 たとえば、5,000ドル未満の注文書リクエストは承認のためにマネージャに送信するというビジネス・ルールを作成します。 一方、5,000ドル以上の注文書リクエストは、承認のためにマネージャのマネージャに送信します。 ビジネス・ルールの2つの主要な機能は、ファクトとアクション・タイプです。詳細は、第25.3.7.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定」を参照してください。
参加者タイプを選択すると、図25-27に示すように、タスク参加者の割当て先（ユーザー、グループまたはアプリケーション・ロール）のリストを作成するためのオプションを選択できるダイアログが表示されます。 前述の3つの選択肢（「名前および式」、「管理チェーン」および「ルールベース」）を使用できます。
オプションを選択した後は、図25-28に示すように、タスク参加者割当て先（ユーザー、グループまたはアプリケーション・ロール）およびデータ型を動的に割り当てます。
この項では、これらの参加者リストの作成方法について説明します。
値ベースの名前と式で構成される参加者リストの作成
ユーザー、グループまたはアプリケーション・ロールをタスク参加者として静的または動的に割り当てる方法を選択します。
詳細は、次の各項を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、第24.2.1.1.3項「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、第24.2.1.2「静的、動的およびルールベースのタスク割当て」を参照してください。
値ベースの名前と式で構成される参加者リストを作成する手順は、次のとおりです。
「参加者のリストの作成で使用」リストから、「名前および式」を選択します。
「属性の指定で使用」リストから、「値ベース」を選択します。
ダイアログがリフレッシュされ、図25-29に示すように、フィールドが表示されます。
「追加」アイコンをクリックし、ユーザー、グループまたはアプリケーション・ロールをタスク参加者として選択します。
「参加者名」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。
「識別タイプ」列での選択を変更するには、その列をクリックしてドロップダウン・リストを表示します。
「データ型」列で、現在選択されている値をクリックし、値を割り当てるドロップダウン・リストを表示します。
名前別: 識別タイプがユーザーまたはグループの場合は、右側の「参照」アイコン（...）をクリックし、アイデンティティ・サービスを介して構成されたユーザーまたはグループを選択するためのダイアログを表示します。アイデンティティ・サービスを使用すると、ユーザー・プロパティ、ロールおよびグループ・メンバーシップのルックアップが可能になります。ユーザー情報は、Oracle Internet DirectoryなどのLDAPサーバーから取得します。IDの検索にはワイルドカード（*）を使用できます。
アプリケーション・ロールを選択する場合は、「参照」アイコンをクリックし、アプリケーション・ロールを選択するための「アプリケーション・ロールの選択」ダイアログを表示します。アプリケーション・ロールを検索するには、最初にアプリケーション・サーバーへの接続を作成する必要があります。 検索する際は、ロール名を見つけるためにアプリケーション名を指定する必要があります。タスク定義で参照できるのは、単一のアプリケーション名のみです。割当先またはタスク所有者は、異なるアプリケーションのアプリケーション・ロールを使用できません。
式別: ユーザー、グループまたはアプリケーション・ロールの識別タイプについて、「参照」アイコンをクリックし、「式ビルダー」ダイアログでタスク割当て先を動的に選択します。bpws:getVariableData(...)式またはids:getManager() XPath関数を使用します。
指定した値が「値」列に表示されます。
値を手動で入力する場合は、「値」列のフィールドをクリックし、値を指定します。
管理チェーン・パラメータをタスク参加者として静的または動的に割り当てる方法を選択します。
詳細は、次の各項を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、第24.2.1.1.3項「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、第24.2.1.2「静的、動的およびルールベースのタスク割当て」を参照してください。
管理チェーンについては、第25.3.6.1.1項「単一タスク参加者リストの作成」を参照してください。
値ベースの管理チェーンに基づいて参加者リストを指定する手順は、次のとおりです。
「参加者のリストの作成で使用」リストから、「管理チェーン」を選択します。
「属性の指定で使用」リストから、「値ベース」を選択します。
ダイアログがリフレッシュされ、図25-30に示すように、フィールドが表示されます。
「開始参加者」表のリストにユーザー、グループまたはアプリケーション・ロールを割り当てる方法は、手順3〜6を参照してください。
「最上位の参加者」リストで、タスク参加者のレベル数を割り当てる方法を選択します。
役職別: 管理チェーンの最終（最高）承認者の役職を選択します。
XPath: 「式ビルダー」ダイアログを介して最上位の参加者を動的に入力する場合に選択します。
「レベル数」リストで、最上位参加者を割り当てる方法を選択します。
番号別: このタスクに含める管理チェーンのレベル数の値を入力します。たとえば、2を入力して、タスクが最初にユーザーjcooperに割り当てられている場合は、ユーザーjstein（jcooperのマネージャ）とユーザーwfaulk（jsteinのマネージャ）の両方がリストに（最初の割当て先であるjcooperとは別に）含まれます。
XPath: 「式ビルダー」ダイアログを介して値を動的に入力する場合に選択します。
ルールセットは、ルールおよびデシジョン表の実行単位を提供します。また、ルールセットはルールの共有単位を提供します。ルールはルールセットに所属します。 複数のルールセットを順に実行できます。 これはルール・フローと呼ばれます。 順番はルールセット・スタックで決まります。 順番は、スタック上でルールセットをプッシュおよびポップするルール・アクションによって操作できます。 ルールセットでは、ルールの優先度を適用することで、ルールセット内でのルールの起動順序を指定します。また、ルールセットは有効日も指定します。この指定によって、ルールセットは常に有効か、日時の範囲、開始日時または終了日時に基づいて制限されるかが識別されます。
ルールセットの作成方法は、そのルールセットへのアクセス方法に基づいています。 これについては、次の項で説明しています。
ルールセットに基づいて参加者リストを指定する手順は、次のとおりです。
ビジネス・ルールによって、参加者リストを定義できます。 ビジネス・ルールの使用については、2つのオプションがあります。
ルールによって、特定のリスト・ビルダー（「名前および式」、「管理チェーン」など）のパラメータが定義されます。 この場合、タスク・ルーティング・パターンは、特定のリスト・ビルダーを使用するようにモデリングされます。 このリスト・ビルダーには、ルールで作成されたパラメータがリストされます。 ルールは、Oracle JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを返します。
「参加者のリストの作成で使用」リストから、「名前および式」または「管理チェーン」を選択します。
「属性の指定で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図25-31に詳細を示します。
「OK」をクリックします。
ルールによって、リスト・ビルダーおよびリスト・ビルダー・パラメータが定義されます。 この場合は、リスト自体がルールを使用して作成されます。 ルールによって、リスト・ビルダーとパラメータが定義されます。
「参加者のリストの作成で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図25-32に詳細を示します。
「OK」をクリックします。
ルール・ディクショナリが未作成で、参加者リストを簡単に指定するために複数のルール関数とファクトが事前にシードされている場合は、いずれのオプションでもルール・ディクショナリが作成されます。 ルール・ディクショナリには、参加者リストを作成するための次のルール関数がシードされています。
CreateResourceList
CreateManagementChainList
Taskファクトはタスク・サービスによってアサートされ、ルール条件のベースとなります。
ルール・ディクショナリが作成されると、Oracle Business Rulesデザイナが表示されます。
ルール条件をモデリングします。 アクション部分で、前述の関数のいずれか1つをコールして、リストの作成を完了します。 図25-33に詳細を示します。
ルール関数のパラメータは、Oracle JDeveloperモデリングでのパラメータに類似しています。 Oracle JDeveloperでの構成に加え、Oracle Business Rulesデザイナでは、次の属性について複数の追加オプションを使用できます。
responseType: レスポンス・タイプが「REQUIRED」の場合は、割当て先がタスクを操作する必要があります。 それ以外の場合、割当てはFYI割当てに変換されます。
ruleName: ルール名を使用して割当ての理由を作成できます。
lists: このオブジェクトは、作成されるリストの所有者です。 このオプションをクリックすると、事前にアサートされたファクトのListsオブジェクトが表示されます。このオブジェクトはパラメータとして使用されます。
図25-34に、管理チェーンベースの参加者を指定するルールの例を示します。
複数のルールが起動されると、最も高い優先度のルールに基づいて作成されたリスト・ビルダーが選択されます。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
図25-35に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
時間を指定します。
ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、第25.3.8項「タスクのエスカレート、期限更新または終了方法」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
これは非定型ルーティングとも呼ばれます。 このオプションが選択されている場合は、実行時にOracle BPM Worklistの「アクション」リストに「非定型ルート」が追加されます。
他の参加者をタスクに招待する手順は、次のとおりです。
図25-35に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
「この参加者による他の参加者の招待を許可」を選択します。
特定の条件が満たされている場合は、タスク参加者（ユーザー、グループまたはアプリケーション・ロール）をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスクをバイパスする手順は、次のとおりです。
図25-35に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
「スキップ・ルールの指定」を選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。
タスク参加者をバイパスするための式は、ブール値に評価される必要があります。たとえば、/task:task/task:payload/order:orderAmount < 1000は、参加者をスキップするための有効なXPath式です。
動的なルール条件の作成方法の詳細は、第25.3.7.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定」を参照してください。
図25-36および図25-37は、「パラレル」ダイアログの上部および下部のセクションを示しています。
この参加者タイプは、パラレルで作業する複数のユーザーが同時にタスクを操作する（たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する）必要がある場合に使用します。結果が有効になるために必要な得票率（多数決や満場一致など）を指定します。
たとえば、ビジネス・プロセスでは、雇用プロセス中に面接担当者全員からフィードバックを収集し、それをとりまとめて各面接担当者に採用または不採用リクエストを割り当てます。最後に、面接担当者の大多数が不採用ではなく採用に投票すると、候補者が雇用されます。
参加者をパラレル参加者タイプに割り当てる手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル（Approval Manager、Primary Reviewersなど）は、タスク定義のすべての参加者の中で一意にする必要があります。
表25-7に、パラレル参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
表25-7 参加者タイプの編集 — 「パラレル」タイプ
| サブセクション | 参照先 |
|---|---|
|
デフォルトの結果 同意パーセント 最小のパーセントに達するとただちに投票結果がトリガーされます 結果をトリガーせずにすべての投票の完了まで待機 |
|
|
参加者リスト |
第25.3.6.2.2項「パラレル・タスク参加者リストの作成」 |
|
添付ファイルとコメントの共有 |
第25.3.6.2.3項「タスク参加者との添付ファイルおよびコメントの共有」 |
|
割当て済期間の制限の設定（「詳細」セクション） |
第25.3.6.2.4項「タスクの操作に対する時間制限の指定」 |
|
この参加者による他の参加者の招待を許可（「詳細」セクション） |
|
|
スキップ・ルールの指定（「詳細」セクションの下） |
|
パラレル・タイプの「参加者タイプの編集」ダイアログの「投票結果」セクションに移動します。
「デフォルトの結果」リストで、同意パーセントの値に達しない場合にこのタスクで有効にするデフォルトの結果を選択するか、XPath式を入力します。この状況が発生するのは、得票数が同数の場合、またはタスクの有効期限が切れる前に応答しない参加者がいる場合です。 第25.3.4.3項「タスクの結果の指定」で「結果」ダイアログに入力したシード済結果とカスタム結果は、このリストに表示されます。
「同意パーセント」リストで、最終タスクの結果の決定方法を選択します。
番号別: このタスクの結果が有効になるために必要なパーセント値を選択するか、XPath式を入力します。たとえば、多数決（51）や満場一致（100）などです。たとえば、予想される2つの結果（「ACCEPT」および「REJECT」）と、5つのサブタスクがあるとします。2つのサブタスクが承認され、3つが却下された場合に、承認に必要なパーセントが50に設定されていると、タスクの結果は却下になります。
この機能は確定的でないことに注意してください。 たとえば、サブタスクが2つある場合に30%を選択することは無意味です。
式別: フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示することで、詳細を動的に指定します。
さらにグループ投票詳細を指定します。
最小のパーセントに達するとただちに投票結果がトリガーされます
このサブセクションが選択されている場合は、完了したサブタスクの結果に基づいてタスクの結果を早期に計算でき、保留中のサブタスクの取消しが可能になります。たとえば、4人のユーザーがタスクの操作に割り当てられており、デフォルトの結果が「APPROVE」で、同意パーセントが「50」に設定されているとします。 最初の2人のユーザーがタスクを承認した場合は、同意パーセント値に達しているため、第3および第4のユーザーがタスクを操作する必要はありません。
このサブセクションが選択されている場合、ワークフローはすべてのレスポンスを待機してから結果を開始します。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
これらの参加者リストの作成方法の詳細は、第25.3.6.1.1項「単一タスク参加者リストの作成」を参照してください。
コメントおよび添付ファイルは、すべてのグループ協力者またはワークフロー参加者と共有できます。 通常、この情報はOracle BPM Worklistのフッター・リージョンに表示されます。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
パラレル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクション（図25-37を参照）で、「開く」アイコンをクリックしてセクションを開きます。
「割当て済期間の制限の設定」を選択します。
時間を指定します。
ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、第25.3.8項「タスクのエスカレート、期限更新または終了方法」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
特定の条件が満たされている場合は、タスク参加者（ユーザー、グループまたはアプリケーション・ロール）をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスク参加者をバイパスする手順は、次のとおりです。
パラレル・タイプの「参加者タイプの編集」ダイアログで、「スキップ・ルールの指定」チェック・ボックスを選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。
参加者をスキップするための有効なXPath式は、第25.3.6.1.4項「タスク参加者のバイパス」を参照してください。
図25-38に、「シリアル」ダイアログを示します。
この参加者タイプを使用すると、ワークフロー用に参加者の順序リストを作成できます。たとえば、文書をJohn、MaryおよびScottに順番にレビューさせる場合は、この参加者タイプを使用します。シリアル参加者タイプの場合、参加者はユーザーまたはグループのリストになります。
シリアル参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル（Approval Manager、Primary Reviewersなど）は、タスク定義のすべての参加者の中で一意にする必要があります。
表25-8に、シリアル参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
図25-8 参加者タイプの編集 — 「シリアル」タイプ
| サブセクション | 参照先 |
|---|---|
|
参加者リスト |
第25.3.6.3.1項「シリアル・タスク参加者リストの作成」 |
|
割当て済期間の制限の設定（「詳細」セクション） |
第25.3.6.3.2項「タスクの操作に対する時間制限の指定」 |
|
この参加者による他の参加者の招待を許可（「詳細」セクション） |
|
|
スキップ・ルールの指定（「詳細」セクションの下） |
|
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
これらの参加者リストを作成する方法は、第25.3.6.1.1項「単一タスク参加者リストの作成」を参照してください。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
「シリアル」タイプの「参加者タイプの編集」ダイアログの「詳細」セクション（図25-38を参照）で、「開く」アイコンをクリックしてセクションを開きます。
「割当て済期間の制限の設定」をクリックします。
時間を指定します。
ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、第25.3.8項「タスクのエスカレート、期限更新または終了方法」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
シリアル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクションで、「開く」アイコンをクリックしてセクションを開きます（開いていない場合）。
「この参加者による他の参加者の招待を許可」を選択します。
|
注意: シリアル参加者タイプでは、次のようにして他の参加者を招待できます。
|
特定の条件が満たされている場合は、タスク参加者（ユーザー、グループまたはアプリケーション・ロール）をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスク参加者をバイパスする手順は、次のとおりです。
シリアル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクションで、「スキップ・ルールの指定」チェック・ボックスを選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。
参加者をスキップするために有効なXPath式については、第25.3.6.1.4項「タスク参加者のバイパス」を参照してください。
図25-39に、「FYI」タイプの「参加者タイプの編集」ダイアログを示します。
この参加者タイプは、ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。
たとえば、雑誌の購読契約の更新期日がきているとします。ユーザーが期日までに現在の購読契約を取り消さない場合は、購読契約の期限が更新されます。リクエストが期限切れになるかユーザーが操作するまで、このユーザーに週に1回ずつリマインダが送信されます。
FYI参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル（Approval Manager、Primary Reviewersなど）は、タスク定義のすべての参加者の中で一意にする必要があります。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
これらの参加者リストを作成する方法は、第25.3.6.1.1項「単一タスク参加者リストの作成」を参照してください。
参加者タイプを構成してヒューマン・タスク・エディタに戻ると、図25-40に示すように、「タスクは開始参加者から最終参加者へ移行します」アイコンが有効化されています。
図25-40 ヒューマン・タスク・エディタ — 「割当ておよびルーティング・ポリシー」セクション
このアイコンをクリックすると、図25-41に示す「割当ての構成」ダイアログが表示されます。 このダイアログでは、ワークフローを介してタスクをルーティングする方法を指定できます。
表25-9に、用意されているルーティング・ポリシー・メソッドを示します。
表25-9 ルーティング・ポリシー・メソッド
| ルーティング・ポリシーの選択 | このポリシーを使用する環境 | 項 |
|---|---|---|
|
このポリシーを選択すると、次のサブオプションを指定できます。 |
タスクは、参加者の表示順に従って各参加者にルーティングする必要があります。 これは事前に決定されているデフォルトのルーティングです。 たとえば、雇用プロセスで、3人のユーザーが面接して検討結果を提供する場合、タスクは人事部に送信されます。 |
第25.3.7.1項「指定した順序での全参加者へのタスクのルーティング」 |
|
参加者は、タスクを承認する際に、ユーザーまたはグループを次の割当て先（臨時）として選択できます。 |
第25.3.7.1.1項「全参加者による他の参加者の招待の許可」 |
|
タスクの参加者が、タスクを承認または却下できます。したがって、他の参加者にタスクが送信されずにワークフローが終了します。 たとえば、マネージャが却下した注文書は、レビューのためにそのマネージャのマネージャに送信されません。 |
第25.3.7.1.2項「他の参加者へのタスクのルーティングの停止」 |
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因になることはありません。 |
第25.3.7.1.3項「パラレル・サブタスクでの早期完了の有効化」 |
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因となります。 |
第25.3.7.1.4項「早期完了するサブタスクの親サブタスクの完了」 |
|
拡張ルールの使用 |
タスクのルーティング先の参加者は、モデリングしたビジネス・ルール・ロジックによって判断されます。 たとえば、融資申請タスクは、融資エージェント、そのマネージャおよびシニア・マネージャを経由するように設計されているとします。 この場合、融資エージェントは承認したが、そのマネージャが却下すると、その融資申請タスクは融資エージェントに戻されます。 |
第25.3.7.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定」 |
|
外部ルーティングを使用 |
タスクの参加者は動的に決定されます。 たとえば、ある企業のルールでは、タスク参加者は、実行時に決定しバックエンド・データベースから取得する必要があります。 |
|
|
「割当て」タブ |
参加者に、失敗したタスクがリカバリの目的で割り当てられます。 |
|
選択された参加者全員がタスクをレビューするように選択できます。これは、表示された順序で各参加者にタスクがルーティングされるデフォルト・ルーティングです。このタイプのルーティングは、ステート・マシン・ベースのルーティングとは異なります。
指定した順序でタスクを全参加者にルーティングする手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
図25-42に示すように、リストから「指定した順序で全参加者へタスクをルート」を選択します。
ルーティング・ポリシーの定義方法は、次の各項を参照してください。
「全参加者による他の参加者の招待の許可」
「参加者の選択によるタスクの完了」
「パラレル・サブタスクでの早期完了の有効化」
「早期完了するサブタスクの親サブタスクの完了」
このチェック・ボックスは、以前の10.1.3 Oracle BPEL Process Managerリリースの非定型ワークフロー・パターンに相当します。これは、参加者が1人以上存在する場合に適用されます。この場合は、各ユーザーがタスクの承認時に次の割当て先としてユーザーまたはグループを選択します。
全参加者に対して他の参加者の招待を許可する手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
「指定した順序で全参加者へタスクをルート」を選択します。
「全参加者による他の参加者の招待を許可」チェック・ボックスを選択し、このタスクの割当て先がこのワークフローの次の割当て先にルーティングする前に、他の参加者をワークフローに招待できるようにします。
ワークフローの他の参加者に関係なくタスクを早期完了させる条件を指定できます。
たとえば、経費レポートがマネージャに送信されてから取締役に送信されるとします。最初の参加者（マネージャ）がレポートを却下した場合は、次の参加者（取締役）に送信せずにワークフローを終了できます。
条件付き中途完了を設定する手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「指定した順序で全参加者へタスクをルート」を選択します。
「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスを選択します。
「中途完了の詳細」ダイアログが表示されます。
タスクの中途完了を指定するには、次の2つの方法があります。
結果
XPath式のルーティング条件
結果を指定した場合は、選択したタスクの結果が発生すると、そのタスクが完了します。結果とルーティング条件の両方を指定した場合は、ワークフロー・サービスにより2つの条件の論理ORが実行されます。
図25-43に示すように、適切な結果を選択して「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。
「ルーティング条件」フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示すると、このダイアログで、このタスクを中途完了させる条件を動的に作成できます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
早期完了を有効化する場合は、「パラレル・サブタスクで早期完了を有効化」をクリックします。 詳細は、第25.3.7.1.3項「パラレル・サブタスクでの早期完了の有効化」を参照してください。
親タスクの早期完了を有効化する場合は、「早期完了するサブタスクの親タスクを完了」をクリックします。 詳細は、第25.3.7.1.4項「早期完了するサブタスクの親サブタスクの完了」を参照してください。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスの右側にあるアイコンをクリックすると、この情報を編集できます。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。 ただし、他のパラレル・グループによるサブタスクの操作は停止されません。 このグループでは、タスクの操作が続行されます。
たとえば、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。 一方のグループは、注文の明細を操作します。 他方のグループは、同じ注文のヘッダーを操作します。 第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。 一方、第2パラレル・グループは注文ヘッダーの操作を続行します。 このシナリオでは、タスク全体は早期完了しません。 図25-44に詳細を示します。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。 これにより、他のパラレル・グループによるサブタスクの操作も停止されます。
たとえば、図25-44に示すように、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。 一方のグループは、注文の明細を操作します。 他方のグループは、同じ注文のヘッダーを操作します。 第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。 さらに、第2パラレル・グループも注文ヘッダーの操作を停止します。 このシナリオでは、タスク全体が早期完了します。
複雑なワークフロー・ルーティング・シナリオを作成するには、拡張ルーティング・ルールを使用します。参加者タイプ（単一、パラレル、シリアル、FYI）は、中途完了、割当て先のスキップなどの基本条件を使用して、一連のユーザーから別のユーザーに直線的なフローを作成する際に使用されます。ただし、多くの場合、ワークフローの複数のユーザー間で、より複雑な前後へのルーティングを実行することが必要になります。1つの選択肢は、これらのタスクの調整として、BPELプロセスを使用することです。もう1つの選択肢は、ビジネス・ルールを使用して宣言的にルーティングを指定することです。 この項では、ヒューマン・タスク・エディタとビジネス・ルールを使用して、これらの複雑な相互作用をモデリングする方法について説明します。
ステート・マシン・ルーティング・ルールは、Oracle Business Rulesを使用して定義できます。 このアクションによって、評価されるOracle Business Rulesを作成できます。
その前に、ルーティング・スリップ・タスク参加者がタスクの結果を設定します。
その後に、タスクが次のルーティング・スリップ参加者に割り当てられます。
このアクションによって、第25.3.7.1項「指定した順序での全参加者へのタスクのルーティング」に説明されている標準的なタスク・ルーティング・スリップを上書きし、タスクに対して複雑なルーティング動作を作成できます。
Oracle Business Rulesを使用して、ビジネス・オブジェクト（ファクトと呼ばれる）に依存する一連のルール（ルールセットと呼ばれる）を定義し、実行するアクションを判断します。
ファクトとは、特定のビジネス・データを備えたオブジェクトです。ルーティング・スリップの割当て先がタスクの結果を設定するたびに、タスクを次の割当て先に自動的にルーティングするかわりに、タスク・サービスが次のステップを実行します。
ファクトをデシジョン・サービスにアサートします。
拡張ルーティング・ルールセットを実行します。
ルールでは、アサートされたファクトの値をテストし、TaskActionファクト・タイプに値を設定することで、ルーティングの動作を指定できます。
表25-10は、タスク・サービスによりアサートされたファクト・タイプを示しています。
表25-10 タスク・サービスによりアサートされたファクト・タイプ
| ファクト・タイプ | 説明 |
|---|---|
|
|
このファクトには、ワークフロー・タスク・インスタンスの現在の状態が含まれます。すべてのタスク属性がタスクに対してテストされます。タスク・ファクトには現在のタスク・ペイロードも含まれます。 このファクトを使用すると、ペイロード値およびタスク属性値との照合テストを構築できます。 |
|
|
このファクトには、前回のタスクの結果と、結果を設定した割当て先が記述されます。このファクトには、次の属性が含まれます。
|
|
|
このファクトは、書込みルールのテストを意図したものではありません。 かわりに、このファクトはルールセットによって更新され、タスクのルーティング方法を示すためにタスク・サービスに返されます。 ルールで |
ワークフロー・ルーティング・ルールのみで使用できるファクト・タイプと、ワークフロー参加者ルールのみで使用できるファクト・タイプがあります。 表25-11に、それぞれのタイプを使用できるルールを示します。
表25-11 ファクト・タイプの使用
| ファクト・タイプ | ルーティング・ルールでの使用 | 参加者ルールでの使用 |
|---|---|---|
|
|
可 |
可 |
|
|
可 |
不可 |
|
|
可 |
不可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
|
|
不可 |
可 |
タスクのルーティング方法をタスク・サービスに指示するために、ルールでは多数のタスク・アクションの1つを指定できます。 この指定は、ルール・セッションにアサートされたTaskActionファクトを更新することによって実行されます。 ただし、ルールでTaskActionファクトを直接更新することはできません。 かわりに、アクションRL関数の1つをコールし、TaskActionファクトをパラメータとして渡す必要があります。これらの関数によって、ファクトへの実際の更新が処理されます。 たとえば、先に進むアクションを指定するには、call GO_FORWARD（TaskAction）をルールのアクション部分に追加する必要があります。
ステート・マシン・ルーティング・ルールが評価されるたびに、ルールは表25-12に記載されているアクションの1つを実行します。
表25-12 ビジネス・ルールのアクション
| アクション | 説明 | パラメータ |
|---|---|---|
|
|
ルーティング・スリップの次の参加者に進みます（デフォルト動作）。 |
なし |
|
|
ルーティング・スリップの前の参加者（直前にタスクの結果を設定した前の参加者）に戻ります。 |
なし |
|
|
ルーティング・スリップでの特定の参加者に進みます。 |
タスクをルーティングする参加者のラベルを識別する文字列です（ |
|
|
ルーティングを終了し、タスクを完了します。タスクが完了としてマークされ、ルーティングがさらに要求されることはありません。 |
なし |
|
|
タスク・エスカレーション・ポリシーに従って（通常は現在の割当て先のマネージャに）タスクをエスカレートし、再割当てします。 |
なし |
この項では、簡単な例でカスタム・ルーティングの動作を実装するルールの使用方法を説明します。費用請求の承認を管理するためのヒューマン・ワークフロー・タスクが作成されます。 タスクの結果には、承認と却下があります。 タスク定義には、ExpenseRequestペイロードの要素が含まれます。 ExpenseRequestのフィールドの1つは、費用請求の総額です。 タスクのルーティング・スリップは、単一参加者3人（assignee1、assignee2、assignee3）で構成されます。
デフォルトでは、タスクは各割当て先にルーティングされ、各割当て先ではタスクの承認または却下が選択されます。
このデフォルト動作のかわりに、次のように必要なルーティング動作を指定します。
費用請求の総額が100ドル未満の場合は、参加者のいずれか1人の承認が必要です。それ以外の場合は、3人全員が承認する必要があります。
参加者のいずれかが費用請求を却下した場合は、再評価のために前の参加者に費用請求を戻す必要があります。最初の参加者によって却下されると、費用請求は却下され完了としてマークされます。
次のルールを使用して、この動作を実装します。 拡張ルーティング・ルールに対してルール・ディクショナリが生成されている場合、その拡張ルーティング・ルールはデフォルトのGO_FORWARD動作を実装するテンプレート・ルールを使用して作成されることに注意してください。 Oracle Business Rulesデザイナで「ルールのコピー」を右クリックして選択すると、このルールを編集し、テンプレート・ルールをコピーできます。
金額が100ドルより大きく、前の割当て先がタスクを承認した場合は、各割当て先に順番にタスクをルーティングするルールを指定する必要はありません。これは、ルールセットのルールがトリガーされない場合の戻り先のデフォルト動作となります。
反復設計の詳細は、Oracle Technology Networkから入手できるworkflow-106-IterativeDesignサンプルを参照してください。
http://www.oracle.com/technology/sample_code/products/hwf
拡張ルーティング・ルールを作成する手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」で、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「拡張ルールの使用」を選択します。
図25-48に示すように、「ルール・ディクショナリ」の右側にある「編集」アイコンをクリックします。
これにより、Oracle Business Rulesデザイナ（図25-49を参照）が開始されます。ルール・デザイナにはリポジトリが事前にシードされており、必要なすべてのファクト定義が格納されています。ディクショナリ用のデシジョン・サービス・コンポーネントが作成され、タスク・サービス・コンポーネントに関連付けられます。
Oracle Business Rulesを使用して、タスクのステート・マシン・ルーティング・ルールを定義します。
これにより、ヒューマン・タスク内で完全に接続されたデシジョン・サービスと、関連するルール・リポジトリとデータ・モデルが自動的に作成されます。
ビジネス・ルールの詳細は、次を参照してください。
ヒューマン・タスク・ルールセットの例は、第25.3.7.2.4項「ルールセットのサンプル」を参照してください。
『Oracle Fusion Middleware Oracle Business Rulesランゲージ・リファレンス・ガイド』
ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成します。 このルーティング・ポリシーを指定すると、他の参加者タイプはすべて無視されます。 タスクのルーティングを決定する参加者タイプ（単一承認者、シリアル承認者、パラレル承認者など）のリストを実行時に提供するのは、外部ルーティング・サービスとみなされています。
このオプションは、タスク割当て先の決定にルーティング・ルールを使用しない場合に使用します。 この場合、タスク割当てのすべてのロジックは、外部ルーティング・サービスに委任されます。
|
注意: 「割当ての構成」ダイアログで「外部ルーティングを使用」を選択した場合は、Javaクラスを指定し、「OK」をクリックして終了します。次回、このダイアログを開くと、ドロップダウン・リストには、他の2つの選択肢（「指定した順序で全参加者へタスクをルート」および「拡張ルールの使用」）は表示されません。 3つの選択肢すべてに再度アクセスするには、割当て全体を削除する必要があります。 |
外部ルーティングを使用する手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」で、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「外部ルーティングを使用」を選択します。
図25-50に示すように、「編集」アイコンをクリックします。
図25-51に示すように、「外部ルーティングを使用」ダイアログが表示されます。
「クラス名」フィールドで、完全修飾クラス・ファイル名（org.mycompany.tasks.RoutingServiceクラス名など）を入力します。 このクラスは、oracle.bpel.services.workflow.task.IAssignmentServiceインタフェースを実装している必要があります。
表25-13に示すように、外部サービスに渡す名前またはXPath式別に、名前/値ペアのパラメータを追加します。
「追加」アイコンをクリックし、その他の名前/値ペアのパラメータを追加します。
タスクは、間違った割当てなどの理由でエラーになることがあります。 このようなエラーが発生すると、タスクは、修正処理を実行するエラー割当て先に割り当てられます。 リカバリ可能なエラーは、次のとおりです。
すべての参加者に対して無効なユーザーおよびグループ。
割当て先および有効期間に関連する無効なXPath式。
有効期限のエスカレーション・エラー。
エスカレーション・ポリシーの評価。
期限更新ポリシーの評価。
管理チェーンの計算。
動的割当てルールの評価。 タスクは、現在はエラーではありませんが、現在のユーザーに割り当てられたままです。したがって、リカバリ可能です。
動的割当ての循環割当て（「ユーザーA」→「ユーザーB」→「ユーザーA」など）。 タスクは、現在はエラーではありませんが、チェーンの最終ユーザーに割り当てられたままです。したがって、リカバリ可能です。
次のエラーは、リカバリ可能ではありません。 このような場合、タスクは終了状態ERROREDに移動します。
無効なタスク・メタデータ。
読取り不可のタスク・メタデータ。
ステート・マシン・ルールからの無効なGOTO参加者。
割当てサービスが見つからない場合。
割当てサービスによるエラー。
カスタム・エスカレート関数の評価。
パラレルのデフォルト結果とパーセント値に対する無効なXPathおよび値。
ワークフローのエラー割当て先は、ワークフロー・タスクのモデリング中に指定できます。エラー割当て先が指定されている場合は、その割当て先が評価されてタスクが割り当てられます。 実行時にエラー割当て先が指定されていない場合は、管理ユーザーが検索され、アラート状態のタスクが割り当てられます。エラー割当て先は、次のいずれかのアクションを実行します。
非定型ルート
タスクを、そのタスクに実際に割り当てられているユーザーにルーティングします。 非定型ルーティングを使用すると、タスクを順番に、またはパラレルなどでユーザーにルーティングできます。
再割当て
タスクを、このタスクに実際に割り当てられているユーザーに再割当てします。
エラー・タスク
このタスクを修正できないことを示します。
エラー割当て先の評価中にエラーがあると、タスクはエラー発生としてマークされます。
このダイアログでは、割当てエラーが発生した場合にタスク割当て先となるユーザーまたはグループを指定できます。
エラー割当て先を構成する手順は、次のとおりです。
「割当ておよびルーティング・ポリシー」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
「割当て」タブをクリックします。
図25-52に示すように、「追加」アイコンをクリックして、レビューアまたはエラー割当て先を割り当てます。
「追加」アイコンをクリックし、このタスクに参加するユーザー、グループまたはアプリケーション・ロールを選択します。
「開始参加者」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。
ユーザー、グループまたはアプリケーション・ロールの選択方法は、第25.3.6.1.1「単一タスク参加者リストの作成」の手順4〜6を参照してください。
ユーザー、グループまたはアプリケーション・ロールの詳細は、第24.2.1.1.3項「参加者の割当て」を参照してください。
図25-53に、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションを示します。
このグローバル・ポリシー・セクション（ルーティング・スリップ・レベル）で、タスクの有効期間を指定できます。有効期間を参加者タイプ・レベルではなくルーティング・スリップ・レベルで指定すると、この期間は全参加者のタスクの有効期間となります。ただし、参加者タイプ・レベルで（「割当て済期間の制限の設定」フィールドを介して）有効期間を指定すると、その設定は「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で指定した設定よりも優先されます。
図25-53 ヒューマン・タスク・エディタ — 「有効期限およびエスカレーション・ポリシー」セクション
この項では、このレベルで有効期間を指定し、その設定を参加者全員のタスクの有効期間にする方法の概要を説明します。
たとえば、図25-54に示すように、参加者LoanAgentGroupおよび参加者Supervisorの両者間でタスクを操作するための日数が3日であるとします。
参加者レベルまたはこのルーティング・スリップ・レベルで有効期限が指定されていない場合、そのタスクの有効期間設定はありません。
いずれかの参加者レベルで有効期間が設定されている場合、その参加者には対応する有効期間が使用されます。ただし、参加者レベルの有効期間が設定されていない参加者には、引き続きグローバルな有効期間が使用されます。グローバルな有効期間は、常にタスクでの経過時間だけ減分されます。
参加者について参加者レベルの有効期限を解析するためのポリシーは、次のとおりです。
シリアル
「管理チェーン」内の各割当ては、「シリアル」で指定されている内容と同じ有効期間を取得します。期間は、この割当てによって発生したすべての割当てに対するものではないことに注意してください。 タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、エスカレーションおよび期限更新ポリシーが適用されます。
パラレル
パラレル・ワークフローでは、パラレル参加者がリソースとして指定されている場合は、リソースごとにルーティング・スリップが作成されます。作成された各ルーティング・スリップの有効期間には、次のルールが適用されます。
パラレル参加者の有効期間が指定されている場合は、それと同じ有効期間。
ルーティング・スリップ・レベルで指定されている場合は、タスクに残っている有効期間。
それ以外は有効期間なし。
パラレル参加者がルーティング・スリップとして指定されている場合、その有効期間はルーティング・スリップにより決定されます。
|
注意: パラレル・タスク内で親タスクが期限切れになった場合、期限切れになっていないサブタスクや未完了のサブタスクは取り消されます。 |
タスクが期限切れにならないように指定できます。
「期限切れなし」ポリシーを指定する手順は、次のとおりです。
図25-53に示すように、「有効期限およびエスカレーション・ポリシー」セクションのドロップダウン・リストで、「期限切れなし」を選択します。
タスクに有効期限を指定できます。タスクが期限切れになると、ルーティング・スリップ・レベルのエスカレーション・ポリシーまたは期限更新ポリシーが適用されます。どちらのポリシーも指定されていない場合、タスクは期限切れになります。ルーティング・スリップ・レベルの有効期限ポリシーは、すべての参加者に共通です。
タスクに有効期限を指定する手順は、次のとおりです。
ユーザーが割当て時間内に応答しない場合は、有効期限の期間を延長できます。 このためには、期限切れの際にタスクの期限を更新できる回数（3回の追加更新など）と各期限更新期間（期限更新ごとに3日間など）を指定します。
有効期限ポリシー期間を延長する手順は、次のとおりです。
ユーザーが割当て時間内に応答しない場合は、タスクをエスカレートできます。 たとえば、ユーザー・ディレクトリに構成されているエスカレーション階層を使用している場合は、ユーザーのマネージャにタスクをエスカレートできます。 エスカレーション・コールバックを使用している場合は、定義したユーザーにタスクをエスカレートできます。 タスクが最大回数までエスカレートされた場合、エスカレートは停止します。 エスカレートされたタスクは、そのタスクの期限切れ以降もユーザーの受信ボックス内に残すことができます。
タスク・ポリシーをエスカレートする手順は、次のとおりです。
図25-53に示すように、「有効期限およびエスカレーション・ポリシー」セクションのドロップダウン・リストで、「エスカレートまでの時間」を選択します。
さらに次の値を指定します。 両方を設定すると、エスカレーション・ポリシーがより限定的になります。
エスカレーション・レベルの最大数
タスクをエスカレートする管理レベル数。 このフィールドは必須です。
承認者の最高役職
最上位承認者の役職（自分、マネージャ、取締役またはCEOなど）。これらの役職は、対応するユーザー・リポジトリのタスク割当て先の役職と比較されます。このフィールドはオプションです。
エスカレーション・ポリシーでは、タスクを期限切れ時にエスカレートできる回数と期限更新期間を指定します。 図25-57では、タスクが期限切れになると、最大3回までエスカレートされます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。
期日は、タスクを完了する必要がある日付を示すために使用されます。 期日は、有効期限とは異なることに注意してください。 期限切れタスクの場合は、期限切れとしてマークされるか、エスカレーション・ポリシーに基づいて自動的にエスカレートまたは期限更新されます。 通常、期日は有効期限より早い日付で、タスクの期限切れが近いことをユーザーに示します。
図25-53に示すように、タスクの期日を入力できます。 タスクは指定された期日をすぎると、期限切れとなります。この日付は有効期限ポリシーの付加項目です。期日は、有効期限ポリシーが指定されているかどうかに関係なく指定できます。 期日を使用すると、Oracle BPM Worklistに期日を表示し、期限切れタスクをリストし、受信ボックス内の期限切れタスクをハイライト表示できます。期限切れタスクは、TaskQueryService.queryTask(...) APIの述語を使用して、問合せできます。
期日を指定する手順は、次のとおりです。
「有効期限およびエスカレーション・ポリシー」セクションで、「期間を使用」チェック・ボックスを選択します。
「日付別」を選択して特定の期日を入力するか、「式別」を選択してXPath式として値を動的に入力します。
次の点に注意してください。
期日は、（Oracle BPM Worklistの「To Doタスクの作成」ダイアログを使用する）タスクと、（ヒューマン・タスク・エディタを使用する）.taskファイルの両方で設定できます。これにより、タスクの開始時に、タスク定義のないTo Doタスクで期日を設定できるようになります。 タスク（実行時オブジェクト）に設定された期日は、.taskファイルに設定された期日よりも優先されます。
タスク定義では、期日は各参加者に対してではなく、グローバルなレベルでのみ指定できます。
タスクに対して期日が設定されている場合、.taskファイルの期日は無視されます。
タスクに対して期日が設定されていない場合は、.taskファイルの期日が評価され、タスクに設定されます。
タスクと.taskファイルのいずれにも期日がない場合、タスクには期日がありません。
|
注意: To Doタスクに対してビジネス・ルールを指定することはできません。 |
詳細は、第27.3.4項「To Doタスクの作成方法」を参照してください。
図25-58に、ヒューマン・タスク・エディタの「通知設定」セクション（完全に開いた状態）を示します。
通知は、ユーザーにタスクが割り当てられる時期を示すか、タスクのステータスに変更があったことを通知します。通知は、電子メール、ボイス・メッセージ、インスタント・メッセージまたはSMSで送信できます。異なるアクションについて様々なタイプの参加者に通知が送信されます。デフォルトでは、通知はデフォルト・メッセージを使用して構成されます。たとえば、タスクが完了してクローズされたことを示す通知メッセージが送信されます。独自の構成を作成するか、既存の構成を変更できます。
参加者の通知プリファレンスを指定する手順は、次のとおりです。
「通知設定」セクション（図25-58を参照）で、「開く」アイコンをクリックしてセクションを開きます。
表25-14に、「通知設定」セクションの各サブセクションの構成方法を示します。
表25-14 ヒューマン・タスク・エディタ — 「通知設定」セクション
| サブセクション | 参照先 |
|---|---|
|
タスク・ステータス 受信者 |
第25.3.9.1項「受信者へのタスク・ステータス変更の通知」 |
|
通知ヘッダー |
|
|
リマインダ |
|
|
エンコーディング |
第25.3.9.4項「キャラクタ・セット・エンコーディングの変更」 |
|
通知のセキュア化(詳細を除く) |
|
|
通知をアクション可能にする |
|
|
電子メール通知によるタスクの添付ファイルの送信 |
第25.3.9.6項「電子メール・メッセージのアクション可能化」 |
通知サービスの詳細は、第29.2項「ヒューマン・ワークフローからの通知」を参照してください。
「タスク・ステータス」列には、3つのデフォルト・ステータス・タイプ「割当て」、「完了」および「エラー」が表示されます。通知メッセージの受信用に他のステータス・タイプを選択できます。
受信者にタスク・ステータス変更を通知する手順は、次のとおりです。
「通知設定」セクションの「タスク・ステータス」列で、タイプをクリックしてタスク・タイプの完全なリストを表示します。
アラート済
タスクがアラート済の状態の場合は、受信者に通知できます。 ただし、いずれの通知受信者（割当て先、承認者、所有者、起案者またはレビューア）も、アラート済の状態を知らせるFYI通知の単なる受信者であり、アラート済の状態からエラー状態にタスクを移動することはできません。 所有者は、タスクの再割当て、取消し、削除またはパージを実行できます。また、エラーを解決できない場合はタスクをエラー状態に移動するようにエラー割当て先に依頼できます。 アラート済からエラー状態にタスクを移動できるのは、エラー割当て先のみです。
エラー割当て先は、「割当ての構成」ダイアログの「割当て」タブで構成します。このタブは「割当ておよびルーティング・ポリシー」セクションの「タスクは開始参加者から最終参加者へ移行します」アイコンの下にあります。 詳細は、第25.3.7.4項「エラー割当て先の構成」を参照してください。
割当て
ユーザーまたはグループにタスクが割り当てられた場合。 この場合は、次のアクションが取得されます。
ユーザーへのタスクの割当て
シリアル・ワークフローでの新規ユーザーへのタスクの割当て
タスクの期限更新
タスクの委任
タスクの再割当て
タスクのエスカレート
タスク情報の発行
完了
エラー
期限切れ
情報のリクエスト
再開
一時停止
更新
タスク・ペイロードの更新
タスクの更新
コメントの追加
添付ファイルの追加および更新
結果の更新
取消
その他のすべてのアクション
前述のタスク・タイプ以外のアクション これにはタスクの取得が含まれます。
タスク・ステータスのタイプを選択します。
通知は、様々な範囲でタスクに関与するユーザーに送信できます。これには、タスクがグループに割り当てられている場合が含まれます。グループに通知エンドポイントが設定されていない場合は、グループの各ユーザーに通知が送信されます。
「受信者」列でエントリをクリックして、通知メッセージの受信者候補のリストを表示します。
割当て先
タスクが現在割り当てられているユーザーまたはグループ。
起案者
タスクを作成したユーザー。
承認者
この時点までにタスクを操作したユーザー。これは、複数のユーザーがタスクを承認するシリアル参加者タイプに適用され、通知はこれらのユーザー全員に送信される必要があります。
所有者
タスクの所有者。
レビューア
タスクにコメントおよび添付ファイルを追加できるユーザー。
詳細は、第29.2.5項「通知チャネル・プリファレンスの構成方法」を参照してください。
デフォルトの通知メッセージを、選択した受信者に配信できます。必要な場合は、デフォルト・メッセージのテキストを変更できます。
通知メッセージを編集する手順は、次のとおりです。
「通知設定」セクションの「通知ヘッダー」列で、「編集」アイコンをクリックして、デフォルトの通知メッセージを変更します。
図25-59に示す「通知メッセージの編集」ダイアログが表示されます。
このメッセージは、サポート対象のすべての通知チャネル（電子メール、ボイス、インスタント・メッセージおよびSMS）に適用されます。電子メール・メッセージには、このメッセージに定義したワークリスト・タスク詳細も挿入できます。メッセージの配信チャネルは、指定した通知プリファレンスに基づいています。
必要に応じてメッセージの文言を変更します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
通知プリファレンスの詳細は、第29.2項「ヒューマン・ワークフローからの通知」を参照してください。
タスクのリマインダを送信できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づいています。リマインダの数およびリマインダ間の間隔も構成可能です。
リマインダを設定する手順は、次のとおりです。
「通知設定」セクションのリマインダ・リストから、リマインダの送信数を選択します。
割当て先に1回、2回または3回通知するように選択した場合は、リマインダの間隔を選択し、リマインダを割当て前に送信するか割当て後に送信するかを選択します。 図25-60に詳細を示します。
有効期限およびルーティング・ポリシー・セクションで「期間を使用」を選択した場合は、右端にあるドロップダウン・リストに、「期日前」という選択オプションが表示されます。
詳細は、第29.2.12項「リマインダの送信方法」を参照してください。
Unicodeは、任意の言語の情報を単一のキャラクタ・セットを使用して格納できる全世界共通のエンコード・キャラクタ・セットです。 Unicodeは、プラットフォーム、プログラムまたは言語に関係なく、あらゆる文字に一意のコード値を提供します。 UTF-8のデフォルト設定を使用するか、Javaクラスでキャラクタ・セットを指定できます。
キャラクタ・セットのエンコーディングを変更する手順は、次のとおりです。
「エンコーディング」リストから、「Javaクラスで指定」を選択します。
使用するJavaクラスを入力します。
通知のセキュア化、メッセージのアクション可能化および添付ファイルの送信を設定する手順は、次のとおりです。
「通知設定」セクションで「通知のセキュア化(詳細を除く)」を選択します。
選択すると、デフォルトの通知メッセージが使用されます。電子メールには、HTMLのワークリスト・タスク詳細、添付ファイルまたはアクション可能なリンクはありません。メッセージにはタスク番号のみが含まれます。
詳細は、第29.2.10項「セキュアな通知の送信方法」を参照してください。
「通知設定」セクションで「通知をアクション可能にする」を選択します。 このアクションにより、電子メールを介してタスク・アクションを実行できます。
その他の構成の詳細は、第29.2.7項「アクション可能なメッセージの送信方法」を参照してください。
アウトバウンドおよびインバウンド電子メールの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。
「通知設定」セクションで「電子メール通知によるタスクの添付ファイルの送信」を選択します。
通知のヘッダーをカスタマイズする場合は、カスタム通知ヘッダーも選択します。
カスタム通知ヘッダーは、名前/値ペアを指定し、通知の中でキー・フィールドを識別するために使用されます。ユーザーは、これらの入力項目を使用して、通知の配布プリファレンスを定義します。 たとえば、「名前」を「ApprovalType」、「値」を「経費」に設定したり、「名前」を「優先度」、「値」を「高」に設定することができます。その後、ユーザーはOracle BPM Worklistで配信プリファレンスを指定できます。これらのプリファレンスは通知の内容に基づいています。
ルールベース通知サービスは、使用する優先通知チャネルを識別するのみであることに注意してください。優先チャネルのアドレスは、その後もアイデンティティ・サービスから取得できます。
名前またはXPath式別に、名前/値ペアのパラメータを追加します。
プリファレンスの詳細は、第29.2.8項「インバウンドおよびアウトバウンド添付ファイルの送信方法」、第29.2.14項「カスタム通知ヘッダーの作成方法」、第VII部「Oracle User Messaging Serviceの使用」を参照してください。
このセクションでは、拡張ヒューマン・タスク機能を指定できます。たとえば、カスタム・エスカレーション・ルール、添付ファイルのカスタム・スタイルシート、多言語設定、コールバック・クラス、デジタル署名ポリシー、タスク・コンテンツおよびアクションへのアクセス、制限付き割当て、BPELコールバックのタスクとルーティング・カスタマイズ、グラフィカル履歴などを指定できます。
図25-61に、ヒューマン・タスク・エディタの「詳細設定」セクションを示します。
表25-15に、使用可能なセクションを示します。
表25-15 「詳細設定」セクション
| セクション | 参照先 |
|---|---|
|
エスカレーション・ルールを指定してください。 |
|
|
添付ファイルのWordMLスタイルシートを指定してください。 |
第25.3.10.2項「添付ファイルのWordMLスタイルシートの指定」 |
|
添付ファイルのスタイルシートを指定してください。 |
第25.3.10.3項「添付ファイルのスタイルシートの指定」 |
|
多言語設定を指定してください。 |
|
|
タスク・ステータスにコールバック・クラスを指定してください。 |
第25.3.10.5項「タスク・ステータスのコールバック・クラスの指定」 |
|
ワークフロー署名ポリシーを指定してください |
|
|
タスク・コンテンツのデフォルト・アクセスをオーバーライドします |
第25.3.10.8項「タスク・コンテンツへのアクセス・ポリシーの指定」 |
|
制限付き割当ての指定 |
|
|
BPELコールバックのタスクとルーティング・カスタマイズを許可 |
第25.3.10.10項「BPELコールバックのタスクとルーティング・カスタマイズの許可」 |
|
グラフィカル履歴全体の表示 |
|
このオプションを使用すると、特定のワークフローについてカスタム・エスカレーション・ルールをプラグインできます。たとえば、期限切れ時に、タスクを現在のユーザーの部門マネージャに割り当てるには、カスタム・タスク・エスカレーション関数を記述してワークフロー・サービスに登録し、その関数をタスク定義に使用できます。
デフォルトのエスカレーション・ルールでは、タスクは現在のユーザーのマネージャに割り当てられます。新規エスカレーション・ルールを追加するには、次の手順に従います。
エスカレーション・ルールを指定する手順は、次のとおりです。
インタフェースoracle.bpel.services.workflow.assignment.dynamic.IDynamicTaskEscalationFunctionを実装します。この実装は、サーバーのクラスパスで使用可能にする必要があります。
Oracle Enterprise Manager Fusion Middleware Controlコンソールにログインします。
ナビゲータで、「SOA」フォルダを開きます。
「soa-infra」を右クリックし、「SOA管理」→「ワークフロー・タスク・サービス・プロパティ」の順に選択します。
「ワークフロー・タスク・サービス・プロパティ」ページが表示されます。
新しい関数を追加します。次に例を示します。
関数名: Department_supervisor
クラスパス: oracle.bpel.services.workflow.assignment.dynamic.patterns.DepartmentSupervisor
関数のパラメータ名
関数のパラメータ値
「詳細設定」セクションの「エスカレーション・ルールを指定してください。」フィールドに、エスカレーション・ルールについて「ワークフロー・タスク・サービス・プロパティ」ページに定義されている関数名を入力します。
詳細は、第29.3.3項「カスタム・エスカレーション関数」を参照してください。
このオプションを使用すると、WordML XSLTスタイルシートを使用して電子メール添付ファイルとして送信するためのMicrosoft Word文書を動的に作成できます。 XSLTスタイルシートは、タスク・ドキュメントに適用されます。
添付ファイルのWordMLスタイルシートを指定する手順は、次のとおりです。
「詳細設定」セクションの「添付ファイルのWordMLスタイルシートを指定してください。」フィールドで、「検索」アイコンをクリックし、WordMLスタイルシートを添付ファイルとして選択します。
このオプションを使用すると、XSLTスタイルシートを使用して電子メール添付ファイルを作成できます。 XSLTスタイルシートは、タスク・ドキュメントに適用されます。
添付ファイルのスタイルシートを指定する手順は、次のとおりです。
「詳細設定」セクションの「添付ファイルのスタイルシートを指定してください。」フィールドで、「検索」アイコンをクリックし、スタイルシートを添付ファイルとして選択します。
リソース・バンドルは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するように指定できます。次のタスク詳細でリソース・バンドルがサポートされます。
プレーン・テキストまたはmessage(key)書式によるタスクの結果値の表示。
Oracle BPM Worklistのペイロード表示でのXML要素名および属性名の表示。 Oracle BPM WorklistでXML要素名を国際化するには、リソース・バンドル内のキー名がXML要素名および属性名と同一である必要があります。
様々な言語による電子メール通知メッセージの有効化。 実行時にXPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を指定して、指定のリソース・バンドルから国際化された文字列を取得します。通知受信者のロケールは、関数hwf:getNotificationProperty(propertyName)で取得できます。
リソース・バンドルは単純にプロパティ・ファイルでもあります。たとえば、タスクの結果の表示名を構成するリソース・バンドルは、次のようになります。
APPROVE=Approve
REJECT=Reject
多言語設定を指定する手順は、次のとおりです。
「詳細設定」セクションの「多言語設定を指定してください。」フィールドで、「リソースの構成」をクリックします。
図25-62に示す「リソースの詳細」ダイアログが表示されます。
「リソース名」フィールドで、リソース・バンドルに使用するリソース名を入力します。 このファイルは.propertiesベースのリソース・バンドル・ファイルである必要があります。
「リソースの場所」フィールドで、「検索」アイコンをクリックし、使用するJARまたはZIPリソース・バンドル・ファイルを選択します。リソース・バンドルはシステム・アーカイブ（SAR）ファイルの一部です。
リソース・バンドルがコンポジット・プロジェクト外部にある場合は、SCA-INF/libにローカル・コピーを格納するように求めるプロンプトが表示されます。
リソース・バンドル・ファイルがコンポジット・クラス・ローダー（SCA-INF/classesの直下またはSCA-INF/libのJARファイル内）にない場合は、そのファイルがある場所を指定する必要があります。 たとえば、リソース・バンドルがコンポジット・クラス・ローダー外部の場所（http://host:port/bundleApp/taskBundles.jarのようなHTTPの場所など）からアクセス可能な場合は、その場所をこのフィールドに指定する必要があります。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
詳細は、第29.2.6項「異なる言語による通知メッセージの構成方法」を参照してください。
ワークフロー・サービスのコールバックは、タスクのライフサイクルで特定のステージに到達したときにコールするように登録できます。2つのタイプのコールバックがサポートされています。
Javaコールバック: コールバック・クラスは、インタフェースoracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装している必要があります。このコールバック・クラスをサーバーのクラスパスで使用可能にします。
ビジネス・イベント・コールバック: ヒューマン・タスクの状態が変化したときに、ビジネス・イベントが発生するようにできます。Javaクラスを開発して登録する必要はありません。 コール元は、承認トランザクションの現在の状態が通知されるように、メディエータ・サービス・コンポーネントを使用してコールバックを実装し、適用可能なビジネス・イベントをサブスクライブします。
タスク・ステータスのコールバック・クラスを指定する手順は、次のとおりです。
「詳細設定」セクションの「タスク・ステータスにコールバック・クラスを指定してください。」フィールドで、「コールバックの構成」をクリックします。
「追加」アイコンをクリックして表にコールバックを追加します。「コールバック」列には、「OnAssigned」というコールバックが自動的に追加されます。
「OnAssigned」をクリックして他のコールバック値のリストを表示し、この列の値を選択します。
使用可能なコールバックは、次のとおりです。
OnCompleted
タスクが完了し、コントロールが起案者（タスクを開始するBPELプロセスなど）に渡されようとしているときに、コールバック・クラスを最終的にコールする必要がある場合に選択します。
OnAssigned
標準的なルーティング、再割当て、委任、エスカレーションなどを含め、割当ての変更時にコールバック・クラスをコールする必要がある場合に選択します。タスクによって結果が更新される（つまり、チェーンのいずれかの承認者がタスクを承認または却下する）ときにコールバックする必要がある場合は、このオプションを選択する必要があります。
OnUpdated
更新（ペイロード、コメント、添付、優先度などを含む）時にコールバック・クラスをコールする必要がある場合に選択します。
OnSubtaskUpdated
サブタスク（パラレルおよびパラレル・シナリオのいずれかのタスク）の更新（ペイロード、コメント、添付、優先度などを含む）時にコールバック・クラスをコールする必要がある場合に選択します。
OnStageCompleted
ヒューマン・ワークフロー・タスクでビジネス・イベント・コールバックを有効化するために、コールバック・クラスをコールする必要がある場合に選択します。 イベントが発生すると、そのイベントには、完了したステージの名前、完了したステージの結果、およびコールバックが起動された時点でのタスクのスナップショットが格納されます。
実行するコールバックのタイプに応じて、次の項を参照してください。
Javaコールバックを指定する手順は、次のとおりです。
「タイプ」列で、「Java」をクリックします。
「値」列の空のフィールドをクリックして値を入力します。この値は、oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaクラスの完全クラス名です。 図25-63に詳細を示します。
「OK」をクリックします。
ビジネス・イベント・コールバックを指定する手順は、次のとおりです。
「タイプ」列で、「イベント」をクリックします。 これにより、図25-64に示すように、「値」列が使用不可になります。各コールバック（OnAssignedなど）は、1つのビジネス・イベント・ポイントに対応しています。ビジネス・イベントが起動されると、イベント詳細にはタスク・オブジェクトおよび一連のプロパティが挿入されます。各プロパティの値は、起動されるイベントの内容に基づいて移入されます。
事前にシードされている静的イベント定義言語（EDL）ファイル（JDev_Home\jdeveloper\integration\seed\soa\shared\workflow\HumanTaskEvent.edl）によって、サブスクライブ対象として使用可能なビジネス・イベントのリストが提供されます。これらのビジネス・イベントは、「コールバック詳細」ダイアログで選択したコールバックに対応しています。EDLファイルを参照し、適切なビジネス・イベントをサブスクライブするメディエータ・サービス・コンポーネントを作成する必要があります。
|
注意: EDLファイルを配置できるようにするには、ファイルベースのMDS接続が必要です。 ファイルベースのMDSの場所は、JDev_Home\jdeveloper\integration\seedです。 |
イベントをサブスクライブできる同じまたは異なるSOAコンポジット・アプリケーションに、Oracle Mediatorサービス・コンポーネントを作成します。
Oracle Mediatorの作成時に、「テンプレート」リストで、「イベントのサブスクライブ」を選択します。
「追加」アイコンをクリックして、新しいイベントをサブスクライブします。
「イベント定義」フィールドの右側にある「参照」アイコンをクリックし、EDLファイルを選択します。
「SOAリソース・ブラウザ」ダイアログが表示されます。
前に作成したファイルベースのMDS接続を選択します。
上部のリストから「リソース・パレット」を選択します。
「SOA」→「共有」→「ワークフロー」→「HumanTaskEvent.edl」の順に選択します。
「OK」をクリックします。
これで、選択可能なEDLファイル・ビジネス・イベントが「イベント・チューザ」に移入されます。
「イベント」フィールドで、サブスクライブするイベントを選択します。 図25-65に詳細を示します。
イベントのサブスクライブに使用可能なヒューマン・タスクは複数あります。 たとえば、次のヒューマン・タスクがあるとします。
イベント（OnAssignedなど）をサブスクライブするTaskAというヒューマン・タスクを構成しました。
同じイベントをサブスクライブするTaskBというヒューマン・タスクを構成しました。
TaskAとTaskBのイベントを区別し、意図したOracle Mediatorによってイベントを確実に処理するためには、静的なルーティング・フィルタを追加できます。
xpath20:compare(med:getComponentName(), 'TaskA')
これにより、送信コンポーネントがTaskAの場合にのみ、このルーティングが起動されます。
ファイルベースのMDS接続からEDLファイルを選択していない場合は、プロンプトが表示されたときに、依存するXSDファイルを受け入れてインポートし、「OK」をクリックします。 ファイルベースのMDS接続からEDLファイルを選択している場合、プロンプトは表示されません。
これで、Oracle Mediatorサービス・コンポーネントに、サブスクライブするビジネス・イベントが移入されます。同じEDLファイルに定義されている他のビジネス・イベントも、この時点で、または後でサブスクライブできます。
ビジネス・イベントおよびコールバックの詳細は、次の各項を参照してください。
ビジネス・イベントの詳細は、第44章「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。
サンプルのworkflow-116-WorkflowEventCallbackは、Oracle Technology Networkから入手できます。
http://www.oracle.com/technology/sample_code/products/hwf
デジタル署名は、デジタル署名されたヒューマン・タスクの否認防止メカニズムを提供します。この機能は、タスクを操作する参加者に対し、タスクの更新前に詳細と各自のアクションに対する署名を義務付けることで、後で否認できないようにします。
|
注意: タスクに対してデジタル署名が有効な場合、アクション可能な電子メールは実行時に送信されません。 設計時にアクション可能な電子メールが有効化された場合も同様です。 |
ワークフロー署名ポリシーを指定する手順は、次のとおりです。
「詳細設定」セクションの「ワークフロー署名ポリシーを指定してください」フィールドで、「ポリシーの構成」をクリックします。
タスク参加者が使用する署名ポリシーを指定します。
署名は不要
参加者は、署名せずにタスクの送信と操作を実行できます。これはデフォルトのポリシーです。
パスワードは必須
参加者は、次の参加者にタスクを送信する前に、署名を指定します。 参加者はタスクを操作する際に、パスワードを再入力する必要があります。パスワードは、デジタル署名の生成に使用されます。デジタル署名はメッセージ送信者または文書の署名者の本人認証を行います。これにより、送信されたメッセージの元の内容が変更されていないことが保証されます。
デジタル証明書は必須
参加者は、デジタル署名されたヒューマン・タスクの否認防止のために、デジタル証明書を保持する必要があります。参加者の資格証明は、デジタル証明書によって証明されます。デジタル証明書は認証局（CA）が発行します。 次の情報が記載されています。
名前
シリアル番号
有効期限
証明書所有者の公開鍵のコピー（メッセージとデジタル署名の暗号化に使用）
証明書発行者のデジタル署名（メッセージ信頼性の証明）
認証局の名称とCRLおよび発行認証局のURLは、個別に構成する必要があります。
「OK」をクリックします。
詳細は、第29.1.10項「エビデンス・ストア・サービスとデジタル署名」を参照してください。
デジタル署名を使用するには、信頼できるCAをworkflow-config.xmlファイルに指定する必要があります。 このCAから発行された証明書のみが、ヒューマン・ワークフローで有効と見なされます。
認証局を指定する手順は、次のとおりです。
workflow-config.xmlファイルを編集し、信頼できるCAを指定します。
<trustedCAList>
<trustedCA CAName="CN=VeriSign Class 1 Individual Subscriber CA
-G2,OU=Persona Not Validated,OU=Terms of use at
https://www.verisign.com/rpa(c)05,OU=VeriSign Trust Network,O=VeriSign\,
Inc.,C=US"
CAURL="http://IndC1DigitalID-crl.verisign.com/IndC1DigitalID.crl"/>
<trustedCA CAName="CN=Thawte Personal Freemail Issuing CA,O=Thawte
Consulting (Pty) Ltd.,C=ZA"
CAURL="http://crl.thawte.com/ThawtePersonalFreemailIssuingCA.crl"/>
</trustedCAList>
これらのCAは、単に表示するために使用されます。 これらの値は、使用前に検証する必要があります。
参加者が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。アクセス・ルールは、タスクの取得および更新時にタスク・オブジェクトにルールを適用するワークフロー・サービスによって規定されます。
|
注意: タスク・コンテンツ・アクセス・ルールおよびタスク・アクション・アクセス・ルールは相互に独立して存在します。 |
アクセス・ルールは、次の詳細に基づいて算定されます。
アクセス・ルールに対応して構成されていないロールの権限は、アクセス・ルールで構成された属性によって却下されます。たとえば、割当て先が読み取るペイロードを構成するとします。 このアクションによって、割当て先のみに読取り権限を指定できます。割当て先も含めて、誰にも書込み権限はありません。
アクセス・ルールで構成されない属性には、すべての権限があります。
ペイロードのメッセージ属性がアクセス・ルールで構成されている場合は、競合の可能性があるためにペイロード自体の構成は無視されます。この場合、APIが返すマップにはペイロードの入力項目は含まれません。読取り権限は、書込み権限によって自動的に提供されます。
メッセージ属性のサブセットのみがアクセス・ルールで構成されている場合、影響を受けないすべてのメッセージ属性には、すべての権限があります。
追加権限があるのは、コメントと添付ファイルのみです。
特定の属性への書込み権限は意味がありません。たとえば、履歴の書込み権限によって、履歴に対する権限が付与されたり、却下されることはありません。
次の日付属性は、ヒューマン・タスク・エディタでは1つの属性として構成されます。TaskMetadataService.getVisibilityRules()が返すマップには、それぞれ1つのキーがあります。同様に、参加者にDATESの読取り権限がない場合、タスクには次のタスク属性のいずれも含まれません。
START_DATE
END_DATE
ASSIGNED_DATE
SYSTEM_END_DATE
CREATED_DATE
EXPIRATION_DATE
ALL_UPDATED_DATE
次の割当て先属性は、ヒューマン・タスク・エディタでは1つの属性として構成されます。TaskMetadataService.getVisibilityRules()が返すマップには、次の割当て先属性のそれぞれに対して1つのキーがあります。同様に、参加者にASSIGNEESの読取り権限がない場合、タスクには次のタスク属性のいずれも含まれません。
ASSIGNEES
ASSIGNEE_USERS
ASSIGNEE_GROUPS
ACQUIRED_BY
フレックス・フィールドには、TaskMetadataService.getVisibilityRules()が返すマップ内に個別の表示はありません。
TaskMetadataService.getVisibilityRules()が返すマップにあるすべてのメッセージ属性には、ITaskMetadataService.TASK_VISIBILITY_ATTRIBUTE_PAYLOAD_MESSAGE_ATTR_PREFIX (PAYLOAD)の接頭辞が付きます。
アプリケーションでは、アクセス・ルールに基づいてタスク属性を表示するページ（または表示しないページ）も作成できます。これは、oracle.bpel.services.workflow.metadata.ITaskMetadataServiceでAPIをコールして参加者のアクセス・ルールを取得することで実行できます。 例25-1に詳細を示します。
例25-1 APIコール
public Map<String, IPrivilege> getTaskVisibilityRules(IWorkflowContext context,
String taskId)
throws TaskMetadataServiceException;
この方法の詳細は、『Oracle Fusion Middleware Workflow Services Java API Reference for Oracle BPEL Process Manager』を参照してください。
特定のタスク・コンテンツ（ペイロードなど）の操作を特定のユーザー（タスクの作成者または所有者など）に許可する権限を指定できます。
タスク・コンテンツの操作についてユーザー権限を指定する手順は、次のとおりです。
「詳細設定」セクションの「タスク・コンテンツおよびアクションのデフォルト・アクセスをオーバーライドします」フィールドで、「表示の構成」をクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
アクセス権を指定するタスク・コンテンツ（この例ではPAYLOAD）を選択します。
図25-66に示すように、「編集」アイコンをクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
タスク・コンテンツを操作するユーザーに権限（読取り、書込みまたはアクセスなし）を割り当てます。ユーザーには、最高レベルを超えて権限を割り当てることはできません。たとえば、ADMINユーザーにPAYLOADタスク・コンテンツに対する書込み権限を割り当てることはできません。割り当てようとすると、エラーが発生します。 表25-16に、タスク・コンテンツに対する各ユーザーの最大権限を示します。
表25-16 タスク・コンテンツに対するユーザーの最高権限レベル
| タスク・コンテンツ | 読取り権限保持者 | 書込み権限保持者 |
|---|---|---|
|
PAYLOAD |
ADMIN、APPROVERS、REVIEWERS |
ASSIGNEES、CREATOR、OWNER |
|
ASSIGNEES |
ASSIGNEES、CREATOR、OWNER、ADMIN、APPROVERS、REVIEWERS |
|
|
ATTACHMENTS |
ADMIN、APPROVERS |
ASSIGNEES、CREATOR、OWNER、REVIEWERS |
|
COMMENTS |
ADMIN、APPROVERS |
ASSIGNEES、CREATOR、OWNER、REVIEWERS |
|
DATES |
ASSIGNEES、CREATOR、OWNER、ADMIN、APPROVERS、REVIEWERS |
|
|
FLEXFIELDS |
ADMIN、APPROVERS、REVIEWERS |
ASSIGNEES、CREATOR、OWNER |
|
HISTORY |
ASSIGNEES、CREATOR、OWNER、ADMIN、APPROVERS、REVIEWERS |
-- |
|
REVIEWERS |
ASSIGNEES、CREATOR、OWNER、ADMIN、APPROVERS、REVIEWERS |
-- |
|
ペイロード要素 |
ペイロードから継承 |
ペイロードから継承 |
たとえば、PAYLOADタスク・コンテンツについて、ASSIGNEES、CREATORおよびOWNERの書込みアクセス権、ADMIN、APPROVERSおよびREVIEWERSの読取りアクセス権、およびアクセス権がないPUBLICというデフォルト設定をそのまま使用すると、ダイアログは図25-67に示すように表示されます。
「OK」をクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログに戻ります。
ダイアログの下部にある「アクセス・レベルの高い方が低い方より優先されます」ラジオ・ボタンと「アクセス・レベルの低い方が高い方より優先されます」ラジオ・ボタンは、次のシナリオに対応しています。
所有者、作成者、割当て先など、タスクで1つ以上のロールを果たすユーザー
複数のグループに属しているユーザー
複数のアプリケーション・ロールが付与され、各ロールに異なるアクセス・レベルが定義されているユーザー
環境に適したオプションを選択します。 図25-17に詳細を示します。
表25-17 アクセス・ルール・モード
| オプション | 選択する場合 |
|---|---|
|
アクセス・レベルの高い方が低い方より優先されます |
次のいずれかに該当する場合に選択し、ユーザーによるタスクのアクションの実行またはタスクの属性の変更を許可します。
|
|
アクセス・レベルの低い方が高い方より優先されます |
次のいずれかに該当する場合に選択し、ユーザーによるタスクのアクションの実行またはタスクの属性の変更を防止します。
|
|
注意: システムで許可されている内容とは別に、アクセス・ルールは、常にアクションの実行者とタスクの現在の状態に基づいて適用されます。 |
タスク・コンテンツ（ペイロードなど）の操作について、図25-67の「タスク・コンテンツ・アクセスの設定」ダイアログで指定した特定のユーザー（タスクの作成者または所有者など）に許可するアクション（アクセスまたはアクセスなし）を指定できます。
タスクの操作に対してアクションを指定する手順は、次のとおりです。
「詳細設定」セクションの「タスク・コンテンツおよびアクションのデフォルト・アクセスをオーバーライドします」フィールドで、「表示の構成」をクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
「タスク・アクション」タブをクリックします。
ユーザーを指定するタスク・アクションを選択します。
図25-68に示す「編集」アイコンをクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
図25-69に示すように、選択したアクションを参加者が実行できるかどうかを選択します。
「OK」をクリックします。
「タスク・コンテンツ・アクセスの設定」ダイアログに戻ります。
「アクセス・レベルの高い方が低い方より優先されます」ラジオ・ボタンと「アクセス・レベルの低い方が高い方より優先されます」ラジオ・ボタンがダイアログの下部に表示されます。
これらのラジオ・ボタンの使用方法は、手順6を参照してください。
コールバック・クラスを介してタスクを再割当てまたはルーティングできるユーザーを制限できます。
タスク割当てに対して制限を指定する手順は、次のとおりです。
「詳細設定」セクションの「制限付き割当ての指定」フィールドで、「制限付き割当ての設定」をクリックします。
「制限付き割当ての設定」ダイアログが表示されます。
クラス名を入力します。入力するクラスは、oracle.bpel.services.workflow.task.IRestrictedAssignmentCallbackインタフェースを実装している必要があります。
「追加」アイコンをクリックし、コールバックを起動する際に渡すプロパティ・マップの名前と値のペアを追加します。
「OK」をクリックします。
通常、BPELプロセスはワークフロー・コンポーネントをコールしてユーザーにタスクを割り当てます。ワークフローが完了すると、ヒューマン・ワークフロー・サービスはBPELプロセスにコールバックされます。ただし、詳細なコールバック（たとえば、onTaskUpdateまたはonTaskEscalated）をBPELプロセスに送信する場合は、このオプションを使用する必要があります。
このコールバック設定については、BPELダイアグラムを必ず手動でリフレッシュしてください。
BPELコールバックのタスクとルーティングのカスタマイズを許可する手順は、次のとおりです。
「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。
Oracle BPELデザイナに戻ります。
タスクのアクティビティ・ダイアログを開きます。
「OK」をクリックします。
これにより、タスクのscopeアクティビティ内に、BPELコールバックをカスタマイズするためのwhile、pick、およびpickアクティビティのonMessageブランチが作成されます。
Oracle BPM Worklistでは、ワークフロー履歴全体（参加者のルーティング全体）またはタスク履歴のみを表示できます。
「詳細設定」セクションで、「グラフィカル履歴全体の表示」をクリックします。
注釈は、タスク定義の様々な属性へのラベル付けに使用されます。この機能は、ビジネス・ユーザーが設計したモデルをOracle BPEL Process Managerの完全なヒューマン・タスク定義に変換する際に、Oracle Business Process Analysisで使用されます。ビジネス・ユーザーが開発者またはITユーザーのために挿入したコメントは、変換時に注釈として保存されます。 開発者またはITユーザーは、保存された注釈を使用してモデリング・プロセスを完了します。
ヒューマン・タスクの変更は、いつでも保存できます。「アプリケーション・ナビゲータ」でメタデータ・タスク構成ファイル（.task）をクリックすると、後でタスクを再編集できます。
ヒューマン・タスク・エディタを終了し、変更内容を保存する手順は、次のとおりです。
「ファイル」メイン・メニューから「保存」を選択するか、「X」記号（図25-70を参照）をクリックして、.taskメタデータ・タスク構成ファイルを閉じます。
「X」記号をクリックした場合は、プロンプトで「はい」を選択して変更内容を保存します。
SOAコンポジット・エディタで作成したヒューマン・タスク・サービス・コンポーネントをBPELプロセスに関連付ける場合は、次の指示に従います。 関連付けが完了すると、Oracle BPELデザイナにタスク・サービス・パートナ・リンクが作成されます。 タスク・サービスでは、タスクの実行に必要な操作が公開されます。
ヒューマン・タスクの作成方法の詳細は、第25.3項「ヒューマン・タスク・エディタでのヒューマン・タスク定義の作成」を参照してください。
ヒューマン・タスク・コンポーネントをBPELプロセスに関連付けるには、2つの方法があります。
SOAコンポジット・アプリケーションでヒューマン・タスク・コンポーネントを作成した場合は、Oracle BPELデザイナのBPELプロセスにヒューマン・タスク・アクティビティをドラッグします。 次に、「ヒューマン・タスクの作成」ダイアログの「タスク定義」リストから、既存のヒューマン・タスク・コンポーネントを選択します。 これで、タスクのタイトル、起案者、パラメータ値および他の値を指定できます。
ヒューマン・タスク・コンポーネントを作成していない場合は、Oracle BPELデザイナのBPELプロセスにヒューマン・タスク・アクティビティをドラッグします。次に、「ヒューマン・タスクの作成」ダイアログの「タスク定義」リストの右側にある「追加」アイコンをクリックします。 これで、新しいヒューマン・タスク・コンポーネントの名前、パラメータおよび結果を指定できます。 次に、残りのタスク・メタデータを設計するためのヒューマン・タスク・エディタが開きます。 設計完了後、ヒューマン・タスク・エディタを閉じます。
ヒューマン・タスクをBPELプロセスに関連付ける手順は、次のとおりです。
SOAコンポジット・エディタに移動します。
ヒューマン・タスク・サービス・コンポーネントの.taskファイルを関連付ける先のBPELプロセス・サービス・コンポーネントをダブルクリックします。
「コンポーネント・パレット」から「BPEL」を選択します。
BPELアクティビティを開きます。
新規のHuman TaskアクティビティをBPELプロセスにドラッグ・アンド・ドロップします。
「ヒューマン・タスクの作成」ダイアログが表示されます。
|
注意: このアクティビティをOracle JDeveloperに初めてドラッグした場合、ダイアログには「ヒューマン・タスクの作成」という名前が指定されます。このダイアログで詳細を指定して「OK」をクリックすると、このダイアログの名前は「Human Task」に変わります。 |
「一般」タブの「タスク定義」リストから、ヒューマン・タスクを選択します（図25-71を参照）。
ヒューマン・タスク・サービス・コンポーネントの.taskファイルがBPELプロセスに関連付けられます。
|
注意: ヒューマン・タスク・アクティビティをBPELプロセスに関連付けて「ヒューマン・タスクの作成」ダイアログを閉じた後は、そのヒューマン・タスク・アクティビティをOracle BPELデザイナでダブルクリックして、このダイアログにいつでも再アクセスできます。 |
BPELプロセスとそのプロセスが起動するヒューマン・タスク・サービス・コンポーネント間のワイヤを削除すると、ヒューマン・ワークフローのinvokeアクティビティがBPELプロセスから削除されます。 ただし、アクションを実行する（承認、却下、その他のタスクの結果を含む）「taskSwitch」switchアクティビティはそのまま残ります。 このように設計されている理由は、次のとおりです。
switchアクティビティには、ユーザーが入力したBPELコードが格納されています。
このswitchは、ワイヤの削除が単に別のヒューマン・タスクを指すことを意図している場合は再利用できます。
switchの削除はシングルステップのアクションです。
次に、同じ「taskSwitch」switchアクティビティを使用するためにヒューマン・タスク・サービス・コンポーネントをBPELプロセスにドラッグ・アンド・ドロップすると、新しい「taskSwitch」switchアクティビティが作成されます。 BPELプロセスに同じ名前の2つのswitchアクティビティが存在する状態になります。 どちらを削除するかを判断するには、「taskSwitch」switchアクティビティの承認、却下および他の結果を調査し、修正した古いswitchと新しいswitchを判断する必要があります。
図25-72に、ヒューマン・タスクを選択した後に表示される「一般」タブを示します。
「Human Task」アクティビティ・ダイアログの「一般」タブでは、表25-18に示す操作を実行できます。
タスクのタイトルは、実行時にOracle BPM Worklistに表示されます。これは必須フィールドです。 第25.3.4.1項「タスクのタイトルの指定」の説明に従ってヒューマン・タスク・エディタの「タイトル」フィールドに入力したタスクのタイトルは、このフィールドに入力したタイトルによって上書きされます。
タスクのタイトルを指定する手順は、次のとおりです。
「一般」タブの「タスクのタイトル」フィールドに、次のいずれかの方法でタスクのタイトルを入力します。
タイトルを手動で入力します。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示し、タイトルを動的に作成します。
同じタイトルに静的なテキストと動的な式を併用することもできます。動的なテキストを使用するには、テキストの適切な位置にカーソルを置き、右側にあるアイコンをクリックして「式ビルダー」ダイアログを起動します。
タスク起案者を指定できます。起案者とは、タスクを開始するユーザーです。 起案者は、作成したタスクをOracle BPM Worklistで参照したり、特定のタスク（タスクの取消し、一時停止など）を実行することができます。
タスク起案者とタスク優先度を指定する手順は、次のとおりです。
「一般」タブの「起案者」フィールドに、タスク起案者（たとえばjcooper）を入力するか、右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示し、タスク起案者を動的に指定します。このフィールドはオプションです。起案者が指定されていない場合は、「Human Task」ダイアログの「詳細」タブで指定したタスク所有者にデフォルト設定されます。タスク所有者も指定されていない場合、起案者はbpeladminにデフォルト設定されます。
「優先度」リストで1（最高値）から5の優先度値を選択します。これはユーザーが参照するためのフィールドで、このタスクの優先度が実行時に高くなることはありません。 優先度を使用すると、Oracle BPM Worklistでタスクをソートできます。ヒューマン・タスク・エディタの「優先度」リストで選択した優先度値は、この優先度値によって上書きされます。
ヒューマン・タスク・エディタの優先度の指定の詳細は、第25.3.4.1項「タスクのタイトルの指定」を参照してください。
「タスクのタイトル」および「起案者」フィールドを完了すると、タスク・パラメータ表（図25-73を参照）にタスク・パラメータのリストが表示されます。
タスク・パラメータを指定する手順は、次のとおりです。
「BPEL変数」列で、「...」をダブルクリックして、タスク・パラメータをBPEL変数にマップします。マップする必要があるのは、入力データを使用するタスク・パラメータのみです。 Oracle BPM Worklistから入力された出力データの場合、対応する変数のマップは不要です。
「タスク・パラメータ」ダイアログが表示されます。
「変数」ツリー（図25-74を参照）を開き、適切なタスク変数を選択します。
「OK」をクリックします。
図25-75に示す「Human Task」ダイアログが次のように表示されます。
「OK」をクリックします。
ヒューマン・タスク・アクティビティの拡張機能を定義する場合は、「詳細」タブをクリックして第25.4.4項「ヒューマン・タスク・アクティビティの拡張機能の定義方法」に進みます。それ以外の場合は、「OK」をクリックしてヒューマン・タスク・ダイアログを閉じます。
図25-76に、「詳細」タブを示します。
「Human Task」アクティビティ・ダイアログの「詳細」タブでは、表25-19に示す操作を実行できます。
表25-19 「Human Task」 - 「詳細」タブ
| フィールド | 参照先 |
|---|---|
|
スコープ名 グローバル・タスク変数名 |
第25.4.4.1項「スコープ名とグローバル・タスク変数名の指定」 |
|
所有者 |
|
|
識別キー |
|
|
アイデンティティ・コンテキスト |
第25.4.4.4項「アイデンティティ・コンテキストの指定」 |
|
アプリケーション・コンテキスト |
第25.4.4.5項「アプリケーション・コンテキストの指定」 |
|
タスク履歴の追加元 |
第25.4.4.6項「他のヒューマン・タスクのタスク履歴の追加」 |
デフォルトのスコープ名とグローバル・タスク変数名は、ヒューマン・タスク・アクティビティの作成時に自動的に入力されます。ただし、ヒューマン・タスク・アクティビティの作成時にスコープとグローバル変数に名前を指定するためのカスタム名は指定できます。
スコープ名およびグローバル・タスク変数名を指定する手順は、次のとおりです。
「詳細」タブの「スコープ名」フィールドに、生成するBPELスコープの名前を入力します。
このBPELスコープにより、ワークフロー・サービスとBPEL変数の操作を使用する相互作用全体がカプセル化されます。
「詳細」タブの「グローバル・タスク変数名」フィールドに、グローバル・タスク変数名を入力します。
これは、ワークフローの相互作用に使用されるBPELタスク変数の名前です。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、タスク割当て先のユーザーにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。
「Human Task」ダイアログの「一般」タブでタスク起案者を指定しない場合は、ここで指定した所有者にデフォルト設定されます。
タスク所有者を指定する手順は、次のとおりです。
「詳細」タブの「所有者」フィールドに、タスク所有者名を入力するか、右側にあるアイコンをクリックし、「式ビルダー」を使用してこのタスクの所有者を動的に指定します。
識別キーは、タスクのユーザー定義IDとして使用できます。たとえば、注文書の承認に関するタスクの場合は、タスクの識別キーとして注文書IDを設定できます。 タスクは、識別キーを使用してOracle BPM Worklistで検索できます。この属性にデフォルト値はありません。
識別キーを指定する手順は、次のとおりです。
「詳細」タブの「識別キー」フィールドに、必要に応じて識別キー値を入力します。
複数のレルムが構成されている場合は、タスクに対してアイデンティティ・レルム名が使用されます。 同じタスクを実行している複数のレルムから割当て先を指定することはできません。 複数のレルムを使用している場合、このフィールドは必須です。
アイデンティティ・コンテキストを指定する手順は、次のとおりです。
「詳細」タブの「アイデンティティ・コンテキスト」フィールドに、値を入力します。
アプリケーションのストライプ名には、タスクで使用されるアプリケーション・ロールが含まれます。
アプリケーション・コンテキストを指定する手順は、次のとおりです。
「詳細」タブの「アプリケーション・コンテキスト」フィールドに、値を入力します。
この機能により、あるヒューマン・タスクを別のヒューマン・タスクで継続できます。複数のタスクが単一のBPELプロセスに関係する様々なシナリオがあります。たとえば、1台のコンピュータを調達するためにマネージャの承認が必要な調達プロセスがあり、そのプロセスには複数のBPELアクティビティがあり、コンピュータを購入するIT部門には別タスクがあると仮定します。マネージャが購買を承認したときに作成された承認履歴、コメントおよび添付ファイルを、第2タスクの参加者が参照する場合があります。このオプションを使用して第2タスクを第1タスクに結び付けることで、BPELプロセス内の様々なタスクをリンクできます。
連鎖したタスクの場合は、新しいタスクのタイトルをタスク・メタデータ（.taskファイル）から設定することはできません。 たとえば、既存のTaskAが新規のタスクTaskBに連鎖していると仮定します。TaskBには、ヒューマン・タスク・エディタで新しいタイトルを設定しました。このタイトルは認識されません。 したがって、連鎖したタスクに異なるタイトルが必要な場合、そのタイトルは、タスク・サービスreinitiate操作をコールする前に、タスク・インスタンスに設定する必要があります。 BPELプロセスがタスクを開始する場合は、ワークフロー・サービスAPIがコールされる前にタスクのタイトルを設定します。 JavaプログラムがワークフローAPIをプログラムでコールしている場合は、タイトルを設定する必要があります。
タスクの履歴を他のタスクに追加する手順は、次のとおりです。
「詳細」タブの「タスク履歴の追加元」チェック・ボックスを選択して、BPELプロセス内の前のワークフロー・タスクを拡張します。このチェック・ボックスを選択すると、前のタスクからタスク履歴、コメントおよび添付ファイルが追加されます。これにより、完全なエンドツーエンドの監査証跡が得られます。
ヒューマン・タスクを別のヒューマン・タスクで続行する場合は、次の情報が新規ワークフローに引き継がれます。
タスク・ペイロードと、前のワークフローでペイロードに追加された変更内容
タスク履歴
前のワークフローでタスクに追加されたコメント
前のワークフローでタスクに追加された添付ファイル
「タスク履歴の追加元」リストに、既存のワークフローがすべて表示されます。
特定のヒューマン・タスクを選択し、選択したヒューマン・タスクを拡張し（続け）ます。
たとえば、雇用プロセスを使用して、新規従業員を採用します。各面接担当者は、候補者を雇用するかどうか投票します。投票者の75%が雇用に賛成の場合、候補者は採用されます。このパーセントに満たない場合、候補者は採用されません。候補者が採用されると、HRデータベースにエントリが作成され、人事担当者は雇用プロセスを完了します。 人事担当者は、各面接担当者と、候補者に関するコメントを確認する必要があります。 このプロセスは、雇用にパラレル参加者タイプを使用することでモデリングできます。候補者が採用された場合は、データベース・アダプタを使用してHRデータベースにエントリが作成されます。 その後は、単純ワークフローにパラレル参加者タイプのタスク履歴を追加して、応募申込み書、履歴書および面接担当者のコメントを引き継ぐことができます。この単純ワークフローは、人事担当者に割り当てられます。
使用するペイロードを次の中から選択します。
古いペイロードの消去と再作成
このオプションは、この拡張されたワークフローに含まれるヒューマン・タスクのXMLファイル内のペイロード属性が異なる場合に適用できます。たとえば、履歴を含めるヒューマン・タスクのペイロード属性に、他のヒューマン・タスクのペイロードにはない属性が3個ある場合などです。
既存のペイロードの使用
このオプションは、この拡張されたワークフローに含まれるヒューマン・タスクのXMLファイル内のペイロード属性がまったく同じ場合に適用できます。
ヒューマン・タスク・アクティビティのモデリングを完了すると、デザイナでヒューマン・タスクが生成されます。
図25-77に、Oracle BPEL Process Managerでワークフロー相互作用をモデリングする方法を示します。 図25-77は、BPELコールバックがモデリングされていない場合の相互作用も示しています。 この場合、タスクが完了した後、完了したタスクを使用してBPELプロセスがコールバックされます。中間のイベントはBPELプロセス・インスタンスに伝播されません。ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。
図25-78に示すように、Oracle BPELデザイナのヒューマン・タスク・アクティビティの横にある「拡張」アイコンをクリックして、その内容を表示します。
図25-79に、Oracle BPELデザイナでのワークフロー相互作用を示します。
中間のイベントをBPELプロセス・インスタンスに伝播する必要がある場合は、ヒューマン・タスク・エディタの「詳細設定」セクションにある「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。これらのオプションが選択されている場合、ワークフロー・サービスはタスクの更新ごとにBPELインスタンス内でコールバックを起動します。次に説明するコールバックがTaskService.wsdlファイルにリストされます。
onTaskCompleted
このコールバックは、タスクの完了、期限切れ、取消しまたはエラー時に起動されます。
onTaskAssigned
このコールバックは、次のアクションが原因でタスクが一連の新規の割当て先に割り当てられるときに起動されます。
結果の更新
現在の割当てのスキップ
ルーティング・スリップの上書き
onTaskUpdated
このコールバックは、onTaskCompleteまたはonTaskAssignedコールバックに該当しないタスクに対する他の更新の際に起動されます。 これには、情報のリクエスト、情報の発行、エスカレーション、再割当てなどによるタスクの更新が含まれます。
onSubTaskUpdated
このコールバックは、サブタスクに対する更新の際に起動されます。
図25-80に、Oracle BPEL Process Managerでコールバックを使用したワークフロー相互作用をモデリングする方法を示します。 このタスクが開始されると、タスクが完了するまでwhileループを使用してメッセージが受信されます。whileループには、4つのonMessageブランチ（前述したコールバック操作ごとに1つずつ）を備えたpickアクティビティが含まれています。ワークフロー相互作用は、onMessageブランチに何も変化がなくても正常に機能します。つまり、onMessageブランチでのカスタマイズは不要です。
このシナリオでは、ワークフロー・コンテキストはBPELインスタンスで取得されます。このコンテキストは、ワークフロー・サービスとのすべての相互作用に使用できます。 たとえば、グループに割り当てられているタスクを再度割り当てる場合、タスク・サービスには、reassignTask操作のワークフロー・コンテキストが必要です。
ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。
図25-81に、Oracle JDeveloperにおけるワークフロー相互作用を示します。
図25-81 Oracle JDeveloperにおけるワークフロー相互作用のモデリング（コールバックを使用）
生成されたヒューマン・タスク・アクティビティを変更する必要がある場合は、次の詳細に注意してください。
ヒューマン・タスクをBPELプロセス・フローに追加するときは、switchアクティビティ内に自動的に作成されるassignタスクを変更しないでください。 かわりに、switchアクティビティの外部に新しいassignアクティビティを追加します。
ヒューマン・タスクに渡されるパラメータを変更した場合（たとえば、「タスク・パラメータの編集」ダイアログでパラメータ・タイプを変更した場合）は、BPELプロセス・フローのヒューマン・タスク・アクティビティを開いて「OK」をクリックし、ペイロード変数の参照を修正する必要があります。 修正しないと、パラメータ名が変わり、編集不可になります。
ヒューマン・タスク・エディタでタスクの結果を変更した場合は、ヒューマン・タスク・アクティビティを編集し、「OK」をクリックする必要があります。 switch caseは、結果に対する変更に基づいて更新されます。
ヒューマン・タスクで生成されたパートナ・リンク（たとえば、「パートナ・リンク」スイムレーンのhuman_task_name.TaskService）を削除すると、ヒューマン・タスクが使用不可になります。 パートナ・リンクを削除した場合は、Oracle BPELデザイナでヒューマン・タスク・アクティビティを削除して、再起動する必要があります。
多くの場合、ビジネス・プロセスのフローは、タスクの結果によって決定されます。ビジネス・ロジックのモデリングを容易にするため、ユーザー・タスクの生成時には、BPELのswitchアクティビティがビルトインのcaseアクティビティとともに生成されます。デフォルトでは、タスクの作成時に選択した結果ごとに1つのcaseブランチが作成されます。また、タスクの取消し、期限切れ、エラー発生の各状態に対応するotherwiseブランチもswitchに生成されます。
転送されるタスクには、ペイロードが含まれます。ペイロードがビジネス・プロセス変数から設定されている場合は、ペイロードをタスクからソースにコピーして戻すために、copyPayloadFromTaskという名前のassignアクティビティが各caseおよびotherwiseブランチに作成されます。ペイロードが他のXPath式（ora:getNodes(...)など）で表現されている場合は、ペイロードをコピーするためのプロセス変数が存在しないため、このassignは作成されません。 ペイロードを変更する必要がない場合、このassignは削除できます。
デフォルトでは、switchアクティビティには通常の結果のみに対応するcase文が含まれています。その他のタスクの結果は、otherwiseブランチで取得されます。これらの結果は、次のとおりです。
タスクの取消し
タスクでのエラー発生
タスクの期限切れ
ビジネス・ロジックをその他の結果にそれぞれ追加する必要がある場合は、case文をこれらの各条件に追加できます。case文は、次のBPELセグメントのように作成できます。 その他の結果に対応する各caseアクティビティのXPath条件は、例25-2の中で太字で示されています。
例25-2 その他の結果に対応する各caseアクティビティのXPath条件
<switch name="taskSwitch">
<case condition="bpws:getVariableData('SequentialWorkflowVar1',
'/task:task/task:state') = 'COMPLETED' and
bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:conclusion') = 'ACCEPT'">
<bpelx:annotation>
<bpelx:pattern>Task outcome is ACCEPT
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'WITHDRAWN'">
<bpelx:annotation>
<bpelx:pattern>Task is withdrawn
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'EXPIRED'">
<bpelx:annotation>
<bpelx:pattern>Task is expired
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') =
'ERRORED'">
<bpelx:annotation>
<bpelx:pattern>Task is errored
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<otherwise>
<bpelx:annotation>
<bpelx:pattern>Task is EXPIRED, WITHDRAWN or ERRORED
</bpelx:pattern>
</bpelx:annotation>
...
</otherwise>
</switch>
