32 承認管理の使用
Oracle SOA Suiteのヒューマン・ワークフロー・サービスで使用可能な承認管理の拡張機能の概要を取得します。ヒューマン・ワークフロー・サービスでは、組織の適切なユーザーのタスクを作成および追跡して、ビジネス・プロセスに参加するユーザーまたはグループとのすべての相互作用を処理します。
ユーザーは通常、Oracle BPM Worklist、電子メール、ポータル、カスタム・アプリケーションなどの各種クライアントを通じてタスクにアクセスします。承認管理の拡張機能では、ビジネス・ドキュメントおよび関連するルールを考慮して作業アイテムの承認階層を決定することで、ヒューマン・ワークフローのための複雑なタスク・ルーティング・スリップを定義できます。さらに、承認管理の拡張機能では、スーパーバイザまたはポジション階層に基づいて関連付けられたリスト・ビルダーを使用して、複数ステージの承認を定義できます。Oracle JDeveloperのヒューマン・タスク・エディタで承認タスクを定義し、そのタスクをBPELプロセスに関連付けます。
ヒューマン・タスクの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「ヒューマン・ワークフロー・サービス・コンポーネントの使用」の各章を参照してください。
この章の内容は次のとおりです。
32.1 承認管理の概要
承認管理の拡張機能(AMX)では、複雑な承認パターンでヒューマン・ワークフロー・サービスを拡張します。これは、ヒューマン・ワークフローの高度な割当てマネージャとして機能します。
主なワークフロー機能は次のとおりです。
-
承認管理プロセスの宣言モデリング
-
静的および動的な承認リストを使用して、複雑な複数ステージの承認を定義する機能
-
タスク・パラメータ、割当てとルーティングのポリシー、エスカレーションと有効期限の設定、および通知設定を定義するワークフロー・エディタ
-
ポリシー・ベースのタスク割当て。これにより、ユーザーはビジネス・ドキュメントに基づいて承認ルールを定義できます。
-
承認タスクおよび関連付けられたタスクの操作のコンテンツをレンダリングするためのタスク・フォームを設計する機能
-
ワークフロー内の様々な参加者の電子メールおよびインスタント・メッセージ(IM)の通知を定義する機能。
-
タスク割当て先、プロセス所有者および管理者の、Webベースのワークリスト・アプリケーション
-
Oracle Internet Directory、LDAPおよびサード・パーティのディレクトリなどの様々なユーザー・ディレクトリで、ユーザーおよびロールを検索する機能
AMXは、次の追加機能を提供します。
-
トランザクション・アプリケーションのADFビュー・オブジェクトから導出された属性
-
階層プロバイダ・プラグインを使用して、HRシステムから様々なジョブ、ポジションおよびスーパーバイザ階層を取得する機能
-
承認リストおよび階層の構成を制御するルールを定義する機能
32.1.1 AMXコンポーネント
次の図は、主要なAMXおよびヒューマン・タスク統合コンポーネントを示しています。これらのコンポーネントは、この章の後述の項で説明します。
ヒューマン・ワークフロー・サービスによって、ユーザーは、ビジネス・プロセスの一部として、ユーザーの相互作用をモデリングできます。ヒューマン・ワークフロー・サービスは、タスクおよびルールのメタデータに基づいてリクエストを処理します。これは、次の一連のコア・サービスで構成されています。
-
タスク・サービス
-
タスク問合せサービス
-
ユーザー・メタデータ・サービス
-
タスク・メタデータ・サービス
-
アイデンティティ・サービス
-
通知サービス
-
割当てマネージャ
これらのサービスは、『Oracle SOA SuiteでのSOAアプリケーションの開発』のヒューマン・ワークフロー・サービスの概要に関する項に詳細が説明されています。AMXは、ビジネス・ルールに基づく複雑な承認パターンのモデリングを可能にし、ヒューマン・ワークフロー内の高度な割当てマネージャとして機能します。
承認管理に必要なコア・コンポーネントは、次のとおりです。
-
JDeveloperのヒューマン・タスク・エディタ
このタスク・エディタは、ヒューマン・タスクおよびルーティング・スリップのメタデータの定義に使用されます。タスク・エディタを使用すると、このようなメタデータを、タスク・パラメータ、結果、有効期限とエスカレーション、および通知の設定として定義できます。AMXによって追加された一部のコンポーネントには、次を実行するための機能が含まれています。
-
JDeveloperで、複数ステージの承認および関連付けられた承認リスト・ビルダーを定義します。
-
ビジネス・ドキュメント(ADFオブジェクト)およびビジネス・ルールに基づいて、承認階層を決定します。これは、JDeveloperのルール・デザイナを介して行います。
-
-
ヒューマン・ワークフロー・サービス
複雑な承認を処理するのに必要な主なサービスは、次のとおりです。
-
タスク・サービス - デハイドレーション・ストア内でタスクを作成および管理する役割
-
アイデンティティ・サービス - ユーザーおよびグループの認証および認可の役割。このサービスでは、ユーザーの認可および連絡先情報用の様々なユーザー・ディレクトリを検索できます。
-
タスク問合せサービス - Webベースのワークリスト・アプリケーションのタスクを取得する役割
-
デシジョン・サービス - 承認に関連するビジネス・ルールを実行する役割
-
-
Oracle BPM Worklist
Oracle BPM Worklistは、ユーザーに割り当てられたタスクにアクセスして、承認プロセス内のロールに基づくアクションを実行できるWebベースのアプリケーションです。Oracle BPM Worklistは、次のプロファイルをサポートしています。
-
作業割当て先 - タスクを割り当てられるエンド・ユーザー。これらのユーザーは、割り当てられたタスクを表示し、アクションを実行できます。また、カスタム・ビューを定義し、タスクのルーティング・ルールを定義することもできます。
-
プロセス所有者 - 通常、承認の特定のタイプを管理する責任があるビジネス・アナリスト。これらのユーザーは、所有するプロセスのタスクを管理し、承認グループを定義し、承認ポリシーを変更できます。
-
ワークフロー管理者 - 通常、エラー発生タスクを管理し、作業キューを管理および監視する責任があるシステム管理者。このユーザーは、Oracle Enterprise Managerを使用して、ワークフロー・サービスのヘルス状態を監視することもできます。
-
32.2 承認管理の概念の理解
AMXは、複雑な承認パターンを処理する追加機能を使用して、ヒューマン・ワークフロー・サービスを拡張します。
理解している必要があるヒューマン・ワークフローの概念は、次のとおりです。
-
JDeveloperのヒューマン・タスク・エディタ
-
タスク・メタデータ(タスク・パラメータ、使用可能な操作およびパターン)およびルーティング・スリップ
-
タスク・フォームに基づくADFタスク・フロー
-
Oracle BPM Worklist
これらの概念は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「ヒューマン・ワークフロー・サービス・コンポーネントの使用」の各章に説明されています。
次の各項では、複雑な承認を処理するための概念について説明します:
32.2.1 タスク
タスクは承認を処理します。要件によって提供されるビジネスに基づいて、各承認要件に対して異なるタスクが作成されます。たとえば、新規経費精算書の承認タスクや、新規注文書の承認タスクなどです。
タスクの標準的なメタデータは次のとおりです。
-
タイトル、結果(承認、却下など)の優先度、有効期限などのタスク属性
-
シンプルなプリミティブ・タイプ、XML要素またはADFビュー・オブジェクトなどの外部エンティティに基づくタスク・パラメータ
-
承認シーケンス内の主なマイルストンを識別する1つ以上のステージを含む複雑な承認タスク。詳細は、「ステージ」を参照してください。
-
有効期限とエスカレーションのポリシー
-
様々な参加者に通知するための通知設定
-
ステージ内のリスト・ビルダー。これは、名前と式、管理チェーン、スーパーバイザ、ポジション、ジョブ・レベルの階層、または承認グループに基づいています。詳細は、「リスト・ビルダー」を参照してください。
-
承認者の置換および変更のポリシー、自動承認の構成、および繰り返された承認者などの承認タスク構成。詳細は、「タスク」を参照してください。
次の図は、サンプルの承認パターンでの様々なステージを示しています。
承認パターンは、次の4つのステージで構成されています。
-
ヘッダー承認
-
ライン承認
-
レシート検証
-
支払
ヘッダー承認は、ライン承認およびレシート検証と並行して実行されます。これらのステージの実行後に、支払ステージが実行されます。
4つの各ステージに、リスト・ビルダーがあります。ステージ内の複数のリスト・ビルダーを、相互にシリアルまたはパラレルで実行できます。各リスト・ビルダー内に1つ以上の承認者を設定できます。次の図は、これらの概念について説明しています。
これらの概念は、後述の項で説明しています。
32.2.2 サービス・データ・オブジェクト
ADFビジネス・コンポーネント・オブジェクトは、サービス・インタフェースを介してサービス・データ・オブジェクト(SDO)として簡単に公開できます。これにより、ビジネス・エンティティを受け入れる柔軟な方法が提供されます。その後、SDOをネイティブでサポートすると、複数のビジネス・エンティティを受け入れることができます。これは、将来のFlexfield SDOサポートへの基礎を築くことにもなります。SDOは構造化XMLであるため、タスク・ペイロードを介して静的XMLとしてSDOを渡すことができます。
コレクションは、タスクのエンティティ・パラメータに定義されます。これにより、XPATH式によって取得されたXMLフラグメントとして、ビジネス・エンティティの一部にアクセスできます。キーを使用すると、このフラグメントの主キーを識別できます。
エンティティ・パラメータは、SDOまたは静的XMLへのアクセス方法を示す定義です。エンティティ・パラメータは、SDOの次の情報を取得します。
-
SDO WebサービスのWebサービス定義言語(WSDL)などのSCAプロセス全体での参照のアイデンティティ
-
起動するメソッド
-
Webサービスへのメッセージの入力
-
Webサービスへのメッセージの出力
-
コレクション
エンティティ・パラメータは、静的XMLの次の情報を取得します。
-
静的XMLのXSD
-
コレクション
たとえば、経費伝票は、ヘッダー、ラインおよびコスト・センターの階層グループを持つことができます。ヘッダーおよびラインが、セット承認者を決定するのに必要な唯一のコンポーネントである場合、承認ポリシーの目的で、ヘッダーおよびラインでのコレクションのみ定義できます。ルールの定義に必要ないビジネス・ドキュメントの一部は、コレクションとしてマップする必要がありません。
詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「アプリケーション・モジュールによるビジネス・サービスの実装」および「アプリケーション・モジュールによるSOAP Webサービスの作成」を参照してください。
32.2.3 ステージ
ステージは、コレクションに関連する一連の承認です。複数の承認ステージに同じコレクションを関連付けることができます。
次の図は、ステージおよびコレクションのマッピングを示しています。
各承認ステージは、コレクションに関連付けられます。その図では、承認に4つのステージがあります。
-
ヘッダー承認は、経費ヘッダーのコレクションに関連付けられます。
-
レシート検証は、経費ヘッダーのコレクションに関連付けられます。
-
支払は、経費ヘッダーのコレクションに関連付けられます。
-
ライン承認は、経費ラインのコレクションに関連付けられます。
複合承認は、複数のステージで構成され、相互にシリアルまたはパラレルでモデリングできます。各ステージは、承認者のリストを決定するリスト・ビルダーで構成されます。
オプションで、各リスト・ビルダーを承認ポリシー、つまりルールのセットに関連付けることができます。ランタイムに、ステージ内で使用されたリスト・ビルダーおよび関連付けられたポリシーに基づいて、適切な承認のセットが戻されます。
32.2.4 リスト・ビルダー
「ステージ」で説明しているように、各承認ステージは、承認者の実際のリストを決定するリスト・ビルダーで構成されます。次のリスト・ビルダーがサポートされています。
-
名前と式
静的な名前またはXPath式から取得された名前を使用して、リストを作成できます。
-
承認グループ
事前定義された承認者グループを、承認者リストに含めます。承認グループは、静的にも動的にもなります。
-
ジョブ・レベル
スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
-
位置
ポジション階層内を上行します。指定された承認者のポジションから開始し、十分なジョブ・レベルを持つポジションが見つかるまで続行します。
-
スーパーバイザ
プライマリ・スーパーバイザ階層内を上行します。リクエスタまたは指定された承認者から開始し、固定承認者数を持つチェーンを生成します。
-
管理チェーン
対応するユーザー・ディレクトリ内の管理関係に基づいて、リストを作成できます。
管理チェーン最初の割当て先が単一ユーザーの場合、管理チェーン参加者タイプでサポートされるのはパラレル・ルーティングのみです。管理チェーンの最初の割当て先として、一連のユーザーまたはグループなどのパラレル参加者を指定することはできません。
-
ルールベース
様々な条件に基づいて様々なリスト・ビルダー・タイプを戻すルールをモデリングできます。たとえば、ルールを持つスーパーバイザ・リスト・ビルダーをモデリングする場合、ルールは、スーパーバイザ・リスト・ビルダーのみを戻すことができます。ルールベースのリスト・ビルダーをモデリングする場合、ルールは、様々なリスト・ビルダー・タイプを戻すことができます。
ノート:
承認グループ、ジョブ・レベル、ポジションおよびスーパーバイザ・リスト・ビルダーはAMXに固有で、「リスト・ビルダーをモデリングおよび構成する方法」に詳細が説明されています。
名前と式、管理チェーンおよびルールベースのリスト・ビルダーの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の単一タスク参加者リストの作成に関する項を参照してください。
32.2.5 タスク操作
標準的なヒューマン・タスク操作の大部分も、AMXベースのタスクで使用できます。共通の操作は、次のとおりです。
-
ユーザー定義の結果 - 承認および却下などの、タスクに関連付けられたビジネスの結果。ユーザーがこれらのタイプのアクションを実行すると、タスクはユーザーの受信ボックスから削除され、完了済とマークされるか、次の承認者に移動します。
-
委任 - ユーザーは、別のユーザーまたはロールに、自分の代理として処理するようにタスクを割り当てることができます。
-
エスカレート - ユーザーまたは管理者は、ユーザーのスーパーバイザに、タスクをエスカレートできます。
-
再割当て - ユーザーは、別のユーザーにタスクを転送できます。その時点から、新しいユーザーの階層が、スーパーバイザまたは他の組織ベースの承認に使用されます。
-
取消 - タスク・イニシエータまたは管理者は、承認の開始後にタスクをキャンセルまたは取消できます。
-
情報のリクエスト - タスク承認者は、前の参加者またはタスク・イニシエータから情報をリクエストできます。
-
プッシュバック - タスク承認者は、前の承認者に、再確認するようにタスクをプッシュ・バックできます。
-
非定型挿入 - タスク割当て先は、生成された承認リストに承認者を挿入できます。
ノート:
ポジション・リスト・ビルダーでは、承認者が再割当て、委任、エスカレートまたは非定型挿入の実行を行うことはできません。
アクションの完全なリストは、『Oracle SOA SuiteでのSOAアプリケーションの開発』のタスクの処理: タスクの詳細ページに関する項を参照してください。
32.2.6 承認のビジネス・ルール
タスク定義のインラインで、またはタスクの実際の承認者を識別するリスト・ビルダーを指定するビジネス・ルールを使用して、タスクの承認者を定義できます。さらに、ビジネス・ルールを使用して、承認者の置換およびリストの変更を指定できます。これらのルールは、Oracle Business Rulesのヘルプを使用して定義され、組織間で変えることができます。ただし、通常、これらは顧客によって定義されます。
ビジネス・ルールは、条件とアクションの組合せです。オプションで、ビジネス・ルールに優先度および有効期間を定義できます。ヒューマン・ワークフロー・ルールでは、タスク、タスク・メッセージおよび(SDOオブジェクトのXML表現である)エンティティ属性に対応するファクト・タイプを使用して、ルール条件が定義されます。ルール・アクションは、承認者リスト・ビルダーおよびそのパラメータで構成されます。承認者リスト・ビルダーは、特定の階層に移動し、定義されたパラメータに応じて承認者リストを作成または変更します。承認者リスト・ビルダーは、XML (JAXB)ファクト・タイプとして実装されます。
これらの概念の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のビジネス・ルール・サービス・コンポーネントの使用に関する項を参照してください。
32.2.6.1 リスト作成
リスト作成ポリシーには、リスト・ビルダーを作成するルール条件およびアクションが含まれます。
次のルールの例は、SDOベースのファクト・タイプに基づく承認者リストを作成する、スーパーバイザ・リスト・ビルダー・パラメータの構成を示しています。
詳細は、「リストを作成する方法」を参照してください。
例32-1 ルール1
IF
ExpenseItems.ReceiptAmount < 200
THEN
call CreateSupervisoryList( levels:1,
startingPoint:HierarchyBuilder.getPrinicipal("jstein",-1,"",""),
uptoApprover:HierarchyBuilder.getPrinicipal("wfaulk",-1,"",""),
autoActionEnabled:false,autoAction:null,
responseType:ResponseType.REQUIRED,ruleName:"Rule_1",lists:Lists)例32-2 ルール2
IF
xpenseItems.ReceiptAmount >= 200
THEN
call CreateSupervisoryList( levels:1,
startingPoint:HierarchyBuilder.getPrinicipal("wfaulk",-1,"",""),
uptoApprover:HierarchyBuilder.getPrinicipal("cdickens",-1,"",""),
autoActionEnabled:false,autoAction:null,
responseType:ResponseType.REQUIRED,ruleName:"Rule_2",lists:Lists)
32.2.6.2 承認者の置換
リスト置換を使用して、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。
次のルールの例は、承認者の置換の使用方法を示しています。
このルールは、経費項目の金額が4000より小さい場合、承認者jcooperを承認者jstein(承認者リストに存在する場合)に置換することを示しています。
詳細は、「承認者の置換を行う方法」を参照してください。
例32-3 承認者の置換の使用方法
IF ExpenseItems.ReceiptAmount < new BigDecimal(4000) THEN call Substitute(fromId:"jcooper", toId:"jstein", ruleName:"Substituted", substitutionRules: SubstitutionRules)
32.2.6.3 リストの変更
ジョブ・レベルおよびポジションのリストを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。
次のルールの例は、リストの変更の使用方法を示しています。
このルールは、経費項目の金額が3000より大きい場合、および承認者リストの最終承認者がジョブ・レベル3の場合、承認者リストを少なくとも相対的に2レベルまで拡張することを示しています。
詳細は、「リストの変更を行う方法」を参照してください。
例32-4 リストの変更の使用方法
IF ExpenseItems.ReceiptAmount > new BigDecimal(3000) THEN Call Extend(ifFinalApproverLevel:3, extendBy:2,ruleName:"Modified",lists:Lists)
32.3 Oracle JDeveloperでの承認管理タスクの設計
複数ステージの承認をモデリングする機能を提供するヒューマン・タスクを定義することで、承認管理タスクを設計し、ビジネス・オブジェクトおよび関連付けられたHR階層プロバイダの承認ポリシーに基づいて、適切な承認者を決定します。
この項では、JDeveloperで承認管理タスクをモデリングするのに使用する、モデリング・プロセス全体およびプロセスの詳細について説明します。
32.3.1 モデリング・プロセスの概要
承認管理タスクを設計するためのモデリング・プロセスは、次のとおりです。
-
ヒューマン・タスク定義の作成
-
ヒューマン・タスク・エディタを使用したタスク表示フォームの作成
ヒューマン・タスク定義の作成には、次のタスクがあります。
-
タスク・タイトルとタスク・タイトル・グローバリゼーション、結果、優先度、所有者およびカテゴリなどの、一般的な情報の指定
-
サービス・データ・オブジェクト(SDO)参照を持つパラメータなどの、タスク・パラメータの指定
-
ステージおよびリスト・ビルダーの指定によるタスク・ルーティングのモデリング、およびリスト・ビルダーを定義するビジネス・ルールのモデリング
-
コールバック、セキュリティ・アクセス・ルールおよび制限付き割当てなどの、詳細設定のモデリング
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の「ヒューマン・ワークフロー・サービス・コンポーネントの使用」の各章を参照してください。
32.3.2 始める前に
承認管理タスクを設計する前に、次の前提条件を満たしている必要があります。
-
SDOサービスをデプロイしている必要があります。
-
承認タスクを設計するヒューマン・タスク・サービス・コンポーネントを作成している必要があります。
32.3.3 一般的な情報の指定
タスク・タイトル、結果、優先度、所有者およびカテゴリなどの一般的な情報は、AMXに固有ではありません。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のヒューマン・タスク・アクティビティのタイトル、イニシエータ、優先度およびパラメータ変数の定義方法に関する項を参照してください。
32.3.3.1 タスク・タイトル・グローバリゼーション
タスク・オブジェクトのタイトル属性には、大部分は本質的にわかりやすい、ユーザーフレンドリな値が含まれています。AMXでは、ユーザーの優先言語でレンダリングするように、タスク・タイトルをグローバル化できます。
タイトルは、デザインタイム用に*.taskファイルで、ランタイム用にWorkflowTask.xsdファイルで定義されます。現在、これらのファイルの両方の要素の定義は、シンプルなxsd(文字列タイプ)です。翻訳可能でフォーマットされた文字列を提供するメカニズムに対応するために、グローバリゼーション用にこれらの要素の構造および使用方法を変更します。
これらの要素のデザインタイムのメタデータは、値要素および一連のオプション・パラメータを含めるように拡張されます。XPath式または静的として定義されたメッセージは、値要素に格納された情報を持ち、パラメータは必要ありません。リソース・バンドル内の情報に依存している定義済のメッセージには、定義されたパラメータを持つ値要素に格納されたキーがあります。
ヒューマン・タスク・エディタは、式ビルダーでのメカニズムを提供し、ユーザーはリソース・キーおよびパラメータを指定できます。同時に、taskDefinitionで、適切なデザインタイムのXMLを生成します。
次の図は、ヒューマン・タスク・エディタのグローバリゼーション・アイコンを示しています。
次の手順は、翻訳可能な文字列の追加方法を説明しています。これは、リソース・バンドルが指定されていることを前提としています。
-
ドロップダウン・リストから「変換」を選択します。
「グローバル」アイコンが表示されます。
-
アイコンをクリックして、「翻訳可能文字列の編集」ダイアログ・ボックスを表示します。
-
ドロップダウン・リストからキーを選択するか、プラス記号(+)をクリックしてキーを作成します。
「翻訳可能文字列の編集」ダイアログ・ボックスでプラス記号(+)をクリックすると、次の「新規キーの作成」ダイアログ・ボックスが表示されます。
-
名前、翻訳可能なテキストを入力し、「OK」をクリックします。
追加された新規キーのダイアログ・ボックスは、新規キーが追加された後の「翻訳可能文字列の編集」ダイアログ・ボックスを示しています。
-
式ビルダーを使用して、値を追加します。
翻訳可能なテキストおよび値のダイアログ・ボックスは、完了した「翻訳可能文字列の編集」ダイアログを示しています。
ノート:
タイトル値、またはタイトル値の定義は、TaskDefinition XML(
.task)ファイル、またはbpelファイルの2つの場所で設定できます。bpelファイルで設定すると、この値は、TaskDefinitionでの定義より優先されます。ただし、bpelファイル内の値は翻訳可能になりません。 -
「OK」をクリックし、ダイアログ・ボックスを閉じます。
32.3.4 タスク・パラメータの指定
タスク・パラメータの指定には、次のタスクがあります。
-
SDO参照の作成
-
エンティティ・パラメータの定義
-
コレクションの定義
32.3.4.1 サービス・データ・オブジェクト(SDO)参照を作成する方法
SDOサービスは、ワークフロー・サービスから起動して、XMLとしてSDOを取得できます。この起動は、SOA Webサービス・コールのフォームにあります。SDOサービスのWSDL URLが使用可能な場合、「Webサービスの作成」ダイアログ・ボックスを使用して、Webサービス参照を追加する必要があります。
参照を作成するには、次の図に示すように、WSDL URLを入力し、使用可能なポート・タイプからポート・タイプを選択します。
SDOの作成の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のSDOベースのEnterprise JavaBeansアプリケーションの設計に関する項のトピックを参照してください。
32.3.4.2 エンティティ・パラメータを定義する方法
次の手順によって、サービス・データ・オブジェクト(SDO)を受け入れることができます。
-
コンポジット内のサービス参照を作成します。
これにより、ファブリックは、WSDLを指す特定のURLへの必要なすべてのワイヤリングを作成できます。
-
タスク・ペイロードを外部として定義し、どのワークフローがSDOオブジェクトを取得するかを指定します。
これにより、SDO Webサービスへの入出力を表すタスク・パラメータが作成されます。
-
「エンティティ」を選択します。
-
参照を選択します。
-
ステージのコレクションを設定します。
-
「OK」をクリックします。
次の手順によって、静的XMLを受け入れることができます。
- スキーマを定義するXSDを指定します。
- タスク・ペイロード・パラメータを静的XMLとして定義します。
- コレクション、そのXPATH式およびそのキーを定義します。
- ステージのコレクションを設定します。
- 「OK」をクリックします。
32.3.4.3 コレクションを定義する方法
コレクションは、タスク・メッセージ属性の特定の部分である静的XMLベースおよびエンティティの両方の属性への参照です。コレクションを定義すると、コレクションをステージに関連付けて、コレクションの処理時にステージを識別できます。
コレクションの定義には、コレクション名の定義およびコレクション要素へのXPathの定義があります。コレクションをエンティティ属性に定義する場合、コレクション要素のキーも指定する必要があります。各キーはコレクション要素の直接の子である必要があります。次の図は、コレクションの定義方法を示しています。
コレクションを定義すると、JDeveloperによって、コレクションが繰返し要素であるかどうかが自動的に決定されます。この情報は、コレクションをステージに関連付けるときに使用されます。非繰返しコレクションは、単一のステージに関連付けることができます。繰返しコレクションは、ステージに関連付ける場合、ランタイムにコレクション内の各要素のステージをパラレルで繰り返します。コレクション情報のステージでの使用方法の詳細は、「ステージをモデリングおよび構成する方法」を参照してください。
32.3.5 マップ済属性の指定
ヒューマン・ワークフローは、タスクのペイロードから抽出されたデータなど、ユースケース固有のデータを格納するのに使用できるタスク・メッセージ属性を提供します。これらの属性は、フレックスフィールド属性またはマップ済フレックスフィールド属性とも呼ばれます。
マップ済フレックスフィールド属性を使用すると、ペイロード値を、タスク詳細で非表示にするのではなく、タスク・リスト内の列として表示できます。これらの値は、ヒューマン・ワークフロー・データベース・スキーマに格納され、問合せ、ビュー定義および割当てルール定義で使用できます。
メッセージ属性には次の2つのタイプがあります。
-
パブリック - ランタイムに特定のタスク・コンポーネントにマップされる属性。これらのマッピングはいつでも変更でき、タスク・コンポーネントの再デプロイ時に再作成する必要があります。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のマップ済属性(フレックス・フィールド)の使用に関する項を参照してください。
-
保護 - デザインタイムに定義されたタスク・コンポーネントと保護済のフレックスフィールド属性間のAMX固有のマッピング。これらはランタイムに変更できず、タスク・コンポーネントとともにデプロイされます。
表32-1には、60個の使用可能な保護済のフレックスフィールド属性がまとめられています。
表32-1 保護済のフレックスフィールド属性
名前 説明 ProtectedTextAttribute1からProtectedTextAttribute20
テキスト・データを2000文字まで格納します。タスク問合せサービスを介したOracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容がチェックされます。
ProtectedFormAttribute1からProtectedFormAttribute10
テキスト・データを2000文字まで格納します。Oracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容はチェックされません。
ProtectedURLAttribute1からProtectedURLAttribute10
テキスト・データを200文字まで格納します。Oracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容はチェックされません。
ProtectedDateAttribute1からProtectedDateAttribute10
日付情報を格納します。
ProtectedNumberAttribute1からProtectedNumberAttribute10
数値情報を格納します。
32.3.5.1 属性ラベルおよび属性ラベル・マッピングについて
属性ラベルは、意味のある文字列を、特定のフレックスフィールド属性に適用できるユーザー定義のプロパティです。ラベルは、属性に格納するデータを反映する必要があります。たとえば、CustomerNameをProtectedTextAttribute1に、OrderNumberをProtectedNumberAttribute2に、OrderDateをProtectedDateAttribute1にします。
フレックスフィールド属性は、属性に定義された複数の属性ラベルを持つことができます。たとえば、属性ProtectedTextAttribute1は、ラベルCusomerName、PartIdおよびEmployeeDepartmentを持つことがあります。
保護済の属性の属性ラベル・マッピングは、デザインタイムにヒューマン・タスク・エディタで定義されます。これらは、特定のタスク・コンポーネントと属性ラベル間のマッピングを定義し、属性の値を移入する方法を指定します。同じ属性ラベルを複数のマッピングで再利用できます。これにより、タスク・コンポーネントは、同じセマンティックな意味を持つデータを、共通のラベルで識別される共通の属性にマップできます。
たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクすべてがCustomerNameラベルへのマッピングを定義するとします。複数のタスク・コンポーネントで同じ属性ラベルを共有することによって、複数のタスク・タイプを問い合せ、共通の属性ラベルから値を表示またはフィルタ処理するワークリスト問合せを作成できます。たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクを選択し、ワークリストのタスク・リスト内の列としてCustomerNameを表示する問合せを作成できます。
32.3.6 ルーティングおよび承認ポリシーの指定
ルーティングおよび承認ポリシーの指定には、次のタスクがあります。
-
ステージのモデリングおよび構成
-
タスク参加者のモデリング
-
リスト・ビルダーのモデリングおよび構成
-
ビジネス・ルールの定義
-
ビジネス・ルールを使用したリスト・ビルダーの指定
-
割当てコンテキスト情報の使用
-
タスク承認の集計
32.3.6.1 ステージをモデリングおよび構成する方法
機能のニーズに基づいて、順次ステージおよびパラレル・ステージの組合せとなる構造に、複数のステージを追加および配置できます。この項では、順次ステージおよびパラレル・ステージの作成方法について説明します。
次の手順を使用して、ステージを作成します。
- ステージを、右側のパレットからキャンバス上の特定の場所にドラッグします。
順次ステージを作成するように選択した場合、割当ておよびルーティング・セクションは、次の図のようになります。
パラレル・ステージを作成するように選択した場合、割当ておよびルーティング・セクションは、次の図のようになります。
- 作成したステージをダブルクリックします。
次の図に示すように「編集」ダイアログ・ボックスが表示されます。
- 選択内容に従って、次のいずれかを実行します。
-
「繰返しなし」を選択した場合、「OK」をクリックして、「編集」ダイアログ・ボックスを閉じます。
-
「コレクション内の各アイテムのステージを並行して繰り返します。」を選択した場合、次の図に示すように、追加オプションが表示されます。
次を実行します。
-
デフォルトの結果を選択します。
-
同意パーセントを選択します。
-
ただちに結果をトリガーするか、または結果をトリガーせずにすべての投票の完了まで待機するかを選択します。
-
「添付とコメントの共有」チェック・ボックスを選択します。
-
「OK」をクリックして「編集」ダイアログ・ボックスを閉じます。
-
-
32.3.6.2 タスク参加者をモデリングする方法
各ステージ内で、デフォルトのタスク参加者を編集するか、新規タスク参加者を追加できます。ルーティング・パターンに基づいて、タスク参加者を次のいずれかに割り当てます。
-
単一
-
パラレル
-
シリアル
-
FYI
ルーティング・パターンの選択後に、リスト・ビルダーを選択およびモデリングする必要もあります。このプロセスは、「リスト・ビルダーをモデリングおよび構成する方法」で詳細を説明しています。
32.3.6.3 リスト・ビルダーをモデリングおよび構成する方法
ステージは、リスト・ビルダーの組合せを使用して、承認リストを生成します。詳細は、「ステージ」および「リスト・ビルダー」を参照してください。各タイプのリスト・ビルダーは、ステージごとに一度のみ使用できます。順次またはパラレルの順序で、これらの承認者リスト・ビルダーを配置できます。選択した順序は、リスト・ビルダーによって生成された承認者リストに含まれる承認者を承認タスクに割り当てる順序を制御します。
次のリスト・ビルダーは、承認管理拡張機能(AMX)に固有のものです:
-
承認グループ(「承認グループ・リスト・ビルダーをモデリングする方法」を参照)
-
ジョブ・レベル(「ジョブ・レベル・リスト・ビルダーをモデリングする方法」を参照)
-
ポジション(「ポジション・リスト・ビルダーをモデリングする方法」を参照)
-
スーパーバイザ(「スーパーバイザ・リスト・ビルダーをモデリングする方法」を参照)
「リスト・ビルダー」ダイアログでは、値ベース(「リスト・ビルダー」ダイアログを使用)またはルールベース(「ルール・エディタ」を使用)の2つの方法で属性を指定できます:
- 値ベース: 「リスト・ビルダー」ダイアログで指定した値に基づいて参加者のリストを作成するための制約を指定します。ポジション・リスト・ビルダーには適用されません。
- ルールベース: ルール・エディタで定義されたルールに基づいて参加者のリストを作成するための制約を指定します。すべてのリスト・ビルダーに適用されます。
表32-2 リスト・ビルダー・オプション
| オプション名 | 説明 | リスト・ビルダー |
|---|---|---|
|
名前 |
使用する承認グループの名前 |
承認グループ |
|
空のグループを許可 |
選択すると、メンバーのない承認グループの使用を許可します。
|
承認グループ |
|
開始参加者 |
リスト内の最初の参加者。通常はマネージャです。 |
ジョブ・レベル ポジション(ルールベースのみ) スーパーバイザ |
|
最上位の参加者 |
承認での最後の参加者。承認は、階層内でこの参加者より先には進みません。 |
ジョブ・レベル ポジション(ルールベースのみ) スーパーバイザ |
|
レベル数 |
最下位および最上位のジョブ・レベル(ジョブ・レベルの場合)またはトラバースするレベル数(スーパーバイザの場合)を指定する正の数値。この数には、絶対値、または開始点または作成者からの相対値を使用できます。 ジョブ・レベルの設定:
この表の後の「「レベル数」オプションのジョブ・レベル設定の例」を参照してください。 スーパーバイザの設定: スーパーバイザ・リスト・ビルダーのコンテキストでは、「レベル数」パラメータを使用して階層トラバースを制限できます。階層のトラバースを制御する他のパラメータは、「最上位の参加者」です。「レベル数」または「最上位の参加者」によって設定された条件のいずれかが満たされると、階層トラバースが停止します。
|
ジョブ・レベル ポジション(ルールベースのみ) スーパーバイザ |
|
相対 |
スーパーバイザが移動するレベル数、またはジョブ・レベルおよびポジションのジョブ・レベル数を指定する正数。可能な値は、開始点、作成者および絶対値です。 |
ジョブ・レベル ポジション(ルールベースのみ) |
|
最後のレベルの全マネージャを含む |
ジョブ・レベルがリスト内で以前に計算された最後の参加者のレベルと等しい場合は、リスト内の次のマネージャが含まれます。 |
ジョブ・レベル |
|
使用される参加者 |
参加者の計算済リストからこのオプションで指定された参加者のみ使用します。使用可能なオプションは、全員、最初および最後のマネージャ、最後のマネージャです。 |
ジョブ・レベル ポジション(ルールベースのみ) |
|
自動アクションの有効化 |
リスト・ビルダーが次のオプションに基づいてタスクを自動的に実行するかどうかを指定します。 |
ジョブ・レベル スーパーバイザ(ルールベースのみ) ポジション(ルールベースのみ) |
|
自動アクション |
設定される結果を指定します。自動アクションが有効でない場合は、nullにできます。 |
ジョブ・レベル スーパーバイザ(ルールベースのみ) ポジション(ルールベースのみ) |
「レベル数」オプションのジョブ・レベル設定の例
例1: 最小<最大
- 最小 = 3 (絶対値)
- 最大 = 5 (絶対値)
- 作成者 = JL1(レベル = 1)
- 開始参加者 = マネージャ
- 最後のレベルの全マネージャを含む = いいえ
- 最上位の参加者 = JL9(レベル=9)
- 開始点は常に承認フローで考慮されます: JL2
- まず最小の評価が開始されます。最小 = 3条件に従うと、JL2およびJL3が適格ですが、JL2はすでに開始点条件の一部として評価されているため、最小条件に一致するのはJL3のみです。
- 最大の評価が開始されます。最大 = 5条件に従うと、JL2、JL3、JL4およびJL5が適格ですが、JL2およびJL3はすでに開始点および最小条件の一部として評価されているため、最大条件に一致するのはJL4およびJL5のみです。
- すべての承認者: 開始点(JL2) + 最小(JL3) + 最大(JL4、JL5) = JL2、JL3、JL4、JL5
例2: 最小 = 最大
- 最小 = 4 (絶対値)
- 最大 = 4 (絶対値)
- 作成者 = JL1(レベル = 1)
- 開始参加者 = マネージャ
- 最後のレベルの全マネージャを含む = いいえ
- 最上位の参加者 = JL9(レベル=9)
- 開始点は常に承認フローで考慮されます: JL2
- まず最小の評価が開始されます。最小 = 4条件に従うと、JL2、JL3およびJL4が適格ですが、JL2はすでに開始点条件の一部として評価されているため、最小条件に一致するのはJL3およびJL4のみです。
- 最大の評価が開始されます。最大 = 4条件に従うと、JL2、JL3およびJL4が適格ですが、JL2、JL3およびJL4はすでに開始点および最小条件の一部として評価されているため、最大条件に一致するものはありません。
- すべての承認者: 開始点(JL2) + 最小(JL3、JL4) + 最大(一致なし) = JL2、JL3、JL4
階層プロバイダ・プラグインの構成
階層プロバイダ・プラグインを構成しない場合、ポジション・リスト・ビルダーは機能しません。
階層の拡張を定義する際に、プロパティmustUseSpecifiedProvider,を定義しない場合、そのデフォルト値はtrueです。
階層プラグインに問題がある場合に例外をスローしないようにスーパーバイザおよびジョブ・レベル・リスト・ビルダーを構成できます。リスト・ビルダーを構成するには、workflow-identity-config.xml構成ファイルにmustUseSpecifiedProviderプロパティを追加し、値属性をfalseに設定する必要があります。
デフォルトでは、workflow-identity-config.xmlファイルには、mustUseSpecifiedProviderプロパティが含まれていません。このプロパティが存在し、その値がfalseの場合、階層プラグインに関する問題があると、スーパーバイザおよびジョブ・レベル・リスト・ビルダーはLDAP管理チェーンを使用します。
次の例に、mustUseSpecifiedProviderプロパティを指定するworkflow-identity-config.xmlファイルを示します。このプロパティの値は、階層プラグインが使用可能でない場合に、スーパーバイザおよびジョブ・レベル・ビルダーが失敗するようにtrueに設定されています。
<ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig">
<configurations>
<configuration realmName="jazn.com">
<provider providerType="JPS" name="JpsProvider" service="Identity">
<property name="jpsContextName" value="default"/>
<property name="IdentityServiceExtension"
value="HCMIdentityServiceExtension"/>
</provider>
</configuration>
</configurations>
<property name="caseSensitive" value="false"/>
<property name="mustUseSpecifiedProvider" value="true"/> <!-- Fail when the hierarchy plug ins are not available-->
<serviceExtensions>
...
</ISConfiguration>
32.3.6.3.1 承認グループ・リスト・ビルダーをモデリングする方法
承認グループは、静的に定義された、または動的に生成された承認者のリストです。承認グループは、通常、ワークリスト・アプリケーションを使用して、プロセス所有者によって構成されます。一般に、これらは、管理承認の前後にタスクを処理する必要がある、人事や弁護士などのトランザクションの権限の管理チェーンの外側の主題専門家をモデリングするのに使用されます。
静的な承認グループは事前定義済の承認者リストで、動的な承認グループはランタイムに承認者リストを生成します。動的な承認グループでは、次を実行する必要があります。
-
開発者による動的承認者リストのインタフェースに応じた実装の提供
-
IT部門によるOracle BPM WorklistのUIを使用した動的な承認グループとしての前述の実装の登録
-
SOAクラス・パスの一部であるグローバルなウェルノウン・ディレクトリでのクラス・ファイルの可用性
タスク・ペイロードに基づいて承認グループを動的に計算する必要がある場合は、動的な承認グループを使用します。具体的には、各ラインで異なる承認グループが必要になる可能性があるライン・レベルの承認の場合などです。たとえば、コスト・センターごとに異なるコスト・センター所有者の承認が必要になることがあります。各ラインには、異なるコスト・センター所有者の承認を必要とする異なるコスト・センターがある可能性があります。コスト・センターの総数が100を超える場合は、ビジネス・ルールによる管理が困難になることがあります。
承認グループ・リスト・ビルダーの2つのビューを次の図に示します。
承認グループ・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログ・ボックスでオプションを選択します。オプションの詳細は、表32-2を参照してください。
ノート:
リソース・リストをグループで構成した場合、構成がシリアル・タイプであるかパラレル・タイプであるかにかかわらず、リソース・リストは単一タイプの参加者として動作します。
32.3.6.3.2 ジョブ・レベル・リスト・ビルダーをモデリングする方法
ジョブ・レベル・リスト・ビルダーは、スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
ジョブ・レベル・リスト・ビルダーの2つのビューを次の図に示します。
ジョブ・レベル・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログ・ボックスでオプションを選択します。オプションの詳細は、表32-2を参照してください。
32.3.6.3.3 ポジション・リスト・ビルダーをモデリングする方法
ポジション・リスト・ビルダーは、ポジション階層内を上行します。リクエスタまたは指定された承認者のポジションから開始し、指定したレベル数または特定のポジションまで進みます。
次の図は、ポジション・リスト・ビルダーの表示を示しています。
ポジション・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログ・ボックスでオプションを選択します。オプションの詳細は、表32-2を参照してください。
32.3.6.3.4 スーパーバイザ・リスト・ビルダーをモデリングする方法
スーパーバイザ・リスト・ビルダーは、プライマリ・スーパーバイザ階層内を上行します。リクエスタまたは指定された承認者から開始し、固定承認者数を持つチェーンを生成します。
ポジション・リスト・ビルダーの2つのビューを次の図に示します。
スーパーバイザ・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログ・ボックスでオプションを選択します。オプションの詳細は、表32-2を参照してください。
32.3.6.4 ビジネス・ルールを使用してリスト・ビルダーを指定する方法
タスク定義のインラインで、またはタスクの実際の承認者を識別するリスト・ビルダーを指定するビジネス・ルールを使用して、タスクの承認者を定義できます。さらに、ビジネス・ルールを使用して、承認者の置換およびリストの変更を指定できます。これらのルールは、Oracle Business Rulesのヘルプを使用して定義され、組織間で変えることができます。ただし、通常、これらは顧客によって定義されます。
ビジネス・ルールは、条件とアクションの組合せです。オプションで、ビジネス・ルールに優先度および有効期間を定義できます。ヒューマン・ワークフロー・ルールでは、タスク、タスク・メッセージおよび(SDOオブジェクトのXML表現である)エンティティ属性に対応するファクト・タイプを使用して、ルール条件が定義されます。ルール・アクションは、承認者リスト・ビルダーおよびそのパラメータで構成されます。承認者リスト・ビルダーは、特定の階層に移動し、定義されたパラメータに応じて承認者リストを作成または変更します。承認者リスト・ビルダーは、XML (JAXB)ファクト・タイプとして実装されます。
これらの概念の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のビジネス・ルール・サービス・コンポーネントの使用に関する項の各章を参照してください。
後述の項では、Oracle Business Rulesを使用した、リストの作成、承認者の置換、リストの変更および繰返しノード属性について説明します。
32.3.6.4.1 リストを作成する方法
ビジネス・ルールを使用して、使用するリスト・ビルダーを定義できます。ビジネス・ルールには2つのタイプがあります。
-
特定のリスト・ビルダーのパラメータを定義するルール。この場合、特定のリスト・ビルダーを使用するために、タスク・ルーティング・パターン・ダイアログ・ボックスがモデリングされます。リスト・ビルダーのパラメータはルールに基づきます。このオプションを使用して、ルールは、JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを戻す必要があります。次の図は、サンプル構成を示しています。
-
リスト・ビルダーおよびリスト・ビルダー・パラメータを定義するルール。この場合は、リスト自体がルールを使用して作成されます。次の図は、サンプル構成を示しています。
ルール・ディクショナリで、リスト・ビルダーの作成を容易にするために、ルール関数がシードされます。リスト・ビルダーの関数は次のとおりです:
-
CreateResourceList -
CreateSupervisoryList -
CreateManagementChainList -
CreateApprovalGroupList -
CreateJobLevelList -
CreatePositionList
次の図に示すように、ルール・デザイナで、条件をモデリングし、アクション部分で、前述の関数の1つを呼び出して、リストの作成を完了します。
ルール関数のパラメータは、JDeveloperモデリングでのパラメータに類似しています。JDeveloperでの構成に加えて、ルール・デザイナでは、次の追加のオプションが使用可能です:
| パラメータ | 説明 |
|---|---|
startingPoint
|
JDeveloperでは、開始点および上位承認者がユーザーとして指定されます。次の図に示すように、ルール・デザイナでは、 ノート: 
|
allowEmptyApprovalGroup |
次の図に示すように、ルール・デザイナでは、 有効な値:
 |
autoActionEnabled
|
ルール・デザイナでは、特定のリスト・ビルダーによって生じるユーザーがタスクを自動的に処理できるように構成できます。
|
responseType |
レスポンス・タイプがREQUIREDの場合、割当て先はタスクを処理する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。
有効な値: |
ruleName |
ルール名は、割当て理由の作成に使用されます。 有効な値: 任意の有効な文字列 |
lists |
これは、作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、事前にアサートされたファクトの |
次の図に、ルールの例を示します。
ノート:
複数のルールが起動する場合、最も優先度が高いルールによって作成されたリスト・ビルダーが選択されます。
ルールが同じ優先度の場合、ランダムな順序で起動し、最初に起動したルールが選択されます。
警告:
リスト作成ルール・セット内のルール定義が不適切または不完全な場合は、実行時エラーの原因になることがあります。次の場合にエラーが発生します。
-
ルール・セットにルールが定義されていない場合。
-
ルールに定義された条件が1つも満たされていない場合。
すべての条件を処理するよう、ルールを正しく定義してください。
32.3.6.4.2 承認者の置換を行う方法
リスト置換によって、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。各ルール・ディクショナリに、SubstitutionRulesという名前の事前にシードされたルール・セットがあります。ルール・ディクショナリには、リスト置換を構成するためのSubstituteルール関数もシードされています。表32-3には、Substitute関数およびそのパラメータがリストされています。
表32-3 Substitute関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
fromId |
置換元のユーザー/グループ/アプリケーション・ロールのID。 |
|
toId |
置換先のユーザー/グループ/アプリケーション・ロールのID。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
substitutionRules |
すべての置換のホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、SubstitutionRulesオブジェクトが表示されます。 |
ノート:
置換ルールを使用するヒューマン・タスクでは、結果の承認リストで参加者が重複する可能性があります。「将来の参加者」リストでは、重複した承認者を編集することはできません。
次の図に、承認者の置換アクションのサンプルを示します。
32.3.6.4.3 リストの変更を行う方法
リストの変更によって、ジョブ・レベルおよびポジションのリスト・ビルダーを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。この機能は、JDeveloperからの構成は必要ありません。各ルール・ディクショナリに、ModificationRulesという名前の事前にシードされたルール・セットがあります。ルール・セットを作成したリストに、ジョブ・レベルおよびポジションのリスト・ビルダーがアサートされる場合のみ、このルール・セットが呼び出されます。最も優先度が高い適用可能なルールのみ適用されます。
ルール・デザイナで、リストの変更を容易にするために、ルール関数がシードされます。これらの関数は次のとおりです。
-
拡張
-
切捨て
これらのルール関数を、次の図に示します。
表32-4および表32-5には、ExtendおよびTruncateのパラメータがリストされています。
表32-4 Extend関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
ifFinalApproverLevel |
最終承認者が存在するレベル以下のレベル。 |
|
extendBy |
最終ジョブ・レベルに追加するレベル数。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
リスト |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
表32-5 Truncate関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
afterLevel |
切り捨てた後のレベル。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
リスト |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
次の図に、リストの変更アクションのサンプルを示します。
32.3.6.4.4 ビジネス・ルール条件の繰返しノード属性を定義する方法
ビジネス・ルールの定義時に、繰返しノードからの属性に基づいてルール条件を指定できます。たとえば、注文書のシナリオで、各注文書ヘッダーに複数の行アイテムが存在するとします。この場合、PurchaseOrderHeaderが非繰返しノードで、PurchaseOrderLinesが繰返しノードです。
ルールを次のように定義します。
行アイテムの金額が50000より小さい場合、jcooperを2レベルまで含むスーパーバイザ・リストを作成します。
この場合、金額は行の属性、つまり繰返しノードの属性です。
次の手順を使用して、繰返しノード属性を定義します。
- 「ベース・ディクショナリ」で、「ファクト」を選択します。
Humantask1RulesBaseルール・タブで、次のようにファクトのリストが表示されます。
- 次の図に示すように、それぞれの適切なファクトを編集して、表示されることを確認します。
- 一般的なルール、デシジョン表、動詞ルールのいずれを追加するのかを決定します。決定したら、「追加」(+)ボタンをクリックします。ルール・デザイナで、ルールを選択し、「追加」アイコン(+)をクリックします。
次のルール定義セクションが表示されます。
- 次の図に示すように、ルール名の左側にある二重下向き矢印をクリックして、詳細設定を表示します。
- 次の図に示すように、「ツリー・モード」を選択し、「<ファクト・タイプ>」を選択してオプションのリストを表示し、そこから「ROOT」を選択します。
32.3.6.5 割当てコンテキストを使用する方法
割当てコンテキストはタスクに存在する情報です。タスクのライフ・サイクルの間に、割当てコンテキストは様々な割当て先を介して進みます。タスク割当て先のコンテキストが変更されると、割当てコンテキストの値も変更されます。
タスクの履歴を参照すると、ライフ・サイクルの間にタスクに含まれた様々な割当てコンテキストを表示できます。Oracle BPM Worklistは、タスク履歴を表示する際に割当てコンテキストを使用します。
32.3.6.5.1 割当てコンテキストの構成
次のいずれかの方法で、JDeveloperの「参加者タイプの追加」ダイアログまたは「参加者タイプの編集」ダイアログ・ボックスで、割当てコンテキストを構成します。
-
「参加者タイプ」セクションで、「ルールベース」オプションを選択します。
この場合、割当てコンテキストは見えないところで暗黙的に構成されます。ルール・レイヤーは、ルールに基づいて割当て先のリストを解決します。タスクが様々な割当て先を介して進んでいくと、割当てコンテキストの値はルールに基づいて計算されます。
割当てコンテキストは、値ベースのコンテキストでも割り当てることができます。詳細は、「タスク参加者の割当て」を参照してください。
-
「詳細」フィンガー・タブを選択して、任意の数の割当てコンテキストを構成します。
この場合、「割当てコンテキスト」フィールドに情報を入力して、割当てコンテキストをカスタマイズできます。次の図にフィールドを示します。
表32-6はフィールドの説明です。
表32-6 割当てコンテキストのフィールドの説明
フィールド 説明 名前
割当てコンテキストの名前。どの名前でも指定できます。これは文字列フィールドです。
値
割当てコンテキストの値。どの値でも指定できます。これは文字列フィールドです。
タイプ
「値」値フィールドに関連付けられています。
可能な値は次のとおりです。
-
名前別 - ユーザー指定の値パラメータ。
-
式別 - 式ビルダーによって作成された値パラメータ。
-
32.3.6.6 タスク承認を集計する方法
タスクのライフ・サイクルの間に、1つのユーザーにタスクを複数回割り当てることができます。ヒューマン・タスク・エディタを使用すると、ユーザーがタスクを確認する頻度を構成できます。
次の手順では、タスク承認の集計を構成する方法を説明します。
- 上部にある「構成」をクリックします。
次のように「タスク・プロパティ」ウィンドウが表示されます。
タスクが集計され、ユーザーに割り当てられると、タスクは、Oracle BPM Worklist内に、ユーザーが承認しているタスクのすべてのコレクションを表示するコレクション表を持っています。ユーザーがアクションを実行すると、ステージまたはタスク内で、アクションは記録され、すべてのユーザーの割当てに再実行されます。
集計されたタスクは、すべての標準割当てのプロキシ・タスクです。
集計済タスクはビジネス・タスクであり、承認および却下アクションが表示されます。FYIタスクを集計できる場合は、FYIタスクには承認および却下アクションが表示されます。この場合、承認および却下アクションは確認として扱われます。
ノート:
集計は、割当て先が同じセットに属する場合にのみ使用できます。たとえば、あるタスクをユーザーAに割り当てて、もう1つのタスクをユーザーAとユーザーBの両方に割り当てた場合、ユーザーAには2つの独立したタスクが表示されます。割当て先がまったく同じではないため、この2つの割当ては、集計されません。
32.3.7 エスカレーションおよび更新ポリシーの定義
この機能はAMXに固有ではありません。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のタスクのエスカレート、期限更新または終了に関する項を参照してください。
ノート:
エスカレーションは、管理チェーンにのみ適用可能です。
32.3.8 通知設定の指定
この機能はAMXに固有ではありません。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の参加者の通知プリファレンスの指定に関する項を参照してください。
32.3.9 詳細設定の使用
詳細設定の使用には、次のタスクがあります。
-
ノート、添付および検証のコールバックの指定
-
セキュリティ・アクセス・ルールの定義
32.3.9.1 ノート、添付および検証のコールバックを追加する方法
コールバックは、次を実行できるメカニズムです。
-
外部のコンテンツ管理システムまたはカスタム・スキーマからの、ビジネス・オブジェクトに関連付けられたノートおよび添付へのアクセス
-
各タスク・アクションの検証ロジックの定義による、タスクのライフ・サイクルの様々な時点での、ワークフロー・タスクのカスタム検証の実行。
次の手順を使用して、コールバックを追加します。
- タスク・エディタから、「4」フィンガー・タブを選択し、コールバックを構成します。
次のように「コールバック詳細」ダイアログ・ボックスが開きます。
32.3.9.2 セキュリティ・アクセス・ルールを定義する方法
アクセス・ルールは、デフォルトのアクションおよび権限をオーバーライドすることによって、ユーザーが実行できるアクションを制限します。ランタイムに、システムでは、承認、追加、削除などの変更を加える権限がユーザーにあるかどうかを確認する定義済のアクセス・ルールに対して、タスク内のすべての操作をチェックします。ユーザーに変更を加える権限がない場合、適切なエラー・メッセージとともに、操作エラーが出力されます。
AMXでは、グループおよびアプリケーション・ロールにアクセス・ルールを定義できます。たとえば、Operatorsというグループに対して取消アクションを制限するように、アクセス・ルールを定義する場合、このグループに属するすべてのユーザーは、タスクの取消が許可されません。同様に、SOAAuditViewerというアプリケーション・ロールに対して取消アクションを制限するように、アクセス・ルールを定義する場合、SOAAuditViewerアプリケーション・ロールが付与されているすべてのユーザーは、タスクの取消が許可されません。
セキュリティ・アクセス・ルールを定義するには:
- 「表示の構成」をクリックします。
次の図に示すように、「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
アプリケーション・グループのアクセス・ルールを定義するには、次の例外を適用して、同じ手順を使用します。
-
「タスク・アクション」タブをクリックして選択します。
-
ドロップダウン・リストから、「アプリケーション」を選択します。
-
次の図に示すように、「アプリケーション・ロールの選択」ダイアログ・ボックスからアクセス・ルールに含めるアプリケーション・ロールを選択します。
詳細は、「タスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定」の図29-61を参照してください。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のタスク・コンテンツへのアクセス・ポリシーとタスク・アクションの指定に関する項を参照してください。
32.4 エンドツーエンドの承認管理サンプルの使用
エンドツーエンドの承認管理のサンプルを使用できます。
表32-7は、ORACLE_HOME\samples\soa-infra\workflow\amxディレクトリにある、エンドツーエンドのワークフローの例を示しています。
表にリストされたデモンストレーション機能以外に、すべてのサンプルは、ワークリスト・アプリケーションおよびワークフロー通知の使用を示しています。
表32-7 エンドツーエンドのサンプル
| サンプル | 説明 | 場所 |
|---|---|---|
|
経費ライン承認 |
承認ポリシーが定義されたライン・レベルの承認を示します。 |
|
|
従業員雇用 |
Order投票制度の承認グループ・リスト・ビルダーおよびスーパーバイザ・リスト・ビルダーの2つのステージを持つ承認の、非定型の挿入機能を示します。 |
|
|
注文書承認 |
ヘッダーおよびライン・レベルの承認を持つ注文書承認シナリオを示します。 |
|
|
従業員異動 |
パラレルなジョブ・レベルの参加者の間の、あるチームから別のチームへの従業員異動シナリオを示します。 |
|
|
自動承認 |
自動アクション・ルールを介した自動承認の実装方法を示します。 |
|
|
ポジション・リスト・ビルダー |
ポジション・リスト・ビルダーの使用を示します。 |
|
32.5 ユーザー・メタデータ移行ユーティリティの使用
ユーザー・メタデータ移行ユーティリティhwfMigratorは、シェル・スクリプトを実行してSOAサーバー間でワークフローのユーザー構成可能データを移行するプロセスを自動化します。
ユーザー・メタデータ移行ユーティリティの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のテストから本番環境へのヒューマン・ワークフロー・データの移動に関する項を参照してください。