| Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド 11gリリース1 (11.1.1.7) B56238-10 |
|
 前 |
 次 |
この章では、ヒューマン・タスクの異なるプロパティを構成する方法について説明します。基本的なプロパティ、タスク・ペイロード・データ構造、参加者の割当て、ルーティング・ポリシー、ローカライズ、エスカレーション、通知プリファレンス、アクセス・ポリシーとタスク・アクション、制限、およびJavaコールバックとビジネス・イベント・コールバックについて説明します。
この章では、次の項目について説明します。
ヒューマン・ワークフローの問題のトラブルシューティングの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。
この項では、ヒューマン・タスク・エディタのセクションにアクセスする方法について説明します。各セクションについて簡単に説明し、詳細の参照先を示します。
ヒューマン・タスク・エディタのセクションにアクセスする手順は、次のとおりです。
SOAコンポジット・エディタの「ヒューマン・タスク」アイコンをダブルクリックするか、Oracle BPELデザイナの「ヒューマン・タスク」アイコンをダブルクリックして、右上隅にある「編集」アイコンをクリックします。
ヒューマン・タスク・エディタは、図29-1の左側に示す主要なセクションで構成されています。これらのセクションを使用すると、ヒューマン・タスクのメタデータを設計できます。
表29-1に、ヒューマン・タスク・エディタのこれらの主要なセクションを使用してワークフロー・タスクを作成する方法を示します。
表29-1 ヒューマン・タスク・エディタ
| セクション | 説明 | 参照先 |
|---|---|---|
|
一般 (「タイトル」、「説明」、「結果」、「カテゴリ」、「優先度」、「所有者」および「アプリケーション・コンテキスト」) |
タスクの詳細(タイトル、タスクの結果、所有者、その他の属性など)を定義できます。 |
第29.2項「タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストの指定」 |
|
データ |
タスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を定義できます。 |
|
|
割当て |
参加者をタスクに割り当て、そのタスクをワークフローを使用してルーティングするためのポリシーを作成できます。 |
|
|
プレゼンテーション |
次の設定を指定できます。
|
|
|
期限 |
タスクの有効期間、カスタム・エスカレーションJavaクラスおよび期日を指定できます。 |
|
|
通知 |
ユーザーにタスクが割り当てられたとき、またはタスクのステータスが変化したときの通知を作成して送信できます。 |
|
|
アクセス |
タスク・コンテンツとタスク・アクションのアクセス・ルール、ワークフロー署名ポリシーおよび割当て制限を指定できます。 |
第29.9項「タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定」 第29.9.2項「ワークフロー・デジタル署名ポリシーの指定方法」 |
|
イベント |
コールバック・クラスおよびBPELコールバックでのタスクとルーティングの割当てを指定できます。 |
第29.11項「Javaコールバックまたはビジネス・イベント・コールバックの指定」 |
|
ドキュメント |
第29.12項「Oracle Enterprise Content Managementでのドキュメントの格納」 |
この項では、次の内容を説明します。
タイトル、説明、結果、優先度、カテゴリ、所有者およびアプリケーション・コンテキストを指定する手順は、次のとおりです。
「一般」タブをクリックします。
図29-2に、ヒューマン・タスク・エディタの「一般」セクションを示します。
このセクションでは、タスクのタイトル、説明、結果、カテゴリ、優先度、所有者などの詳細を指定できます。
表29-2に、「一般」セクションの各サブセクションの構成方法を示します。
表29-2 ヒューマン・タスク・エディタ - 「一般」セクション
| サブセクション | 参照先 |
|---|---|
|
タイトル |
|
|
説明 |
|
|
結果 |
|
|
優先度 |
|
|
カテゴリ |
|
|
所有者 |
|
|
アプリケーション・コンテキスト |
第29.2.8項「アプリケーション・コンテキストの指定方法」 |
タスクのタイトルを指定する手順は、次のとおりです。
タスクのタイトルを入力します(オプション)。開始したタスクにタイトルが設定されていない場合のみ、この値がタイトルにデフォルト設定されます。このタイトルによって、タスクが視覚的に識別されます。タスクのタイトルはOracle BPM Worklistに表示されます。タイトルは、Oracle BPM Worklistで検索することもできます。
「一般」セクションの「タスクのタイトル」フィールドで、タスクのタイトルを指定する方法を選択します。
プレーン・テキスト: 名前(承認された休暇申請など)を手動で入力します。
テキストとXPath: 手動によるテキストと動的な式の組合せを入力します。タイトルの一部(注文IDに必要な承認:など)を手動で入力した後、テキストの右側の空白にカーソルを置き、このフィールドの右側にあるアイコンをクリックします。この操作によって、タイトルの残りの部分を動的に作成するための式ビルダーが表示されます。名前の動的部分を完成した後は、「OK」をクリックし、このフィールドに戻ります。完全な名前が表示されます。例:
Approval Required for Order Id: <%/task:task/task:payload/task:orderId%>
式は、実行時にタスク・ペイロードからの正確な注文ID値を使用して解決されます。
第28.4.3.1項「タスクのタイトルの指定」の説明に従って、「ヒューマン・タスクの作成」ダイアログの「一般」タブで「タスクのタイトル」フィールドにタイトルを入力すると、ここで入力したタイトルはオーバーライドされます。
必要に応じて、「一般」セクションの「説明」フィールドにタスクの説明を指定できます。説明を使用すると、タスクに関する補足的な詳細を提供できます。たとえば、タスクのタイトルがコンピュータのアップグレード・リクエストの場合、このフィールドには、コンピュータのモデル、CPUの能力、RAM容量などの補足的な詳細を記載できます。この説明は、Oracle BPM Worklistには表示されません。
タスクの結果により、タスクに可能な結果が取得されます。Oracle BPM Worklistには、ここで指定した結果が実行時に実行可能なタスク・アクションとして表示されます。図29-3に詳細を示します。
次のタイプのタスクの結果を指定できます。
シード済結果の選択
カスタム結果の入力
タスクの結果には、ここで指定した実際の結果値とは異なる実行時の表示値を割り当てることもできます。これにより、Oracle BPM Worklistでは、結果を異なる言語で表示できます。国際化の詳細は、第29.6.2項「多言語設定の指定方法」を参照してください。
タスクの結果を指定する手順は、次のとおりです。
「一般」セクションの「結果」フィールドの右側にある「検索」アイコンをクリックします。
タスクに予想される結果が「結果ダイアログ」(図29-4を参照)に表示されます。「APPROVE」および「REJECT」はデフォルトで選択されています。
表29-3に示す情報を入力します。
表29-3 結果ダイアログ
| フィールド | 説明 |
|---|---|
|
1つ以上の結果の選択 |
追加するタスク結果を選択するか、デフォルトの結果を選択解除します。 |
|
「追加」アイコン |
クリックすると、カスタム結果を追加するダイアログが起動されます。 ダイアログの「名前」フィールドにカスタム名を入力し、「OK」をクリックします。結果が「結果」フィールドに表示されます。 注意: 次のネーミング制限を考慮してください。
|
|
コメントが必要な結果 |
クリックすると、実行時にOracle BPM Worklistで割当て先がコメントを追加する結果を選択できます。割当て先は、実行時にタスクを保存しないでコメントを追加し、アクションを実行する必要があります。 |
|
デフォルトの結果 |
この結果に対するデフォルトの結果を選択します。 |
ここで選択したシード済結果とカスタム結果が、パラレル参加者タイプの「多数決の結果」セクションに表示され、選択できます。
詳細は、第29.4.4.1項「投票結果の指定」を参照してください。
タスクの優先度を指定します。優先度は、1から5までで、1が最高値です。タスクの優先度は、デフォルトで3に設定されています。この優先度値は、「ヒューマン・タスクの作成」ダイアログの「一般」タブで優先度値を選択するとオーバーライドされます。優先度に基づいてタスクをフィルタ処理し、Oracle BPM Worklistで優先度のビューを作成できます。
タスク優先度を指定する手順は、次のとおりです。
「一般」セクションの「優先度」リストで、タスクの優先度を選択します。
「ヒューマン・タスクの作成」ダイアログでの優先度値の指定方法の詳細は、第28.4.3.2項「タスク・イニシエータとタスク優先度の指定」を参照してください。
タスク・カテゴリは、必要に応じて、「一般」セクションの「カテゴリ」フィールドに指定できます。この指定によって、システムで作成されるタスクのカテゴリが決まります。たとえば、ヘルプ・デスク環境では、顧客のリクエストをソフトウェア関連またはハードウェア関連として分類できます。カテゴリはOracle BPM Worklistに表示されます。カテゴリに基づいてタスクをフィルタ処理し、Oracle BPM Worklistでカテゴリのビューを作成できます。
タスク・カテゴリを指定する手順は、次のとおりです。
「一般」セクションの「カテゴリ」フィールドでタスク・カテゴリを指定する方法を選択します。
名前別: 名前を手動で入力します。
式別: このフィールドの右側にあるアイコンをクリックし、カテゴリを動的に作成するための式ビルダーを表示します。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、割当て済タスクの参加者タイプのいずれかにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。タスク所有者は、タスクのビジネス管理者と見なすことができます。また、タスク所有者は、第28.4.4.2項「タスク所有者の指定」の説明に従って、「ヒューマン・タスクの作成」ダイアログの「詳細」タブで指定することもできます。「詳細」タブで指定されているタスク所有者は、ここで入力するタスク所有者よりも優先されます。
タスク所有者の詳細は、第27.2.1.3項「タスクのステークホルダ」を参照してください。
タスク所有者を指定する手順は、次のとおりです。
タスク所有者の指定方法を選択します。
アイデンティティ・サービスのユーザー・ディレクトリまたはアプリケーション・ロールのリストを介して静的に指定
XPath式を介して動的に指定
例:
タスクに、ownerが格納されているpoという名前のペイロード・メッセージ属性がある場合は、/task:task/task:payload/po:purchaseOrder/po:ownerなどのXPath式を指定できます。
ids:getManager('jstein', 'jazn.com')
jsteinのマネージャがタスク所有者です。
ユーザー、グループおよびアプリケーション・ロールの詳細は、第27.2.1.1.3項「参加者の割当て」を参照してください。
タスク所有者は、Oracle SOA Suiteで使用するように構成されたユーザー・ディレクトリ(Oracle Internet Directory、Java AuthoriZatioN (JAZN)/XML、LDAPなど)またはアプリケーション・ロールのリストを参照することで選択できます。
ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介してタスク所有者を静的に指定する手順は、次のとおりです。
「一般」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。図29-5に詳細を示します。
図29-5 ユーザー・ディレクトリまたはアプリケーション・ロールの参照によるタスク所有者の指定
「一般」セクションの「所有者」フィールドの右側にある2番目のリストで、「静的」を選択します。
選択した所有者のタイプに基づいて、表29-4の手順を参照してください。
「ユーザー」または「グループ」を選択した場合は、図29-6に示す「アイデンティティ・ルックアップ」ダイアログが表示されます。
ユーザーまたはグループを選択するには、最初にアプリケーション・サーバー接続を作成する必要があります。そのためには「追加」アイコンをクリックします。次の制約に注意してください:
アイデンティティ・サービス・レルムのリストを取得するOracle WebLogic管理サーバーに対して、アプリケーション・サーバー接続を作成しないでください。これは、この管理サーバーには、実行するアイデンティティ・サービスがないためです。したがって、「アイデンティティ・ルックアップ」ダイアログで検索パターンを使用して検索を実行した場合は、レルム情報もユーザーも表示されません。かわりに、管理対象のOracle WebLogic Serverに対してアプリケーション・サーバー接続を作成してください。
完全なドメイン名(myhost.us.example.comなど)を使用して構成されているアプリケーション・サーバー接続を選択する必要があります。ホスト名(myhostなど)のみで構成されている接続を選択すると、使用可能なレルムが「レルム」リストに表示されない可能性があります。既存の接続にドメイン名が含まれていない場合は、次の手順を実行します。
「リソース・パレット」で、アプリケーション・サーバー接続を右クリックします。
「プロパティ」を選択します。
「構成」タブで、適切なドメインをホスト名に追加します。
「アイデンティティ・ルックアップ」ダイアログに戻り、接続を再度選択します。
アプリケーション・サーバー接続を選択または作成し、選択用のレルムを表示します。レルムには、ユーザーおよびロール(グループ)のポリシー・ストアへのアクセスが用意されています。
検索文字列(jcooper、j*、*など)を入力して所有者を検索します。「ユーザー名」フィールドの右側にある「ルックアップ」アイコンをクリックすると、検索基準と一致するすべてのユーザーがフェッチされます。図29-7に詳細を示します。「選択」をクリックすると、1つ以上のユーザーまたはグループをハイライトして選択できます。
ユーザーをハイライトして「階層」をクリックし、そのユーザーの階層を表示します。同様に、「報告先」をクリックすると、選択したユーザーまたはグループの報告先が表示されます。図29-8に詳細を示します。
ユーザーまたはグループをハイライトして「詳細」をクリックし、そのユーザーまたはグループの詳細を表示します。図29-9に詳細を示します。
「OK」をクリックして「アイデンティティ・ルックアップ」ダイアログに戻ります。
「選択」をクリックして、ユーザーを「選択したユーザー」セクションに追加します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
「アプリケーション・ロール」を選択した場合は、「アプリケーション・ロールの選択」ダイアログが表示されます。
「アプリケーション・サーバー」リストで、アプリケーション・ロールが設定されているアプリケーション・サーバーのタイプを選択するか、「追加」アイコンをクリックして接続を作成するための「アプリケーション・サーバー接続の作成」ウィザードを起動します。
「アプリケーション」リストで、アプリケーション・ロールが設定されているアプリケーションを選択します(カスタム・アプリケーションまたはSOAインフラストラクチャ・アプリケーション(soa-infra)など)。
「選択可能」セクションで、適切なアプリケーション・ロールを選択し、「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。図29-10に詳細を示します。
「OK」をクリックします。
タスク所有者を「式ビルダー」ダイアログで動的に選択できます。
タスク所有者を動的に指定する手順は、次のとおりです。
「一般」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。図29-11に詳細を示します。
「一般」セクションの「所有者」フィールドの右側にある2番目のリストで、「XPath」を選択します。
アイコンをクリックして、式ビルダーを起動します。
図29-12に示す「式ビルダー」ダイアログが表示されます。
使用可能な変数のスキーマおよび関数を参照してタスク所有者を作成します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
詳細は、次を参照してください。
「式ビルダー」ダイアログとXPathビルディング・アシスタントの使用手順については、「ヘルプ」をクリックしてください。
ワークフロー・サービスのDynamic Assignment Function、アイデンティティ・サービス関数およびXPathビルディング・アシスタントの使用手順の詳細は、付録B「XPath拡張関数」を参照してください。
タスクで使用するアプリケーション・ロールが含まれているアプリケーションの名前を指定できます。これによって、アプリケーション・ロールが操作するコンテキストが指定されます。タスクを明示的に作成しなくても結果的に所有した場合は、このコンテキストを設定できます。
「一般」セクションの「アプリケーション・コンテキスト」フィールドに名前を入力します。
図29-13に、ヒューマン・タスク・エディタの「データ」セクションを示します。
このセクションでは、XSDファイルに定義されているタスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を指定できます。XSDファイルの要素を表すパラメータを作成します。これにより、ペイロード・データがワークフロー・タスクで使用できるようになります。例:
ストアフロント・アプリケーションから注文するための注文ID要素に対してパラメータを作成します。
ヘルプ・デスク・リクエストを作成するための場所、タイプ、問題の説明、重大度、ステータスおよび解決の各要素に対してパラメータを作成します。
タスク・ペイロード・データは、1つ以上の要素またはタイプで構成されます。選択内容に基づいてタスク・ペイロードのXMLスキーマ定義が作成されます。
タスク・ペイロード・データ構造を指定する手順は、次のとおりです。
「データ」タブをクリックします。
「追加」アイコンをクリックして、ペイロード・タイプを選択します。
文字列
整数
ブール
その他
図29-14に示すように、「タスク・パラメータの追加」ダイアログが表示されます。
表29-5に記載されている詳細を入力します。
表29-5 「タスク・パラメータの追加」ダイアログのフィールドと値
| フィールド | 説明 |
|---|---|
|
パラメータ・タイプ |
「タイプ」または「要素」を選択し、「検索」アイコンをクリックすると、タスク・パラメータ選択用の「タイプ・チューザ」ダイアログが表示されます。 |
|
パラメータ名 |
デフォルト名をそのまま使用するか、カスタムの名前を入力します。このフィールドが表示されるのは、パラメータ・タイプとして「タイプ」を選択した場合のみです。 |
|
ワークリストにより編集可能 |
このチェック・ボックスを選択すると、タスク・ペイロードのこの部分をOracle BPM Worklistで編集できます。たとえば、融資承認タスクの場合、APR属性は、タスクをレビューするユーザーによる更新が必要な場合がありますが、SSNフィールドは編集できません。 参加者が表示および更新できるタスクの部分を決定するアクセス・ルールも指定できます。詳細は、第29.9.1項「タスク・コンテンツへのアクセス・ポリシーの指定方法」を参照してください。 |
|
注意: Oracle BPM Worklistで定義できるのは、単純なXMLタイプ(文字列、整数など)または複雑なタイプ(注文書など)のペイロード・パラメータに対するペイロード・マップ済属性(以前はフレックス・フィールド・マッピングと呼ばれていました)のみです。キーワードを使用してタスクを検索する必要がある場合、またはタスク・コンテンツに基づいてビューまたは委任ルールを定義する必要がある場合は、単純なXMLタイプに基づいたペイロード・パラメータを使用する必要があります。これらの単純タイプは、Oracle BPM Worklistでフレックス列にマップできます。 |
図29-15に示すように、タイプを選択します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「データ」セクションに表示されます。
選択内容を編集するには、対象項目を選択して「データ」セクションの右上にある「編集」アイコンをクリックします。
図29-16に、ヒューマン・タスク・エディタの「割当て」セクションを示します。このセクションでは、ビジネス要件を満たす参加者タイプを選択できます。参加者タイプを構成するときは、タスクを操作するユーザー、グループおよびアプリケーション・ロールのリストを作成します。
単純または複雑なワークフロー・ルーティング・ポリシーを作成するためには、参加者タイプを簡単に組み合せて調整できます。以前に構成したヒューマン・タスクの機能を拡張して、より複雑なワークフローをモデリングすることもできます。
参加者タイプはステージの下のブロックにグループ化されます(たとえば、図29-16ではStage1という名前です)。ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。1つ以上のステージを順番に、またはパラレルで指定できます。各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。参加者タイプ・ブロックの順序は、[↑]キーと[↓]キーを使用して再配置できます。
例:
すべての参加者タイプ・ブロックを単一のステージに作成できます(たとえば、注文のすべての内容が全体として承認または却下される注文書リクエスト)。
より複雑な承認タスクを作成して、1つ以上のステージを含めることができます。たとえば、最初のステージに参加者タイプ・ブロックのグループを配置し、2番目のステージに他のブロックを配置できます。第1ステージに配置した参加者のリストでは明細入力の承認が処理され、第2ステージに配置した参加者のリストではヘッダー入力の承認が処理されます。
参加者タイプごとに、構成タスクに使用するエディタが関連付けられています。割当て先の追加順序は、実行順序を示します。
別のステージ名を指定したり、追加ステージの作成が必要なビジネス要件を指定するには、次の手順を実行します。追加ステージの作成は高度な要件で、自社の環境には必要がない場合があります。
この項では、次の内容を説明します。
参加者タイプの詳細は、第27.2.1.1項「タスクの割当ておよびルーティング」を参照してください。
ステージ名を指定し、パラレルおよび順次ブロックを追加する手順は、次のとおりです。
デフォルトでは、ステージに「Stage1」という名前が指定されます。この名前は、必要に応じて変更できます。
名前をダブルクリックします。
図29-17に示す「編集」ダイアログが表示されます。
名前を入力し、「OK」をクリックします。
図29-18に示すように、ステージとその参加者タイプ・ブロックを選択します。
「追加」アイコンをクリックします。
リストからオプションを選択します(たとえば、「パラレル・ステージ」)。
図29-19に示すように、第2ステージが第1ステージに対してパラレルに追加されます。
右側の第2ステージを選択し、「追加」アイコンをクリックします。第2ステージ(たとえば、図29-20ではStage1という名前です)を選択するのではなく、参加者タイプ・ブロック(たとえば、図29-20ではEdit Participantという名前です)のみを選択した場合は、「追加」アイコンの下にあるすべてのオプションが無効になります。
「順次ステージ」を選択します。
順次ステージが、選択したブロックの下に追加されます。
これらのブロック内に参加者タイプを作成します。
タスク参加者を割り当てる手順は、次のとおりです。
図29-22に、単一参加者タイプの「参加者タイプの編集」ダイアログを示します。図29-23に、展開された「詳細」セクションを示します。
タスクに対して動的に割り当てるために、単一参加者をグループ、アプリケーション・ロールまたは参加者リストから選択できます。
単一参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。
表29-7に、単一参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
参加者リストに割り当てられているユーザーは、タスクを操作できます。単一タスク参加者リストでは、タスクの操作に必要なユーザーは1人のみです。単一のユーザーか、このパターンのユーザー、グループまたはアプリケーション・ロールのリストを指定できます。リストが指定されている場合、リスト上のすべてのユーザーがタスクに割り当てられています。このうちの1人が手動でタスクを申告して操作する必要があるか、または割当てパターンによっていずれかのユーザーがリストから自動的に選択されるようにするかを指定できます。1人のユーザーがタスクを操作する場合、このタスクは他の割当て先のタスク・リストから取り消されます。
単一ユーザー参加者やパラレル、シリアルおよびFYIユーザー参加者に対して、次のような様々なタイプのリストを作成できます。
これらのリストでは、ユーザー、グループまたはアプリケーション・ロールをタスク割当て先として静的または動的に選択できます。
管理チェーンは通常、管理チェーン階層内の複数のユーザーからシリアル承認を得るために使用されます。したがって、このリストは多くの場合、シリアル参加者タイプに有効です。通常は、階層内のすべてのユーザーがタスクを操作する場合に使用します。管理チェーンは単一参加者タイプでも使用できます。ただし、この場合は、階層内のすべてのユーザーにタスクが同時に割り当てられます。1人のユーザーがタスクを操作すると、そのタスクは、他のユーザーから取り消されます。
たとえば、注文書がマネージャに割り当てられているとします。マネージャが承認した注文は、上位のマネージャに割り当てられます。そのマネージャが承認すると、さらに上位のマネージャに割り当てられ、3人のマネージャが注文を承認するまで上位へと順番にルーティングされます。条件付き中途完了を指定した場合は、マネージャのいずれかがリクエストを却下するか、リクエストの期限が切れると、注文は却下されます。それ以外の場合、タスク・フローは引き続きルーティングされます。
ビジネス・ルールを使用すると、複雑な式でタスク参加者のリストを作成できます。たとえば、$5000未満の注文書リクエストは承認のためにマネージャに送信するというビジネス・ルールを作成します。一方、$5000以上の注文書リクエストは、承認のためにマネージャのマネージャに送信します。ビジネス・ルールの2つの主要な機能は、ファクトとアクション・タイプです。詳細は、第29.5.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。
参加者タイプを選択すると、図29-24に示すように、ダイアログ・ボックスを使用してタスク参加者の割当て先(ユーザー、グループまたはアプリケーション・ロール)のリストを作成するためのオプションを選択できます。前述の3つの選択肢(「名前および式」、「管理チェーン」および「ルールベース」)を使用できます。
オプションを選択した後は、図29-25に示すように、タスク参加者割当て先(ユーザー、グループまたはアプリケーション・ロール)およびデータ型を動的に割り当てます。
この項では、これらの参加者リストの作成方法について説明します。
ユーザー、グループまたはアプリケーション・ロールをタスク参加者として静的または動的に割り当てる方法を選択します。
概念的な情報は、次を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、第27.2.1.1.3項「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、第27.2.1.2「静的、動的およびルールベースのタスク割当て」を参照してください。
値ベースの名前と式で構成される参加者リストを作成する手順は、次のとおりです。
「参加者のリストの作成で使用」リストから、「名前および式」を選択します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-26に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-26に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。
「属性の指定で使用」リストから、「値ベース」を選択します。
ダイアログがリフレッシュされ、図29-27に示すように、フィールドが表示されます。
「追加」アイコンをクリックし、ユーザー、グループまたはアプリケーション・ロールをタスク参加者として選択します。
「参加者名」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。
「識別タイプ」列での選択を変更するには、その列をクリックしてドロップダウン・リストを表示します。
「データ型」列で、現在選択されている値をクリックし、値を割り当てるドロップダウン・リストを表示します。
名前別: 識別タイプがユーザーまたはグループの場合は、右側の「参照」アイコン(...)をクリックし、アイデンティティ・サービスを介して構成されたユーザーまたはグループを選択するためのダイアログを表示します。アイデンティティ・サービスを使用すると、ユーザー・プロパティ、ロールおよびグループ・メンバーシップのルックアップが可能になります。ユーザー情報は、Oracle Internet DirectoryなどのLDAPサーバーから取得します。IDの検索にはワイルドカード(*)を使用できます。
アプリケーション・ロールを選択する場合は、「参照」アイコンをクリックし、アプリケーション・ロールを選択するための「アプリケーション・ロールの選択」ダイアログを表示します。アプリケーション・ロールを検索するには、最初にアプリケーション・サーバーへの接続を作成する必要があります。検索する際は、ロール名を見つけるためにアプリケーション名を指定する必要があります。タスク定義で参照できるのは、単一のアプリケーション名のみです。割当て先またはタスク所有者は、異なるアプリケーションのアプリケーション・ロールを使用できません。
式別: ユーザー、グループまたはアプリケーション・ロールの識別タイプについて、「参照」アイコンをクリックし、「式ビルダー」ダイアログでタスク割当て先を動的に選択します。bpws:getVariableData(...)式またはids:getManager() XPath関数を使用します。
指定した値が「値」列に表示されます。
値を手動で入力するには、「値」列のフィールドをクリックし、値を指定します。
管理チェーン・パラメータをタスク参加者として静的または動的に割り当てる方法を選択します。
概念的な情報については次を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、第27.2.1.1.3項「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、第27.2.1.2「静的、動的およびルールベースのタスク割当て」を参照してください。
管理チェーンについては、第29.4.3.1項「単一タスク参加者リストの作成」を参照してください。
値ベースの管理チェーンに基づいて参加者リストを作成する手順は、次のとおりです。
「参加者のリストの作成で使用」リストから、「管理チェーン」を選択します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して「ユーザー」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-26に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-26に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。
「属性の指定で使用」リストから、「値ベース」を選択します。
ダイアログがリフレッシュされ、図29-28に示すように、フィールドが表示されます。
「開始参加者」表のリストにユーザー、グループまたはアプリケーション・ロールを割り当てる手順の詳細は、第29.4.3.1項「単一タスク参加者リストの作成」のステップ4からステップ7を参照してください。
「最上位の参加者」リストで、タスク参加者のレベル数を割り当てる方法を選択します。
役職別: 管理チェーンの最終(最高)承認者の役職を選択します。
XPath: 「式ビルダー」ダイアログを介して最上位の参加者を動的に入力する場合に選択します。
「レベル数」リストで、最上位参加者を割り当てる方法を選択します。
番号別: このタスクに含める管理チェーンのレベル数の値を入力します。たとえば、2を入力して、タスクが最初にユーザーjcooperに割り当てられている場合は、ユーザーjstein (jcooperのマネージャ)とユーザーwfaulk (jsteinのマネージャ)の両方がリストに(最初の割当て先であるjcooperとは別に)含まれます。
XPath: 「式ビルダー」ダイアログを介して値を動的に入力する場合に選択します。
ルールセットは、ルールおよびデシジョン表の実行単位を提供します。また、ルールセットはルールの共有単位を提供します。ルールはルールセットに所属します。複数のルールセットを順に実行できます。これはルール・フローと呼ばれます。順番はルールセット・スタックで決まります。順番は、スタック上でルールセットをプッシュおよびポップするルール・アクションによって操作できます。ルールセットでは、ルールの優先度を適用することで、ルールセット内でのルールの起動順序を指定します。また、ルールセットは有効日も指定します。この指定によって、ルールセットは常に有効か、日時の範囲、開始日時または終了日時に基づいて制限されるかが識別されます。
ルールセットの作成方法は、そのルールセットへのアクセス方法に基づいています。これについては、次の項で説明しています。
|
注意: ルール・ディクショナリが作成された後は、ファクトを更新できません。 |
ルールセットに基づいて参加者リストを指定する手順は、次のとおりです。
ビジネス・ルールによって、参加者リストを定義できます。ビジネス・ルールの使用については、2つのオプションがあります。
ルールによって、特定のリスト・ビルダー(「名前および式」、「管理チェーン」など)のパラメータが定義されます。この場合、タスク・ルーティング・パターンは、特定のリスト・ビルダーを使用するようにモデリングされます。このリスト・ビルダーには、ルールで作成されたパラメータがリストされます。ルールは、Oracle JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを返します。
「参加者のリストの作成で使用」リストから、「名前および式」または「管理チェーン」を選択します。
「属性の指定で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図29-29に詳細を示します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-26に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-26に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。
「OK」をクリックします。
ルールによって、リスト・ビルダーおよびリスト・ビルダー・パラメータが定義されます。この場合は、リスト自体がルールを使用して作成されます。ルールによって、リスト・ビルダーとパラメータが定義されます。
「参加者のリストの作成で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図29-30に詳細を示します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-26に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
「OK」をクリックします。
ルール・ディクショナリが未作成で、参加者リストを簡単に指定するために複数のルール関数とファクトが事前にシードされている場合は、いずれのオプションでもルール・ディクショナリが作成されます。ルール・ディクショナリには、参加者リストを作成するための次のルール関数がシードされています。
CreateResourceList
CreateManagementChainList
Taskファクトはタスク・サービスによってアサートされ、ルール条件のベースとなります。
ルール・ディクショナリが作成されると、Oracle Business Rulesデザイナが表示されます。
ルール条件をモデリングします。アクション部分で、前述の関数のいずれか1つをコールして、リストの作成を完了します。図29-31に詳細を示します。
ルール関数のパラメータは、Oracle JDeveloperモデリングでのパラメータに類似しています。Oracle JDeveloperでの構成に加え、Oracle Business Rulesデザイナでは、次の属性について複数の追加オプションを使用できます。
responseType: レスポンス・タイプが「REQUIRED」の場合は、割当て先がタスクを操作する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。
ruleName: ルール名で割当ての理由を作成できます。
lists: このオブジェクトは、作成されるリストの所有者です。このオプションをクリックすると、事前にアサートされたファクトのListsオブジェクトが表示されます。このオブジェクトはパラメータとして使用されます。
図29-32に、管理チェーンベースの参加者を指定するルールの例を示します。
複数のルールが起動されると、最も高い優先度のルールに基づいて作成されたリスト・ビルダーが選択されます。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
図29-33に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
時間を指定します。
ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、第29.7項「タスクのエスカレート、期限更新または終了」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
これは非定型ルーティングとも呼ばれます。このオプションが選択されている場合は、実行時にOracle BPM Worklistの「アクション」リストに「非定型ルート」が追加されます。
|
注意: FYI参加者の上下に非定型割当て先を追加しないでください。 |
他の参加者をタスクに招待する手順は、次のとおりです。
図29-33に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
「この参加者による他の参加者の招待を許可」を選択します。
特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスクをバイパスする手順は、次のとおりです。
図29-33に示すように、単一タイプの「参加者タイプの編集」ダイアログの「詳細」セクションを開きます。
「スキップ・ルールの指定」を選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。
タスク参加者をバイパスするための式は、ブール値に評価される必要があります。たとえば、/task:task/task:payload/order:orderAmount < 1000は、参加者をスキップするための有効なXPath式です。
動的なルール条件の作成の詳細は、第29.5.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。
図29-34および図29-35は、「パラレル」ダイアログの上部および下部のセクションを示しています。
この参加者タイプは、パラレルで作業する複数のユーザーが同時にタスクを操作する(たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する)必要がある場合に使用します。結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。
たとえば、ビジネス・プロセスでは、雇用プロセス中に面接担当者全員からフィードバックを収集し、それをとりまとめて各面接担当者に採用または不採用リクエストを割り当てます。最後に、面接担当者の大多数が不採用ではなく採用に投票すると、候補者が雇用されます。
参加者をパラレル参加者タイプに割り当てる手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。
表29-8に、パラレル参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
「デフォルトの結果」リストで選択したデフォルトの結果よりも優先される投票結果を指定できます。この結果が有効になるのは、必要なパーセントに到達した場合です。結果はこの表にリストされている順序で評価されます。
パラレル・タイプの「参加者タイプの編集」ダイアログの「投票結果」セクションに移動します。
「投票結果」列のリストから、タスクの結果(「Any」、「ACCEPT」、「REJECT」、第29.2.4項「タスクの結果の指定方法」で指定した他の結果など)を選択します。
「Any」結果を使用すると、実行時に結果を動的に決定できます。たとえば、「Any」を選択して、結果パーセントを60に設定した場合は、実行時に60%に到達した結果が最終投票結果になります。割当て先の60%が結果の却下に投票すると、その結果は却下されます。
「結果タイプ」列のリストから、最終タスクの結果の決定方法を選択します。
式別: XPath式を使用して詳細を動的に指定します。
パーセンテージ別: このタスクの結果が有効であると決定するパーセント値を指定します。
ステップ3での選択内容に基づいて、「値」列のリストに値を指定します。
「式別」を選択した場合は、このフィールドの右側にある「参照」アイコンをクリックし、式を作成するための「式ビルダー」ダイアログを表示します。
「パーセンテージ別」を選択した場合は、このタスクの結果が有効になるために必要なパーセント値を入力します。たとえば、多数決(51)や満場一致(100)などです。たとえば、予想される2つの結果(「ACCEPT」および「REJECT」)と、5つのサブタスクがあるとします。2つのサブタスクが承認され、3つが却下された場合に、承認に必要なパーセントが50に設定されていると、タスクの結果は却下になります。図29-36に詳細を示します。
この機能は非決定性です。たとえば、サブタスクが2つある場合に30%を選択することは無意味です。
「追加」アイコンをクリックして、追加の結果を指定します。
「デフォルトの結果」リストで、同意パーセントの値に達しない場合にこのタスクで有効にするデフォルトの結果を選択するか、XPath式を入力します。この状況が発生するのは、得票数が同数の場合、またはタスクの有効期限が切れる前に応答しない参加者がいる場合です。第29.2.4項「タスクの結果の指定方法」で「結果」ダイアログに入力したシード済結果とカスタム結果は、このリストに表示されます。
さらにグループ投票詳細を指定します。
最小のパーセントに達するとただちに投票結果がトリガーされます
このサブセクションが選択されている場合は、完了したサブタスクの結果に基づいてタスクの結果を早期に計算でき、保留中のサブタスクの取消しが可能になります。たとえば、4人のユーザーがタスクの操作に割り当てられており、デフォルトの結果が「APPROVE」で、同意パーセントが「50」に設定されているとします。最初の2人のユーザーがタスクを承認した場合は、同意パーセント値に達しているため、第3および第4のユーザーがタスクを操作する必要はありません。
このサブセクションが選択されている場合、ワークフローはすべてのレスポンスを待機してから結果を開始します。
コメントおよび添付ファイルをすべてのグループ協力者またはワークフロー参加者と共有するには、「添付ファイルとコメントの共有」を選択します。 通常、この情報はOracle BPM Worklistのフッター・リージョンに表示されます。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリンク
これらの参加者リストの作成方法の詳細は、第29.4.3.1項「単一タスク参加者リストの作成」を参照してください。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
パラレル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクション(図29-35を参照)で、「詳細」アイコンをクリックしてセクションを開きます。
「割当て済期間の制限の設定」を選択します。
時間を指定します。
ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、第29.7項「タスクのエスカレート、期限更新または終了」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスク参加者をバイパスする手順は、次のとおりです。
パラレル・タイプの「参加者タイプの編集」ダイアログで、「スキップ・ルールの指定」チェック・ボックスを選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。
参加者をスキップするための有効なXPath式は、第29.4.3.4項「タスク参加者のバイパス」を参照してください。
図29-37に、「シリアル」ダイアログを示します。図29-38に、展開された「詳細」セクションを示します。
この参加者タイプを使用すると、ワークフロー用に参加者の順序リストを作成できます。たとえば、文書をJohn、MaryおよびScottに順番にレビューさせる場合は、この参加者タイプを使用します。シリアル参加者タイプの場合、参加者はユーザーまたはグループのリストになります。
シリアル参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。
表29-9に、シリアル参加者タイプの「参加者タイプの編集」ダイアログの各サブセクションの構成方法を示します。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリスト
これらの参加者リストを作成する方法は、第29.4.3.1項「単一タスク参加者リストの作成」を参照してください。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
シリアル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクション(図29-37を参照)で、「詳細」アイコンをクリックしてセクションを開きます。
「割当て済期間の制限の設定」をクリックします。
時間を指定します。
|
注意: シリアル参加者のレベルでタスク有効期間を指定する場合、指定した期限に達したときにそのシリーズ内の次の参加者にタスクが移動しません。むしろ、そのタスク全体が期限切れになります。 |
ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、第29.7項「タスクのエスカレート、期限更新または終了」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
シリアル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクションで、「詳細」アイコンをクリックしてセクションを開きます(まだ開いていない場合)。
「この参加者による他の参加者の招待を許可」を選択します。
|
注意: シリアル参加者タイプでは、次のようにして他の参加者を招待できます。
|
特定の条件が満たされている場合は、タスク参加者(ユーザー、グループまたはアプリケーション・ロール)をバイパスできます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
タスク参加者をバイパスする手順は、次のとおりです。
シリアル・タイプの「参加者タイプの編集」ダイアログの「詳細」セクションで、「スキップ・ルールの指定」チェック・ボックスを選択します。
これにより、「式ビルダー」ダイアログにアクセスして条件を作成するためのアイコンが表示されます。式はブール値に評価される必要があります。
参加者をスキップするための有効なXPath式は、第29.4.3.4項「タスク参加者のバイパス」を参照してください。
図29-39に、「FYI」タイプの「参加者タイプの編集」ダイアログを示します。このダイアログの下部には、「参加者除外リスト」が含まれています(図29-39には表示されていません)。
この参加者タイプは、ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。
たとえば、雑誌の購読契約の更新期日がきているとします。ユーザーが期日までに現在の購読契約を取り消さない場合は、購読契約の期限が更新されます。リクエストが期限切れになるかユーザーが操作するまで、このユーザーに週に1回ずつリマインダが送信されます。
FYI参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリスト
これらの参加者リストを作成する方法は、第29.4.3.1項「単一タスク参加者リストの作成」を参照してください。
参加者タイプを構成してヒューマン・タスク・エディタに戻った後に、図29-40に示す「タスクは開始参加者から最終参加者へ移行します」アイコンをクリックします。
これによって、図29-41に示す「割当ての構成」ダイアログが表示され、ワークフローを介してタスクをルーティングする方法を指定できます。
表29-10に、用意されているルーティング・ポリシー・メソッドを示します。
表29-10 ルーティング・ポリシー・メソッド
| ルーティング・ポリシーの選択 | このポリシーを使用する環境 | 項 |
|---|---|---|
|
このポリシーを選択すると、次のサブオプションを指定できます。 |
タスクは、参加者の表示順に従って各参加者にルーティングする必要があります。これは事前に決定されているデフォルトのルーティングです。たとえば、雇用プロセスで、3人のユーザーが面接して検討結果を提供する場合、タスクは人事部に送信されます。 |
第29.5.1項「指定した順序でタスクを全参加者にルーティングする方法」 |
|
参加者は、タスクを承認する際に、ユーザーまたはグループを次の割当て先(臨時)として選択できます。 |
第29.5.1.1項「全参加者による他の参加者の招待の許可」 |
|
タスクの参加者が、タスクを承認または却下できます。したがって、他の参加者にタスクが送信されずにワークフローが終了します。たとえば、マネージャが却下した注文書は、レビューのためにそのマネージャのマネージャに送信されません。 |
第29.5.1.2項「他の参加者へのタスクのルーティングの停止」 |
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因になることはありません。 |
第29.5.1.3項「パラレル・サブタスクでの早期完了の有効化」 |
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因となります。 |
第29.5.1.4項「早期完了するサブタスクの親サブタスクの完了」 |
|
拡張ルールの使用 |
タスクのルーティング先の参加者は、モデリングしたビジネス・ルール・ロジックによって判断されます。たとえば、融資申請タスクは、融資エージェント、そのマネージャおよびシニア・マネージャを経由するように設計されているとします。この場合、融資エージェントは承認したが、そのマネージャが却下すると、その融資申請タスクは融資エージェントに戻されます。 |
第29.5.2項「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」 |
|
外部ルーティングを使用 |
タスクの参加者は動的に決定されます。たとえば、ある企業のルールでは、タスク参加者は、実行時に決定しバックエンド・データベースから取得する必要があります。 |
|
|
「割当て」タブ |
参加者に、失敗したタスクがリカバリの目的で割り当てられます。 |
|
選択された参加者全員がタスクをレビューするように選択できます。これは、表示された順序で各参加者にタスクがルーティングされるデフォルト・ルーティングです。このタイプのルーティングは、ステート・マシン・ベースのルーティングとは異なります。
指定した順序でタスクを全参加者にルーティングする手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
図29-42に示すように、リストから「指定した順序で全参加者へタスクをルート」を選択します。
ルーティング・ポリシーの定義方法は、次の各タスクを参照してください。
全参加者による他の参加者の招待の許可
参加者の選択によるタスクの完了
パラレル・サブタスクでの早期完了の有効化
早期完了するサブタスクの親サブタスクの完了
このチェック・ボックスは、以前の10.1.3 Oracle BPEL Process Managerリリースの非定型ワークフロー・パターンに相当します。これは、参加者が1人以上存在する場合に適用されます。この場合は、各ユーザーがタスクの承認時に次の割当て先としてユーザーまたはグループを選択します。
全参加者に対して他の参加者の招待を許可する手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
「指定した順序で全参加者へタスクをルート」を選択します。
「全参加者による他の参加者の招待を許可」チェック・ボックスを選択し、このタスクの割当て先がこのワークフローの次の割当て先にルーティングする前に、他の参加者をワークフローに招待できるようにします。
|
注意: FYI参加者の上下に非定型割当て先を追加しないでください。 |
ワークフローの他の参加者に関係なくタスクを早期完了させる条件を指定できます。
たとえば、経費レポートがマネージャに送信されてから取締役に送信されるとします。最初の参加者(マネージャ)がレポートを却下した場合は、次の参加者(取締役)に送信せずにワークフローを終了できます。
条件付き中途完了を設定する手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「指定した順序で全参加者へタスクをルート」を選択します。
「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスを選択します。
「中途完了の詳細」ダイアログが表示されます。
タスクの中途完了を指定するには、次の2つの方法があります。
結果
XPath式のルーティング条件
結果を指定した場合は、選択したタスクの結果が発生すると、そのタスクが完了します。結果とルーティング条件の両方を指定した場合は、ワークフロー・サービスにより2つの条件の論理OR演算子が実行されます。
図29-43に示すように、適切な結果を選択して「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。
「ルーティング条件」フィールドの右側にあるアイコンをクリックして「式ビルダー」ダイアログを表示すると、このダイアログで、このタスクを中途完了させる条件を動的に作成できます。たとえば、ユーザーが発行した出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
早期完了のXPath式は、少なくとも一人のユーザーのタスク操作が完了するまで評価されません。
早期完了を有効化するには、「パラレル・サブタスクで早期完了を有効化」をクリックします。詳細は、第29.5.1.3項「パラレル・サブタスクでの早期完了の有効化」を参照してください。
親タスクの早期完了を有効化するには、「早期完了するサブタスクの親タスクを完了」をクリックします。詳細は、第29.5.1.4項「早期完了するサブタスクの親サブタスクの完了」を参照してください。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
「参加者が次を選択するとタスクを完了: <結果>」チェック・ボックスの右側にあるアイコンをクリックすると、この情報を編集できます。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。ただし、他のパラレル・グループによるサブタスクの操作は停止されません。このグループでは、タスクの操作が続行されます。
たとえば、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。一方、第2パラレル・グループは注文ヘッダーの操作を続行します。このシナリオでは、タスク全体は早期完了しません。図29-44に詳細を示します。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。これにより、他のパラレル・グループによるサブタスクの操作も停止されます。
たとえば、図29-44に示すように、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。さらに、第2パラレル・グループも注文ヘッダーの操作を停止します。このシナリオでは、タスク全体が早期完了します。
複雑なワークフロー・ルーティング・シナリオを作成するには、拡張ルーティング・ルールを使用します。参加者タイプ(単一、パラレル、シリアル、FYI)は、中途完了、割当て先のスキップなどの基本条件を使用して、一連のユーザーから別のユーザーに直線的なフローを作成する際に使用されます。ただし、多くの場合、ワークフローの複数のユーザー間で、より複雑な前後へのルーティングを実行することが必要になります。1つの選択肢は、これらのタスクの調整として、BPELプロセスを使用することです。もう1つの選択肢は、ビジネス・ルールを使用して宣言的にルーティングを指定することです。この項では、ヒューマン・タスク・エディタとビジネス・ルールを使用して、これらの複雑な相互作用をモデリングする方法について説明します。
ステート・マシン・ルーティング・ルールは、Oracle Business Rulesを使用して定義できます。このアクションによって、評価されるOracle Business Rulesを作成できます。
その前に、ルーティング・スリップ・タスク参加者がタスクの結果を設定します。
その後に、タスクが次のルーティング・スリップ参加者に割り当てられます。
このアクションにより、第29.5.1項「指定した順序でタスクを全参加者にルーティングする方法」に説明されている標準的なタスク・ルーティング・スリップのメソッドをオーバーライドし、タスクに対して複雑なルーティング動作を作成できます。
Oracle Business Rulesを使用して、ビジネス・オブジェクト(ファクトと呼ばれる)に依存する一連のルール(ルールセットと呼ばれる)を定義し、実行するアクションを判断します。
ファクトとは、特定のビジネス・データを備えたオブジェクトです。ルーティング・スリップの割当て先がタスクの結果を設定するたびに、タスクを次の割当て先に自動的にルーティングするかわりに、タスク・サービスが次のステップを実行します。
ファクトをデシジョン・サービスにアサートします。
拡張ルーティング・ルールセットを実行します。
ルールでは、アサートされたファクトの値をテストし、TaskActionファクト・タイプに値を設定することで、ルーティングの動作を指定できます。
表29-11は、タスク・サービスによりアサートされたファクト・タイプを示しています。
表29-11 タスク・サービスによりアサートされたファクト・タイプ
| ファクト・タイプ | 説明 |
|---|---|
|
|
このファクトには、ワークフロー・タスク・インスタンスの現在の状態が含まれます。すべてのタスク属性がタスクに対してテストされます。タスク・ファクトには現在のタスク・ペイロードも含まれます。このファクトを使用すると、ペイロード値およびタスク属性値との照合テストを構築できます。 |
|
|
このファクトには、前回のタスクの結果と、結果を設定した割当て先が記述されます。このファクトには、次の属性が含まれます。
|
|
|
このファクトは、書込みルールのテストを意図したものではありません。かわりに、このファクトはルールセットによって更新され、タスクのルーティング方法を示すためにタスク・サービスに返されます。ルールで |
ワークフロー・ルーティング・ルールのみで使用できるファクト・タイプと、ワークフロー参加者ルールのみで使用できるファクト・タイプがあります。表29-12に、それぞれのタイプを使用できるルールを示します。
表29-12 ファクト・タイプの使用
| ファクト・タイプ | ルーティング・ルールでの使用 | 参加者ルールでの使用 |
|---|---|---|
|
|
はい |
はい |
|
|
はい |
いいえ |
|
|
はい |
いいえ |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
|
|
いいえ |
はい |
タスクのルーティング方法をタスク・サービスに指示するために、ルールでは多数のタスク・アクションの1つを指定できます。この指定は、ルール・セッションにアサートされたTaskActionファクトを更新することによって実行されます。ただし、ルールでTaskActionファクトを直接更新することはできません。かわりに、アクションRL関数の1つをコールし、TaskActionファクトをパラメータとして渡す必要があります。これらの関数によって、ファクトへの実際の更新が処理されます。たとえば、先に進むアクションを指定するには、call GO_FORWARD(TaskAction)をルールのアクション部分に追加する必要があります。
ステート・マシン・ルーティング・ルールが評価されるたびに、ルールは表29-13に記載されているアクションの1つを実行します。
表29-13 ビジネス・ルールのアクション
| アクション | 説明 | パラメータ |
|---|---|---|
|
|
ルーティング・スリップの次の参加者に進みます(デフォルト動作)。 |
なし |
|
|
ルーティング・スリップの前の参加者(直前にタスクの結果を設定した前の参加者)に戻ります。 注意: プッシュバックは、グループ投票ではなく単一承認者で機能するように設計されています。グループ投票(またはパラレル)シナリオを含むステージから別ステージへのプッシュバックは、許可されません。同様に、単一の割当て先からグループ投票(またはパラレル)シナリオにプッシュバックすることもできません。 |
なし |
|
|
ルーティング・スリップでの特定の参加者に進みます。 |
タスクをルーティングする参加者のラベルを識別する文字列です( |
|
|
ルーティングを終了し、タスクを完了します。タスクが完了としてマークされ、ルーティングがさらに要求されることはありません。 |
なし |
|
|
タスク・エスカレーション・ポリシーに従って(通常は現在の割当て先のマネージャに)タスクをエスカレートし、再割当てします。 |
なし |
この項では、簡単な例でカスタム・ルーティングの動作を実装するルールの使用方法を説明します。費用請求の承認を管理するためのヒューマン・ワークフロー・タスクが作成されます。タスクの結果には、承認と却下があります。タスク定義には、ExpenseRequestペイロードの要素が含まれます。ExpenseRequestのフィールドの1つは、費用請求の総額です。タスクのルーティング・スリップは、単一参加者3人(assignee1、assignee2、assignee3)で構成されます。
デフォルトでは、タスクは各割当て先にルーティングされ、各割当て先ではタスクの承認または却下が選択されます。
このデフォルト動作のかわりに、次のように必要なルーティング動作を指定します。
費用請求の総額が$100未満の場合は、参加者のいずれか1人の承認が必要です。それ以外の場合は、3人全員が承認する必要があります。
参加者のいずれかが費用請求を却下した場合は、再評価のために前の参加者に費用請求を戻す必要があります。最初の参加者によって却下されると、費用請求は却下され完了としてマークされます。
次のルールを使用して、この動作を実装します。拡張ルーティング・ルールに対してルール・ディクショナリが生成されている場合、その拡張ルーティング・ルールはデフォルトのGO_FORWARD動作を実装するテンプレート・ルールを使用して作成されます。Oracle Business Rulesデザイナで「ルールのコピー」を右クリックして選択すると、このルールを編集し、テンプレート・ルールをコピーできます。
金額が$100より大きく、前の割当て先がタスクを承認した場合は、各割当て先に順番にタスクをルーティングするルールを指定する必要はありません。これは、ルールセットのルールがトリガーされない場合の戻り先のデフォルト動作となります。
反復設計の詳細は、Oracle SOA Suiteサンプルで使用可能なworkflow-106-IterativeDesignのサンプルを参照してください。
ヒューマン・ワークフローで、ビジネス・ルール・アーティファクトが2つのルール・ディクショナリに格納されるようになりました。これは、アプリケーションをカスタマイズする必要があるシナリオで役立ちます。たとえば、アプリケーションのバージョン1を作成して、顧客に発送するとします。顧客は、Oracle SOAコンポーザを使用してアプリケーションのルールセットをカスタマイズできます。このカスタマイズされたルールセットが、ベース・ルール・ディクショナリとは別のルール・ディクショナリに格納されるようになりました。カスタマイズされたルールセットが格納されるルール・ディクショナリは、ベース・ディクショナリのルールとリンクしています。後でアプリケーションのバージョン2を発送するときに、製品に導入された追加の変更がベース・ルール・ディクショナリに含まれている場合があります。顧客が以前に行ったルールセットのカスタマイズによる変更も保持されているため、ベース・ディクショナリの新規の変更で使用できます。ルールを使用するタスクを含む既存のアプリケーションが開かれたときに、そのルールが1つのディクショナリを使用する古い形式の場合、ルールは自動的にアップグレードされ、次の2つのルール・ディクショナリに分割されます。
ベース・ディクショナリ
カスタム・ディクショナリ
カスタマイズの詳細は、第46章「SOAコンポジット・アプリケーションのカスタマイズ」を参照してください。
拡張ルーティング・ルールを作成する手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「拡張ルールの使用」を選択します。
図29-48に示すように、「ルール・ディクショナリ」の右側にある「編集」アイコンをクリックします。
これにより、Oracle Business Rulesデザイナ(図29-49を参照)が開始されます。ルール・デザイナにはリポジトリが事前にシードされており、必要なすべてのファクト定義が格納されています。ディクショナリ用のデシジョン・サービス・コンポーネントが作成され、タスク・サービス・コンポーネントに関連付けられます。
Oracle Business Rulesを使用して、タスクのステート・マシン・ルーティング・ルールを定義します。
これにより、ヒューマン・タスク内で完全に接続されたデシジョン・サービスと、関連するルール・リポジトリとデータ・モデルが自動的に作成されます。
ビジネス・ルールの詳細は、次のドキュメントを参照してください。
第29.5.2.4項「サンプル・ルールセット」(ヒューマン・タスク・ルールセットの例)
Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド
Oracle Fusion Middleware Oracle Business Rulesランゲージ・リファレンス・ガイド
ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成します。このルーティング・ポリシーを指定すると、他の参加者タイプはすべて無視されます。タスクのルーティングを決定する参加者タイプ(単一承認者、シリアル承認者、パラレル承認者など)のリストを実行時に提供するのは、外部ルーティング・サービスとみなされています。
このオプションは、タスク割当て先の決定にルーティング・ルールを使用しない場合に使用します。この場合、タスク割当てのすべてのロジックは、外部ルーティング・サービスに委任されます。
|
注意: 「割当ての構成」ダイアログで「外部ルーティングを使用」を選択した場合は、Javaクラスを指定し、「OK」をクリックして終了します。次回、このダイアログを開くと、ドロップダウン・リストには、他の2つの選択肢(「指定した順序で全参加者へタスクをルート」および「拡張ルールの使用」)は表示されません。3つの選択肢すべてに再度アクセスするには、割当て全体を削除する必要があります。 |
外部ルーティングを使用する手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
リストから「外部ルーティングを使用」を選択します。
図29-50に示すように、「編集」アイコンをクリックします。
図29-51に示すように、外部ルーティング・ダイアログが表示されます。
「クラス名」フィールドで、完全修飾クラス・ファイル名(org.mycompany.tasks.RoutingServiceクラス名など)を入力します。このクラスは、次のインタフェースを実装している必要があります。
oracle.bpel.services.workflow.task.IAssignmentService
表29-14に示すように、外部サービスに渡す名前またはXPath式別に、名前/値ペアのパラメータを追加します。
「追加」アイコンをクリックし、その他の名前/値ペアのパラメータを追加します。
タスクは、間違った割当てなどの理由でエラーになることがあります。このようなエラーが発生すると、タスクは、修正処理を実行するエラー割当て先に割り当てられます。リカバリ可能なエラーは、次のとおりです。
すべての参加者に対して無効なユーザーおよびグループ。
割当て先および有効期間に関連する無効なXPath式。
有効期限のエスカレーション・エラー。
エスカレーション・ポリシーの評価
期限更新ポリシーの評価
管理チェーンの計算。
動的割当てルールの評価。タスクは、現在はエラーではありませんが、現在のユーザーに割り当てられたままです。したがって、リカバリ可能です。
動的割当ての循環割当て(「ユーザーA」→「ユーザーB」→「ユーザーA」など)。タスクは、現在はエラーではありませんが、チェーンの最終ユーザーに割り当てられたままです。したがって、リカバリ可能です。
次のエラーは、リカバリ可能ではありません。このような場合、タスクは終了状態ERROREDに移動します。
無効なタスク・メタデータ
読取り不可のタスク・メタデータ。
ステート・マシン・ルールからの無効なGOTO参加者。
割当てサービスが見つからない場合。
割当てサービスによるエラー。
カスタム・エスカレート関数の評価。
パラレルのデフォルト結果とパーセント値に対する無効なXPathおよび値。
ワークフローのエラー割当て先は、ワークフロー・タスクのモデリング中に指定できます。エラー割当て先が指定されている場合は、その割当て先が評価されてタスクが割り当てられます。実行時にエラー割当て先が指定されていない場合は、管理ユーザーが検索され、アラート状態のタスクが割り当てられます。エラー割当て先は、次のいずれかのアクションを実行します。
非定型ルート
タスクを、そのタスクに実際に割り当てられているユーザーにルーティングします。非定型ルーティングを使用すると、タスクを順番に、またはパラレルなどでユーザーにルーティングできます。注意: FYI参加者の上下に非定型割当て先を追加しないでください。
再割当て
タスクを、このタスクに実際に割り当てられているユーザーに再割当てします。
エラー・タスク
このタスクを修正できないことを示します。
エラー割当て先の評価中にエラーがあると、タスクはエラー発生としてマークされます。
このダイアログでは、割当てエラーが発生した場合にタスク割当て先となるユーザーまたはグループを指定できます。
エラー割当て先を構成する手順は、次のとおりです。
「割当て」セクションで、「タスクは開始参加者から最終参加者へ移行します」の右側にあるアイコンをクリックします。
「割当て」タブをクリックします。
図29-52に示すように、「追加」アイコンをクリックして、レビューアまたはエラー割当て先を割り当てます。
「追加」アイコンをクリックし、このタスクに参加するユーザー、グループまたはアプリケーション・ロールを選択します。
「開始参加者」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。
ユーザー、グループまたはアプリケーション・ロールを選択する手順の詳細は、第29.4.3.1項「単一タスク参加者リストの作成」のステップ5から7を参照してください。
パラレル参加者タイプを使用する場合は、サブタスク・ペイロードの格納場所を次のオプションで指定できます。
サーバー設定を使用
Oracle Enterprise Manager Fusion Middleware ControlのSharePayloadAcrossAllParallelApproversシステムMBeanブラウザ・ブール型プロパティで、ルート・タスク内のサブタスクのペイロードを共有するかどうかを決定します。デフォルトで、このプロパティは「true」に設定されています。「true」に設定されている場合、「すべてのタスク参加者が同じペイロードを共有(パフォーマンスが向上し、記憶域のスペースが削減されます)」オプションが使用されます。このプロパティを「false」に設定すると、「各パラレル参加者がペイロードのローカル・コピーを所有」オプションが使用されます。このプロパティを変更するには、次の手順を実行します。
「soa-infra」を右クリックして、「管理」→「システムMBeanブラウザ」の順に選択します。
「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowConfig」→「human-workflow」の順に開きます。
「SharePayloadAcrossAllParallelApprovers」をクリックします。
リストでこのプロパティを変更し、「適用」をクリックします。
すべてのタスク参加者が同じペイロードを共有(パフォーマンスが向上し、記憶域のスペースが削減されます)
サブタスクのペイロードは、そのサブタスクのルート・タスクに格納されます。この状況は、ルート・タスクのペイロードが、そのサブタスクすべてで共有されることを意味します。内部的には、このオプションによってパフォーマンスが向上し、記憶域のスペース使用が削減されます。記憶域のスペース使用が削減されるのは、ルート・タスクのペイロードが、そのサブタスクすべてで共有されるためです。
各パラレル参加者がペイロードのローカル・コピーを所有
各サブタスクが独自にペイロードのコピーを持ちます。内部的には、このオプションを使用すると、より大きな記憶域のスペースが使用されるため、パフォーマンスが低下し、記憶域のスペース消費が増加します。
「OK」をクリックします。
ユーザー、グループまたはアプリケーション・ロールの詳細は、第27.2.1.1.3項「参加者の割当て」を参照してください。
図29-53に示すように、「プレゼンテーション」セクションでは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するためのリソース・バンドルを指定したり、添付ファイルのWordMLおよびカスタム・スタイル・シートを指定できます。
添付ファイルのWordMLスタイルシートを指定する手順は、次のとおりです。
「プレゼンテーション」セクションの「添付ファイルのスタイルシート」リストで、次のオプションのいずれかを選択します。
Word ML: このオプションを使用すると、WordML XSLTスタイルシートを使用して電子メール添付ファイルとして送信するためのMicrosoft Word文書を動的に作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。
その他: このオプションを使用すると、XSLTスタイルシートを使用して電子メール添付ファイルを作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。
「検索」アイコンをクリックし、添付ファイルとして使用するスタイル・シートを選択します。
リソース・バンドルは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するように指定できます。次のタスク詳細でリソース・バンドルがサポートされます。
プレーン・テキストまたはmessage(key)書式によるタスクの結果値の表示。
様々な言語による電子メール通知メッセージの有効化。実行時にXPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を指定して、指定したリソース・バンドルから国際化された文字列を取得します。通知受信者のロケールは、関数hwf:getNotificationProperty(propertyName)で取得できます。
リソース・バンドルは単純にプロパティ・ファイルでもあります。たとえば、タスクの結果の表示名を構成するリソース・バンドルは、次のようになります。
APPROVE=Approve
REJECT=Reject
多言語設定を指定する手順は、次のとおりです。
「プレゼンテーション」セクションで、「リソース・バンドル」の横にある「追加」アイコンをクリックします。
図29-54に示す「リソースの詳細」ダイアログが表示されます。
「リソース名」フィールドで、リソース・バンドルに使用するリソース名を入力します。このファイルは.propertiesベースのリソース・バンドル・ファイルである必要があります。
「リソースの場所」フィールドで、「検索」アイコンをクリックし、使用するJARまたはZIPリソース・バンドル・ファイルを選択します。リソース・バンドルはシステム・アーカイブ(SAR)ファイルの一部です。
リソース・バンドルがコンポジット・プロジェクト外部にある場合は、SCA-INF/libにローカル・コピーを格納するように求めるプロンプトが表示されます。
リソース・バンドル・ファイルがコンポジット・クラス・ローダー(SCA-INF/classesの直下またはSCA-INF/libのJARファイル内)にない場合は、そのファイルがある場所を指定する必要があります。たとえば、リソース・バンドルがコンポジット・クラス・ローダー外部の場所(たとえば、http://host:port/bundleApp/taskBundles.jarのようなHTTPの場所など)からアクセス可能な場合は、その場所をこのフィールドに指定する必要があります。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
詳細は、第34.2.6項「異なる言語による通知メッセージの構成方法」を参照してください。
図29-55に、ヒューマン・タスク・エディタの「期限」セクションを示します。
このグローバル・ポリシー・セクション(ルーティング・スリップ・レベル)で、タスクの有効期間を指定できます。有効期間を参加者タイプ・レベルではなくルーティング・スリップ・レベルで指定すると、この期間は全参加者のタスクの有効期間となります。ただし、参加者タイプ・レベルで(「割当て済期間の制限の設定」チェック・ボックスを介して)有効期間を指定すると、その設定は「期限」セクション(ルーティング・スリップ・レベル)で指定した設定よりも優先されます。
指定した期間後にタスクがユーザーのマネージャにエスカレートされるように指定できます。詳細は、第29.4.3.2項「タスクの操作に対する時間制限の指定」を参照してください。
この項では、このレベルで有効期間を指定し、その設定を参加者全員のタスクの有効期間にする方法の概要を説明します。
たとえば、図29-56に示すように、参加者LoanAgentGroupおよび参加者Supervisorの両者間でタスクを操作するための日数が3日であるとします。
参加者レベルまたはこのルーティング・スリップ・レベルで有効期限が指定されていない場合、そのタスクの有効期間設定はありません。
参加者のいずれかのレベルで有効期間が設定されている場合、その参加者には対応する有効期間が使用されます。ただし、参加者レベルの有効期間が設定されていない参加者には、引き続きグローバルな有効期間が使用されます。グローバルな有効期間は、常にタスクでの経過時間だけ減分されます。
参加者について参加者レベルの有効期限を解析するためのポリシーは、次のとおりです。
シリアル
「管理チェーン」内の各割当ては、「シリアル」で指定されている内容と同じ有効期間を取得します。期間は、この割当てによって生じるすべての割当てに対するものではありません。タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、エスカレーションおよび期限更新ポリシーが適用されます。
パラレル:
パラレル・ワークフローでは、パラレル参加者がリソースとして指定されている場合は、リソースごとにルーティング・スリップが作成されます。作成された各ルーティング・スリップの有効期間には、次のルールが適用されます。
パラレル参加者の有効期間が指定されている場合は、それと同じ有効期間。
ルーティング・スリップ・レベルで指定されている場合は、タスクに残っている有効期間。
それ以外は有効期間なし。
パラレル参加者がルーティング・スリップとして指定されている場合、その有効期間はルーティング・スリップにより決定されます。
|
注意: パラレル・タスク内で親タスクが期限切れになった場合、期限切れになっていないサブタスクや未完了のサブタスクは取り消されます。 |
タスクが期限切れにならないように指定できます。
「期限切れなし」ポリシーを指定する手順は、次のとおりです。
図29-55に示すように、「期限」セクションのドロップダウン・リストで、「期限切れなし」を選択します。
タスクに有効期限を指定できます。タスクが期限切れになると、ルーティング・スリップ・レベルのエスカレーション・ポリシーまたは期限更新ポリシーが適用されます。どちらのポリシーも指定されていない場合、タスクは期限切れになります。ルーティング・スリップ・レベルの有効期限ポリシーは、すべての参加者に共通です。
タスクに有効期限を指定する手順は、次のとおりです。
ユーザーが割当て時間内に応答しない場合は、有効期限の期間を延長できます。このためには、期限切れの際にタスクの期限を更新できる回数(3回の追加更新など)と各期限更新期間(期限更新ごとに3日間など)を指定します。
有効期限ポリシー期間を延長する手順は、次のとおりです。
ユーザーが割当て時間内に応答しない場合は、タスクをエスカレートできます。たとえば、ユーザー・ディレクトリに構成されているエスカレーション階層を使用している場合は、ユーザーのマネージャにタスクをエスカレートできます。エスカレーション・コールバックを使用している場合は、定義したユーザーにタスクをエスカレートできます。タスクが最大回数までエスカレートされた場合、エスカレートは停止します。エスカレートされたタスクは、そのタスクの期限切れ以降もユーザーの受信ボックス内に残すことができます。
タスク・ポリシーをエスカレートする手順は、次のとおりです。
図29-59に示すように、「期限」セクションのドロップダウン・リストで、「エスカレートまでの時間」を選択します。
さらに次の値を指定します。両方を設定すると、エスカレーション・ポリシーがより限定的になります。
エスカレーション・レベルの最大数
タスクをエスカレートする管理レベル数。このフィールドは必須です。
承認者の最高役職
最上位承認者の役職(自分、マネージャ、取締役またはCEOなど)。これらの役職は、対応するユーザー・リポジトリのタスク割当て先の役職と比較されます。このフィールドはオプションです。
エスカレーション・ポリシーでは、タスクを期限切れ時にエスカレートできる回数と期限更新期間を指定します。図29-59では、タスクが期限切れになると、最大3回までエスカレートされます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。
このオプションを使用すると、特定のワークフローについてカスタム・エスカレーション・ルールをプラグインできます。たとえば、期限切れ時に、タスクを現在のユーザーの部門マネージャに割り当てるには、カスタム・タスク・エスカレーション関数を記述してワークフロー・サービスに登録し、その関数をタスク定義に使用できます。
デフォルトのエスカレーション・ルールでは、タスクは現在のユーザーのマネージャに割り当てられます。新規エスカレーション・ルールを追加するには、次の手順に従います。
エスカレーション・ルールを指定する手順は、次のとおりです。
次のインタフェースを実装します。
oracle.bpel.services.workflow.assignment.dynamic.IDynamicTaskEscalationFunction
この実装はサーバーのクラス・パスで使用可能である必要があります。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。
ナビゲータで、「SOA」フォルダを開きます。
「soa-infra」を右クリックして、「SOA管理」→「ワークフロー構成」→「タスク」タブを選択します。
「ワークフロー・タスク・サービス・プロパティ」ページが表示されます。
新しい関数を追加します。例:
関数名: DepartmentSupervisor
クラスパス: oracle.bpel.services.workflow.assignment.dynamic.patterns.DepartmentSupervisor
関数のパラメータ名
関数のパラメータ値
「期限」セクションの「カスタム・エスカレーションJavaクラス」フィールドに、エスカレーション・ルールについて「ワークフロー・タスク・サービス・プロパティ」ページに定義されている関数名を入力します。
詳細は、第34.3.3項「カスタム・エスカレーション関数」を参照してください。
期日は、タスクを完了する必要がある日付を示すために使用されます。期日は有効期限とは異なります。期限切れタスクの場合は、期限切れとしてマークされるか、エスカレーション・ポリシーに基づいて自動的にエスカレートまたは期限更新されます。通常、期日は有効期限より早い日付で、タスクの期限切れが近いことをユーザーに示します。
図29-55に示すように、タスクの期日を入力できます。タスクは指定された期日をすぎると、期限切れとなります。この日付は有効期限ポリシーの付加項目です。期日は、有効期限ポリシーが指定されているかどうかに関係なく指定できます。期日を使用すると、Oracle BPM Worklistに期日を表示し、期限切れタスクをリストし、受信ボックス内の期限切れタスクをフィルタ処理できます。期限切れタスクは、TaskQueryService.queryTask(...) APIの述語を使用して、問合せできます。
期日を指定する手順は、次のとおりです。
「期限」セクションで、「要求されたアクションの期日」チェック・ボックスを選択します。
「期間別」を選択して特定の期間を入力するか、「式別」を選択してXPath式として値を動的に入力します。
次の点に注意してください。
期日は、(Oracle BPM Worklistの「To Doタスクの作成」ダイアログを使用する)タスクと、(ヒューマン・タスク・エディタを使用する).taskファイルの両方で設定できます。これにより、タスクの開始時に、タスク定義のないTo Doタスクで期日を設定できるようになります。タスク(実行時オブジェクト)に設定された期日は、.taskファイルに設定された期日よりも優先されます。
タスク定義では、期日は各参加者に対してではなく、グローバルなレベルでのみ指定できます。
タスクに対して期日が設定されている場合、.taskファイルの期日は無視されます。
タスクに対して期日が設定されていない場合は、.taskファイルの期日が評価され、タスクに設定されます。
タスクと.taskファイルのいずれにも期日がない場合、タスクには期日がありません。
|
注意: To Doタスクに対してビジネス・ルールを指定することはできません。 |
詳細は、第32.3.4項「To Doタスクの作成方法」を参照してください。
図29-60に、ヒューマン・タスク・エディタの「通知」セクションの「一般」タブ(完全に開いた状態)を示します。
通知は、ユーザーまたはグループにタスクが割り当てられる時期を示すか、タスクのステータスに変更があったことを通知します。通知は、電子メール、ボイス・メッセージ、インスタント・メッセージまたはSMSで送信できます。異なるアクションについて様々なタイプの参加者に通知が送信されます。デフォルトでは、通知はデフォルト・メッセージを使用して構成されます。たとえば、タスクが完了してクローズされたことを示す通知メッセージが送信されます。独自の構成を作成するか、既存の構成を変更できます。
|
注意: 組込みLDAPでは、グループの電子メール・アドレスがサポートされていません。したがって、タスクがグループIDに割り当てられると、電子メールはグループの電子メール・アドレスではなく、そのグループの全メンバーに送信されます。 |
参加者の通知プリファレンスを指定する手順は、次のとおりです。
図29-60に示すように、「通知」タブをクリックします。
表29-15に、「通知」セクションの「一般」タブの各サブセクションの構成方法を示します。
表29-15 ヒューマン・タスク・エディタ - 「通知」セクションの「一般」タブ
| サブセクション | 参照先 |
|---|---|
|
タスク・ステータス 受信者 |
第29.8.1項「受信者へのタスク・ステータス変更の通知方法」 |
|
通知ヘッダー |
|
通知サービスの詳細は、第34.2項「ヒューマン・ワークフローからの通知」を参照してください。
「通知」セクションで、「詳細」タブをクリックします。図29-61に詳細を示します。
表29-16に、「通知」セクションの「詳細」タブの各サブセクションの構成方法を示します。
表29-16 ヒューマン・タスク・エディタ - 「通知」セクションの「詳細」タブ
| サブセクション | 参照先 |
|---|---|
|
リマインダ |
|
|
エンコーディング |
|
|
通知のセキュア化(詳細を除く) |
|
|
ワークリストURLを通知に表示 |
第29.8.6項「通知でのOracle BPM Worklist URLの表示方法」 |
|
通知をアクション可能にする |
第29.8.7項「電子メール・メッセージをアクション可能にする方法」 |
|
電子メール通知によるタスクの添付ファイルの送信 |
第29.8.8項「電子メール通知によるタスクの添付ファイルの送信方法」 |
|
グループ通知構成 |
第29.8.9項「グループおよびアプリケーション・ロールへの電子メール通知の送信方法」 |
|
通知ヘッダーの属性 |
|
「タスク・ステータス」列には、3つのデフォルト・ステータス・タイプ「割当て」、「完了」および「エラー」が表示されます。通知メッセージの受信用に他のステータス・タイプを選択できます。
受信者にタスク・ステータス変更を通知する手順は、次のとおりです。
「通知」セクションで、「一般」タブをクリックします。
「タスク・ステータス」列で、タイプをクリックしてタスク・タイプの完全なリストを表示します。
アラート済
タスクがアラート済の状態の場合は、受信者に通知できます。ただし、いずれの通知受信者(割当て先、承認者、所有者、イニシエータまたはレビューア)も、アラート済の状態を知らせるFYI通知の単なる受信者であり、アラート済の状態からエラー状態にタスクを移動することはできません。所有者は、タスクの再割当て、取消し、削除またはパージを実行できます。また、エラーを解決できない場合はタスクをエラー状態に移動するようにエラー割当て先に依頼できます。アラート済からエラー状態にタスクを移動できるのは、エラー割当て先のみです。
エラー割当て先は、「割当ての構成」ダイアログの「割当て」タブで構成します。このタブは「割当て」セクションの「タスクは開始参加者から最終参加者へ移行します」アイコンの下にあります。詳細は、第29.5.4項「エラー割当て先の構成方法」を参照してください。
割当て
ユーザーまたはグループにタスクが割り当てられた場合。この場合は、次のアクションが取得されます。
ユーザーへのタスクの割当て
シリアル・ワークフローでの新規ユーザーへのタスクの割当て
タスクの期限更新
タスクの委任
タスクの再割当て
タスクのエスカレート
タスク情報の発行
完了
エラー
期限切れ
情報のリクエスト
再開
一時停止
更新
タスク・ペイロードの更新
タスクの更新
コメントの追加
添付ファイルの追加および更新
結果の更新
取消
その他のすべてのアクション
前述のタスク・タイプ以外のアクションこれにはタスクの取得が含まれます。
タスク・ステータスのタイプを選択します。
通知は、様々な範囲でタスクに関与するユーザーに送信できます。これには、タスクがグループに割り当てられている場合が含まれます。グループに通知エンドポイントが設定されていない場合は、グループの各ユーザーに通知が送信されます。
「受信者」列でエントリをクリックして、通知メッセージの受信者候補のリストを表示します。
割当て先
タスクが現在割り当てられているユーザーまたはグループ。
イニシエータ
タスクを作成したユーザー。
承認者
この時点までにタスクを操作したユーザー。これは、複数のユーザーがタスクを承認するシリアル参加者タイプに適用され、通知はこれらのユーザー全員に送信される必要があります。
所有者
タスクの所有者
レビューア
タスクにコメントおよび添付ファイルを追加できるユーザー。
詳細は、第34.2.5項「通知チャネル・プリファレンスの構成方法」を参照してください。
デフォルトの通知メッセージを、選択した受信者に配信できます。必要な場合は、デフォルト・メッセージのテキストを変更できます。
通知メッセージを編集する手順は、次のとおりです。
「通知」セクションで、「一般」タブをクリックします。
「通知ヘッダー」列で、「編集」アイコンをクリックして、デフォルトの通知メッセージを変更します。
図29-62に示す「通知メッセージの編集」ダイアログが表示されます。
このメッセージは、サポート対象のすべての通知チャネル(電子メール、ボイス、インスタント・メッセージおよびSMS)に適用されます。電子メール・メッセージには、このメッセージに定義したワークリスト・タスク詳細も挿入できます。メッセージの配信チャネルは、指定した通知プリファレンスに基づいています。
必要に応じてメッセージの文言を変更します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
通知プリファレンスの詳細は、第34.2項「ヒューマン・ワークフローからの通知」を参照してください。
タスクのリマインダを送信できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づいています。リマインダの数およびリマインダ間の間隔も構成可能です。
リマインダを設定する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
リストから、リマインダの送信数を選択します。
割当て先に1回、2回または3回通知するように選択した場合は、リマインダの間隔を選択し、リマインダを割当て前に送信するか割当て後に送信するかを選択します。
詳細は、第34.2.12項「リマインダの送信方法」を参照してください。
Unicodeは、任意の言語の情報を単一の文字セットを使用して格納できる全世界共通のエンコード文字セットです。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。UTF-8のデフォルト設定を使用するか、Javaクラスで文字セットを指定できます。
文字セットのエンコーディングを変更する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「エンコーディング」リストから、「Javaクラスで指定」を選択します。
使用するJavaクラスを入力します。
通知のセキュア化、メッセージのアクション可能化および添付ファイルの送信を設定する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「通知のセキュア化(詳細を除く)」を選択します。
選択すると、デフォルトの通知メッセージが使用されます。電子メールには、HTMLのワークリスト・タスク詳細、添付ファイルまたはアクション可能なリンクはありません。メッセージにはタスク番号のみが含まれます。
詳細は、第34.2.10項「セキュアな通知の送信方法」を参照してください。
電子メール通知メッセージにOracle BPM Worklist URLを表示するかどうかを構成できます。
通知にOracle BPM Worklist URLを表示する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「ワークリストURLを通知に表示」チェック・ボックスを選択すると、Oracle BPM Worklist URLが電子メール通知メッセージに表示されます。このチェック・ボックスを選択しないと、URLは表示されません。
電子メール・メッセージをアクション可能にする手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「通知をアクション可能にする」を選択します。このアクションにより、電子メールを介してタスク・アクションを実行できます。
その他の構成の詳細は、第34.2.7項「アクション可能なメッセージの送信方法」を参照してください。
アウトバウンドおよびインバウンド電子メールの構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
電子メール通知によってタスクの添付ファイルを送信できます。
電子メール通知によってタスクの添付ファイルを送信する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「電子メール通知によるタスクの添付ファイルの送信」を選択します。
タスクが割り当てられたグループおよびアプリケーション・ロールに電子メール通知を送信できます。
グループおよびアプリケーション・ロールに電子メール通知を送信する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「グループ通知構成」リストから、次のいずれかのオプションを選択します。
電子メールを個別に送信
グループまたはアプリケーション・ロール内の各ユーザーが個別の電子メール通知を受け取ります。これがデフォルトの選択です。
また、「ロケールに基づいて個別のタスク・フォームを使用」チェック・ボックスが自動的に選択されます。
選択すると、言語ロケールに基づいた個別のタスク・フォームを使用して個別の電子メールが送信されます。
選択しないと、タスク・フォームを再使用(共有)して個別の電子メールが送信されます。
すべてのユーザー・アドレスを含む電子メールを送信
グループまたはアプリケーション・ロール内の各ユーザー・ロケールに対して共有の通知電子メールが1回生成され、その結果電子メール・コンテンツの生成時間が短縮されます。電子メールは、グループまたはアプリケーション・ロール内のすべてのユーザーに送信されます。
|
注意:
|
カスタム通知ヘッダーは、名前/値ペアを指定し、通知の中でキー・フィールドを識別するために使用されます。ユーザーは、これらの入力項目を使用して、通知の配布プリファレンスを定義します。たとえば、「名前」を「ApprovalType」、「値」を「経費」に設定したり、「名前」を「優先度」、「値」を「高」に設定することができます。その後、ユーザーはOracle BPM Worklistで配信プリファレンスを指定できます。これらのプリファレンスは通知の内容に基づいています。
ルールベースの通知サービスは、使用する優先通知チャネルを特定する目的のみに使用されます。優先チャネルのアドレスは、引き続きアイデンティティ・サービスから取得されます。
通知ヘッダーをカスタマイズする手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「通知ヘッダーの属性」を開きます。
名前またはXPath式別に、名前/値ペアのパラメータを追加します。
プリファレンスの詳細は、次の各項を参照してください。
タスク・コンテンツへのアクセス・ルールと、そのコンテンツに対して実行するアクションを指定できます。
参加者が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。アクセス・ルールは、タスクの取得および更新時にタスク・オブジェクトにルールを適用するワークフロー・サービスによって規定されます。
|
注意: タスク・コンテンツ・アクセス・ルールおよびタスク・アクション・アクセス・ルールは相互に独立して存在します。 |
アクセス・ルールは、次の詳細に基づいて算定されます。
アクセス・ルールに対応して構成されていないロールの権限は、アクセス・ルールで構成された属性によって却下されます。たとえば、割当て先が読み取るペイロードを構成するとします。このアクションでは、割当て先のみの読取り権限が有効になり、他の誰も対象になりません。割当て先も含めて、誰にも書込み権限はありません。
アクセス・ルールで構成されていない属性には、すべての権限があります。
ペイロードのメッセージ属性がアクセス・ルールで構成されている場合は、競合の可能性があるためにペイロード自体の構成は無視されます。この場合、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をコールして参加者のアクセス・ルールを取得することで実行できます。例29-1に詳細を示します。
例29-1 APIコール
public Map<String, IPrivilege> getTaskVisibilityRules(IWorkflowContext context,
String taskId)
throws TaskMetadataServiceException;
このメソッドの詳細は、Oracle Fusion Middleware Oracle SOA Suiteワークフロー・サービスJava APIリファレンスを参照してください。
特定のタスク・コンテンツ(ペイロードなど)の操作を特定のユーザー(タスクの作成者または所有者など)に許可する権限を指定できます。
タスク・コンテンツの操作についてユーザー権限を指定する手順は、次のとおりです。
「アクセス」タブをクリックします。
「コンテンツ」タブをクリックします。
図29-63に示すように、アクセス権を指定するタスク・コンテンツを選択します。
タスク・コンテンツを操作するユーザーに権限(読取り、書込みまたはアクセスなし)を割り当てます。ユーザーには、最高レベルを超えて権限を割り当てることはできません。たとえば、ADMINユーザーにPAYLOADタスク・コンテンツに対する書込み権限を割り当てることはできません。表29-17に、タスク・コンテンツに対する各ユーザーの最大権限を示します。
表29-17 タスク・コンテンツに対するユーザーの最高権限レベル
| タスク・コンテンツ | 読取り権限保持者 | 書込み権限保持者 |
|---|---|---|
|
割当て先 |
管理者、承認者、割当て先、作成者、所有者、レビューア |
-- |
|
添付ファイル |
管理者、承認者 |
割当て先、作成者、所有者、レビューア |
|
コメント |
管理者、承認者 |
割当て先、作成者、所有者、レビューア |
|
日付 |
管理者、承認者、割当て先、作成者、所有者、レビューア |
-- |
|
フレックスフィールド |
管理者、承認者、レビューア |
割当て先、作成者、所有者 |
|
履歴 |
管理者、承認者、割当て先、作成者、所有者、レビューア |
-- |
|
ペイロード |
管理者、承認者、レビューア |
割当て先、作成者、所有者 |
|
レビューア |
管理者、承認者、割当て先、作成者、所有者、レビューア |
-- |
|
ペイロード要素 |
ペイロードから継承 |
ペイロードから継承 |
たとえば、PAYLOADタスク・コンテンツについて、ASSIGNEES、CREATORおよびOWNERの書込みアクセス権、ADMIN、APPROVERSおよびREVIEWERSの読取りアクセス権、およびアクセス権がないPUBLICというデフォルト設定をそのまま使用すると、ダイアログは図29-63に示すように表示されます。
このダイアログで、タスク・コンテンツの表示方法を選択します。現在選択されていないオプションを選択すると、すべての設定がデフォルトの値にリセットされます。
大まかな(デフォルト)
タスク・コンテンツが総括的に表示されます(たとえば、ペイロードやレビューアが1つのみ表示されます)。
きめ細かな
コンテンツが個別の要素として表示されます (たとえば、すべてのペイロード(p1、p2、p3など)およびこのタスクに割り当てられているすべてのレビューア(jstein、wfaulk、cdickens)が表示されます)。
|
注意: システムで許可されている内容とは別に、アクセス・ルールは、常にアクションの実行者とタスクの現在の状態に基づいて適用されます。 |
タスク・コンテンツ(ペイロードなど)の操作について、「タスク・コンテンツ・アクセスの設定」ダイアログで指定した特定のユーザー(タスクの作成者または所有者など)に許可するアクション(アクセスまたはアクセスなし)を指定できます。
タスクの操作に対してアクションを指定する手順は、次のとおりです。
「アクセス」タブをクリックします。
「アクション」タブをクリックします。
図29-64に示すように、ユーザーを指定するタスク・アクションを選択します。
選択したアクションを参加者が実行できるかどうかを選択します。
このダイアログで、タスク・アクションの表示方法を選択します。現在選択されていないオプションを選択すると、すべての設定がデフォルトの値にリセットされます。
大まかな(デフォルト)
タスク・アクションが総括的に表示されます(たとえば、承認や却下が1つのみ表示されます)。
きめ細かな
コンテンツに対するアクションが個別要素として表示されます (たとえば、すべての承認や却下が表示されます)。
デジタル署名は、デジタル署名されたヒューマン・タスクの否認防止メカニズムを提供します。この機能は、タスクを操作する参加者に対し、タスクの更新前に詳細と各自のアクションに対する署名を義務付けることで、後で否認できないようにします。
|
注意: タスクに対してデジタル署名が有効な場合、アクション可能な電子メールは実行時に送信されません。設計時にアクション可能な電子メールが有効化された場合も同様です。 |
ワークフロー・デジタル署名ポリシーを指定する手順は、次のとおりです。
「アクセス」タブをクリックします。
図29-65に示すように、「署名ポリシー」リストで「ポリシーの設定」を選択します。
タスク参加者が使用する署名ポリシーを指定します。
署名は不要
参加者は、署名せずにタスクの送信と操作を実行できます。これはデフォルトのポリシーです。
パスワードは必須
参加者は、次の参加者にタスクを送信する前に、署名を指定します。参加者はタスクを操作する際に、パスワードを再入力する必要があります。パスワードは、デジタル署名の生成に使用されます。デジタル署名はメッセージ送信者または文書の署名者の本人認証を行います。これにより、送信されたメッセージの元の内容が変更されていないことが保証されます。
デジタル証明書は必須
参加者は、デジタル署名されたヒューマン・タスクの否認防止のために、デジタル証明書を保持する必要があります。参加者の資格証明は、デジタル証明書によって証明されます。これは認証局(CA)が発行します。次の項目が含まれます。
名前
シリアル番号
有効期限
証明書所有者の公開鍵のコピー(メッセージとデジタル署名の暗号化に使用)
証明書発行者のデジタル署名(メッセージ信頼性の証明)
認証局の名称とCRLおよび発行認証局のURLは、個別に構成する必要があります。
「OK」をクリックします。
詳細は、第34.1.10項「エビデンス・ストア・サービスとデジタル署名」を参照してください。
デジタル署名を使用するには、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで信頼できるCAを指定する必要があります。このCAから発行された証明書のみが、ヒューマン・ワークフローで有効と見なされます。
認証局を指定する手順は、次のとおりです。
「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。
「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「WorkflowConfig」→「human.workflow」の順に選択します。
「操作」タブをクリックします。
「AddTrustedCA」をクリックします。
「CaName」および「CaURL」の「値」フィールドに、適切な値を指定します。
「起動」をクリックします。
「戻る」をクリックします。
これらの値は、使用前に検証する必要があります。
コールバック・クラスを使用してタスクを再割当てまたはルーティングできるユーザーを制限できます。
通常のLDAPディレクトリにシードされているユーザー・コミュニティは会社全体や部署全体を表します。ただし、タスクに関連付けるユーザーの潜在的リストは、スコープに基づいて制限したり、タスクや関連するデータの重要性に基づいて制限することが必要な場合があります。たとえば、数千のユーザーが存在する大企業では、少数のユーザーのみが注文書を承認および作成できるようにする場合があります。特にこのようなタスクでは、非定型ルーティングおよび再割当てに対して選択できるユーザーとして、会社全体規模のユーザーを対象にしないでください。かわりに、適切または権限のある少数のユーザーのみを選択対象とする必要があります。これを実行するには、制限付き割当て機能を使用します。この機能はコールバック・クラスとして実装されます。このコールバック・クラスには、インスタンス・データを含むタスク・オブジェクトが渡されるとそのタスク・オブジェクトに基づいて適切なユーザー・セットを動的に選択するロジックを実装できます。
|
注意: コールバックを実装した場合、ユーザー・コールバック実装によって、他の形式の制限付き割当て(たとえば、割当て先候補)がオーバーライドされます。検索を実行すると、その結果には、ユーザー・コールバックによって返されるユーザーのみが表示されます。 |
Javaコールバックまたはビジネス・イベント・コールバックを指定できます。
ワークフロー・サービスのコールバックは、タスクのライフサイクルで特定のステージに到達したときにコールするように登録できます。2つのタイプのコールバックがサポートされています。
Javaコールバック: コールバック・クラスは、インタフェースoracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装している必要があります。このコールバック・クラスをサーバーのクラスパスで使用可能にします。
ビジネス・イベント・コールバック: ヒューマン・タスクの状態が変化したときに、ビジネス・イベントが発生するようにできます。Javaクラスを開発して登録する必要はありません。コール元は、承認トランザクションの現在の状態が通知されるように、Oracle Mediatorサービス・コンポーネントを使用してコールバックを実装し、適用可能なビジネス・イベントをサブスクライブします。
タスク・ステータスのコールバック・クラスを指定する手順は、次のとおりです。
「イベント」タブをクリックします。
選択できる状態変更コールバックは、次のとおりです。
OnAssigned
標準的なルーティング、再割当て、委任、エスカレーションなどを含め、割当ての変更時にコールバック・クラスをコールする必要がある場合に選択します。タスクによって結果が更新される(つまり、チェーンのいずれかの承認者がタスクを承認または却下する)ときにコールバックする必要がある場合は、このオプションを選択する必要があります。
OnUpdated
更新(ペイロード、コメント、添付ファイル、優先度などを含む)時にコールバック・クラスをコールする必要がある場合に選択します。
OnCompleted
タスクが完了し、コントロールがイニシエータ(タスクを開始するBPELプロセスなど)に渡されようとしているときに、コールバック・クラスを最終的にコールする必要がある場合に選択します。
OnStageCompleted
ヒューマン・ワークフロー・タスクでビジネス・イベント・コールバックを有効化するために、コールバック・クラスをコールする必要がある場合に選択します。イベントが発生すると、そのイベントには、完了したステージの名前、完了したステージの結果、およびコールバックが起動された時点でのタスクのスナップショットが格納されます。
OnSubtaskUpdated
サブタスク(パラレルおよびパラレル・シナリオのいずれかのタスク)の更新(ペイロード、コメント、添付ファイル、優先度などを含む)時にコールバック・クラスをコールする必要がある場合に選択します。
Oracle JDeveloperのインストールが、BPEL拡張とBPM拡張の両方を含むように更新されている場合は、次のコンテンツのコールバックも選択できます。
コメント・コールバック
WFCOMMENT列以外のスキーマにコメントを格納するために、コールバック・クラスをコールする必要がある場合に選択します。コールバック・クラスは、oracle.bpel.services.workflow.callback.NotesStoreインタフェースを実装している必要があります。
添付コールバック
WFATTACHMENT列以外のスキーマに添付ファイルを格納するために、コールバック・クラスをコールする必要がある場合に選択します。コールバック・クラスは、oracle.bpel.services.workflow.callback.AttachmentStoreインタフェースを実装している必要があります。
検証コールバック
タスクまたはペイロードのいずれかを更新や承認などの前に検証するために、コールバック・クラスをコールする必要がある場合に選択します。
実行するコールバックのタイプに応じて、次の項を参照してください。
Javaコールバックを指定する手順は、次のとおりです。
「イベント」セクションの「状態」列で、タスク状態を選択します。
「Javaクラス」列の空のフィールドをクリックして値を入力します。この値は、oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaクラスの完全クラス名です。図29-66に詳細を示します。
「OK」をクリックします。
ビジネス・イベント・コールバックを指定する手順は、次のとおりです。
「イベント」セクションの「状態」列で、タスク状態を選択します。
「Javaクラス」フィールドは空のままにします。
「ワークフロー・イベントのトリガー」チェック・ボックスを選択します。これにより、図29-67に示すように、「Javaクラス」列が使用不可になります。各コールバック(OnAssignedなど)は、1つのビジネス・イベント・ポイントに対応しています。ビジネス・イベントが起動されると、イベント詳細にはタスク・オブジェクトおよび一連のプロパティが挿入されます。各プロパティの値は、起動されるイベントの内容に基づいて移入されます。
事前にシードされている静的イベント定義言語(EDL)ファイル(JDev_Home\jdeveloper\integration\seed\soa\shared\workflow\HumanTaskEvent.edl)によって、サブスクライブ対象として使用可能なビジネス・イベントのリストが提供されます。これらのビジネス・イベントは、「コールバック詳細」ダイアログで選択したコールバックに対応しています。EDLファイルを参照し、適切なビジネス・イベントをサブスクライブするOracle Mediatorサービス・コンポーネントを作成する必要があります。
|
注意: EDLファイルを配置できるようにするには、ファイルベースのMDS接続が必要です。ファイルベースのMDSの場所は、 |
イベントをサブスクライブできる同じまたは異なるSOAコンポジット・アプリケーションに、Oracle Mediatorサービス・コンポーネントを作成します。
Oracle Mediatorの作成時に、「テンプレート」リストで、「イベントのサブスクライブ」を選択します。
「追加」アイコンをクリックして、新しいイベントをサブスクライブします。
「イベント定義」フィールドの右側にある「参照」アイコンをクリックし、EDLファイルを選択します。
「SOAリソース・ブラウザ」ダイアログが表示されます。
前に作成したファイルベースのMDS接続を選択します。
上部のリストから「リソース・パレット」を選択します。
「SOA」→「共有」→「ワークフロー」→「HumanTaskEvent.edl」の順に選択します。
「OK」をクリックします。
これで、選択可能なEDLファイル・ビジネス・イベントが「イベント・チューザ」に移入されます。
「イベント」フィールドで、サブスクライブするイベントを選択します。図29-68に詳細を示します。
イベントのサブスクライブに使用可能なヒューマン・タスクは複数あります。たとえば、次を実行したとします。
イベント(OnAssignedなど)をサブスクライブするTaskAというヒューマン・タスクを構成しました。
同じイベントをサブスクライブするTaskBというヒューマン・タスクを構成しました。
TaskAとTaskBのイベントを区別し、意図したOracle Mediatorによってイベントを確実に処理するためには、静的なルーティング・フィルタを追加できます。
xpath20:compare(med:getComponentName(), 'TaskA')
これにより、送信コンポーネントがTaskAの場合にのみ、このルーティングが起動されます。
EDLファイルがファイルベースのMDS接続から選択されなかった場合、プロンプトに従って依存XSDファイルのインポートを受け入れ、「OK」をクリックします。EDLファイルがファイルベースのMDS接続から選択された場合、プロンプトは表示されません。
これで、Oracle Mediatorサービス・コンポーネントに、サブスクライブするビジネス・イベントが移入されます。同じEDLファイルに定義されている他のビジネス・イベントも、この時点で、または後でサブスクライブできます。
ビジネス・イベントおよびコールバックの詳細は、次の各項を参照してください。
ビジネス・イベントの詳細は、第41章「ビジネス・イベントおよびイベント配信ネットワークの使用」を参照してください。
サンプルのworkflow-116-WorkflowEventCallback(Oracle SOA Suiteサンプルで使用できます)。
通常、BPELプロセスはワークフロー・コンポーネントをコールしてユーザーにタスクを割り当てます。ワークフローが完了すると、ヒューマン・ワークフロー・サービスはBPELプロセスにコールバックされます。ただし、詳細なコールバック(たとえば、onTaskUpdateまたはonTaskEscalated)をBPELプロセスに送信する場合は、「BPELコールバックのタスクとルーティング・カスタマイズを許可」オプションを使用できます。
このコールバック設定については、BPELダイアグラムを必ず手動でリフレッシュしてください。
BPELコールバックのタスクとルーティングのカスタマイズを指定する手順は、次のとおりです。
「イベント」セクションで、「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。
Oracle BPELデザイナに戻ります。
タスクのアクティビティ・ダイアログを開きます。
「OK」をクリックします。
これにより、タスクのscopeアクティビティ内に、BPELコールバックをカスタマイズするためのwhile、pick、およびpickアクティビティのonMessageブランチが作成されます。
タスクとルーティング・カスタマイズの指定の詳細は、第28.4.5.1項「BPELコールバックの起動」を参照してください。
図29-69に、ヒューマン・タスク・エディタの「ドキュメント」セクションを示します。
