| Oracle BPEL Process Manager開発者ガイド 10g（10.1.3.1.0） B31874-03 |
|
 戻る |
 次へ |
企業のビジネス・プロセスでは、そのプロセスに参加するシステムと従業員の統合が促進されます。ビジネス・プロセスとその関連システムには、ライフ・サイクルと特定の動作があります。ビジネス・プロセスに参加するユーザーには、ビジネス・プロセスでタスクを実行するためのロールと権限が付与されます。Oracle BPEL Process Managerのワークフロー・サービスを使用すると、システムおよびサービスをヒューマン・ワークフローと統合して単一のエンドツーエンド・プロセス・フローに取り込みながら、可視性を利用して様々なレベルで例外処理や最適化を有効にできます。
この章の内容は次のとおりです。
|
関連項目: |
リリース10.1.2の「ワークフロー・ウィザード」で設計したワークフローを、リリース10.1.3.1.0でデプロイして実行できます。ただし、これらのタスクにアクセスするには古いワークリストのURLを使用する必要があります。
http://localhost:9700/integration/oldworklistapp/Login
リリース10.1.3.1.0では、「ワークフロー・ウィザード」がヒューマン・タスク・エディタで置き換えられています。このエディタを使用すると、タスク設定（タスクの結果、ペイロード構造、タスク参加者、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できます。
リリース10.1.2ベースのワークフローは、ヒューマン・タスク・エディタでは編集できません。リリース10.1.3.1.0の新機能を使用するには、新規ワークフロー・メタデータを使用するように、ワークフローのタスク・スコープを手動で移行する必要があります。
また、これはリリース10.1.2で設計したワークフローをデプロイできる最終リリースであることに注意してください。
ワークフロー・サービスの使用により、ユーザーの操作とシステムやサービスの接続関係とを組み合せ、エンドツーエンドのプロセス・フローに割り込ませることができます。図15-1に示すとおり、ワークフロー・サービスは他のWebサービスと同様、WSDL規約を通じてBPELプロセスにリンクしています。このプロセスは、タスクをユーザーまたはロールに割り当て、レスポンスを待機します。ユーザーは、Oracle BPEL Worklistアプリケーションを使用してタスクを操作します。
ワークフロー・サービスで使用される用語は、次のとおりです。
通知: ユーザーにタスクが割り当てられたとき、またはタスクのステータスが変化したときに送信される電子メール、ボイス、FAX、ポケットベルまたはショート・メッセージ・サービス（SMS）メッセージ
ワークリスト: ユーザーに割り当てられているか、ユーザーが関心を持っているタスク（作業項目）を列挙したリスト
ヒューマン・タスク・エディタ: タスク設定（タスクの結果、ペイロード構造、タスク参加者、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できるツール
ルーティング・スリップ: フロー・パターン（ワークフロー、割当て先、エスカレーション・ポリシー、有効期限、シグネチャ・ポリシー、参加者がタスクで対話する順序など）に関する情報を格納
作業キュー
標準作業キュー: 高優先度のタスク、期日の近いタスク、新規タスクなど。
カスタム作業キュー: ユーザーは特定の検索基準に基づいて新規の作業キューを定義できます。
プロキシ作業キュー: 選択した作業キューへのアクセス権限を他のユーザーに付与できます。権限を付与されたユーザーは、そのタスクをかわりに操作できます。
ユーザー・ルール: カスタムの委任ルール、自動承認ルールまたは休暇ルールを定義できます。
グループ・ルール: ロールまたはグループに関する自動割当てルール（ラウンド・ロビン、最もビジーでない箇所など）を定義できます。
タスクの割当ておよびルーティング: ビジネス・プロセスからのタスクの作成と、ユーザーまたはロールへのタスクの割当てを含みます。その他のタスクの割当ておよびルーティング機能は、次のとおりです。
参加者タイプ: 単一の承認者、グループ投票、管理チェーン、承認者の順序リスト、FYI割当て先および外部ルーティング・サービス
アイデンティティ・サービス: バックエンドのID管理システムと対話して、Java AuthoriZatioN（JAZN）およびLDAPからすべてのユーザー情報を取得します。アイデンティティ・サービスにより、ロールベースのアクセス制御が提供されます。ロールに権限を割り当て、組織階層を認可用のロール・モデルにリンクできます。次のことも実行できます。
ユーザー、ロールまたはグループへのワークリスト権限の割当て
名前、場所、電話番号、FAX番号、電子メールなどのユーザー・プロパティの管理
組織階層（レポート構造）およびグループ情報の取得
ユーザーおよびロール・プロビジョニング用の標準的なディレクトリ・サービス（LDAPベースのディレクトリなど）との統合
|
関連項目:
|
指定したタスクの変更通知を指定したユーザーに送信
様々な配信チャネル（電子メール、電話、FAX、ボイスおよびSMS）を介して通知
各種タスクにあわせて通知のコンテンツをカスタマイズ可能
電子メールを介したタスクに対するアクションの実行
完全にカスタマイズ可能なワークリスト
様々なユーザー・プロファイルのサポート: エンド・ユーザー、監督者、タスク所有者、グループ所有者、管理者
ワークリスト内のタスクに対して認可されたアクションを実行するためのユーザー権限またはロール権限に基づくタスクの表示
様々な基準に基づいてワークリスト・ビューでタスクをフィルタ可能
共有タスクを獲得およびチェックアウト可能
カスタム作業キューのサポート
カスタムの休暇ルールと委任ルールの定義
選択したワークリスト・ビューへのアクセス権限を他のユーザーに付与（プロキシ・サポート）
完全なワークフロー履歴と監査証跡
組込みの生産性レポート
ワークフロー・サービスの機能は、図15-2のような、リクエストされた品目の注文を承認または却下するための単純な注文書承認ビジネス・プロセスを使用して説明できます。承認および却下は、最初の承認者と最初の承認者のマネージャに関係する2ステップ・プロセスです。注文は、最初に監督者ロールに割り当てられます。監督者ロールに属しているユーザーにより注文が承認されると、最終承認のためにそのユーザーのマネージャに送信されます。
図15-3は、次のワークフロー・サービス・コンポーネントを示しています。
タスク・サービスにより、タスク状態の管理およびタスクの永続性が可能になります。これらのサービスに加え、タスク・サービスでは、タスクの更新、完了、エスカレート、再割当てなどの操作が公開されます。タスク・サービスは、ユーザーに割り当てられているタスクを取得するためにOracle BPEL Worklistアプリケーションで使用されます。また、このサービスでは、タスク状態が変化したときにユーザーやグループに通知を送信するかどうかも決定されます。タスク・サービスは、次のサービスで構成されます。
アイデンティティ・サービスは、Oracle Application Server 10gのセキュリティ・インフラストラクチャまたはカスタム・ユーザー・リポジトリの上部に位置するWebサービスのシン・レイヤーです。このサービスにより、ユーザーの認証および認可と、ユーザー・プロパティ、ロール、グループ・メンバーシップ、権限のルックアップが可能になります。
通知サービスは、電子メール、電話ボイス・メッセージ、ポケットベル、FAXおよびSMSのいずれかのチャネルを通じて、指定のユーザーに対して特定のコンテンツを含む通知を配信します。詳細は、「ワークフロー・サービスからの通知」を参照してください。
ユーザー・メタデータ・サービスにより、ワークフロー・ユーザー関連のメタデータ（ユーザー作業キュー、プリファレンス、休暇および委任ルールなど）が管理されます。
ランタイム構成サービスは、タスク・サービスのランタイム環境で使用されるメタデータの管理方法を提供します。主に、タスク・ペイロード・フレックス・フィールド・マッピングの管理をサポートします。
図15-4は、サービスとビジネス・プロセス間の相互作用を示しています。
ワークフロー・サービスの使用方法は、VacationRequest、AutoLoanDemo、ExpenseRequestApproval、LoanDemoPlus、DocumentReview、HelpDeskServiceRequestおよびOrderApprovalの各デモで具体的に示されます。
次の各項では、ワークフロー・サービスの複数のユースケースについて説明します。
休暇申請プロセスは、ユーザーから休暇の詳細を取得し、承認担当のマネージャにその申請をルーティングすることから開始されます。ユーザー詳細と組織階層は、ユーザー・ディレクトリまたはストアからルックアップできます。図15-5に示すこのシナリオは、OrderApprovalサンプルで説明されています。
タスクは、「グループ投票」、「管理チェーン」または「承認者の順序リスト」参加者タイプの複数のユーザーを介してルーティングできます。たとえば、融資承認フローの一部として融資申請が考えられます。融資申請は、初めに融資エージェント・ロールに割り当てることができます。融資金額が100,000ドルを超えている場合は、特定の融資エージェントが融資を取得して承認した後で、さらに複数の管理レベルにその融資をルーティングさせることが可能です。図15-6に示すこのシナリオは、LoanDemoPlusサンプルで説明されています。
ワークフロー・サービスでサポートされる様々なフロー・タイプの詳細は、「ワークフロー・サービスの参加者タイプ」を参照してください。これらのタイプをビルディング・ブロックとして使用することで、複雑なワークフローを作成できます。
タスク・タイプに基づいて、優先度の高いタスクを特定のユーザーまたはロールに割り当てることができます。ただし、ユーザーが一定期間内にタスクを操作しない場合、そのタスクを期限切れとし、追加アクションのためにマネージャにエスカレートできます。エスカレーションの一環として、電子メール、電話ボイス・メッセージ、SMS、ポケットベルまたはFAXでユーザーに通知することも可能です。同様に、マネージャは、様々なタスク割当て間で負荷を分散するために、ある部下から別の部下にタスクを委任できます。BPELで定義されるすべてのタスクには、関連する有効期限があります。また、図15-7に示すように、エスカレーション・ポリシーまたは期限更新ポリシーを指定する場合もあります。たとえば、HelpDeskServiceRequestプロセスの一部としてサポート・コールが考えられます。優先度の高いタスクを特定のユーザーに割り当て、ユーザーが2日以内に対応しない場合、追加アクションのためにタスクをマネージャにルーティングします。
ユーザーは、自分のかわりに他のユーザーにタスクを実行させるように決定できます。タスクは、Oracle BPEL Worklistアプリケーションから明示的に委任するか、または自動的に委任できます。たとえば、マネージャは、自分が担当する高優先度のタスクを休暇中はすべて自動的に部下の1人にルーティングするという休暇ルールを設定します。タスクをその内容に基づいて別のユーザーにルーティングできる場合もあります。自動ルーティングのもう1つの例は、グループに属する複数のユーザー間でタスクを割り当てることです。たとえば、ヘルプ・デスクの監督者は、西部地域のすべてのタスクをラウンド・ロビン方式で割り当てたり、未処理タスクの最も少ないユーザー（最もビジーでない箇所）にタスクを割り当てるように決定します。
通常は、ユーザーが他のユーザーのワークリストの一部にアクセスできるようにする必要があります。たとえば、役員は経費承認へのアクセス権限を特定の限度内で秘書に付与するように決定します。作業キューを使用すると、カスタム・ビューを作成してワークリスト内のタスクのサブセット（高優先度のタスク、24時間以内に期限があるタスク、経費承認タスクなど）をグループ化できます。これらの作業キューを、タスク所有者を代理できる他のユーザーに付与できます。たとえば、前述のシナリオでは、役員は$5000未満の経費について委任経費承認作業キューを作成できます。
ユーザーは通常、図15-8に示すように、自分に割り当てられたタスクにOracle BPEL Worklistアプリケーションを使用してアクセスします。ワークリストは、ユーザーと、ユーザーが属するグループに割り当てられたタスクで構成されます。タスクには、フォームや添付に加え、履歴、コメント、承認順序などのタスク詳細を含めることが可能です。OracleAS Portalまたはその他のクライアントからワークリストにアクセスして、タスクの操作および生産性レポートの取得を実行できます。Oracle BPEL Worklistアプリケーションは、アプリケーション固有のニーズに基づいてカスタマイズおよび拡張できます。ワークリスト機能とサンプルOracle BPEL Worklistアプリケーションの詳細は、第16章「ワークリスト・アプリケーション」を参照してください。
Oracle BPEL Process Managerには、参加者タイプ（旧リリースでの名称はワークフロー・パターン）のライブラリが用意されています。ビジネス要件を満たす参加者タイプを選択し、その参加者タイプに基づいてワークフローをモデリングできます。Oracle BPEL Process Managerでサポートされる参加者タイプは、次のとおりです。
単一の承認者: 単一のユーザーがタスクを操作する場合に使用します。タスクが複数のユーザーを含むロールまたはグループに割り当てられている場合は、メンバーの1人がタスクを申告して操作する必要があります。そのユーザーのアクションに基づいて、ビジネス・プロセスの内容を定義します。
グループ投票: 並行して作業する複数のユーザーが同時にアクションを実行する（たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する）場合に使用します。結果が有効になるために必要な得票率（多数決や満場一致など）を指定します。
管理チェーン: タスクを承認のために管理チェーン階層内の複数のユーザーにルーティングする場合に使用します。タスク参加者を管理チェーン・リストまたはユーザー・リストとして指定します。
承認者の順序リスト（順序ワークフローの拡張）: ワークフローについて参加者の順序リストを作成する場合に使用します。「管理チェーン」参加者タイプはこのタイプに似ていますが、ユーザーは組織階層に含まれます。「承認者の順序リスト」参加者タイプの場合、任意のユーザー・リストまたはグループ・リストに所属できます。
FYI割当て先: ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYI割当て先がタスクの結果を直接左右することはできませんが、コメントを提供したり添付ファイルを追加できる場合があります。
外部ルーティング・サービス: ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成する場合に使用します。この参加者タイプを指定すると、他の参加者タイプはすべて無視されます。外部ルーティング・サービスは、タスクのルーティングを決定するために実行時に参加者タイプ（単一の承認者、承認者のリスト、グループ投票など）のリストを提供するものとみなされます。
モデリング・プロセスは、ヒューマン・タスクの作成、BPELプロセスとの関連付け、Oracle BPEL Worklistアプリケーションで実行時にヒューマン・タスクの表示に使用する書式の生成から構成されます。この項では、これらのモデリング・タスクの概要について説明し、特定のモデリング手順の参照先を示します。
ヒューマン・タスク・エディタを使用すると、タスクのメタデータを定義できます。このエディタでは、ヒューマン・タスク設定（タスクの結果、ペイロード構造、タスク参加者、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できます。この情報は、メタデータ・タスク構成ファイル（拡張子.task）に保存されます。
ヒューマン・タスク設定を構成する.taskファイルをBPELプロセスに関連付けます。関連付けには、構成対象のBPELプロセスにドラッグ・アンド・ドロップするヒューマン・タスク・アクティビティを使用します。また、タスク定義、タスク起案者、タスク優先度も定義して、入力データを渡すタスク・パラメータをBPEL変数にマップします。さらに、拡張機能も定義できます。たとえば、スコープとグローバル・タスク変数名（デフォルト名を受け入れない場合）、タスク所有者、識別キー、BPELコールバックのカスタマイズ、およびヒューマン・タスクを拡張して他のワークフロー・タスクを追加するかどうかなどです。
関連付けが完了すると、タスク・サービス・パートナ・リンクが作成されます。タスク・サービスでは、タスクの操作に必要な操作が公開されます。
ヒューマン・タスク・エディタを使用すると、タスクのメタデータを定義できます。このエディタでは、ヒューマン・タスク設定（タスクの結果、ペイロード構造、タスク参加者、割当ておよびルーティング・ポリシー、有効期限およびエスカレーション・ポリシー、通知設定など）を指定できます。
ヒューマン・タスクの作成が完了すると、次のフォルダとファイルが作成されます。
「ヒューマン・タスク・エディタへのアクセス」で「ヒューマン・タスク名」フィールドに指定したヒューマン・タスク名を持つフォルダが、アプリケーション・ナビゲータでBPELプロセスの「インテグレーション・コンテンツ」フォルダの下に作成されます。
ヒューマン・タスク・エディタで指定したヒューマン・タスク設定が、メタデータ・タスク構成ファイル（拡張子.task）に保存されます。このファイルはヒューマン・タスク名と同じ名前のフォルダに格納されます。このファイル内の設定はいつでも再編集できます。そのためには、このファイルをアプリケーション・ナビゲータでダブルクリックします。これにより、.taskファイルがヒューマン・タスク・エディタで再び開きます。
この項の内容は次のとおりです。
ヒューマン・タスクの作成を開始できるようになった時点で、Oracle JDeveloperから複数の方法でヒューマン・タスク・エディタにアクセスできます。
この方法では、ヒューマン・タスクを作成し、後からヒューマン・タスク・アクティビティを使用してBPELプロセスに関連付けることができます。
アプリケーション・ナビゲータでBPELプロセスを右クリックして「ヒューマン・タスク定義の作成」を選択します。
「ヒューマン・タスクの追加」ウィンドウが表示されます。
「ヒューマン・タスク名」フィールドに名前を入力します。
入力した名前が「場所」フィールドのディレクトリ・パスに追加されます。
SOA_Oracle_Home/jdev/mywork/my_application/my_process/bpel/ Human_task_directory/Human_task_name.task
「OK」をクリックします。
ヒューマン・タスク・エディタが表示されます。
|
注意: 後からBPELプロセスに関連付けるヒューマン・タスクを作成するには、「ファイル」メイン・メニューから「新規」を選択し、インテグレーション層→「ヒューマン・タスク」→「ヒューマン・タスク定義」を選択する方法もあります。 |
この方法では、ヒューマン・タスク・アクティビティを作成した直後に、そのヒューマン・タスク・アクティビティを使用してBPELプロセスを関連付けることができます。
コンポーネント・パレットから「プロセス・アクティビティ」を選択します。
Human TaskアクティビティをBPELプロセスにドラッグ・アンド・ドロップします。
「ヒューマン・タスクの追加」ウィンドウが表示されます。
「タスク定義」フィールドの右側にある2番目のアイコンをクリックします。
「ヒューマン・タスク名」フィールドに名前を入力します。
入力した名前が「場所」フィールドのディレクトリ・パスに追加されます。
SOA_Oracle_Home/jdev/mywork/my_application/my_process/bpel/ Human_task_directory/Human_task_name.task
「OK」をクリックします。
ヒューマン・タスク・エディタが表示されます。
ヒューマン・タスク・エディタは、図15-9に示すメイン・セクションで構成されています。これらのセクションを使用してヒューマン・タスクを作成できます。
表15-1に、ヒューマン・タスク・エディタのこれらのメイン・セクションを使用してワークフロー・タスクを作成する手順を示します。
表15-1 ヒューマン・タスク・エディタ
| メイン・セクション | 参照先 |
|---|---|
| タスク構成
（タイトル、結果、優先度および所有者） |
「タスクのタイトル、優先度、結果および所有者の指定」 |
| パラメータ | 「タスク・ペイロードのデータ構造の指定」 |
| 割当ておよびルーティング・ポリシー | 「タスク参加者の割当て」 |
| 有効期限およびエスカレーション・ポリシー | 「タスクのエスカレート、期限更新または終了」 |
| 通知設定 | 「参加者の通知プリファレンスの指定」 |
| 詳細設定
（カスタム・エスカレーション・ルール、添付ファイルのカスタム・スタイルシート、多言語設定、カスタム・タスク・アクション、エラー・メッセージおよびコールバック・クラスの指定に使用） |
「詳細設定の指定」 |
図15-10に、ヒューマン・タスク・エディタの「タスク構成」セクションを示します。
このセクションでは、タスクのタイトル、優先度、結果および所有者などの詳細を指定できます。
表15-2に、「タスク構成」セクションのサブセクションの構成手順を示します。
表15-2 ヒューマン・タスク・エディタ: 「タスク構成」セクション
| サブセクション | 参照先 |
|---|---|
| タイトル
優先度 |
「タスクのタイトルと優先度の指定」 |
| 結果 | 「タスクの結果の指定」 |
| 所有者 | 「タスク所有者の指定」 |
次の詳細を入力します。
| フィールド | 説明 |
|---|---|
| タイトル | タスクのタイトルを入力します（オプション）。タスクのタイトルはOracle BPEL Worklistアプリケーションに表示されます。「タスクのタイトルの指定」の説明に従って「ヒューマン・タスク」ウィンドウの「一般」タブで「タスクのタイトル」フィールドにタイトルを入力すると、このフィールドに入力したタイトルが上書きされます。 |
| 優先度 | タスクの優先度を指定します。優先度は、1から5までで、1が最高値です。タスクの優先度は、デフォルトで3に設定されます。優先度を使用して、Oracle BPEL Worklistアプリケーションでタスクをソートできます。「ヒューマン・タスクの追加」ウィンドウの「一般」タブで優先度値を選択すると、この優先度値が上書きされます。
関連項目: 「ヒューマン・タスクの追加」ウィンドウで優先度値を指定する手順は、「タスクの起案者と優先度の指定」を参照してください。 |
タスクの結果により、タスクに可能な結果が取得されます。Oracle BPEL Worklistアプリケーションには、ここで指定した結果が実行時に実行可能なアクションとして表示されます。次のタイプのタスクの結果を指定できます。
シード済結果の選択
カスタム結果の入力
タスクの結果には、ここで指定した実際の結果値とは異なる実行時の表示値を割り当てることもできます。これにより、Oracle BPEL Worklistアプリケーションで結果を異なる言語で表示できます。国際化の詳細は、「多言語設定の指定」を参照してください。
「結果」フィールドの右側にある懐中電灯アイコンをクリックします。
タスクに可能な結果が「結果」ウィンドウに表示されます。承認および「却下」はデフォルトで選択されます。
さらにタスクの結果を選択するか、デフォルトの結果の選択を解除します。
「カスタム結果」フィールドにカスタム結果をカンマで区切って入力します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「結果」フィールドに表示されます。
ここで選択したシード済結果とカスタム結果が「グループ投票」参加者タイプの「多数決の結果」セクションに表示され、選択できます。
switchアクティビティに最初にカスタム結果が表示されるかどうかは、ヒューマン・タスク定義の作成方法によって決まります。 次のタスクを実行するとします。
ヒューマン・タスク・アクティビティを設計ウィンドウにドラッグ・アンド・ドロップします。
「タスク定義」フィールドの右にある「タスク定義の作成」アイコン（2番目のアイコン）をクリックします。
カスタム結果を指定してヒューマン・タスク定義を作成します。
ヒューマン・タスク・アクティビティを開きます。
最初はswitchアクティビティにカスタム結果が表示されないことに注意してください。
これを解決するには、次の手順を実行します。
ヒューマン・タスク・アクティビティをクリックして「ヒューマン・タスク」ウィンドウを表示します。
「OK」をクリックします。
プロンプトに対して「はい」をクリックし、カスタム結果が考慮されるようにヒューマン・タスク定義を更新します。
「ソース」をクリックします。
「ダイアグラム」をクリックします。
ヒューマン・タスク・アクティビティのswitchアクティビティを開き、カスタム結果が表示されることを確認します。
または、ヒューマン・タスク定義ファイルを常に次のように作成します。
「アプリケーション・ナビゲータ」でBPELプロセスを右クリックします。
「ヒューマン・タスク定義の作成」を選択します。
ヒューマン・タスク定義を設計します。
新しいヒューマン・タスク・アクティビティを設計ウィンドウにドラッグし、このヒューマン・タスク定義ファイルに関連付けます。
ヒューマン・タスク・アクティビティのswitchアクティビティを開き、カスタム結果が表示されることを確認します。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、割当て済タスクの参加者タイプのいずれかにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも行うことができます。指定がない場合、このオプション・フィールドは、デフォルトでシステム・ユーザーbpeladminになります。また、タスク所有者は「タスク所有者の指定」の説明に従って「ヒューマン・タスク」ウィンドウの「詳細」タブで指定することもできます。「詳細」タブでタスク所有者を指定すると、ここに入力したタスク所有者が上書きされます。
タスク所有者の指定方法を選択します。
タスク所有者は、Oracle BPEL Process Managerで使用するように構成されたユーザー・ディレクトリ（Oracle Internet Directory（OID）、JAZN/XML、LDAPなど）を参照することで選択できます。
「所有者」フィールドの右側にある最初のアイコンをクリックして、「アイデンティティ・ルックアップ・ダイアログ」を表示します。
検索文字列（jcooper, j*, *,など）を入力して所有者を検索します。「ルックアップ」をクリックすると、検索条件に一致するすべてのユーザーが取得されます。
「選択」をクリックすると、1つ以上のユーザーまたはグループをハイライトして選択できます。
ユーザーを選択して「階層」をクリックし、そのユーザーの階層を表示します。同様に、「報告先」をクリックすると、選択したユーザーまたはグループの部下が表示されます。
ユーザーまたはグループを選択して「詳細」をクリックし、そのユーザーまたはグループの詳細を表示します。
「OK」をクリックして「アイデンティティ・ルックアップ・ダイアログ」に戻ります。
「選択」をクリックしてユーザーを「選択したユーザー」セクションに追加します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
タスク所有者を「式ビルダー」ウィンドウで動的に選択できます。
「所有者」フィールドの右側にある2番目のアイコンをクリックして、「式ビルダー」ウィンドウを表示します。
使用可能な変数のスキーマおよび関数を参照してタスク所有者を作成します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「所有者」フィールドに表示されます。
|
関連項目:
|
図15-11に、ヒューマン・タスク・エディタの「パラメータ」セクションを示します。
このセクションでは、タスク・ペイロード（タスクのデータ）の構造（メッセージ属性）を定義できます。タスク・ペイロード・データは、1つ以上の要素またはタイプで構成されます。選択内容に基づいてタスク・ペイロードのXMLスキーマ定義が作成されます。
「+」記号をクリックして「タスク・パラメータの追加」ウィンドウを表示します。
次の詳細を入力します。
| フィールド | 説明 |
|---|---|
| パラメータ・タイプ | 「タイプ」または「要素」を選択し、懐中電灯アイコンをクリックして、タスク・パラメータ選択用の「タイプの選択」ウィンドウを表示します。 |
| 名前 | デフォルト名を受け入れるか、カスタムの名前を入力します。このフィールドが表示されるのは、パラメータ・タイプとして「タイプ」を選択した場合のみです。 |
| ワークリストにより変更可能 | このチェック・ボックスを選択すると、Oracle BPEL Worklistアプリケーションのフッターのタスク・ペイロード・データを編集できます。たとえば、アプリケーションの承認者は承認者コメントの追加を必要とする場合があります。 |
|
注意: Oracle BPEL Worklistアプリケーションで定義できるのは、単純XMLタイプであるペイロード・パラメータのペイロード・フレックス・フィールド・マッピングのみです。 |
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
選択内容が「パラメータ」セクションに表示されます。
選択内容を編集する場合は、対象項目を選択して「パラメータ」セクションの右上にある最初のアイコンをクリックします。
図15-12に、ヒューマン・タスク・エディタの「割当ておよびルーティング・ポリシー」セクションを示します。
このセクションでは、ビジネス要件を満たす参加者タイプを選択できます。以前のリリースのOracle BPEL Process Managerでは、参加者タイプはワークフロー・パターンと呼ばれていました。
複数の参加者タイプを組み合せて調整し、ヒューマン・タスクをモデリングできます。これにより、前に構成したヒューマン・タスクの機能を拡張し、より複雑なワークフローをモデリングできます。
参加者タイプごとに、構成タスクに使用するエディタが関連付けられています。割当て先の追加順序は、実行順序を示します。
「+」記号をクリックして「参加者タイプの追加」ウィンドウを表示します。
これにより、特定の参加者タイプを選択できます。
「タイプ」リストから参加者タイプを選択します。
各参加者タイプの構成タスクについては、以降の各項を参照してください。
選択内容に応じて次の項を参照してください。
| サブセクション | 参照先 |
|---|---|
参加者タイプの追加
|
|
参加者タイプの構成後に、図15-12に示すタスクの「割当ておよびルーティング・ポリシー」の次の各セクションを参照します。これらのセクションを選択に使用するには、まず参加者タイプを作成する必要があります。
| サブセクション | 参照先 |
|---|---|
| 全参加者による他の参加者の招待を許可 | 「全参加者による他の参加者の招待の許可」 |
| 条件付き中途完了の有効化 | 「条件付き中途完了」 |
各参加者タイプのユーザーおよびグループを静的または動的に指定できます。ユーザーとグループを静的に（アイデンティティ・サービスを参照して）指定する場合、値は次のいずれかになります。
単一の承認者の場合、単一のユーザーまたはグループ（jsteinなど）は次のように取得されます。
<participant name="Assignee1"> <resource isGroup="false" type="STATIC">jstein</resource> </participant>
単一の承認者の場合、ユーザーまたはグループのデリミタ付き文字列（jstein、wfaulk、cdickensなど）は次のように取得されます。
<participant name="Assignee1"> <resource isGroup="false" type="STATIC">jstein, wfaulk, cdickens</resource> </participant>
ペイロード変数で指定されたタスク承認者の動的リストを作成するというビジネス要件を使用できます。 このXPath式は、0（ゼロ）個以上のXMLノードに解決できます。 各ノードの値は次のいずれかになります。
単一のユーザーまたはグループ。
ユーザーまたはグループのデリミタ付き文字列。 たとえば、次のタスクは、ペイロード・メッセージ属性がxsd:Stringタイプで、その値がカンマ区切りの承認者文字列であることを示しています。 このノードを使用して参加者を指定できます。
<task> . . . <payload> <approvers>jstein,wfaulk,cdickens</approvers> </payload> </task>
割当て先のデリミタ付き文字列のデフォルト・デリミタはカンマ（,）です。 このデリミタは、wf-config.xmlファイル内でassigneeDelimiter XML要素を使用して変更できます。 このデリミタはシステム内のすべてのワークフローに適用されます。
この方法による参加者の指定はすべての参加者タイプに適用可能ですが、解釈はタイプごとに異なります。たとえば、次のようになります。
単一ユーザー参加者タイプの場合、タスクは評価された全ユーザーに割り当てられます。
「承認者の順序リスト」参加者タイプの場合、タスクはリストで評価されたユーザーおよびグループに順番に割り当てられます。
「グループ投票」参加者タイプの場合は、リストで評価されたユーザーおよびグループごとにタスクが作成されます。
このようにリソースXPath式を解釈することにより、orcl:create-nodeset-from-delimited-stringと等価の機能が得られ、ペイロード変数から1人以上のタスク承認者（リソース要素メンバー）の動的リストを指定できるようになります。
図15-13に、「単一の承認者」ウィンドウを示します。
この参加者タイプでは、1人のユーザーがタスクを操作する必要があります。タスクが複数のユーザーを含むロールまたはグループに割り当てられている場合は、メンバーの1人がタスクを申告して操作する必要があります。そのユーザーのアクションに基づいて、ビジネス・プロセスの内容を定義します。
たとえば、休暇申請がマネージャに割り当てられているとします。マネージャは、休暇が始まる3日前までに申請タスクを操作する必要があります。マネージャが申請を正式に承認または却下すると、その決定が従業員に通知されます。マネージャがタスクを操作しなければ、申請は却下として扱われます。正式な却下の場合と同様に通知アクションが実行されます。
「ラベル」フィールドに、この参加者を識別可能なラベルを入力します。このラベルは、このワークフロー内で一意である必要があります（Approval Manager、Primary Reviewersなど）。
表15-3に、「参加者タイプの追加 - 単一の承認者」ウィンドウの各サブセクションの構成手順を示します。
表15-3 「参加者タイプの追加 - 単一の承認者」
| サブセクション | 参照先 |
|---|---|
| 次のいずれかの参加者によるアクションが必要です: | 「単一の承認者タスクへの参加者の割当て」 |
| スキップ・ルールの指定 | 「タスク参加者のバイパス」 |
| 割当て済期間の制限の設定 | 「タスクの操作に対する時間制限の指定」 |
| この参加者による他の参加者の招待を許可 | 「タスクへの他の参加者の招待」 |
このタスクに対するアクションの実行に参加するユーザーまたはグループの割当て方法を選択します。
名前別
ユーザー名またはグループ名をクリックするか、フィールドの右側にある最初のアイコン（懐中電灯）をクリックし、表示されるウィンドウでアイデンティティ・サービスを介して構成済のユーザーまたはグループを選択します。アイデンティティ・サービスを使用すると、ユーザー認可と、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能です。ユーザー情報は、Java AuthoriZatioN（JAZN）またはLDAPサーバー（Oracle Internet Directoryなど）から取得されます。IDの検索にはワイルドカード（*）を使用できます。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、このタスクをユーザー（jcooperなど）またはグループ（administratorsなど）に動的に割り当てます。グループのメンバーであるユーザーに、このタスクが割り当てられます。グループに割り当てられたタスクを操作するユーザーは、最初にOracle BPEL Worklistアプリケーションで実行時にタスクを申告する必要があります。
割当て先を指定するXPath式は、次のルールに従う必要があります。
タスクXSDに基づく必要があります。これには、ペイロード・セクションで定義されたペイロードが含まれます。たとえば、/task:task/task:payload/order:orderAssigneeはタスクXSDに基づくXPath式の一例です。
XPath式には、bpws:getVariableData()のようなBPEL固有のXPath関数を使用できません。これらのXPath式はBPELインスタンスのコンテキストから評価されないためです。
XPath式には、BPELに依存しないXPath関数を使用できます。これには、ids:getManager()などのアイデンティティ・サービスXPath関数が含まれます。
「+」記号をクリックして、図15-13に示した「詳細」セクションを開きます。
ユーザーまたはグループにタスクの操作に関して与えられる時間を指定します。ユーザーまたはグループが指定の時間内に操作しなければ、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されており、この参加者が指定の期間内に操作しなければ、タスクは必要に応じてマネージャまたは他のユーザーにエスカレートします。
|
関連項目: ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションでグローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、「タスクのエスカレート、期限更新または終了」を参照してください。 |
図15-14に、「グループ投票」ウィンドウを示します。
この参加者タイプは、並行して作業する複数のユーザーが同時にアクションを実行する（たとえば、雇用に関するフローで複数のユーザーが応募者の採否を票決する）必要がある場合に使用します。結果が有効になるために必要な得票率（多数決や満場一致など）を指定します。
たとえば、ビジネス・プロセスでは、雇用プロセス中に面接担当者全員からフィードバックを収集し、それをとりまとめて各面接担当者に採用または不採用リクエストを割り当てます。最後に、面接担当者の大多数が不採用ではなく採用に投票すると、候補者が雇用されます。
「ラベル」フィールドに、この参加者を識別可能なラベルを入力します。このラベルは、このワークフロー内で一意である必要があります（Approval Manager、Primary Reviewersなど）。
表15-4に、「参加者タイプの追加 - グループ投票」ウィンドウの各サブセクションの構成手順を示します。
表15-4 「参加者タイプの追加 - グループ投票」ウィンドウ
| サブセクション | 参照先 |
|---|---|
| 参加者間に必要な同意: 50 | 「グループ投票タスクへの参加者の割当て」 |
| スキップ・ルールの指定 | 「タスク参加者のバイパス」 |
| 添付ファイルとコメントの共有 | 「タスク参加者との添付ファイルおよびコメントの共有」 |
| デフォルトの結果
同意パーセント 最小のパーセントに達するとただちに投票結果がトリガーされます 結果をトリガーせずにすべての投票の完了まで待機 |
「グループ投票詳細の指定」 |
| 割当て済期間の制限の設定 | 「タスクの操作に対する時間制限の指定」 |
このタスクに参加するユーザーまたはグループの割当て方法を選択します。割り当てられた参加者は、タスクが完了とみなされる場合について同意に達する必要があります。
名前別
ユーザー名またはグループ名をクリックするか、フィールドの右側にある最初のアイコン（懐中電灯）をクリックし、表示されるウィンドウでアイデンティティ・サービスを介して構成済のユーザーまたはグループを選択します。アイデンティティ・サービスを使用すると、ユーザー認可と、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能です。ユーザー情報は、Java AuthoriZatioN（JAZN）またはLDAPサーバー（Oracle Internet Directoryなど）から取得されます。IDの検索にはワイルドカード（*）を使用できます。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、このタスクをユーザー（jcooperなど）またはグループ（administratorsなど）に動的に割り当てます。グループのメンバーであるユーザーに、このタスクが割り当てられます。グループに割り当てられたタスクを操作するユーザーは、最初にOracle BPEL Worklistアプリケーションで実行時にタスクを申告する必要があります。
最終タスクの結果の選択方法を指定します。下のリストから「式別」を選択すると、フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、詳細を動的に指定できます。
同意パーセントの値に達しない場合に有効にする、このタスクのデフォルトの結果を選択します。この状況が発生するのは、得票数が同数の場合、またはタスクの有効期限が切れる前に応答しない参加者がいる場合です。「タスクの結果の指定」で「結果」ウィンドウに入力したシード済結果とカスタム結果は、このリストに表示されます。
このタスクの結果が有効になるために必要なパーセント値を選択します。たとえば、多数決（51）や満場一致（100）などです。たとえば、予想される2つの結果（「承認」および「却下」）と、5つのサブタスクがあるとします。2つのサブタスクが承認され、3つが却下された場合に、承認に必要なパーセントが50%に設定されていると、タスクの結果は却下になります。
さらにグループ投票詳細を指定します。
「+」記号をクリックして、図15-14に示した「詳細」セクションを開きます。
「割当て済期間の制限の設定」を選択します。
ユーザーまたはグループにタスクの操作に関して与えられる時間を指定します。ユーザーまたはグループが指定の時間内に操作しなければ、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されており、この参加者が指定の期間内に操作しなければ、タスクは必要に応じてマネージャまたは他のユーザーにエスカレートします。
|
関連項目: ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションでグローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、「タスクのエスカレート、期限更新または終了」を参照してください。 |
図15-15に、「管理チェーン」ウィンドウを示します。
この参加者タイプでは、タスクが承認のために管理チェーン階層内の複数のユーザーにルーティングされます。タスク参加者を管理チェーン・リストまたはユーザー・リストとして指定します。
たとえば、注文書がマネージャに割り当てられているとします。マネージャが承認した注文は、上位のマネージャに割り当てられます。そのマネージャが承認するとさらに上位のマネージャに割り当てられ、3人のマネージャが注文を承認するまで上位へと順番にルーティングされます。マネージャのいずれかがリクエストを却下するか、リクエストの期限が切れると、注文が却下されます。
「ラベル」フィールドに、この参加者を識別可能なラベルを入力します。このラベルは、このワークフロー内で一意である必要があります（Approval Manager、Primary Reviewersなど）。
表15-5に、「参加者タイプの追加 - 管理チェーン」ウィンドウの各サブセクションの構成手順を示します。
表15-5 「参加者タイプの追加 - 管理チェーン」
| サブセクション | 参照先 |
|---|---|
| 次のいずれかの参加者の管理チェーン承認が必要です | 「管理チェーン・タスクへの参加者の割当て」 |
| スキップ・ルールの指定 | 「タスク参加者のバイパス」 |
| チェーン・レベル上げの最大数
承認者の最高役職 |
「承認者数の指定」 |
| 割当て済期間の制限の設定 | 「タスクの操作に対する時間制限の指定」 |
| この参加者による他の参加者の招待を許可 | 「タスクへの他の参加者の招待」 |
このタスクに参加するユーザーまたはグループの割当て方法を選択します。
名前別
ユーザー名またはグループ名をクリックするか、フィールドの右側にある最初のアイコン（懐中電灯）をクリックし、表示されるウィンドウでアイデンティティ・サービスを介して構成済のユーザーまたはグループを選択します。アイデンティティ・サービスを使用すると、ユーザー認可と、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能です。ユーザー情報は、Java AuthoriZatioN（JAZN）またはLDAPサーバー（Oracle Internet Directoryなど）から取得されます。IDの検索にはワイルドカード（*）を使用できます。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、このタスクをユーザー（jcooperなど）またはグループ（administratorsなど）に動的に割り当てます。グループのメンバーであるユーザーに、このタスクが割り当てられます。グループに割り当てられたタスクを操作するユーザーは、最初にOracle BPEL Worklistアプリケーションで実行時にタスクを申告する必要があります。
「+」記号をクリックして、図15-15に示した「詳細」セクションを開きます。
「割当て済期間の制限の設定」を選択します。
ユーザーまたはグループにタスクの操作に関して与えられる時間を指定します。ユーザーまたはグループが指定の時間内に操作しなければ、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されており、この参加者が指定の期間内に操作しなければ、タスクは必要に応じてマネージャまたは他のユーザーにエスカレートします。
|
関連項目: ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションでグローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、「タスクのエスカレート、期限更新または終了」を参照してください。 |
このタスク割当て先がこのワークフローの次の割当て先へのルーティング前に他の参加者をワークフローに招待できるようにする場合は、「この参加者による他の参加者の招待を許可」を選択します。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
|
注意: 「管理チェーン」参加者タイプの場合、他の参加者を招待できるのは管理チェーンの最後のユーザーのみです。 |
図15-16に、「承認者の順序リスト」ウィンドウを示します。
この参加者タイプを使用すると、ワークフロー用に参加者の順序リストを作成できます。たとえば、文書をJohn、MaryおよびScottに順番にレビューさせる場合は、この参加者タイプを使用します。「管理チェーン」参加者タイプはこのタイプに似ていますが、ユーザーは組織階層に含まれます。「承認者の順序リスト」参加者タイプの場合、任意のユーザー・リストまたはグループ・リストに所属できます。
「ラベル」フィールドに、この参加者を識別可能なラベルを入力します。このラベルは、このワークフロー内で一意である必要があります（Approval Manager、Primary Reviewersなど）。
表15-6に、「参加者タイプの追加 - 承認者の順序リスト」ウィンドウの各サブセクションの構成手順を示します。
表15-6 「参加者タイプの追加 - 承認者の順序リスト」
| サブセクション | 参照先 |
|---|---|
| 次のすべての参加者の順次承認が必要です: | 「承認者の順序リスト・タスクへの参加者の割当て」 |
| スキップ・ルールの指定 | 「タスク参加者のバイパス」 |
| 割当て済期間の制限の設定 | 「タスクの操作に対する時間制限の指定」 |
| この参加者による他の参加者の招待を許可 | 「タスクへの他の参加者の招待」 |
このタスクに参加するユーザーまたはグループの割当て方法を選択します。
名前別
ユーザー名またはグループ名をクリックするか、フィールドの右側にある最初のアイコン（懐中電灯）をクリックし、表示されるウィンドウでアイデンティティ・サービスを介して構成済のユーザーまたはグループを選択します。アイデンティティ・サービスを使用すると、ユーザー認可と、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能です。ユーザー情報は、Java AuthoriZatioN（JAZN）またはLDAPサーバー（Oracle Internet Directoryなど）から取得されます。IDの検索にはワイルドカード（*）を使用できます。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、このタスクをユーザー（jcooperなど）またはグループ（administratorsなど）に動的に割り当てます。グループのメンバーであるユーザーに、このタスクが割り当てられます。グループに割り当てられたタスクを操作するユーザーは、最初にOracle BPEL Worklistアプリケーションで実行時にタスクを申告する必要があります。
「+」記号をクリックして、図15-16に示した「詳細」セクションを開きます。
「割当て済期間の制限の設定」をクリックします。
ユーザーまたはグループにタスクの操作に関して与えられる時間を指定します。ユーザーまたはグループが指定の時間内に操作しなければ、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で設定したグローバルなエスカレーションおよび期限更新ポリシーが適用されます。たとえば、タスクをエスカレートするようにグローバル・ポリシーが設定されており、この参加者が指定の期間内に操作しなければ、タスクは必要に応じてマネージャまたは他のユーザーにエスカレートします。
|
関連項目: ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションでグローバルなエスカレーションおよび期限更新ポリシーを設定する手順は、「タスクのエスカレート、期限更新または終了」を参照してください。 |
このタスク割当て先がこのワークフローの次の割当て先へのルーティング前に他の参加者をワークフローに招待できるようにする場合は、「この参加者による他の参加者の招待を許可」を選択します。たとえば、承認ワークフローがJames CooperからJohn Steinbeckに進むとします。このオプションを選択すると、James Cooperは最初にIrving StoneにルーティングしてからJohn Steinbeckにルーティングするように指定できます。
|
注意: 「承認者の順序リスト」参加者タイプの場合、他の参加者を招待できるのは管理チェーンの最後のユーザーのみです。 |
図15-17に、「FYI割当て先」ウィンドウを示します。
この参加者タイプは、ユーザーにタスクを送信するが、ビジネス・プロセスでユーザーのレスポンスを待機しない場合に使用します。プロセスは単に継続されます。FYI割当て先がタスクの結果を直接左右することはできませんが、コメントを提供したり添付ファイルを追加できる場合があります。
たとえば、雑誌の購読契約の更新期日がきているとします。ユーザーが期日までに現在の購読契約を取り消さなければ、購読契約の期限が更新されます。リクエストが期限切れになるかユーザーが操作するまで、このユーザーに週に1回ずつリマインダが送信されます。
「ラベル」フィールドに、この参加者を識別可能なラベルを入力します。このラベルは、このワークフロー内で一意である必要があります（Approval Manager、Primary Reviewersなど）。
表15-7に、「参加者タイプの追加 - FYI割当て先」ウィンドウの各サブセクションの構成手順を示します。
表15-7 「参加者タイプの追加 - FYI割当て先」
| サブセクション | 参照先 |
|---|---|
| 次のすべての参加者にこのタスクのFYIコピーを送信: | 「FYI割当て先タスクへの参加者の割当て」 |
| 添付ファイルとコメントの共有 | 「タスク参加者との添付ファイルおよびコメントの共有」 |
このタスクに参加するユーザーまたはグループの割当て方法を選択します。
名前別
ユーザー名またはグループ名をクリックするか、フィールドの右側にある最初のアイコン（懐中電灯）をクリックし、表示されるウィンドウでアイデンティティ・サービスを介して構成済のユーザーまたはグループを選択します。アイデンティティ・サービスを使用すると、ユーザー認可と、ユーザーのプロパティ、ロール、グループ・メンバーシップおよび権限のルックアップが可能です。ユーザー情報は、Java AuthoriZatioN（JAZN）またはLDAPサーバー（Oracle Internet Directoryなど）から取得されます。IDの検索にはワイルドカード（*）を使用できます。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、このタスクをユーザー（jcooperなど）またはグループ（administratorsなど）に動的に割り当てます。グループのメンバーであるユーザーに、このタスクが割り当てられます。グループに割り当てられたタスクを操作するユーザーは、最初にOracle BPEL Worklistアプリケーションで実行時にタスクを申告する必要があります。
図15-18に、「外部ルーティング・サービス」ウィンドウを示します。
この参加者タイプを使用すると、ワークフローの参加者を動的に決定する外部ルーティング・サービスを構成できます。この参加者タイプを指定すると、他の参加者タイプはすべて無視されます。外部ルーティング・サービスは、タスクのルーティングを決定するために実行時に参加者タイプ（単一の承認者、承認者のリスト、グループ投票など）のリストを提供するものとみなされます。
参加者タイプを構成してヒューマン・タスク・エディタに戻ると、図15-19のように「全参加者による他の参加者の招待を許可」チェック・ボックスが有効化されています。
このチェック・ボックスは、以前のBPELリリースの非定型ワークフロー・パターンに相当します。これは、参加者が1人以上存在する場合に適用されます。この場合、各ユーザーがタスクの承認時に次の割当て先としてユーザーまたはグループを選択します。
このタスク割当て先がこのワークフローの次の割当て先へのルーティング前に他の参加者をワークフローに招待できるようにする場合は、「全参加者による他の参加者の招待を許可」チェック・ボックスを選択します。
参加者タイプを構成してヒューマン・タスク・エディタに戻ると、図15-19のように「条件付き中途完了の有効化」チェック・ボックスが有効化されています。
ワークフローの他の参加者に関係なくタスクを早期完了させる条件を指定する場合は、「条件付き中途完了の有効化」チェック・ボックスを選択します。
「中途完了の詳細」ウィンドウが表示されます。
たとえば、経費レポートがマネージャに送信されてから取締役に送信されるとします。最初の参加者（マネージャ）がレポートを却下した場合、次の参加者（取締役）に送信せずにワークフローを終了できます。
タスクの中途完了を指定するには、次の2つの方法があります。
結果
XPath式のルーティング条件
結果を指定した場合は、選択したタスクの結果が発生すると、そのタスクが完了します。結果とルーティング条件の両方を指定した場合は、ワークフロー・サービスにより2つの条件の論理ORが実行されます。
適切な結果を選択して「>」ボタンをクリックします。すべてを選択するには、「>>」ボタンをクリックします。
「ルーティング条件」フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示します。このウィンドウで、このタスクを中途完了させる条件を動的に作成できます。たとえば、ユーザーが発行する出張旅費レポートが特定の金額を下回っている場合、マネージャによる承認は不要です。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
チェック・ボックスが選択されています。これは、情報を定義したことを示しています。「条件付き中途完了の有効化」チェック・ボックスの右側にあるアイコンをクリックすると、この情報を編集できます。
図15-20に、ヒューマン・タスク・エディタの「有効期限およびエスカレーション・ポリシー」セクションを示します。
このグローバル・ポリシー・セクション（ルーティング・スリップ・レベル）で、タスクの有効期間を指定できます。有効期間を参加者タイプ・レベルではなくルーティング・スリップ・レベルで指定すると、この期間は全参加者のタスクの有効期間となります。ただし、参加者タイプ・レベルで（「割当て済期間の制限の設定」フィールドを介して）有効期間を指定すると、その設定は「有効期限およびエスカレーション・ポリシー」セクション（ルーティング・スリップ・レベル）で指定した設定よりも優先されます。
この項では、このレベルで有効期間を指定して、この設定を参加者全員のタスクの有効期間にする方法の概要を説明します。
たとえば、図15-21に示すように、参加者LoanAgentGroupおよび参加者Supervisorの両者間でタスクを操作するための日数が3日であるとします。
参加者レベルまたはこのルーティング・スリップ・レベルで有効期限が指定されていなければ、そのタスクの有効期間設定はありません。
いずれかの参加者レベルで有効期間が設定されている場合、その参加者には対応する有効期間が使用されます。ただし、参加者レベルの有効期間が設定されていない参加者には、引き続きグローバルな有効期間が使用されます。グローバルな有効期間は、常にタスクでの経過時間だけ減分されます。
参加者について参加者レベルの有効期限を解析するためのポリシーは、次のとおりです。
管理チェーン: 管理チェーンの各参加者は同じ有効期間を取得します。期間は、この割当てによって生じるすべての割当てに対するものではありません。タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、そのタスクは期限切れになり、エスカレーションおよび期限更新ポリシーが適用されます。
承認者の順序リスト: 管理チェーン内の各割当ては、承認者の順序リストで指定されているのと同じ有効期間を取得します。期間は、この割当てによって生じるすべての割当てに対するものではないことに注意してください。タスクが管理チェーン内のいずれかの割当てで有効期限に達すると、そのタスクは期限切れになり、エスカレーションおよび期限更新ポリシーが適用されます。
グループ投票
グループ投票ワークフローの場合、パラレル参加者がリソースとして指定されていれば、リソースごとにルーティング・スリップが作成されます。作成された各ルーティング・スリップの有効期間には、次のルールが適用されます。
パラレル参加者の有効期間が指定されている場合は、それと同じ有効期間。
ルーティング・スリップ・レベルで指定されている場合は、タスクに残っている有効期間。
それ以外は、有効期間なし。
パラレル参加者がルーティング・スリップとして指定されている場合、その有効期間はルーティング・スリップにより決定されます。
|
注意: パラレル・タスク内で親タスクが期限切れになった場合、期限切れになっていないか完了していないサブタスクは取り消されます。 |
次のルーティング・スリップ・サンプルでは、ルーティング・スリップ・レベルでは有効期間が指定されていますが、参加者Loan Agent Groupの有効期間は1日で、参加者Loan Agent Supervisorにはタスクの有効期間が指定されていません。この例では、ルーティング・スリップはルーティング・スリップ・レベルで有効期間が指定されていない場合と同様に扱われます。
<routingSlip xmlns="http://xmlns.oracle.com/pcbpel/workflow/routingslip">
<expirationDuration>PT10D </expirationDuration>
<participants>
<participant name="Loan Agent 1" expirationDuration="PT2D">
<resource isGroup="true" type="STATIC">jcooper</resource>
</participant>
<participant name="Loan Agent 2">
<resource isGroup="true" type="STATIC">jstein</resource>
</participant>
<managementChain name="Loan Approval Chain"
expirationDuration="PT2D">
<resource isGroup="true" type="STATIC">wfaulk</resource>
<levels type="STATIC">1</levels>
<title type="STATIC">Vice President</title>
</managementChain>
<participant name="Reviewer">
<resource isGroup="true" type="STATIC">sfitzger</resource>
</participant>
</participants>
</routingSlip>
表15-8に、有効期限ポリシーを示します。前述の例の管理チェーンは、2人のユーザーwfaulkおよびcdickens（wfaulkのマネージャ）と評価されることに注意してください。
表15-8 有効期限ポリシー
| 参加者 | 有効期限 | 承認までの実際の所要時間 |
|---|---|---|
Loan Agent 1: jcooper
|
2日（参加者レベル）
|
1日 |
Loan Agent 2: jstein
|
9日（10 – 1日）（グローバル・レベル）
|
1日 |
Loan Approval Chain: wfaulk（チェーン内の最初のユーザー）
|
2日（参加者レベル）
|
1日 |
Loan Approval Chain: cdickens（チェーン内の第2のユーザー）
|
2日（参加者レベル）
|
1日 |
Reviewer: sfitzger
|
6日（10 – 4日）（グローバル・レベル）
|
|
エスカレーションおよび有効期限ポリシーを選択します。「式別」フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、固定時間または動的時間を入力できます。
タスクの有効期限を指定する場合は、図15-20に示すリストから「期限切れまでの時間」を選択します。
タスクがオープンになっている最大期間を指定します。
タスクが期限切れになると、ルーティング・スリップ・レベルのエスカレーション・ポリシーまたは期限更新ポリシーが適用されます。どちらのポリシーも指定されていなければ、タスクは期限切れになります。ルーティング・スリップ・レベルの有効期限ポリシーは、すべての参加者に共通です。
パラレル参加者に対する有効期限ポリシーは、次のように解析されます。
パラレル参加者がパラレル要素でリソースとして指定されている場合、各パラレル参加者に対する有効期限ポリシーはありません。
パラレル参加者がルーティング・スリップとして指定されている場合、パラレル参加者にはルーティング・スリップの有効期限ポリシーが適用されます。
図15-22は、タスクが3日で期限切れになることを示しています。
ユーザーが割当て時間内に応答しない場合にタスクを（ユーザーのマネージャなどに）エスカレートする場合は、図15-20に示すリストから「エスカレートまでの時間」を選択します。
さらに次の値を指定します。
エスカレーション・レベルの最大数
タスクをエスカレートする管理レベル数
承認者の最高役職
最上位承認者の役職（自分、マネージャ、取締役またはCEOなど）
エスカレーション・ポリシーでは、タスクを期限切れ時にエスカレートできる回数と期限更新期間を指定します。図15-24では、タスクが期限切れになると、最大3回までエスカレートされます。タスクが参加者LoanAgentGroupの手元で期限切れになるか、参加者Supervisorの手元で期限切れになるかは関係ありません。
図15-25に、ヒューマン・タスク・エディタの「通知設定」セクション（完全に開いた状態）を示します。
通知は、ユーザーにタスクが割り当てられる時期を示すか、タスクのステータスに変更があったことを通知します。通知は、電子メール、ボイス・メッセージ、FAX、ポケットベルまたはSMSで送信できます。異なるアクションについて様々なタイプの参加者に通知が送信されます。デフォルトでは、通知はデフォルト・メッセージを使用して構成されます。たとえば、タスクが完了してクローズされたことを示す通知メッセージが送信されます。独自の構成を作成するか、既存の構成を変更できます。
「+」記号をクリックして、「通知設定」セクションを開きます（図15-25）。
表15-9に、「通知設定」セクションのサブセクションの構成手順を示します。
表15-9 ヒューマン・タスク・エディタ: 「通知設定」セクション
| サブセクション | 参照先 |
|---|---|
| タスク・ステータス
受信者 |
「受信者へのタスク・ステータス変更の通知」 |
| 通知ヘッダー | 「通知メッセージの編集」 |
| リマインダ | 「リマインダの設定」 |
| 通知のセキュア化(詳細を除く)
電子メール・メッセージのアクション可能化 電子メール通知によるタスクの添付ファイルの送信 |
「通知のセキュア化、メッセージのアクション可能化および添付ファイルの送信」 |
「タスク・ステータス」列には、3つのデフォルト・ステータス・タイプ「割当て」、「完了」および「エラー」が表示されます。通知メッセージの受信用に他のステータス・タイプを選択できます。
「タスク・ステータス」列でタイプをクリックしてタスク・タイプの詳細リストを表示します。
割当て: ユーザーまたはグループにタスクが割り当てられた場合。このアクションでは、次のアクションが取得されます。
ユーザーへのタスクの割当て
承認者の順序リスト・ワークフローでの新規ユーザーへのタスクの割当て
タスクの期限更新
タスクの委任
タスクの再割当て
タスクのエスカレート
タスク情報の発行
完了
エラー
期限切れ
情報のリクエスト
結果の更新
一時停止
取消
タスク・ステータスのタイプを選択します。
通知は、様々な範囲でタスクに関与するユーザーに送信できます。これには、タスクがグループに割り当てられている場合が含まれます。そのグループに通知エンドポイントが設定されていなければ、グループの各ユーザーに通知が送信されます。
「受信者」列でエントリをクリックして、通知メッセージの受信者候補のリストを表示します。
割当て先: タスクが現在割り当てられているユーザーまたはグループ。
起案者: タスクを作成したユーザー。
承認者: これまでにタスクを承認したすべてのユーザー。これは、複数のユーザーがタスクを承認する「承認者の順序リスト」参加者タイプに適用されます。通知は、これらのユーザー全員に送信される必要があります。
所有者: タスク所有者。
デフォルトの通知メッセージを、選択した受信者に配信できます。必要な場合は、デフォルト・メッセージのテキストを変更できます。
デフォルトの通知メッセージを変更するには、「通知ヘッダー」列のアイコンをクリックします。
「通知メッセージの編集」ウィンドウが表示されます。
このメッセージは、サポート対象のすべての通知チャネル（電子メール、ボイス、FAX、ポケットベルおよびSMS）に適用されます。電子メールおよびFAXによるメッセージには、このメッセージで定義されているワークリスト・タスクの詳細を含めることもできます。メッセージの配信チャネルは、指定した通知プリファレンスに基づきます。
必要に応じてメッセージの文言を変更します。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
タスクのリマインダを送信できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づきます。リマインダの数およびリマインダ間の間隔も構成可能です。
通知リストからリマインダの送信数を選択します。
割当て先に1回、2回または3回通知するように選択した場合は、リマインダの間隔を選択し、リマインダを割当て前に送信するか割当て後に送信するかを選択します。
このセクションでは、さらに通知タスクを実行できます。
使用する機能に対応するチェック・ボックスを選択します。
| フィールド | 値 |
|---|---|
| 通知のセキュア化(詳細を除く) | 通知メッセージをセキュア化する場合に選択します。選択すると、デフォルトの通知メッセージが使用されます。電子メールには、HTMLのワークリスト・タスク詳細、添付ファイルまたはアクション可能なリンクはありません。メッセージにはタスク番号のみが含まれます。
関連項目: 「セキュアな通知の送信」 |
| 電子メール・メッセージのアクション可能化 | 電子メール通知をアクション可能にする場合に選択します。これにより、電子メールを介してタスク・アクションを実行できます。
関連項目: その他の構成の詳細は、「アクション可能な電子メールの送信」を参照してください。 |
| 電子メール通知によるタスクの添付ファイルの送信 | 通知メッセージでタスクの添付ファイルを送信する場合に選択します。 |
このセクションでは、拡張ヒューマン・タスク機能を指定できます。たとえば、カスタムのエスカレーション・ルール、添付ファイルのカスタム・スタイルシート、多言語設定、カスタム・タスクのアクションとエラー・メッセージおよびコールバック・クラスなどを指定できます。
図15-26に、ヒューマン・タスク・エディタの「詳細設定」セクションを示します。
表15-10に、使用可能なセクションを示します。
表15-10 「詳細設定」のセクション
| セクション | 参照先 |
|---|---|
| エスカレーション・ルールを指定してください。 | 「エスカレーション・ルールの指定」 |
| 添付ファイルのWordMLスタイルシートを指定してください。 | 「添付ファイルのWordMLスタイルシートの指定」 |
| 添付ファイルのスタイルシートを指定してください。 | 「添付ファイルのスタイルシートの指定」 |
| 多言語設定を指定してください。 | 「多言語設定の指定」 |
| デフォルトのシステム・アクションを上書きします。 | 「デフォルトのシステム・アクションの上書き」 |
| デフォルトの例外管理を上書きします。 | 「デフォルトの例外管理の上書き」 |
| タスク・ステータスにコールバック・クラスを指定してください。 | 「タスク・ステータスのコールバック・クラスの指定」 |
| BPELコールバックのタスクとルーティング・カスタマイズを許可 | 「BPELコールバックのタスクとルーティング・カスタマイズの許可」 |
このオプションを使用すると、特定のワークフローについてカスタム・エスカレーション・ルールをプラグインできます。たとえば、タスクを期限切れ時に現在のユーザーの部門マネージャに割り当てるには、カスタム・タスク・エスカレーション関数を記述してワークフロー・サービスに登録し、その関数をタスク定義に使用できます。
デフォルトのエスカレーション・ルールでは、タスクは現在のユーザーのマネージャに割り当てられます。新規エスカレーション・ルールを追加する手順は、次のとおりです。
インタフェースoracle.bpel.services.workflow.assignment.dynamic.IDynamicTaskEscalationFunctionを実装します。この実装をサーバーのクラスパスで使用可能にする必要があります。
ファイルSOA_Oracle_Home¥bpel¥system¥services¥config¥wf-dynamic-assign-cfg.xmlを変更し、新規の関数を追加します。
<dynamicAssignmentFunctions>
<function name="MANAGERS_MANAGER"
classpath="oracle.bpel.services.workflow.assignment.dynamic.patterns.
TaskEscalationManagersManager">
</function>
</dynamicAssignmentFunctions>
「エスカレーション・ルールを指定してください。」フィールドに、wf-dynamic-assign-cfg.xmlファイルでエスカレーション・ルールについて定義されている関数名を入力します。
このオプションを使用すると、WordML XSLTスタイルシートを使用して電子メール添付ファイルとして送信するために、Microsoft Word文書を動的に作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。
懐中電灯アイコンをクリックし、添付ファイルとしてWordMLスタイルシートを選択します。
このオプションを使用すると、XSLTスタイルシートを使用して電子メール添付ファイルを作成できます。XSLTスタイルシートは、タスク・ドキュメントに適用されます。
懐中電灯アイコンをクリックし、添付ファイルとしてスタイルシートを選択します。
Oracle BPEL Worklistアプリケーションで様々な言語でタスク詳細を表示できるように、リソース・バンドルを指定できます。次のタスク詳細でリソース・バンドルがサポートされます。
プレーン・テキストまたはmessage(key)書式によるタスクの結果値の表示。
Oracle BPEL Worklistアプリケーションのペイロード表示へのXML要素名および属性名の表示。Oracle BPEL WorklistアプリケーションでのXML要素名を国際化するには、リソース・バンドル内のキー名がXML要素名および属性名と同一である必要があります。
様々な言語による電子メール通知メッセージの有効化。 実行時にXPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を指定して、指定のリソース・バンドルから国際化された文字列を取得します。通知受信者のロケールは、関数hwf:getNotificationProperty(propertyName)で取得できます。
「リソースの構成」をクリックします。
「リソースの詳細」ウィンドウが表示されます。
リソース・バンドルで使用されているリソース名を入力します。
懐中電灯アイコンをクリックし、使用するJARまたはZIPリソース・バンドル・ファイルを選択します。リソース・バンドルは、BPELスーツケースの一部でもかまいません。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
Oracle BPEL Worklistアプリケーションから実行されるアクションは、すべてのビジネス・プロセスに共通です。ただし、特定のビジネス・プロセスのいくつかのアクションは、制限することが可能です。
たとえば、融資承認プロセスにおいて、融資申請を保留しないというビジネス要件があるとします。このシナリオをモデリングするには、設計時に「一時停止」を制限付きアクションとして選択できます。アクションを制限付きとして選択すると、Oracle BPEL Worklistアプリケーションにはこのタスクのアクションが表示されません。
デフォルトでは、これらのアクションはユーザーの権限に応じてすべてのタスクに実行可能です。タスク所有者またはbpeladmin管理者は、所有するプロセスに対していつでもこれらのアクションを実行できます。
「アクションの構成」をクリックします。
タスクに対して許可するシステム・アクションを選択します。デフォルトでは、すべてが選択されており、使用可能です（無制限）。
次のシステム・アクションは、選択を解除することで制限できます。
一時停止: タスク所有者（またはBPMWorkflowSuspend権限を持つユーザー）は、ワークフローを一時的に保留できます。ワークフローが再開されるまで、タスクの有効期限とエスカレーションは適用されません。一時停止されているタスクについては、アクションを実行できません（再開または取消しを除く）。
プッシュバック: タスクをワークフロー内で1つ前のレベルに送信します。たとえば、タスクがLoanAgentGroupにルーティングされてからjsteinにルーティングされたとします。jsteinがタスクをプッシュバックすると、LoanAgentGroupに送信されます。
期限更新: タスクの期限切れが近づいている場合、タスク割当て先のユーザーは、タスクを更新してタスク実行のための期間延長をリクエストできます。この操作は、プロセス設計者によってワークフローのタスク期限更新が制限されている場合は、許可されません。
現在の割当てのスキップ: 現在の割当てをスキップして次の割当てに移動するか、他に割当て先が存在しない場合は、直前の承認者により設定された結果を使用します。
非定型ルート: 結果を入力して、タスクをレビューする必要のある次のユーザーに非定型フローの形式でタスクをルーティングできます。
情報のリクエスト: ワークフローのすべての参加者は、タスク起案者または前のいずれかのタスク承認者に詳細情報をリクエストできます。リクエストされた情報が発行されると、タスクは、その情報をリクエストしたユーザーに割り当てられます。
委任: すべてのワークフロー参加者は、タスクを他のユーザーに委任できます。この場合、委任されたユーザーは、現在の割当て先にかわって操作します。タスクが委任されると、元の割当て先または委任されたユーザーが操作するまで両方のユーザーのワークリストに残ります。
再割当て: 現在の割当て先がタスクを他のユーザーまたはグループに転送できるようにします。この場合、タスクは現在の割当て先のワークリストから新規の割当て先に移動します。
エスカレート: さらに操作するためにタスクをマネージャにエスカレートします。
取消: タスク起案者は、ワークフローを介して送信する必要がなくなった場合に、保留中のタスクを取り消すことができます。タスク所有者も、作成者のかわりにタスクを取り消すことが可能です。タスクが取り消されると、ビジネス・プロセスは、タスクの状態属性が「取消し済」に設定されてコールバックされます。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
タスクは、不正な割当てが原因でエラーになることがあります。不正な割当ては、次のような理由で発生します。
無効な割当て先: タスク割当て先のユーザーまたはグループがシステム内で有効なユーザーではない場合。
無効な動的割当て: 割当て先を動的割当て先として指定したために、動的XPath式が評価されない場合。
前述の場合、タスクはエラー発生としてマークされます。デフォルトでは、タスクのライフ・サイクルはそのアクションで完了します。ワークフロー・タスクのモデリング中に、ワークフローのエラー割当て先を指定できます。エラー割当て先が指定されている場合は、それが評価されてタスクが割り当てられます。エラー割当て先は、次のアクションを1つ実行できます。
非定型ルート: タスクを、そのタスクに実際に割り当てられているユーザーにルーティングします。非定型ルートを使用すると、タスクを順番に、またはパラレルなどでユーザーにルーティングできます。
再割当て: タスクを、このタスクに実際に割り当てられているユーザーに再割当てします。
エラー・タスク: このタスクを修正できないことを示します。
エラー割当て先の評価中にエラーがあると、タスクはエラー発生としてマークされます。
このウィンドウでは、割当てエラーが発生した場合にタスク割当て先となるユーザーまたはグループを指定できます。
「割当ての構成」をクリックします。
エラー割当て先を選択します。
タスクのライフ・サイクル中にコールするように、ワークフロー・サービスのコールバックを登録できます。コールバック・クラスは、インタフェースoracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装する必要があります。コールバック・クラスをサーバーのクラスパスで使用可能にします。
「コールバックの構成」をクリックします。
「+」記号をクリックして表にコールバックを追加します。「コールバック」列にOnAssignedというコールバックが自動的に追加されます。
「OnAssigned」をクリックして他のコールバック値のリストを表示し、この列の値を選択します。
使用可能なコールバックは、次のとおりです。
OnCompleted: このコールバックは、タスクが完了するか、期限切れ、取消しまたはエラーになるときに起動されます。
OnAssigned: このコールバックは、次のアクションが原因でタスクが新規の割当て先セットに割り当てられるときに起動されます。
結果の更新
現在の割当てのスキップ
ルーティング・スリップの上書き
OnUpdated: このコールバックは、onTaskCompleteまたはonTaskAssignedコールバックに該当しないタスクに対する他の更新の際に起動されます。これには、情報のリクエスト、情報の発行、エスカレーション、再割当てなどによるタスクの更新が含まれます。
OnSubtaskUpdated: このコールバックは、サブタスクに対する更新の際に起動されます。
「タイプ」列で「Java」をクリックして、この列の他の値のリストを表示します。
「値」列の空のフィールドをクリックして値を入力します。この値は、oracle.bpel.services.workflow.task.IRoutingSlipCallbackを実装するJavaクラスの完全クラス名です。
「OK」をクリックします。
図15-28に示す「ヒューマン・タスク - 詳細」タブで「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択した場合は、同じ名前のチェック・ボックスを選択する必要があります。両方のチェック・ボックスを選択すると、コールバックのメタデータが更新されます。
ヒューマン・タスクの変更は、いつでも保存できます。アプリケーション・ナビゲータでメタデータ・タスク構成ファイル（.task）をクリックすると、後でタスクを再編集できます。
「ファイル」メイン・メニューから「保存」を選択するか、「X」記号をクリックしてメタデータ・タスク構成ファイル（.task）を閉じます。 
図ht_exit.gifの説明
「X」記号をクリックした場合は、プロンプトで「はい」を選択して変更内容を保存します。
ヒューマン・タスク設定を構成する.taskファイルをBPELプロセスに関連付ける必要があります。関連付けが完了すると、タスク・サービス・パートナ・リンクが作成されます。タスク・サービスでは、タスクの操作に必要な操作が公開されます。
タスクがすでにBPELプロセスに関連付けられているかどうかは、ヒューマン・タスクの作成方法により確認できます。表15-11に、これらの方法と、次のタスクの実行方法に関する参照先を示します。
|
注意: ヒューマン・タスクをBPELプロセスに関連付けたかどうかに関係なく、主要なヒューマン・タスク・アクティビティのプロパティ（タスクのタイトル、起案者、優先度およびパラメータ変数など）を定義する必要があることに注意してください。これらのタスクについては、「ヒューマン・タスク・アクティビティのタイトル、起案者、優先度およびパラメータ変数の定義」および「ヒューマン・タスク・アクティビティの拡張機能の定義」を参照してください。 |
表15-11 ヒューマン・タスクとBPELプロセスの関連付け
| ヒューマン・タスク作成方法 | 現在の状態 | 参照先 |
|---|---|---|
|
ヒューマン・タスクをBPELプロセスに関連付ける必要があります。 | 「ヒューマン・ワークリスト・タスクとBPELプロセスの関連付け」 |
|
ヒューマン・タスクはBPELプロセスに関連付けられています。 | 「BPELプロセスに関連付けられているヒューマン・タスク・アクティビティのオープン」 |
アプリケーション・ナビゲータで、ヒューマン・タスクの.taskファイルを関連付けるBPELプロセスを選択します。
コンポーネント・パレットから「プロセス・アクティビティ」を選択します。
新規のHuman TaskアクティビティをBPELプロセスにドラッグ・アンド・ドロップします。
「ヒューマン・タスクの追加」ウィンドウが表示されます。
|
注意: このアクティビティをOracle JDeveloperに初めてドラッグ・アンド・ドロップする場合、ウィンドウ名は「ヒューマン・タスクの追加」となっています。このウィンドウで詳細を指定して「OK」をクリックすると、このウィンドウの名前が「ヒューマン・タスク」に変わります。 |
「タスク定義」フィールドの右側にある最初のアイコンをクリックします。
「タスク定義ファイルの選択」が表示されます。
.taskファイルを選択して「開く」をクリックします。このファイルは、BPELプロセスのbpel¥human_task_nameディレクトリにあります。
.taskファイルが「タスク定義」フィールドに追加されます。
次の項を参照してヒューマン・タスク・アクティビティを構成します。
BPELプロセス内で前に作成したHuman Taskアクティビティをダブルクリックします。
「ヒューマン・タスク」ウィンドウが表示されます。
「タスク定義」フィールドの右側にある3番目のアイコンをクリックして、前に作成したヒューマン・ワークリスト・タスクを開きます。
次の項を参照してヒューマン・タスク・アクティビティを構成します。
図15-27に「一般」タブを示します。
Human Taskアクティビティの「一般」タブでは、表15-12に示すタスクを実行できます。
表15-12 「ヒューマン・タスク - 一般」タブ
| フィールド | 参照先 |
|---|---|
| タスクのタイトル | 「タスクのタイトルの指定」 |
| 起案者
優先度 |
「タスクの起案者と優先度の指定」 |
| タスク・パラメータ | 「タスク・パラメータの指定」 |
次のいずれかの方法で「タスクのタイトル」フィールドにタスクのタイトルを入力します。これは必須フィールドです。このフィールドに入力したタイトルにより、「タスクのタイトルと優先度の指定」の説明に従ってヒューマン・タスク・エディタの「役職」フィールドに入力したタスクのタイトルが上書きされます。実行時には、タスクがこのタイトルでOracle BPEL Worklistアプリケーションに表示されます。
タイトルを手動で入力します。
フィールドの右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、タイトルを動的に作成します。
同じタイトルに静的なテキストと動的な式を併用することもできます。動的なテキストを使用するには、テキストの適切な位置にカーソルを置き、右側にあるアイコンをクリックして「式ビルダー」ウィンドウを起動します。
「起案者」フィールドに起案者（jcooperなど）を入力するか、右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、起案者を動的に指定します。このフィールドはオプションです。
起案者とは、タスクを開始するユーザーです。起案者はOracle BPEL Worklistアプリケーションから自分が作成したタスクを参照したり、「システム・アクション詳細」ウィンドウで定義した特定のタスク（タスクの取消しや一時停止など）を実行できます。起案者を指定しなければ、「ヒューマン・タスク」ウィンドウの「詳細」タブで指定したタスク所有者にデフォルト設定されます。タスク所有者も指定されていなければ、起案者はbpeladminにデフォルト設定されます。
「優先度」リストで1（最高）から5の優先度値を選択します。このフィールドはユーザー参照用であり、このタスクの優先度が実行時に高くなることはありません。優先度を使用して、Oracle BPEL Worklistアプリケーションでタスクをソートできます。この優先度値により、ヒューマン・タスク・エディタの「優先度」リストで選択した優先度値が上書きされます。
「タスクのタイトル」および「起案者」フィールドへの入力を完了すると、タスク・パラメータ表にタスク・パラメータのリストが表示されます。
「BPEL変数」列で懐中電灯をクリックしてタスク・パラメータをBPEL変数にマップします。マップする必要があるのは、入力データを使用するタスク・パラメータのみです。ワークリストから入力される出力データの場合、対応する変数にマップする必要はありません。
「タスク・パラメータ」ウィンドウが表示されます。
「変数」ナビゲーション・ツリーを開き、適切なタスク変数を選択します。
「OK」をクリックします。
次のような「ヒューマン・タスク」ウィンドウが表示されます。
「適用」をクリックします。
ヒューマン・タスク・アクティビティの拡張機能を定義する場合は、「詳細」タブをクリックして「ヒューマン・タスク・アクティビティの拡張機能の定義」に進みます。それ以外の場合は、「OK」をクリックして「ヒューマン・タスク」ウィンドウを閉じます。
図15-28に「詳細」タブを示します。
Human Taskアクティビティの「詳細」タブでは、表15-13に示すタスクを実行できます。
表15-13 「ヒューマン・タスク - 詳細」タブ
| フィールド | 参照先 |
|---|---|
| スコープ名
グローバル・タスク変数名 |
「スコープ名とグローバル・タスク変数名の指定」 |
| 所有者 | 「タスク所有者の指定」 |
| 識別キー | 「識別キーの指定」 |
| タスク履歴の追加元 | 「他のヒューマン・タスクのタスク履歴の追加」 |
| BPELコールバックのタスクとルーティング・カスタマイズを許可 | 「BPELコールバックのタスクとルーティング・カスタマイズの許可」 |
デフォルトのスコープ名とグローバル・タスク変数名は、ヒューマン・タスク・アクティビティの作成時に自動的に入力されます。ただし、カスタム名を指定して、ヒューマン・タスク・アクティビティの作成時にスコープ名とグローバル変数名に使用できます。
「スコープ名」フィールドに、生成するBPELスコープの名前を入力します。
このBPELスコープにより、ワークフロー・サービスとBPEL変数の操作を使用する相互作用全体がカプセル化されます。
「グローバル・タスク変数名」フィールドにグローバル・タスク変数名を入力します。
これは、ワークフローの相互作用に使用されるBPELタスク変数の名前です。
「所有者」フィールドにタスク所有者名を入力するか、右側にあるアイコンをクリックし、「式ビルダー」を使用してこのタスクの所有者を動的に指定します。
タスク所有者は、所有するビジネス・プロセスに属するタスクを参照し、タスク割当て先のユーザーにかわって操作を実行できます。また、所有者は、タスクの再割当て、取消しまたはエスカレートも行うことができます。
「ヒューマン・タスク」ウィンドウの「一般」タブでタスク起案者を指定しなければ、ここで指定した所有者にデフォルト設定されます。所有者を指定しなければ、bpeladmin管理者にデフォルト設定されます。
「識別キー」フィールドに識別キーの値を入力します（オプション）。
識別キーは、タスクのユーザー定義IDとして使用できます。たとえば、注文書の承認に関するタスクの場合、タスクの識別キーとして注文書IDを設定できます。タスクは、識別キーを基準にOracle BPEL Worklistアプリケーションで検索できます。この属性にデフォルト値はありません。
この機能により、あるワークフローを別のワークフローに続けることができます。
「タスク履歴の追加元」チェック・ボックスを選択して、BPELプロセス内の前のワークフロー・タスクを拡張します。このチェック・ボックスを選択すると、前のタスクからタスク履歴、コメントおよび添付ファイルが追加されます。これにより、完全なエンドツーエンドの監査証跡が得られます。
ワークフロー・タスクを別のワークフローに続ける場合、次の情報が新規ワークフローに持ち越されます。
タスク・ペイロードと、前のワークフローでペイロードに追加された変更内容
タスク履歴
前のワークフローでタスクに追加されたコメント
前のワークフローでタスクに追加された添付
「タスク履歴の追加元」リストに、既存のワークフローがすべて表示されます。特定のワークフローを選択することで、そのワークフローを拡張（継続）できます。
たとえば、雇用プロセスを使用して、新規従業員を採用します。各面接担当者は、候補者を雇用するかどうか投票します。投票者の75%が雇用に賛成の場合、候補者は採用されます。そのパーセントに満たない場合、候補者は採用されません。候補者が採用されると、HRデータベースにエントリが作成され、人事担当者が雇用プロセスを完了します。人事担当者は、各面接担当者と、候補者に関するコメントを確認する必要があります。このプロセスは、雇用にグループ投票を使用することでモデリングできます。候補者が採用される場合は、データベース・アダプタを使用してHRデータベースにエントリが作成されます。その後、応募申込み書、履歴書、および面接担当者のコメントを持ち越すように、単純ワークフローでグループ投票からのタスク履歴を追加できます。この単純ワークフローは、人事担当者に割り当てます。
タスクが別のユーザーにルーティングされるか、タスクのステータスが変化するたびに、OnMessageコールバックを使用してBPELプロセスを通知するには、「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。コールバックのメタデータを更新するために、図15-26に示したヒューマン・タスク・エディタの「詳細設定」セクションでも同じ名前のチェック・ボックスを選択する必要があります。
これらのコールバックでは、タスク・サービスをコールしてルーティングを変更したり、現行の割当て先を更新できます。このオプションは、タスク・サービスと対話するために生成されたBPELコードに影響します。
このオプションを選択しなければ、クライアント・プロセスにはタスクの完了時、期限切れ時またはエラー発生時にのみ通知されます。
「OK」をクリックして「ヒューマン・タスク」ウィンドウを閉じます。
このヒューマン・タスク（.taskファイル）のヒューマン・タスク・エディタに移動します。
エディタの下部にある「詳細設定」セクションを開きます。
「BPELコールバックのタスクとルーティング・カスタマイズを許可」をクリックします。
コールバックを使用するには、このチェック・ボックスを選択する必要があります。これにより、メタデータの更新が可能になります。
ヒューマン・タスク・アクティビティのモデリングを完了すると、デザイナ・ウィンドウでヒューマン・タスクが生成されます。
図15-29に、Oracle BPEL Process Managerでワークフロー相互作用をモデリングする方法を示します。この図は、BPELコールバックがモデリングされていない場合の相互作用も示しています。この場合、タスクが完了すると、完了したタスクを使用してBPELプロセスがコールバックされます。中間のイベントはBPELプロセス・インスタンスに伝播しません。ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。
図15-30に、Oracle JDeveloperにおけるワークフロー相互作用を示します。
中間のイベントをBPELプロセス・インスタンスに伝播させる必要がある場合は、「ヒューマン・タスク」ウィンドウの「詳細」タブとヒューマン・タスク・エディタの「詳細設定」セクションの両方で「BPELコールバックのタスクとルーティング・カスタマイズを許可」チェック・ボックスを選択します。この2つのオプションが選択されている場合、ワークフロー・サービスはタスクの更新ごとにBPELインスタンス内でコールバックを起動します。次のコールバックがTaskService.wsdlファイルにリストされます。
onTaskCompleted: このコールバックは、タスクが完了するか、期限切れ、取消しまたはエラーになるときに起動されます。
onTaskAssigned: このコールバックは、次のアクションが原因でタスクが新規の割当て先セットに割り当てられるときに起動されます。
結果の更新
現在の割当てのスキップ
ルーティング・スリップの上書き
onTaskUpdated: このコールバックは、onTaskCompleteまたはonTaskAssignedコールバックに該当しないタスクに対する他の更新の際に起動されます。これには、情報のリクエスト、情報の発行、エスカレーション、再割当などによるタスクの更新が含まれます。
onSubTaskUpdated: このコールバックは、サブタスクに対する更新の際に起動されます。
図15-31に、Oracle BPEL Process Managerでコールバックを使用したワークフロー相互作用をモデリングする方法を示します。このタスクが開始されると、タスクが完了するまでwhileループを使用してメッセージが受信されます。whileループには、4つのonMessageブランチ（前述したコールバック操作ごとに1つずつ）を持つpickが含まれています。ワークフロー相互作用は、onMessageブランチに何も変化がなくても正常に機能します。つまり、onMessageブランチでのカスタマイズは不要です。
このシナリオでは、ワークフロー・コンテキストはBPELインスタンスで取得されます。このコンテキストをワークフロー・サービスとのすべての相互作用に使用できます。たとえば、グループに割り当てられているタスクを再割当てする場合は、タスク・サービスにreassignTask操作のワークフロー・コンテキストが必要です。
ユーザー・カスタマイズは、最初のassignであるAssignTaskAttributesで実行し、AssignSystemTaskAttributesを変更しないことをお薦めします。
図15-32に、Oracle JDeveloperにおけるワークフロー相互作用を示します。
多くの場合、ビジネス・プロセスのフローは、タスクの結果によって決定されます。ビジネス・ロジックのモデリングを容易にするため、ユーザー・タスクの生成時に、BPELのswitchアクティビティがビルトインのcaseアクティビティとともに生成されます。デフォルトで、タスクの作成中に選択された結果ごとに1つのcaseブランチが作成されます。また、タスクの取消し、期限切れ、エラー発生の各状態に対応するotherwiseブランチもswitchに生成されます。
転送されるタスクには、ペイロードが含まれます。ペイロードがビジネス・プロセス変数から設定される場合、ペイロードをタスクからソースにコピーして戻すために、copyPayloadFromTaskというassignアクティビティが各caseおよびotherwiseブランチに作成されます。ペイロードが他のXPath式（ora:getNodes(...)など）で表現されている場合、ペイロードをコピーするためのプロセス変数が存在しないため、このassignは作成されません。ペイロードを変更する必要がない場合、このassignは削除できます。
デフォルトでは、switchアクティビティには通常の結果のみに対応するcase文が含まれます。その他のタスク結果は、otherwiseブランチで取得されます。これらの結果は、次のとおりです。
タスクの取消し
タスクでのエラー発生
タスクの期限切れ
ビジネス・ロジックをその他の結果にそれぞれ追加する必要がある場合、case文をこれらの各条件に追加できます。case文は、次のBPELセグメントのように作成できます。その他の結果に対応する各caseアクティビティのXPath条件は、太字で示されています。
<switch name="taskSwitch">
<case condition="bpws:getVariableData('SequentialWorkflowVar1',
'/task:task/task:state') = 'COMPLETED' and
bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:conclusion') = 'ACCEPT'">
<bpelx:annotation>
<bpelx:pattern>Task outcome is ACCEPT
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'WITHDRAWN'">
<bpelx:annotation>
<bpelx:pattern>Task is withdrawn
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'EXPIRED'">
<bpelx:annotation>
<bpelx:pattern>Task is expired
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'ERRORED'">
<bpelx:annotation>
<bpelx:pattern>Task is errored
</bpelx:pattern>
</bpelx:annotation>
...
</case>
<otherwise>
<bpelx:annotation>
<bpelx:pattern>Task is EXPIRED, WITHDRAWN or ERRORED
</bpelx:pattern>
</bpelx:annotation>
...
</otherwise>
</switch>
タスク表示フォームでは、Oracle BPEL Worklistアプリケーションでのタスク・ペイロードの表示メカニズムを定義します。この項では、使用可能な各種のタスク表示フォームについて説明します。
この項の内容は次のとおりです。
ヒューマン・タスク用のタスク表示フォームは、自動的に生成してからカスタマイズする方法と、ワークフローAPIを使用して新規に開発する方法があります。自動的に生成する場合、タスク・フォームには一連のシード済テンプレートおよびリージョンが使用されます。タスク定義に関連したフォームを生成するには、次の2つの方法があります。
単純タスク・フォームを自動的に生成: 標準のヘッダー、本体およびフッターのテンプレートを使用するJSPベースのフォーム。
カスタム・タスク・フォーム: 既存のテンプレートおよびリージョンから1つ選択してタスク・フォームを作成できます。フォームに表示するタスク・パラメータも指定できます。
タスク表示フォームの生成時に、テンプレートのURIおよびリージョン情報を含む.tformファイルが作成されます。.tformファイルは、プロセス・デプロイメント・アーカイブに含まれており、プロセスとともにデプロイされます。
ヒューマン・タスク用のタスク表示フォームを生成する手順は、次のとおりです。
Oracle JDeveloperでアプリケーション・ナビゲータにナビゲートします。
タスク表示フォームの作成対象となるヒューマン・タスクのフォルダを右クリックします（この例ではExpenseRequest BPELプロセスのExpenseApprovalが選択されています）。
選択したフォルダについて次のメニューが表示されます。
各種タスク・フォームの生成の詳細は、以降の各項を参照してください。
| 選択 | 参照先 |
|---|---|
| 単純タスク・フォームの自動生成 | 「単純タスク表示フォームの自動生成」 |
| カスタム・タスク・フォーム | 「カスタム・タスク表示フォームの生成」 |
アプリケーション開発フレームワーク（ADF）データ・コントロールに対するタスク表示フォーム・サポートのプレビュー・リリースが用意されています。このプレビュー・リリースでは、最小限のサポートが提供されます。次の制限に注意してください。
繰返し要素を含む複雑なXSDはサポートされていません。
ADFデータ・コントロールを使用して生成されたタスク・フォームは編集できません。
このプレビュー・リリースを使用する手順は、次のとおりです。
オペレーティング・システムのコマンド・プロンプトを開きます。
Oracle JDeveloperをプレビュー・モードで開きます。
JDev_Oracle_Home¥jdev¥bin¥jdev.exe -J"-Dpreview_mode=true"
「タスク表示フォームの選択」の手順2に示すように、ヒューマン・タスクのフォルダを右クリックすると、メニュー・オプションとして「ADFデータコントロールによるタスク・フォームの自動生成」が表示されるようになったことに注意してください。
SOA_Oracle_Home¥j2ee¥OC4J_Home¥config¥server.xmlファイルを開きます。
OC4J_Homeは、インストール・タイプに対応するOC4Jコンテナの名前です。
home: Oracle Application Server SOA Basicインストール・タイプの場合
OC4J_SOA: Oracle Application Server SOA Advancedインストール・タイプのデフォルト値を受け入れた場合
<shared-library name="oracle.bpel.common" version="10.1.3">セクションに次の行を追加します。
<import-shared-library name="adf.oracle.domain"/>
変更を有効にするためにOracle Application Server SOA Suiteを再起動します。
このオプションを使用すると、デフォルトのタスク・パラメータと3つのリージョンに基づいて、タスク・フォームを自動的に生成できます。
手順2に示したリストから「単純タスク・フォームの自動生成」を選択します。
デフォルト・レイアウトは、次の3つのリージョン・テンプレートに基づいています。
ヘッダー・リージョン: このリージョンには、タイトル、優先度、作成日、割当て先および有効期限など、標準的なタスク属性があります。この情報はHeader1.jspファイルに含まれています。
本体リージョン: このリージョンはタスク・パラメータに基づいて生成されます。タスクに使用するXSDに応じて、値リストまたは表（項目を繰り返す場合）として生成されます。手順2の「タスク・パラメータの追加」ウィンドウでパラメータをワークリストにより変更可能として指定した場合は、フォームに編集可能フィールドとして表示されます。それ以外の場合、フィールドは読取り専用として表示されます。このリージョンの情報は、payload-body.jspファイルとpayload-body.xmlマッピング・ファイルに含まれています。生成後に読取り専用パラメータの変更が必要になった場合は、payload-body.xmlファイルを変更できます。
フッター・リージョン: このリージョンには、コメント、添付ファイルおよびタスク・ルーティングの短い履歴用の領域があります。この情報はFooter1.jspファイルに含まれています。
.tformファイルが生成されます。このファイルの内容は、次のとおりです。
<?xml version = '1.0' encoding = 'UTF-8'?>
<taskDisplay
targetNamespace="http://xmlns.companyABC.com/workflow/orderTaskDisplay"
generateInternationlizedJSP="false"
xmlns:task="http://xmlns.oracle.com/bpel/workflow/task"
xmlns="http://xmlns.oracle.com/bpel/workflow/taskDisplay">
<taskDefinitionId>${domain_id}_${process_id}_${process_revision}_
Workflow_Name</taskDefinitionId>
<applicationName>worklist</applicationName>
<template>${http_url}/${domain_id}/${process_id}/${process_
revision}/Workflow_Name/Template_Name.jsp</template>
<regions>
<defaultJSP regionName="Header">
<jspURI>Header1.jsp</jspURI>
</defaultJSP>
<autoGeneratedJSP regionName="Body" editable="true">
<jspURI>payload-body.jsp</jspURI>
<messageAttribute
editable="false">Workflow_NameProcessRequest</messageAttribute>
</autoGeneratedJSP>
<defaultJSP regionName="Footer">
<jspURI>Footer1.jsp</jspURI>
</defaultJSP>
</regions>
</taskDisplay>
自動生成JSPのペイロードを表示するために、次の2つのファイルが自動的に生成されます。
デフォルトのJSPファイルpayload-body.jsp。このファイルは、プロジェクトのHTMLルート・ディレクトリ（デフォルトではpublic_htmlディレクトリ）に追加されます。
マッピングXMLファイルpayload-body.xml。このファイルは、payload-body.jspと同じプロジェクト・ディレクトリに追加されます。
|
注意: 手順2で「カスタム・タスク・フォーム」を選択した場合は、自動生成JSPについて一意のファイル名を指定できます。マッピングXMLファイルはJSPファイル名に基づいて作成されます。また、自動生成JSPに含めるペイロード要素も選択できます。たとえば、JSPファイル名がautogenerate-body.jspであれば、マッピングXMLファイル名はautogenerate-body.xmlとなります。
詳細は、「カスタム・タスク表示フォームの生成」を参照してください。 |
JSPファイルのコンパイル用として、JSPランタイム・ライブラリとBPMWorkflowライブラリがBPELプロジェクトに自動的に追加されます。デフォルトのJSPファイルは次の2つの目的を想定して設計されています。
単純なフォームの提供。このJSPを使用することで、深さが3より大きいXSDツリーを読みやすいように表示すること。
変更が最小限で済むデフォルトJSPの提供。変更が避けられない場合は、ユーザー・インタフェース・ツールで容易に行うことができます。
これらの目的を達成するため、デフォルトJSPは、ペイロードXSD構造を模倣するツリー構造を表示せずに、ペイロード構造全体を複数のセクションにグループ化しています。この場合、同じ親に属する単純型がグループ化され、セクションを構成します。
たとえば、次のペイロードXSDが指定されているとします。
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.mycompany.com/mycompany"
xmlns:mp="http://www.mycompany.com/mycompany">
<element name="myCompany" type="mp:myCompanyType"/>
<complexType name="myCompanyType" >
<sequence>
<element name="board" type="mp:boardType" />
<element name="CEO" type="string"/>
<element name="department" type="mp:departmentType" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="boardType">
<sequence>
<element name="size" type="int" />
<element name="head" type="string" />
</sequence>
</complexType>
<complexType name="departmentType">
<sequence>
<element name="size" type="int" />
<element name="head" type="string" />
<element name="function" type="string" />
</sequence>
</complexType>
</schema>
図15-33に、このXSDの構造を示します。
デフォルトJSPには、リーフ・ノードの構造に基づいて、{size, head}、{CEO}、{size, head, function}という3つのセクションが含まれます。これら3つのセクションは、その親の名前に基づいて名前が付けられます。つまり、それぞれboard、myCompanyおよびdepartmentという名前が付けられます。boardセクションには、sizeおよびheadの2つのフィールドがあります。各フィールドは、編集可能なHTML入力タイプです。セクションdepartmentは他のセクションとは異なり、複数の出現を持つことができます（maxOccurs > 1）。この場合、このセクションのすべてのフィールド（size、headおよびfunction）は、各行が1つの部門を示すように表に水平に表示されます。これは表セクションと呼ばれます。department表セクションには、行（department）を追加するプラス（+）のボタンと行を削除するマイナス（-）のボタンが用意されています。通常のセクションとは異なり、すべてのフィールドが必ずしも表セクションの同じXSDの親に属しているとはかぎりません。たとえば、head要素にemployeeNumberおよびdateOfBirthの2つの要素があるとします。これら2つの要素は、maxOccursが1以下に設定されているため、同じdepartment表セクションに表示されます。これは望ましい動作です。department表に行を追加すると、sizeおよびfunctionフィールドのみでなく、head情報フィールドも同じdepartment行に追加されるためです。これにより、複雑なペイロード・インスタンス間の移動が容易になります。
複数のネストされた要素（maxOccurs > 1）がサポートされます。department要素に、groupMemberという子要素があり、この子要素のmaxOccursが無制限であるとします。この場合、親要素departmentは表セクションに存在するのに対し、子要素groupMemberは独立した子表セクションに存在します。親であるdepartment表セクションにはgroup member列が存在し、この列には子であるグループ・メンバー・セクションを参照するHTML hrefリンクが含まれます。親departmentセクションで「+」ボタンを押すと、親表に行が追加されるのみでなく、その新しい行に子セクションも追加されます。
現在のリリースのデフォルトJSPには次の制限があります。
繰返し要素を含むXSDはサポートされていません。
デフォルトJSPには、ペイロードXSDに定義されているすべての単純型が表示されます。複数の単純型が同じXSDのchoiceブロックに属する場合、これらすべての単純型は、デフォルトJSPに表示されます。単純型はJSPに保持されますが、XSDの制限とは無関係です。
サポートされるのは、単純型ではない変数からコピーされたペイロードのみです。たとえば、問合せがbpws:getVariableData(var)またはbpws:getVariableData(var, part)で、変数が単純型の場合、JSP生成は失敗します。bpws:getVariableData(var, part, query)およびbpws:getVariableData(var, query)は、問合せデータが単純型でも機能することに留意してください。変数自体が単純型でないことだけを確認する必要があります。
XSI拡張はサポートされていません。
XSD順序インジケータ（choice、allおよびsequence）に対する特別な処理は行いません。たとえば、デフォルトJSPは、firstnameおよびlastnameの両方を入力したかどうかをチェックしません。
<xs:element name="person">
<xs:complexType>
<xs:all>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:element>
自動生成されたデフォルトJSPは、汎用のものであるため、場合によってはルック・アンド・フィールを改善するための変更が必要です。JSPは、ペイロード内のどの要素をフォームに表示するかを決定するマッピング・ファイルと組み合せることで機能します。
マッピング・ファイルにより、表示形式を制御できます。マッピング・ファイルは、表示可能なフィールドのリストを含むXMLファイルです。マッピング・ファイルのルート要素には、targetNameSpaceとその他のネームスペース、およびその属性としてのxmlEditableが含まれます。
単純型のすべての要素は、マッピング・ファイルにフィールドとしてリストされます。これらの要素とともに、要素の直接の親も多言語サポート用にリストされます。各フィールドには、マッピング・ファイルで定義された3つのプロパティが含まれます。xpath、editableおよびresource_keyです。
xpathプロパティは、そのフィールドのXPathを定義します。このプロパティには、接頭辞として常に/ns0:task/ns0:payloadが付きます。これは、ペイロード・オブジェクトのルートへのXPathです。maxOccursが1を超えている場合、[*]によって示されます。たとえば、/ns0:task/ns0:payload/company[*]/ceoは、companyフィールドのmaxOccursが1を超えていることを示します。
|
注意: このXPathフィールドは、フィールドのIDを決定する一意キーでもあるため、変更しないでください。 |
editableプロパティは、そのフィールドが編集可能であるかどうかを定義します。このプロパティは、デフォルトでtrueに設定されます。このフィールドの値をfalseに変更すると、デフォルトJSPには、値の変更が禁止された無効なテキスト・フィールドが表示されます。
resource_keyプロパティは、多言語サポートに使用されます。自動生成JSPに英語以外で優先する言語を表示するには、リソース・バンドルを指定する必要があります。
リソース・バンドルを追加する手順は、次のとおりです。
バンドル・ファイル（MyBundleなど）を作成します。このファイルは、プロジェクトのルートに存在するプロパティ・ファイルを示しています。次のコードは、MyBundle_en-US.propertiesの例を示しています。
ACCEPT_MSG = Accept0 REJECT_MSG = Reject0 FLEX_STRING1_MSG = Flex String1 FLEX_LONG1_MSG = Flex Long1 FLEX_DATE1_MSG = Flex Date1 TASK_TITLE = i18n Task
このとき、フィールドがマッピング・ファイルで次のように定義されているとします。
<field>
<xpath>/ns0:task/ns0:payload/taskTitle</xpath>
<editable>true</editable>
<resourceKey>TASK_TITLE</resourceKey>
</field>
次の関数をコールします。
FormUtil.getElementDisplayName("/ns0:task/ns0:payload/taskTitle", ,
form, context.getLocale(), task)
ロケールがen-USに設定されている場合、デフォルトJSPには文字列i18n Taskが返されます。同様に、ロケールがフランス語に設定されている場合、適切なプロパティ・ファイル（MyBundle_fr.properties）が選択されます。
「多言語設定の指定」に示すように、ヒューマン・タスク・エディタの「リソースの詳細」ウィンドウでリソース・バンドルの名前と場所を指定します。
マッピング・ファイルでの制御が不十分な場合、デフォルトJSPファイルを変更できます。次のラベルの後のセクションのみが変更可能です。
/* Modify the code below when necessary */
JSP変更の大部分は、Oracle JDeveloperのJSP設計ビューで実行できます。
デフォルトでは、すべてのフィールドがテキスト・フィールドに設定されます。テキスト・フィールドをテキスト領域に変更する場合、次のようにします。
図15-34のように、コンポーネント・パレットで「Text Area」を選択します。
そのコンポーネントを、置き換えるテキスト・フィールドの位置にドロップします。
テキスト・フィールドの名前は、関数oracle.bpel.services.workflow.worklist.payload.PayloadFormGenerator.constructName(String xpath)をコールすることにより設定され、フィールドの値は、PayloadFormGenerator.selectNodeValue(Element payload, String xpath, Map namespace)により設定されます。フォーム・フィールド名を構成し、フィールド値を取得するには、これらの関数を使用する必要があります。
テキスト領域の名前と値を、テキスト・フィールドと同じ名前と値に設定します。
テキスト・フィールドは削除します。
表に含まれないテキストまたは他のHTML要素を挿入する場合、その場所に直接入力してテキストを追加するか、コンポーネント・パレットからHTMLコンポーネントをドラッグ・アンド・ドロップしてHTML要素を追加します。
HTML表に含まれるHTML要素を挿入する場合、テキストや水平線を挿入するには、最初に行を選択して右クリックし、「行の挿入」を選択して表の行を追加します。行が挿入されたら、必要に応じて、行内のすべてのセルを選択して右クリックし、「セルの結合」を選択してすべてのセルを結合します。これで、テキストを入力するか、HTMLコンポーネントをドラッグ・アンド・ドロップできます。
表またはフォームのレイアウトを変更する場合、変更するセクションを選択して右クリックし、「表」または「フォーム」を選択します。
テキストを書式設定する場合、ツールバーの「色」および「スタイル」ボタンを使用します。
デフォルトJSPのルック・アンド・フィールのみを変更することをお薦めします。JSPで使用される関数は保持している必要があります。また、HTMLフォームで送信される非表示パラメータは変更しないでください。「更新」ボタンにより、特定の値を受け入れるWFTaskUpdateに対するフォーム送信が実行されるためです。変更が複雑で、その変更にプログラミング・ロジックが含まれる場合は、ソース・ビューに切り替えてJSPコードを直接変更する必要があります。
デフォルトJSPに<%@ page pageEncoding="UTF-8" %>という文を配置すると、デフォルト・エンコーディングとしてUTF-8が設定されます。
|
関連項目: 自動生成JSPの例と、ペイロード表示の変更方法の詳細は、SOA_Oracle_Home¥bpel¥samples¥demosのHelpDeskServiceRequestデモを参照してください。
|
テキスト・ボックスのかわりに、選択可能なチェック・ボックスを表示するようにJSPページをカスタマイズする手順は、次のとおりです。
ステータスのinputが次のように生成されていることを確認します。
<input name="<%=PayloadFormGenerator.constructName("/ns0:task/ns0:payload/ns1:holds/ns
1:holdCodes[" + i3 + "]/ns1:status")%>"
value="<%=PayloadFormGenerator.selectNodeValue(payload,
"/ns0:task/ns0:payload/ns1:holds/ns1:holdCodes[" + i3 + "]/ns1:status",
form.getNamespaceMap())%>" dataType="string" <%=thisDisabled%> ></input>
手順1に示したコード・ブロック全体を次のコード・ブロックで置き換えます。
String checked = "";
String status = PayloadFormGenerator.selectNodeValue(payload,
"/ns0:task/ns0:payload/ns1:holds/ns1:holdCodes[" + i3 + "]/ns1:status",
form.getNamespaceMap());
if(status != null && status.equals("true"))
{
checked = "checked";
}
<input type="CHECKBOX"
name="<%=PayloadFormGenerator.constructName
("/ns0:task/ns0:payload/ns1:holds/ns
1:holdCodes[" + i3 + "]/ns1:status")%>" value="<%=status%>" <%=checked%>
onClick="changeStatusValue(this)" ></input>
次のJavaScriptを追加します。 この追加が必要となるのは、JavaScriptではチェック・ボックス・フィールドの値が常にinput要素で定義されている値であるためです。
function changeStatusValue(obj)
{
obj.value = obj.checked;
}
このリリースでは、タスク表示フォームは様々なリージョンで構成されるテンプレートを使用して生成されます。Oracle JDeveloperでは、3つのテンプレートと2つのデフォルトJSPが自動的に使用されます。
3つのテンプレートは、次のとおりです。
3リージョンJSP: ヘッダー、本体およびフッターの各リージョンで構成されます。これらのリージョンは、カスタムJSP、XSL、デフォルトJSPまたは自動生成JSPファイルを使用して表示できます。自動生成JSPでは本体リージョンが表示されます。
2リージョンJSP: ヘッダー・リージョンとフッター・リージョンで構成されます。
1リージョンJSP: 本体リージョンで構成されます。
2つのデフォルトJSPは次のとおりです。
ヘッダーJSPでは、タスク番号、優先度、タイトルなどのタスク属性が表示されます。
フッターJSPでは、添付ファイルやコメントなどのタスク属性が表示されます。
カスタム・タスク表示フォームを使用すると、タスク詳細の表示に使用するテンプレートとレンダリング・タイプを選択できます。
手順2に示したリストから「カスタム・タスク・フォーム」を選択します。
「フォームの表示タスク」ウィンドウが表示されます。
「現在のテンプレート」リストからテンプレートを選択します。3つのシード済リージョン（3リージョンJSP、2リージョンJSPおよび1リージョンJSP）があります。リージョンの選択後に、レンダリング方法を指定できます。
各種のカスタム・タスク表示フォームの生成の詳細は、次に示す各項を参照してください。
| タイプ | 参照先 |
|---|---|
| 自動JSP | 「自動生成JSP」 |
| カスタムJSP | 「カスタムJSP」 |
| デフォルトJSP | 「デフォルトJSP」 |
| XSL | 「XSL」 |
このオプションを選択すると、タスクのペイロード用のフォームを自動的に生成できます。オプションで、表示されるフォームに追加する特定のタスク・パラメータを指定することもできます。
「レンダリング」セクションの「本文」リストから「自動JSP」を選択します。
「ソース」セクションのBody.jspの右側にアイコンが表示されます。
このアイコンをクリックします。
「ペイロード・マッピング」ウィンドウが表示されます。
このウィンドウでメッセージ属性を選択できます。
自動生成JSPに追加するメッセージ属性を選択します。
「OK」をクリックして「フォームの表示タスク」ウィンドウに戻ります。
このオプションを使用すると、タスク詳細を表示する外部のカスタムJSPを起動できます。このJSPに実行時に渡すURLパラメータを指定することもできます。デフォルトでは、3つのパラメータtaskID、versionおよびworkflowContextが渡されます。他のパラメータは明示的に指定する必要があります。
「レンダリング」セクションの「ヘッダー」リストから「カスタムJSP」を選択します。
「ソース」セクションの右側に2番目のアイコンが表示されます。このアイコンをクリックすると、カスタムJSPパラメータを編集できます。
「ソース」フィールドにカスタムJSPファイル名を入力するか、最初のアイコンをクリックして、使用するJSPファイルを選択します。このJSPがプロジェクトに使用され、他のJSPファイルとともにデプロイされます。
2番目のアイコンをクリックしてランタイムJSPパラメータを指定します。
「ペイロード・マッピング」ウィンドウが表示されます。このウィンドウで入力JSPパラメータを追加できます。
「+」記号をクリックしてパラメータを追加します。
「名前」列に名前を追加します。
行の右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示し、「XPath」列の値を動的に入力します。
この例では、リクエストからタスクIDを受け取るように、カスタムJSPでPRIORITYというパラメータを使用しています。そのため、名前としてPRIORITYを指定し、XPath式として/tns:task/tns:systemAttributes/tns:PRIORITYを指定しています。
このオプションでは、ヘッダー・リージョンとフッター・リージョンの表示用にそれぞれデフォルトのHeader1.jspおよびFooter1.jspファイルが提供されます。
ワークフロー・タスク表示フォームは、deployTaskForm antターゲットを使用してデプロイされます。このターゲットは、Oracle JDeveloperまたはコマンド・プロンプトからBPELプロセスをデプロイするときに実行されます。このターゲットにより、生成済のデフォルトまたはカスタムJSPをすべて含んだEARファイルが生成されます。この生成EARファイルは、Oracle BPEL Process Managerアプリケーションの子としてデプロイされます。
次のディレクトリ構造が生成されます。
JDev_Oracle_Home¥jdev¥mywork¥application_name¥project_name¥public_html¥human_task_name¥form
次のサブディレクトリおよびファイルが作成されます。
J2EEエンタープライズ・アーカイブ・ディレクトリearが作成されます。EARデプロイメント・ディスクリプタが生成され、META-INFサブディレクトリに格納されます。
Webアーカイブ（WAR）ディレクトリwarが作成されます。このディレクトリには、次のファイルとサブディレクトリが含まれます。
スタイルシートとJavaServer Pagesファイル（ヘッダーの場合はHeader1.jsp）、（フッターの場合はFooter1.jsp）および（本体の場合はpayload-body.jspとpayload-body.xml）が生成され、warディレクトリに格納されます。
Webサービスのデプロイメント・ディスクリプタがサブディレクトリWEB-INFに生成されます。
アプリケーション・ナビゲータでヒューマン・タスク・フォルダを右クリックして「タスク・フォーム・ファイルの削除」を選択すると、すべてのフォーム関連ファイルを削除できます。
前述のように、ワークリストにタスク詳細をレンダリングするためのカスタムJSPを登録できます。BPELワークリストでは、登録済のカスタムJSPが起動されます。
カスタムJSPフォームを作成する手順は、次のとおりです。
リクエストからタスクID、バージョンおよびコンテキストIDを取得します。
コンテキストIDに基づいてワークフロー・コンテキスト・オブジェクトを取得します。
タスクIDとバージョンに基づいてタスク・オブジェクトを取得します。バージョンがNULLまたは空の場合は、タスク問合せサービスAPI getTaskDetailsByIdを使用します。それ以外の場合は、getTaskVersionDetails APIを使用します。
タスク・オブジェクト・メソッドを使用して、JSPに表示する値を取得します。
更新サポートの場合、次のパラメータ用に非表示のHTMLタイプを生成します。これにより、更新サーブレットでこれらのパラメータ値を読み取ることができます。
oracle.bpel.service.workflow.worklist.api.payload.PayloadConstants.WORKLIST_NEXT_PAGE_PARAMETER_NAME
oracle.bpel.service.workflow.worklist.api.payload.PayloadConstants.WORKLIST_LOGIN_PAGE_PARAMETER_NAME
oracle.bpel.service.workflow.worklist.api.payload.PayloadConstants.WORKLIST_ERROR_PAGE_PARAMETER_NAME
これらのパラメータの値は、カスタムJSPのサーブレット・リクエスト・オブジェクトで取得できます。ランタイムは、これらのパラメータを渡してカスタムJSPを起動します。
次のカスタムJSPコードは、ローカル問合せサービスおよび検証APIを使用するカスタムJSPを前述の手順に従って記述する方法を示しています。そのため、このJSPをhw_servicesアプリケーションの子としてデプロイします。同じアプリケーション・サーバーにデプロイしない場合は、ローカルAPIをリモートAPIで置き換えてください。
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ page import="java.util.*,
java.net.URLEncoder,
java.io.UnsupportedEncodingException,
java.text.*,
oracle.bpel.services.workflow.query.impl.TaskQueryService,
oracle.bpel.services.workflow.query.ITaskQueryService,
oracle.bpel.services.workflow.verification.IWorkflowContext,
oracle.bpel.services.workflow.verification.IVerificationService,
oracle.bpel.services.workflow.verification.impl.VerificationService,
oracle.bpel.services.workflow.task.model.Task,
oracle.bpel.services.workflow.task.model.IdentityType,
oracle.bpel.services.workflow.task.model.CommentType,
oracle.bpel.services.workflow.task.model.AttachmentType,
oracle.bpel.services.workflow.task.model.IdentityType,
oracle.bpel.services.workflow.worklist.display.Resource,
oracle.bpel.services.workflow.worklist.display.ResourceKeyConstants,
oracle.bpel.services.workflow.worklist.servlet.Constants,
oracle.bpel.services.workflow.worklist.api.util.WorklistUtil,
oracle.bpel.services.workflow.worklist.api.payload.PayloadConstant;"%>
<%
String taskId = request.getParameter(Constants.WORKLIST_TASKID_PARAMETER_
NAME);
String strTaskVersion = request.getParameter(Constants.WORKLIST_TASK_
VERSION_PARAMETER_NAME);
String contextId = request.getParameter(Constants.WORKLIST_CONTEXT_
PARAMETER_NAME);
int taskVersion = 0;
// incase strTaskVersion is null means user wants latest version
// from WFTask table
// else it wants from the WFTaskHistory table
if(strTaskVersion != null && !strTaskVersion.trim().equals(""))
{
try
{
taskVersion = Integer.parseInt(strTaskVersion);
}
catch(NumberFormatException exc)
{
//TO DO throw the exception
taskVersion = 1;
}
}
//no need to use Notm to get the task
Task task = (Task)session.getAttribute(Constants.SESSION_CURRENT_TASK_
OBJECT);
IVerificationService verificationService =
VerificationService.getVerificationService();
IWorkflowContext context = verificationService.getContext(contextId);
if(task == null)
{
ITaskQueryService queryService = TaskQueryService.getInstance();
if(taskVersion == 0)
{
task = queryService.getTaskDetailsById(context, taskId);
}
else
{
task = queryService.getTaskVersionDetails(context,taskId,taskVersion);
}
}
Locale locale = context.getLocale();
// get the TaskId and use above object
SimpleDateFormat dfshort = new SimpleDateFormat( "MM/dd/yy" );
SimpleDateFormat dflong = new SimpleDateFormat( "MM/dd/yy hh:mm a" );
String nextPage = request.getParameter(Constants.WORKLIST_NEXT_PAGE_
PARAMETER_NAME);
String loginPage = request.getParameter(Constants.WORKLIST_LOGIN_PAGE_
PARAMETER_NAME);
%>
カスタムJSPに更新サポートを追加するには、リモート・タスク・サービスAPIを使用してカスタムJSPのタスク値を更新するサーブレットを記述できます。
カスタムJSPの場合と同じ手順でタスク・オブジェクトを取得します。
タスク・オブジェクトを問い合せ、カスタムJSPフォームに基づいて値を設定します。
たとえば、カスタムJSPフォームでユーザーに優先度属性の更新を許可する場合は、優先度JSPフォーム値を取得してtask.setPriority(newvalue);をコールします。
リモート・タスク・サービスAPIを使用してタスクを更新します。
サーブレット・パラメータWORKLIST_NEXT_PAGE_PARAMETER_NAMEから値を取得します。このパラメータは、カスタムJSPページに非表示のパラメータとして含まれています。
ページをURLにリダイレクトします。
ヒューマン・タスクを含むBPELプロセスをOracle BPEL Controlで変更すると、Oracle BPEL Worklistアプリケーションでのタスクの表示に影響します。
「インスタンス」タブでアクティブなBPELプロセス・インスタンスを中断すると、関連タスクはOracle BPEL Worklistアプリケーション・ホームページの「ステータス」列で「失効」としてマークされます。
「インスタンス」タブでBPELプロセス・インスタンスを削除すると、すべての関連タスクが削除されます。
「BPELプロセス」タブでBPELプロセスをアンデプロイすると、関連タスクはOracle BPEL Worklistアプリケーション・ホームページの「ステータス」列で「失効」としてマークされます。
通知は、タスクの状態が変化したことをユーザーに警告するために送信されます。通知は、電子メール、電話ボイス・メッセージ、FAX、ポケットベル、SMSのいずれかのチャネルを通じて送信できます。
この項の内容は次のとおりです。
Oracle JDeveloperで電子メールおよび他のチャネルの通知サービスを構成した後、SOA_Oracle_Home¥bpel¥system¥services¥config¥ns_emails.xmlファイル内で通知サービスのNotificationModeパラメータをALLまたはEMAILに設定します。
デフォルトでは、この値はNONEに設定されます。これは、通知が送信されないことを意味します。NotificationMode属性に可能な値は次のとおりです。
ALL: 電子メール、SMS、ボイス、FAXおよびポケットベルの各チャネルが構成され、任意のチャネルを介して通知が送信されます。
EMAIL: 電子メール・チャネルのみが通知メッセージの送信用に構成されます。
NONE: チャネルは通知メッセージの送信用に構成されません。これはデフォルト設定です。
タスク通知は、ヒューマン・タスク・エディタでタスクの作成時に構成できます。異なるアクションについて様々なタイプの参加者に通知を送信することが可能です。タスク通知を送信できるアクションは、次のとおりです。
割当て: ユーザーまたはグループにタスクが割り当てられた場合。このアクションでは、タスク・アクション（獲得、非定型ルート、委任、エスカレート、タスク情報の発行、プッシュバック、再割当て、リリースおよび再開）が取得されます。
タスクの完了。
タスクでのエラー発生。
タスクの期限切れ。
タスクに対する情報のリクエスト。
タスクの結果の更新。
タスクの一時停止。
タスクの取消し。
通知は、様々な範囲でタスクに関与するユーザーに送信できます。次のユーザーが含まれます。
割当て先: タスクが現在割り当てられているユーザーまたはグループ
起案者: タスクを作成したユーザー
作成者: タスクを作成したユーザー
承認者: これまでにタスクを承認したすべてのユーザー
これは、複数のユーザーがタスクを承認した「承認者の順序リスト」参加者タイプに適用されます。通知は、これらのユーザー全員に送信される必要があります。
所有者: タスクの所有者
タスクがグループに割り当てられている場合、そのグループに通知エンドポイントが設定されていなければ、グループの各ユーザーに通知が送信されます。
|
関連項目:
|
各電子メール通知には、次のパートを含めることができます。
通知メッセージ
ワークリスト・アプリケーションからのHTMLコンテンツ: タスクに関するワークリスト・アプリケーションの読取り専用ビュー
タスク添付ファイル: 通知にタスク添付ファイルが含まれる場合
アクション可能リンク
SMS、ボイス、FAXおよびポケットベルを介した通知に含まれるのは、通知メッセージのみです。
通知メッセージは、静的なテキストと動的な値を含めることのできるXPath式です。メッセージの作成時に動的な値に使用できるのは、タスクBPEL変数のみです。メッセージはBPELプロセスのコンテキスト外で評価されるため、この制限があります。また、タスク変数のペイロードでは、XPathツリー参照用のペイロードの型を含むために、強い型指定が使用されます。XPath拡張関数hwf:getNotificationProperty(propertyName)を使用すると、特定の通知のプロパティを取得できます。この関数は、通知ごとに対応する値と評価されます。propertyNameの値は、次のいずれかになります。
recipient: 通知の受信者
recipientDisplay: 受信者の表示名
taskAssignees: タスク割当て先
taskAssigneesDisplay: タスク割当て先の表示名
locale: 受信者のロケール
taskId: 通知対象となるタスクのID
taskNumber: 通知対象となるタスクの番号
appLink: ワークリスト・アプリケーションのタスク詳細ページへのHTMLリンク
次の例に、hwf:getNotificationPropertyとhwf:getTaskResourceBundleを併用する方法を示します。
concat('Dear ', hwf:getNotificationProperty('recipientDisplay'), ' Task ',
/task:task/task:systemAttributes/task:taskNumber, ' is assigned to you. ',
hwf:getTaskResourceBundleString(/task:task/task:systemAttributes/task:taskId,
'CONGRATULATIONS', hwf:getNotificationProperty('locale')))
この場合、メッセージは次のようになります。
Dear Cooper, James Task 1111 is assigned to you. Congratulations
次のいずれかの方法で、通知コンテンツ内の国際化されたメッセージを取得できます。
タスクを定義する際に指定したリソース・バンドルからの値を使用する場合は、XPath拡張関数hwf:getTaskResourceBundleString(taskId, key, locale?)を使用します。この関数は、タスク定義で指定されたリソース・バンドルから国際化された文字列を返します。
通知受信者のロケールは、関数hwf:getNotificationProperty('locale')で取得できます。
通知に対応するタスクIDは、関数hwf:getNotificationProperty('taskId')で取得できます。
異なるリソース・バンドルが使用されている場合は、XPath拡張関数orcl:get-localized-string()を使用して、ローカライズされたメッセージを取得できます。
アクション可能な電子メールを使用できるようにタスクを設定している場合、電子メールを介してタスク・アクションを実行できます（同じアクションをOracle BPEL Worklistアプリケーションからも実行できます）。アクション可能な電子メール・アカウントでは、タスク・アクション関連の電子メールを受信して処理できます。この電子メールのアカウント名は、構成ファイルSOA_Oracle_Home¥bpel¥system¥services¥config¥wf_config.xmlの要素actionableEmailAccountNameで識別されます。
電子メール通知をアクション可能にするには、ヒューマン・タスク・エディタの「通知設定」セクションで「電子メール・メッセージのアクション可能化」を選択する必要があります。（図15-25を参照。）これにより、電子メールを介してタスク・アクションを実行できます。
通知がアクション可能な場合、電子メールにはカスタムの結果ごとにリンクが含まれます。リンクをクリックすると、電子メール・クライアントの作成ウィンドウが表示されます。この電子メールの件名や本文を変更する必要はありません。NIDサブストリングを含むコンテンツを変更すると、電子メールは処理されません。
図15-35に、アクション可能な電子メールのサンプルを示します。
添付を含めるフラグが選択されている場合は、電子メールのみが送信されます。電子メールには、すべてのタスク添付ファイルが電子メール添付ファイルとして含まれます。ヒューマン・タスク・エディタの「通知設定」セクションで「電子メール通知によるタスクの添付ファイルの送信」を選択します。（図15-25を参照。）
アクション可能な電子メール・リプライでは、電子メールに添付ファイルを追加できます。これらの添付ファイルはタスク添付ファイルとして追加されます。
アクション可能な電子メール・リプライでは、電子メールのComments[['と']]の間にコメントを追加できます。これらのコンテンツはタスクのコメントとして追加されます。たとえば、Comments[[looks good]]とします。
以前のリリースでは、ワークフローのアウトバウンド通知には信頼性がありませんでした。つまり、通知はスレッドを使用して送信され、送信する通知のリストはメモリーに格納されていました。Oracle BPEL Serverが動作しなくなると、未送信の通知メッセージはワークフローから消失していました。
リリース10.1.3のワークフロー・アウトバウンド通知サービスでは、永続性サービスとともにキューを使用してユーザーに通知が送信されます。
ワークフローでユーザーに通知を送信する必要がある場合は、通知ID、タスクID、バージョンなどのタスク情報がデハイドレーション・ストアに格納され、通知IDがキューにエンキューされます。このキューをリスニングしているMessage-Driven Bean（MDB）は、メッセージをデキューしてユーザーに送信する通知メッセージを作成します。次に、通知サービスを使用してこのメッセージを送信します。この場合、デハイドレーション・ストアとともにキューが使用されます。
ヒューマン・タスク・エディタの「通知設定」セクションで通知をセキュアとしてマークすると、デフォルトの通知メッセージが使用されます。（図15-25を参照。）デフォルトの通知メッセージには、Oracle BPEL Worklistアプリケーション内のタスクへのリンクが含まれています。タスク詳細を参照するにはログインする必要があります。
ユーザー通知のためのチャネルは、Java AuthoriZatioN（JAZN）で指定されるユーザーの通知プリファレンス属性によって決定されます。通知プリファレンスは、属性orclWorkflowNotificationPreferenceで識別されます。JAZNファイルベースのシステムでは、この属性の値をusers-properties.xmlファイル内で変更できます。このファイルはSOA_Oracle_Home¥bpel¥system¥services¥configにあります。
Oracle Internet Directoryベースのシステムでは、Oracle Delegated Administration Serviceを使用してユーザー・プロパティを変更できます。この属性が設定されていない場合、デフォルトで電子メール・チャネルが使用されます。
タスクは、リマインダを送信するよう構成できます。リマインダは、タスクがユーザーに割り当てられた時刻またはタスクの有効期限が切れる時刻に基づきます。リマインダの数およびリマインダ間の間隔も構成可能です。タスクがASSIGNEDとしてマークされている場合、リマインダに使用されるメッセージはASSIGNEESに対するメッセージです。
リマインダの設定は、ヒューマン・タスク・エディタの「通知設定」セクションで行います。（図15-25を参照。）リマインダ構成に関連するパラメータは、次のとおりです。
recurrence: recurrenceでは、リマインダの送信回数を指定します。recurrenceに使用可能な値は、EVERY、NEVER、0、1、2 ...、10です。
relativeDate: relativeDateでは、タスクの割当て日または有効期限日のどちらからリマインダ期間を相対的に計算するかを指定します。relativeDateに使用可能な値は、ASSIGNEDとEXPIRATIONです。
duration: relativeDateからの、最初のリマインダとそれ以降の各リマインダの間隔を示します。期間のデータ型は、xsd:durationであり、その書式はISO 8601によりPnYnMnDTnHnMnSという形式で定義されています。大文字はデリミタであり、対応するメンバーを使用しない場合は省略できます。例としては、PT1004199059S、PT130S、PT2M10S、P1DT2S、-P1Y、P1Y2M3DT5H20M30.123Sのようになります。
次の例でリマインダが送信されるタイミングを具体的に説明します。
relativeDateがASSIGNED、recurrenceがEVERY、およびリマインダ期間がPT1Dであるとします。タスクが2005年3月24日午前10:00に割り当てられた場合、リマインダは、2005年3月25日午前10:00、2005年3月26日午前10:00、2005年3月27日午前10:00のように、ユーザーがタスクを操作するまで送信されます。
relativeDateがEXPIRATION、recurrenceが2、およびリマインダ期間がPT1Dであるとします。タスクの有効期限切れが2005年3月26日午前10:00で、タスクが2005年3月24日午前10:00より前に割り当てられた場合、リマインダは2005年3月24日午前10:00と2005年3月25日午前10:00に送信されます。
relativeDateがEXPIRATION、recurrenceが2、およびリマインダ期間がPT1Dであるとします。タスクの有効期限切れが2005年3月26日午前10:00で、タスクが2005年3月24日午後3:00に割り当てられた場合、リマインダは2005年3月25日午前10:00の1回のみ送信されます。
表15-14に、Oracle BPEL Process Managerに用意されているエンドツーエンドのワークフローの例を示します。これらのサンプルと同じディレクトリにあるドキュメントを参照してください。
すべてのサンプルは、表15-14に示すデモンストレーション機能のみでなく、ワークリスト・アプリケーションとワークフロー通知の使用方法も示しています。
表15-14 エンドツーエンドの例
| サンプル | 位置 | 説明 | デモの内容 |
|---|---|---|---|
| AutoLoanDemo | SOA_Oracle_Home¥bpel¥samples¥demos
|
融資申請の確認と承認 |
|
| DocumentReview | SOA_Oracle_Home¥bpel¥samples¥demos
|
文書の確認と承認 |
|
| ExpenseRequestApproval | SOA_Oracle_Home¥bpel¥samples¥demos
|
ExpenseRequestビジネス・プロセスを使用して従業員からの経費請求を承認および却下 |
|
| HelpDeskServiceRequest | SOA_Oracle_Home¥bpel¥samples¥demos
|
ヘルプ・デスク・サービスによる承認 |
|
| LoanDemoPlus | SOA_Oracle_Home¥bpel¥samples¥demos
|
融資申込書の承認 |
|
| OrderApproval | SOA_Oracle_Home¥bpel¥samples¥tutorials¥127.OrderBookingTutorial
|
注文書の承認または却下 |
|
| VacationRequest | SOA_Oracle_Home¥bpel¥samples¥demos
|
休暇申請の承認または却下 |
|
この例では、休暇申請のビジネス・プロセスを作成する方法について説明します。このビジネス・プロセスでは、休暇を申請するユーザーのマネージャが、申請を承認または却下します。承認または却下は、1ステップのプロセスです。
この例は、次のツールの使用に特徴があります。
Oracle JDeveloperを使用した単一承認ワークフローのモデリング
Oracle BPEL Worklistアプリケーションを使用したタスクの表示と操作
この例では、次のことが仮定されます。
ユーザーは、BPELアクティビティやパートナ・リンクなどの基本的なBPEL構成要素と、基本的なXPath関数についてよく理解している必要があります。また、BPELプロセスを作成してデプロイするためのOracle JDeveloper環境についても理解している必要があります。
電子メール通知を使用できるように、アカウントDefaultの電子メール・サーバー設定を構成する必要があります。Defaultアカウントは、電子メールの送信に使用されます。電子メール・サーバー構成は、次のファイルで行います。
SOA_Oracle_Home¥bpel¥system¥services¥config¥ns_emails.xml
ファイルの次のコード例では、必要に応じて構成するパラメータを太字で示しています。
<EmailAccount>
<Name>Default</Name>
<GeneralSettings>
<FromName>Oracle BPM</FromName>
<FromAddress>accountId@yourdomain.com</FromAddress>
</GeneralSettings>
<OutgoingServerSettings>
<SMTPHost>yourdomain.com</SMTPHost>
<SMTPPort>25</SMTPPort>
</OutgoingServerSettings>
<IncomingServerSettings>
<Server>yourdomain.com</Server>
<Port>110</Port>
<Protocol>pop3</Protocol>
<UserName>accountId</UserName>
<Password ns0:encrypted="false"
xmlns:ns0="http://xmlns.oracle.com/ias/pcbpel/NotificationService">
password</Password>
<UseSSL>false</UseSSL>
<Folder>Inbox</Folder>
<PollingFrequency>1</PollingFrequency>
<PostReadOperation>
<MarkAsRead/>
</PostReadOperation>
</IncomingServerSettings>
</EmailAccount>
ns_emails.xmlファイル内でNotificationModeパラメータを次のいずれかの値に設定する必要があります。
ALL: 電子メール、SMS、ボイス、FAXおよびポケットベルの各チャネルを設定している場合
EMAIL: 電子メール・チャネルのみを設定している場合
たとえば、次のようになります。
<EmailAccounts xmlns="http://xmlns.oracle.com/ias/pcbpel/NotificationService"
EmailMimeCharset=""
NotificationMode="EMAIL">
ユーザーjsteinの電子メール・アドレスを、アクセス可能な電子メール・アドレスに変更する必要があります。XMLベースのJAZNプロバイダを使用する場合は、これらのプロパティを次のファイルで変更できます。
SOA_Oracle_Home¥bpel¥system¥services¥config¥users-properties.xml
users-properties.xmlの次のXMLセグメントは、電子メールの構成場所を示しています。
<userObject>
<name>jstein</name>
<description>Demo User</description>
<email>user1@dlsun4254.us.oracle.com</email>
<title>Manager2</title>
<firstName>John</firstName>
<lastName>Steinbeck</lastName>
<manager>wfaulk</manager>
<timeZone>America/Los_Angeles</timeZone>
<languagePreference>en-US</languagePreference>
<notificationPreferences>Mail</notificationPreferences>
</userObject>
前述の変更の実行後は、Oracle BPEL Process Managerを再起動する必要があります。
チュートリアルのこのフェーズでは、新規プロジェクトOrderApprovalを作成し、ヒューマン・ワークフロー・プロセス（注文が承認または却下される単一承認者ワークフロー）を定義します。注文は、最初に監督者ロールに割り当てられます。監督者ロールを持つユーザーにより注文が承認されると、最終承認のためにそのユーザーのマネージャに送信されます。
この項の内容は次のとおりです。
アプリケーション・ナビゲータでアプリケーションを右クリックして「新規プロジェクト」を選択します。
「BPELプロセス・プロジェクト」を選択します。
非同期のBPELプロセスをVacationRequestという名前で作成します。
「次へ」をクリックします。
「入力スキーマ要素」の横にある懐中電灯をクリックし、次のディレクトリにあるVacationRequest.xsdを参照します。
SOA_Oracle_Home¥bpel¥samples¥demos¥VacationRequest¥bpel
「開く」をクリックします。
「タイプの選択」ウィンドウが表示されます。
「インポートしたスキーマ」→「VacationRequest.xsd」→「VacationRequestProcessRequest」を順番に開いて選択します。
「OK」をクリックします。
「出力スキーマ要素」の横にある懐中電灯をクリックします。
「インポートしたスキーマ」→「VacationRequest.xsd」→「VacationRequestProcessResponse」を順番に開いて選択します。
「終了」をクリックします。
これでスキーマがプロジェクトにインポートされました。アプリケーション・ナビゲータでは「VacationRequest」→「インテグレーション・コンテンツ」→「スキーマ」の下、「構造」セクションでは「スキーマ」の下に、VacationRequest.xsdが表示されます。BPELプロセスとしてreceiveアクティビティ（receiveInput）およびinvokeアクティビティ（callbackClient）が表示されます。
「ファイル」メイン・メニューから「保存」を選択します。
|
概要: ヒューマン・タスクを定義すると、VacationApproval.taskファイル（タスク構成メタデータ・ファイル）が作成されます。
|
Human TaskアクティビティをreceiveInputとcallbackClientの間にドラッグ・アンド・ドロップします。
「タスク定義の作成」アイコン（2番目のアイコン）をクリックします。
ヒューマン・タスク名としてVacationApprovalと入力し、「OK」をクリックします。（デフォルトの場所を受け入れます。）
VacationApproval.taskファイルが作成されます。
ヒューマン・タスク・エディタが表示されます。
「タイトル」にVacation Approvalと入力します。
「優先度」と「結果」のデフォルト値を受け入れます。
「パラメータ」では、ウィンドウの右側にある「+」アイコンをクリックします。
「タスク・パラメータの追加」ウィンドウが表示されます。
「要素」と懐中電灯アイコンを順番にクリックします。
「タイプの選択」ウィンドウで、「プロジェクトのスキーマ・ファイル」→「VacationRequest.xsd」→「VacationRequestProcessRequest」を順番に開いて選択し、「OK」をクリックします。
「タスク・パラメータの追加」ウィンドウで、「ワークリストにより変更可能」と「OK」を順番にクリックします。
これにより、Oracle BPEL Worklistアプリケーションを使用してタスク・データを変更できるようになります。
「割当ておよびルーティング・ポリシー」セクションで、ウィンドウの右側にある「+」アイコンをクリックします。
「参加者タイプの追加」ウィンドウが表示されます。
「タイプ」で「単一の承認者」を選択します。
この参加者タイプは、タスクに対して単独で機能します。
「ラベル」にVacation Approverと入力します。
「式別」をクリックします。
この例では、休暇申請者のマネージャにタスクを割り当てます。
動的ユーザーXPathフィールドの右側にあるアイコンをクリックして、「式ビルダー」ウィンドウを表示します。
「関数」セクションのリストから「Identity Service Functions」を選択します。
「getManager」をダブルクリックします。
「式ビルダー」ウィンドウの左側の「スキーマ」セクションに移動します。
「task:task」→「task:payload」→「ns0:VacationRequestProcessRequest」→「ns0:creator」を順番に開きます。
「式に挿入」をクリックします。
次のような「式ビルダー」ウィンドウが表示されます。
「OK」をクリックして「参加者タイプの追加」ウィンドウに戻ります。
「OK」をクリックしてヒューマン・タスク・エディタに戻ります。
「+」記号をクリックして「有効期限およびエスカレーション・ポリシー」セクションを開きます。
ドロップダウン・リストから「期限切れまでの時間」を選択します。
「固定期間」をクリックして「日」リストから1を選択します。
「ファイル」メイン・メニューから「保存」を選択します。
「VacationApproval.task」の横にある「X」をクリックしてヒューマン・タスク・エディタを閉じます。
|
概要: フィールドをBPELプロセスの変数にマップします。 |
BPELプロセス内のVacationApproval_1ヒューマン・タスク・サービスをダブルクリックします。
「ヒューマン・タスク」ウィンドウが表示されます。
「タスクのタイトル」フィールドで、単語Vacation Approvalの後にforと入力します。
右側にあるアイコンをクリックして「式ビルダー」ウィンドウを表示します。
「BPEL変数」セクションで、「inputVariable」→「payload」→「client:VacationRequestProcessRequest」→「client:creator」を順番に開いて選択します。
「式に挿入」をクリックします。
「式」セクションにXPath式が表示されます。
「OK」をクリックします。
XPath式がタスク・タイトルに追加されます。
「起案者」フィールドの右側にあるアイコンをクリックして、「式ビルダー」ウィンドウを表示します。
手順4から6までを繰り返して、「起案者」フィールドに同じXPath式を挿入します。
「BPEL変数」列の下にある懐中電灯アイコンをクリックします。
「タスク・パラメータ」ウィンドウが表示されます。
「タスク・パラメータ」ウィンドウで、「変数」→「inputVariable」→「payload」→「client:VacationRequestProcessRequest」を順番に開いて選択します。
「OK」をクリックします。
「ヒューマン・タスク」ウィンドウで「OK」をクリックします。
「ファイル」メイン・メニューから「保存」を選択します。
|
概要: 自動生成タスク・フォームpayload-body.jspを作成します。
|
アプリケーション・ナビゲータで、「VacationApproval」フォルダを右クリックして「単純タスク・フォームの自動生成」を選択します。
タスク・フォーム・ファイルが自動的に生成されます。
上部の「X」記号をクリックして「payload-body.jsp」を閉じます。
|
概要: switchアクティビティには、可能な結果、つまり前に指定したcase（承認および「却下」）が反映されます。また、その他の結果（エラー発生、失効または期限切れなど）を表すotherwiseというcaseもあります。各case内に、ビジネス・プロセス・モデリングを完了するためのアクティビティを追加できます。このcopyPayloadFromTask Assignアクティビティにより、ペイロードがソースにコピーして戻されます。 |
「VacationRequest.bpel」をダブルクリックします。
「taskSwitch」Switchアクティビティを開きます。
Assignアクティビティを、Switchアクティビティの「<case Task outcome is APPROVE>」セクションにある「copyPayloadFromTask」Assignアクティビティの下にドラッグ・アンド・ドロップします。
「割当て」アイコンをダブルクリックして「割当て」ウィンドウを表示します。
「一般」タブをクリックします。
「名前」フィールドにassignVacationApproval1と入力します。
「適用」をクリックします。
「コピー操作」タブをクリックします。
「作成」をクリックして「コピー操作」を選択します。
次の詳細を入力します。
| フィールド | 値 |
|---|---|
| 送信元 | |
|
式 |
|
string('Approved') |
| 宛先 | |
|
変数 |
|
「変数」→「outputVariable」→「payload」→「client:VacationRequestProcessResponse」→「client:result」を順番に開いて選択します。
注意: ネームスペース番号値（clientやns1など）は変更される場合があります。自動的に表示されるネームスペース値を使用します。 |
「OK」をクリックし、「コピー操作の作成」ウィンドウと「Assign」ウィンドウを閉じます。
手順3から11までを繰り返して、「<case Task outcome is REJECT>」セクションにある「copyPayloadFromTask」Assignアクティビティの下にAssignアクティビティを作成します。前述と同じ詳細を次のように変更して入力します。
名前としてassignVacationApproval2と入力します。
「式」フィールドをstring('Rejected')に設定します。
手順3から11までを繰り返して、「<otherwise>」セクションにある「copyPayloadFromTask」Assignアクティビティの下にAssignアクティビティを作成します。前述と同じ詳細を次のように変更して入力します。
名前としてassignVacationApproval3と入力します。
「式」フィールドをstring('Rejected')に設定します。
このプロセスは次のようになります。
「ファイル」メイン・メニューから「保存」を選択します。
「-」記号をクリックして「taskSwitch」Switchアクティビティを閉じます。
「スタート」→「すべてのプログラム」→「Oracle - Oracle_Home」→「Oracle BPEL Process Manager」→「BPEL Control」を選択して、Oracle BPEL Controlにログインします。
Oracle BPEL Controlへのログインに必要な次の詳細を入力して、「ログイン」をクリックします。
| フィールド | 値 |
|---|---|
| ユーザー名 | oc4jadmin
|
| パスワード | welcome1
|
「デプロイ済のBPELプロセス」リストで「VacationApproval」をクリックします。
休暇作成者としてjcooperと入力します。
残りのフィールドに適切な値を入力します。
「XMLメッセージの転送」をクリックします。
「BPELプロセス」タブに次のようなメッセージが表示されます。
Test Instance Initiated
上部の「インスタンス」タブをクリックします。
OrderApprovalインスタンスをクリックします。
インスタンスがアクティブであることを示すメッセージが表示されます。
「スタート」→「すべてのプログラム」→「Oracle - Oracle_Home」→「Oracle BPEL Process Manager」→「Sample Worklist Application」を選択して、Oracle BPEL Worklistアプリケーションのログイン・ウィンドウにアクセスします。
jstein/welcome1としてログインします。
ユーザーjsteinはjcooperのマネージャです。ログインするとOracle BPEL Worklistアプリケーションが表示されます。承認待ちのタスクが表示されます。
承認するタスクの「アクション」リストで「申告」を選択します。
「実行」をクリックします。
タスク詳細とペイロード情報が表示されます。
情報を確認します。たとえば、OrderBookingPO_1.xmlのコンテンツにコピーして貼り付けた場合は、次の情報が表示されます。
「タスク・アクション」リストから承認を選択して「実行」をクリックします。
ユーザーjcooperとしてログアウトします。
Oracle BPEL Worklistアプリケーションにjstein/welcome1としてログインします。
「アクション」リストから承認を選択して「実行」をクリックします。
処理が完了すると、Oracle BPEL Worklistアプリケーションにタスクが表示されなくなります。
ログアウトします。
Oracle BPEL Controlに戻ります。
上部の「インスタンス」タブをクリックします。
VacationApprovalインスタンスをクリックします。
インスタンスが完了済であることを示すメッセージが表示されます。
「監査」および「フロー」リンクをクリックし、完了したOrderApprovalプロセスの詳細を確認します。
ワークフロー・サービスおよび関数は、様々なタスクを扱います。この項では、次のワークフロー・サービスの役割について説明します。
表15-15に、タスク・サービスに対して提供されるSOAP、EJBおよびJavaサポートのタイプを示します。
表15-15 EJB、SOAPおよびJavaサポート
表15-16に、各タスク・サービスのSOAP WSDLファイルの場所を示します。
表15-16 タスク・サービスのSOAP WSDLの場所
アイデンティティ・サービスを除き、前述のAPI（SOAP、リモートEJB、ローカルEJBおよびJava WSIF）を使用するすべてのサービスでは、認証を起動する必要があります。前述のすべてのチャネルで、ワークフロー・コンテキストを使用したユーザーIDの受渡しがサポートされています。ワークフロー・コンテキストには、次のいずれかが含まれます。
ログインとパスワード
トークン
タスク問合せサービスにより、ログインとパスワードをとって全サービスに使用するワークフロー・コンテキストを返す認証操作が公開されます。オプションで、リクエストごとにログインおよびパスワードとともにワークフロー・コンテキストを渡すことができます。
認証操作では、管理IDおよび管理パスワードを持つユーザーにかわってコンテキストを作成するという概念もサポートされます。これにより、Oracle BPEL Worklistアプリケーションにログインしたユーザーのパスワードを利用できない場合に、そのユーザー用のコンテキストを作成できます。
SOAP Webサービスでも、Webサービス・セキュリティがサポートされます。Webサービス・セキュリティが使用される場合、ワークフロー・コンテキストをSOAP入力に存在させる必要はありません。Webサービス・セキュリティは、Oracle Enterprise Manager 10g Application Server Controlコンソールから構成できます。
|
注意: Webサービス・セキュリティを使用する場合、ワークフロー・サービスのSOAPクライアントは使用できません。 |
タスク問合せサービスに対するauthenticate API操作では、管理ユーザーのユーザーIDとパスワードをリクエストで渡すことで、ユーザーのかわりにワークフロー・コンテキストを作成できます。管理ユーザーは、BPMWorkflowAdminロールを持つユーザーです。この場合、ユーザーのかわりにパスワードを使用して作成した場合と同様のコンテキストが作成されます。
この例では、ユーザーjcooperのワークフロー・コンテキストが作成されます。
ITaskQueryService taskQueryService = ….
String realm = …;
IWorkflowContext wfCtx =
taskQueryService.authenticate('bpeladmin', 'welcome1', realm, 'jcooper');
タスク・サービスにより、タスクに対するアクションを実行するための操作が公開されます。表15-17に、タスク・サービスの操作を示します。パッケージoracle.bpel.services.workflow.taskは、タスク・サービスに対応しています。
表15-17 タスク・サービスのメソッド
| メソッド | 説明 |
|---|---|
acquireTask
|
タスクを獲得します。 |
acquireTasks
|
一連のタスクを獲得します。 |
addAttachment
|
タスクに添付ファイルを追加します。 |
addComment
|
タスクにコメントを追加します。 |
delegateTask
|
タスクを別のユーザーに委任します。現在の割当て先とタスク委任先ユーザーの両方が、タスクを表示して操作できます。 |
errorTask
|
タスクをエラーにします。通常、この操作はエラー割当て先が使用します。 |
escalateTask
|
タスクをエスカレートします。デフォルトでは、現行のユーザーのマネージャにエスカレートします。これはエスカレーション関数を使用して上書きできます。 |
getApprovers
|
タスクの前の承認者を取得します。 |
getFutureParticipants
|
タスクの今後の参加者を取得します。今後の参加者は、単純参加者を含むルーティング・スリップ形式で返されます（ルーティング・スリップを含む参加者ノードとパラレル・ノード）。 |
getUsersToRequestInfoForTask
|
情報リクエストのリクエスト先ユーザーを取得します。 |
initiateTask
|
タスクを開始します。 |
mergeAndUpdateTask
|
タスクをマージおよび更新します。この操作を使用するのは、部分タスクに更新が必要な場合です。部分タスクとは、一部のタスク属性が存在しないタスクです。この部分タスクでは、次のタスク属性のみが解析されます。
|
overrideRoutingSlip
|
タスク・インスタンスのルーティング・スリップを新規ルーティング・スリップで上書きします。現行のタスク割当てはNULLになり、タスクの開始時には新規ルーティング・スリップが解析されます。 |
pushBackTask
|
タスクを前の承認者または当初の割当て先にプッシュバックします。当初の割当て先は、タスクの再割当てやエスカレートを行っている可能性があるため、承認者でなくてもかまいません。タスクが当初の割当て先にプッシュバックされるか承認者にプッシュバックされるかは、wf_config.xml内のプロパティpushbackAssigneeにより制御されます。
|
reassignTask
|
タスクを再割当てします。 |
reinitiateTask
|
タスクを再開始します。タスクを再開始すると、前に完了したタスクが持ち越されるため、履歴、コメントおよび添付ファイルも新規タスクに持ち越されます。 |
releaseTask
|
前に獲得したタスクをリリースします。 |
releaseTasks
|
前に獲得した一連のタスクをリリースします。 |
removeAttachment
|
タスク添付ファイルを削除します。 |
renewTask
|
タスクの期限を更新して有効期間を延長します。 |
requestInfoForTask
|
タスク情報をリクエストします。 |
requestInfoForTaskWithReapproval
|
再承認を伴うタスク情報をリクエストします。たとえば、jcooperがタスクを作成し、jsteinとwfaulkが同じ順序でタスクを承認したとします。次の承認者であるcdickensがjcooperに対して再承認を伴う情報のリクエストを送信すると、jcooperはリクエストされた情報を発行し、jsteinとwfaulkはcdickensより先にそのタスクを承認します。cdickensがjsteinに対して再承認を伴う情報のリクエストを送信すると、jsteinはリクエストされた情報を発行し、wfaulkはcdickensより先にそのタスクを承認します。
|
resumeTask
|
タスクを再開します。ワークフローの保留を解除するためにタスク所有者（またはBPMWorkflowSuspend権限を持つユーザー）のみが実行できる操作です。ワークフローの再開後は、タスクにアクションを実行できます。
|
resumeTasks
|
一連のタスクを再開します。 |
routeTask
|
タスクをレビューする必要のある次のユーザーに非定型フローの形式でルーティングできるようにします。ユーザーは、タスクを順序、パラレルまたは単純割当てでルーティングするように指定できます。タスクをルーティングできるのは、ワークフローでタスクの非定型ルーティングが許可されている場合のみです。 |
skipCurrentAssignment
|
現在の割当てをスキップして次の割当てに移動するか、他に割当て先が存在しない場合は、直前の承認者により設定された結果を使用します。 |
submitInfoForTask
|
タスク情報を発行します。通常、このアクションは、必要なタスク更新を実行した後、または追加情報を含むコメントや添付を追加した後に実行します。 |
suspendTask
|
タスク所有者（またはBPMWorkflowSuspend権限を持つユーザー）に、ワークフローの一時的な保留を許可します。この場合、ワークフローが再開されるまで、タスクの有効期限とエスカレーションは適用されません。一時停止されているタスクには、アクションを実行できません（再開または取消しを除く）。
|
suspendTasks
|
一連のタスクを一時停止します。 |
updateOutcomeOfTasks
|
一連のタスクの結果を更新します。 |
updateTask
|
タスクを更新します。 |
updateTaskOutcome
|
タスクの結果を更新します。 |
updateTaskOutcomeAndRoute
|
タスクの結果を更新してタスクをルーティングします。タスクをルーティングすると、ユーザーはタスクをレビューする必要のある次のユーザーに非定型フローの形式でルーティングできます。ユーザーは、タスクを順序、パラレルまたは単純割当てでルーティングするように指定できます。タスクをルーティングできるのは、ワークフローでタスクの非定型ルーティングが許可されている場合のみです。 |
withdrawTask
|
タスク作成者は、タスクをワークフローに送る必要がなくなった場合に、保留中のタスクを取り消すことができます。タスク所有者も、作成者のかわりにタスクを取り消すことが可能です。タスクが取り消されると、ビジネス・プロセスは、タスクの状態属性が「取消し済」に設定されてコールバックされます。
|
withdrawTasks
|
一連のタスクを取り消します。 |
タスク問合せサービスでは、様々な検索基準（キーワード、カテゴリ、ステータス、ビジネス・プロセス、属性値、タスクの履歴情報など）に基づいてタスクを問い合せます。 表15-18に、SOAPを介したサービスの使用方法など、タスク問合せサービスの操作を示します。パッケージoracle.bpel.services.workflow.queryは、タスク問合せサービスに対応しています。
表15-18 タスク問合せサービスのメソッド
この項では、Oracle BPEL Process Managerのアイデンティティ・サービス・コンポーネントについて説明します。アイデンティティ・サービスは、Oracle Application Server 10gのセキュリティ・インフラストラクチャ（OracleAS JAAS Provider（JAZN））または任意のカスタム・ユーザー・リポジトリの上部に位置するWebサービスのシン・レイヤーです。このサービスにより、ユーザーの認証および認可と、ユーザー・プロパティ、ロール、グループ・メンバーシップ、権限のルックアップが可能になります。
一部のユーザーおよびロールは、Oracle BPEL Process Managerのインストール時に自動的に作成されます。設定済ユーザーは、次のとおりです。
guest
default
bpeladmin
oc4jadmin
アイデンティティ・サービスでは、次のロールが事前定義されています。これらのロールは、ワークフロー関連の操作を実行するユーザーに付与できます。
PUBLIC: このロールは、暗黙的なJAZNロールです。明示的にいずれかのユーザーに付与する必要はありません。ユーザーがワークリストで認証されると、そのユーザーは、自分自身に割り当てられているか、自分が属するグループに割り当てられているタスクを参照し、そのタスクを操作できます。
|
注意: サード・パーティ・プロバイダで暗黙的なPUBLICロールをサポートしていない場合、BPMPublicロールを各ユーザーに明示的に付与して使用できます。
|
BPMWorkflowReassign: このロールにより、ユーザーは、タスクを組織の別のユーザーに再割当てできます。マネージャは、Reassign権限がない場合でも、常に組織階層で下位のユーザーにタスクを委任できます。ただし、管理階層外のユーザーに再割当てを実行するには、BPMWorkflowReassignロールが必要です。
BPMWorkflowSuspend: このロールにより、ユーザーは、プロセスを一時停止できます。プロセスが一時停止された場合、有効期限は適用されません。有効期限は、プロセスが再開されたときに再度計算されます。プロセス設計者がSuspendを制限付きアクションとして指定している場合、ユーザーは、BPMWorkflowSuspendロールを付与されていてもワークフローを一時停止できません。
BPMWorkflowViewHistory: 一般的に、ユーザーは、ワークリストの一部としてタスク割当て順序のみを参照できます。このロールを付与されたユーザーは、タスク承認順序からBPELビジネス・プロセスの監査証跡にドリルダウンできます。
BPMWorkflowAdmin: このロールにより、ユーザーは、システムのワークフローに対してシステム・アクションを実行できます。ただし、このロールでは、タスク結果（承認または却下など）を変更することはできません。委任、エスカレート、一時停止などのアクションを実行できるのみです。タスク結果を変更できるのは、タスク割当て先またはタスク所有者のみです。
BPMSystemAdmin: BPMWorkflowAdminとBPMSystemAdminには、同レベルのワークフロー権限が付与されています。
BPMDefaultDomainAdmin: このロールは、ユーザーにOracle BPEL Controlを介したdefaultドメインへのアクセス権限を提供します。
これらのロールの一部は、ネストしています。BPMWorkflowReassign、BPMWorkflowSuspendおよびBPMWorkflowViewHistoryロールは、BPMWorkflowAdminロールに付与されています。BPMSystemAdminロールは、設定済のbpeladminユーザーに付与されています。
ディレクトリ固有のツールを使用して、レルム、ユーザーまたはグループを作成します。たとえば、次のようになります。
OIDを使用する場合にユーザーおよびグループを作成するには、Oracle Delegated Administration Serviceツールを使用します。詳細は、『Oracle Identity Management委任管理ガイド』を参照してください。
XMLベースのJAZNプロバイダを使用する際にユーザーおよびグループの資格証明を作成するには、JAZN Admintoolを使用してjazn-data.xmlファイルを変更します。XMLベースのJAZNユーザーまたはロールを追加または削除するには、JAZN Admintoolを使用する必要があります。users-properties.xmlファイルを手動で編集し、JAZNではサポートされない詳細ユーザー・プロパティを指定できます。
たとえば、指定したレルムにユーザーを追加するには、次のコマンドを発行します。
java -jar jazn.jar -user adminUser -password adminPassword -adduser realmName newUser newUserPassword
JAZN Admintoolには、様々なコマンド・オプションがあります。次のように-helpオプションを付けることで、すべてのオプションとその構文をリストできます。
java -jar jazn.jar -help
サード・パーティLDAPサーバーまたはカスタム・ユーザー・リポジトリを使用している場合、そのディレクトリに適した固有のツールを使用する必要があります。
Oracle BPEL Process Managerのアイデンティティ・サービスでは、図15-36に示すように、JAZN、サード・パーティLDAPまたはカスタム・プラグインという3タイプのプロバイダがサポートされます。
アイデンティティ・サービス・プロバイダにより、次の操作が実行されます。
認証: ユーザー名とパスワードでユーザーを認証します。
認可: 特定ユーザーのロールおよびグループ・メンバーシップを判別します。これらのロールは、ワークリストにおける様々な作業項目および操作へのアクセスを制御する際に使用されます。
ユーザー・プロパティの取得: このプロパティには、氏名、電話番号、電子メール、優先通知チャネル、言語設定、タイムゾーンなどの連絡先情報や、マネージャ名、部下などの組織詳細情報が含まれます。
JAZNプロバイダ・モードは、事前構成済であり、すべての認証および認可の問合せをJAZNレイヤーに委任します。OC4Jセキュリティ・インフラストラクチャの一部として、XMLベースのファイルとLDAPベースのOIDという2つのJAASプロバイダが提供されます。
XMLベースのJAZNプロバイダ・タイプ: XMLベースのプロバイダ・タイプでは、情報の軽量記憶域としてXMLファイルを使用します。すべてのユーザー名、ロールおよび権限は、XMLファイルに格納されます。この場合、ユーザー名、パスワードおよび権限は、jazn-data.xmlファイルに保存されます。また、Oracle BPEL Process Managerでは、名前、電子メール、電話番号、マネージャなどの詳細ユーザー・プロパティを格納するために、このファイルとともに機能するuser-properties.xmlファイルを使用します。
LDAPベースのJAZNプロバイダ・タイプ（Oracle Internet Directory）: LDAPベースのプロバイダ・タイプは、情報の集中記憶域としてディレクトリを使用するためのLightweight Directory Access Protocol（LDAP）に基づきます。Oracle Internet Directory（OID）は、すべてのユーザー・データに単一の中央リポジトリを提供するLDAPベースの標準ディレクトリです。これにより、サイトでは、ユーザーID、ロール、認可および認証資格証明に加え、アプリケーション固有の設定やプロファイルを単一のリポジトリで管理できます。
サード・パーティLDAPプロバイダ・モードの場合、アイデンティティ・サービスは、Sun Directory Server（iPlanet）、Microsoft Active Directory、OpenLDAPなどのサード・パーティLDAPサーバーと連携して動作します。このモードの場合、アイデンティティ・サービスでは、ディレクトリがすべてのユーザー・データ（認証資格証明、ロール、プロファイルなど）の中央リポジトリであるとみなされます。これらの詳細は、LDAPスキーマの標準のorganizationalPersonおよびinetOrgPersonオブジェクトにより取得されます。
このモードでは、カスタム・アイデンティティ・サービス・プロバイダを定義して、非LDAPベースのユーザー・リポジトリにプラグイン接続できます。カスタム・アイデンティティ・サービス・プラグインでは、BPMIdentityServiceインタフェースを実装する必要があります（Javadocを参照）。また、このidentityserviceクラスの名前は、is_config.xmlに登録されている必要があります。
|
関連項目:
|
アイデンティティ・サービスでは、次のユーザー・プロパティがサポートされます。
表示名
名、ミドル・ネームおよび姓
説明
役職
電子メール・アドレス
電話番号
自宅電話番号
携帯電話番号
FAX番号
ポケットベル番号
マネージャID
所有者（ユーザーではなくグループとロールに適用）
タイムゾーン
言語プリファレンス（Javaロケール）
通知プリファレンス（優先通知チャネル）
Oracle BPEL Process Managerユーザーにとって、これらのプロパティはオプションです。ただし、連絡先情報がディレクトリまたはJAZN XMLベースのプロバイダのusers-propertiesファイルに存在しなければ、一部の機能（タスク通知など）は使用できません。また、自動エスカレーションやマネージャ・ビューも、マネージャ・フィールドがアイデンティティ・サービスで利用できない場合は使用できません。グループ所有者として表示されないユーザーは、グループに対して定義されたルールを変更できません。
次のOID objectClassesでは、mail、managerおよびtelephoneNumberなどのユーザー・プロパティとロール・プロパティを指定します。
top
person
cn
sn
description
telephoneNumber
organizationalPerson
title
telephoneNumber
facsimileTelephoneNumber
inetOrgPerson
uid
displayName
givenName
manager
mail
homePhone
mobile
pager
preferredLanguage
orclUserV2
middleName
orclTimeZone
orclWorkflowNotificationPref
groupOfUniqueNames
description
owner
uniqueMember
orclGroup
displayName
mail
アイデンティティ・サービスでは、これらのプロパティをLDAPディレクトリから取得するために接続プールが維持されます。
XMLベースのJAZNプロバイダを使用している場合、同じエントリが次の場所にあるusers-properties.xmlファイルのXML要素として表現されます。
SOA_Oracle_Home¥bpel¥system¥services¥config
アイデンティティ・サービスでは、is_config.xmlファイル内で複数の構成設定（アイデンティティ・コンテキスト、サポート対象レルムなど）を指定できます。ビジネス・プロセスでは、定義済の構成の1つが実行時に使用されます。
構成では、ビジネス・プロセスが実行時にコンテキストを解決できるようにレルム名を指定する必要があります。JAZNプロバイダの場合、レルム名はサポート対象のJAZNレルム名の1つに一致する必要があります。一致しなければ、実行時例外がスローされます。JAZN XMLベースのプロバイダの場合は、各レルムの拡張ユーザー・プロパティおよびロール・プロパティを個別のファイルに格納する必要があります。LDAPプロバイダの場合はレルム名として任意の一意な名前を使用できますが、コンテキストはLDAPサーバー・ツリーのLDAP URL、ユーザー検索ベースおよびロール検索ベースの各ノードで定義されます。これらのプロパティは、is_config.xml内のconnection、userControlsおよびroleControlsプロバイダ要素により制御されます。
is_config.xmlファイルに複数の構成が含まれる場合は、その1つがデフォルト構成として定義されます。デフォルト・コンテキストは、実行時に特定のコンテキスト情報が見つからない場合にBPELプロセスにより使用されます。アイデンティティ・サービスでは、構成コンテキストがレルム名に基づいて解決されます。
アイデンティティ・サービスでは、認証、認可およびアイデンティティ・サービスの各プロバイダがサポートされます。アイデンティティ・サービス・プロバイダは、デフォルトの擬似サービス・プロバイダです。このプロバイダをis_config.xmlファイル内の構成ごとに定義する必要があります。アイデンティティ・サービス・プロバイダは、すべてのコールを認証サービス・プロバイダまたは認可サービス・プロバイダに委任します。デフォルトでは、3つのサービス・プロバイダすべてが、アイデンティティ・プロバイダに定義されている同一のコンテキスト設定を共有します。アイデンティティ・サービスでは、認証サービスまたは認可サービスについて独自の設定属性を使用してサービス・プロバイダを追加定義できます。プロバイダ・サービス属性がAuthenticationに設定されている場合、その設定とプロバイダ・コンテキストは構成のすべての認証コールにのみ使用されます。プロバイダ・サービス属性がAuthorizationに設定されている場合、設定とプロバイダ・コンテキストは認可コールにのみ使用されます。
通知サービスでは、電子メール、ボイス、FAX、ポケットベルまたはショート・メッセージ・サービス（SMS）のいずれかのチャネルを通じて通知を送信するための操作が公開されています。これらの操作は、BPELビジネス・プロセスから起動できます。
|
関連項目:
|
タスク・メタデータ・サービスにより、タスク関連のメタデータ情報を取得するための操作が公開されます。表15-19に、これらのメソッドを示します。パッケージoracle.bpel.services.workflow.metadataは、タスク・メタデータ・サービスに対応しています。
表15-19 タスク・メタデータ・サービスのメソッド
| メソッド | 説明 |
|---|---|
getOutcomes
|
タスクについて許可されている結果を取得します。結果とその表示値が返されます。 |
getResourceBundleInfo
|
タスクのリソース・バンドル情報を取得します。リソース・バンドル情報には、バンドルの位置と名前が含まれます。 |
getRestrictedActions
|
特定のタスクに対する制限付きアクションを取得します。 |
getTaskAttributes
|
タスク・メッセージ属性を取得します。 |
getTaskAttributesForTaskDefinition
|
特定のタスク定義のメッセージ属性を取得します。 |
getTaskDefinition
|
タスクに関連するタスク定義を取得します。 |
getTaskDefinitionById
|
タスク定義IDによるタスク定義を取得します。 |
getTaskDefinitionOutcome
|
特定のタスク定義IDの結果を取得します。 |
getTaskDisplay
|
タスクのタスク表示を取得します。 |
getTaskDisplayRegion
|
タスクのタスク表示リージョンを取得します。 |
getVersionTrackedAttrs
|
変更された場合にタスク・バージョンが作成されるタスク属性を取得します。 |
listTaskMetadata
|
システム内のタスク定義をリストします。 |
ユーザー・メタデータ・サービスは、個々のユーザーおよびグループに固有のメタデータを管理するためのメソッドを提供します。このサービスは、ユーザー・ワークリストのプリファレンスの取得と設定、ユーザーのカスタム・ビューの管理およびユーザーとグループに対するワークフロー・ルールの管理に使用されます。
ユーザー・メタデータ・サービスのほとんどのメソッドの場合、認証済ユーザーは独自のユーザー・メタデータを問い合せて更新できます。ただし、他のユーザーに属するメタデータは更新できません。
グループ・メタデータ（グループに対するワークフロー・ルールなど）の場合、グループのメタデータを問い合せて更新できるのは、そのグループの所有者として指定されているユーザー（またはBPMWorkflowAdminユーザー）のみです。ただし、BPMWorkflowAdminロールを付与されているユーザーは、すべてのユーザーまたはグループのメタデータを問い合せて更新できます。
表15-20に、ユーザー・メタデータ・サービスのメソッドを示します。パッケージoracle.bpel.services.workflow.userは、ユーザー・メタデータ・サービスに対応しています。
表15-20 ユーザー・メタデータ・サービスのメソッド
| メソッド | 説明 |
|---|---|
setVacationInfo
|
ユーザーに対してタスクを割り当てることができない日付の範囲を設定します。（Dynamic Assignment Functionでは、休暇中のユーザーにタスクが割り当てられることはありません。） |
getVacationInfo
|
ユーザーに対してタスクを割り当てることができない日付の範囲（設定されている場合）を取得します。 |
getRuleList
|
特定のユーザーまたはグループに対するルールのリストを取得します。 |
getRuleDetail
|
特定のワークフロー・ルールの詳細を取得します。 |
createRule
|
新規ルールを作成します。 |
updateRule
|
既存のルールを更新します。 |
deleteRule
|
ルールを削除します。 |
increaseRulePriority
|
ルールの優先度を1つ高くします。ユーザーまたはグループに対するルールは、優先度の順序付きリストで保守されます。高優先度のルール（リストの先頭に近いルール）は、低優先度のルールよりも先に実行されます。このルールが最高優先度の場合、このメソッドでは何も実行されません。 |
decreaseRulePriority
|
ルールの優先度を1つ低くします。このルールが最低優先度の場合、このメソッドでは何も実行されません。 |
getRuleSetInfo
|
特定のユーザーまたはグループに対するルールの格納に使用されているOracle Business Rulesルール・セット関連の情報を返します。これは、クライアントでルール操作にユーザー・メタデータ・サービスを使用するのではなく、ルールSDKを直接使用する必要がある場合に役立ちます。 |
getUserTaskViewList
|
ユーザーが所有するユーザー・タスク・ビューのリストを取得します。 |
getGrantedTaskViewList
|
ユーザーに他のユーザーから権限付与されたユーザー・タスク・ビューのリストを取得します。ユーザーは付与されたビューを使用してタスクのリストを問合せできますが、ビュー定義は更新できません。 |
getStandardTaskViewList
|
ワークフロー・サービスに付属する、ユーザー全員が使用可能な標準タスク・ビューのリストを取得します。 |
getUserInboxView
|
ユーザーが各自のメイン受信ボックスのタスク・リストをパーソナライズできるように、構成情報を格納するための特殊なビューを取得します。 |
getUserTaskViewDetails
|
単一ビューの詳細を取得します。 |
createUserTaskView
|
新規のユーザー・タスク・ビューを作成します。 |
updateUserTaskView
|
既存のユーザー・タスク・ビューを更新します。 |
deleteUserTaskView
|
ユーザー・タスク・ビューを削除します。 |
updateGrantedTaskView
|
このユーザーに対する他のユーザーからのビュー権限付与の詳細を更新します。更新は、ビュー権限付与の非表示または非表示解除（ビューを非表示にするとビューがワークリスト・アプリケーションのメイン受信ボックス・ページに表示されなくなります）、および権限を付与されたユーザーに表示されるビュー名および説明の変更に制限されています。 |
getUserPreferences
|
ユーザーのユーザー・プリファレンスのリストを取得します。ユーザー・プリファレンスは、単純な名前/値ペアの文字列です。ユーザー・プリファレンスはユーザーごとにプライベートです（ただし、BPMWorkflowAdminも問い合せて更新できます）。
|
setUserPreferences
|
ユーザーのユーザー・プリファレンス値を設定します。前に格納されていて新規のユーザー・プリファレンス・リストに含まれていないプリファレンスは削除されます。 |
getPublicPreferences
|
ユーザーのパブリック・プリファレンスのリストを取得します。パブリック・プリファレンスはユーザー・プリファレンスに似ていますが、すべてのユーザーが問合せできます。ただし、このプリファレンスを更新できるのは所有者またはBPMWorkflowAdminのみです。パブリック・プリファレンスは、アプリケーション単位のプリファレンスを格納する場合に役立ちます（プリファレンスをMyAppPrefsなどのダミー・ユーザー名で格納できます）。
|
setPublicPreferences
|
ユーザーのパブリック・プリファレンスを設定します。 |
|
関連項目:
|
ランタイム構成サービスは、タスク・サービスのランタイム環境で使用されるメタデータの管理方法を提供します。主に、タスク・ペイロード・フレックス・フィールド・マッピングの管理をサポートします。
タスク・サービスで使用されるタスク・オブジェクトには多数のフレックス・フィールド属性が含まれており、タスク・ペイロードからの情報を移入できます。これにより、タスク・ペイロード情報を問い合せ、タスク・リストに表示し、ワークフロー・ルールに使用できます。
ランタイム構成サービスを使用すると、管理者は単純タスク・ペイロード属性とこれらのフレックス・フィールド属性とのマッピングを作成できます。
ペイロード・マッピングを更新できるのは、BPMWorkflowAdmin権限を持つユーザーのみです。ただし、認証済ユーザーは、このサービスの問合せメソッドを使用できます。
管理者は、各種フレックス・フィールド属性を表す属性ラベルを作成できます。これらの属性ラベルは、属性にわかりやすいラベルを提供します（たとえば、フレックス・フィールド属性TextAttribute1を表すラベルLocationを作成できます）。特定のフレックス・フィールド属性に複数のラベルを関連付けることができます。ユーザーがワークリスト・アプリケーションで特定のタスクの属性リストを表示すると、この属性ラベルが表示されます。特定のタスク・タイプの属性ラベルは、タスク・メタデータ・サービスのgetTaskAttributesForTaskDefinitionメソッドをコールして決定できます。
属性ラベルを定義する際に、次のフィールドにはサービスにより自動的に移入されます。 これらの属性の値を属性ラベルの作成時または更新時に指定する必要はありません。
Id
CreatedDate
WorkflowType
Active
タスク属性フィールドに有効な値は、次のとおりです。
TextAttribute1からTextAttribute10まで
FormAttribute1からFormAttribute5まで
UrlAttribute1からUrlAttribute5まで
DateAttribute1からDateAttribute5まで
NumberAttribute1からNumberAttribute5まで
その後、タスク・ペイロード・フィールドと属性ラベルとのマッピングを作成できます。たとえば、ペイロード・フィールドcustomerLocationを属性ラベルLocationにマップできます。様々なタスク・タイプで同じ属性ラベルを共有可能です。これにより、同じ意味を持つ異なるタスク・タイプのペイロード属性を同じ属性ラベルにマップできます。
|
注意: マップできるのは、単純XMLタイプのペイロード・フィールドのみです。 |
ランタイム構成サービスには、サーバーでサポートされているDynamic Assignment Functionを問い合せるためのメソッドも用意されています。
表15-21に、ランタイム構成サービスのメソッドを示します。パッケージoracle.bpel.services.workflow.runtimeconfigは、ランタイム構成サービスに対応しています。
表15-21 ランタイム構成サービス
| メソッド | 説明 |
|---|---|
GetWorkflowPayloadMappings
|
特定のワークフロー・タスク定義に関するすべてのフレックス・フィールド・マッピングのリストを取得します。 |
CreateAttributeLabel
|
特定のタスク・フレックス・フィールド属性を表す新規の属性ラベルを作成します。 |
updateAttributeLabel
|
既存の属性ラベルを更新します。 |
DeleteAttributeLabel
|
既存の属性ラベルを削除します。 |
getAttributeLabelUsages
|
ラベルが現在使用されているマッピング（存在する場合）の属性ラベル（すべての属性ラベル、または特定のタイプの属性のラベル）のリストを取得します。 |
createPayloadMapping
|
属性ラベルとタスク・ペイロード・フィールドとの新規マッピングを作成します。 |
deletePayloadMapping
|
既存のペイロード・マッピングを削除します。 |
getUserDynamicAssignmentFunctions
|
このサーバーに実装されているユーザーを選択できるDynamic Assignment Functionのリストを返します。 |
getGroupDynamicAssignmentFunctions
|
このサーバーに実装されているグループを選択できるDynamic Assignment Functionのリストを返します。 |
|
関連項目:
|
属性ラベルは、タスク・フレックス・フィールド属性にわかりやすいラベルを添付する手段を提供します。ユーザーのロケールに適した言語に翻訳された属性ラベルを表示することが望ましい場合があります。
そのために、WorkflowLabels.propertiesリソース・プロパティ・ファイルにエントリを追加し、同じエントリを関連リソース・バンドルに他の言語で追加できます。このファイルはSOA_Oracle_Home¥bpel¥system¥services¥config¥wfresourceディレクトリにあります。
フレックス・フィールド属性ラベルのエントリには、次の書式を使用する必要があります。
FLEX_LABEL.[label name]=Label Display Name
たとえば、Locationというラベルのエントリは次のようになります。
FLEX_LABEL.Location=Location
これらのファイルに属性ラベルのエントリを追加するかどうかはオプションであることに注意してください。ファイルにエントリが存在しなければ、APIを使用して指定した属性ラベルの名前がかわりに使用されます。
この項では、割当てサービスの構成方法について説明します。
この項の内容は次のとおりです。
Dynamic Assignment Functionでは、グループ、ユーザー・リストまたはグループ・リストから、特定のユーザーまたはグループが選択されます。
選択は、特定のDynamic Assignment Functionに固有の基準に従って行われます。Oracle BPEL Process Managerには、表15-22に示す3つのDynamic Assignment Functionが組み込まれています。
表15-22 Dynamic Assignment Function
| 関数 | 説明 |
|---|---|
ROUND_ROBIN
|
各ユーザーまたはグループを順番に選択します。 |
least-busy
|
現在割り当てられているタスク数が最も少ないユーザーまたはグループを選択します。 |
most-productive
|
特定の期間（デフォルトでは過去7日間）に最も多くのタスクを完了したユーザーまたはグループを選択します。 |
これらの関数ではいずれもユーザーの休暇ステータスがチェックされます。現在割当てできないユーザーにタスクが自動的に割り当てられることはありません。
これらのDynamic Assignment Functionは、BPELプロセスまたはタスク定義でカスタムXPath関数を使用してコールできます。
wfDynamicUserAssign
wfDynamicGroupAssign
これらのXPath関数は、次のパラメータを2つ以上指定してコールする必要があります。
コールするDynamic Assignment Functionの名前。
関数の実行対象となるグループの名前（またはユーザー・リストやグループ・リスト）。（オプション）ユーザーまたはグループが属しているアイデンティティ・レルム（デフォルト値はデフォルトのアイデンティティ・レルム）。
Dynamic Assignment Function固有のその他のオプション・パラメータ。割当て関数most-productiveの場合は、ユーザーの生産性の計算対象となる期間（日数）です。他の2つの関数では、追加のパラメータは使用しません。
また、グループ用に作成したワークフロー・ルールでは、Dynamic Assignment Functionを使用してタスクを再割当てするメンバーをそのグループから選択できます。
3つの関数の他に、独自のDynamic Assignment Functionを実装して構成できるようにDynamic Assignment Frameworkが用意されています。
独自のDynamic Assignment Functionを実装するには、次の一方または両方のインタフェースを実装するJavaクラスを記述します。
oracle.bpel.services.workflow.assignment.dynamic. IDynamicUserAssignmentFunction oracle.bpel.services.workflow.assignment.dynamic. IDynamicGroupAssignmentFunction
Dynamic Assignment Functionでユーザーを選択する場合は、最初のインタフェースを実装します。グループを選択する場合は、第2のインタフェースを実装します。ユーザーとグループの両方を選択可能にする場合は、両方のインタフェースを実装します。
前述の2つのインタフェースは、どちらもインタフェースoracle.bpel.services.workflow.assignment.dynamic.IDynamicAssignmentFunctionを拡張します。
Javaクラスでは、そのインタフェースのメソッドも実装する必要があります。
これらのインタフェースを次に示します。
public interface IDynamicAssignmentFunction
{
/**
* Sets the initialization parameters required by the function (if any)
* This function is called automatically by the DynamicAssignmentRegistry
* on registration of a new function. Initialization parameters can be
* specified in the xml definition of the function in the dynamic assign
* config file
* @param initParams Map of String parameter values keyed by String parameter
* names
* @throws DynamicAssignmentException if implementation of method finds invalid
* parameters
*/
public void setInitParams( Map initParams ) throws DynamicAssignmentException;
/**
* Gets the name of this Dynamic Assignment Function
* @return String the name of the Dynamic Assignment Function
*/
public String getFunctionName();
/**
* Gets a description of this Dynamic Assignment Function
* @return String description of function
*/
public String getDescription();
}
public interface IDynamicGroupAssignmentFunction extends
IDynamicAssignmentFunction
{
/**
* This method contains the implementation of the Assignment Function
* Given a group name, it will return a subgroup in that group,
* according to the assignment pattern implemented
* @return String name of group
* @param groupName String name of group to select group from
* @param realm String name of Identity Service realm the group belongs
* to. If realm is null, the default Identity Service realm will be used.
* @param parameters String[] optional array of parameter values.
* Use of parameter values is implementation-specific.
*/
public String getGroupAssignment( String groupName, String realm, String[]
parameters )
throws DynamicAssignmentException;
/**
* This method contains the implementation of the Assignment Function
* Given an arbitrary list of groups, it will return a group in that
* list, according to the assignment pattern implemented
* @return String name of group
* @param groupNames List of groups to select from
* @param realm String name of Identity Service realm the groups belong
* to. If realm is null, the default Identity Service realm will be used.
* @param parameters String[] optional array of parameter values.
* Use of parameter values is implementation-specific.
*/
public String getGroupAssignment( List groupNames, String realm, String[]
parameters )
throws DynamicAssignmentException;
}
public interface IDynamicUserAssignmentFunction extends IDynamicAssignmentFunction
{
/**
* This method contains the implementation of the Assignment Function
* Given a group name, it will return a user in that group,
* according to the assignment pattern implemented
* @return String username of user
* @param groupName String name of group to select user from
* @param realm String name of Identity Service realm the group belongs
* to. If realm is null, the default Identity Service realm will be used.
* @param parameters String[] optional array of parameter values.
* Use of parameter values is implementation-specific.
*/
public String getUserAssignment( String groupName, String realm, String[]
parameters )
throws DynamicAssignmentException;
/**
* This method contains the implementation of the Assignment Function
* Given an arbitrary list of users, it will return a user in that
* list, according to the assignment pattern implemented
* @return String username of user
* @param usernames List of usernames to select user from
* @param realm String name of Identity Service realm the users belong
* to. If realm is null, the default Identity Service realm will be used.
* @param parameters String[] optional array of parameter values.
* Use of parameter values is implementation-specific.
*/
public String getUserAssignment( List usernames, String realm, String[]
parameters )
throws DynamicAssignmentException;
}
Dynamic Assignment Frameworkには、ユーティリティ・クラスoracle.bpel.services.workflow.assignment.dynamic.DynamicAssignmentUtilsも用意されています。
このクラスは、Dynamic Assignment Functionの実装時に役立つ多数のメソッドを提供します。
次に例を示します。
/**
* Method returns a list of users belonging to the specified group
* that are available (i.e. not on vacation etc.)
* @return List of String usernames of available users
* @param group - name of group to lookup users for
* @throws DynamicAssignmentException if error encountered looking up
* group, or checking users.
*/
public static List getAvailableUsersFromGroup( String group, String realm )
throws DynamicAssignmentException
/**
* Method returns a list of users from the specified list
* that are available (i.e. not on vacation etc.)
* @return List of String usernames of available users
* @param usernames - List of String usernames to check
* @param realm - realm that users belong to
* @throws DynamicAssignmentException if error encountered looking up
* group, or checking users.
*/
public static List getAvailableUsersFromList( List usernames, String realm )
throws DynamicAssignmentException
/**
* Method uses the specified group name to lookup the sub-groups belonging to
* that group using the identity service.
* @return List of String names of groups
* @param groupName name of group to lookup
* @param realm to lookup group in - if null, then use identity service default
* @realm
* @batam boolean - directsOnly: if true return only the direct sub-groups
* of this group. If false, return all groups belonging to this group.
* @throws DynamicAssignmentException if group could not be found
*/
public static List getGroupsFromGroup( String groupName
, String realm
, boolean directsOnly )
throws DynamicAssignmentException
/**
* Method uses the specified group name to lookup the users belonging to that
* group using the identity service.
* @return List of String usernames of user
* @param groupName String name of group to lookup
* @param realm to lookup group in - if null, then use identity service default
* @realm
* @throws DynamicAssignmentException if group could not be found
*/
public static List getUsersFromGroup( String groupName, String realm )
throws DynamicAssignmentException
/**
*Method returns the default identity management realm for the Identity Service
*Instance.
*/
public static String getIDServiceDefaultRealm( ) throws
DynamicAssignmentException
/**
* Method checks WF Schema to determine if the specified user is available
* (i.e. they are not on vacation etc.).
* @return true if user is available, false if they are on vacation
* @param username
* @param realm
*/
public static boolean isUserAvailable( String username, String realm )
throws DynamicAssignmentException
Dynamic Assignment Functionを構成するには、SOA_Oracle_Home¥bpel¥system¥services¥configディレクトリにあるwf-dynamic-assign-cfg.xmlファイルを使用します。
Dynamic Assignment Functionごとに、このファイルにエントリを<function>タグ形式で指定する必要があります。
functionタグには、次の2つの属性を含める必要があります。
name: 関数名
classpath: 関数を実装するクラスのクラスパス
また、functionタグ内ではオプションで必要な数の<property>タグを使用できます。これらのタグにより、Dynamic Assignment Functionに初期化パラメータが渡されます。各propertyタグにはname属性を含める必要があります。propertyの値は、タグ本体で指定します。
これらのタグで指定したプロパティ値は、Dynamic Assignment FunctionのsetInitParametersメソッドに（name属性の値で索引付けされた）マップとして渡されます。
関数のうち2つは、初期化パラメータをとります。この種の関数は次のとおりです。
ROUND_ROBIN: MAX_MAP_SIZEパラメータでは、関数でROUND_ROBINのカウントを維持できるユーザー・セットまたはグループ・セットの最大数を指定します。Dynamic Assignment Functionでは、ROUND_ROBIN関数を実行するように要求される各グループ（またはユーザーとグループのリスト）について、ユーザーとグループのリストがメモリーに保持されます。
most-productive: DEAFULT_TIME_PERIODパラメータで、ユーザーの生産性の計算対象となる期間（日数）を指定します。この値は、most-productive Dynamic Assignment Functionをコールするときに上書きできます。XPath関数のコールで第3のパラメータとして代替値を指定して、XPath関数を使用します。
ランタイム構成サービスには、使用可能なユーザーとグループのDynamic Assignment Functionのリストを返すメソッドが用意されています。これらの関数では、関数の名前とユーザー表示可能なラベルの両方が返されます。この関数では表示名のローカライズがサポートされるため、コンテキスト・ユーザーに適切な言語で表示されます。これらの関数は、使用可能なDynamic Assignment Functionのリストを表示するためにワークリスト・アプリケーションで使用されます。
Dynamic Assignment Functionの表示名（および適切なトランスレーション）を指定するには、エントリをリソース・プロパティ・ファイルWorkflowLabels.propertiesに追加し、関連リソース・プロパティ・ファイルには他の言語で追加します。このファイルはSOA_Oracle_Home¥bpel¥system¥services¥config¥wfresourceディレクトリにあります。
Dynamic Assignment Functionのエントリには、次の書式を使用する必要があります。
DYN_ASSIGN_FN.[function name]=Function Display Name
たとえば、ROUND_ROBIN関数のエントリは次のようになります。
DYN_ASSIGN_FN.ROUND_ROBIN = Round Robin
これらのファイルにDynamic Assignment Functionのエントリを追加するかどうかはオプションであることに注意してください。ファイルにエントリが存在しなければ、かわりに関数名（ROUND_ROBINなど）が使用されます。
ワークフロー・タスク参加者は、ルーティング・スリップで宣言的に指定されます。ルーティング・スリップでは、参加者およびワークフロー・タスクへの参加方法（管理チェーン階層、参加者の順序リストなど）を指定することでワークフローの進行方法を決定します。
ワークフロー・タスク参加者が複雑なルールを使用して動的に計算されるシナリオがあります。このような動的割当てをサポートするために、割当てサービスが使用されます。割当てサービスは、タスク割当て先の決定を担当します。独自の割当てサービスを実装し、その実装をプラグイン接続して特定のワークフローで使用することもできます。
この項の内容は次のとおりです。
割当てサービスにより、ワークフローの次のタスク割当て詳細が決定されます。
タスク開始時の割当て。
タスク再開始時の割当て。
ユーザーがタスクの結果を更新するときの割当て。タスクの結果が更新された場合は、そのタスクを他のユーザーにルーティングするか完了にできます。
タスク情報のリクエスト先の割当て先。
タスクでOracle BPEL Worklistアプリケーションからの再承認をサポートしている場合、ユーザーは再承認のための情報をリクエストできます。
再承認がサポートされている場合にタスクを再承認するユーザー。
ワークフロー・サービスでは、特定のタスクについて割当てサービスが識別されて起動され、タスク割当てが決定されます。
たとえば、単純割当てサービスの相互作用は次のとおりです。
クライアントが、割当てサービスによりルーティングが決定される経費承認タスクを開始します。
割当てサービスが、タスク割当て先をjcooperであると決定します。
jcooperがタスクを承認すると、割当てサービスがタスクをjsteinに割り当てます。また、割当てサービスはタスク作成者であるjlondonに必ず通知を送信するように指定します。
jsteinがタスクを承認し、割当てサービスは他にタスクの割当て先ユーザーがいないことを示します。
割当てサービスは、IAssignmentServiceインタフェースを使用して実装されます。ワークフロー・サービスは、次の情報を割当てサービスに渡してタスク割当てを決定します。
タスク・ドキュメント: ワークフローで実行されるタスク・ドキュメント。タスク・ドキュメントには、ペイロードと他のタスク情報（現在の状態など）が含まれています。
プロパティ・マップ: 割当てサービスを指定するときにプロパティのリストも指定して、タスク割当て先を決定するバックエンド・サービスにコールバックを相関付けることができます。
タスク履歴: タスク履歴は、タスクの履歴をトレースするための時系列順のタスク・ドキュメントのリストです。このリスト内のタスク・ドキュメントには、実際のタスクの属性のサブセット（state、updatedBy、outcome、updatedDateなど）が含まれています。
|
注意:
|
ワークフロー・サービスでワークフロー実行時に起動する独自の割当てサービス・プラグインを実装できます。
次の例に、TestAssignmentService.javaというIAssignmentServiceサンプル実装を示します。
/* $Header: TestAssignmentService.java 24-may-2006.18:26:16 rarangas Exp $ */
/* Copyright (c) 2004, 2006, Oracle. All rights reserved. */
/*
DESCRIPTION
Interface IAssignmentService defines the callbacks an assignment
service will implement. The implementation of the IAssignmentService
will be called by the workflow service
PRIVATE CLASSES
<list of private classes defined - with one-line descriptions>
NOTES
<other useful comments, qualifications, etc.>
MODIFIED (MM/DD/YY)
rarangas 01/30/06 -
*/
/**
* @version $Header: IAssignmentService.java 29-jun-2004.21:10:35 rarangas Exp
$
* @author rarangas
* @since release specific (what release of product did this appear in)
*/
package oracle.bpel.services.workflow.test.workflow;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import oracle.bpel.services.workflow.metadata.routingslip.model.*;
import oracle.bpel.services.workflow.metadata.routingslip.model.Participants;
import oracle.bpel.services.workflow.metadata.routingslip.model.ParticipantsType.*;
import oracle.bpel.services.workflow.task.IAssignmentService;
import oracle.bpel.services.workflow.task.ITaskAssignee;
import oracle.bpel.services.workflow.task.model.Task;
public class TestAssignmentService implements
oracle.bpel.services.workflow.task.IAssignmentService {
static int numberOfApprovals = 0;
static String[] users = new String[]{"jstein", "wfaulk", "cdickens"};
public Participants onInitiation(Task task,
Map propertyBag) {
return createParticipant();
}
public Participants onReinitiation(Task task,
Map propertyBag) {
return null;
}
public Participants onOutcomeUpdated(Task task,
Map propertyBag,
String updatedBy,
String outcome) {
return createParticipant();
}
public Participants onAssignmentSkipped(Task task,
Map propertyBag) {
return null;
}
public List getAssigneesToRequestForInformation(Task task,
Map propertyBag) {
List rfiUsers = new ArrayList();
rfiUsers.add("jcooper");
rfiUsers.add("jstein");
rfiUsers.add("wfaulk");
rfiUsers.add("cdickens");
return rfiUsers;
}
public List getReapprovalAssignees(Task task,
Map propertyBag,
ITaskAssignee infoRequestedAssignee) {
List reapprovalUsers = new ArrayList();
reapprovalUsers.add("jstein");
reapprovalUsers.add("wfaulk");
reapprovalUsers.add("cdickens");
return reapprovalUsers;
}
private Participants createParticipant() {
if (numberOfApprovals > 2) {
numberOfApprovals = 0;
return null;
}
String user = users[numberOfApprovals++];
ObjectFactory objFactory = new ObjectFactory();
Participants participants = objFactory.createParticipants();
Participant participant = objFactory.createParticipantsTypeParticipant();
participant.setName("Loan Agent");
ResourceType resource2 = objFactory.createResourceType(user);
resource2.setIsGroup(false);
resource2.setType("STATIC");
participant.getResource().add(resource2);
participants.getParticipantOrSequentialParticipantOrAdhoc().
add(participant);
return participants;
}
}
次のメソッドを1つ使用して、割当てサービスの実装クラスおよび関連クラスをOracle BPEL Process Managerのクラスパスで使用可能にする必要があります。
クラスをSOA_Oracle_Home¥bpel¥system¥classesディレクトリにロードし、同じディレクトリ内でJARファイルを解凍します。
Oracle BPEL Process Managerの共有ライブラリを変更してJARファイルを含めます。
|
注意:
|
Oracle BPEL Process Managerには、ワークフロー・サービスとアイデンティティ・サービスで使用できるようにXPath拡張関数が用意されています。XPath拡張関数は、XPath 2.0標準に類似しています。表15-23にサポート対象のワークフロー・サービス関数を、表15-24にサポート対象のアイデンティティ・サービス関数を示します。
表15-23 ワークフロー・サービス関数
| 関数 | 説明 | 参照先 |
|---|---|---|
hwf:clearTaskAssignees()
|
タスク内のタスク割当て先を消去します。 | 「clearTaskAssignees」 |
hwf:createWordMLDocument()
|
指定のXSLTをWordMLに変換してWord文書を作成します。 | 「createWordMLDocument」 |
hwf:getNotificationProperty()
|
特定の通知のプロパティを取得します。 | 「通知のコンテンツ」
|
hwf:getNumberOfTaskApprovals()
|
タスク承認数を取得します。 | 「getNumberOfTaskApprovals」 |
hwf:getPreviousTaskApprover()
|
前のタスク承認者を取得します。 | 「getPreviousTaskApprover」 |
hwf:getTaskAttachmentByIndex()
|
添付ファイルの索引でタスク添付ファイルを取得します。 | 「getTaskAttachmentByIndex」 |
hwf:getTaskAttachmentByName()
|
添付ファイル名でタスク添付ファイルを取得します。 | 「getTaskAttachmentByName」 |
hwf:getTaskAttachmentContents()
|
添付ファイル名でタスク添付ファイルのコンテンツを取得します。 | 「getTaskAttachmentContents」 |
hwf:getTaskAttachmentsCount()
|
タスク添付ファイル数を取得します。 | 「getTaskAttachmentsCount」 |
hwf:getTaskAttachmentByIndex()
|
特定のタスクのリソース文字列を取得します。 | 「getTaskAttachmentByIndex」 |
hwf:wfDynamicGroupAssign()
|
指定の割当てパターンに従って選択されたアイデンティティ・サービス・グループの名前を取得します。 | 「wfDynamicGroupAssign」 |
hwf:wfDynamicUserAssign()
|
指定の割当てパターンに従って選択されたアイデンティティ・サービス・ユーザーの名前を取得します。 | 「wfDynamicUserAssign」 |
表15-24 アイデンティティ・サービス関数
| 関数 | 説明 | 参照先 |
|---|---|---|
ids:getDefaultRealmName()
|
デフォルトのレルム名を取得します。 | 「getDefaultRealmName」 |
ids:getGroupProperty()
|
グループのプロパティを取得します。 | 「getGroupProperty」 |
ids:getManager()
|
指定したユーザーのマネージャを取得します。 | 「getManager」 |
ids:getReportees()
|
ユーザーの直接報告先を取得します。 | 「getReportees」 |
ids:getSupportedRealmNames()
|
サポートされるレルム名を取得します。 | 「getSupportedRealmNames」 |
ids:getUserProperty()
|
ユーザー・プロパティを取得します。 | 「getUserProperty」 |
ids:getUserRoles()
|
ユーザー・ロールを取得します。 | 「getUserRoles」 |
ids:getUsersInGroup()
|
グループ内のユーザーを取得します。 | 「getUsersInGroup」 |
ids:isUserInRole()
|
ユーザーに指定ロールがあるかどうかを検証します。 | 「isUserInRole」 |
ids:lookupGroup()
|
グループ・オブジェクトを取得します。 | 「lookupGroup」 |
ids:lookupUser()
|
ユーザー・オブジェクトを取得します。 | 「lookupUser」 |
表15-25に、このリリースで廃止になったワークフロー・サービス関数とアイデンティティ・サービス関数を示します。
表15-25 廃止になったワークフロー・サービス関数とアイデンティティ・サービス関数
| ワークフロー関数 | アイデンティティ・サービス関数 |
|---|---|
ora:getNumberOfTaskApprovals()
|
ora:getGroupProperty()
|
ora:getPreviousTaskApprover()
|
ora:getManager()
|
ora:getTaskAttachmentByIndex()
|
ora:getReportees()
|
ora:getTaskAttachmentByName()
|
ora:getUserRoles()
|
ora:getTaskAttachmentContents()
|
ora:getUsersInGroup()
|
ora:getTaskAttachmentCount()
|
ora:isUserInRole()
|
| |
ora:lookupGroup()
|
| |
ora:lookupUser()
|
| |
ora:getUserProperty()
|
Oracle BPEL Worklistアプリケーションで様々な言語でタスク詳細を表示できるように、リソース・バンドルを指定できます。
また、リソース・プロパティ・ファイルWorkflowLabels.propertiesを使用して次の表示名を設定できます。
Dynamic Assignment Function
ペイロード・マッピング属性ラベル
タスク属性
|
関連項目:
|
