決済結果の受信〜発送完了通知

決済結果の受信〜発送完了通知

後半部分の修正は、前半部分で行った修正と内容的にはほぼ同内容である。以下に変更後のフローを示す。

図5：修正後のフロー2
（画像をクリックすると別ウィンドウに拡大図を表示します）

カードの決済結果がNGであった場合提携会社には決済結果が通知される。提携会社のビジネスプロセスはこの情報を基にそれまでに行った受注処理のキャンセルなどの対応をとることができる。

カードの決済結果がOKの場合は、自社内での発送プロセスと提携会社からの発送完了通知を並列に実行する。自社での発送と提携会社での発送の両方が完了したことを確認してから、顧客に発送完了のお知らせを行う。

修正後のフローのBPELについては、アクティビティの名称などが変わるだけで基本的に前半部分と同じであるため割愛する。

以上の変更において、もともとあった他システムとの連携には何も影響をおよぼさずに、新しい要件の実装を追加できている点に注目してほしい。

終わりに

従来技術であるEAIのような非SOA的な接続形態では、様々なシステムに対して横断的に存在しているプロセスが明確に意識されていなかった。そのようなシステムにプロセスの変更を適用する場合、各システムは全体の変更の中でそのシステムに関係のある部分のみを個別に対応していくことでシステムの更新を行っていた。

BPIを利用したSOAに基づくシステムではプロセスは外部化され、プロセスに対する変更は外部化されたプロセスの中で明確に意識されてプロセス自身や個々のシステムへの変更要件へとブレイクダウンされていく。これをまとめるとSOAに基づくシステムは次のようなメリットを享受することができるとい える。

今回はO社のネット注文システムを例にビジネスプロセスに対して変更を加えるための具体的な手順を解説した。SOAに基づくシステムであれば既存の連携に影響を与えることなく新しいビジネス要件を容易に追加していくことができることがご理解いただけたと思う。

   ビジネス環境は絶えず変化しているので、一時点での成功だけでは次の成功の保証にはならない。環境の変化を捉えて戦略も変化させることが重要である。SOAやビジネスプロセスインテグレーションは、戦略の変更をシステム面からバックアップするのである。

   次回はメディエーション機能の1つであるリレーションシップ機能を利用したシナリオの実現例について紹介する。