![]() ![]() ![]() ![]() |
ワークリストでは、タスクはユーザに割り当てるアクティビティを表します。ユーザは、タスクの進行を管理し、タスクが適切な方法でスケジュールどおりに確実に完了するようにします。タスクには、1 つまたは複数のステップと、1 つまたは複数の終了ポイント (終端ステップ) を含めることができます。各ステップは、タスクの完了までの個別のフェーズを表します。ヒューマン アクターは、定義された各ステップでタスクのアクションを実行することでタスクを進めていきます。各ステップでは、ヒューマン アクターが選択できる 1 つまたは複数のアクションを定義します。「作業アクション」と呼ばれるアクションには、そのアクションが実行されたときにタスクを遷移させる次のステップが関連付けられています。このモデルでは、タスクで実行されたアクションで指示された方法で、計画された一連のステップに沿ってタスクを進めていくことができます。
終端ステップは、タスクの有効期間の終わりを示します。終端ステップには、ユーザが実行した作業アクションからのみ到達できます。終端ステップには、(完了ステップによる) 正常な完了または (中止ステップによる) 異常終了を示すマークを付けることができます。タスク プランには、終端ステップが少なくとも 1 つは必要です。
タスクはユーザに割り当てることができ、ユーザはタスクを申請できます。タスクは、タスク データを表す一連のプロパティに関連付けられています。タスクのステップが完了すると、ユーザはプロパティを指定および変更できます。
特定タイプのタスクのステップとプロパティはタスク プランで定義され、そのタイプのタスクの全インスタンスに適用されます。特定タイプのすべてのタスクは、そのタスク タイプに定義されたプランによって制御されます。タスク プランは、そのプランの制御対象となるタイプのタスク インスタンスを作成する前に設計者が定義します。
関連付けられているタスク プランに関係なく、すべてのタスク インスタンスには、次のようなプロパティ (システム プロパティ) があります。
さらに、タスク インスタンスに関連付けられたタスク プランでは、タスク インスタンスの他の要素を定義します。次のような要素があります。
タスクの管理状態は、ワークリスト システムがタスク インスタンスを現在どのように処理しているかを示す値です。次のように、さまざまな管理状態があります。
タスクの作業状態は、そのタスクで作業できるヒューマン アクターとタスクとの現在の関連付けを示す値です。次のように、さまざまな作業状態があります。
タスクの管理状態に影響する多数のグローバル アクションが定義されています。これらのアクションは、タスク プランに関係なく、どのタスク インスタンスでも実行できます。管理状態に影響するアクションは次のとおりです。
すべてのタスクには、システム プロパティと呼ばれる多数の組み込みのプロパティがあります。編集可能なシステム プロパティは、タスク プランおよびタスク プランのステップやアクションを定義するときに指定できます。また、タスク プランに関連するプロパティを定義することもできます。これらは、ユーザ プロパティと呼ばれます。
タスク プランを設計および開発するときに、以下のプロパティを指定できます。
すべてのタスクには、個々のタスク プランではなく、ワークリストによって定義された多数の組み込みのプロパティがあります。これらのプロパティは、コンストラクタまたはステップで実行されるアクションを通じて設定できます。システム プロパティと呼ばれるこれらのプロパティは、システム プロパティ名にシステム定義のプレフィックスを付けることによって、アクションまたはコンストラクタのプロパティ名リストで参照できます。
注意 : | このプレフィックスは、ロケールによって異なります。米国英語ロケールの場合、プレフィックスは「sys:」になります。 |
編集可能なシステム プロパティとして、タスク名、コメント、優先度、タスクの完了期日、タスクの見積り時間、現在のステップの完了期日、および現在のステップの見積り時間があります。
タスクのユーザ プロパティは、タスク プランのすべてのインスタンスに対して保持するデータ要素を定義する、名前と型の多数のペアで構成されます。これらのデータ要素は、特定のタスクの完了に関与する関係者間で渡されるデータを表します。タスク プランでは、そのタスク タイプの目的を果たす上で役立つユーザ プロパティを定義できます。
実行時に、ワークリスト管理者 (およびワークリスト API とタスク コントロール) は、必要に応じて、タスク インスタンスのプロパティ (ユーザとシステムの両方) を変更できます (新しいユーザ プロパティの追加など)。プロパティを変更するには、タスクのタスク プランのコピーを作成して、ユーザ プロパティを追加し、タスク プランの設定グローバル アクションによってタスク インスタンスに新しいタスク プランを適用します。この機能により、ワークリスト管理者は、タスク インスタンスごとに発生する可能性のある特殊な状況に対応できます。
ワークリストでは、一部のシステム データ型が定義されていますが、ユーザ定義のデータ型を追加することもできます (新しいデータ型の SPI レイヤを実装することによりプラグインされます)。システム データ型は次のとおりです。
MIME タイプと値が指定された TaskMessage (MIME タイプは動的に変更でき、値は MIME タイプに従って解釈される)
Worklist アプリケーションは、EAR プロジェクトと Web プロジェクトで構成されます。これらのプロジェクトには、1 つの作業単位に関係するすべてのファイルとディレクトリが含まれます。必要に応じて、Worklist アプリケーションのユーティリティ フォルダを用意し、WebLogic System Integration とコントロール スキーマを格納することもできます。
EAR プロジェクトはエンタープライズ アプリケーションに対応します。このプロジェクトをビルドおよびデプロイすることにより、企業のプロセス フロー全体を作成できます。作成したタスク プランは、<EAR プロジェクト名> フォルダにある EARContent フォルダの下に格納されます。
Web プロジェクトは、システムのユーザ インタフェースとして機能する、ワークリストの Web アプリケーションと対応しています。Web プロジェクトは EAR プロジェクトの一部です。
注意 : | このドキュメントに記載された <Web プロジェクト名> は、このフォルダの名前を指します。 |
ワークリストでは、開発者はさまざまなタイプのカスタム プラグイン クラスを定義できます。たとえば、com.bea.wli.worklist.api.config.AssignmentHandler
を実装することでカスタム割り当てハンドラを定義できます。また、com.bea.wli.worklist.api.events.TaskEventListener
を実装すると、カスタム タスク イベント リスナを実装できます。
カスタム プラグイン クラスは、ホスト アプリケーションのクラス ローダから利用できるように、ユーティリティ プロジェクト内に配置する必要があります。これらのクラスを作成するには、開発者はワークリスト API クラスにアクセスする必要があります。カスタム プラグイン クラスを実装するには、プラグイン コードをホストするユーティリティ プロジェクトを作成し、このプロジェクトのビルド パスに worklist-client.jar
ライブラリを手動で追加します。
worklist-client.jar
ライブラリをプロジェクトのビルド パスに追加するには、以下の手順を実行します。
これで、ユーティリティ プロジェクトから、プラグイン実装の作成に必要なワークリスト API クラスにアクセスできるようになります。
Worklist アプリケーションには、次の 3 つのタイプがあります。
独自のワークリスト システム インスタンス、タスク プラン、ワークリスト ユーザ ポータルおよびマネージャ ポータルをホストする、スタンドアロン Worklist アプリケーションです。この定義により、スタンドアロン Worklist アプリケーションは、ワークリスト ホスト アプリケーション、タスク プラン ホスト アプリケーション、およびワークリスト ポータル ホスト アプリケーションとなります。単純クライアントは、ワークリスト API を使用してワークリストと相互作用します。
ワークリスト システム インスタンスをホストするアプリケーションです。ほとんどの場合、Worklist アプリケーションは、ワークリスト ホスト アプリケーションでもあります。ワークリスト システム ホストはタスク プランを定義し、Worklist User Portal を使用してワークリストと相互作用します。
ワークリスト ポータルのインスタンスをホストまたはデプロイするアプリケーションです。ほとんどの場合、Worklist アプリケーションは、ワークリスト ポータル ホスト アプリケーションでもあります。プロセス ホストは WebLogic Integration プロセスとタスク プランを定義し、プログラムではワークリスト コントロールを使用してワークリストと相互作用します。また、ユーザのアクションについては、ユーザ ポータルを使用してワークリストと相互作用します。
特定タイプのタスクのステップとプロパティはタスク プランで定義され、そのタイプのタスクの全インスタンスに適用されます。タスク プランの各ステップ (完了ステップや中止ステップなどの終端ステップを除く) にアクションを含めることができます。アクションにより、あるステップから別のステップにタスク インスタンスを遷移させることができます。権限を有するユーザまたはシステム アクターがこのようなアクションを実行できます。
ステップとは、タスクのライフサイクルにおける 1 つのフェーズです。ワークリスト設計者は、タスク プランの範囲内で各ステップを定義します。ステップは、処理中のタスクを進めるために実行できるアクションの簡単なセットを表します。終端ステップ (完了ステップまたは中止ステップ) では、ステップを終了させることができます。ステップには、次のような要素が含まれます。
パレット ビューでステップを選択し、タスク プラン エディタにドラッグ アンド ドロップできます。これで、ステップにアクションを追加できるようになります。また、ステップのプロパティを設定することもできます。詳細については、「タスク プランへのステップとアクションの追加」を参照してください。
アクションは、ユーザが実行する作業、またはタスク インスタンスのステップでユーザが下す決定事項を表します。ユーザは、タスク インスタンスの現在のステップに定義されたアクションを実行します。アクション定義はステップ内で存続します。また、ステップはタスク プラン内で存続します。ワークリストには、次のようなさまざまなタイプのアクションがあります。
タスク プラン パースペクティブのパレット ビューでこれらのステップを選択し、アクションをタスク プランのステップ内にドラッグ アンド ドロップできます。詳細については、「タスク プランへのステップとアクションの追加」を参照してください。
作業アクションは、ユーザが実行した作業、またはこのタスクについてユーザが下した決定事項を表します。作業アクションは、あるステップから別のステップにタスクを遷移させます。遷移の発生元のステップは、作業アクションを含むステップです。遷移後のステップまたは終端状態は、作業アクション内で名前が指定されているか、特定されています。終了した作業または下された決定に関する情報は、タスクのプロパティに取り込まれます。作業アクションでは、そのアクションの完了に必要なデータ (存在する場合)、アクションの内容の説明、およびヒューマン アクターがアクションを実行する必要のある状況を定義します。
作業アクションでは、アクションの実行時に更新または指定する必要のあるいくつかのプロパティを指定できます。これは、タスクのプロパティを更新するための主要メカニズムです。
タスクで割り当てアクションを実行すると、アクションに定義されている割り当て手順に従ってタスクが再割り当てされます。
戻りアクションは、後日、別のユーザがタスクを申請できるように、タスクを割り当て済み作業状態に戻します。
次のユーザへの割り当てアクションは、「反復リスト」候補リスト処理と連動し、タスクを候補リスト内の次のユーザに割り当てます (また、そのユーザに代わってタスクを自動的に申請します)。詳細については、「候補リストの処理」を参照してください。
パレット ビューでの接続は、タスク プランのステップとアクションのナビゲーションを指定するために使用されます。この接続により、コネクタがタスク プランの最初のステップに接続されます。また、アクションを実行する順序も指定されます。
タスク プランでは、タスク プランの新しいインスタンスの初期化に使用する 1 つまたは複数のコンストラクタを定義します。コンストラクタは以下を定義します。
コンストラクタに定義されたプロパティは、作業アクションでリストされたプロパティと同じルールに従います。つまり、コンストラクタは、タスク プランまたは編集可能なシステム タスク プロパティで定義されたプロパティを参照できます。
注意 : | タスク プランでは、必須プロパティを定義しないコンストラクタを定義できます。また、このようなコンストラクタがいくつあってもかまいません。 |
タスクは、明示的に割り当てることも、割り当て対象リストを使用して暗黙的に割り当てることもできます。Worklist Console からタスクを割り当てる方法については、『Worklist Console の使い方』の「ワークリスト管理」にある「ユーザまたはグループへのタスクの割り当て」を参照してください。タスク プラン エディタからタスクを割り当てる方法については、「割り当て手順」を参照してください。
割り当て対象リストが評価されて、タスクの申請者候補のリストが生成されます。次に、この候補リストが評価されます。候補リストの評価の考えられるシナリオを以下に示します。これらのシナリオは、選択した候補リスト処理のタイプに基づいています。候補リスト処理の有効な値は次のとおりです。
割り当て対象リストから複数の候補を含む候補ユーザのリストが生成され、候補リストの処理タイプが「ロード バランシング」に設定されている場合、ワークリストは、ユーザの作業負荷と、場合によってはユーザの可用性に基づいてユーザを選択します。この動作は、「ロード バランシング」と呼ばれます。
ロード バランシングは若干コストがかかる可能性があるため (特に、候補ユーザの大規模なリストについて作業負荷を評価する場合)、ワークリストではタスク管理者がステップ バイ ステップ方式でロード バランシングを明示的に有効にしていくことができます。ロード バランシングは、WorklistTaskAdmin.assignTask()
呼び出しでの割り当て手順、または割り当て手順を指定するステップで、候補リストの処理タイプを LoadBalancing
に指定することで有効にできます。
デフォルトでは、ロード バランシングにおいては (ビジネス カレンダーに基づく) ユーザの可用性は考慮されません。ただし、ユーザの可用性を考慮する必要がある場合は、ロード バランシング プロセス内でチェックを有効にできます。可用性は「スコア」として計算されます。スコアの値が大きいほど、可用性が高いことを示します。
ドメインは、Configuration Wizard を使用して作成できます。詳細については、『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』の「新しい WebLogic ドメインの作成」を参照してください。
Worklist アプリケーションをデプロイできるサーバをコンフィグレーションする必要があります。
注意 : | サーバをコンフィグレーションしていない場合に、Workshop for WebLogic Platform から Worklist Console を起動しようとすると、次のエラー メッセージが表示されます。 |
サーバをコンフィグレーションするには、以下の手順を実行します。
Workshop for WebLogic Platform IDE が表示されます。
Worklist アプリケーションは、EAR プロジェクトと Web プロジェクトで構成されます。これらのプロジェクトには、1 つの作業単位に関係するすべてのファイルとディレクトリが含まれます。
EAR プロジェクトは、エンタープライズ アプリケーションに対応しています。このプロジェクトをビルドおよびデプロイすることにより、企業のプロセス フロー全体を作成できます。
Web プロジェクトは、システムのユーザ インタフェースとして機能する、ワークリストの Web アプリケーションと対応しています。Web プロジェクトは EAR プロジェクトの一部です。
新しい Worklist アプリケーションを作成するには、以下の手順を実行します。
Worklist アプリケーションが作成されます。[パッケージ・エクスプローラー] ビューに、3 つのプロジェクト フォルダ (EAR プロジェクト、Web プロジェクト、ユーティリティ プロジェクトごとに 1 つのフォルダ) が自動的に作成され、表示されます。
タスク プラン パースペクティブが現在のパースペクティブでない場合、[関連付けられたパースペクティブを開きますか?] ダイアログが表示されます。
これで、タスク プラン パースペクティブが Worklist アプリケーションに関連付けられました。Workshop for WebLogic Platform ウィンドウの右上に、[タスク プラン] アイコン () が表示されます。
<EAR プロジェクト フォルダ名>\EarContent
フォルダを右クリックし、[新規
このタスク プラン フォルダは、<EAR プロジェクト フォルダ名>\EarContent
フォルダの下に作成されます。
タスク プランが作成され、コンソールにタスク プランが開きます。コンソールでは、タスクのステップとアクションを定義できます。タスク プラン ファイル (.task ファイル) は、コンテンツ フォルダの下の WebLogic EAR プロジェクト内に直接配置されます。このフォルダ名は、プロジェクトのコンフィグレーションによって異なる場合がありますが、通常は EARContent という名前が付けられます。
タスク プランは、ユーザがタスクでの作業時に実行する必要のあるアクションを定義するステップの集まりです。タスク プランにステップとアクションを追加するには、以下の手順を実行します。
*.task
ファイル) をダブルクリックします。
新しいステップのデフォルト名は、Step
#
です。ここで、# は、1 で始まり、タスク プランの既存のステップの数に応じて増加する数値です。
新しいアクションのデフォルト名は、Action
#
です。ここで、# は、1 で始まり、ステップの既存のアクションの数に応じて増加する数値です。
注意 : | 必要に応じて、タスク プランのユーザ プロパティを作成し、これらのユーザ プロパティをアクションに定義できます。詳細については、「タスク プランのユーザ プロパティの作成」を参照してください。 |
接続を指定すると、次の図に示すようにソース アクションに緑色のチェック マークが表示されます。アクションを別のステップまたはアクションに接続すると、タスク プラン内のステップとアクションの実行順序が指定されます。
注意 : | 現在のアクションの完了後に、アクションをステップに確実に戻すために、自己遷移を使用することもできます。図 2-6 の場合、ステップ 1 のアクション 3 が完了すると、制御がステップ 1 に戻ります。自己遷移を有効にするには、アクションをダブルクリックします。 |
すべてのステップとアクションがタスク プランに追加されます。次に、タスク プランのコンストラクタを定義する必要があります。
タスク プランには、タスク インスタンスの作成方法を定義するコンストラクタが少なくとも 1 つ含まれています。タスク プランのコンストラクタは、タスク インスタンスの作成に使用された初期データ、および作成されたタスク インスタンスのステップを示します。各コンストラクタには、ステップが関連付けられている必要があります。1 つのタスク プランに対して複数のコンストラクタが存在してもかまいません。
注意 : | コンストラクタを呼び出すことができるのは、許可されたユーザまたはシステム アクターです。したがって、タスク インスタンスは、プロセスでユーザによるデータ入力またはシステムの実行によって作成できます。 |
アウトライン ビューにタスク プランを表示することもできます。
ステップでは、その親タスク プランのインスタンスを申請できるユーザを制御する割り当て手順を定義します (親タスク プランのインスタンスがこのステップに存在する場合)。タスク インスタンスを申請できるのは、常に 1 人のヒューマン アクターに限られます。したがって、現在のステップの割り当て手順 (存在する場合) は、実際にはタスク インスタンス全体の割り当て手順になります。
タスク インスタンスを申請するアクターは、タスク インスタンスの「申請者」と呼ばれます。このアクターは、名前、グループ、またはロールによって指定できます。ヒューマン アクターの場合、ステップを申請するには、名前付きアクターのいずれかである、名前付きグループのいずれかに属している、または名前付きロールを付与されている必要があります。
ステップのシステム プロパティを設定するには、以下の手順を実行します。
これで、システム プロパティが設定されました。必要に応じて、 アイコンをクリックし、ステップのデフォルト システム プロパティに戻します。デフォルト値に戻すことができるのは、タスク プランを保存しなかった場合のみです。
すべてのアクションに対して以下のシステム プロパティを設定できます。
ユーザ プロパティは、タスク プランの業務固有のデータ要素です。ユーザ プロパティはグローバルであり、タスク プランのライフサイクル全体を通じてすべてのステップに適用されます。
データ型には、Boolean、DateTime、Float、Integer、JavaBean、String、URL
、または XMLBean
を指定できます。[バリアント情報] フィールドで、DateTime、JavaBean、XMLBean
を選択した場合は、プロパティを指定する形式を入力します。たとえば、日時形式として
mm/dd/yyyy `at' hh:mm:ss
を指定できます。
タスク プランの設計およびデプロイの最終段階では、必要なエンタープライズ モデルの仕様に従ってタスク プランが機能しているかどうかを検証します。
注意 : | タスク プランを正常にデプロイするには、タスク プランのバージョンが 1.0 であることが必要です。プロパティ ビューで、タスク プランのバージョンが 1.0 であることを確認します。 |
必要に応じて、[WorklistAutomatic Layout] を選択すると、タスク プランのレイアウトを変更できます。
既存のタスク プランを現在のワークスペースにインポートするには、以下の手順を実行します。
注意 : | [インポート] ダイアログで、インポート元として [ファイル システム] を選択することもできます。[ファイル システム] ダイアログが表示されます。タスク プランのパスを指定し、インポートするプロジェクトを選択して、ファイル システムのインポート先の親フォルダを指定します。[終了] をクリックして、タスク プランをインポートします。 |
タスク プランを完全にモデル化したら、WebLogic Integration Server にデプロイできます。
サーバにプロジェクトをデプロイするには、ある程度の時間がかかります。タスク プランが正常にデプロイされると、Workshop for WebLogic 環境内の Worklist User Portal にタスク プランが開きます。
タスク プランは、必要に応じて変更できます。タスク プランを変更したら、必ず再デプロイしてください。
注意 : | タスク プランを更新したら、タスク プランを再デプロイします。詳細については、「タスク プランのデプロイ」を参照してください。更新済みの変更は、タスク プランの再デプロイ後に作成したタスク インスタンスにのみ反映されます。 |
![]() ![]() ![]() |