 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 長時間にわたる処理 | ||||||||||||
|
複数のシステムにまたがるビジネスプロセスの場合、人手による処理、バッチ処理、社外システムとの連携などにより、短時間で処理が終わらないケースが少なくない。このような処理の場合には長時間にわたる処理特有の要件も存在する。 処理が長時間になる場合、そのビジネスプロセスがどのような状態になっているのかを確認するという要件がある。システム管理者が確認する場合もあれば、エンドユーザが自分に関係するビジネスプロセスがどのような状態にあるか確認する場合もある（例えば、インターネットで購入した商品が、既に発送されたのか、在庫がなくまだ発送されていないのか確認するなど）。また、処理の途中でそのビジネスプロセスをキャンセルするという要件も存在する。 では、この「ビジネスプロセスの状態確認」と「ビジネスプロセスのキャンセル」について、これらを解決するために具体的にどのような機能が必要なのだろうか。 ビジネスプロセスの状態確認については、ビジネスプロセスの進捗状況をリアルタイムに監視できる必要があるが、そのための機能としては以下の項目の表示機能がある。
|
||||||||||||
|
表4：ビジネスプロセスの状態確認に必要な機能 |
||||||||||||
| これらにより、エンドユーザは自分の申し込みが、今どこまで進んでいるのか、どこで止まっているのか把握することができる。 次にビジネスプロセスのキャンセルのための機能であるが、実現するためには以下のような仕組みが必要である。
|
||||||||||||
|
表5：ビジネスプロセスの停止に必要な機能 |
||||||||||||
この機能を実現するための標準的な技術としては前述のWSBPELがあげられる。WSBPELには「コリレーション」と「イベントハンドラー」という機能ががある。「コリレーション」によってビジネスプロセスエンジンとしての仕組みの動作、つまりリクエストの中のある情報を元にそのメッセージを受け付けるのに適当なビジネスプロセスを検出することができ、また「イベントハンドラー」により、ビジネスプロセス中の任意のタイミングでイベントを受け付け、それをトリガーに起動する処理ロジックを定義することができる（図5）。 図5：イベントのキャンセル |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
