| Oracle® Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド 11g リリース1 (11.1.1.6.2) B61409-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド 11g リリース1 (11.1.1.6.2) B61409-05 |
|
前 |
次 |
この章では、Oracle SOA Suiteのヒューマン・ワークフロー・サービスで使用可能な承認管理の拡張機能について説明します。ヒューマン・ワークフロー・サービスの役割は、ビジネス・プロセスに参加しているユーザーまたはグループのすべての相互作用を処理することです。これを行うために、組織内で該当するユーザーのタスクを作成および追跡します。ユーザーは通常、Oracle BPM Worklist、電子メール、ポータル、カスタム・アプリケーションなどの各種クライアントを通じてタスクにアクセスします。承認管理の拡張機能では、ビジネス・ドキュメントおよび関連するルールを考慮して作業アイテムの承認階層を決定することで、ヒューマン・ワークフローのための複雑なタスク・ルーティング・スリップを定義できます。さらに、承認管理の拡張機能では、スーパーバイザまたはポジション階層に基づいて関連付けられたリスト・ビルダーを使用して、複数ステージの承認を定義できます。Oracle JDeveloperのヒューマン・タスク・エディタで承認タスクを定義し、そのタスクをBPELプロセスに関連付けます。
ヒューマン・タスクの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の次の章および付録を参照してください。
「ヒューマン・タスクの設計」
「ヒューマン・タスク・サービスの理解」
この章の内容は次のとおりです。
承認管理の拡張機能では、複雑な承認パターンでヒューマン・ワークフロー・サービスを拡張します。これは、ヒューマン・ワークフローの高度な割当てマネージャとして機能します。提供されている主なワークフロー機能は、次のとおりです。
承認管理プロセスの宣言モデリング
静的および動的な承認リストを使用して、複雑な複数ステージの承認を定義する機能
タスク・パラメータ、割当てとルーティングのポリシー、エスカレーションと有効期限の設定、および通知設定を定義するワークフロー・エディタ
ポリシー・ベースのタスク割当て。これにより、ユーザーはビジネス・ドキュメントに基づいて承認ルールを定義できます。
承認タスクおよび関連付けられたタスクの操作のコンテンツをレンダリングするためのタスク・フォームを設計する機能
ワークフロー内の様々な参加者の電子メール、ボイスおよびインスタント・メッセージの通知を定義する機能
タスク割当て先、プロセス所有者および管理者の、Webベースのワークリスト・アプリケーション
Oracle Internet Directory、LDAPおよびサード・パーティのディレクトリなどの様々なユーザー・ディレクトリで、ユーザーおよびロールを検索する機能
AMXは、次の追加機能を提供します。
トランザクション・アプリケーションのADFビュー・オブジェクトから導出された属性
階層プロバイダ・プラグインを使用して、HRシステムから様々なジョブ、ポジションおよびスーパーバイザ階層を取得する機能
承認リストおよび階層の構成を制御するルールを定義する機能
図32-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つ以上のステージを含む複雑な承認タスク。詳細は、32.2.3項「ステージ」を参照してください。
有効期限とエスカレーションのポリシー
様々な参加者に通知するための通知設定
ステージ内のリスト・ビルダー。これは、名前と式、管理チェーン、スーパーバイザ、ポジション、ジョブ・レベルの階層、または承認グループに基づいています。詳細は、32.2.4項「リスト・ビルダー」を参照してください。
承認者の置換および変更のポリシー、自動承認の構成、および繰り返された承認者などの承認タスク構成。詳細は、32.2.1項「タスク」を参照してください。
図32-2は、サンプルの承認パターンでの様々なステージを示しています。
これらは、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』で詳細を説明しています。
承認パターンは、次の4つのステージで構成されています。
ヘッダー承認
ライン承認
レシート検証
支払
ヘッダー承認は、ライン承認およびレシート検証と並行して実行されます。これらのステージの実行後に、支払ステージが実行されます。
4つの各ステージに、リスト・ビルダーがあります。ステージ内の複数のリスト・ビルダーを、相互にシリアルまたはパラレルで実行できます。各リスト・ビルダー内に1つ以上の承認者を設定できます。図32-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開発者ガイド』の「アプリケーション・モジュールを使用したビジネス・サービスの実装」および「サービス対応のアプリケーション・モジュールの統合」を参照してください。
ステージは、コレクションに関連する一連の承認です。複数の承認ステージに同じコレクションを関連付けることができます。
図32-4は、ステージおよびコレクションのマッピングを示しています。
各承認ステージは、コレクションに関連付けられます。図32-4では、承認に4つのステージがあります。
ヘッダー承認は、経費ヘッダーのコレクションに関連付けられます。
レシート検証は、経費ヘッダーのコレクションに関連付けられます。
支払は、経費ヘッダーのコレクションに関連付けられます。
ライン承認は、経費ラインのコレクションに関連付けられます。
複合承認は、複数のステージで構成され、相互にシリアルまたはパラレルでモデリングできます。各ステージは、承認者のリストを決定するリスト・ビルダーで構成されます。
オプションで、各リスト・ビルダーを承認ポリシー、つまりルールのセットに関連付けることができます。ランタイムに、ステージ内で使用されたリスト・ビルダーおよび関連付けられたポリシーに基づいて、適切な承認のセットが戻されます。
32.2.3項で説明しているように、各承認ステージは、承認者の実際のリストを決定するリスト・ビルダーで構成されます。次のリスト・ビルダーがサポートされています。
名前と式
静的な名前またはXPath式から取得された名前を使用して、リストを作成できます。
承認グループ
事前定義された承認者グループを、承認者リストに含めます。承認グループは、静的にも動的にもなります。
ジョブ・レベル
スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
ポジション
ポジション階層内を上行します。指定された承認者のポジションから開始し、十分なジョブ・レベルを持つポジションが見つかるまで続行します。
スーパーバイザ
プライマリ・スーパーバイザ階層内を上行します。リクエスタまたは指定された承認者から開始し、固定承認者数を持つチェーンを生成します。
管理チェーン
対応するユーザー・ディレクトリ内の管理関係に基づいて、リストを作成できます。
管理チェーン最初の割当て先が単一ユーザーの場合、管理チェーン参加者タイプでサポートされるのはパラレル・ルーティングのみです。管理チェーンの最初の割当て先として、一連のユーザーまたはグループなどのパラレル参加者を指定することはできません。
ルールベース
様々な条件に基づいて様々なリスト・ビルダー・タイプを戻すルールをモデリングできます。たとえば、ルールを持つスーパーバイザ・リスト・ビルダーをモデリングする場合、ルールは、スーパーバイザ・リスト・ビルダーのみを戻すことができます。ルール・ベースのリスト・ビルダーをモデリングする場合、ルールは、様々なリスト・ビルダー・タイプを戻すことができます。
|
注意: 承認グループ、ジョブ・レベル、ポジションおよびスーパーバイザ・リスト・ビルダーはAMXに固有で、32.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ベースのファクト・タイプに基づく承認者リストを作成する、スーパーバイザ・リスト・ビルダー・パラメータの構成を示しています。
例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.3.6.4.1項「リストを作成する方法」を参照してください。
リスト置換を使用して、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。
次のルールの例は、承認者の置換の使用方法を示しています。
例32-3 承認者の置換の使用方法
IF ExpenseItems.ReceiptAmount < new BigDecimal(4000) THEN call Substitute(fromId:"jcooper", toId:"jstein", ruleName:"Substituted", substitutionRules: SubstitutionRules)
このルールは、経費項目の金額が4000より小さい場合、承認者jcooperを承認者jstein(承認者リストに存在する場合)に置換することを示しています。
詳細は、32.3.6.4.2項「承認者の置換を行う方法」を参照してください。
ジョブ・レベルおよびポジションのリストを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。
次のルールの例は、リストの変更の使用方法を示しています。
例32-4 リストの変更の使用方法
IF ExpenseItems.ReceiptAmount > new BigDecimal(3000) THEN Call Extend(ifFinalApproverLevel:3, extendBy:2,ruleName:"Modified",lists:Lists)
このルールは、経費項目の金額が3000より大きい場合、および承認者リストの最終承認者がジョブ・レベル3の場合、承認者リストを少なくとも相対的に2レベルまで拡張することを示しています。
詳細は、32.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を生成します。
図32-5は、ヒューマン・タスク・エディタのグローバリゼーション・アイコンを示しています。
次の手順は、翻訳可能な文字列の追加方法を説明しています。これは、リソース・バンドルが指定されていることを前提としています。
アイコンをクリックして、「翻訳可能文字列の編集」ダイアログを表示します。
ドロップダウン・リストからキーを選択するか、プラス記号(+)をクリックしてキーを作成します。
図32-6は、「新規キーの作成」ダイアログを示しています。これは、「翻訳可能文字列の編集」ダイアログのプラス記号(+)をクリックすると表示されます。
名前、翻訳可能なテキストを入力し、「OK」をクリックします。
図32-7は、新規キーが追加された後の「翻訳可能文字列の編集」ダイアログを示しています。
式ビルダーを使用して、値を追加します。
図32-8は、完了した「翻訳可能文字列の編集」ダイアログを示しています。
|
注意: タイトル値、またはタイトル値の定義は、TaskDefinition XML( |
「OK」をクリックして、ダイアログを閉じます。
タスク・パラメータの指定には、次のタスクがあります。
SDO参照の作成
エンティティ・パラメータの定義
コレクションの定義
SDOサービスは、ワークフロー・サービスから起動して、XMLとしてSDOを取得できます。この起動は、SOA Webサービス・コールのフォームにあります。SDOサービスのWSDL URLが使用可能な場合、「Webサービスの作成」ダイアログを使用して、Webサービス参照を追加する必要があります。
参照を作成するには、図32-9に示すように、WSDL URLを入力し、使用可能なポート・タイプからポート・タイプを選択します。
SDOの作成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、SOAコンポジット・エディタの概要に関する項の、参照の概要に関する項を参照してください。
次の手順によって、サービス・データ・オブジェクト(SDO)を受け入れることができます。
コンポジット内のサービス参照を作成します。
これにより、ファブリックは、WSDLを指す特定のURLへの必要なすべてのワイヤリングを作成できます。
タスク・ペイロードを外部として定義し、どのワークフローがSDOオブジェクトを取得するかを指定します。
これにより、SDO Webサービスへの入出力を表すタスク・パラメータが作成されます。
「エンティティ」を選択します。
図32-10に示すように、コレクション、そのXPATH式およびそのキーを定義します。
ステージのコレクションを設定します。
「OK」をクリックします。
次の手順によって、静的XMLを受け入れることができます。
スキーマを定義するXSDを指定します。
タスク・ペイロード・パラメータを静的XMLとして定義します。
コレクション、そのXPATH式およびそのキーを定義します。
ステージのコレクションを設定します。
「OK」をクリックします。
コレクションは、タスク・メッセージ属性の特定の部分である静的XMLベースおよびエンティティの両方の属性への参照です。コレクションを定義すると、コレクションをステージに関連付けて、コレクションの処理時にステージを識別できます。
コレクションの定義には、コレクション名の定義およびコレクション要素へのXPathの定義があります。コレクションをエンティティ属性に定義する場合、コレクション要素のキーも指定する必要があります。各キーはコレクション要素の直接の子である必要があります。図32-11は、コレクションの定義方法を示しています。
コレクションを定義すると、JDeveloperによって、コレクションが繰返し要素であるかどうかが自動的に決定されます。この情報は、コレクションをステージに関連付けるときに使用されます。非繰返しコレクションは、単一のステージに関連付けることができます。繰返しコレクションは、ステージに関連付ける場合、ランタイムにコレクション内の各要素のステージをパラレルで繰り返します。コレクション情報のステージでの使用方法の詳細は、32.3.6.1項「ステージをモデリングおよび構成する方法」を参照してください。
ヒューマン・ワークフローは、タスクのペイロードから抽出されたデータなど、ユースケース固有のデータを格納するのに使用できるタスク・メッセージ属性を提供します。これらの属性は、フレックスフィールド属性またはマップ済フレックスフィールド属性とも呼ばれます。
マップ済フレックスフィールド属性を使用すると、ペイロード値を、タスク詳細で非表示にするのではなく、タスク・リスト内の列として表示できます。これらの値は、ヒューマン・ワークフロー・データベース・スキーマに格納され、問合せ、ビュー定義および割当てルール定義で使用できます。
メッセージ属性には次の2つのタイプがあります。
パブリック - ランタイムに特定のタスク・コンポーネントにマップされる属性。これらのマッピングはいつでも変更でき、タスク・コンポーネントの再デプロイ時に再作成する必要があります。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の次の項を参照してください。
「Oracle BPM Worklistの使用」の、フレックス・フィールドのマップ方法に関する項
「ヒューマン・ワークフローの概要」の、フレックス・フィールドの概要に関する項
保護 - デザインタイムに定義されたタスク・コンポーネントと保護済のフレックスフィールド属性間の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 |
数値情報を格納します。 |
属性ラベルは、意味のある文字列を、特定のフレックスフィールド属性に適用できるユーザー定義のプロパティです。ラベルは、属性に格納するデータを反映する必要があります。たとえば、CustomerNameをProtectedTextAttribute1に、OrderNumberをProtectedNumberAttribute2に、OrderDateをProtectedDateAttribute1にします。
フレックスフィールド属性は、属性に定義された複数の属性ラベルを持つことができます。たとえば、属性ProtectedTextAttribute1は、ラベルCusomerName、PartIdおよびEmployeeDepartmentを持つことがあります。
保護済の属性の属性ラベル・マッピングは、デザインタイムにヒューマン・タスク・エディタで定義されます。これらは、特定のタスク・コンポーネントと属性ラベル間のマッピングを定義し、属性の値を移入する方法を指定します。同じ属性ラベルを複数のマッピングで再利用できます。これにより、タスク・コンポーネントは、同じセマンティックな意味を持つデータを、共通のラベルで識別される共通の属性にマップできます。
たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクすべてがCustomerNameラベルへのマッピングを定義するとします。複数のタスク・コンポーネントで同じ属性ラベルを共有することによって、複数のタスク・タイプを問い合せ、共通の属性ラベルから値を表示またはフィルタ処理するワークリスト問合せを作成できます。たとえば、PurchaseOrder、LoanRequestおよびServiceRequestのタスクを選択し、ワークリストのタスク・リスト内の列としてCustomerNameを表示する問合せを作成できます。
詳細は、32.5.2項「マップ済属性ラベルを作成する方法」を参照してください。
図32-12に示すように、ヒューマン・タスク・エディタの「マップ済属性」セクションで、属性ラベル・マッピングを定義します。
次の手順を使用して、属性ラベル・マッピングを定義します。
「追加」アイコンをクリックして、図32-13に示す「マップ済属性の追加」ダイアログを表示します。
次のいずれかのオプションを実行します。
ドロップダウン・リストから、保護済の属性ラベルを含むアプリケーション・サーバーを選択します。
「追加」アイコンをクリックして、接続を作成します。
「編集」アイコンをクリックして、既存の接続を編集します。
「属性」ドロップダウン・リストを使用して、指定したサーバーから使用可能な属性ラベルを移入します。
ドロップダウン・リストから、属性を選択します。
|
注意: このリストには、このタスク・コンポーネントがマップされているフレックスフィールド属性のラベルは含まれていません。 |
「値」フィールドで、次の方法のいずれかを使用して値を指定します。
属性に格納する値を決定するXPath式を入力します。
アイコンをクリックして、式ビルダーで値を作成します。
フィールドを空白にして、ランタイムに値を決定できます。
通常、このXPath式は、タスクのペイロードから値を選択しますが、単純型(文字列、日付、数値など)と評価される有効な式を指定できます。
XPath式の指定は必須ではないことに注意してください。基礎となるフレックスフィールド属性の値を自分で設定するように選択できます。たとえば、タスクを開始するBPELプロセスにカスタム割当てアクティビティを追加したり、ワークフロー・サービスAPIを介してタスク・オブジェクトを操作できます。
説明を入力します。これはオプションです。
「OK」をクリックします。
ルーティングおよび承認ポリシーの指定には、次のタスクがあります。
ステージのモデリングおよび構成
タスク参加者のモデリング
リスト・ビルダーのモデリングおよび構成
ビジネス・ルールの定義
ビジネス・ルールを使用したリスト・ビルダーの指定
割当てコンテキスト情報の使用
タスク承認の集計
機能のニーズに基づいて、順次ステージおよびパラレル・ステージの組合せとなる構造に、複数のステージを追加および配置できます。この項では、順次ステージおよびパラレル・ステージの作成方法について説明します。
次の手順を使用して、ステージを作成します。
ヒューマン・タスク・エディタの割当ておよびルーティングセクションで、ステージを選択します。
図32-14に示すように、「追加」アイコンをクリックし、ドロップダウン・リストから「順次ステージ」または「パラレル・ステージ」のいずれかを選択します。
順次ステージを作成するように選択した場合、割当ておよびルーティングセクションは、図32-15のようになります。
パラレル・ステージを作成するように選択した場合、割当ておよびルーティングセクションは、図32-16のようになります。
作成したステージをダブルクリックするか、ステージを選択して「編集」アイコンをクリックします。
図32-17に示すように、「編集」ダイアログが表示されます。
ステージの名前を入力します。
次のいずれかのオプションを選択します。
繰返しなし - コレクション内の各要素に、1ステージのみが並行して存在することを指定します。
コレクション内の各アイテムのステージを並行して繰り返します。 - ステージを、コレクション内の各要素に対して並行して繰り返すように指定します。たとえば、10行の注文書の場合、ステージは並行して10回繰り返されます。
ドロップダウン・リストからコレクションを選択します。
選択内容に従って、次のいずれかを実行します。
「繰返しなし」を選択した場合、「OK」をクリックして、「編集」ダイアログを閉じます。
「コレクション内の各アイテムのステージを並行して繰り返します。」を選択した場合、図32-18に示すように、追加オプションが表示されます。
次のように実行します。
デフォルトの結果を選択します。
同意パーセントを選択します。
ただちに結果をトリガーするか、または結果をトリガーせずにすべての投票の完了まで待機するかを選択します。
「OK」をクリックして、「編集」ダイアログを閉じます。
各ステージ内で、デフォルトのタスク参加者を編集するか、新規タスク参加者を追加できます。ルーティング・パターンに基づいて、タスク参加者を次のいずれかに割り当てます。
単一
パラレル
シリアル
FYI
参加者タイプおよびタスク参加者のステージへの割当ての詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク参加者の割当て方法に関する項を参照してください。
ルーティング・パターンの選択後に、リスト・ビルダーを選択およびモデリングする必要もあります。このプロセスは、32.3.6.3項「リスト・ビルダーをモデリングおよび構成する方法」で詳細を説明しています。
ステージは、リスト・ビルダーの組合せを使用して、承認リストを生成します。詳細は、32.2.3項「ステージ」および32.2.4項「リスト・ビルダー」を参照してください。それぞれのタイプのリスト・ビルダーは、ステージごとに1回のみ使用できます。順次またはパラレルの順序で、これらの承認者リスト・ビルダーを配置できます。選択した順序は、リスト・ビルダーによって生成された承認者リストに含まれる承認者を承認タスクに割り当てる順序を制御します。
次のリスト・ビルダーはAMXに固有です。
承認グループ
ジョブ・レベル
ポジション
スーパーバイザ
|
注意: その他のリスト・ビルダーのモデリングの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の、ヒューマン・タスク・エディタを使用したヒューマン・タスク定義の作成に関する項の、タスク参加者の割当て方法に関する項の、単一のタスク参加者リストの作成に関する項を参照してください。 |
表32-2は、AMX固有のリスト・ビルダーおよびそれに使用できるオプションを説明しています。
表32-2 リスト・ビルダー・オプション
| オプション名 | 説明 | リスト・ビルダー |
|---|---|---|
|
値ベース |
指定した値に基づいて、参加者のリストを作成するための制限を指定します。 |
ポジション以外のすべて |
|
ルールベース |
ルール・エディタで定義されたルールに基づいて、参加者のリストを作成するための制限を指定します。 |
すべて |
|
名前 |
使用する承認グループの名前 |
承認グループ |
|
空のグループを許可 |
メンバーのない承認グループの使用を許可します。 |
承認グループ |
|
ルールセットのリスト |
参加者のリストを作成するための制限を指定しているルールセットの名前。 |
すべて |
|
開始参加者 |
リスト内の最初の参加者。通常はマネージャです。 |
ジョブ・レベル ポジション スーパーバイザ |
|
最上位の参加者 |
承認での最後の参加者。承認は、階層内でこの参加者より先には進みません。 |
ジョブ・レベル ポジション スーパーバイザ |
|
レベル数 |
スーパーバイザが移動するレベル数、またはジョブ・レベルおよびポジションのジョブ・レベル数を指定する正数。この数には、絶対値、開始点からの相対値、作成者を使用できます。 |
ジョブ・レベル ポジション スーパーバイザ |
|
相対 |
スーパーバイザが移動するレベル数、またはジョブ・レベルおよびポジションのジョブ・レベル数を指定する正数。使用可能な値は、開始点、作成者および絶対値です。 |
ジョブ・レベル ポジション |
|
最後のレベルの全マネージャを含む |
ジョブ・レベルがリスト内で以前に計算された最後の参加者のレベルと等しい場合は、リスト内の次のマネージャが含まれます。 |
ジョブ・レベル |
|
使用される参加者 |
参加者の計算済リストからこのオプションで指定された参加者のみ使用します。使用可能なオプションは、全員、最初および最後のマネージャ、最後のマネージャです。 |
ジョブ・レベル ポジション |
|
自動アクションの有効化 |
リスト・ビルダーが次のオプションに基づいてタスクを自動的に実行するかどうかを指定します。 |
スーパーバイザ ジョブ・レベル ポジション |
|
自動アクション |
設定される結果を指定します。自動アクションが有効でない場合は、nullにできます。 |
スーパーバイザ ジョブ・レベル ポジション |
階層プロバイダ・プラグインを構成しない場合、ポジション・リスト・ビルダーは機能しません。
階層の拡張を定義する際に、プロパティmustUseSpecifiedProviderを定義しない場合、デフォルト値はtrueです。
階層プラグインに問題がある場合に例外をスローしないようにスーパーバイザおよびジョブ・レベル・リスト・ビルダーを構成できます。リスト・ビルダーを構成するには、workflow-identity-config.xml構成ファイルにmustUseSpecifiedProviderプロパティを追加し、値属性をfalseに設定する必要があります。
デフォルトでは、workflow-identity-config.xmlファイルには、mustUseSpecifiedProviderプロパティが含まれていません。このプロパティが存在し、その値がfalseの場合、階層プラグインに関する問題があると、スーパーバイザおよびジョブ・レベル・リスト・ビルダーはLDAP管理チェーンを使用します。
例32-5に、mustUseSpecifiedProviderプロパティを指定するworkflow-identity-config.xmlファイルを示します。このプロパティの値はtrueに設定されており、階層プラグインが使用可能でない場合に、スーパーバイザおよびジョブ・レベル・ビルダーが失敗するようになっています。
例32-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クラス・パスの一部であり世界的に有名なディレクトリでの、クラス・ファイルの公開
|
注意: ドロップ8では、承認グループはフラット・リストです。シリアルおよびパラレルのパターンは定義されなくなります。 |
詳細は、32.5項「Oracle BPM Worklistおよびプロセス・ワークスペースの承認管理機能の使用」を参照してください。
図32-19および図32-20は、承認グループ・リスト・ビルダーの2種類の表示を示しています。
承認グループ・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表32-2を参照してください。
ジョブ・レベル・リスト・ビルダーは、スーパーバイザ階層内を上行します。指定された承認者から開始し、十分なジョブ・レベルを持つ承認者が見つかるまで続行します。
図32-21および図32-22は、ジョブ・レベル・リスト・ビルダーの2種類の表示を示しています。
ジョブ・レベル・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表32-2を参照してください。
ポジション・リスト・ビルダーは、ポジション階層内を上行します。リクエスタまたは指定された承認者のポジションから開始し、指定したレベル数または特定のポジションまで進みます。
図32-23は、ポジション・リスト・ビルダーの表示を示しています。
ポジション・リスト・ビルダーをモデリングするには、まず、リスト・ビルダーの属性が値ベースまたはルールベースであるかを指定し、対応するダイアログでオプションを選択します。オプションの詳細は、表32-2を参照してください。
タスク定義のインラインで、またはタスクの実際の承認者を識別するリスト・ビルダーを指定するビジネス・ルールを使用して、タスクの承認者を定義できます。さらに、ビジネス・ルールを使用して、承認者の置換およびリストの変更を指定できます。これらのルールは、Oracle Business Rulesのヘルプを使用して定義され、組織間で変えることができます。ただし、通常、これらは顧客によって定義されます。
ビジネス・ルールは、条件とアクションの組合せです。オプションで、ビジネス・ルールに優先度および有効期間を定義できます。ヒューマン・ワークフロー・ルールでは、タスク、タスク・メッセージおよび(SDOオブジェクトのXML表現である)エンティティ属性に対応するファクト・タイプを使用して、ルール条件が定義されます。ルール・アクションは、承認者リスト・ビルダーおよびそのパラメータで構成されます。承認者リスト・ビルダーは、特定の階層に移動し、定義されたパラメータに応じて承認者リストを作成または変更します。承認者リスト・ビルダーは、XML (JAXB)ファクト・タイプとして実装されます。
これらの概念の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「Oracle Business Rulesの概要」を参照してください。
後述の項では、Oracle Business Rulesを使用した、リストの作成、承認者の置換、リストの変更および繰返しノード属性について説明します。
ビジネス・ルールを使用して、使用するリスト・ビルダーを定義できます。ビジネス・ルールには2つのタイプがあります。
特定のリスト・ビルダーのパラメータを定義するルール。この場合、特定のリスト・ビルダーを使用するために、タスク・ルーティング・パターン・ダイアログがモデリングされます。リスト・ビルダーのパラメータはルールに基づきます。このオプションを使用して、ルールは、JDeveloperでモデリングされたタイプと同じタイプのリスト・ビルダーを戻す必要があります。図32-26は、サンプルの構成を示しています。
リスト・ビルダーおよびリスト・ビルダー・パラメータを定義するルール。この場合は、リスト自体がルールを使用して作成されます。図32-27は、サンプルの構成を示しています。
ルール・ディクショナリで、リスト・ビルダーの作成を容易にするために、ルール関数がシードされます。これらの関数は次のとおりです。
CreateResourceList
CreateSupervisoryList
CreateManagementChainList
CreateApprovalGroupList
CreateJobLevelList
CreatePositionList
図32-28に示すように、ルール・デザイナで、条件をモデリングし、アクション部分で、上述の関数の1つを呼び出して、リストの作成を完了します。
ルール関数のパラメータは、JDeveloperモデリングでのパラメータに類似しています。JDeveloperでの構成に加えて、ルール・デザイナでは、次の属性の追加のオプションが使用可能です。
startingPointおよびtopApprover - JDeveloperでは、開始点および上位承認者がユーザーとして指定されます。ルール・デザイナでは、HierarchyPrincipalを開始点および上位承認者として作成できます。階層プリンシパルを構築するには、図32-29に示すように、HierarchyBuilder関数を使用します。
autoActionEnabledおよびautoAction - ルール・デザイナから、特定のリスト・ビルダーによって生じるユーザーがタスクを自動的に処理できるように構成できます。
responseType - レスポンス・タイプがREQUIREDの場合、割当て先はタスクを処理する必要があります。それ以外の場合、割当てはFYI割当てに変換されます。
ruleName - ルール名は、割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。
lists - これは、作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。
図32-30および図32-31は、ルールの例を示しています。
|
注意: 複数のルールが起動する場合、最も優先度が高いルールによって作成されたリスト・ビルダーが選択されます。 ルールが同じ優先度の場合、ランダムな順序で起動し、最初に起動したルールが選択されます。 |
|
警告: リスト作成ルール・セット内のルール定義が不適切または不完全な場合は、実行時エラーの原因になることがあります。次の場合にエラーが発生します。
すべての条件を処理するよう、ルールを正しく定義してください。 |
リスト置換によって、リストに表示されるユーザー、グループおよびアプリケーション・ロールを置換できます。リスト置換は、ルール・デザイナから使用可能で、JDeveloperでの構成は必要ありません。各ルール・ディクショナリに、SubstitutionRulesという名前の事前にシードされたルール・セットがあります。ルール・ディクショナリには、リスト置換を構成するためのSubstituteルール関数もシードされています。表32-3には、Substitute関数およびそのパラメータがリストされています。
表32-3 Substitute関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
fromId |
置換元のユーザー/グループ/アプリケーション・ロールのID。 |
|
toId |
置換先のユーザー/グループ/アプリケーション・ロールのID。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
substitutionRules |
すべての置換のホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、SubstitutionRulesオブジェクトが表示されます。 |
図32-32は、承認者の置換アクションのサンプルを示しています。
リストの変更によって、ジョブ・レベルおよびポジションのリスト・ビルダーを、ルールから拡張または切り捨てることができます。リストの変更は、リストの作成後に適用されます。この機能は、JDeveloperからの構成は必要ありません。各ルール・ディクショナリに、ModificationRulesという名前の事前にシードされたルール・セットがあります。ルール・セットを作成したリストに、ジョブ・レベルおよびポジションのリスト・ビルダーがアサートされる場合のみ、このルール・セットが呼び出されます。最も優先度が高い適用可能なルールのみ適用されます。
ルール・デザイナで、リストの変更を容易にするために、ルール関数がシードされます。これらの関数は次のとおりです。
Extend
Truncate
図32-33は、これらのルール関数を示しています。
表32-4および表32-5には、ExtendおよびTruncateのパラメータがリストされています。
表32-4 Extend関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
ifFinalApproverLevel |
最終承認者が存在するレベル以下のレベル。 |
|
extendBy |
最終ジョブ・レベルに追加するレベル数。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
lists |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
表32-5 Truncate関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
afterLevel |
切り捨てた後のレベル。 |
|
ruleName |
割当て理由の作成に使用されます。ルール・セット名 + "_" + ルール名は、翻訳可能な割当ての理由のリソース・バンドルを検索するためのキーとして使用されます。このリソースは、まずプロジェクト・リソース・バンドル内で検索され、次にカスタム・リソース・バンドル内、最後にシステム・リソース・バンドル内で検索されます。 |
|
lists |
作成されるすべてのリストのホルダーとなるオブジェクトです。このオプションをクリックすると、パラメータとして使用するために、事前にアサートされたファクト、Listsオブジェクトが表示されます。 |
図32-34は、リストの変更アクションのサンプルを示しています。
ビジネス・ルールの定義時に、繰返しノードからの属性に基づいてルール条件を指定できます。たとえば、注文書のシナリオで、各注文書ヘッダーに複数の行アイテムが存在するとします。この場合、PurchaseOrderHeaderが非繰返しノードで、PurchaseOrderLinesが繰返しノードです。
ルールを次のように定義します。
行アイテムの金額が50000より小さい場合、jcooperを2レベルまで含むスーパーバイザ・リストを作成します。
この場合、金額は行の属性、つまり繰返しノードの属性です。
次の手順を使用して、繰返しノード属性を定義します。
ルール・デザイナで、「ファクト」を選択します。
図32-35に示すように、ファクトのリストが表示されます。
図32-36に示すように、それぞれの適切なファクトを編集して、表示されることを確認します。
ルール・デザイナで、ルールを選択し、「追加」アイコン(+)をクリックします。
図32-37に示すように、ルール定義セクションが表示されます。
図32-38に示すように、ルール名の左側にある二重下向き矢印をクリックして、詳細設定を表示します。
図32-39に示すように、「ツリー・モード」を選択し、<ファクト・タイプ>をクリックして、ROOTを選択するオプションのリストを表示します。
ルール条件を定義します。
割当てコンテキストはタスクに存在する情報です。タスクのライフ・サイクルの間に、割当てコンテキストは様々な割当て先を介して進みます。タスク割当て先のコンテキストが変更されると、割当てコンテキストの値も変更されます。
タスクの履歴を参照すると、ライフ・サイクルの間にタスクに含まれた様々な割当てコンテキストを表示できます。Oracle BPM Worklistは、タスク履歴を表示する際に割当てコンテキストを使用します。
タスクのライフ・サイクルの間に、1つのユーザーにタスクを複数回割り当てることができます。ヒューマン・タスク・エディタを使用すると、ユーザーがタスクを確認する頻度を構成できます。
次の手順では、タスク承認の集計を構成する方法を説明します。
ヒューマン・タスク・エディタの「割当ておよびルーティング・ポリシー」セクションで、ステージを選択し、「タスクは開始参加者から最終参加者へ移行します」の右側にある鉛筆アイコンをクリックします。
「制限付き割当ての設定」ダイアログで、「割当て」タブを選択します。
図32-41は、ダイアログで選択したタブを示しています。
ドロップダウン・リストから、次のタスクの集計オプションを選択します。
なし - 承認の集計がないことを示します。つまり、タスクが割り当てられるたびに、ユーザーはタスクを確認します。
ステージ - ユーザーは、ステージで一度のみ、タスクを確認します。
タスク - ユーザーは、タスクのライフ・サイクルで一度のみ、タスクを確認します。
「OK」をクリックします。
タスクが集計され、ユーザーに割り当てられると、タスクは、Oracle BPM Worklist内に、ユーザーが承認しているタスクのすべてのコレクションを表示するコレクション表を持っています。ユーザーがアクションを実行すると、ステージまたはタスク内で、アクションは記録され、すべてのユーザーの割当てに再実行されます。
集計されたタスクは、すべての標準割当てのプロキシ・タスクです。集計されたタスクでは、次のアクションのみ許可されています。
承認/却下などのカスタム・アクション
再割当て
獲得
ユーザーは、個別のタスクでエスカレートなどの追加のアクションを実行できますが、これらのアクションは、記録されず、他のタスクに再生されません。これらのアクションは、集計されたタスクではなく個別のタスク上のアクションとして扱われます。
この機能はAMXに固有ではありません。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」を参照してください。
|
注意: エスカレーションは、管理チェーンにのみ適用可能です。 |
この機能はAMXに固有ではありません。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」を参照してください。
詳細設定の使用には、次のタスクがあります。
ノート、添付および検証のコールバックの指定
セキュリティ・アクセス・ルールの定義
コールバックは、次を実行できるメカニズムです。
外部のコンテンツ管理システムまたはカスタム・スキーマからの、ビジネス・オブジェクトに関連付けられたノートおよび添付へのアクセス
各タスク・アクションの検証ロジックの定義による、タスクのライフ・サイクルの様々な時点での、ワークフロー・タスクのカスタム検証の実行。
次の手順を使用して、コールバックを追加します。
タスク・エディタで、「詳細設定」セクションを展開します。
「コールバックの構成」をクリックします。
図32-42に示すように、「コールバック詳細」ダイアログが開きます。
「その他のコールバック」タブをクリックします。
図32-43に示すように、追加の入力フィールドが表示されます。
次のいずれかのオプションを使用します。
「コメント・コールバック」フィールドには、ノート・コールバックの適切なJavaクラスを入力します。
「添付コールバック」フィールドには、添付コールバックの適切なJavaクラスを入力します。
「検証コールバック」フィールドには、検証コールバックの適切なJavaクラスを、カンマで区切って入力します。
「OK」をクリックします。
アクセス・ルールは、デフォルトのアクションおよび権限をオーバーライドすることによって、ユーザーが実行できるアクションを制限します。ランタイムに、システムでは、承認、追加、削除などの変更を加える権限がユーザーにあるかどうかを確認する定義済のアクセス・ルールに対して、タスク内のすべての操作をチェックします。ユーザーに変更を加える権限がない場合、適切なエラー・メッセージとともに、操作エラーが出力されます。
AMXでは、グループおよびアプリケーション・ロールにアクセス・ルールを定義できます。たとえば、Operatorsというグループに対して取消アクションを制限するように、アクセス・ルールを定義する場合、このグループに属するすべてのユーザーは、タスクの取消が許可されません。同様に、SOAAuditViewerというアプリケーション・ロールに対して取消アクションを制限するように、アクセス・ルールを定義する場合、SOAAuditViewerアプリケーション・ロールが付与されているすべてのユーザーは、タスクの取消が許可されません。
セキュリティ・アクセス・ルールを定義するには:
図32-44に示すように、ヒューマン・タスク・エディタの「詳細設定」セクションを展開し、「タスク・コンテンツおよびアクションのデフォルト・アクセスをオーバーライドします」オプションに移動します。
「表示の構成」をクリックします。
図32-45に示すように、「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
「タスク・コンテンツ」タブまたは「タスク・アクション」タブをクリックして選択します。(この手順では、「タスク・コンテンツ」タブを選択していることを前提としています。)
編集するタスクを選択し、「編集」アイコンをクリックします。
2つ目の「タスク・コンテンツ・アクセスの設定」ダイアログが表示されます。
図32-46に示すように、ドロップダウン・リストから、「グループ」を選択します。
「アイデンティティ・ルックアップ」ダイアログが表示されます。
図32-47に示すように、アプリケーション・サーバー、レルムおよび適切なグループを選択します。
「OK」をクリックします。
図32-48に示すように、選択したグループがアクセス・ルールに追加されます。
「OK」をクリックして、ダイアログを閉じます。
アプリケーション・グループのアクセス・ルールを定義するには、次の例外を適用して、同じ手順を使用します。
「タスク・アクション」タブをクリックして選択します。
ドロップダウン・リストから、「アプリケーション」を選択します。
図32-49に示すように、「アプリケーション・ロールの選択」ダイアログで、アクセス・ルールに含めるアプリケーション・ロールを選択します。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の、タスク・コンテンツのアクセス・ロールの指定に関する項を参照してください。
表32-7は、ORACLE_HOME\samples\soa-infra\workflowディレクトリにある、エンドツーエンドのワークフローの例を示しています。
表にリストされたデモンストレーション機能以外に、すべてのサンプルは、ワークリスト・アプリケーションおよびワークフロー通知の使用を示しています。
表32-7 エンドツーエンドのサンプル
| サンプル | 説明 | 場所 |
|---|---|---|
|
経費ライン承認 |
承認ポリシーが定義されたライン・レベルの承認を示します。 |
|
|
従業員雇用 |
Order投票制度の承認グループ・リスト・ビルダーおよびスーパーバイザ・リスト・ビルダーの2つのステージを持つ承認の、非定型の挿入機能を示します。 |
|
|
注文書承認 |
ヘッダーおよびライン・レベルの承認を持つ注文書承認シナリオを示します。 |
|
|
従業員異動 |
パラレルなジョブ・レベルの参加者の間の、あるチームから別のチームへの従業員異動シナリオを示します。 |
|
|
自動承認 |
自動アクション・ルールを介した自動承認の実装方法を示します。 |
|
|
ポジション・リスト・ビルダー |
ポジション・リスト・ビルダーの使用を示します。 |
|
Oracle BPM Worklistを使用すると、ユーザーは、次のような様々な承認管理タスクを実行できます。
タスク・フォームを使用したタスクの管理
マップ済属性ラベルの定義
承認グループの管理
タスク構成を使用した承認ルールの構成
タスク・リスト・リージョンおよびポートレットの使用
タスク履歴リージョンを使用した承認者のプレビュー
ヒューマン・ワークフロー・サービスでは、ユーザーにタスクを作成して、ビジネス・プロセスと相互作用します。それぞれのタスクには、タスク・メタデータとタスク・フォームという2つの部分があります。タスク・フォームは、タスクのコンテンツをユーザーのワークリストに表示するために使用されます。
タスク・フォームは、Oracle Application Development Framework (Oracle ADF)を使用して、JDeveloperで設計されます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスク用のタスク表示フォームの設計」を参照してください。
Oracle BPM Worklistには、ユーザーまたはグループに割り当てられているすべてのワークリスト・タスクが表示されます。ワークリスト・ユーザーが特定のタスクにドリル・ダウンすると、タスク表示フォームは、そのタスクの詳細をレンダリングします。たとえば、経費承認タスクでは様々な経費の明細項目が記載されたフォームが表示され、ヘルプ・デスク・タスク・フォームでは重大度や問題の場所などの詳細が表示されます。
後述の項では、管理者権限を持つユーザーがタスクを管理するために使用する、Oracle BPM Worklistのタスク・フォームについて説明します。図32-50は、タスク・フォームの表示内容を示しています。
図32-51に示すヘッダー・ビューは、ヘッダー・ドロップ・ハンドラを使用して、JDeveloperで作成されます。
デフォルトでは、ドロップ・ハンドラには、表32-8にリストされたヘッダー・フィールドが含まれています。ただし、ユース・ケースに基づいて、任意のフィールドを追加または削除できます。
表32-8 ヘッダー・フィールド
| フィールド | 説明 |
|---|---|
|
タスク番号 |
タスクに自動的に割り当てられる番号。 |
|
状態 |
タスクの現在のステータス。 |
|
結果 |
ユーザーの結果。たとえば、ユーザーが「承認」をクリックした場合、「結果」フィールドには「承認」と表示されます。 |
|
優先度 |
タスクに割り当てられる優先度レベル。 |
|
作成者 |
タスクを作成したユーザー。 |
|
作成日 |
タスクの作成日付。 |
|
更新済 |
タスクが最後に更新された日付。 |
|
有効期限 |
タスクが期限切れになる日付。 |
|
割当て先 |
タスクを割り当てる管理者の名前。 |
|
取得者 |
アクションの実行前にタスクを申告するユーザーの名前。 |
|
期日 |
タスクの期限となる日付。 |
ヘッダーにも、カスタム・アクションおよびシステム・アクションがあります。カスタム・アクションは、タスク・メタデータの結果に依存するアクションです。たとえば、メタデータに承認と却下の結果が含まれる場合、「承認」および「却下」が、カスタム・アクションとしてヘッダーに表示されます。メタデータに3つ以上の結果が含まれる場合、カスタム・アクションは、独立したボタンではなくドロップダウン・リストとしてヘッダーに表示されます。図32-51では、「承認」および「却下」は、独立したボタンとして表示されています。これは、タスク・メタデータには承認と却下の2つの結果が含まれていることを示しています。
エスカレート、一時停止、再開などのシステム・アクションは、常にドロップダウン・リストで表示されます。表示されるアクションは、ユーザーが実行する内容に依存しています。たとえば、タスクが開始されると、そのタスクを取り消すことができます。その後、ユーザーがOracle BPM Worklistにログインして、開始されたタスクの詳細を表示すると、「取消」が、実行可能なアクションのリストに表示されます。
表32-9には、管理者がヘッダーから実行できるすべてのアクションおよびその説明がリストされています。
表32-9 ヘッダー・アクション
| アクション | 説明 |
|---|---|
|
却下 |
管理者はタスクを却下できます。 |
|
承認 |
ユーザーはタスクを承認できます。 |
|
委任 |
管理者は、別のユーザーに、自分の代理として処理するようにタスクを割り当てることができます。 |
|
再割当て |
管理者は、別の管理者にタスクを転送できます。 |
|
一時停止 |
管理者は、タスクを一時停止して、後で操作できます。 |
|
再開 |
管理者は、一時停止していたタスクを再開できます。 |
|
取消 |
管理者は、開始したタスクを取り消すことができます。 |
|
エスカレート |
管理者は、スーパーバイザにタスクをエスカレートできます。 |
|
削除 |
管理者はタスクを削除できます。すべてのTo Doタスクに対して表示されます。 |
|
パージ |
管理者はタスクをパージできます。すべてのTo Doタスクに対して表示されます。 |
|
実行 |
管理者は、ドロップダウン・リストで選択したアクションに移動できます。 |
|
保存 |
管理者はタスクを保存できます。 |
図32-52に示すタスク・ペイロード・ビューは、タスク・パラメータの詳細を表示し、それを更新できます。SDOに基づいて設計されたパラメータも、ここで表示できます。汎用パラメータの値が、タスクに渡されたり任意のユーザーによって更新されたものに基づいている場合、SDOベースのパラメータの値は、基礎となるアプリケーションで更新されたとおりに、現在のビジネス・オブジェクトの値を反映します。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスク用のタスク表示フォームの設計」を参照してください。
図32-53に示すタスク履歴ビューは、タスクのライフ・サイクルでのイベントを、グラフまたは表形式で表示します。さらに、デザイナで承認者構成の編集オプションを選択した場合、予定承認者を編集できる表形式表示の特別なコントロールが使用できます。追加されたすべての承認者を手動で削除でき、新規承認者を追加できます。表形式表示に加えられた承認者の変更は、グラフ形式表示に即時に反映されます。タスクが保存されるか、承認または却下などのカスタム・アクションがタスクで実行されると、すべての承認者関連の変更も保存されます。
承認タスクの構成時に、「参加者による将来の参加者の編集を許可」オプションを選択した場合、履歴リージョンには、参加者が将来の参加者のリストを編集できる追加アクションが表示されます。詳細は、32.3.3項「一般的な情報の指定」を参照してください。
図32-54は、「適用」ボタンおよび「リセット」ボタンの追加を示しています。
表32-10は、承認タスクのすべての追加アクションを説明しています。
表32-10 将来の参加者リストの編集アクション
| アクション | 説明 |
|---|---|
|
追加 |
ユーザーが将来の参加者を選択した場合に有効になります。このオプションを選択すると、「参加者の追加」ダイアログが開き、ユーザーは非定型の参加者を挿入できます。 |
|
編集 |
ユーザーが、挿入された非定型の参加者を選択した場合に有効になります。このオプションを選択すると、「参加者の編集」ダイアログが開き、ユーザーは、挿入された参加者の位置を移動できます。 |
|
削除 |
ユーザーが、挿入された非定型の参加者を選択した場合に有効になります。このオプションを選択すると、該当する参加者が削除されます。 |
|
適用 |
将来の参加者リストへの編集を持続します。 |
|
リセット |
将来の参加者からの編集を、システム生成のリストにリセットします。 |
表32-11には、管理者がタスク履歴ビューから実行できるアクションおよびその説明がリストされています。
表32-11 タスク履歴アクション
| アクション | 説明 |
|---|---|
|
タスク・スナップショット |
選択したバージョンのタスク詳細を表示します。 |
|
フル・タスク・アクション |
選択すると、フル・タスク・アクション履歴が表示されます。選択解除すると、アクション履歴のみが表示されます。デフォルトでは、チェック・ボックスは選択解除されています。 |
|
すべての親タスク |
選択すると、サブタスク・ビューの親タスクが表示されます。選択解除すると、サブタスク履歴のみが表示されます。デフォルトでは、チェック・ボックスは選択されています。 |
|
予定承認者の表示 |
選択すると、予定承認者が履歴とともに表示されます。デフォルトでは、チェック・ボックスは選択解除されています。 |
図32-55に示すコメントと添付ファイル・ビューは、タスク・データ・コントロール・ドロップ・ハンドラを使用して、JDeveloperで作成されます。これには、タスクに関するコメントを入力するテキスト入力フィールド、およびサポート・ドキュメントを添付する機能が含まれています。
マップ済属性は、タスクのペイロードから抽出されたデータなど、ユースケース固有のデータを格納するのに使用できる属性です。Oracle BPM Worklistを使用して、サーバー上にマップ済属性ラベルを表示および作成できます。
|
注意: 保護済のフレックスフィールド属性を作成するには、workflow.mapping.protectedFlexfield権限を持っている必要があります。デフォルトの管理ユーザー、weblogicは、この権限を持っています。 |
詳細は、32.3.5項「マップ済属性の指定」を参照してください。
属性ラベルを表示するには:
Oracle BPM Worklistのメイン・ページで、ページの右上隅にある「管理」リンクをクリックします。
「管理」ペインで、「保護フレックス・フィールド」リンクをクリックします。図32-56に示すようなページが表示されます。
ページでは、既存の属性ラベルのリストが表示されます。ドロップダウン・リストから属性タイプを選択して、リストをフィルタ処理できます。特定のラベルをクリックすると、「詳細」パネルで属性が使用するマッピングのリストが表示されます。
属性ラベルを作成するには:
「追加」(+)ボタンをクリックします。図32-57に示すように、「ラベルの作成」ダイアログが表示されます。
ドロップダウン・リストから、属性タイプおよびタスク属性を選択します。
一意のラベル名および説明を入力します。
「作成」をクリックします。ラベルが作成され、タスク・コンポーネントでのマッピングに使用できるようになります。
属性ラベルを削除するには:
属性ラベルを削除するには、まず属性ラベルのリストから属性ラベルを選択します。次に「削除」(-)ボタンをクリックします。
|
注意: 属性ラベルを削除できるのは、いずれのマッピングにも使用されていない場合のみです。 |
あるサーバーに属性ラベルが定義され、それらを別のサーバーに再作成する必要がある場合、ユーザー・メタデータ移行ユーティリティを使用して、ラベルをXMLファイルに定義したサーバーから、保護済の属性ラベルのリストをエクスポートできます。このユーティリティによって、このファイルから新しいサーバーに属性ラベルをデプロイできます。これにより、Oracle BPM Worklistで属性ラベルを手動で再作成する必要がなくなります。詳細は、32.6項「ユーザー・メタデータ移行ユーティリティの使用」を参照してください。
属性ラベルが、Oracle BPM Worklistのタスク・リスト・ページなど、エンド・ユーザーに表示される場合、ラベルの作成時に指定されたラベル名が使用されます。異なる国籍のユーザーがラベルを参照する可能性がある場合、Oracle BPM Worklistユーザーのロケールに適した言語に翻訳されたラベル名を表示できます。WorkflowLabels.propertiesリソース・バンドルを使用して、属性ラベルの翻訳をカスタマイズできます。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・ワークフロー・サービスの概要」の、属性ラベルの国際化に関する項を参照してください。
承認グループは、名前と、特定パターンでタスクを実行するように構成された事前定義のユーザーの集合で構成されます。このパターンは、ヒューマン・ワークフローのルーティング・スリップ・パターンに類似しており、ユーザーがシリアルまたはパラレルでタスクを実行できます。承認グループには、パターンでネストされている承認グループを含めることもできます。
承認グループの名前は、32.3.6.3.1項「承認グループ・リスト・ビルダーをモデリングする方法」で説明されているように、承認グループのリスト・ビルダーを指定する際に必要です。承認グループで構成されたパターンは、タスクを操作する必要があるユーザーを順序付けするためにデフォルトで使用されます。ただし、リスト・ビルダーを作成する際は、投票制度を指定してデフォルトのパターンをオーバーライドできます。
後述の項では、管理者権限を持つユーザーが承認グループを管理できるOracle BPM Worklistユーザー・インタフェースについて説明します。
Oracle BPM Worklistのホーム・ページで、「承認グループ」タブをクリックします。図32-58に示すようなページが表示されます。
この図では、「DisbursementTeam」という承認グループに2人のユーザー「bpalmer」と「rjames」がいることが示されています。これらのユーザーは特定のシーケンス構成でタスクを実行します。
承認グループは、ユーザー名またはグループ名で検索できます。
ユーザー名で検索するには:
左側にあるナビゲーション・ペインで、ドロップダウン・リストから「ユーザー」を選択します。
テキスト入力フィールドに完全なユーザー名を入力します(ユーザー名の一部とアスタリスク(*)を入力してワイルドカード検索を実行することもできます)。
アクション(>)ボタンをクリックします。
図32-59に示すように、左側にあるナビゲーション・ペインに、ユーザーが所属する承認グループのリストが表示されます。
承認グループ名をクリックすると、右側の詳細ペインがそのグループの構造でリフレッシュされます。
グループ名で検索するには:
左側にあるナビゲーション・ペインで、ドロップダウン・リストから「グループ」を選択します。
テキスト入力フィールドに完全なグループ名を入力します(グループ名の一部とアスタリスク(*)を入力してワイルドカード検索を実行することもできます)。
アクション(>)ボタンをクリックします。
図32-59に示すように、左側にあるナビゲーション・ペインに、一致する承認グループがすべてリスト表示されます。
承認グループ名をクリックすると、右側の「詳細」ペインがそのグループの構造でリフレッシュされます。
静的承認グループには、ユーザーまたは他の承認グループをメンバーとして追加できます。次の手順では、承認グループに新しいユーザー・メンバーを追加する方法を説明します。
図32-62に示したページで、「追加」(+)アイコンをクリックします。
その他のアイコンは、承認シーケンスでのメンバーの編集、削除、並替えに使用します。
図32-63に示すように、「グループに追加」ポップアップ・ダイアログが表示されます。
「ユーザー」を選択します。
次のいずれかのオプションを使用してユーザーを選択します。
完全なユーザー名を入力して「OK」をクリックします。
ダイアログが閉じ、「詳細」ペインの「メンバー」セクションに新しいメンバーが表示されます。
虫眼鏡アイコンをクリックしてユーザーを検索します。
図32-64に示すように、虫眼鏡アイコンをクリックすると、「認証ブラウザ」ポップアップ・ダイアログが表示されます。
ドロップダウン・リストから「ユーザー」を選択します。
テキスト入力フィールドに完全名を入力して「検索」をクリックします(ユーザー名の一部とアスタリスク(*)を入力してワイルドカード検索を実行することもできます)。
図32-65に示すように、「認証ブラウザ」ダイアログがリフレッシュされ、検索結果が表示されます。
リストからユーザーを選択します。
選択したユーザーの詳細が、ダイアログの「詳細」セクションに表示されます。
「OK」をクリックします。
「OK」を再度クリックして、「グループに追加」ダイアログを閉じます。
図32-66に示すように、「詳細」ペインの「メンバー」セクションで、選択したユーザーを表すノードが承認グループ構造に表示されます。
この手順を繰り返せば、承認グループにさらにメンバーを追加できます。メンバー追加後の承認グループ構造は、図32-67のようになります。
次の手順では、承認グループからメンバーを削除する方法を説明します。
承認グループ構造から、目的のメンバー・ノードを選択します。
「削除」アイコンをクリックします。
承認グループ構造がリフレッシュされ、メンバー・ノードが削除されます。
次の手順では、承認グループの並び順を変更する方法を説明します。
移動するメンバー・ノードを選択します。
「メンバーのプッシュ・アップ」(^)アイコンと「メンバーのプッシュ・ダウン」(v)アイコンを使用して、メンバーを目的の位置に移動します。
次の手順では、承認グループの名前を変更する方法を説明します。
承認グループの新しい名前を「名前」フィールドに入力します。
「適用」をクリックします。
名前の変更は、この承認グループがネストされている他の承認グループにも反映されます。
動的承認グループを使用すると、ランタイムにカスタムJavaクラスを通じて承認グループを作成できます。これには、次の手順が必要です。
開発者が、カスタム実装に必要なカスタムの動的承認グループ・クラスを記述します
IT部門が、ワークリスト・アプリケーションのUIを使用して、カスタムの動的承認グループを登録します
SOAクラス・パスの一部であり世界的に有名なディレクトリに、クラス・ファイルを公開します
動的承認グループを定義するには、カスタマは、インタフェース・ファイルIDynamicApprovalGroup.java(AMXによって、パッケージoracle.bpel.services.workflow.task内に動的承認グループとして定義されています)を使用して実装クラスを定義する必要があります。これには、承認グループのメンバーを取得するパブリック・メソッドが1つだけ含まれています。入力パラメータはTaskオブジェクトのみです。主キー・リストは、task/systemAttributes/collectionTargetタスクによって取得できます。
例32-6 実装クラス
************** IDynamicApprovalGroup.java ******************
public interface IDynamicApprovalGroup {
/**
* Get members of this dynamic approval group
* @param task Property bag containing information required to generate
the approver list
* @return list of IApprovalListMember including sequence, member, member_
type; null for empty group
* The primary key list can be obtained from task:
task/systemAttributes/collectionTarget
*/
public List getMembers(Task task )
throws WorkflowException;
}
**********************************************************
図32-72は、動的承認グループ・クラスのサンプルを示したコード・スニペットです。
SOAクラス・パスの一部であり世界的に有名なディレクトリにクラス・ファイルを公開するには、クラス・ファイルを次のWebLogic Serverディレクトリに配置する必要があります。
$BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes
たとえば、oracle.apps.DynamicAGというJavaクラスの場合、パスは$BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes/oracle/apps/DynamicAG.classとなります。クラス・ファイルをこのパスに配置してからWebLogic Serverを再起動してください。
次の手順では、承認グループを削除する方法を説明します。
左側にあるナビゲーション・ペインで、削除する承認グループを選択します。
図32-75に示すように、「削除」(-)ボタンをクリックします。
確認ダイアログが表示されます。
「OK」をクリックします。
承認グループが削除されます。
|
注意: 削除した承認グループが他の承認グループにネストされている場合、親グループからも削除されます。 |
Oracle BPM Worklistのタスク構成を使用すると、ビジネス・ユーザーと管理者は、ワークフロー設計者がデフォルトとして構成したルールを参照できます。この事前定義済ルールを変更することで、承認フローをいつでも特定の顧客向けに、適用可能な顧客企業ポリシーに基づいてカスタマイズできます。
たとえば、金額が1000ドルを超える支出については2レベルの承認を必要とする企業ポリシーがあり、このポリシーの承認を3レベルに変更する場合、顧客はこのWebベース・アプリケーションを使用してルールを変更できます。基礎となるプロセスのルールを変更してから再デプロイするという手順をIT部門に依頼する必要はありません。ルールの変更は次のインスタンスから適用され、進行中のインスタンスでは現在のルール定義が使用されます。
タスク構成を使用すると、承認フローに関連付けられているイベント駆動ルールとデータ駆動ルールを、ワークフローのデプロイ時であるランタイムに編集できます。アプリケーションの「管理」セクションのメインの「タスク構成」タブをクリックすると、「イベント駆動」タブおよび「データ駆動」タブにアクセスできます。図32-76に示すような画面が表示されます。
左側の「設定するタスク」パネルには、承認フロー・ルールを使用するように構成されているすべてのワークフロー・タスクがリストされます。検索機能もあります。表示モードのときは、承認フローのリスト・ビルダー構成をオーバーライドするデフォルトの構成とルールが右側のパネルに表示されます。ルール構成は、承認フローで定義されているステージに則して表示されます。
この項では、イベント駆動の設定、つまりタスク・メタデータについて説明します。
図32-77は、イベント駆動のタスク構成ページを示しています。
次の手順を使用して、イベント駆動設定を編集します。
「タスク構成」タブで、「イベント駆動」タブをクリックします。
「設定するタスク」ペインでタスクを選択します。「編集」(鉛筆)アイコンをクリックします。
図32-78に示すように、メイン・ページが編集モードに変わります。
必要な変更を行い、「適用」をクリックして変更を保存します。
「デプロイ」をクリックして変更をデプロイします。
|
警告: リスト作成ルール・セット内のルール定義が不適切または不完全な場合は、実行時エラーの原因になることがあります。次の場合にエラーが発生します。
すべての条件を処理するよう、ルールを正しく定義してください。 |
「イベント駆動」タブには、ヒューマン・タスク・エディタで使用できるいくつかのルーティング・オプションがあります。
図32-79に示すように、承認集計の要件として、次のいずれかを指定できます。
なし
タスクごとに1回
ステージごとに1回
Oracle BPM Worklistにおける有効期限とエスカレーションのポリシーの定義は、ヒューマン・タスク・エディタでの定義方法とほぼ同じです。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の章で、タスクをエスカレート、期限更新または終了する方法に関する項を参照してください。
|
注意: 有効期限を0日0時間0分に設定すると、タスクはデプロイした直後に期限切れになります。 |
Oracle BPM Worklistにおけるタスクの通知設定の作成または更新は、ヒューマン・タスク・エディタでの作成または更新方法とほぼ同じです。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・タスクの設計」の章で、参加者の通知プリファレンスの指定方法に関する項を参照してください。
アクセス・ルール設定を設定すると、ユーザーが実行できるアクションを制御できます。設定方法は、ヒューマン・タスク・エディタでの設定方法とほぼ同じです。コンテンツおよびアクションの権限は、作成者(イニシエータ)、所有者、割当て先、レビューアなどユーザーの論理上のロールに基づいて指定できます。
詳細は、32.3.9.2項「セキュリティ・アクセス・ルールを定義する方法」を参照してください。
データ駆動の設定、つまりルールまたは条件を編集するには、次の手順を使用します。
「タスク構成」タブで、「データ駆動」タブをクリックします。
「設定するタスク」ペインでタスクを選択します。「編集」(鉛筆)アイコンをクリックします。
ルール名を更新します。
このルール名は、履歴グラフにルールの根拠として表示されます。リソース・バンドルを定義した場合、ルール名はリソース・バンドルの取得に使用され、翻訳済テキストが表示されます。
次のいずれかの操作を実行します。
追加
更新
削除
アサーションの変更(アサーションはルールの構成対象となったリスト・ビルダーのタイプによって異なります)
変数の追加
必要な変更を行った後で、「適用」をクリックします。
変更は、ルール・ディクショナリのルール定義に保存されます。
「デプロイ」をクリックして変更をデプロイします。
32.5.4.2.1項「変数の追加方法」および32.5.4.2.2項「条件の定義方法」では、追加の編集タスクについて説明しています。
変数を追加するには、次の手順を使用します。
「変数の追加」をクリックします。
図32-85に示すように、「変数の追加」ウィンドウが表示されます。
変数の名前を入力します。
下矢印をクリックして、ドロップダウン・リストから変数タイプを選択します。
リストに表示されるタイプは、ルール・ディクショナリで使用可能なタイプに対応しています(ビルトイン・タイプまたは登録されたタイプ)。
値を入力します。
「OK」をクリックします。
これで、変数を使用して条件を定義できるようになりました。
条件の左辺と右辺は、条件ブラウザからオペランドを選択して設定できます。虫眼鏡アイコンをクリックすると条件ブラウザが表示されます。図32-86は、左辺の条件ブラウザを示しています。
条件のオペランドを比較する演算子は、条件の左辺で選択したオペランドのタイプに応じて変わります。図32-87は、右辺の条件ブラウザを示しています。
式ビルダーを使用すると、さらに複雑な条件を定義することもできます。
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』で、ADFデータ・バインディングのEL式の作成に関する項を参照してください。また、Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイドの、EL式の作成に関する項も参照してください。
Oracle BPM Worklistのタスク・リスト・リージョンは、埋込みのアプリケーションでのタスク・リストの表示に使用する、スタンドアロンで再利用可能なコンポーネントとして使用できます。これは、埋込みのアプリケーションに含めることができるADFライブラリとして提供されます。
図32-88は、タスク・リスト・リージョンを示しています。
タスク・リスト・リージョンはポートレットとして公開され、他のアプリケーションに埋め込むことができます。
コンシューマ・アプリケーションは、JDeveloperを使用して開発されます。タスク・リスト・ポートレットは、コンシューマ・アプリケーションのページに埋め込まれます。ランタイムに、コンシューマ・アプリケーションに渡されたログイン資格証明は、WSRPプロデューサに伝播され、ポートレット・コンテンツはこのページに表示されます。スタンドアロンのタスク・リスト・ポートレットは、WLS PORTLETサーバーにデプロイされます。このサーバーはワークフロー・サービスのリモートのWLS SOAサーバーに接続します。ポートレット・サーバー上のデプロイメント用に、独立したポートレットearが指定されます。
すべてのコンシューマは、ポートレット・プロデューサ(WLSポートレット・サーバー)への登録後にタスク・リスト・ポートレットを使用できます。
タスク・リスト・リージョンをアプリケーションに埋め込むには:
タスク・リストADFライブラリのadflibTaskListTaskFlow.jarファイルがクラス・パスに存在している必要があります。このjarは、JDeveloperのOracle BPM Worklistコンポーネント・ライブラリ内にあります。
JDeveoloperで、新しいアプリケーションを作成し、名前を指定します(TaskListTaskFlowSampleなど)。
adflibTaskListTaskFlow.jarタスク・フローをプロジェクトのクラス・パスに追加します。
「ライブラリとクラスパス」の次のライブラリを、クラス・パスに追加します。
Oracle BPM Worklistコンポーネント
BPMワークフロー
WSRPコンテナ
非SOAサーバー上でアプリケーションを実行する場合、32.5.5.1.1項「リモートの非SOAサーバー上のヒューマン・タスク詳細ページをデプロイする方法」に示す手順を実行します。それ以外の場合、ステップ5に進みます。
.jspxページを作成します。「testSample.jspx」などの名前を付けることができます。
コンポーネント・パレットからadflibTaskListFlow.jarを選択し、Tasklist-flow-definitionを.jspxページにリージョンとしてドラッグします。
「タスク・フロー・バインディングの編集」ダイアログが表示されます。
例32-7は、testSamplePagedef.xmlに作成されたコードを示しています。
例32-7 testSamplePagedef.xmlのコード
<taskFlow id="taskListtaskflowdefinition1"
taskFlowId="/WEB-INF/taskList-task-flow-definition.xml
#taskList-task-flow-definition"
xmlns="http://xmlns.oracle.com/adf/controller/binding">
<parameters>
<parameter id="federatedMode" value="true"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
<parameter id="showServerColumn" value="true"
xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
</parameters>
</taskFlow>
次の共有ライブラリをweblogic-application.xmlに追加します。
<library-ref>
<library-name>oracle.soa.workflow</library-name>
</library-ref>
|
注意: oracle.soa.workflow.wcがサーバーにインストールされている場合、このライブラリを適切に追加します。 |
「WARデプロイメント・プロファイルのプロパティの編集」ダイアログで、次を選択します。
adflibTaskListTaskFlow.jar
adflibWorklistComponents.jar
wsrp-container.jar.
図32-90に示すように、「レベル」メニューで、「保護」→「ADFセキュリティの構成」を選択して、アプリケーションを保護します。
「ADFセキュリティの構成」ダイアログで、次のことを行います:
「ADF認証」を選択します。
「HTTP Basic認証」を選択します。
「終了」をクリックします。
タスク・フローをフェデレーテッド・モードで使用している場合、追加で実行する必要がある手順の詳細は、32.5.5.1.2項「タスク・フローをフェデレーテッド・モードで使用する方法」を参照してください。それ以外の場合、ステップ12に進みます。
EARデプロイメント・プロファイルを作成し、earを作成してデプロイします。
次のURLに移動します。 http://server:port/TaskListTaskFlowSample-ViewController-context-root/faces/testSample.jspx。
表示されるポップアップ・ダイアログから、任意のユーザーでログインします。そのユーザーのタスク・リストが表示されます。
ドロップダウン・リストには、使用可能なすべてのサーバーが含まれています。サーバーの組合せを選択すると、それらのサーバーに属するすべてのタスクを表示するタスク・リストがリフレッシュされます。
showServerColumnをtrueとして渡した場合、タスクが属するサーバーを示すサーバー列がタスクに表示されます。
任意のタスク・タイトルをクリックして、タスクの詳細を含むダイアログを表示します。
非SOAサーバー上でアプリケーションを実行する場合、次の手順を実行する必要があります。
非SOAサーバーでデプロイするには:
oracle.soa.workflow共有ライブラリを非SOA WLSサーバーにデプロイします。次のように実行します。
http://remote_hostname:remote_port/コンソールにナビゲートします。remote_hostnameおよびremote_portは、リモートの非SOA WLSサーバーのホスト名およびポートです。
「デプロイメント」リンクをクリックし、「インストール」をクリックします。
「パス」フィールドに次の値が指定されていることを確認します。$ADE_VIEW_ROOTが実際のディレクトリに置き換えられていることを確認します。次に例を示します。
$ADE_VIEW_ROOT/fmwtools/fmwtools_home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1。
oracle.soa.workflow.jarを選択します。
「終了」をクリックします。
oracle.soa.workflow(11.1.1,11.1.1)ライブラリがアクティブな状態であることを確認します。
非SOA WLSサーバーに外部JNDIを定義します。次のように実行します。
http://remote_hostname:remote_port/コンソールにナビゲートします。remote_hostnameおよびremote_portは、リモートの非SOA WLSサーバーのホスト名およびポートです。
「ドメイン構造」→「サービス」→「外部JNDIプロバイダ」にナビゲートします。
「新規」をクリックします。
名前をForeignJNDIProvider-SOAと入力します。
「OK」をクリックします。
「ForeignJNDIProvider-SOA」リンクをクリックします。
soa_hostnameおよびsoa_portをSOA WLSサーバーのホスト名およびポートに置き換えます。
次の値を入力します。
- 初期コンテキスト・ファクトリ: weblogic.jndi.WLInitialContextFactory
- プロバイダURL: t3://soa_hostname:soa_port/soa-infra
- ユーザー: weblogic
- パスワード: weblogic
|
注意: プロバイダURLは、ドメインではなくsoa-infraアプリケーションを参照しています。「soa-infra」を「soa」に変更しないでください。 |
「保存」をクリックします。
非SOA WLSサーバーにJNDIリンクを定義します。次のように実行します。
http://remote_hostname:remote_port/コンソールにナビゲートします。remote_hostnameおよびremote_portは、リモートの非SOA WLSサーバーのホスト名およびポートです。
「ドメイン構造」→「サービス」→「外部JNDIプロバイダ」にナビゲートします。
ForeignJNDIProvider-SOAをクリックします。
「リンク」タブを選択し、「新規」をクリックします。
次の値を入力します。
- 名前: RuntimeConfigService - ローカルJNDI名: RuntimeConfigService - リモートJNDI名: RuntimeConfigService
「OK」をクリックします。
名前、ローカルJNDI名、およびリモートJNDI名に次の値を入力して、手順aからfを繰り返します。
- ejb/bpel/services/workflow/TaskServiceBean- ejb/bpel/services/workflow/TaskMetadataServiceBean- TaskReportServiceBean- TaskEvidenceServiceBean
- TaskQueryService
- UserMetadataService
|
注意: ejb/bpel/services/workflow/TaskServiceBeanおよびejb/bpel/services/workflow/TaskMetadataServiceBeanのみに対して、「ejb/bpel/services/workflow/」を指定します。 |
例32-8に示すように、bpm-services.jarへの権限付与を含めるように、リモートの非SOA WLSサーバー上のsystem-jazn-data.xmlを変更します。ヒューマン・タスクのADFタスク・フローを、統合されたWLSサーバーにデプロイしている場合、$ADE_VIEW_ROOT/system11.1.1.1.32.53.26/DefaultDomain/config/fmwconfigでsystem-jazn-data.xmlファイルを検索できます。
重要: $ADE_VIEW_ROOTが実際のパスに置き換えられていることを確認してください。たとえば、/scratch/skaneshi/view_storage/skaneshi_d7b4/fmwtools/fmwtools_home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jarなどです。
例32-8 bpm-services.jarの権限付与コード
<grant>
<grantee>
<codesource>
<url>file:$ADE_VIEW_ROOT/fmwtools/fmwtools_
home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>VerificationService.createInternalWorkflowContext</name>
</permission>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<name>credstoressp.credstore.BPM-CRYPTO.BPM-CRYPTO</name>
<actions>read,write</actions>
</permission>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
リモートの非SOA WLSサーバーを再起動します。
ヒューマン・タスクの詳細なUIを含んでいるアプリケーションを、リモートの非SOA WLSサーバーにデプロイします。
32.5.5.1項「タスク・リスト・リージョンをアプリケーションに埋め込む方法」のステップ5に戻ります。
タスク・フローをフェデレーテッド・モードで使用している場合、アプリケーションのクラス・パスにwf_client_config.xmlを配置する必要があります。詳細は、32.5.5.2項「タスク・リスト・リージョン・パラメータを使用する方法」を参照してください。
2つのサーバー間のグローバル信頼関係を有効にする必要もあります。これにより、認証済のユーザーが、クライアント構成ファイルに定義されたすべてのフェデレーテッド・サーバーに渡されるようになります。
|
重要: すべてのサーバーを再起動する必要があります。 |
タスク・フローをフェデレーテッド・モードで使用するには:
wf_client_config.xmlに定義されたすべてのサーバーに対して、次の手順を実行します。
WebLogicコンソールにログインします。
「ドメイン構造」で、soainfraドメイン名をクリックします。
「セキュリティ」タブを選択します。
「保存」ボタンの近くにある「詳細」リンクをクリックします。
選択した資格証明パスワードを入力します。
|
注意: このパスワードは、すべてのSOAサーバーに対して使用する必要があります。 |
「保存」をクリックします。
サーバーを再起動します。
32.5.5.1項「タスク・リスト・リージョンをアプリケーションに埋め込む方法」のステップ12に戻ります。
例32-9は、wf_client_config.xmlのコードのサンプルを示しています。
|
注意: サーバーをフェデレーテッド・サーバー・リストに含めない場合、 |
例32-9 wf_client_config.xmlのコードのサンプル
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowServicesClientConfiguration xmlns="http://xmlns.oracle.com/bpel/services/client">
<server name="default" default="true" excludeFromFederatedList="true">
<localClient>
<participateInClientTransaction>false</participateInClientTransaction>
</localClient>
<remoteClient>
<serverURL>t3://sta00048.us.oracle.com:7001</serverURL>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory
</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>
<soapClient>
<rootEndPointURL>http://sta00048.us.oracle.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>
</server>
<server name="ERP">
<soapClient>
<rootEndPointURL>http://sta00147.us.oracle.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>
<remoteClient>
<serverURL>t3://sta00147.us.oracle.com:7001</serverURL>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory
</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>
</server>
<server name="CRM">
<soapClient>
<rootEndPointURL>http://sta00048.us.oracle.com:7001</rootEndPointURL>
<identityPropagation mode="dynamic" type="saml">
<policy-references>
<policy-reference enabled="true" category="security"
uri="oracle/wss10_saml_token_client_policy"/>
</policy-references>
</identityPropagation>
</soapClient>
<remoteClient>
<serverURL>t3://sta00048.us.oracle.com:7001</serverURL>
<initialContextFactory>weblogic.jndi.WLInitialContextFactory
</initialContextFactory>
<participateInClientTransaction>false</participateInClientTransaction>
</remoteClient>
</server>
</workflowServicesClientConfiguration>
タスク・リスト・リージョン・パラメータは、組み込まれたリージョンの表示動作を制御します。この項では、これらのパラメータについて説明します。
表示パラメータ
federatedMode
このパラメータをtrueと設定して渡す場合は、タスク・リストがフェデレーテッド・モードで表示されます。タスク・フローをフェデレーテッド・モードで実行するには、次のいずれかの方法で、フェデレーテッド・サーバーのリストをタスク・フローに渡す必要があります。
クライアント構成ファイルであるwf_client_config.xml(EARレベルのAPP-INF\classes\wf_client_config.xmlまたはWebアプリケーションのWEB-INF\classes)をクラス・パスに配置します。クライアント構成ファイルには、すべてのフェデレーテッド・サーバーの詳細が含まれています。詳細は、32.5.5.1.2項「タスク・フローをフェデレーテッド・モードで使用する方法」を参照してください。
フェデレーテッド・サーバー・リストを格納したJAXBオブジェクトを作成します。このJAXBオブジェクトは、federatedServersパラメータを使用してタスク・フローに渡すことができます。JAXBオブジェクトの作成方法の詳細は、このパラメータの詳細を参照してください。
federatedServers
このパラメータは、タスク・フローをフェデレーテッド・モードで実行した場合にサーバーのリストを表示します。次に示すコードを使用してJAXBオブジェクト(WorkflowServicesClientConfigurationType)を作成し、パラメータとしてタスク・フローに渡します。コードに太字で示したように、サーバーの1つがデフォルトとして設定されていることを確認します。
デフォルトのサーバーを使用するのは、複数のサーバーがwf_client_config.xmlまたはJAXBオブジェクトに定義されている場合です。ただし、ワークフロー・クライアントに対しては、1つのサーバーを使用することをお薦めします。サーバー名をパラメータとして取得しないレガシーAPIがいくつかあります。これらのAPIをサポートするには、1つのサーバーをデフォルト・サーバーとして定義する必要があります(そうしないと、これらのAPIは動作しません)。
例32-10 単一サーバーの定義
import oracle.bpel.services.workflow.client.config.IdentityPropagationType; import oracle.bpel.services.workflow.client.config.PolicyReferenceType; import oracle.bpel.services.workflow.client.config.PolicyReferencesType; import oracle.bpel.services.workflow.client.config.RemoteClientType; import oracle.bpel.services.workflow.client.config.ServerType; import oracle.bpel.services.workflow.client.config.SoapClientType; import oracle.bpel.services.workflow.client.config. WorkflowServicesClientConfigurationType; WorkflowServicesClientConfigurationType wscct = new WorkflowServicesClientConfigurationType(); List<ServerType> servers = wscct.getServer(); /**** Setting default server in the list ****/ ServerType defaultServer= new ServerType(); servers.add(defaultServer); defaultServer.setDefault(true); defaultServer.setExcludeFromFederatedList(true); defaultServer.setName("default"); RemoteClientType rct = new RemoteClientType(); rct.setServerURL("t3://sta00048.us.oracle.com:7001"); rct.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory"); rct.setParticipateInClientTransaction(false); server.setRemoteClient(rct); SoapClientType sct = new SoapClientType(); PolicyReferencesType prts = new PolicyReferencesType(); PolicyReferenceType prt = new PolicyReferenceType(); prt.setEnabled(true); prt.setCategory("security"); prt.setUri("oracle/wss10_saml_token_client_policy"); prts.getPolicyReference().add(prt); IdentityPropagationType ipt = new IdentityPropagationType(); ipt.setMode("dynamic"); ipt.setType("saml"); ipt.setPolicyReferences(prts); sct.setRootEndPointURL("http://sta00048.us.oracle.com:7001"); sct.setIdentityPropagation(ipt); defaultServer.setSoapClient(sct); /****** Setting Federated Server 1 to the list ****/ ServerType server1 = new ServerType(); servers.add(server1); server1.setName("Human Resource"); RemoteClientType rct1 = new RemoteClientType(); rct1.setServerURL("t3://stadl28.us.oracle.com:7001"); rct1.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory"); rct1.setParticipateInClientTransaction(false); server1.setRemoteClient(rct1); SoapClientType sct1 = new SoapClientType(); PolicyReferencesType prts1 = new PolicyReferencesType(); PolicyReferenceType prt1 = new PolicyReferenceType(); prt1.setEnabled(true); prt1.setCategory("security"); prt1.setUri("oracle/wss10_saml_token_client_policy"); prts1.getPolicyReference().add(prt1); IdentityPropagationType ipt1 = new IdentityPropagationType(); ipt1.setMode("dynamic"); ipt1.setType("saml"); ipt1.setPolicyReferences(prts1); sct1.setRootEndPointURL("http://stadl28.us.oracle.com:7001"); sct1.setIdentityPropagation(ipt1); server1.setSoapClient(sct1); /****** Setting Federated Server 2 to the list ****/ ServerType server2 = new ServerType(); servers.add(server2); server2.setName("Financials"); RemoteClientType rct2 = new RemoteClientType(); rct2.setServerURL("t3://sta00048.us.oracle.com:7001"); rct2.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory"); rct2.setParticipateInClientTransaction(false); server2.setRemoteClient(rct2); SoapClientType sct2 = new SoapClientType(); PolicyReferencesType prts2 = new PolicyReferencesType(); PolicyReferenceType prt2 = new PolicyReferenceType(); prt2.setEnabled(true); prt2.setCategory("security"); prt2.setUri("oracle/wss10_saml_token_client_policy"); prts2.getPolicyReference().add(prt2); IdentityPropagationType ipt2 = new IdentityPropagationType(); ipt2.setMode("dynamic"); ipt2.setType("saml"); ipt2.setPolicyReferences(prts2); sct2.setRootEndPointURL("http://sta00048.us.oracle.com:7001"); sct2.setIdentityPropagation(ipt2); server2.setSoapClient(sct2);
showServerColumn
タスク・フローをフェデレーテッド・モードで実行した場合、デフォルトでタスク・リストにサーバー列が表示されません。サーバー列を表示するには、このパラメータをtrueで渡す必要があります。
wfCtxID
ワークフロー・コンテキスト・トークン文字列で、タスク・フロー内にワークフロー・コンテキストを作成するときに使用します。アプリケーションのシングル・サインオンが有効である場合やADFセキュリティで保護されている場合にはこのパラメータは不要です。ワークフロー・コンテキストを次に示します。
showViewsPanel
ビュー・パネルは、trueで渡された場合のみ表示されます。デフォルトでは、これは表示されません。
showTaskDetailsPanel
タスク詳細パネルは、trueで渡された場合のみ表示されます。デフォルトでは、これは表示されません。
refreshURL
この文字列を使用すると、タスク・リスト・リージョンのタスク詳細をインライン・フレームに表示できます。タスク詳細ページでアクションが実行されると、そのアクションによって、タスクのフロー/ポートレットが含まれるページURLを持つタスク・リスト領域がリフレッシュされます。
タスク・フローはコンテナ・ページのURLを認識しないため、URLをパラメータで渡す必要があります。リクエスト・オブジェクトのgetRequestURL()メソッドを呼び出して、パラメータを取得します。リクエスト・オブジェクトのgetRequestURL()メソッドを呼び出すか、次のフォーマットでURLを渡すことによって、完全なURLを渡すことができます。
/context-root/faces/page-name For example: /FederatedWorklist/faces/test.jspx
localeSource
ロケール・ソースを渡す文字列パラメータ。ブラウザ(BROWSER)またはアイデンティティ・コンテキスト(IDENTITY)から指定できます
showActionDropdown
アクション・ドロップダウンは、falseで渡された場合のみ表示されません。デフォルトでは、これは表示されます。
showViewFilter
ビュー・フィルタ・ドロップダウンは、falseで渡された場合のみ表示されません。デフォルトでは、これは表示されます。
showCreateTODOTaskAction
アクション・メニューにTODOアクションを表示するかどうかを指定します。TODOアクションを非表示にするには、このパラメータをfalseに設定します。デフォルトでは、アクション・メニューにTODOアクションが含まれます。
showAssignmentFilter
割当てフィルタ・ドロップダウンは、falseで渡された場合のみ表示されません。デフォルトでは、これは表示されます。
showStatusFilter
ステータス・フィルタ・ドロップダウンは、falseで渡された場合のみ表示されません。デフォルトでは、これは表示されます。
showSearchControl
検索ボックスは、falseで渡された場合のみ表示されません。デフォルトでは、これは表示されます。
displayColumnsList
この文字列のカンマ区切りのリストを使用すると、指定した順序で、列のリストをリージョンに表示できます。
sortColumn
この文字列は、デフォルトでリージョンのタスクをソートするのに使用する列の名前を指定します。
sortOrder
この文字列は、ソート・タスクのソート順を昇順(ASC)または降順(DESC)で指定します。
フィルタ・パラメータ
assignmentFilter
この文字列は、タスクの割当てフィルタの選択内容として使用する値を指定します。設定しない場合、値はデフォルトのMyおよびGroupになります。詳細は、32.5.5.2.1項「割当てフィルタの制約の使用」を参照してください。
viewFilter
この文字列は、タスクをフィルタ処理するビュー名の選択内容として使用する値を指定します。設定しない場合、値はデフォルトのInboxになります。
taskTypesFilterList
表示するタスクをフィルタ処理するのに使用される、タスク・タイプのカンマ区切りのリストを指定する文字列パラメータ。
attributesFilterOperator
属性フィルタ・リストに指定されたフィールドの述語結合基準として使用する演算子(and/or)を指定する文字列
attributesFilterList
属性値に基づいてタスクをフィルタ処理するのに使用される、名前と値のペアのカンマ区切りのリストを指定する文字列パラメータ。(名前はタスクの列名、値は列の値です。)
例
属性フィルタ値がpriority = 1、status = ASSIGNED、推進されたフレックスフィールドがtextAttribute1 = NorthAmericaのタスクを参照する場合、値を次のように設定します。
attributeFilterList: priority=1, status=ASSIGNED, textAttribute1=NorthAmerica
属性フィルタ演算子は、次のようになります。
attributeFilterOperator: and
次に、割当てフィルタの制約を示します。
マイ
グループ
マイ+グループ
報告先
作成者
所有者
レビューア
前
管理者
次に、displayColumnListパラメータで渡すことができる列定数を示します。定数値は、渡す必要がある値です。たとえば、TITLE_COLUMN = "title"では、"TITLE_COLUMN"ではなく"title"を渡す必要があります。
プライマリ列制約
その他の列制約
履歴コンポーネントは、開始されたタスクおよび開始前のタスクの過去および将来の参加者をレンダリングするのに使用するADFの宣言UIコンポーネントです。このコンポーネントは将来の参加者を編集でき、ADFページに組み込むことができます。パラメータは次のとおりです。
タスク・オブジェクト
ワークフロー・サービス・クライアント
ワークフロー・コンテキスト
showTabularView
showGraphicalView
最初の3つのパラメータのいずれかがnullで渡される場合、またはタスク・オブジェクトの相関IDがnullの場合、コンポーネントには承認リストが表示されません。かわりに、承認リストの表示の失敗に関する考えられる原因を説明するメッセージが表示されます。最後の2つのパラメータは、表またはグラフ形式のビューを表示するかどうかを示すのに使用されます。デフォルトでは、表およびグラフ形式のビューは両方とも表示されます。値trueまたはfalseは、最後の2つのパラメータに渡すことができます。
ユーザー・メタデータ移行ユーティリティhwfMigratorは、シェル・スクリプトを実行してSOAサーバー間でワークフローのユーザー構成可能データを移行するプロセスを自動化するツールです。
ユーザー・メタデータ移行ユーティリティの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のテスト環境から本番環境へヒューマン・ワークフロー・データの移動に関する説明を参照してください。
