TOP
＞
プロジェクト管理
＞ はじめに
企業戦略におけるビジネス・プロセス・インテグレーション
第３回：ビジネスプロセスを意味のあるプロセスに
著者：
日本アイ・ビー・エム 小倉 弘敬、佐藤 泉
2005/11/1
1
2
3
次のページ
はじめに
前回はBPIの実行時の特徴の1つである「複数システムの連携」について解説した。今回はもう1つの特徴である「ビジネス的に意味のある一連の作業の自動化」について、さらにBPIの開発時や運用時の特徴について、どのような要件があり、それを解決する機能が必要であるかを解説していく。
ビジネス的に意味のある一連の作業
単一システム内の1つの処理は、トランザクション処理と呼ばれる1つの作業単位（UOW：Unit Of Work）からできている。このUOWの中ではトランザクション処理を満たすための要件、ACID（Atomicity：原子性、Consistency：一貫性、Isolation：独立性、Durability：永続性）特性が保たれるように開発される。
Atomicity
（原子性）
処理が全て完了しているか、処理が全くされなかったことになっているかの状態しかないことを保証する
Consistency
（一貫性）
トランザクション後の結果に一貫性が保たれていることを保証する
Isolation
（独立性）
複数のトランザクション処理が同時に行われる場合、他のトランザクションから影響を受けずに実行できることを保証する
Durability
（永続性）
トランザクションの結果が永続的に保証される
表1：ACID特性
ACID特性の維持はデータベースやTPモニター（Transaction Processing Monitor）などのミドルウェアとアプリケーションによって保証される。
一方、BPIで問題にしているシステム連携処理は、様々なシステムを連携しているので単一トランザクション処理ではなく、複数のUOWから成り立っている。そのため単一システム内の個々のUOWではACID特性が保証されるが、ビジネス的に意味のある処理としてのACIDは特性が保証されない。
永続性がデータベースシステムによって実現されたとしても、他の特性（原子性・一貫性・独立性）は保証されない。そのうえ複数のUOWで構成されるため、中途半端な状態が存在してしまい、やはり原子性・一貫性を保証することはできない。また前述したように長時間にわたる処理を考えると、独立性を保証するために処理が終わるまでの間、関連するシステムにロックをかけるようなことは現実的ではない。
しかしシステム連携処理においても、ビジネス的に意味のある処理として、要件を満たす必要がある。このためには、処理の途中でACID特性が保証されない状態があったとしても、最終的にはビジネスレベルでACID特性を満たすようにすることが重要である。
そのための技術として補償（Compensation）という考え方がある。つまり、ビジネスレベルでの取り消し処理を実現するのである。以下の具体例をみながら、その仕組みを解説しよう。例えば顧客がインターネットで商品を注文した場合、おおまかには以下のような流れになる。
システムは在庫を調べ、在庫があれば顧客の注文を受け付ける
顧客のカードの有効性をチェックする
配送状況をみて、いつごろ発送できそうか顧客にメールを送る
実際に在庫データから購入分の商品数を引く
カードの決済処理をする
商品の発送を行う
表2：インターネットで商品を注文した時の処理の流れ
つまり、表2の各階段はそれぞれ別のシステムで実行されることが多く、それぞれ別のUOWとなる。インターネット注文が混みあって、プロセスが平行して同時に何件も発生した場合、1の段階で余裕のあった在庫が、4まで処理が進んだ時にはすでに在庫がなくなっている場合もある。
このような場合、プロセスは先に進むことができなくなるため、ビジネス的に一貫性を保つためにその注文を取り消さなくてはならない。つまりは4で失敗したため、3のUOWを取り消すために顧客へのキャンセルとお詫びのメールの送付を行い、1の取り消しとして受け付けた注文データはキャンセル状態にするといった処理が必要である。
上記の場合だけをみれば、4の処理時にif文を使用し処理を分岐させれば対応可能だと思われるかも知れない。しかし実際には、1〜6すべての処理時に失敗は起こりうるため、それぞれの取り消しのための処理も用意しなくてはならない。これはビジネスプロセスの定義において、通常処理フローと異常時の処理フローが混在することを意味し、プロセスの可読性を損ない開発生産性やメンテナンス性を悪化させる要因になる。
そこで、上記のような問題を回避するために補償の仕組みを利用し、下図のように取り消し処理を行う。
図1：取り消し処理
（画像をクリックすると別ウィンドウに拡大表示します）
4のステップで在庫数が購入予定数より少なかった場合、プロセスエンジンは補償のロジックを起動する。この補償ロジックと補償ロジックの起動はそのビジネスプロセスの定義時（開発時）において、プロセスの取り消し処理として記述されている必要がある。
そして、補償ロジックは各UOWについて定義することも可能であり、異なる処理箇所で異常が発生した場合でも、そこから任意の補償ロジックを起動させることもできるため、補償ロジックの記述は必要最小限ですむことになる。
現在、この補償の仕組みはWSBPELの仕様の一部として規定されており、ビジネスプロセスの補償はこれが標準となりつつある。
1
2
3
次のページ
著者プロフィール
日本アイ・ビー・エム株式会社 小倉 弘敬
日本アイ・ビー・エムソリューション開発 インテグレーション所属
ソフトウェア・エバンジェリスト。担当分野は、ビジネス・プロセス・インテグレーション（BPI:Business Process Integration）。WebSphere Business Integration（WBI）ソリューションセンターで、BPIソリューションの開発／提供に従事する。
著者プロフィール
日本アイ・ビー・エム株式会社 佐藤 泉
入社以来、ワークフロー、ビジネスプロセスエンジン、ビジネスプロセスモニターなどのソフトウェア製品の開発やそれらの製品をベースとしたソリューションの提案活動に従事。
特に、SOAに則ったBPI（Business Process Integration）やBIO（Business Innovation and Optimization）を得意分野とする。
INDEX
第3回：ビジネスプロセスを意味のあるプロセスに
はじめに
再開発、再利用性の向上
ビジネスプロセスの向上とビジネスパフォーマンスの向上
