| Oracle® Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド 11g リリース1 (11.1.1.7) B61409-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド 11g リリース1 (11.1.1.7) B61409-09 |
|
前 |
次 |
この章では、Oracle SOA Suiteのヒューマン・ワークフロー・サービスで使用可能な承認管理の拡張機能について説明します。ヒューマン・ワークフロー・サービスの役割は、ビジネス・プロセスに参加しているユーザーまたはグループのすべての相互作用を処理することです。これを行うために、組織内で該当するユーザーのタスクを作成および追跡します。ユーザーは通常、Oracle BPM Worklist、電子メール、ポータル、カスタム・アプリケーションなどの各種クライアントを通じてタスクにアクセスします。承認管理の拡張機能では、ビジネス・ドキュメントおよび関連するルールを考慮して作業アイテムの承認階層を決定することで、ヒューマン・ワークフローのための複雑なタスク・ルーティング・スリップを定義できます。さらに、承認管理の拡張機能では、スーパーバイザまたはポジション階層に基づいて関連付けられたリスト・ビルダーを使用して、複数ステージの承認を定義できます。Oracle JDeveloperのヒューマン・タスク・エディタで承認タスクを定義し、そのタスクをBPELプロセスに関連付けます。
ヒューマン・タスクの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の次の章および付録を参照してください。
「ヒューマン・タスクの設計」
「ヒューマン・タスク・サービスの理解」
この章の内容は次のとおりです。
承認管理の拡張機能では、複雑な承認パターンでヒューマン・ワークフロー・サービスを拡張します。これは、ヒューマン・ワークフローの高度な割当てマネージャとして機能します。提供されている主なワークフロー機能は、次のとおりです。
承認管理プロセスの宣言モデリング
静的および動的な承認リストを使用して、複雑な複数ステージの承認を定義する機能
タスク・パラメータ、割当てとルーティングのポリシー、エスカレーションと有効期限の設定、および通知設定を定義するワークフロー・エディタ
ポリシー・ベースのタスク割当て。これにより、ユーザーはビジネス・ドキュメントに基づいて承認ルールを定義できます。
承認タスクおよび関連付けられたタスクの操作のコンテンツをレンダリングするためのタスク・フォームを設計する機能
ワークフロー内の様々な参加者の電子メール、ボイスおよびインスタント・メッセージの通知を定義する機能
タスク割当て先、プロセス所有者および管理者の、Webベースのワークリスト・アプリケーション
Oracle Internet Directory、LDAPおよびサード・パーティのディレクトリなどの様々なユーザー・ディレクトリで、ユーザーおよびロールを検索する機能
AMXは、次の追加機能を提供します。
トランザクション・アプリケーションのADFビュー・オブジェクトから導出された属性
階層プロバイダ・プラグインを使用して、HRシステムから様々なジョブ、ポジションおよびスーパーバイザ階層を取得する機能
承認リストおよび階層の構成を制御するルールを定義する機能
図30-1は、主要なAMXとヒューマン・タスクの統合コンポーネントを示しています。これらのコンポーネントは、この章の後述の項で説明します。
ヒューマン・ワークフロー・サービスによって、ユーザーは、ビジネス・プロセスの一部として、ユーザーの相互作用をモデリングできます。ヒューマン・ワークフロー・サービスは、タスクおよびルールのメタデータに基づいてリクエストを処理します。これは、次の一連のコア・サービスで構成されています。
タスク・サービス
タスク問合せサービス
ユーザー・メタデータ・サービス
タスク・メタデータ・サービス
アイデンティティ・サービス
通知サービス
割当てマネージャ
これらのサービスは、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスク用のタスク表示フォームの設計」で詳しく説明しています。AMXは、ビジネス・ルールに基づく複雑な承認パターンのモデリングを可能にし、ヒューマン・ワークフロー内の高度な割当てマネージャとして機能します。
承認管理に必要なコア・コンポーネントは、次のとおりです。
JDeveloperのヒューマン・タスク・エディタ
このタスク・エディタは、ヒューマン・タスクおよびルーティング・スリップのメタデータの定義に使用されます。タスク・エディタを使用すると、このようなメタデータを、タスク・パラメータ、結果、有効期限とエスカレーション、および通知の設定として定義できます。AMXによって追加された一部のコンポーネントには、次を実行するための機能が含まれています。
JDeveloperで、複数ステージの承認および関連付けられた承認リスト・ビルダーを定義します。
ビジネス・ドキュメント(ADFオブジェクト)およびビジネス・ルールに基づいて、承認階層を決定します。これは、JDeveloperのルール・デザイナを介して行います。
ヒューマン・ワークフロー・サービス
複雑な承認を処理するのに必要な主なサービスは、次のとおりです。
タスク・サービス - デハイドレーション・ストア内でタスクを作成および管理する役割
アイデンティティ・サービス - ユーザーおよびグループの認証および認可の役割。このサービスでは、ユーザーの認可および連絡先情報用の様々なユーザー・ディレクトリを検索できます。
タスク問合せサービス - Webベースのワークリスト・アプリケーションのタスクを取得する役割
デシジョン・サービス - 承認に関連するビジネス・ルールを実行する役割
Oracle BPM Worklist
Oracle BPM Worklistは、ユーザーに割り当てられたタスクにアクセスして、承認プロセス内のロールに基づくアクションを実行できるWebベースのアプリケーションです。Oracle BPM Worklistは、次のプロファイルをサポートしています。
作業割当て先 - タスクを割り当てられるエンド・ユーザー。これらのユーザーは、割り当てられたタスクを表示し、アクションを実行できます。また、カスタム・ビューを定義し、タスクのルーティング・ルールを定義することもできます。
プロセス所有者 - 通常、承認の特定のタイプを管理する責任があるビジネス・アナリスト。これらのユーザーは、所有するプロセスのタスクを管理し、承認グループを定義し、承認ポリシーを変更できます。
ワークフロー管理者 - 通常、エラー発生タスクを管理し、作業キューを管理および監視する責任があるシステム管理者。このユーザーは、Oracle Enterprise Managerを使用して、ワークフロー・サービスのヘルス状態を監視することもできます。
前述のとおり、AMXは、複雑な承認パターンを処理する追加機能を使用して、ヒューマン・ワークフロー・サービスを拡張します。
理解している必要があるヒューマン・ワークフローの概念は、次のとおりです。
JDeveloperのヒューマン・タスク・エディタ
タスク・メタデータ(タスク・パラメータ、使用可能な操作およびパターン)およびルーティング・スリップ
タスク・フォームに基づくADFタスク・フロー
Oracle BPM Worklist
これらの概念は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の次の章で説明しています。
「ヒューマン・タスクの設計」
「ヒューマン・タスク用のタスク表示フォームの設計」
「Oracle BPM Worklistアプリケーションの使用」
後述の項では、複雑な承認を処理するために導入された新しい概念について説明します。
タスクは承認を処理します。要件によって提供されるビジネスに基づいて、各承認要件に対して異なるタスクが作成されます。たとえば、新規経費精算書の承認タスクや、新規注文書の承認タスクなどです。
タスクの標準的なメタデータは次のとおりです。
タイトル、結果(承認、却下など)の優先度、有効期限などのタスク属性
シンプルなプリミティブ・タイプ、XML要素またはADFビュー・オブジェクトなどの外部エンティティに基づくタスク・パラメータ
承認シーケンス内の主なマイルストンを識別する1つ以上のステージを含む複雑な承認タスク。詳細は、30.2.3項「ステージ」を参照してください。
有効期限とエスカレーションのポリシー
様々な参加者に通知するための通知設定
ステージ内のリスト・ビルダー。これは、名前と式、管理チェーン、スーパーバイザ、ポジション、ジョブ・レベルの階層、または承認グループに基づいています。詳細は、30.2.4項「リスト・ビルダー」を参照してください。
承認者の置換および変更のポリシー、自動承認の構成、および繰り返された承認者などの承認タスク構成。詳細は、30.2.1項「タスク」を参照してください。
図30-2は、サンプルの承認パターンでの様々なステージを示しています。
これらは、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』で詳細を説明しています。
承認パターンは、次の4つのステージで構成されています。
ヘッダー承認
ライン承認
レシート検証
支払
ヘッダー承認は、ライン承認およびレシート検証と並行して実行されます。これらのステージの実行後に、支払ステージが実行されます。
4つの各ステージに、リスト・ビルダーがあります。ステージ内の複数のリスト・ビルダーを、相互にシリアルまたはパラレルで実行できます。各リスト・ビルダー内に1つ以上の承認者を設定できます。図30-3は、これらの概念を示しています。
これらの概念は、後述の項で説明しています。
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 Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュールを使用したビジネス・サービスの実装に関する項およびサービス対応のアプリケーション・モジュールの統合に関する項を参照してください。
ステージは、コレクションに関連する一連の承認です。複数の承認ステージに同じコレクションを関連付けることができます。
図30-4は、ステージおよびコレクションのマッピングを示しています。
各承認ステージは、コレクションに関連付けられます。図30-4では、承認に4つのステージがあります。
ヘッダー承認は、経費ヘッダーのコレクションに関連付けられます。
レシート検証は、経費ヘッダーのコレクションに関連付けられます。
支払は、経費ヘッダーのコレクションに関連付けられます。
ライン承認は、経費ラインのコレクションに関連付けられます。
複合承認は、複数のステージで構成され、相互にシリアルまたはパラレルでモデリングできます。各ステージは、承認者のリストを決定するリスト・ビルダーで構成されます。
オプションで、各リスト・ビルダーを承認ポリシー、つまりルールのセットに関連付けることができます。ランタイムに、ステージ内で使用されたリスト・ビルダーおよび関連付けられたポリシーに基づいて、適切な承認のセットが戻されます。
30.2.3項で説明しているように、各承認ステージは、承認者の実際のリストを決定するリスト・ビルダーで構成されます。次のリスト・ビルダーがサポートされています。
名前と式
静的な名前またはXPath式から取得された名前を使用して、リストを作成できます。
承認グループ
事前定義された承認者グループを、承認者リストに含めます。承認グループは、静的にも動的にもなります。
ジョブ・レベル
スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
ポジション
ポジション階層内を上行します。指定された承認者のポジションから開始し、十分なジョブ・レベルを持つポジションが見つかるまで続行します。
スーパーバイザ
プライマリ・スーパーバイザ階層内を上行します。リクエスタまたは指定された承認者から開始し、固定承認者数を持つチェーンを生成します。
管理チェーン
対応するユーザー・ディレクトリ内の管理関係に基づいて、リストを作成できます。
管理チェーン最初の割当て先が単一ユーザーの場合、管理チェーン参加者タイプでサポートされるのはパラレル・ルーティングのみです。管理チェーンの最初の割当て先として、一連のユーザーまたはグループなどのパラレル参加者を指定することはできません。
ルールベース
様々な条件に基づいて様々なリスト・ビルダー・タイプを戻すルールをモデリングできます。たとえば、ルールを持つスーパーバイザ・リスト・ビルダーをモデリングする場合、ルールは、スーパーバイザ・リスト・ビルダーのみを戻すことができます。ルール・ベースのリスト・ビルダーをモデリングする場合、ルールは、様々なリスト・ビルダー・タイプを戻すことができます。
|
注意: 承認グループ、ジョブ・レベル、ポジションおよびスーパーバイザ・リスト・ビルダーはAMXに固有で、30.3.6.3項「リスト・ビルダーをモデリングおよび構成する方法」に詳細が説明されています。 名前と式、管理チェーンおよびルールベースのリスト・ビルダーの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク参加者の割当て方法に関する項の、単一のタスク参加者リストの作成に関する項を参照してください。 |
標準的なヒューマン・タスク操作の大部分も、AMXベースのタスクで使用できます。共通の操作は、次のとおりです。
ユーザー定義の結果 - 承認および却下などの、タスクに関連付けられたビジネスの結果。ユーザーがこれらのタイプのアクションを実行すると、タスクはユーザーの受信ボックスから削除され、完了済とマークされるか、次の承認者に移動します。
委任 - ユーザーは、別のユーザーまたはロールに、自分の代理として処理するようにタスクを割り当てることができます。
エスカレート - ユーザーまたは管理者は、ユーザーのスーパーバイザに、タスクをエスカレートできます。
再割当て - ユーザーは、別のユーザーにタスクを転送できます。その時点から、新しいユーザーの階層が、スーパーバイザまたは他の組織ベースの承認に使用されます。
取消 - タスク・イニシエータまたは管理者は、承認の開始後にタスクをキャンセルまたは取消できます。
情報のリクエスト - タスク承認者は、前の参加者またはタスク・イニシエータから情報をリクエストできます。
プッシュバック - タスク承認者は、前の承認者に、再確認するようにタスクをプッシュ・バックできます。
非定型挿入 - タスク割当て先は、生成された承認リストに承認者を挿入できます。
|
注意: ポジション・リスト・ビルダーでは、承認者が委任、エスカレートまたは非定型挿入の実行を行うことはできません。 |
アクションの完全なリストについては、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「Oracle BPM Worklistアプリケーションの使用」の、タスクの処理: タスクの詳細ページに関する説明を参照してください。
タスク定義のインラインで、またはタスクの実際の承認者を識別するリスト・ビルダーを指定するビジネス・ルールを使用して、タスクの承認者を定義できます。さらに、ビジネス・ルールを使用して、承認者の置換およびリストの変更を指定できます。これらのルールは、Oracle Business Rulesのヘルプを使用して定義され、組織間で変えることができます。ただし、通常、これらは顧客によって定義されます。
ビジネス・ルールは、条件とアクションの組合せです。オプションで、ビジネス・ルールに優先度および有効期間を定義できます。ヒューマン・ワークフロー・ルールでは、タスク、タスク・メッセージおよび(SDOオブジェクトのXML表現である)エンティティ属性に対応するファクト・タイプを使用して、ルール条件が定義されます。ルール・アクションは、承認者リスト・ビルダーおよびそのパラメータで構成されます。承認者リスト・ビルダーは、特定の階層に移動し、定義されたパラメータに応じて承認者リストを作成または変更します。承認者リスト・ビルダーは、XML (JAXB)ファクト・タイプとして実装されます。
これらの概念の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「Oracle Business Rulesの概要」を参照してください。
リスト作成ポリシーには、リスト・ビルダーを作成するルール条件およびアクションが含まれます。
次のルールの例は、SDOベースのファクト・タイプに基づく承認者リストを作成する、スーパーバイザ・リスト・ビルダー・パラメータの構成を示しています。
例30-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)
例30-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)
詳細は、30.3.6.4.1項「リストを作成する方法」を参照してください。
リスト置換を使用して、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。
次のルールの例は、承認者の置換の使用方法を示しています。
例30-3 承認者の置換の使用方法
IF ExpenseItems.ReceiptAmount < new BigDecimal(4000) THEN call Substitute(fromId:"jcooper", toId:"jstein", ruleName:"Substituted", substitutionRules: SubstitutionRules)
このルールは、経費項目の金額が4000より小さい場合、承認者jcooperを承認者jstein(承認者リストに存在する場合)に置換することを示しています。
詳細は、30.3.6.4.2項「承認者の置換を行う方法」を参照してください。
ジョブ・レベルおよびポジションのリストを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。
次のルールの例は、リストの変更の使用方法を示しています。
例30-4 リストの変更の使用方法
IF ExpenseItems.ReceiptAmount > new BigDecimal(3000) THEN Call Extend(ifFinalApproverLevel:3, extendBy:2,ruleName:"Modified",lists:Lists)
このルールは、経費項目の金額が3000より大きい場合、および承認者リストの最終承認者がジョブ・レベル3の場合、承認者リストを少なくとも相対的に2レベルまで拡張することを示しています。
詳細は、30.3.6.4.3項「リストを変更する方法」を参照してください。
複数ステージの承認をモデリングする機能を提供するヒューマン・タスクを定義することで、承認管理タスクを設計し、ビジネス・オブジェクトおよび関連付けられたHR階層プロバイダの承認ポリシーに基づいて、適切な承認者を決定します。
この項では、JDeveloperで承認管理タスクをモデリングするのに使用する、モデリング・プロセス全体およびプロセスの詳細について説明します。
承認管理タスクを設計するためのモデリング・プロセスは、次のとおりです。
ヒューマン・タスク定義の作成
ヒューマン・タスク・エディタを使用したタスク表示フォームの作成
ヒューマン・タスク定義の作成には、次のタスクがあります。
タスク・タイトルとタスク・タイトル・グローバリゼーション、結果、優先度、所有者およびカテゴリなどの、一般的な情報の指定
サービス・データ・オブジェクト(SDO)参照を持つパラメータなどの、タスク・パラメータの定義
マップ済属性の指定
ステージおよびリスト・ビルダーの指定によるタスク・ルーティングのモデリング、およびリスト・ビルダーを定義するビジネス・ルールのモデリング
エスカレーションおよび更新ポリシーの定義
通知設定の指定
コールバック、セキュリティ・アクセス・ルールおよび制限付き割当てなどの詳細設定のモデリング
これらの手順の一部は、後述の項で説明しています。そこで説明されていない手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項を参照してください。
承認の詳細を表示するADFタスク・フローを使用して、タスク表示を作成する必要もあります。ADFタスク・フローは、「タスクの詳細」ページのユーザー・インタフェースをモデリングするために使用されます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスク用のタスク表示フォームの設計」を参照してください。
承認管理タスクを設計する前に、次の前提条件を満たしている必要があります。
SDOサービスをデプロイしている必要があります。
承認タスクを設計するヒューマン・タスク・サービス・コンポーネントを作成している必要があります。
タスク・タイトル、結果、優先度、所有者およびカテゴリなどの一般的な情報は、AMXに固有ではありません。
これらの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク・タイトル、優先度、結果および所有者の指定方法に関する項を参照してください。
タスク・オブジェクトのタイトル属性には、大部分は本質的にわかりやすい、ユーザーフレンドリな値が含まれています。AMXでは、ユーザーの優先言語でレンダリングするように、タスク・タイトルをグローバル化できます。
タイトルは、デザインタイム用に*.taskファイルで、ランタイム用にWorkflowTask.xsdファイルで定義されます。現在、これらのファイルの両方の要素の定義は、シンプルなxsd(文字列タイプ)です。翻訳可能でフォーマットされた文字列を提供するメカニズムに対応するために、グローバリゼーション用にこれらの要素の構造および使用方法を変更します。
これらの要素のデザインタイムのメタデータは、値要素および一連のオプション・パラメータを含めるように拡張されます。XPath式または静的として定義されたメッセージは、値要素に格納された情報を持ち、パラメータは必要ありません。リソース・バンドル内の情報に依存している定義済のメッセージには、定義されたパラメータを持つ値要素に格納されたキーがあります。
ヒューマン・タスク・エディタは、式ビルダーでのメカニズムを提供し、ユーザーはリソース・キーおよびパラメータを指定できます。同時に、taskDefinitionで、適切なデザインタイムのXMLを生成します。
図30-5は、ヒューマン・タスク・エディタのグローバリゼーション・アイコンを示しています。
次の手順は、翻訳可能な文字列の追加方法を説明しています。これは、リソース・バンドルが指定されていることを前提としています。
アイコンをクリックして、「翻訳可能文字列の編集」ダイアログを表示します。
ドロップダウン・リストからキーを選択するか、プラス記号(+)をクリックしてキーを作成します。
図30-6は、「新規キーの作成」ダイアログを示しています。これは、「翻訳可能文字列の編集」ダイアログのプラス記号(+)をクリックすると表示されます。
名前、翻訳可能なテキストを入力し、「OK」をクリックします。
図30-7は、新規キーが追加された後の「翻訳可能文字列の編集」ダイアログを示しています。
式ビルダーを使用して、値を追加します。
図30-8は、完了した「翻訳可能文字列の編集」ダイアログを示しています。
|
注意: タイトル値、またはタイトル値の定義は、TaskDefinition XML( |
「OK」をクリックして、ダイアログを閉じます。
タスク・パラメータの指定には、次のタスクがあります。
SDO参照の作成
エンティティ・パラメータの定義
コレクションの定義
SDOサービスは、ワークフロー・サービスから起動して、XMLとしてSDOを取得できます。この起動は、SOA Webサービス・コールのフォームにあります。SDOサービスのWSDL URLが使用可能な場合、「Webサービスの作成」ダイアログを使用して、Webサービス参照を追加する必要があります。
参照を作成するには、図30-9に示すように、WSDL URLを入力し、使用可能なポート・タイプからポート・タイプを選択します。
SDOの作成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、SOAコンポジット・エディタの概要に関する項の、参照の概要に関する項を参照してください。
次の手順によって、サービス・データ・オブジェクト(SDO)を受け入れることができます。
コンポジット内のサービス参照を作成します。
これにより、ファブリックは、WSDLを指す特定のURLへの必要なすべてのワイヤリングを作成できます。
タスク・ペイロードを外部として定義し、どのワークフローがSDOオブジェクトを取得するかを指定します。
これにより、SDO Webサービスへの入出力を表すタスク・パラメータが作成されます。
「エンティティ」を選択します。
図30-10に示すように、コレクション、そのXPATH式およびそのキーを定義します。
ステージのコレクションを設定します。
「OK」をクリックします。
次の手順によって、静的XMLを受け入れることができます。
スキーマを定義するXSDを指定します。
タスク・ペイロード・パラメータを静的XMLとして定義します。
コレクション、そのXPATH式およびそのキーを定義します。
ステージのコレクションを設定します。
「OK」をクリックします。
コレクションは、タスク・メッセージ属性の特定の部分である静的XMLベースおよびエンティティの両方の属性への参照です。コレクションを定義すると、コレクションをステージに関連付けて、コレクションの処理時にステージを識別できます。
コレクションの定義には、コレクション名の定義およびコレクション要素へのXPathの定義があります。コレクションをエンティティ属性に定義する場合、コレクション要素のキーも指定する必要があります。各キーはコレクション要素の直接の子である必要があります。図30-11は、コレクションの定義方法を示しています。
コレクションを定義すると、JDeveloperによって、コレクションが繰返し要素であるかどうかが自動的に決定されます。この情報は、コレクションをステージに関連付けるときに使用されます。非繰返しコレクションは、単一のステージに関連付けることができます。繰返しコレクションは、ステージに関連付ける場合、ランタイムにコレクション内の各要素のステージをパラレルで繰り返します。コレクション情報のステージでの使用方法の詳細は、30.3.6.1項「ステージをモデリングおよび構成する方法」を参照してください。
ヒューマン・ワークフローは、タスクのペイロードから抽出されたデータなど、ユースケース固有のデータを格納するのに使用できるタスク・メッセージ属性を提供します。これらの属性は、フレックスフィールド属性またはマップ済フレックスフィールド属性とも呼ばれます。
マップ済フレックスフィールド属性を使用すると、ペイロード値を、タスク詳細で非表示にするのではなく、タスク・リスト内の列として表示できます。これらの値は、ヒューマン・ワークフロー・データベース・スキーマに格納され、問合せ、ビュー定義および割当てルール定義で使用できます。
メッセージ属性には次の2つのタイプがあります。
パブリック - ランタイムに特定のタスク・コンポーネントにマップされる属性。これらのマッピングはいつでも変更でき、タスク・コンポーネントの再デプロイ時に再作成する必要があります。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の次の項を参照してください。
「Oracle BPM Worklistの使用」の、フレックス・フィールドのマップ方法に関する項
「ヒューマン・ワークフローの概要」の、フレックス・フィールドの概要に関する項
保護 - デザインタイムに定義されたタスク・コンポーネントと保護済のフレックスフィールド属性間のAMX固有のマッピング。これらはランタイムに変更できず、タスク・コンポーネントとともにデプロイされます。
表30-1には、60個の使用可能な保護済のフレックスフィールド属性がまとめられています。
表30-1 保護済のフレックスフィールド属性
| 名前 | 説明 |
|---|---|
|
ProtectedTextAttribute1からProtectedTextAttribute20 |
テキスト・データを2000文字まで格納します。タスク問合せサービスを介したOracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容がチェックされます。 |
|
ProtectedFormAttribute1からProtectedFormAttribute10 |
テキスト・データを2000文字まで格納します。Oracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容はチェックされません。 |
|
ProtectedURLAttribute1からProtectedURLAttribute10 |
テキスト・データを200文字まで格納します。Oracle BPM Worklistでのキーワード検索中に、これらのフィールドの内容はチェックされません。 |
|
ProtectedDateAttribute1からProtectedDateAttribute10 |
日付情報を格納します。 |
|
ProtectedNumberAttribute1からProtectedNumberAttribute10 |
数値情報を格納します。 |
属性ラベルは、意味のある文字列を、特定のフレックスフィールド属性に適用できるユーザー定義のプロパティです。ラベルは、属性に格納するデータを反映する必要があります。たとえば、CustomerNameをProtectedTextAttribute1に、OrderNumberをProtectedNumberAttribute2に、OrderDateをProtectedDateAttribute1にします。
フレックスフィールド属性は、属性に定義された複数の属性ラベルを持つことができます。たとえば、属性ProtectedTextAttribute1は、ラベルCusomerName、PartIdおよびEmployeeDepartmentを持つことがあります。
保護済の属性の属性ラベル・マッピングは、デザインタイムにヒューマン・タスク・エディタで定義されます。これらは、特定のタスク・コンポーネントと属性ラベル間のマッピングを定義し、属性の値を移入する方法を指定します。同じ属性ラベルを複数のマッピングで再利用できます。これにより、タスク・コンポーネントは、同じセマンティックな意味を持つデータを、共通のラベルで識別される共通の属性にマップできます。
たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクすべてがCustomerNameラベルへのマッピングを定義するとします。複数のタスク・コンポーネントで同じ属性ラベルを共有することによって、複数のタスク・タイプを問い合せ、共通の属性ラベルから値を表示またはフィルタ処理するワークリスト問合せを作成できます。たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクを選択し、ワークリストのタスク・リスト内の列としてCustomerNameを表示する問合せを作成できます。
図30-12に示すように、ヒューマン・タスク・エディタの「マップ済属性」セクションで、属性ラベル・マッピングを定義します。
次の手順を使用して、属性ラベル・マッピングを定義します。
「追加」アイコンをクリックして、図30-13に示す「マップ済属性の追加」ダイアログを表示します。
次のいずれかのオプションを実行します。
ドロップダウン・リストから、保護済の属性ラベルを含むアプリケーション・サーバーを選択します。
「追加」アイコンをクリックして、接続を作成します。
「編集」アイコンをクリックして、既存の接続を編集します。
「属性」ドロップダウン・リストを使用して、指定したサーバーから使用可能な属性ラベルを移入します。
ドロップダウン・リストから、属性を選択します。
|
注意: このリストには、このタスク・コンポーネントがマップされているフレックスフィールド属性のラベルは含まれていません。 |
「値」フィールドで、次の方法のいずれかを使用して値を指定します。
属性に格納する値を決定するXPath式を入力します。
アイコンをクリックして、式ビルダーで値を作成します。
フィールドを空白にして、ランタイムに値を決定できます。
通常、このXPath式は、タスクのペイロードから値を選択しますが、単純型(文字列、日付、数値など)と評価される有効な式を指定できます。
XPath式の指定は必須ではないことに注意してください。基礎となるフレックスフィールド属性の値を自分で設定するように選択できます。たとえば、タスクを開始するBPELプロセスにカスタム割当てアクティビティを追加したり、ワークフロー・サービスAPIを介してタスク・オブジェクトを操作できます。
説明を入力します。これはオプションです。
「OK」をクリックします。
ルーティングおよび承認ポリシーの指定には、次のタスクがあります。
ステージのモデリングおよび構成
タスク参加者のモデリング
リスト・ビルダーのモデリングおよび構成
ビジネス・ルールの定義
ビジネス・ルールを使用したリスト・ビルダーの指定
割当てコンテキスト情報の使用
タスク承認の集計
機能のニーズに基づいて、順次ステージおよびパラレル・ステージの組合せとなる構造に、複数のステージを追加および配置できます。この項では、順次ステージおよびパラレル・ステージの作成方法について説明します。
次の手順を使用して、ステージを作成します。
ヒューマン・タスク・エディタの「割当ておよびルーティング」セクションで、ステージを選択します。
図30-14に示すように、「追加」アイコンをクリックし、ドロップダウン・リストから「順次ステージ」または「パラレル・ステージ」のいずれかを選択します。
順次ステージを作成するように選択した場合、「割当ておよびルーティング」セクションは、図30-15のようになります。
パラレル・ステージを作成するように選択した場合、「割当ておよびルーティング」セクションは、図30-16のようになります。
作成したステージをダブルクリックするか、ステージを選択して「編集」アイコンをクリックします。
図30-17に示すように、「編集」ダイアログが表示されます。
ステージの名前を入力します。
次のいずれかのオプションを選択します。
繰返しなし - コレクション内の各要素に、1ステージのみが並行して存在することを指定します。
コレクション内の各アイテムのステージを並行して繰り返します。 - ステージを、コレクション内の各要素に対して並行して繰り返すように指定します。たとえば、10行の注文書の場合、ステージは並行して10回繰り返されます。
ドロップダウン・リストからコレクションを選択します。
選択内容に従って、次のいずれかを実行します。
「繰返しなし」を選択した場合、「OK」をクリックして、「編集」ダイアログを閉じます。
「コレクション内の各アイテムのステージを並行して繰り返します。」を選択した場合、図30-18に示すように、追加オプションが表示されます。
次のように実行します。
デフォルトの結果を選択します。
同意パーセントを選択します。
ただちに結果をトリガーするか、または結果をトリガーせずにすべての投票の完了まで待機するかを選択します。
「OK」をクリックして、「編集」ダイアログを閉じます。
各ステージ内で、デフォルトのタスク参加者を編集するか、新規タスク参加者を追加できます。ルーティング・パターンに基づいて、タスク参加者を次のいずれかに割り当てます。
単一
パラレル
シリアル
FYI
参加者タイプおよびタスク参加者のステージへの割当ての詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク参加者の割当て方法に関する項を参照してください。
ルーティング・パターンの選択後に、リスト・ビルダーを選択およびモデリングする必要もあります。このプロセスは、30.3.6.3項「リスト・ビルダーをモデリングおよび構成する方法」で詳細を説明しています。
ステージは、リスト・ビルダーの組合せを使用して、承認リストを生成します。詳細は、30.2.3項「ステージ」および30.2.4項「リスト・ビルダー」を参照してください。それぞれのタイプのリスト・ビルダーは、ステージごとに1回のみ使用できます。順次またはパラレルの順序で、これらの承認者リスト・ビルダーを配置できます。選択した順序は、リスト・ビルダーによって生成された承認者リストに含まれる承認者を承認タスクに割り当てる順序を制御します。
次のリスト・ビルダーはAMXに固有です。
承認グループ
ジョブ・レベル
ポジション
スーパーバイザ
|
注意: その他のリスト・ビルダーのモデリングの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク参加者の割当て方法に関する項の、単一のタスク参加者リストの作成に関する項を参照してください。 |
表30-2は、AMX固有のリスト・ビルダーおよびそれに使用できるオプションを説明しています。
表30-2 リスト・ビルダー・オプション
| オプション名 | 説明 | リスト・ビルダー |
|---|---|---|
|
値ベース |
指定した値に基づいて、参加者のリストを作成するための制限を指定します。 |
ポジション以外のすべて |
|
ルールベース |
ルール・エディタで定義されたルールに基づいて、参加者のリストを作成するための制限を指定します。 |
すべて |
|
名前 |
使用する承認グループの名前 |
承認グループ |
|
空のグループを許可 |
メンバーのない承認グループの使用を許可します。 |
承認グループ |
|
ルールセットのリスト |
参加者のリストを作成するための制限を指定しているルールセットの名前。 |
すべて |
|
開始参加者 |
リスト内の最初の参加者。通常はマネージャです。 |
ジョブ・レベル ポジション スーパーバイザ |
|
最上位の参加者 |
承認での最後の参加者。承認は、階層内でこの参加者より先には進みません。 |
ジョブ・レベル ポジション スーパーバイザ |
|
レベル数 |
スーパーバイザが移動するレベル数、またはジョブ・レベルおよびポジションのジョブ・レベル数を指定する正数。この数には、絶対値、開始点からの相対値、作成者を使用できます。 |
ジョブ・レベル ポジション スーパーバイザ |
|
相対 |
スーパーバイザが移動するレベル数、またはジョブ・レベルおよびポジションのジョブ・レベル数を指定する正数。可能な値は、開始点、作成者および絶対値です。 |
ジョブ・レベル ポジション |
|
最後のレベルの全マネージャを含む |
ジョブ・レベルがリスト内で以前に計算された最後の参加者のレベルと等しい場合は、リスト内の次のマネージャが含まれます。 |
ジョブ・レベル |
|
使用される参加者 |
参加者の計算済リストからこのオプションで指定された参加者のみ使用します。使用可能なオプションは、全員、最初および最後のマネージャ、最後のマネージャです。 |
ジョブ・レベル ポジション |
|
自動アクションの有効化 |
リスト・ビルダーが次のオプションに基づいてタスクを自動的に実行するかどうかを指定します。 |
スーパーバイザ ジョブ・レベル ポジション |
|
自動アクション |
設定される結果を指定します。自動アクションが有効でない場合は、nullにできます。 |
スーパーバイザ ジョブ・レベル ポジション |
階層プロバイダ・プラグインを構成しない場合、ポジション・リスト・ビルダーは機能しません。
階層の拡張を定義する際に、プロパティmustUseSpecifiedProviderを定義しない場合、デフォルト値はtrueです。
階層プラグインに問題がある場合に例外をスローしないようにスーパーバイザおよびジョブ・レベル・リスト・ビルダーを構成できます。リスト・ビルダーを構成するには、workflow-identity-config.xml構成ファイルにmustUseSpecifiedProviderプロパティを追加し、値属性をfalseに設定する必要があります。
デフォルトでは、workflow-identity-config.xmlファイルには、mustUseSpecifiedProviderプロパティが含まれていません。このプロパティが存在し、その値がfalseの場合、階層プラグインに関する問題があると、スーパーバイザおよびジョブ・レベル・リスト・ビルダーはLDAP管理チェーンを使用します。
例30-5に、mustUseSpecifiedProviderプロパティを指定するworkflow-identity-config.xmlファイルを示します。このプロパティの値はtrueに設定されており、階層プラグインが使用可能でない場合に、スーパーバイザおよびジョブ・レベル・ビルダーが失敗するようになっています。
例30-5 workflow-identity-config.xml構成ファイル
<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>
承認グループは、静的に定義された、または動的に生成された承認者のリストです。承認グループは、通常、ワークリスト・アプリケーションを使用して、プロセス所有者によって構成されます。一般に、これらは、管理承認の前後にタスクを処理する必要がある、人事や弁護士などのトランザクションの権限の管理チェーンの外側の主題専門家をモデリングするのに使用されます。
静的な承認グループは事前定義済の承認者リストで、動的な承認グループはランタイムに承認者リストを生成します。動的な承認グループでは、次を実行する必要があります。
開発者による動的承認者リストのインタフェースに応じた実装の提供
IT部門によるOracle BPM WorklistのUIを使用した動的な承認グループとしての前述の実装の登録
SOAクラス・パスの一部であり世界的に有名なディレクトリでの、クラス・ファイルの公開
タスク・ペイロードに基づいて承認グループを動的に計算する必要がある場合は、動的な承認グループを使用します。具体的には、各ラインで異なる承認グループが必要になる可能性があるライン・レベルの承認の場合などです。たとえば、コスト・センターごとに異なるコスト・センター所有者の承認が必要になることがあります。各ラインには、異なるコスト・センター所有者の承認を必要とする異なるコスト・センターがある可能性があります。コスト・センターの総数が100を超える場合は、ビジネス・ルールによる管理が困難になることがあります。
|
注意: ドロップ8では、承認グループはフラット・リストです。シリアルおよびパラレルのパターンは定義されなくなります。 |
図30-19および図30-20は、承認グループ・リスト・ビルダーの2種類の表示を示しています。
承認グループ・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表30-2を参照してください。
|
注意: リソース・リストをグループで構成した場合、構成がシリアル・タイプであるかパラレル・タイプであるかにかかわらず、リソース・リストは単一タイプの参加者として動作します。 |
ジョブ・レベル・リスト・ビルダーは、スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
図30-21および図30-22は、ジョブ・レベル・リスト・ビルダーの2種類の表示を示しています。
ジョブ・レベル・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表30-2を参照してください。
ポジション・リスト・ビルダーは、ポジション階層内を上行します。リクエスタまたは指定された承認者のポジションから開始し、指定したレベル数または特定のポジションまで進みます。
図30-23は、ポジション・リスト・ビルダーの表示を示しています。
ポジション・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表30-2を参照してください。
タスク定義のインラインで、またはタスクの実際の承認者を識別するリスト・ビルダーを指定するビジネス・ルールを使用して、タスクの承認者を定義できます。さらに、ビジネス・ルールを使用して、承認者の置換およびリストの変更を指定できます。これらのルールは、Oracle Business Rulesのヘルプを使用して定義され、組織間で変えることができます。ただし、通常、これらは顧客によって定義されます。
ビジネス・ルールは、条件とアクションの組合せです。オプションで、ビジネス・ルールに優先度および有効期間を定義できます。ヒューマン・ワークフロー・ルールでは、タスク、タスク・メッセージおよび(SDOオブジェクトのXML表現である)エンティティ属性に対応するファクト・タイプを使用して、ルール条件が定義されます。ルール・アクションは、承認者リスト・ビルダーおよびそのパラメータで構成されます。承認者リスト・ビルダーは、特定の階層に移動し、定義されたパラメータに応じて承認者リストを作成または変更します。承認者リスト・ビルダーは、XML (JAXB)ファクト・タイプとして実装されます。
これらの概念の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「Oracle Business Rulesの概要」を参照してください。
後述の項では、Oracle Business Rulesを使用した、リストの作成、承認者の置換、リストの変更および繰返しノード属性について説明します。
ビジネス・ルールを使用して、使用するリスト・ビルダーを定義できます。ビジネス・ルールには2つのタイプがあります。
特定のリスト・ビルダーのパラメータを定義するルール。この場合、特定のリスト・ビルダーを使用するために、タスク・ルーティング・パターン・ダイアログがモデリングされます。リスト・ビルダーのパラメータはルールに基づきます。このオプションを使用して、ルールは、JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを戻す必要があります。図30-26は、サンプルの構成を示しています。
リスト・ビルダーおよびリスト・ビルダー・パラメータを定義するルール。この場合は、リスト自体がルールを使用して作成されます。図30-27は、サンプルの構成を示しています。
ルール・ディクショナリで、リスト・ビルダーの作成を容易にするために、ルール関数がシードされます。これらの関数は次のとおりです。
CreateResourceList
CreateSupervisoryList
CreateManagementChainList
CreateApprovalGroupList
CreateJobLevelList
CreatePositionList
図30-28に示すように、ルール・デザイナで、条件をモデリングし、アクション部分で、上述の関数の1つを呼び出して、リストの作成を完了します。
ルール関数のパラメータは、JDeveloperモデリングでのパラメータに類似しています。JDeveloperでの構成に加えて、ルール・デザイナでは、次の属性の追加のオプションが使用可能です。
startingPointおよびtopApprover - JDeveloperでは、開始点および上位承認者がユーザーとして指定されます。ルール・デザイナでは、HierarchyPrincipalを開始点および上位承認者として作成できます。階層プリンシパルを構築するには、図30-29に示すように、HierarchyBuilder関数を使用します。
|
注意: HierarchyBuilder関数の使用時にジョブ・レベル属性を未定義のままにする場合は、属性の値を負の整数に設定する必要があります。 |
autoActionEnabledおよびautoAction - ルール・デザイナから、特定のリスト・ビルダーによって生じるユーザーがタスクを自動的に処理できるように構成できます。
responseType - レスポンス・タイプがREQUIREDの場合、割当て先はタスクを処理する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。
ruleName - ルール名は、割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。
lists - これは、作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。
図30-30および図30-31は、ルールの例を示しています。
|
注意: 複数のルールが起動する場合、最も優先度が高いルールによって作成されたリスト・ビルダーが選択されます。 ルールが同じ優先度の場合、ランダムな順序で起動し、最初に起動したルールが選択されます。 |
|
警告: リスト作成ルール・セット内のルール定義が不適切または不完全な場合は、実行時エラーの原因になることがあります。次の場合にエラーが発生します。
すべての条件を処理するよう、ルールを正しく定義してください。 |
リスト置換によって、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。各ルール・ディクショナリに、SubstitutionRulesという名前の事前にシードされたルール・セットがあります。ルール・ディクショナリには、リスト置換を構成するためのSubstituteルール関数もシードされています。表30-3には、Substitute関数およびそのパラメータがリストされています。
表30-3 Substitute関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
fromId |
置換元のユーザー/グループ/アプリケーション・ロールのID。 |
|
toId |
置換先のユーザー/グループ/アプリケーション・ロールのID。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
substitutionRules |
すべての置換のホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、SubstitutionRulesオブジェクトが表示されます。 |
|
注意: 置換ルールを使用するヒューマン・タスクでは、結果の承認リストで参加者が重複する可能性があります。「将来の参加者」リストでは、重複した承認者を編集することはできません。 |
図30-32は、承認者の置換アクションのサンプルを示しています。
リストの変更によって、ジョブ・レベルおよびポジションのリスト・ビルダーを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。この機能は、JDeveloperからの構成は必要ありません。各ルール・ディクショナリに、ModificationRulesという名前の事前にシードされたルール・セットがあります。ルール・セットを作成したリストに、ジョブ・レベルおよびポジションのリスト・ビルダーがアサートされる場合のみ、このルール・セットが呼び出されます。最も優先度が高い適用可能なルールのみ適用されます。
ルール・デザイナで、リストの変更を容易にするために、ルール関数がシードされます。これらの関数は次のとおりです。
Extend
Truncate
図30-33は、これらのルール関数を示しています。
表30-4および表30-5には、ExtendおよびTruncateのパラメータがリストされています。
表30-4 Extend関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
ifFinalApproverLevel |
最終承認者が存在するレベル以下のレベル。 |
|
extendBy |
最終ジョブ・レベルに追加するレベル数。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
lists |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
表30-5 Truncate関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
afterLevel |
切り捨てた後のレベル。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
lists |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
図30-34は、リストの変更アクションのサンプルを示しています。
ビジネス・ルールの定義時に、繰返しノードからの属性に基づいてルール条件を指定できます。たとえば、注文書のシナリオで、各注文書ヘッダーに複数の行アイテムが存在するとします。この場合、PurchaseOrderHeaderが非繰返しノードで、PurchaseOrderLinesが繰返しノードです。
ルールを次のように定義します。
行アイテムの金額が50000より小さい場合、jcooperを2レベルまで含むスーパーバイザ・リストを作成します。
この場合、金額は行の属性、つまり繰返しノードの属性です。
次の手順を使用して、繰返しノード属性を定義します。
ルール・デザイナで、「ファクト」を選択します。
図30-35に示すように、ファクトのリストが表示されます。
図30-36に示すように、それぞれの適切なファクトを編集して、表示されることを確認します。
ルール・デザイナで、ルールを選択し、「追加」アイコン(+)をクリックします。
図30-37に示すように、ルール定義セクションが表示されます。
図30-38に示すように、ルール名の左側にある二重下向き矢印をクリックして、詳細設定を表示します。
図30-39に示すように、「ツリー・モード」を選択し、<ファクト・タイプ>をクリックして、ROOTを選択するオプションのリストを表示します。
ルール条件を定義します。
割当てコンテキストはタスクに存在する情報です。タスクのライフ・サイクルの間に、割当てコンテキストは様々な割当て先を介して進みます。タスク割当て先のコンテキストが変更されると、割当てコンテキストの値も変更されます。
タスクの履歴を参照すると、ライフ・サイクルの間にタスクに含まれた様々な割当てコンテキストを表示できます。Oracle BPM Worklistは、タスク履歴を表示する際に割当てコンテキストを使用します。
タスクのライフ・サイクルの間に、1つのユーザーにタスクを複数回割り当てることができます。ヒューマン・タスク・エディタを使用すると、ユーザーがタスクを確認する頻度を構成できます。
次の手順では、タスク承認の集計を構成する方法を説明します。
ヒューマン・タスク・エディタの「割当ておよびルーティング・ポリシー」セクションで、ステージを選択し、「タスクは開始参加者から最終参加者へ移行します」の右側にある鉛筆アイコンをクリックします。
「制限付き割当ての設定」ダイアログで、「割当て」タブを選択します。
図30-41は、ダイアログで選択したタブを示しています。
ドロップダウン・リストから、次のタスクの集計オプションを選択します。
なし - 承認の集計がないことを示します。つまり、タスクが割り当てられるたびに、ユーザーはタスクを確認します。
ステージ - ユーザーは、ステージで一度のみ、タスクを確認します。
タスク - ユーザーは、タスクのライフ・サイクルで一度のみ、タスクを確認します。
「OK」をクリックします。
タスクが集計され、ユーザーに割り当てられると、タスクは、Oracle BPM Worklist内に、ユーザーが承認しているタスクのすべてのコレクションを表示するコレクション表を持っています。ユーザーがアクションを実行すると、ステージまたはタスク内で、アクションは記録され、すべてのユーザーの割当てに再実行されます。
集計されたタスクは、すべての標準割当てのプロキシ・タスクです。集計されたタスクでは、次のアクションのみ許可されています。
承認/却下などのカスタム・アクション
再割当て
獲得
ユーザーは、個別のタスクでエスカレートなどの追加のアクションを実行できますが、これらのアクションは、記録されず、他のタスクに再生されません。これらのアクションは、集計されたタスクではなく個別のタスク上のアクションとして扱われます。
集計済タスクはビジネス・タスクであるため、承認および却下アクションが表示されます。FYIタスクを集計できる場合は、FYIタスクには承認および却下アクションが表示されます。この場合、承認および却下アクションは確認として扱われます。
|
注意: 集計は、割当て先が同じセットに属する場合にのみ使用できます。たとえば、あるタスクをユーザーAに割り当てて、もう1つのタスクをユーザーAとユーザーBの両方に割り当てた場合、ユーザーAには2つの独立したタスクが表示されます。割当て先がまったく同じではないため、この2つの割当ては、集計されません。 |
この機能はAMXに固有ではありません。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」を参照してください。
|
注意: エスカレーションは、管理チェーンにのみ適用可能です。 |
この機能はAMXに固有ではありません。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」を参照してください。
詳細設定の使用には、次のタスクがあります。
ノート、添付および検証のコールバックの指定
セキュリティ・アクセス・ルールの定義
コールバックは、次を実行できるメカニズムです。
外部のコンテンツ管理システムまたはカスタム・スキーマからの、ビジネス・オブジェクトに関連付けられたノートおよび添付へのアクセス
各タスク・アクションの検証ロジックの定義による、タスクのライフ・サイクルの様々な時点での、ワークフロー・タスクのカスタム検証の実行。
次の手順を使用して、コールバックを追加します。
タスク・エディタで、「詳細設定」セクションを展開します。
「コールバックの構成」をクリックします。
図30-42に示すように、「コールバック詳細」ダイアログが開きます。
「その他のコールバック」タブをクリックします。
図30-43に示すように、追加の入力フィールドが表示されます。
次のいずれかのオプションを使用します。
「コメント・コールバック」フィールドには、ノート・コールバックの適切なJavaクラスを入力します。
「添付コールバック」フィールドには、添付コールバックの適切なJavaクラスを入力します。
「検証コールバック」フィールドには、検証コールバックの適切なJavaクラスを、カンマで区切って入力します。
「OK」をクリックします。
アクセス・ルールは、デフォルトのアクションおよび権限をオーバーライドすることによって、ユーザーが実行できるアクションを制限します。ランタイムに、システムでは、承認、追加、削除などの変更を加える権限がユーザーにあるかどうかを確認する定義済のアクセス・ルールに対して、タスク内のすべての操作をチェックします。ユーザーに変更を加える権限がない場合、適切なエラー・メッセージとともに、操作エラーが出力されます。
AMXでは、グループおよびアプリケーション・ロールにアクセス・ルールを定義できます。たとえば、Operatorsというグループに対して取消アクションを制限するように、アクセス・ルールを定義する場合、このグループに属するすべてのユーザーは、タスクの取消が許可されません。同様に、SOAAuditViewerというアプリケーション・ロールに対して取消アクションを制限するように、アクセス・ルールを定義する場合、SOAAuditViewerアプリケーション・ロールが付与されているすべてのユーザーは、タスクの取消が許可されません。
セキュリティ・アクセス・ルールを定義するには:
図30-44に示すように、ヒューマン・タスク・エディタの「詳細設定」セクションを展開し、「タスク・コンテンツおよびアクションのデフォルト・アクセスをオーバーライドします」オプションに移動します。
「表示の構成」をクリックします。
図30-45に示すように、「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
「タスク・コンテンツ」タブまたは「タスク・アクション」タブをクリックして選択します。(この手順では、「タスク・コンテンツ」タブを選択していることを前提としています。)
編集するタスクを選択し、「編集」アイコンをクリックします。
2つ目の「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
図30-46に示すように、ドロップダウン・リストから、「グループ」を選択します。
「アイデンティティ・ルックアップ」ダイアログが表示されます。
図30-47に示すように、アプリケーション・サーバー、レルムおよび適切なグループを選択します。
「OK」をクリックします。
図30-48に示すように、選択したグループがアクセス・ルールに追加されます。
「OK」をクリックして、ダイアログを閉じます。
アプリケーション・グループのアクセス・ルールを定義するには、次の例外を適用して、同じ手順を使用します。
「タスク・アクション」タブをクリックして選択します。
ドロップダウン・リストから、「アプリケーション」を選択します。
図30-49に示すように、「アプリケーション・ロールの選択」ダイアログで、アクセス・ルールに含めるアプリケーション・ロールを選択します。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の、タスク・コンテンツのアクセス・ロールの指定に関する項を参照してください。
表30-7は、ORACLE_HOME\samples\soa-infra\workflowディレクトリにある、エンドツーエンドのワークフローの例を示しています。
表にリストされたデモンストレーション機能以外に、すべてのサンプルは、ワークリスト・アプリケーションおよびワークフロー通知の使用を示しています。
表30-7 エンドツーエンドのサンプル
| サンプル | 説明 | 場所 |
|---|---|---|
|
経費ライン承認 |
承認ポリシーが定義されたライン・レベルの承認を示します。 |
|
|
従業員雇用 |
Order投票制度の承認グループ・リスト・ビルダーおよびスーパーバイザ・リスト・ビルダーの2つのステージを持つ承認の、非定型の挿入機能を示します。 |
|
|
注文書承認 |
ヘッダーおよびライン・レベルの承認を持つ注文書承認シナリオを示します。 |
|
|
従業員異動 |
パラレルなジョブ・レベルの参加者の間の、あるチームから別のチームへの従業員異動シナリオを示します。 |
|
|
自動承認 |
自動アクション・ルールを介した自動承認の実装方法を示します。 |
|
|
ポジション・リスト・ビルダー |
ポジション・リスト・ビルダーの使用を示します。 |
|
ユーザー・メタデータ移行ユーティリティhwfMigratorは、シェル・スクリプトを実行してSOAサーバー間でワークフローのユーザー構成可能データを移行するプロセスを自動化するツールです。
ユーザー・メタデータ移行ユーティリティの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のテスト環境から本番環境へヒューマン・ワークフロー・データの移動に関する項を参照してください。
