| Oracle® Fusion Middleware Oracle Business Process Management Studioでのビジネス・プロセスの開発 12c (12.2.1.1) E79347-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Process Management Studioでのビジネス・プロセスの開発 12c (12.2.1.1) E79347-01 |
|
|
前 |
次 |
この章では、ヒューマン・タスクの異なるプロパティを構成する方法について説明します。基本プロパティ、タスク・ペイロード・データ構造、参加者の割当て、ルーティング・ポリシー、ローカリゼーション、エスカレーション、通知プリファレンス、アクセス・ポリシーとタスク・アクション、制限、およびJavaコールバックとビジネス・イベント・コールバックについて説明します。
この章の内容は次のとおりです。
ヒューマン・ワークフロー問題のトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のヒューマン・ワークフローのトラブルシューティングに関する項を参照してください。
この項では、ヒューマン・タスク・エディタのセクションにアクセスする方法について説明します。
各セクションについて簡単に説明し、詳細の参照先を示します。
ヒューマン・タスク・エディタのセクションにアクセスする手順は、次のとおりです。
ヒューマン・タスク・エディタは、図29-1の左側に示す主要なセクションで構成されています。これらのセクションを使用すると、ヒューマン・タスクのメタデータを設計できます。
表29-1に、ヒューマン・タスク・エディタのこれらの主要なセクションを使用してワークフロー・タスクを作成する方法を示します。
表29-1 ヒューマン・タスク・エディタ
| セクション | 説明 | 参照先 |
|---|---|---|
一般 (「タイトル」、「説明」、「結果」、「カテゴリ」、「優先度」、「所有者」および「アプリケーション・コンテキスト」) |
タスクの詳細(タイトル、タスクの結果、所有者、その他の属性など)を定義できます。 |
|
データ |
タスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を定義できます。 |
|
割当て |
参加者をタスクに割り当て、そのタスクをワークフローを使用してルーティングするためのポリシーを作成できます。 |
|
プレゼンテーション |
次の設定を指定できます。
|
|
期限 |
タスクの有効期間、カスタム・エスカレーションJavaクラスおよび期日を指定できます。 |
|
通知 |
ユーザーにタスクが割り当てられたとき、またはタスクのステータスが変化したときの通知を作成して送信できます。 |
|
アクセス |
タスク・コンテンツとタスク・アクションのアクセス・ルール、ワークフロー署名ポリシーおよび割当て制限を指定できます。 |
|
イベント |
コールバック・クラスおよびBPELコールバックでのタスクとルーティングの割当てを指定できます。 |
|
ドキュメント |
- |
このセクションでは、タスクのタイトル、説明、結果、カテゴリ、優先度、所有者などの詳細を指定できます。
この項の内容は次のとおりです。
タスクのタイトルを指定する手順は、次のとおりです。
タスクのタイトルを入力します(オプション)。開始したタスクにタイトルが設定されていない場合のみ、この値がタイトルにデフォルト設定されます。このタイトルによって、タスクが視覚的に識別されます。タスクのタイトルはOracle BPM Worklistに表示されます。タイトルは、Oracle BPM Worklistで検索することもできます。
必要に応じて、「一般」セクションの「説明」フィールドにタスクの説明を指定できます。説明を使用すると、タスクに関する補足的な詳細を提供できます。たとえば、タスクのタイトルがコンピュータのアップグレード・リクエストの場合、このフィールドには、コンピュータのモデル、CPUの能力、RAM容量などの補足的な詳細を記載できます。この説明は、Oracle BPM Worklistには表示されません。
タスクの説明を追加する手順は次のとおりです。
ドロップダウン・メニューを選択し、「プレーン・テキスト」と「変換」のいずれかを選択します。
説明を入力します。
プレーン・テキスト:
ダイアログ・ボックスに説明を入力します。
「OK」をクリックします。
変換:
「ルックアップ」ボタンをクリックします。
リソース・バンドルを見つけ、説明を入力します。
「OK」をクリックします。
タスクの結果により、タスクに可能な結果が取得されます。Oracle BPM Worklistには、ここで指定した結果が実行時に実行可能なタスク・アクションとして表示されます。図29-3に詳細を示します。
次のタイプのタスクの結果を指定できます。
シード済結果の選択
カスタム結果の入力
タスクの結果には、ここで指定した実際の結果値とは異なる実行時の表示値を割り当てることもできます。これにより、Oracle BPM Worklistでは、結果を異なる言語で表示できます。国際化の詳細は、「多言語設定の指定方法」を参照してください。
タスクの結果を指定する手順は、次のとおりです。
タスクに予想される結果が「結果」ダイアログ・ボックス(図29-4を参照)に表示されます。「APPROVE」および「REJECT」はデフォルトで選択されています。
タスクの優先度を指定します。優先度は、1から5までで、1が最高値です。タスクの優先度は、デフォルトで3に設定されています。この優先度値は、「ヒューマン・タスクの作成」ダイアログ・ボックスの「一般」タブで優先度値を選択するとオーバーライドされます。優先度に基づいてタスクをフィルタ処理し、Oracle BPM Worklistで優先度のビューを作成できます。
タスク優先度を指定する手順は、次のとおりです。
「ヒューマン・タスクの作成」ダイアログ・ボックスでの優先度の値の指定の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。
タスク・カテゴリは、必要に応じて、「一般」セクションの「カテゴリ」フィールドに指定できます。この指定によって、システムで作成されるタスクのカテゴリが決まります。たとえば、ヘルプ・デスク環境では、顧客のリクエストをソフトウェア関連またはハードウェア関連として分類できます。カテゴリはOracle BPM Worklistに表示されます。カテゴリに基づいてタスクをフィルタ処理し、Oracle BPM Worklistでカテゴリのビューを作成できます。
タスク・カテゴリを指定する手順は、次のとおりです。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、割当て済タスクの参加者タイプのいずれかにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも実行できます。タスク所有者は、タスクのビジネス管理者と見なすことができます。また、『Oracle SOA SuiteでのSOAアプリケーションの開発』のタスク所有者の指定に関する項で説明されているように、「ヒューマン・タスクの作成」ダイアログ・ボックスの「詳細」タブでタスク所有者を指定することもできます。ここに入力したタスク所有者は、「詳細」タブで指定したタスク所有者によって上書きされます。
タスク所有者の詳細は、「タスクのステークホルダ」を参照してください。
タスク所有者を指定する手順は、次のとおりです。
ユーザー、グループおよびアプリケーション・ロールの詳細は、「参加者の割当て」を参照してください。
タスク所有者は、Oracle SOA Suiteで使用するように構成されたユーザー・ディレクトリ(Oracle Internet Directory、Java AuthoriZatioN (JAZN)/XML、LDAPなど)またはアプリケーション・ロールのリストを参照することで選択できます。
ユーザー・ディレクトリまたはアプリケーション・ロールのリストを介してタスク所有者を静的に指定する手順は、次のとおりです。
「一般」セクションの「所有者」フィールドの右側にある最初のリストで、タスク所有者のタイプとして「ユーザー」、「グループ」または「アプリケーション・ロール」を選択します。図29-5に詳細を示します。
注意:
デフォルトで、ヒューマン・タスク内のグループ名は大/小文字を区別します。したがって、Groupを選択した場合に大文字の名前(たとえば、LOANAGENTGROUP)を入力すると、Oracle BPM Worklistの「管理タスク」タブにはタスクが表示されません。グループ名で大/小文字を不可知にする(大/小文字を区別しない)には、システムMBeanブラウザでcaseSensitiveGroupsプロパティをfalseに設定する必要があります。詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。
「一般」セクションの「所有者」フィールドの右側にある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」をクリックします。
タスクで使用するアプリケーション・ロールが含まれているアプリケーションの名前を指定できます。これによって、アプリケーション・ロールが操作するコンテキストが指定されます。タスクを明示的に作成しなくても結果的に所有した場合は、このコンテキストを設定できます。
注意:
Oracle Process WorkspaceおよびOracle BPM Worklistアプリケーションでアプリケーション・ロールにタスクを再割り当てできるようにするために、タスク定義にアプリケーション・コンテキストを設定する必要があります。
このセクションでは、XSDファイルに定義されているタスク・ペイロード(タスクのデータ)の構造(メッセージ要素)を指定できます。
図29-13に、ヒューマン・タスク・エディタの「データ」セクションを示します。
XSDファイルの要素を表すパラメータを作成します。これにより、ペイロード・データがワークフロー・タスクで使用できるようになります。次に例を示します。
ストアフロント・アプリケーションから注文するための注文ID要素に対してパラメータを作成します。
ヘルプ・デスク・リクエストを作成するための場所、タイプ、問題の説明、重大度、ステータスおよび解決の各要素に対してパラメータを作成します。
タスク・ペイロード・データは、1つ以上の要素またはタイプで構成されます。選択内容に基づいてタスク・ペイロードのXMLスキーマ定義が作成されます。
このセクションでは、ビジネス要件を満たす参加者タイプを選択できます。参加者タイプを構成するときは、タスクを操作するユーザー、グループおよびアプリケーション・ロールのリストを作成します。
図29-16に、ヒューマン・タスク・エディタの「割当て」セクションを示します。
単純または複雑なワークフロー・ルーティング・ポリシーを作成するためには、参加者タイプを簡単に組み合せて調整できます。以前に構成したヒューマン・タスクの機能を拡張して、より複雑なワークフローをモデリングすることもできます。
参加者タイプはステージの下のブロックにグループ化されます(たとえば、図29-16ではStage1という名前です)。ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。1つ以上のステージを順番に、またはパラレルで指定できます。各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。参加者タイプ・ブロックの順序は、[↑]キーと[↓]キーを使用して再配置できます。
次に例を示します。
すべての参加者タイプ・ブロックを単一のステージに作成できます(たとえば、注文のすべての内容が全体として承認または却下される注文書リクエスト)。
より複雑な承認タスクを作成して、1つ以上のステージを含めることができます。たとえば、最初のステージに参加者タイプ・ブロックのグループを配置し、2番目のステージに他のブロックを配置できます。第1ステージに配置した参加者のリストでは明細入力の承認が処理され、第2ステージに配置した参加者のリストではヘッダー入力の承認が処理されます。
参加者タイプごとに、構成タスクに使用するエディタが関連付けられています。割当て先の追加順序は、実行順序を示します。
別のステージ名を指定したり、追加ステージの作成が必要なビジネス要件を指定するには、次の手順を実行します。追加ステージの作成は高度な要件で、自社の環境には必要がない場合があります。
この項の内容は次のとおりです。
参加者タイプの詳細は、「タスクの割当ておよびルーティング」を参照してください。
ステージ名を指定し、パラレルおよび順次ブロックを追加する手順は、次のとおりです。
デフォルトでは、ステージに「Stage1」という名前が指定されます。ただし、この名前は変更できます。
図29-18に示すように、第2ステージが第1ステージに対してパラレルに追加されます。
タスク参加者を割り当てる手順は、次のとおりです。
「割当て」セクションで、次のいずれかのタスクを実行します。
「コンポーネント」ウィンドウから参加者を「ステージ」上にドラッグ・アンド・ドロップします。タスク参加者を初めて作成すると、このボックスには「<参加者の編集>」のラベルが付きます。
または
参加者のボックスをダブルクリックします。
「参加者タイプの編集」ダイアログ・ボックスが表示されます。このダイアログ・ボックスでは、特定の参加者タイプを選択できます。
「タイプ」リストから、図29-20に示す参加者タイプを選択します。
選択内容に応じて、表29-6に示す項を参照してください。
表29-6 参加者タイプ
| 参加者タイプ | この参加者タイプの説明参照先 | この参加者タイプの構成手順参照先 |
|---|---|---|
|
タスク参加者とタスク・ステージの無効化
タスクに追加した参加者またはステージを無効化できます。タスクの一時的な変更が必要な場合、ステージまたは参加者全体を削除して再度追加するのではなく、この無効化機能を使用します。タスク参加者またはタスク・ステージを無効にするには、参加者またはステージの横にあるチェック・ボックスの選択を解除します。
図29-21に、単一参加者タイプの「参加者タイプの編集」ダイアログ・ボックスを示します。図29-22に、展開された「詳細」セクションを示します。
タスクに対して動的に割り当てるために、単一参加者をグループ、アプリケーション・ロールまたは参加者リストから選択できます。
単一参加者タイプを構成する手順は、次のとおりです。
参加者リストに割り当てられているユーザーは、タスクを操作できます。単一タスク参加者リストでは、タスクの操作に必要なユーザーは1人のみです。単一のユーザーか、このパターンのユーザー、グループまたはアプリケーション・ロールのリストを指定できます。リストが指定されている場合、リスト上のすべてのユーザーがタスクに割り当てられています。このうちの1人が手動でタスクを申告して操作する必要があるか、または割当てパターンによっていずれかのユーザーがリストから自動的に選択されるようにするかを指定できます。1人のユーザーがタスクを操作する場合、このタスクは他の割当て先のタスク・リストから取り消されます。
単一ユーザー参加者やパラレル、シリアルおよびFYIユーザー参加者に対して、次のような様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
これらのリストでは、ユーザー、グループまたはアプリケーション・ロールをタスク割当て先として静的または動的に選択できます。
値ベースの管理チェーンのリスト
管理チェーンは通常、管理チェーン階層内の複数のユーザーからシリアル承認を得るために使用されます。したがって、このリストは多くの場合、シリアル参加者タイプに有効です。通常は、階層内のすべてのユーザーがタスクを操作する場合に使用します。管理チェーンは単一参加者タイプでも使用できます。ただし、この場合は、階層内のすべてのユーザーにタスクが同時に割り当てられます。1人のユーザーがタスクを操作すると、そのタスクは、他のユーザーから取り消されます。
たとえば、注文書がマネージャに割り当てられているとします。マネージャが承認した注文は、上位のマネージャに割り当てられます。そのマネージャが承認すると、さらに上位のマネージャに割り当てられ、3人のマネージャが注文を承認するまで上位へと順番にルーティングされます。条件付き中途完了を指定した場合は、マネージャのいずれかがリクエストを却下するか、リクエストの期限が切れると、注文は却下されます。それ以外の場合、タスク・フローは引き続きルーティングされます。
ルールベースの名前と式のリストおよび管理チェーンのリスト
ビジネス・ルールを使用すると、複雑な式でタスク参加者のリストを作成できます。たとえば、$5000未満の注文書リクエストは承認のためにマネージャに送信するというビジネス・ルールを作成します。一方、$5000以上の注文書リクエストは、承認のためにマネージャのマネージャに送信します。ビジネス・ルールの2つの主要な機能は、ファクトとアクション・タイプです。詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。
参加者タイプを選択すると、図29-23に示すように、ダイアログ・ボックスを使用してタスク参加者の割当て先(ユーザー、グループまたはアプリケーション・ロール)のリストを作成するためのオプションを選択できます。前述の3つの選択肢(「名前および式」、「管理チェーン」および「ルールベース」)を使用できます。
オプションを選択した後は、図29-24に示すように、タスク参加者割当て先(ユーザー、グループまたはアプリケーション・ロール)およびデータ型を動的に割り当てます。
この項では、これらの参加者リストの作成方法について説明します。
ユーザー、グループまたはアプリケーション・ロールをタスク参加者として静的または動的に割り当てる方法を選択します。参加者リストにユーザーが含まれている場合、グループまたはアプリケーション・ロールを選択すると、動的割当てが失敗します。
概念的な情報は、次を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、「静的、動的およびルールベースのタスク割当て」を参照してください。
値ベースの名前と式で構成される参加者リストを作成する手順は、次のとおりです。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-25に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。
ダイアログ・ボックスがリフレッシュされ、図29-26に示すように、フィールドが表示されます。
管理チェーン・パラメータをタスク参加者として静的または動的に割り当てる方法を選択します。
概念的な情報については次を参照してください。
ユーザー、グループおよびアプリケーション・ロールについては、「参加者の割当て」を参照してください。
タスク参加者の静的および動的割当てについては、「静的、動的およびルールベースのタスク割当て」を参照してください。
管理チェーンについては、「単一タスク参加者リストの作成」を参照してください。
値ベースの管理チェーンに基づいて参加者リストを作成する手順は、次のとおりです。
ダイアログ・ボックスがリフレッシュされ、図29-27に示すように、フィールドが表示されます。
ルールセットは、ルールおよびデシジョン表の実行単位を提供します。また、ルールの共有単位でもあり、ルールはルールセットに属します。複数のルールセットを順番に実行できます。この処理は、ルール・フローと呼ばれます。順序はルールセット・スタックによって決まります。この順序は、スタック上でルールセットをプッシュおよびポップするルール・アクションによって操作できます。ルールセットでは、ルールの優先度を適用することで、ルールセット内でのルールの起動順序を指定します。また、ルールセットは、ルールセットが常にアクティブであること、またはルールセットが日時の範囲や開始日時または終了日時に基づいて制限されることを識別する、有効日指定も提供します。
ルールセットの作成方法は、そのルールセットへのアクセス方法に基づいています。これについては、次の項で説明しています。
注意:
ルール・ディクショナリが作成された後は、ファクトを更新できません。
ルールセットに基づいて参加者リストを指定する手順は、次のとおりです。
ビジネス・ルールによって、参加者リストを定義できます。ビジネス・ルールの使用については、2つのオプションがあります。
ルールによって、特定のリスト・ビルダー(「名前および式」、「管理チェーン」など)のパラメータが定義されます。この場合、タスク・ルーティング・パターンは、特定のリスト・ビルダーを使用するようにモデリングされます。このリスト・ビルダーには、ルールで作成されたパラメータがリストされます。ルールは、Oracle JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを返します。
「参加者のリストの作成で使用」リストから、「名前および式」または「管理チェーン」を選択します。
「属性の指定で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図29-28に詳細を示します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
特定のパターンを使用すると、パターンの評価方法を制御する入力パラメータを指定できる場合があります。たとえば、図29-25に示すように、「最も生産性の高い箇所」パターンを使用すると、生産性が計算される「時間間隔」(日数)を指定できます。入力値は静的な値とするか、またはXPath式を使用して動的に設定できます。パターンによってはパラメータを使用できない場合があります。
「OK」をクリックします。
ルールによって、リスト・ビルダーおよびリスト・ビルダー・パラメータが定義されます。この場合は、リスト自体がルールを使用して作成されます。ルールによって、リスト・ビルダーとパラメータが定義されます。
「参加者のリストの作成で使用」リストから、「ルールベース」を選択します。
「ルールセットのリスト」フィールドに、名前を入力します。
図29-29に詳細を示します。
次のいずれかの操作を行います。
「参加者が手動でタスクを申告」を選択します。このオプションを選択すると、タスクはリスト内のすべての参加者に割り当てられます。タスク割当て先の個別のユーザーは、タスクを手動で申告して作業できます。
「単一への自動割当て」リストを選択して、「ユーザー」、「グループ」または「アプリケーション・ロール」を選択し、割当てパターンを選択します。
各割当てパターンの詳細を確認し、割当てパターンを選択して構成するには、「割当てパターン」をクリックします。「割当てパターン」ダイアログ・ボックスが表示されます。図29-25に、「割当てパターン」ダイアログ・ボックスの例を示します。
「アプリケーション・サーバー」フィールドでアプリケーション・サーバー接続を指定すると、「割当てパターン」リストに割当てパターンがロードされます。「割当てパターン」リストからいずれかのパターンを選択すると、その選択の説明がテキスト・ボックスに表示されます。
その割当てパターンですべてのタイプのタスクが考慮されるようにするには、「すべてのタイプのタスクを使用してパターン条件を評価」を選択します。それ以外の場合、そのパターンでは、選択ユーザーを決定するときに、このタスク・タイプのみが考慮されます。たとえば、休暇申請タスクを最もビジーでないユーザーに割り当てる場合に、「すべてのタイプのタスクを使用してパターン条件を評価」を選択すると、最もビジーでないユーザーを決定するときに、割り当てられたすべてのタスクが考慮されます。「すべてのタイプのタスクを使用してパターン条件を評価」を選択しない場合は、最もビジーでないユーザーを決定するときに、割り当てられている休暇申請タスクのみが考慮されます。
「OK」をクリックします。
ルール・ディクショナリが未作成で、参加者リストを簡単に指定するために複数のルール関数とファクトが事前にシードされている場合は、いずれのオプションでもルール・ディクショナリが作成されます。ルール・ディクショナリには、参加者リストを作成するための次のルール関数がシードされています。
CreateResourceList
CreateManagementChainList
Taskファクトはタスク・サービスによってアサートされ、ルール条件のベースとなります。
ルール・ディクショナリが作成されると、Oracle Business Rulesデザイナが表示されます。
ルール条件をモデリングします。アクション部分で、前述の関数のいずれか1つをコールして、リストの作成を完了します。図29-30に詳細を示します。
ルール関数のパラメータは、Oracle JDeveloperモデリングでのパラメータに類似しています。Oracle JDeveloperでの構成に加え、Oracle Business Rulesデザイナでは、次の属性について複数の追加オプションを使用できます。
responseType: レスポンス・タイプが「REQUIRED」の場合は、割当て先がタスクを操作する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。
ruleName: ルール名で割当ての理由を作成できます。
lists: このオブジェクトは、作成されるリストの所有者です。このオプションをクリックすると、事前にアサートされたファクトのListsオブジェクトが表示されます。このオブジェクトはパラメータとして使用されます。
図29-31に、管理チェーンベースの参加者を指定するルールの例を示します。
複数のルールが起動されると、最も高い優先度のルールに基づいて作成されたリスト・ビルダーが選択されます。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
これは非定型ルーティングとも呼ばれます。このオプションが選択されている場合は、実行時にOracle BPM Worklistの「アクション」リストに「非定型ルート」が追加されます。
注意:
FYI参加者の上下に非定型割当て先を追加しないでください。
他の参加者をタスクに招待する手順は、次のとおりです。
図29-33および図29-34は、「パラレル」ダイアログ・ボックスの上部および下部のセクションを示しています。
この参加者タイプは、パラレルで作業する複数のユーザーが同時にタスクを操作する(たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する)必要がある場合に使用します。結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。
たとえば、ビジネス・プロセスでは、雇用プロセス中に面接担当者全員からフィードバックを収集し、それをとりまとめて各面接担当者に採用または不採用リクエストを割り当てます。最後に、面接担当者の大多数が不採用ではなく採用に投票すると、候補者が雇用されます。
参加者をパラレル参加者タイプに割り当てる手順は、次のとおりです。
「デフォルトの結果」リストで選択したデフォルトの結果をオーバーライドする投票結果を指定できます。この結果は、必要なパーセンテージに達した場合に有効になります。結果はこの表にリストされている順序で評価されます。
グループ投票詳細を指定する手順は、次のとおりです。
「式別」を選択した場合は、このフィールドの右側にある「参照」アイコンをクリックし、式を作成するための「式ビルダー」ダイアログ・ボックスを表示します。
「パーセンテージ別」を選択した場合は、このタスクの結果が有効になるために必要なパーセント値を入力します。たとえば、多数決(51)や満場一致(100)などです。たとえば、予想される2つの結果(「ACCEPT」および「REJECT」)と、5つのサブタスクがあるとします。2つのサブタスクが承認され、3つが却下された場合に、承認に必要なパーセントが50に設定されていると、タスクの結果は却下になります。図29-35に詳細を示します。
この機能は非決定性です。たとえば、サブタスクが2つある場合に30%を選択することは無意味です。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリンク
これらの参加者リストの作成方法の詳細は、「単一タスク参加者リストの作成」を参照してください。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
ヒューマン・タスク・エディタの「期限」セクションで、グローバルなエスカレーションおよび期限更新ポリシーを設定する方法の詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
図29-36に、「シリアル」ダイアログ・ボックスを示します。図29-37に、展開された「詳細」セクションを示します。
この参加者タイプを使用すると、ワークフロー用に参加者の順序リストを作成できます。たとえば、文書をJohn、MaryおよびScottに順番にレビューさせる場合は、この参加者タイプを使用します。シリアル参加者タイプの場合、参加者はユーザーまたはグループのリストになります。
シリアル参加者タイプを構成する手順は、次のとおりです。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリスト
これらの参加者リストを作成する方法は、「単一タスク参加者リストの作成」を参照してください。
ユーザー、グループまたはアプリケーション・ロールには、タスクの操作に関して与えられる時間を指定できます。ユーザー、グループまたはロールが指定の時間内に操作しないと、ヒューマン・タスク・エディタの「期限」セクション(ルーティング・スリップ・レベル)で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されているときに、この参加者が指定の期間内に操作しない場合、そのタスクは必要に応じてマネージャまたは他のユーザーにエスカレートされます。
タスク操作に時間制限を指定する手順は、次のとおりです。
このワークフロー内の次の割当て先にタスクをルーティングする前に、他の参加者をタスク割当て先として招待できます。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
他の参加者をタスクに招待する手順は、次のとおりです。
図29-38に、「FYI」タイプの「参加者タイプの編集」ダイアログ・ボックスを示します。このダイアログ・ボックスの下部には、「参加者除外リスト」が含まれています(図29-38には表示されていません)。
この参加者タイプは、ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。
たとえば、雑誌の購読契約の更新期日がきているとします。ユーザーが期日までに現在の購読契約を取り消さない場合は、購読契約の期限が更新されます。リクエストが期限切れになるかユーザーが操作するまで、このユーザーに週に1回ずつリマインダが送信されます。
FYI参加者タイプを構成する手順は、次のとおりです。
「ラベル」フィールドに、この参加者タイプを認識できるラベルを入力します。このラベル(Approval Manager、Primary Reviewersなど)は、タスク定義のすべての参加者の中で一意にする必要があります。
参加者のリストに割り当てられているユーザーは、タスクを操作できます。様々なタイプのリストを作成できます。
値ベースの名前と式のリスト
値ベースの管理チェーンのリスト
ルールベースの名前と式のリスト
ルールベースの管理チェーンのリスト
ルールベースのリスト
これらの参加者リストを作成する方法は、「単一タスク参加者リストの作成」を参照してください。
この項では、タスクを特定の順序で参加者にルーティングし、参加者が他の人を招待できるようにする方法について説明します。
参加者タイプを構成してヒューマン・タスク・エディタに戻った後に、図29-39に示す「タスクは開始参加者から最終参加者へ移行します」アイコンをクリックします。
これによって、図29-40に示す「割当ての構成」ダイアログ・ボックスが表示され、ワークフローを介してタスクをルーティングする方法を指定できます。
表29-10に、用意されているルーティング・ポリシー・メソッドを示します。
表29-10 ルーティング・ポリシー・メソッド
| ルーティング・ポリシーの選択 | このポリシーを使用する環境 | セクション |
|---|---|---|
|
参加者は、タスクを承認する際に、ユーザーまたはグループを次の割当て先(臨時)として選択できます。 |
|
|
タスクの参加者が、タスクを承認または却下できます。したがって、他の参加者にタスクが送信されずにワークフローが終了します。たとえば、マネージャが却下した注文書は、レビューのためにそのマネージャのマネージャに送信されません。 |
|
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因になることはありません。 |
|
|
注意: このオプションは、複数のステージがあり、参加者がパラレルで作業する環境を意図しています。 参加者はサブタスクをパラレルで実行し、あるグループでのサブタスクの却下または承認が、他のグループでのサブタスクの却下または承認の原因となります。 |
|
拡張ルールの使用 |
タスクのルーティング先の参加者は、モデリングしたビジネス・ルール・ロジックによって判断されます。たとえば、融資申請タスクは、融資エージェント、そのマネージャおよびシニア・マネージャを経由するように設計されているとします。この場合、融資エージェントは承認したが、そのマネージャが却下すると、その融資申請タスクは融資エージェントに戻されます。 |
|
外部ルーティングを使用 |
タスクの参加者は動的に決定されます。たとえば、ある企業のルールでは、タスク参加者は、実行時に決定しバックエンド・データベースから取得する必要があります。 |
|
「割当て」タブ |
参加者に、失敗したタスクがリカバリの目的で割り当てられます。 |
選択された参加者全員がタスクをレビューするように選択できます。これは、表示された順序で各参加者にタスクがルーティングされるデフォルト・ルーティングです。このタイプのルーティングは、ステート・マシン・ベースのルーティングとは異なります。
指定した順序でタスクを全参加者にルーティングする手順は、次のとおりです。
ルーティング・ポリシーの定義方法は、次の各タスクを参照してください。
全参加者による他の参加者の招待の許可
参加者の選択によるタスクの完了
パラレル・サブタスクでの早期完了の有効化
早期完了するサブタスクの親サブタスクの完了
このチェック・ボックスは、以前の10.1.3 Oracle BPEL Process Managerリリースの非定型ワークフロー・パターンに相当します。これは、参加者が1人以上存在する場合に適用されます。この場合は、各ユーザーがタスクの承認時に次の割当て先としてユーザーまたはグループを選択します。
全参加者に対して他の参加者の招待を許可する手順は、次のとおりです。
注意:
FYI参加者の上下に非定型割当て先を追加しないでください。
「非定型ルーティング」の下で、「すべての起案者による参加者の追加を許可」チェック・ボックスを選択し、このタスクの起案者がこのワークフローの次の割当て先にルーティングする前に、他の参加者をワークフローに招待できるようにします。
ワークフローの他の参加者に関係なくタスクを早期完了させる条件を指定できます。
たとえば、経費レポートがマネージャに送信されてから取締役に送信されるとします。最初の参加者(マネージャ)がレポートを却下した場合は、次の参加者(取締役)に送信せずにワークフローを終了できます。
条件付き中途完了を設定する手順は、次のとおりです。
このオプションは、次の環境で使用できます。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。ただし、他のパラレル・グループによるサブタスクの操作は停止されません。このグループでは、タスクの操作が続行されます。
たとえば、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。一方、第2パラレル・グループは注文ヘッダーの操作を続行します。このシナリオでは、タスク全体は早期完了しません。図29-43に詳細を示します。
このオプションは、次の環境で使用できます。
複数のステージがあり、参加者のグループがパラレルでサブタスクを実行する環境。
1グループの参加者がサブタスクを承認または却下する環境。この場合、同じグループ内の他の参加者によるタスクの操作は停止されます。これにより、他のパラレル・グループによるサブタスクの操作も停止されます。
たとえば、図29-43に示すように、それぞれが別のステージにある2つのパラレル・サブグループがあるとします。一方のグループは、注文の明細を操作します。他方のグループは、同じ注文のヘッダーを操作します。第1グループの参加者ApproveLines.Participant2が明細を却下すると、第1グループの他のすべてのタスク参加者は、タスクの操作を停止します。さらに、第2パラレル・グループも注文ヘッダーの操作を停止します。このシナリオでは、タスク全体が早期完了します。
複雑なワークフロー・ルーティング・シナリオを作成するには、拡張ルーティング・ルールを使用します。参加者タイプ(単一、パラレル、シリアル、FYI)は、中途完了、割当て先のスキップなどの基本条件を使用して、一連のユーザーから別のユーザーに直線的なフローを作成する際に使用されます。ただし、多くの場合、ワークフローの複数のユーザー間で、より複雑な前後へのルーティングを実行することが必要になります。1つの選択肢は、これらのタスクの調整として、BPELプロセスを使用することです。もう1つの選択肢は、ビジネス・ルールを使用して宣言的にルーティングを指定することです。この項では、ヒューマン・タスク・エディタとビジネス・ルールを使用して、これらの複雑な相互作用をモデリングする方法について説明します。
ステート・マシン・ルーティング・ルールは、Oracle Business Rulesを使用して定義できます。このアクションによって、評価されるOracle Business Rulesを作成できます。
その前に、ルーティング・スリップ・タスク参加者がタスクの結果を設定します。
その後に、タスクが次のルーティング・スリップ参加者に割り当てられます。
このアクションにより、「指定した順序でタスクを全参加者にルーティングする方法」に説明されている標準的なタスク・ルーティング・スリップのメソッドをオーバーライドし、タスクに対して複雑なルーティング動作を作成できます。
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つのルール・ディクショナリに分割されます。
ベース・ディクショナリ
カスタム・ディクショナリ
カスタマイズの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションのカスタマイズに関する章を参照してください。
ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成します。このルーティング・ポリシーを指定すると、他の参加者タイプはすべて無視されます。タスクのルーティングを決定する参加者タイプ(単一承認者、シリアル承認者、パラレル承認者など)のリストを実行時に提供するのは、外部ルーティング・サービスとみなされています。
このオプションは、タスク割当て先の決定にルーティング・ルールを使用しない場合に使用します。この場合、タスク割当てのすべてのロジックは、外部ルーティング・サービスに委任されます。
注意:
「割当ての構成」ダイアログ・ボックスで「外部ルーティングを使用」を選択した場合は、Javaクラスを指定し、「OK」をクリックして終了します。次回、このダイアログ・ボックスを開くと、ドロップダウン・リストには、他の2つの選択肢(「指定した順序で全参加者へタスクをルート」および「拡張ルールの使用」)は表示されません。3つの選択肢すべてに再度アクセスするには、割当て全体を削除する必要があります。
外部ルーティングを使用する手順は、次のとおりです。
図29-49に示すように、外部ルーティング・ダイアログ・ボックスが表示されます。
タスクは、間違った割当てなどの理由でエラーになることがあります。このようなエラーが発生すると、タスクは、修正処理を実行するエラー割当て先に割り当てられます。リカバリ可能なエラーは、次のとおりです。
すべての参加者に対して無効なユーザーおよびグループ。
割当て先および有効期間に関連する無効なXPath式。
有効期限のエスカレーション・エラー。
エスカレーション・ポリシーの評価
期限更新ポリシーの評価
管理チェーンの計算。
動的割当てルールの評価。タスクは、現在はエラーではありませんが、現在のユーザーに割り当てられたままです。したがって、リカバリ可能です。
動的割当ての循環割当て(「ユーザーA」→「ユーザーB」→「ユーザーA」など)。タスクは、現在はエラーではありませんが、チェーンの最終ユーザーに割り当てられたままです。したがって、リカバリ可能です。
次のエラーは、リカバリ可能ではありません。このような場合、タスクは終了状態ERROREDに移動します。
無効なタスク・メタデータ
読取り不可のタスク・メタデータ。
ステート・マシン・ルールからの無効なGOTO参加者。
割当てサービスが見つからない場合。
割当てサービスによるエラー。
カスタム・エスカレート関数の評価。
パラレルのデフォルト結果とパーセント値に対する無効なXPathおよび値。
ワークフローのエラー割当て先は、ワークフロー・タスクのモデリング中に指定できます。エラー割当て先が指定されている場合は、その割当て先が評価されてタスクが割り当てられます。実行時にエラー割当て先が指定されていない場合は、管理ユーザーが検索され、アラート状態のタスクが割り当てられます。エラー割当て先は、次のいずれかのアクションを実行します。
非定型ルート
タスクを、そのタスクに実際に割り当てられているユーザーにルーティングします。非定型ルーティングを使用すると、タスクを順番に、またはパラレルなどでユーザーにルーティングできます。注意: FYI参加者の上下に非定型割当て先を追加しないでください。
再割当て
タスクを、このタスクに実際に割り当てられているユーザーに再割当てします。
エラー・タスク
このタスクを修正できないことを示します。
エラー割当て先の評価中にエラーがあると、タスクはエラー発生としてマークされます。
このダイアログ・ボックスでは、割当てエラーが発生した場合にタスク割当て先となるユーザーまたはグループを指定できます。
エラー割当て先を構成する手順は、次のとおりです。
図29-50に示すように、「追加」アイコンをクリックして、レビューアまたはエラー割当て先を割り当てます。
「追加」アイコンをクリックし、このタスクに参加するユーザー、グループまたはアプリケーション・ロールを選択します。
「開始参加者」表の「識別タイプ」列に、選択したユーザー、グループまたはアプリケーション・ロールが表示されます。
ユーザー、グループまたはアプリケーション・ロールを選択する手順の詳細は、「単一タスク参加者リストの作成」のステップ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」をクリックします。
ユーザー、グループまたはアプリケーション・ロールの詳細は、「参加者の割当て」を参照してください。
タスク詳細を様々な言語で表示するためのリソース・バンドルを指定できます。
図29-51に示すように、「プレゼンテーション」セクションでは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するためのリソース・バンドルを指定したり、添付ファイルのWordMLおよびカスタム・スタイル・シートを指定できます。
リソース・バンドルは、Oracle BPM Worklistで様々な言語でタスク詳細を表示するように指定できます。次のタスク詳細でリソース・バンドルがサポートされます。
プレーン・テキストまたはmessage(key)書式によるタスクの結果値の表示。
様々な言語による電子メール通知メッセージの有効化。実行時にXPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を指定して、指定したリソース・バンドルから国際化された文字列を取得します。通知受信者のロケールは、関数hwf:getNotificationProperty(propertyName)で取得できます。
リソース・バンドルは単純にプロパティ・ファイルでもあります。たとえば、タスクの結果の表示名を構成するリソース・バンドルは、次のようになります。
APPROVE=Approve
REJECT=Reject
多言語設定を指定する手順は、次のとおりです。
図29-52に示す「リソースの詳細」ダイアログ・ボックスが表示されます。
「プレゼンテーション」セクションで、worklistappのタスク詳細フォームの「ランタイム履歴」セクションにレコードを指定できます。
繰返しステージのマージ: すべての繰返しステージに対する1つの集計済エントリを表示するには、このオプションを選択します。ワークリストUIは、このオプションを設定または設定解除するオプションも提供します。
将来の参加者の表示: そのタスクのすべての将来の参加者に関する詳細を表示するには、このオプションを選択します。
ユーザーが実行したアクションのみを表示: デフォルトでは、タスク履歴詳細には、ルート・タスクの更新など管理およびシステム・アクションのレコードが含まれます。タスク詳細に、ユーザーが実行したアクションの更新のみを表示しないようにするには、このオプションを選択します。
このグローバル・ポリシー・セクション(ルーティング・スリップ・レベル)で、タスクの有効期間を指定できます。
有効期間を参加者タイプ・レベルではなくルーティング・スリップ・レベルで指定すると、この期間は全参加者のタスクの有効期間となります。ただし、参加者タイプ・レベルで(「割当て済期間の制限の設定」チェック・ボックスを介して)有効期間を指定すると、その設定は「期限」セクション(ルーティング・スリップ・レベル)で指定した設定よりも優先されます。
図29-53に、ヒューマン・タスク・エディタの「期限」セクションを示します。
指定した期間後にタスクがユーザーのマネージャにエスカレートされるように指定できます。詳細は、「タスクの操作に対する時間制限の指定」を参照してください。
この項では、このレベルで有効期間を指定し、その設定を参加者全員のタスクの有効期間にする方法の概要を説明します。
たとえば、図29-54に示すように、参加者LoanAgentGroupおよび参加者Supervisorの両者間でタスクを操作するための日数が3日であるとします。
参加者レベルまたはこのルーティング・スリップ・レベルで有効期限が指定されていない場合、そのタスクの有効期間設定はありません。
参加者のいずれかのレベルで有効期間が設定されている場合、その参加者には対応する有効期間が使用されます。ただし、参加者レベルの有効期間が設定されていない参加者には、引き続きグローバルな有効期間が使用されます。グローバルな有効期間は、常にタスクでの経過時間だけ減分されます。
参加者について参加者レベルの有効期限を解析するためのポリシーは、次のとおりです。
シリアル
「管理チェーン」内の各割当ては、「シリアル」で指定されている内容と同じ有効期間を取得します。期間は、この割当てによって生じるすべての割当てに対するものではありません。タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、エスカレーションおよび期限更新ポリシーが適用されます。
パラレル:
パラレル・ワークフローでは、パラレル参加者がリソースとして指定されている場合は、リソースごとにルーティング・スリップが作成されます。作成された各ルーティング・スリップの有効期間には、次のルールが適用されます。
パラレル参加者の有効期間が指定されている場合は、その有効期間と等しい有効期間になります。
ルーティング・スリップ・レベルで指定されている場合は、タスクに残っている有効期間。
それ他の場合、有効期間はありません。
パラレル参加者がルーティング・スリップとして指定されている場合、その有効期間はルーティング・スリップにより決定されます。
注意:
パラレル・タスク内で親タスクが期限切れになった場合、期限切れになっていないサブタスクや未完了のサブタスクは取り消されます。
タスクが期限切れにならないように指定できます。
「期限切れなし」ポリシーを指定する手順は、次のとおりです。
タスクに有効期限を指定できます。タスクが期限切れになると、ルーティング・スリップ・レベルのエスカレーション・ポリシーまたは期限更新ポリシーが適用されます。どちらのポリシーも指定されていない場合、タスクは期限切れになります。ルーティング・スリップ・レベルの有効期限ポリシーは、すべての参加者に共通です。
タスクに有効期限を指定する手順は、次のとおりです。
パラレル参加者に対する有効期限ポリシーは、次のように解析されます。
パラレル参加者がパラレル要素でリソースとして指定されている場合、各パラレル参加者に対する有効期限ポリシーはありません。
パラレル参加者がルーティング・スリップとして指定されている場合、そのパラレル参加者にはルーティング・スリップの有効期限ポリシーが適用されます。
図29-55は、タスクが3日で期限切れになることを示しています。
ユーザーが割当て時間内に応答しない場合は、有効期限の期間を延長できます。このためには、期限切れの際にタスクの期限を更新できる回数(3回の追加更新など)と各期限更新期間(期限更新ごとに3日間など)を指定します。
有効期限ポリシー期間を延長する手順は、次のとおりです。
図29-56では、タスクが期限切れになると、最大3回まで期限が更新されます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。
ユーザーが割当て時間内に応答しない場合は、タスクをエスカレートできます。たとえば、ユーザー・ディレクトリに構成されているエスカレーション階層を使用している場合は、ユーザーのマネージャにタスクをエスカレートできます。エスカレーション・コールバックを使用している場合は、定義したユーザーにタスクをエスカレートできます。タスクが最大回数までエスカレートされた場合、エスカレートは停止します。エスカレートされたタスクは、そのタスクの期限切れ以降もユーザーの受信ボックス内に残すことができます。
タスク・ポリシーをエスカレートする手順は、次のとおりです。
エスカレーション・レベルの最大数
タスクをエスカレートする管理レベル数。このフィールドは必須です。
承認者の最高役職
最上位承認者の役職(自分、マネージャ、取締役またはCEOなど)。これらの役職は、対応するユーザー・リポジトリのタスク割当て先の役職と比較されます。このフィールドはオプションです。
エスカレーション・ポリシーでは、タスクを期限切れ時にエスカレートできる回数と期限更新期間を指定します。図29-57では、タスクが期限切れになると、最大3回までエスカレートされます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。
このオプションを使用すると、特定のワークフローについてカスタム・エスカレーション・ルールをプラグインできます。たとえば、期限切れ時に、タスクを現在のユーザーの部門マネージャに割り当てるには、カスタム・タスク・エスカレーション関数を記述してワークフロー・サービスに登録し、その関数をタスク定義に使用できます。
デフォルトのエスカレーション・ルールでは、タスクは現在のユーザーのマネージャに割り当てられます。新規エスカレーション・ルールを追加するには、次の手順に従います。
エスカレーション・ルールを指定する手順は、次のとおりです。
期日は、タスクを完了する必要がある日付を示すために使用されます。期日は有効期限とは異なります。期限切れタスクの場合は、期限切れとしてマークされるか、エスカレーション・ポリシーに基づいて自動的にエスカレートまたは期限更新されます。通常、期日は有効期限より早い日付で、タスクの期限切れが近いことをユーザーに示します。
図29-53に示すように、タスクの期日を入力できます。タスクは指定された期日をすぎると、期限切れとなります。この日付は有効期限ポリシーの付加項目です。期日は、有効期限ポリシーが指定されているかどうかに関係なく指定できます。期日を使用すると、Oracle BPM Worklistに期日を表示し、期限切れタスクをリストし、受信ボックス内の期限切れタスクをフィルタ処理できます。期限切れタスクは、TaskQueryService.queryTask(...) APIの述語を使用して、問合せできます。
期日を指定する手順は、次のとおりです。
注意:
To Doタスクに対してビジネス・ルールを指定することはできません。
ToDoタスクの作成方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。
通知は、ユーザーまたはグループにタスクが割り当てられる時期を示すか、タスクのステータスに変更があったことを通知します。通知は、電子メール、ボイス・メッセージ、インスタント・メッセージまたはSMSで送信できます。
図29-58に、ヒューマン・タスク・エディタの「通知」セクションの「一般」タブ(完全に開いた状態)を示します。
異なるアクションについて様々なタイプの参加者に通知が送信されます。デフォルトでは、通知はデフォルト・メッセージを使用して構成されます。たとえば、タスクが完了してクローズされたことを示す通知メッセージが送信されます。独自の構成を作成するか、既存の構成を変更できます。
注意:
組込みLDAPでは、グループの電子メール・アドレスがサポートされていません。したがって、タスクがグループIDに割り当てられると、電子メールはグループの電子メール・アドレスではなく、そのグループの全メンバーに送信されます。
参加者の通知プリファレンスを指定する手順は、次のとおりです。
「タスク・ステータス」列には、3つのデフォルト・ステータス・タイプ「割当て」、「完了」および「エラー」が表示されます。通知メッセージの受信用に他のステータス・タイプを選択できます。
受信者にタスク・ステータス変更を通知する手順は、次のとおりです。
デフォルトの通知メッセージを、選択した受信者に配信できます。必要な場合は、デフォルト・メッセージのテキストを変更できます。
通知メッセージを編集する手順は、次のとおりです。
図29-60に示す「通知メッセージの編集」ダイアログ・ボックスが表示されます。
このメッセージは、サポート対象のすべての通知チャネル(電子メール、ボイス、インスタント・メッセージおよびSMS)に適用されます。電子メール・メッセージには、このメッセージに定義したワークリスト・タスク詳細も挿入できます。メッセージの配信チャネルは、指定した通知プリファレンスに基づいています。
通知プリファレンス詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の通知に関する項を参照してください。
タスクのリマインダを送信できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づいています。リマインダの数およびリマインダ間の間隔も構成可能です。
リマインダを設定する手順は、次のとおりです。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のリマインダに関する項を参照してください。
Unicodeは、任意の言語の情報を単一の文字セットを使用して格納できる全世界共通のエンコード文字セットです。Unicodeでは、プラットフォーム、プログラムまたは言語に関係なく、すべての文字に一意のコード値が指定されます。UTF-8のデフォルト設定を使用するか、Javaクラスで文字セットを指定できます。
文字セットのエンコーディングを変更する手順は、次のとおりです。
通知のセキュア化、メッセージのアクション可能化および添付ファイルの送信を設定する手順は、次のとおりです。
「通知」セクションで、「詳細」タブをクリックします。
「通知のセキュア化(詳細を除く)」を選択します。
選択すると、デフォルトの通知メッセージが使用されます。電子メールには、HTMLのワークリスト・タスク詳細、添付ファイルまたはアクション可能なリンクはありません。メッセージにはタスク番号のみが含まれます。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の通知に関する項を参照してください。
電子メール通知メッセージにOracle BPM Worklist URLを表示するかどうかを構成できます。
通知にOracle BPM Worklist URLを表示する手順は、次のとおりです。
電子メール通知によってタスクの添付ファイルを送信できます。
電子メール通知によってタスクの添付ファイルを送信する手順は、次のとおりです。
タスクが割り当てられたグループおよびアプリケーション・ロールに電子メール通知を送信できます。
グループおよびアプリケーション・ロールに電子メール通知を送信する手順は、次のとおりです。
カスタム通知ヘッダーは、名前/値ペアを指定し、通知の中でキー・フィールドを識別するために使用されます。ユーザーは、これらの入力項目を使用して、通知の配布プリファレンスを定義します。たとえば、「名前」を「ApprovalType」、「値」を「経費」に設定したり、「名前」を「優先度」、「値」を「高」に設定することができます。その後、ユーザーはOracle BPM Worklistで配信プリファレンスを指定できます。これらのプリファレンスは通知の内容に基づいています。
ルールベースの通知サービスは、使用する優先通知チャネルを特定する目的のみに使用されます。優先チャネルのアドレスは、引き続きアイデンティティ・サービスから取得されます。
通知ヘッダーをカスタマイズする手順は、次のとおりです。
タスク・コンテンツへのアクセス・ルールと、そのコンテンツに対して実行するアクションを指定できます。
これには、タスク・コンテンツに関するアクセス・ポリシーの指定や、ワークフロー・デジタル署名ポリシーの指定方法が含まれます。
参加者が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。アクセス・ルールは、タスクの取得および更新時にタスク・オブジェクトにルールを適用するワークフロー・サービスによって規定されます。
注意:
タスク・コンテンツ・アクセス・ルールおよびタスク・アクション・アクセス・ルールは相互に独立して存在します。
アクセス・ルールは、次の詳細に基づいて算定されます。
アクセス・ルールに対応して構成されていないロールの権限は、アクセス・ルールで構成された属性によって却下されます。たとえば、割当て先が読み取るペイロードを構成するとします。このアクションでは、割当て先のみの読取り権限が有効になり、他の誰も対象になりません。割当て先も含めて、誰にも書込み権限はありません。
アクセス・ルールで構成されていない属性には、すべての権限があります。
ペイロードのメッセージ属性がアクセス・ルールで構成されている場合は、競合の可能性があるためにペイロード自体の構成は無視されます。この場合、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に詳細を示します。
このメソッドの詳細は、Oracle Fusion Middleware Oracle SOA Suiteワークフロー・サービスJava APIリファレンスを参照してください。
例29-1 APIコール
public Map<String, IPrivilege> getTaskVisibilityRules(IWorkflowContext context,
String taskId)
throws TaskMetadataServiceException;
特定のタスク・コンテンツ(ペイロードなど)の操作を特定のユーザー(タスクの作成者または所有者など)に許可する権限を指定できます。
タスク・コンテンツの操作についてユーザー権限を指定する手順は、次のとおりです。
注意:
システムで許可されている内容とは別に、アクセス・ルールは、常にアクションの実行者とタスクの現在の状態に基づいて適用されます。
タスク・コンテンツ(ペイロードなど)の操作について、「タスク・コンテンツ・アクセスの設定」ダイアログ・ボックスで指定した特定のユーザー(タスクの作成者または所有者など)に許可するアクション(アクセスまたはアクセスなし)を指定できます。
タスクの操作に対してアクションを指定する手順は、次のとおりです。
この項では、デジタル証明書の作成方法と実装方法について説明します。
注意:
デジタル署名を使用したタスクの署名は、Google ChromeブラウザとApple Safariブラウザではサポートされていません。デジタル証明書の作成と実装のタスク
個別のユーザー証明書を発行するデジタル認証局を作成する必要があります。
個別のユーザー証明書を発行するデジタル認証局を作成します。デジタル認証局を作成するには、ユーザーrootとしてログインし、Linuxの端末ウィンドウを開き、次の各コマンドを連続的に入力します。
認証局を使用して、ユーザーのデジタル証明書を作成します。
デジタル署名を使用するには、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで信頼できるCAを指定する必要があります。このCAから発行された証明書のみが、ヒューマン・ワークフローで有効と見なされます。認証局を指定する手順は、次のとおりです。
デジタル署名は、デジタル署名されたヒューマン・タスクの否認防止メカニズムを提供します。この機能は、タスクを操作する参加者に対し、タスクの更新前に詳細と各自のアクションに対する署名を義務付けることで、後で否認できないようにします。
注意:
タスクに対してデジタル署名が有効な場合、アクション可能な電子メールは実行時に送信されません。設計時にアクション可能な電子メールが有効化された場合も同様です。
ワークフロー・デジタル署名ポリシーを指定する手順は、次のとおりです。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のエビデンス・ストアに関する項を参照してください。
コールバック・クラスを使用してタスクを再割当てまたはルーティングできるユーザーを制限できます。
通常のLDAPディレクトリにシードされているユーザー・コミュニティは会社全体や部署全体を表します。ただし、タスクに関連付けるユーザーの潜在的リストは、スコープに基づいて制限したり、タスクや関連するデータの重要性に基づいて制限することが必要な場合があります。たとえば、数千のユーザーが存在する大企業では、少数のユーザーのみが注文書を承認および作成できるようにする場合があります。特にこのようなタスクでは、非定型ルーティングおよび再割当てに対して選択できるユーザーとして、会社全体規模のユーザーを対象にしないでください。かわりに、適切または権限のある少数のユーザーのみを選択対象とする必要があります。これを実行するには、制限付き割当て機能を使用します。この機能はコールバック・クラスとして実装されます。このコールバック・クラスには、インスタンス・データを含むタスク・オブジェクトが渡されるとそのタスク・オブジェクトに基づいて適切なユーザー・セットを動的に選択するロジックを実装できます。
注意:
制限付きタスクの再割当てなどの特定の関数は、単一のタスクが選択されている場合にのみ使用できます。制限付き再割当てを使用する複数のタスクが選択されている場合、制限付き再割当てアルゴリズムは起動されません。その場合、制限付き再割当てが指定されていなかったかのようにユーザーの完全なリストが返されます。
Javaコールバックまたはビジネス・イベント・コールバックを指定できます。
注意:
コールバックを実装している場合、ユーザー・コールバック実装はその他の形式の制限付き割当てをオーバーライドします。検索を実行すると、その結果には、ユーザー・コールバックによって返されるユーザーのみが表示されます。
ワークフロー・サービスのコールバックは、タスクのライフサイクルで特定のステージに到達したときにコールするように登録できます。2つのタイプのコールバックがサポートされています。
Javaコールバック: コールバック・クラスは、インタフェースoracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装している必要があります。このコールバック・クラスをサーバーのクラスパスで使用可能にします。
ビジネス・イベント・コールバック: ヒューマン・タスクの状態が変化したときに、ビジネス・イベントが発生するようにできます。Javaクラスを開発して登録する必要はありません。コール元は、承認トランザクションの現在の状態が通知されるように、Oracle Mediatorサービス・コンポーネントを使用してコールバックを実装し、適用可能なビジネス・イベントをサブスクライブします。
タスク・ステータスのコールバック・クラスを指定する手順は、次のとおりです。
Javaコールバックを指定する手順は、次のとおりです。
oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaクラスの完全クラス名です。図29-64に詳細を示します。ビジネス・イベント・コールバックを指定する手順は、次のとおりです。
事前にシードされている静的イベント定義言語(EDL)ファイル(JDev_Home\jdeveloper\integration\seed\soa\shared\workflow\HumanTaskEvent.edl)によって、サブスクライブ対象として使用可能なビジネス・イベントのリストが提供されます。これらのビジネス・イベントは、「コールバック詳細」ダイアログ・ボックスで選択したコールバックに対応しています。EDLファイルを参照し、適切なビジネス・イベントをサブスクライブするOracle Mediatorサービス・コンポーネントを作成する必要があります。
注意:
EDLファイルを配置できるようにするには、ファイルベースのMDS接続が必要です。ファイルベースのMDSの場所は、JDev_Home\jdeveloper\integration\seedです。
イベントのサブスクライブに使用可能なヒューマン・タスクは複数あります。たとえば、次を実行したとします。
イベント(OnAssignedなど)をサブスクライブするTaskAというヒューマン・タスクを構成しました。
同じイベントをサブスクライブするTaskBというヒューマン・タスクを構成しました。
TaskAとTaskBのイベントを区別し、意図したOracle Mediatorによってイベントを確実に処理するためには、静的なルーティング・フィルタを追加できます。
xpath20:compare(med:getComponentName(), 'TaskA')
これにより、送信コンポーネントがTaskAの場合にのみ、このルーティングが起動されます。
ビジネス・イベントおよびコールバックの詳細は、次の各項を参照してください。
『Oracle SOA SuiteでのSOAアプリケーションの開発』。
サンプルのworkflow-116-WorkflowEventCallback (Oracle SOA Suiteサンプルで使用できます)。
通常、BPELプロセスはワークフロー・コンポーネントをコールしてユーザーにタスクを割り当てます。ワークフローが完了すると、ヒューマン・ワークフロー・サービスはBPELプロセスにコールバックされます。ただし、詳細なコールバック(たとえば、onTaskUpdateまたはonTaskEscalated)をBPELプロセスに送信する場合は、「BPELコールバックのタスクとルーティング・カスタマイズを許可」オプションを使用できます。
このコールバック設定については、BPELダイアグラムを必ず手動でリフレッシュしてください。
BPELコールバックのタスクとルーティングのカスタマイズを指定する手順は、次のとおりです。
これにより、タスクのscopeアクティビティ内に、BPELコールバックをカスタマイズするためのwhile、pick、およびpickアクティビティのonMessageブランチが作成されます。
タスクとルーティング・カスタマイズの指定の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。
Oracle Enterprise Content Managementを使用して、ストア・ドキュメントを処理できます。
図29-67に、ヒューマン・タスク・エディタの「ドキュメント」セクションを示します。
注意:
ファイルを「プロセス・トラッキング」ページからアタッチすると、それはBPMリポジトリに移動しますが、UCMリポジトリには移動しません。そのため、UCMリポジトリを利用できない場合、「プロセス・トラッキング」ページでファイルをアップロードできます。ただし、UCMリポジトリに添付ファイルをアップロードするようにUCMリポジトリを構成してヒューマン・タスクを設計する場合、「タスク」ページでファイルをUCMリポジトリにアップロードします。ただし、「プロセス・トラッキング」ページでは、必ずファイルをBPMリポジトリにアップロードします。タスクの添付用にOracle UCMリポジトリを構成するには:
「プロジェクト・ナビゲータ」ツリーで、「ビジネス・カタログ」ノードを展開します。
「ヒューマン・タスク」ノードを展開します。
構成するヒューマン・タスクをダブルクリックします。
ヒューマン・タスク・エディタが表示されます。
「ドキュメント」タブをクリックします。
「ドキュメント・パッケージの使用」を選択します。
メタデータ・プロパティを構成するセクションが表示されます。表には、すでに必須の標準メタデータ(「セキュリティ・グループ」および「ドキュメント・タイプ」)が含まれています。
オプションで、次の手順で新しい標準またはカスタム・メタデータ・プロパティを入力します。
「追加」ボタンをクリックします。
「名前」列をクリックし、リストから標準プロパティを選択するか、カスタム名を入力します。
「値」列をクリックし、プロパティに値を割り当てます。「名前別」を選択してテキストを指定してプロパティに値を割り当てるか、または「式別」を選択して式を指定します。
「表示」列をクリックして、次の表示モードを選択します。
編集可能: 添付をアップロードするときにタスク・フォームで値を指定できます。
非表示: 値はタスク・フォームに表示されません。
読取り専用: 値はタスク・フォームに表示されますが、ユーザーは値を変更できません。
注意:
カスタム・メタデータはタスク・フォームに表示されないため、タスク・ペイロードに値をマッピングするか、または静的値を指定する必要があります。
