| Oracle® Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発 12c (12.1.3) E53007-05 |
|
 前 |
 次 |
この章の内容は次のとおりです。
警告:
SOAヒューマン・タスク・データベース表を直接変更しないでください。これらの表の列名およびデータの後方互換性は保証されません。
多くのエンドツーエンドのビジネス・プロセスでは、プロセスに人的な操作が必要です。たとえば、承認や例外管理、またはビジネス・プロセスの進行に必要なアクティビティの実行には、人的な操作が必要です。ヒューマン・ワークフロー・コンポーネントには、次の機能があります。
プロセスの人的な操作。適切なユーザーまたはグループへのタスクの割当てやルーティングなどがあります。
期限、エスカレーション、通知および他の機能。タスク(ヒューマン・アクティビティ)の適時実行を保証するために必要です。
エンド・ユーザーへのタスクの提示。ワークリスト・アプリケーション(Oracle BPM Worklist)などの様々な方法を使用します。
編成、フィルタ処理、優先度設定および他の機能。エンド・ユーザーがタスクを効率的に実行するために必要です。
レポート、再割当、ロード・バランシングおよび他の機能。監督者およびビジネス所有者がタスクのパフォーマンスを管理するために必要です。
図27-1に、ヒューマン・ワークフローの概要を示します。
図27-1では、次のアクションが発生しています。
BPELプロセスは、タスクの実行に人的な操作が必要になると、ヒューマン・タスク・タイプの特別なアクティビティを起動します。
このアクティビティによって、ヒューマン・タスク・サービス・コンポーネントにタスクが作成されます。このプロセスは、タスクが完了するまで待機します。プロセスでは、タスクからのその他のコールバックを監視し、そのコールバックに対応することも可能です。
タスクにはメタデータが関連付けられています。このメタデータは、タスクのライフサイクルを管理するために、ヒューマン・タスク・サービス・コンポーネントで使用されます。このメタデータには、次の指定が含まれています。
タスクを実行するユーザー。タスクの実行に複数のユーザーが必要な場合は、その順序。
他のステークホルダー。
タスクの完了期限。
ユーザーによるタスクの実行方法、ユーザーに提示する情報、ユーザーの入力内容と実行可能なアクション。
ヒューマン・タスク・サービス・コンポーネントでは、アイデンティティ・ディレクトリを使用して、ユーザーのロールと権限を判断します。
アイデンティティ・ストアを構成して、埋込みWebLogic LDAP、Oracle Virtual Directory、サード・パーティのLDAPおよびActive Directory RDBMSを使用できます。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
ヒューマン・タスク・サービス・コンポーネントでは、次のような様々なチャネルを使用してユーザーにタスクを提示します。
Oracle BPM Worklist。監督者やプロセス所有者の考え方をサポートするロール・ベースのアプリケーションで、タスクを検索、編成、管理および実行するための機能を提供します。
ワークリスト機能。エンタープライズ・ポータルに公開可能なポートレットとして使用することもできます。
通知。電子メール、電話、SMSおよびその他のチャネルで送信できます。電子メール通知はアクション可能で、ユーザーは、Oracle BPM WorklistまたはOracle WebLogic Serverに接続しないで、電子メール・クライアント内からタスクに対してアクションを実行できます。
この項では、ヒューマン・ワークフローの主要な設計時および実行時の概念について説明します。ヒューマン・ワークフロー設計の主要な3つのステージの概要についても説明します。
ヒューマン・タスクを設計するには、その前に、設計時および実行時の概念を理解することが重要です。タスクは通常、件名、優先度、タスク参加者、タスク・パラメータまたはデータ、期限、通知またはリマインダ、およびタスク・フォームで構成されています。この項では、主要な概念に関する概要を説明します。
注意:
ヒューマン・ワークフローの設計時タスクは、ヒューマン・タスク・エディタと呼ばれるグラフィカル・エディタで実行されます。「ヒューマン・ワークフローのチュートリアル」のチュートリアルで、このエディタの使用方法を説明しています。
ヒューマン・ワークフローでは、タスクの宣言的な割当ておよびルーティングをサポートしています。最も簡単なケースでは、タスクは単一の参加者(ユーザーまたはグループ)に割り当てられます。ただし、多くの場合は、複雑なタスク割当てとルーティングが必要です(たとえば、図27-2に示すように、タスクに管理チェーンによる承認が必要な場合や、タスクを一連のユーザーがパラレルで作業したり、投票する必要がある場合です)。ヒューマン・ワークフローでは、このようなシナリオに対して宣言的なパターン・ベースのサポートを提供します。
簡単なケースでは、参加者はユーザー、グループまたはロールにマップされます。ただし、「タスクの割当ておよびルーティング」で説明したように、ワークフローでは、管理チェーンやグループ投票などの一般的なルーティング・シナリオに対して宣言的なパターンをサポートしています。使用可能な参加者タイプは、次のとおりです。
単一の承認者
これは、1人の参加者を単一のユーザー、グループまたはロールにマップする単純なケースです。
たとえば、休暇申請がマネージャに割り当てられているとします。マネージャは、休暇が始まる3日前までに申請タスクを操作する必要があります。マネージャが申請を正式に承認または却下すると、その決定が従業員に通知されます。マネージャがタスクを操作しない場合、申請は却下として処理されます。正式な却下の場合と同様に通知アクションが実行されます。
パラレル
この参加者タイプは、一連のユーザーがパラレルで作業する必要があることを示します。このパターンは通常、投票で使用されます。
たとえば、雇用に関して複数のユーザーが応募者の採否を票決する必要がある場合です。結果が有効になるために必要な得票率(多数決や満場一致など)を指定します。
シリアル
この参加者タイプは、一連のユーザーが順番に作業する必要があることを示します。ルーティング・ポリシーには、複数の参加者を順番に使用した順番による作業を指定できますが、このパターンは一連のユーザーが動的である場合に有用です。このシリアル・タイプの一般的なシナリオは、管理チェーン・エスカレーションです。このエスカレーションは、このパターンの指定内にある管理チェーンに基づいてリストを指定することで実行されます。
FYI (情報専用)
この参加者は、単一の承認者と同様に、単一のユーザー、グループまたはロールにマップされます。ただし、このパターンは、参加者が通知タスクを単に受信し、ビジネス・プロセスではこの参加者のレスポンスを待機しないことを示します。FYIの参加者は、タスクの結果に直接影響を与えることはできませんが、場合によっては、コメントを提供したり、添付ファイルを追加できます。
たとえば、採用候補者の採用について地域マネージャが承認し、その候補が承認または却下のために州全体の統括マネージャに渡されたことが、地域の営業所に通知される場合です。FYIはタスクの結果を直接左右できませんが、コメントを提供したり添付ファイルを追加できる場合があります。
詳細は、「タスク参加者の割当て」を参照してください。
タスクは、ユーザーによる実行が必要な作業です。タスクを作成する場合は、そのタスクに参加して操作するユーザーを割り当てます。実行時に、参加者はOracle BPM Worklistからタスクに対してアクションを実行できます。これらのアクションには、休暇申請の承認、発注の却下、ヘルプ・デスク・リクエストへのフィードバックの提供などがあります。参加者には次の3つのタイプがあります。
ユーザー
タスクの操作に個別のユーザーを割り当てることができます。たとえば、特定のタスクに対してユーザーjlondonやjsteinを割り当てることができます。ユーザーは、SOAインフラストラクチャで構成されたアイデンティティ・ストアに定義されます。これらのユーザーは、Oracle WebLogic Serverの組込みLDAP、Oracle Internet Directoryまたはサード・パーティのLDAPディレクトリで定義できます。
グループ
タスクの操作にグループを割り当てることができます。グループには、タスクを要求して操作できる個別のユーザーが含まれています。たとえば、ユーザーjcooperとfkafkaは、タスクの操作を割り当てたグループLoanAgentGroupのメンバーである可能性があります。
ユーザーと同様に、グループはSOAインフラストラクチャのアイデンティティ・ストアに定義されます。
アプリケーション・ロール
タスクの要求と操作に、アプリケーション・ロールのメンバーであるユーザーを割り当てることができます。
アプリケーション・ロールは、アプリケーション・レベルで認可するように論理的にグループ化されたユーザーまたは他のロールで構成されます。これらのロールは、アプリケーション固有のもので、アプリケーションJavaポリシー・ストア(アイデンティティ・ストアではなく)で定義されます。これらのロールは、アプリケーションが直接使用するもので、Java EEコンテナによって把握されているとはかぎりません。
アプリケーション・ロールはポリシーを定義します。アプリケーション・ロールにはJava権限を付与できます。したがって、アプリケーション・ロールは、直接的または他のロールを介して間接的に付与される一連の権限を定義します。ポリシーには、エンタープライズ・グループまたはユーザーに対するアプリケーション・ロールの付与を含めることができます。ファイル・ベースのポリシー・ストアのjazn-data.xmlファイルには、これらのロールが<policy-store>の下の<app-role>要素に定義され、デプロイメント時にファーム・レベルでsystem-jazn-data.xmlに書き込まれます。これらのロールは、デプロイメント後にOracle Enterprise Manager Fusion Middleware Controlを使用して定義することもできます。ロールが事前にデプロイされている場合は、設計時に、タスク所有者または承認者をアプリケーション・ロールに設定できます。
Oracle BPM Worklistの詳細は、「タスク・フォーム」を参照してください。
多様性に対応するプロセスでは、すべての参加者を常に決定できるわけではありません。ヒューマン・ワークフローを使用すると、参加者がタスク実行の一部として他の参加者を招待できるように指定できます。
詳細は、「全参加者による他の参加者の招待または新しい参加者の編集の許可」を参照してください。
デフォルトでは、タスクは、ルーティング・ポリシーに定義したフローに従って(図27-2に示すように)、開始参加者から最終参加者へ移行します。ただし、タスクのルーティング・フロー内の特定ステップでの特定結果によっては、次の参加者へのタスクの提示を続行することが不要になったり、望ましくない場合があります。たとえば、最初のマネージャが承認を却下した場合は、2番目のマネージャにルーティングする必要はありません。ヒューマン・ワークフローでは、特定の結果が発生した場合にタスクまたはサブタスクを完了するように指定することをサポートしています。
詳細は、「次の参加者へのタスクのルーティングの停止」を参照してください。
タスクへのユーザー、グループおよびアプリケーション・ロールの割当てには様々な方法があります。
静的タスク割当て
動的タスク割当て
ユーザー、グループおよびアプリケーション・ロールを静的に(または、アイデンティティ・サービスを参照して)割り当てることができます。値は次のいずれかです。
単一のユーザー、グループまたはアプリケーション・ロール(jstein、CentralLoanRegionまたはApproverRoleなど)。
ユーザー、グループまたはアプリケーション・ロールのデリミタ付き文字列(jstein, wfaulk, cdickensなど)。
ユーザー、グループおよびアプリケーション・ロールを動的に割り当てるには、次の方法があります。
タスク割当てパターンを使用します。このパターンを使用すると、次の操作を実行できます。
簡単に参加者が手動でタスクを申請できるようにします。これはデフォルトの動作です。タスク割当てパターンは適用されません。
参加者タイプが「単一」または「FYI」のいずれかの場合は、タスク割当てパターンを割り当てて、リクエストされたタイプの単一の割当て先を参加者のすべての割当て先候補から選択できます。
たとえば、割当て先候補がユーザーjcooper、グループLoanAgentおよびアプリケーション・ロールDevelopersで構成されているとします。さらに、リクエストされたタイプがuserであるとします。このタスク割当てパターンを適用すると、単一のユーザーが、ユーザーjcooper、グループLoanAgentのすべてのメンバー、およびアプリケーション・ロールDevelopersを付与されているすべてのユーザーから選択されます。
参加者タイプが「パラレル」または「シリアル」の場合は、タスク割当てパターンを割り当てて、リクエストされたタイプの単一の割当て先を参加者のそれぞれの割当て先候補から選択できます。
たとえば、割当て先候補がユーザーjcooper、グループLoanAgentおよびアプリケーション・ロールDevelopersで構成されているとします。さらに、リクエストされたタイプがuserであるとします。このタスク割当てパターンを適用すると、ユーザーjcooper、グループLoanAgent内の1人のユーザー、およびアプリケーション・ロールDevelopersを付与されている1人のユーザーが選択されます。
XPath式を使用します。これらの式を使用すると、参加者タイプに含まれていないユーザーに対する割当てを動的に決定できます。この場合、割当て先候補のリストを作成して、そのうちの1人がタスクを申請する必要があります。
たとえば、ペイロード変数で指定されたタスク承認者の動的リストを作成するというビジネス要件を設定できます。このXPath式は、0(ゼロ)個以上のXMLノードに解決できます。各ノード値には、単一のユーザー、グループまたはアプリケーション・ロールか、デリミタで区切られたユーザー、グループまたはアプリケーション・ロールの文字列を指定できます。割当て先のデリミタ付き文字列のデフォルト・デリミタはカンマ(,)です。
たとえば、タスクに、タスク承認者が格納されているpoという名前のペイロード・メッセージ属性がある場合は、次のXPath式を使用できます。
/task:task/task:payload/po:purchaseOrder/po:approvers
ids:getManager('jstein', 'jazn.com')
この式は、jsteinのマネージャを返します。
ids:getReportees('jstein', 2, 'jazn.com')
この式は、jsteinの2レベルまでの報告先すべてを返します。
ids:getUsersInGroup('LoanAgentGroup', false, 'jazn.com')
この式は、グループLoanAgentGroupのすべての直接ユーザーと間接ユーザーを返します。
両方のオプションを同時に使用できます(たとえば、XPath式を使用してグループを動的に選択してから、タスク割当てパターンを適用して、そのグループからユーザーを動的に選択できます)。
タスクには複数のステークホルダーが含まれます。参加者は、タスク定義の割当ておよびルーティングのセクションに定義されたユーザーです。これらのユーザーは、タスクに対してアクションを実行する主要なステークホルダーです。
割当ておよびルーティング・ポリシーに指定されている参加者に加えて、ヒューマン・ワークフローでは次の追加のステークホルダーがサポートされています。
所有者
この参加者には、タスクに対するビジネス管理権限があります。この参加者は、タスク定義の一部として指定したり、起動プロセスから(および特定のインスタンスに)指定することができます。タスク所有者は、所有するタスクを操作したり、他の参加者のかわりにタスクを操作することもできます。タスク所有者は、タスクの結果と割当ての両方を変更できます。
ヒューマン・タスク・エディタで所有者を指定するには「タスク所有者の指定方法」、または「ヒューマン・タスク」ダイアログ・ボックスの「詳細」タブで所有者を指定するには「タスク所有者の指定」を参照してください。
イニシエータ
プロセスを開始するユーザーです(たとえば、イニシエータは承認用の経費レポートを提出します)。このユーザーは、開始したタスクのフィルタを使用してタスクのステータスを確認できます。また、他の参加者による情報のリクエストに関する潜在的候補者としてイニシエータを含めることは、有用な考え方です。
詳細は、「タスク・イニシエータとタスク優先度の指定」を参照してください。
レビューア
この参加者は、タスクのステータスを確認して、コメントおよび添付ファイルを追加できます。プロセス・インスタンスの属性レビューアおよびreviewerTypeを使用して実行時に参加者にレビューア・ロールを付与できます。レビューア・プロセス属性には、レビューアの名前が格納され、そのデフォルト値はProcessReviewerまたはヒューマン・タスク構成で割り当てられた値です。reviewerTypeプロセス属性には、レビューアのタイプが格納され、それらはユーザー、ロールまたはグループです。これらの属性を動的に設定して有効なレビューアを変更することができます。
管理者
この参加者は、すべてのタスクを表示して、テストの再割当てやエラーを処理するためのタスクの一時停止などの特定のアクションを実行できます。タスク管理者は、タスクの結果を変更できます。
タスク管理者は、タスク参加者が実行できる承認、却下などのアクション・タイプは実行できませんが、この参加者タイプは再割当て、取消しなどのアクションを実行できるため最も強力なタイプです。
エラー割当て先
エラーが発生すると、タスクはこの参加者に割り当てられます(存在しないユーザーにタスクが割り当てられた場合など)。エラーの割当て先は、Oracle BPM Worklistからタスク・リカバリ・アクションを実行できます。Oracle BPM Worklistは、実行時にタスク・アクションを実行するタスク・フォームです。
詳細は、「エラー割当て先とレビューアの構成方法」を参照してください。
ヒューマン・ワークフローでは、タスクに関連する期限の指定がサポートされています。期限には、次のアクションを関連付けることができます。
リマインダ:
割当て後の時刻または有効期限前の時刻に基づいて、タスクのリマインダを複数回送信できます。
エスカレーション:
タスクは、管理階層にエスカレートされます。
期限切れ:
タスクは期限切れです。
更新:
タスクは、自動的に更新されます。
詳細は、「タスクのエスカレート、期限更新または終了」を参照してください。
ヒューマン・タスクは、通知を使用するように構成できます。通知を使用すると、関連するユーザーに、タスクのライフ・サイクル期間にタスクの状態が変化したことを警告できます。たとえば、タスクの承認や取消しの際は、通知が割当て先に送信されます。
異なるアクションについて様々なタイプの参加者に通知を送信するように指定できます。たとえば、次のように指定できます。
タスクの所有者は、タスクがエラー状態の場合(存在しないユーザーに送信された場合など)通知メッセージを受信します。
タスク割当て先は、タスクがエスカレートされた場合通知メッセージを受信します。
通知メッセージのコンテンツと、メッセージの送信に使用する通知チャネルを指定できます。
アクション可能な電子メール通知メッセージを構成できます。つまり、タスク割当て先は、その電子メール内からタスクを操作できます。
ボイス・メッセージ
インスタント・メッセージ(IM)
ショート・メッセージ・サービス(SMS)
たとえば、タスク割当て先がタスクを操作する前に追加の情報をリクエストした場合は、次に示すようなメッセージを電子メールで送信できます。
For me to approve this task, more information is required to justify the need for this business trip
実行時には、メッセージ送信者のアドレスをスパムとしてマークし、不正または無効なアドレス・リストを表示することもできます。これらのアドレスは、不正アドレス・リストに自動的に追加されます。
通知の詳細は、次を参照してください。
第XI部「Oracle User Messaging Serviceの使用」
タスク・フォームは、タスクと相互作用する方法を提供します。Oracle BPM Worklistのタスク・フォームには、タスク割当て先に割り当てられたすべてのワークリスト・タスクが表示されます。特定のタスクに移動すると、タスク・フォームには、ユーザーのワークリストに対するタスクのコンテンツが表示されます。たとえば、経費承認タスクでは様々な経費の明細項目が記載されたフォームが表示され、ヘルプ・デスク・タスク・フォームでは重大度や問題の場所などの詳細が表示されます。
このため、Oracle SOA Suiteの統合開発環境には、Oracle Application Development Framework (Oracle ADF)が含まれています。Oracle ADFを使用すると、SOAコンポジット・アプリケーションのヒューマン・タスクを表すタスク・フォームを設計できます。
ADFベースのタスク・フォームは自動的に生成できます。上級ユーザーは、ADFデータ・コントロールを使用して独自のタスク・フォームを設計して、ページ上にコンテンツをレイアウトし、実行時にはワークフロー・サービス・エンジンに接続して、タスク・コンテンツを取得し、タスクを操作できます。
タスク・フォームは、JSF、.NET、またはAPIを使用する他のクライアント・テクノロジで作成できます。
詳細は、次を参照してください。
この項では、ヒューマン・ワークフローの拡張概念について説明します。
ルールベースのルーティング
Oracle Business Rulesを使用すると、ルーティング・フローを動的に変更できます。使用すると、参加者がそれぞれの手順を完了するたびに、関連付けられているルールが起動し、そのルールからルーティング・フローをオーバーライドできます。
詳細は、「ビジネス・ルールを使用した詳細タスク・ルーティングの指定方法」を参照してください。
ルールベースの参加者割当て
Oracle Business Rulesを使用すると、参加者に関連付けるユーザー、グループおよびロールのリストを動的に作成できます。
詳細は、「タスク参加者の割当て」を参照してください。
ステージ
ステージは、参加者タイプの各ブロックに対して承認プロセスを編成するための1方法です。1つ以上のステージを順番に、またはパラレルで指定できます。各ステージ内で、1つ以上の参加者タイプ・ブロックを順番に、またはパラレルで指定できます。
詳細は、「タスク参加者の割当て」を参照してください。
アクセス・ルール
割当て先が表示および更新できるタスクの部分を決定するアクセス・ルールを指定できます。たとえば、割当て先が読み取るタスク・ペイロード・データを構成できます。このアクションを使用できるのは、読取り権限のある割当て先のみです。割当て先も含めて、誰にも書込み権限はありません。
詳細は、「アクセス・ルールの概要」を参照してください。
コールバック
ヒューマン・ワークフローでは、宣言的に指定可能な詳細な動作がサポートされていますが、一部の高度な状況では、さらに拡張可能な動作が必要になる場合があります。このような拡張性はタスク・コールバックによって可能となり、これらのコールバックは、BPELプロセスまたはJavaクラスの起動時に処理できます。
詳細は、「Javaコールバックの指定」を参照してください。
Oracle BPM Worklistには、タスク分析用の組込みレポートが複数用意されています。
不参加タスク
ユーザーのグループまたは報告先のグループに割り当てられたタスクの中で、まだ獲得されていないタスクが分析されます。
タスクの優先度
ユーザー、報告先またはそのグループに割り当てられたタスクが優先度に基づいて分析されます。
タスクのサイクル・タイム
ユーザーのグループまたは報告先のグループに基づいて、タスクの割当てから完了までの所要時間が分析されます。
タスクの生産性
ユーザー、報告先またはグループについて、特定期間中に割り当てられたタスク数と完了したタスク数が分析されます。
タスク時間分布
割当て先がタスクを実行するために要した時間が表示されます。
タスクの参加者が実行したアクションの監査証跡、およびワークフローの様々な時点におけるタスク・ペイロードと添付ファイルのスナップショットを表示できます。タスクの短い履歴には、次のタスクによって作成されたすべてのバージョンが表示されます。
タスクの開始
タスクの再開始
タスクの結果の更新
タスクの完了
タスクのエラー処理
タスクの期限切れ
タスクの取消し
エラー割当て先に対するタスクのアラート
詳細は、「使用方法」を参照してください。
ヒューマン・ワークフローのモデリングは、3つのモデリング・ステージで構成されます。
ステージ1: ヒューマン・タスクのコンテンツは、ヒューマン・タスク・エディタで作成および定義します。これには、参加者タイプ、ルーティング・ポリシー、エスカレーションと有効期限のポリシー、通知などの定義が含まれます。詳細は、「ヒューマン・タスク定義の作成の概要」を参照してください。
ステージ2: ヒューマン・タスク定義をBPELプロセスに関連付けます。BPELプロセスは、一連のアクティビティ(ヒューマン・タスク・アクティビティを含む)とサービスをエンドツーエンドのプロセス・フローに統合します。詳細は、「ヒューマン・タスク定義とBPELプロセスの関連付けの概要」を参照してください。
ステージ3: タスク・フォームを作成します。このフォームでは、実行時にOracle BPM Worklistで操作するタスクの詳細が表示されます。詳細は、「タスク・フォームの生成の概要」を参照してください。
この項では、ヒューマン・ワークフローのユースケースとサービスの概要を説明します。この項の後で、ヒューマン・タスク全体の設計をチュートリアルで説明します。
休暇申請プロセスは、ユーザーから休暇の詳細を取得し、承認担当のマネージャにその申請をルーティングすることから開始されます。ユーザーの詳細と組織階層は、ユーザー・ディレクトリまたはアイデンティティ・ストアからルックアップできます。図27-3に、このシナリオを示します。
タスクは、「グループ投票」、「管理チェーン」または「承認者の順序リスト」参加者タイプの複数のユーザーを介してルーティングできます。たとえば、融資承認フローの一部として融資申請が考えられます。融資申請は、初めに融資エージェント・ロールに割り当てることができます。融資金額が$100,000を超えている場合は、特定の融資エージェントが融資を取得して承認した後で、さらに複数の管理レベルにその融資をルーティングさせることが可能です。図27-4に、このシナリオを示します。
これらのタイプをビルディング・ブロックとして使用することで、複雑なワークフローを作成できます。
カスタム・エスカレーション機能を使用すると、タスク・タイプに基づいて、優先度の高いタスクを特定のユーザーまたはロールに割り当てることができます。ただし、ユーザーが一定期間内にタスクを操作しない場合は、そのタスクを期限切れとし、追加アクションのためにマネージャにエスカレートできます。エスカレーションの一環として、電子メール、電話ボイス・メッセージまたはSMSでユーザーに通知することも可能です。同様に、マネージャは、様々なタスク割当て間で負荷を分散するために、ある報告先から別の報告先にタスクを委任できます。BPELで定義されるすべてのタスクには、関連する有効期限があります。また、図27-5に示すように、エスカレーション・ポリシーまたは期限更新ポリシーを指定する場合もあります。たとえば、ヘルプ・デスク・サービス・リクエストのプロセスの一部としてサポート・コールが考えられます。優先度の高いタスクを特定のユーザーに割り当て、そのユーザーが2日以内に対応しない場合、そのタスクは、追加アクションのためにマネージャにルーティングされます。
ユーザーは、自分のかわりに他のユーザーにタスクを実行させるように決定できます。タスクは、Oracle BPM Worklistから明示的または自動的に委任することができます。たとえば、マネージャは、自分が担当する高優先度のタスクを、休暇中はすべて自動的に直属の部下の1人にルーティングするという休暇ルールを設定します。タスクをその内容に基づいて別のユーザーにルーティングできる場合もあります。自動ルーティングのもう1つの例は、グループに属する複数のユーザー間でタスクを割り当てることです。たとえば、ヘルプ・デスクの監督者は、西部地域のすべてのタスクをラウンド・ロビン方式で割り当てたり、未処理タスクの最も少ないユーザー(最もビジーでない箇所)にタスクを割り当てるように決定します。
この項では、ヒューマン・ワークフロー・アーキテクチャの概要を説明します。次の内容について説明します。
タスクのライフ・サイクル中に様々な操作を実行するサービス。これには、ユーザーのタスクの問合せ、タスクに関連したメタデータ情報の取得などがあります。
ヒューマン・タスクは、次の2つの方法で使用します。
BPELプロセス・サービス・コンポーネントへの関連付け
スタンドアロン・モードでの使用
ヒューマン・タスクの期間におけるサービス・エンジンの役割。
リリース11g 以降、すべてのヒューマン・タスク・メタデータはメタデータ・サービス(MDS)リポジトリに保存されて管理されます。ワークフロー・サービスは、ビジネス・プロセスと人間の相互作用の様々な側面を処理する多数のサービスで構成されています。
図27-6は、次のワークフロー・サービス・コンポーネントを示しています。
タスク・サービス:
タスク・サービスにより、タスク状態の管理およびタスクの永続性が提供されます。これらのサービスに加え、タスク・サービスでは、タスクの更新、完了、エスカレート、再割当てなどの操作が公開されます。タスク・サービスは、ユーザーに割り当てられているタスクを取得するためにOracle BPM Worklistで使用されます。また、このサービスでは、タスク状態が変化したときにユーザーやグループに通知を送信するかどうかも決定されます。タスク・サービスは、次のサービスで構成されます。
タスク・ルーティング・サービス
タスク・ルーティング・サービスは、タスクのルーティング、エスカレートおよび再割当てを実行するサービスを提供します。サービスでは、宣言的な指定をルーティング・スリップ形式で解析することで、これらの決定が行われます。
タスク問合せサービス
タスク問合せサービスでは、様々な検索基準(キーワード、カテゴリ、ステータス、ビジネス・プロセス、属性値、タスクの履歴情報など)に基づいて、ユーザーのタスクを問い合せます。
タスク・メタデータ・サービス
タスク・メタデータ・サービスにより、タスク関連のメタデータ情報を取得するための操作が公開されます。
アイデンティティ・サービス
アイデンティティ・サービスは、11gのセキュリティ・インフラストラクチャまたはカスタム・ユーザー・リポジトリの上部に位置するWebサービスのシン・レイヤーです。これにより、ユーザーの認証および認可と、ユーザー・プロパティ、ロール、グループ・メンバーシップ、権限のルックアップが可能になります。
通知サービス
通知サービスは、電子メール、電話ボイス・メッセージ、IMおよびSMSのいずれかのチャネルを通じて、指定のユーザーに対して特定のコンテンツを含む通知を配信します。詳細は、「ヒューマン・ワークフローからの通知」を参照してください。
ユーザー・メタデータ・サービス
ユーザー・メタデータ・サービスにより、ワークフロー・ユーザー関連のメタデータ(ユーザー作業キュー、プリファレンス、休暇、委任ルールなど)が管理されます。
ランタイム構成サービス
ランタイム構成サービスは、タスク・サービスのランタイム環境で使用されるメタデータの管理メソッドを提供します。主に、タスク・ペイロード・マップ済属性マッピングの管理をサポートします。
エビデンス・サービス
エビデンス・サービスはデジタル署名されたワークフロー・タスクの保存と否認防止をサポートします。
図27-7は、サービスとビジネス・プロセス間の相互作用を示しています。
ヒューマン・タスクは、次の方法で使用できます。
BPELプロセスへのヒューマン・タスクの関連付け
ヒューマン・タスクをBPELプロセスに関連付けることができます。BPELプロセスは、一連のアクティビティ(ヒューマン・タスク・アクティビティを含む)とサービスをエンドツーエンドのプロセス・フローに統合します。
BPMNプロセスへのヒューマン・タスクの関連付け
ヒューマン・タスクをBPMNプロセスに関連付けることができます。BPMNプロセスには、プロセスのフローの一部として他のタイプのBPMNフロー・オブジェクトが含まれる場合があります。ヒューマン・タスクは、BPMNユーザー・タスクの実装です。
スタンドアロンのヒューマン・タスク
では、BPELプロセスに関連付けないスタンドアロン・コンポーネントとしてのヒューマン・タスクを作成することもできます。スタンドアロン・ヒューマン・タスク・サービス・コンポーネントは、アプリケーションで自動化されたアクティビティが必要のない環境で役に立ちます。スタンドアロンの場合、クライアントは独自にタスクを作成できます。
実行時、ヒューマン・タスク・サービス・コンポーネントのビジネス・ロジックおよび処理ルールは、ヒューマン・ワークフロー・サービス・エンジンによって実行されます。各サービス・コンポーネント(BPELプロセス、ヒューマン・ワークフロー、デシジョン・サービス(ビジネス・ルール)およびOracle Mediator)には、タスクを実行するための独自のサービス・エンジン・コンテナがあります。すべてのヒューマン・タスク・サービス・コンポーネントは、属しているSOAコンポジット・アプリケーションに関係なく、単一のヒューマン・タスク・サービス・エンジンで実行されます。
ヒューマン・ワークフロー・サービス・エンジンの構成、監視および管理を行う方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
Oracle SOA SuiteとOracle Business Process Management (BPM) Suiteは、どちらもビジネス・ルールとヒューマン・ワークフローのサポートを提供しています。ただし、Oracle BPM Suiteには、Oracle SOA Suiteでは使用できない追加のビジネス・ルールおよびヒューマン・ワークフロー機能があります。表27-1は、各スイートでサポートされるビジネス・ルールおよびヒューマン・ワークフロー機能を示しています。
表27-1 Oracle SOA SuiteおよびOracle BPM Suiteにおけるビジネス・ルールおよびヒューマン・ワークフロー機能
| 機能 | Oracle BPM Suiteでサポートされているか | Oracle SOA Suiteでサポートされているか |
|---|---|---|
ワークスペース、プロセス・トラッキング、標準ダッシュボード、ケース管理およびアプリケーション・メニュー |
はい |
いいえ |
承認グループ(参加者リスト) |
はい |
いいえ |
ヒューマン・ワークフローおよびビジネス・ルール(参加者リスト、ルーティング・ルール) |
はい |
はい |
動詞ルール |
はい |
いいえ |
ルール・ビジネス・フレーズ |
はい |
いいえ |
Oracle BPM Composer - デザインタイム・ルール編集 |
はい |
いいえ |
Oracle BPM StudioとOracle BPM Composerとの間のソース管理のためのプロセス・アセット・カタログ(PAM) |
はい |
いいえ |
拡張されたユーザビリティ機能を持つOracle JDeveloperとSOA Composerの両方でのルール・テスト |
はい |
はい |
ルール・デシジョン表に対するMicrosoft Excelのインポート/エクスポート |
はい |
はい |
Oracle BPM Suiteの詳細は、Oracle Business Process Management Studioを使用したビジネス・プロセスの開発を参照してください。
