(57)【要約】【課題】疎結合なシステムにおいてビジネスプロセスの実行失敗を回避する。【解決手段】本発明のビジネスプロセス実行装置200は、ビジネスプロセス実行履歴記憶部254に記憶されるビジネスプロセスによるサービス実行結果から停止中のサービス280、281毎にサービス実行待機時間を算出するサービス待機時間計算部243と、ビジネスプロセス実行履歴記憶部254に記憶される最新のサービス実行結果からサービス280、281毎の稼動状態を判定するとともにサービス毎のサービス実行待機時間を取得するサービス稼動状態解析部242と、サービス280、281を実行する前にサービス280、281の稼動状態およびサービス実行待機時間を取得し、サービス280、281が稼動中である場合にはサービスを実行する一方、サービス280、281が停止中である場合にはサービス実行待機時間の間、サービスの実行を延期するサービス実行制御部233とを備える。【選択図】図１
2009282581.tif 000002
【特許請求の範囲】
【請求項１】
クライアントの処理要求に応じてビジネスプロセス定義に記述された順にネットワーク上の複数のサービスを実行するビジネスプロセス実行装置であって、
ビジネスプロセス実行履歴記憶部に記憶されるビジネスプロセスによるサービス実行結果から停止中のサービス毎にサービス実行待機時間を算出するサービス待機時間計算部と、
前記ビジネスプロセス実行履歴記憶部に記憶される最新のサービス実行結果からサービス毎の稼動状態を判定するとともに前記停止中のサービス毎のサービス実行待機時間を取得するサービス稼動状態解析部と、
前記サービスを実行する前に該サービスの前記稼動状態および前記サービス実行待機時間を取得し、該サービスが稼動中である場合には該サービスを実行する一方、該サービスが停止中である場合には前記サービス実行待機時間の間、該サービスの実行を延期するサービス実行制御部とを
備えることを特徴とするビジネスプロセス実行装置。
【請求項２】
請求項１に記載のビジネスプロセス実行装置において、
前記サービス待機時間計算部は、
前記サービス毎に、サービス実行失敗時刻と該サービス実行失敗時刻直後の同一サービスのサービス実行成功時刻との差分を前記ビジネスプロセス実行履歴記憶部から取得し、その平均を前記サービス実行待機時間として算出する
ことを特徴とするビジネスプロセス実行装置。
【請求項３】
請求項1に記載のビジネスプロセス実行装置において、
前記サービス待機時間計算部は、
前記各サービスの実行失敗の原因毎に、サービス実行失敗時刻と、該サービス実行失敗時刻直後の同一サービスのサービス実行成功時刻との差分を前記ビジネスプロセス実行履歴記憶部から取得し、その平均を前記各サービスの実行失敗の原因毎の前記サービス実行待機時間として算出する
ことを特徴とするビジネスプロセス実行装置。
【請求項４】
請求項１に記載のビジネスプロセス実行装置において、
前記サービス実行制御部は、
前記サービスの稼動状態の更新時刻と前記サービス実行制御部が処理を実行している時点の時刻とを比較し、その差が所定値以上である場合、前記サービスの稼動状態に関わらず該サービスを実行する
ことを特徴とするビジネスプロセス実行装置。
【請求項５】
請求項１に記載のビジネスプロセス実行装置において、
前記サービス実行制御部は、
前記サービス実行待機時間が所定値以上である場合、前記サービスの稼動状態に関わらず該サービスを実行する
ことを特徴とするビジネスプロセス実行装置。
【請求項６】
請求項１に記載のビジネスプロセス実行装置において、
あるビジネスプロセス定義が他のビジネスプロセス定義を実行する場合に該他のビジネスプロセス定義を解析して該他のビジネスプロセス定義が利用するサービスの一覧を取得する依存関係解析部と、
前記他のビジネスプロセス定義が利用する全てのサービスの稼動状態および該他のビジネスプロセス定義の配備状態から該他のビジネスプロセス定義が実行可能か否かを判定し、該他のビジネスプロセス定義が利用するサービスの前記サービス実行待機時間を前記サービス稼働状態解析部から取得して該他のビジネスプロセス定義のビジネスプロセス実行待機時間を決定するビジネスプロセス状態判定部とを
備えることを特徴とするビジネスプロセス実行装置。
【請求項７】
請求項６に記載のビジネスプロセス実行装置において、
前記依存関係解析部は、
前記他のビジネスプロセス定義に条件分岐が含まれる場合、該条件分岐よりも前に実行されるサービスを該他のビジネスプロセス定義が利用するサービスとして取得する
ことを特徴とするビジネスプロセス実行装置。
【請求項８】
請求項６に記載のビジネスプロセス実行装置において、
前記依存関係解析部は、
前記他のビジネスプロセス定義に非同期に応答が返ってくるサービスを実行する処理を含む場合、該非同期のサービスの実行処理よりも前に実行される全てのサービスを、該他のビジネスプロセス定義が利用するサービスとして取得する
ことを特徴とするビジネスプロセス実行装置。
【請求項９】
請求項６に記載のビジネスプロセス実行装置において、
前記ビジネスプロセス状態判定部は、
前記他のビジネスプロセス定義が利用するサービスの一覧を前記依存関係解析部から取得し、かつ、該取得した前記サービスの稼働状態を前記サービス稼動状態解析部から取得し、かつ、該他のビジネスプロセス定義の配備状態を前記ビジネスプロセス実行装置から取得し、
前記サービス一覧に含まれる全てのサービスが稼動状態であり、かつ、該他のビジネスプロセス定義が前記ビジネスプロセス実行装置上に配備されている場合に該他のビジネスプロセス定義が実行可能と判定する
ことを特徴とするビジネスプロセス実行装置。
【請求項１０】
請求項６に記載のビジネスプロセス実行装置において、
前記ビジネスプロセス状態判定部は、
前記他のビジネスプロセス定義が利用する１つ以上のサービスの稼動状態が停止である場合に、前記停止しているサービスのサービス実行待機時間を前記サービス稼働状態解析部から取得し、該取得したサービス実行待機時間のうち最も長いサービス実行待機時間を該他のビジネスプロセス定義の実行待機時間とする
ことを特徴とするビジネスプロセス実行装置。
【請求項１１】
クライアントの処理要求に応じてビジネスプロセス定義に記述された順にネットワーク上の複数のサービスを実行するビジネスプロセス実行方法であって、
ビジネスプロセス実行装置が、
ビジネスプロセス実行履歴記憶部に記憶されるビジネスプロセスによるサービス実行結果から停止中のサービス毎にサービス実行待機時間を算出し、
前記ビジネスプロセス実行履歴記憶部に記憶される最新のサービス実行結果からサービス毎の稼動状態を判定するとともに前記停止中のサービス毎のサービス実行待機時間を取得し、
前記サービスを実行する前に該サービスの前記稼動状態および前記サービス実行待機時間を取得して該サービスが稼動中である場合には該サービスを実行する一方、該サービスが停止中である場合には前記サービス実行待機時間の間、該サービスの実行を延期する
ことを特徴とするビジネスプロセス実行方法。
【請求項１２】
請求項１１に記載のビジネスプロセス実行方法において、
前記サービス実行待機時間の算出は、
前記サービス毎に、サービス実行失敗時刻と該サービス実行失敗時刻直後の同一サービスのサービス実行成功時刻との差分を前記ビジネスプロセス実行履歴記憶部から取得し、その平均を前記サービス実行待機時間として算出する
ことを特徴とするビジネスプロセス実行方法。
【請求項１３】
請求項１１に記載のビジネスプロセス実行方法において、
前記サービス実行待機時間の算出は、
前記各サービスの実行失敗の原因毎に、サービス実行失敗時刻と、該サービス実行失敗時刻直後の同一サービスのサービス実行成功時刻との差分を前記ビジネスプロセス実行履歴記憶部から取得し、その平均を前記各サービスの実行失敗の原因毎の前記サービス実行待機時間として算出する
ことを特徴とするビジネスプロセス実行方法。
【請求項１４】
請求項１１に記載のビジネスプロセス実行方法において、
前記ビジネスプロセス実行装置は、
前記サービスの稼動状態の更新時刻と処理を実行している時点の時刻とを比較し、その差が所定値以上である場合、前記サービスの稼動状態に関わらず該サービスを実行する
ことを特徴とするビジネスプロセス実行方法。
【請求項１５】
請求項１１に記載のビジネスプロセス実行方法において、
前記サービス実行待機時間が所定値以上である場合、前記サービスの稼動状態に関わらず該サービスを実行する
ことを特徴とするビジネスプロセス実行方法。
【請求項１６】
請求項１１に記載のビジネスプロセス実行方法において、
前記ビジネスプロセス実行装置は、
あるビジネスプロセス定義が他のビジネスプロセス定義を実行する場合に該他のビジネスプロセス定義を解析して該他のビジネスプロセス定義が利用するサービスの一覧を取得し、
前記他のビジネスプロセス定義が利用する全てのサービスの稼動状態および該他のビジネスプロセス定義の配備状態から該他のビジネスプロセス定義が実行可能か否かを判定し、該他のビジネスプロセス定義が利用するサービスの前記サービス実行待機時間を取得して該他のビジネスプロセス定義のビジネスプロセス実行待機時間を決定する
ことを特徴とするビジネスプロセス実行方法。
【請求項１７】
請求項１６に記載のビジネスプロセス実行方法において、
前記他のビジネスプロセス定義を解析して該他のビジネスプロセス定義が利用するサービスの一覧を取得するに際して、
前記他のビジネスプロセス定義に条件分岐が含まれる場合、該条件分岐よりも前に実行されるサービスを該他のビジネスプロセス定義が利用するサービスとして取得する
ことを特徴とするビジネスプロセス実行方法。
【請求項１８】
請求項１６に記載のビジネスプロセス実行方法において、
前記他のビジネスプロセス定義を解析して該他のビジネスプロセス定義が利用するサービスの一覧を取得するに際して、
前記他のビジネスプロセス定義に非同期に応答が返ってくるサービスを実行する処理を含む場合、該非同期のサービスの実行処理よりも前に実行される全てのサービスを、該他のビジネスプロセス定義が利用するサービスとして取得する
ことを特徴とするビジネスプロセス実行方法。
【請求項１９】
請求項１６に記載のビジネスプロセス実行方法において、
前記ビジネスプロセス実行装置は、
前記他のビジネスプロセス定義が利用するサービスの一覧を取得し、かつ、該取得した前記サービスの稼働状態を取得し、かつ、該他のビジネスプロセス定義の配備状態を前記ビジネスプロセス実行装置から取得し、
前記サービス一覧に含まれる全てのサービスが稼動状態であり、かつ、該他のビジネスプロセス定義が前記ビジネスプロセス実行装置上に配備されている場合に該他のビジネスプロセス定義を実行可能と判定する
ことを特徴とするビジネスプロセス実行方法。
【請求項２０】
請求項１６に記載のビジネスプロセス実行方法において、
前記ビジネスプロセス実行装置は、
前記他のビジネスプロセス定義が利用する１つ以上のサービスの稼動状態が停止である場合に、前記停止しているサービスのサービス実行待機時間を取得し、該取得したサービス実行待機時間のうち最も長いサービス実行待機時間を該他のビジネスプロセス定義の実行待機時間とする
ことを特徴とするビジネスプロセス実行方法。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上の計算機に配備された複数のサービスを順に実行するビジネスプロセスにおいて、サービスの実行失敗回数を低減する装置および方法に関する。
【背景技術】
【０００２】
近年、ネットワークを介して接続された複数の計算機において、計算機上に配備されたアプリケーションがネットワークを経由して処理要求、応答の送受信を行なう分散処理構成が広く使用されている。
この分散処理構成では、例えば呼出し先アプリケーションがメンテナンス中であり処理要求を受け付けない閉塞状態であったり、呼出し先アプリケーションが配備されているサーバが再起動中であるといった場合があり、呼出し先であるアプリケーションが一時的に停止している可能性を考慮する必要がある。
【０００３】
呼出し先の停止中のアプリケーションへの処理要求送信を回避するためには、処理要求を送る直前に呼出し先アプリケーションの稼動状態を確認し、停止中であればアプリケーションが復旧するまで待機するという方法が考えられる。
アプリケーションの起動やサーバの再起動といった作業は、開始から終了までにかかる時間が毎回、ほぼ同等と考えられるため、アプリケーションが停止している場合には停止理由毎に復旧までにかかる平均的な時間だけアプリケーションの実行を待機すれば、一定時間経過後には復旧し、アプリケーションの実行が成功することが期待できる。
【０００４】
ところで、これまでは、複数のアプリケーションを連携させる場合、呼出し元と呼出し先が互いを意識する密結合な連携方法が採用されることが多かった。この密結合のシステムでは、呼出し先アプリケーションが呼出し元アプリケーションへ稼動状態を通知するなどして、呼出し先のアプリケーションの稼動状態を呼出し元が検知することができる。このため、呼出し先のアプリケーションが障害等により停止している場合は呼出し元で呼出し先を変更するといった障害対策をとることができる。このようなシステムの例として、特許文献1がある。
【０００５】
ところで、密結合なシステムには、システム間の関連度合いが深いことから保守作業が多肢に及び、保守性の低下や開発コストの増大という欠点がある。
これに対して、近年、ＳＯＡ(Service Oriented Architecture)という情報システム設計手法が注目されている。ＳＯＡとは、サービスと呼ばれる業務処理を行なうアプリケーションを、ビジネスプロセスと呼ばれる業務フローを実装したアプリケーションから指定された順序で呼び出すことで新たな情報システムを構築するという考え方である。
【０００６】
ＳＯＡにおけるサービスでは、サービスを実行するためのインタフェースがインタフェース記述言語で記述されており、そのインタフェースに従っていれば、どのビジネスプロセスからでもサービスを実行することができる。インタフェース記述言語の仕様の例としては、ＷＳＤＬ(Web Service Description Language)がある。また、ビジネスプロセス記述言語の仕様の例としては、ＢＰＥＬ(Business Process Execution Language)がある。
【０００７】
ＳＯＡに基づいた情報システムでは、ビジネスプロセスとサービス間の独立性が高いため、既存のサービスを再利用することで低コストかつ迅速に情報システムを開発することができる。加えて、複数のサービスを組み合わせて新たな情報システムを構築するためのサービスの実装の変更や呼出し順序の変更が容易となり、情報システムの柔軟性を確保することができるという利点がある。
しかし、ＳＯＡに代表されるような呼出し元と呼出し先が互いを意識しない疎結合なシステムにおいては、呼出し先であるサービスは呼出し元であるビジネスプロセスを意識しないため、ビジネスプロセスへサービス自身の稼動状態を通知することができない。
【０００８】
この疎結合なシステムにおいて、サービスの稼動状態をビジネスプロセスが検知する手段としては、保管手段であるＵＤＤＩ(Universal Description, Discovery and Integration)を用いる方法が考えられる。ＵＤＤＩとは、サービスの処理内容やサービスを使用するためのインタフェースといった情報を登録しておくリポジトリである。ビジネスプロセスは、サービスを使用する際、ＵＤＤＩへサービスの情報を問合せ、また様々な情報を取得する。ＵＤＤＩがサービスへ稼動状態の問合せを行い、サービスの稼動状態情報を保持し、ビジネスプロセスからの問合せに対してサービスの稼動状態情報を提供することができる。
【特許文献１】特開２００７−２５７８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、ＵＤＤＩでは、複数のビジネスプロセスからの問合せやサービスの稼動状態の応答がＵＤＤＩに集中するため、処理が重くなり、ＵＤＤＩがシステム上のボトルネックとなる可能性がある。また、ＵＤＤＩが何らかの障害により停止した場合、ＵＤＤＩを利用しているビジネスプロセスも処理を実行することができなくなるため、障害の影響範囲が広くなりやすい。
また、ビジネスプロセスからサービスを実行する度にビジネスプロセスがＵＤＤＩへサービスの稼動状態を問い合わせるため、ネットワークトラフィックが増大し、レスポンスが悪くなる、容量オーバーでシステムダウンが発生する等の不都合を生じる。このため、ＵＤＤＩへのアクセス量が過大になると想定される大規模なシステムへ適用するのは現実的ではない。
【００１０】
停止中のサービスをビジネスプロセスから実行してしまった場合、サービスの実行に失敗したという例外がビジネスプロセスにて発生し、ビジネスプロセスの実行に失敗する等の異常処理が発生する。実際には、ビジネスプロセスは同時に複数のクライアントからの処理要求を受け取って並列に処理を実行しているため、1つのサービスが停止すると、1つのビジネスプロセスについて、処理中の処理要求の数だけ例外が発生する。また、あるサービスを複数のビジネスプロセスから利用している場合、共有しているサービスが停止すると複数のビジネスプロセスで例外が発生する。さらに、ビジネスプロセスからビジネスプロセスを実行するような多段構成の場合には、1つのサービス実行失敗が複数のビジネスプロセスに波及し、多数の例外が発生してしまう。
【００１１】
以下、従来のシステムの概要を、図１の一部を用いて説明する。なお、図１は、本発明の第１実施形態のビジネスプロセス処理システムにおけるデータの流れを示す図である。
従来のビジネスプロセス実行装置200におけるビジネスプロセス実行の基本的な流れは、次の通りである。
クライアント270はビジネスプロセス実行装置200へビジネスプロセス1処理要求100を送信する。ビジネスプロセス実行装置200のビジネスプロセス実行部230は、ビジネスプロセス1処理要求100毎にビジネスプロセス1インスタンス231、232を生成する。
【００１２】
このビジネスプロセス1インスタンス231、232は、ビジネスプロセスの進捗状態やビジネスプロセス内部で使用する変数の値といった処理要求毎の実行状態を保持し、実行状態とビジネスプロセス1定義251の内容に従って処理を行なう処理部であり、受信したビジネスプロセス1処理要求100毎にビジネスプロセス実行部230が生成する。そして、ビジネスプロセス1インスタンス231、232はビジネスプロセス1定義251に従ってサービスA280およびサービスB281を実行する。
【００１３】
従来の方法では、仮にサービスB281が何らかの障害により停止している場合、ビジネスプロセス1インスタンス231、232の双方がサービスB281の実行に失敗し、インスタンスが異常終了してしまう。ビジネスプロセスインスタンスが異常終了した場合、インスタンスの進捗状態やサービスの実行状態等を照らし合わせて回復処理を行なう必要がある。
このように、例外が発生した場合、ビジネスプロセスの復旧作業にはサービスの進捗状態とビジネスプロセスの進捗状態の照らし合わせなど、システム管理者による複雑な手作業が必要であり、運用コストの増大を招来している。
【００１４】
この復旧作業を図２０、図２１を用いて説明する。なお、図２０は、従来のビジネスプロセスが多段の場合の障害発生状況を示した図である。
図２０に示すシステムは、ビジネスプロセスへ処理要求を送信するクライアント1850、ビジネスプロセスを実行するビジネスプロセス実行装置200、およびビジネスプロセスからの処理要求を受けて処理を行なう複数のサービス 1860〜1863で構成されている。ビジネスプロセス実行装置200には、発注ビジネスプロセス1851、見積取得ビジネスプロセス1852、購入ビジネスプロセス1853の3つのビジネスプロセスが配備されている。
【００１５】
発注ビジネスプロセス1851は、クライアント1850からの発注依頼を受けて、見積取得ビジネスプロセス1852、購入ビジネスプロセス1853を実行することで発注処理を行なう。見積取得ビジネスプロセス1852は、サービスa 1860、サービスb1861を実行して見積取得処理を行なう。購入ビジネスプロセス1853は納期確認サービス1862、注文サービス1863を実行して購入処理を行なう。
【００１６】
ここで、注文サービス1863が何らかの障害によって停止した場合、注文サービス1863を実行しようとした購入ビジネスプロセス1853で例外が発生する。さらに、購入ビジネスプロセス1853を利用する発注ビジネスプロセス1851でも、購入ビジネスプロセス1853の実行に失敗し、例外が発生する。このように、ビジネスプロセスが多段になっている場合、１つのサービスの実行失敗によって複数のビジネスプロセスで例外が発生し、例外の連鎖が生じる。
【００１７】
図２１は、図２０に示す従来の障害の復旧作業の様子を示した図である。
図２１に示すように、例外が発生したビジネスプロセスは途中まで処理を実行した状態で中断しているため、中断した時点から処理を再開するか、若しくは、誤りの原因となり得る処理済の処理の結果を全て消去(補償処理を実行)して最初からビジネスプロセスをやり直す必要がある。ここでは、例としてシステム管理者が補償処理を実行する手順を述べる。
【００１８】
システム管理者は、運用ツール等によりシステム上で複数の例外が発生していることを検知し、例外が発生したビジネスプロセスを検索する。次に実行履歴を解析し、例外が発生している各ビジネスプロセスの進捗状況を確認する。その結果、実行済みのサービスやビジネスプロセスがあれば、実行済みの処理に対する補償処理を実行する。補償処理の手順は、サービスやビジネスプロセス毎に異なっており、システム管理者はそれぞれ提供されている運用マニュアル等を参照しながら処理を行なう。
【００１９】
補償処理としては、図２１に示すように、例えばサービスa1860が使用しているデータベースから処理データを消去する作業や、発注ビジネスプロセスへ処理要求を送ったクライアント1850へ処理が失敗した旨を通知するメールを送信する作業などが考えられる。また、例外発生原因である注文サービス1863については、注文サービス1863における処理の進捗状況を確認して補償処理を行なう必要がある。
このように、ビジネスプロセスが多段になっている場合は、回復作業に大きな労力が費やされる。このため、サービスの実行に失敗しないようにすることでシステム全体での例外発生数を抑制し、システム管理者の作業量を低減することが可能になると考えられる。
【００２０】
本発明は上記実状に鑑み、疎結合なシステムにおいてビジネスプロセスの実行失敗を回避することが可能なビジネスプロセス実行装置およびビジネスプロセス実行方法の提供を目的とする。
【課題を解決するための手段】
【００２１】
上記目的を達成すべく、第１の本発明に関わるビジネスプロセス実行装置は、クライアントの処理要求に応じてビジネスプロセス定義に記述された順にネットワーク上の複数のサービスを実行するビジネスプロセス実行装置であって、ビジネスプロセス実行履歴記憶部に記憶されるビジネスプロセスによるサービス実行結果から停止中のサービス毎にサービス実行待機時間を算出するサービス待機時間計算部と、ビジネスプロセス実行履歴記憶部に記憶される最新のサービス実行結果からサービス毎の稼動状態を判定するとともに停止中のサービス毎のサービス実行待機時間を取得するサービス稼動状態解析部と、サービスを実行する前に該サービスの稼動状態およびサービス実行待機時間を取得し、該サービスが稼動中である場合には該サービスを実行する一方、該サービスが停止中である場合にはサービス実行待機時間の間、該サービスの実行を延期するサービス実行制御部とを備えている。
【００２２】
第２の本発明に関わるビジネスプロセス実行方法は、クライアントの処理要求に応じてビジネスプロセス定義に記述された順にネットワーク上の複数のサービスを実行するビジネスプロセス実行方法であって、ビジネスプロセス実行装置が、ビジネスプロセス実行履歴記憶部に記憶されるビジネスプロセスによるサービス実行結果から停止中のサービス毎にサービス実行待機時間を算出し、ビジネスプロセス実行履歴記憶部に記憶される最新のサービス実行結果からサービス毎の稼動状態を判定するとともに停止中のサービス毎のサービス実行待機時間を取得し、サービスを実行する前に該サービスの稼動状態およびサービス実行待機時間を取得して該サービスが稼動中である場合には該サービスを実行する一方、該サービスが停止中である場合にはサービス実行待機時間の間、該サービスの実行を延期している。
【発明の効果】
【００２３】
本発明によれば、疎結合なシステムにおいてビジネスプロセスの実行失敗を回避することが可能なビジネスプロセス実行装置およびビジネスプロセス実行方法を実現可能である。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施形態について添付図面を参照して説明する。
まず、第１実施形態について図１から図９を用いて説明する。
＜＜第１実施形態＞＞
＜ビジネスプロセス処理システムＳの構成概要＞
図１は、第１実施形態のビジネスプロセス処理システムＳにおけるデータの流れを示す図である。
第１実施形態のビジネスプロセス処理システムＳは、ビジネスプロセス実行装置200へ処理要求を送信するクライアント270、該クライアント270からの処理要求を受けて処理を行なうビジネスプロセス実行装置200、ビジネスプロセス実行装置200からの処理要求を受けて処理を行なうソフトウェアの集合のサービスA280、サービスB281で構成されている。
【００２５】
サービスとは、サービス実行装置上に配備され、ネットワークを介して処理要求を受け取り、実行結果を応答する処理部である。
以下、「サービスを実行する」との表現は、サービス処理要求送信元がサービスへ実行要求を送信し、サービスが要求された処理を実行し、その処理結果をサービス処理要求送信元が受信するまでの一連の処理を意味する。上記サービスA280およびサービスB281は、ビジネスプロセス実行装置200のビジネスプロセス実行部230によって実行される。
【００２６】
ビジネスプロセス実行部230とは、ビジネスプロセス定義に記述された処理を実行する処理部である。
ビジネスプロセス定義とは、複数のサービスの実行、サービスに送信する処理データの生成といったビジネスプロセス実行部230が行なう処理をビジネスプロセス記述言語を用いてフローとして記述したものである。なお、ビジネスプロセス記述言語の一般的な例としては、BPEL(Business Process Execution Language)がある。
図１に示すビジネスプロセス1定義251には、サービスA280およびサービスB281を実行するための処理が記述されている。ビジネスプロセス1定義251の定義内容、およびビジネスプロセス実行部230が実行する処理については後記する。
【００２７】
＜ビジネスプロセス処理システムＳの概要＞
第１実施形態のビジネスプロセス処理システムＳは、疎結合なシステムにおいて、ビジネスプロセス側が有する情報によってサービスの稼動状態を判定し、サービスの稼動状態に応じてサービスの実行タイミングを制御することで、サービスの実行失敗を回避することを目的としている。
図１に示すように、ビジネスプロセス処理システムＳは、クライアント270からビジネスプロセス実行装置200にサービス処理要求があった場合、サービス実行制御部233およびサービス状態管理部240によりサービスを実行する直前にこのサービスの稼動状態をチェックし、サービスの稼動状態に応じてサービスを実行するか、または一定時間実行を延期するかを決定し、延期する場合は実行対象のサービス、および障害種別に応じてビジネスプロセス実行履歴254に格納される情報から算出したサービス実行待機時間を設定する。
【００２８】
そして、停止中のサービスの実行を回避して復旧している可能性が高いサービス実行待機時間経過後に当該サービスを実行することにより、ビジネスプロセス実行装置200全体としてビジネスプロセスの実行失敗回数を低減している。
ここで、サービス状態管理部240がサービスの稼動状態を検知する手段として、ビジネスプロセス実行装置200が保持するビジネスプロセス実行履歴254を用いる。そのため、従来のように、ビジネスプロセス実行装置200と各サービスが互いの所在を認識し、サービス側がビジネスプロセス実行装置200へ自身の稼動状態を通知するといった密な結合は不要である。
【００２９】
従って、この構成により、サービスA280、B281等のサービス側がビジネスプロセス実行装置200の所在を意識しない疎結合なシステムにおいて、ビジネスプロセス実行装置200側からサービスの稼動状態を検知することができる。
以下、図１を用いて具体的に説明する。
【００３０】
＜具体例＞
図１に示すように、サービスB281が何らかの障害により停止した場合、サービスB281の停止直後にサービスB281を実行するビジネスプロセス1インスタンス231はサービスB281の実行に失敗する。そして、実行に失敗したという情報が、ビジネスプロセス実行装置200のビジネスプロセス実行履歴254に記録されると、サービス状態管理部240がビジネスプロセス実行履歴254を解析し、記録されているサービスB281の稼動状態を更新する。ビジネスプロセス1インスタンス231の後にサービスB281を実行するビジネスプロセス1インスタンス232は、サービス状態管理部240からサービスB281の稼動状態を取得し、サービスB281が停止中のためサービス実行を一定時間延期する。
【００３１】
以上の処理により、従来ではビジネスプロセス1インスタンス231、232の両方でサービス実行に失敗していたのに対し、本ビジネスプロセス処理システムＳの場合は先行するビジネスプロセス1インスタンス231がサービス実行に失敗したという情報を利用して、後続のビジネスプロセス1インスタンス232が停止中のサービスの実行を回避する。
さらに、サービス状態管理部240はビジネスプロセス実行履歴254に記録されるサービスB281の実行失敗データを解析してサービスB281のサービス実行待機時間を取得し、ビジネスプロセス1インスタンス231、232のサービス実行待機時間として設定する。これにより、サービス毎、障害種別毎に過去の実績に基づいて動的に適切な待機時間を設定することができる。
【００３２】
＜ビジネスプロセス処理システムＳのハードウェア構成＞
図２は、第１実施形態のビジネスプロセス処理システムＳのハードウェア構成の一例を示す図である。
ビジネスプロセス処理システムＳは、サービスA280、B281等のサービスの処理要求を発するクライアント実行装置201と、要求される処理を実行するビジネスプロセス実行装置200と、サービスA280を実際に実行するサービス実行装置202と、サービスB281を実際に実行するサービス実行装置203とを備え構成されている。
【００３３】
ここで、クライアント実行装置201、ビジネスプロセス実行装置200およびサービス実行装置202、203上に配置されている全ての処理部は専用のハードウェアとして実現されていても良いし、ＣＰＵ(Central Processing Unit)によって実行されるプログラムとして実現されていても良いが、以下ではプログラムとして実現した場合を示す。
クライアント実行装置201、ビジネスプロセス実行装置200、およびサービス実行装置202、203は、互いにネットワーク204を介して接続されている。このネットワーク204は、ＬＡＮ(Local Area Network)やイントラネットなどのローカルネットワークであっても、インターネットなどのグローバルネットワークであってもよく、限定されない。また、クライアント実行装置201、サービス実行装置202、203は、任意の複数台存在しても良いことは勿論である。
【００３４】
＜クライアント実行装置201＞
図２に示すように、クライアント実行装置201は、ＣＰＵ210、主記憶装置211、ネットワークインタフェース213、およびこれらを接続するシステムバス214で構成されている。
主記憶装置211には、必要に応じてＣＰＵ210によって、クライアント270が、そのプログラムが実行され配備されている。ネットワークインタフェース213は、ＣＰＵ210の指示に従って、ネットワーク204を介してネットワーク204上の他の機器と通信を行なう。
但し、図２に示す構成は一例であり、クライアント実行装置201内に複数のクライアント270が配備されていても良い。
【００３５】
＜サービス実行装置202、203＞
サービス実行装置202、203は、ＣＰＵ210、主記憶装置211、ネットワークインタフェース213、およびこれらを接続するシステムバス214で構成されている。
サービス実行装置202の主記憶装置211にはサービスA280が、サービス実行装置203の主記憶装置211には、サービスB281が、必要に応じてそれぞれＣＰＵ210によって、対応するプログラムが実行され、配備されている。ネットワークインタフェース213は、ＣＰＵ210の指示に従って、ネットワーク204を介してネットワーク204上の他の機器と通信を行なう。
但し、図２の構成は一例であり、サービス実行装置202、203内にはサービスA280、サービスB281以外のサービスが配備されていても良い。
【００３６】
＜ビジネスプロセス実行装置200＞
図２に示すビジネスプロセス実行装置200は、ＣＰＵ210、主記憶装置211、二次記憶装置212、ネットワークインタフェース213、およびこれらを接続するシステムバス214で構成されている。
主記憶装置211には、ＣＰＵ210によってビジネスプロセス実行プログラム220が実行され、配備されている。
このように、図２に示す主記憶装置211上に配置されたビジネスプロセス実行プログラム220の各処理部は、二次記憶装置212内にそれぞれ対応する目的プログラムが格納され、必要に応じてＣＰＵ210によって、主記憶装置211に読み込まれ実行され、配備される。
【００３７】
二次記憶装置212には、ビジネスプロセス1定義251、サービスAインタフェース定義252(以下、サービスAIF定義252と称す)、サービスBインタフェース定義253(以下、サービスBIF定義253と称す)、ビジネスプロセス実行履歴254、稼動状態管理テーブル261、待機時間管理テーブル262等が配置されている。
また、二次記憶装置212は、ビジネスプロセス実行装置200に内蔵されたメモリやハードディスクなどの記憶装置の他、外付けのメモリやハードディスク装置、ネットワークを介して接続されたデータベース、データベースサーバ等によって実現されていても良い。
ネットワークインタフェース213は、ＣＰＵ210の指示に従って、ネットワーク204を介してネットワーク204上の他の機器と通信を行なう。
【００３８】
＜ビジネスプロセス実行プログラム220＞
図２に示すように、ビジネスプロセス実行プログラム220は、ビジネスプロセス実行部230とサービス状態管理部240とを有し構成されている。
ビジネスプロセス実行部230は、図１に示すように、クライアント270からのビジネスプロセス1処理要求100に応じて、ビジネスプロセス1定義251に記述された処理を実行し、処理状態や処理結果をビジネスプロセス実行履歴254として記録する処理部である。
【００３９】
図２に示すように、ビジネスプロセス実行部230は、ビジネスプロセス1インスタンス231、232、およびサービス実行制御部233で構成されている。但し、図２に示す構成は一例であり、ビジネスプロセス実行部230にはビジネスプロセス1定義251以外のビジネスプロセス定義が複数配備されていても良いし、各定義を実行するビジネスプロセスインスタンスが任意の複数存在していても良い。
【００４０】
＜ビジネスプロセス1定義251の処理内容＞
図２に示すビジネスプロセス1定義251内に本第１実施形態で使用するビジネスプロセス1定義251の処理内容の一例を示す。ビジネスプロセス1定義251は、ビジネスプロセス実行部230が実行する処理の手順をビジネスプロセス定義言語を用いてフローとして記述したものである。
ビジネスプロセス定義は、複数のステップで構成されており、各ステップはビジネスプロセス定義内で一意となる識別子であるステップID、ステップで行なう処理の種別を表すステップ種別、および処理内容の詳細を表すステップ詳細情報を含んでいる。
【００４１】
ビジネスプロセス1定義251は、図１に示すビジネスプロセス1処理要求100を受け取りデータを抽出するステップID1であってステップ種別が開始ステップであるステップ300、サービスA280を実行するステップID2であってステップ種別がサービス実行ステップであるステップ301、サービスB281を実行するステップID3であってステップ種別がサービス実行ステップであるステップ302、および後処理を行なうステップID4であってステップ種別が終了ステップであるステップ303を有し構成されている。但し、上記の内容はビジネスプロセス定義の一例であり、ビジネスプロセス定義言語で記述可能な範囲であればどのような処理フローが定義されていても良いことは勿論である。
【００４２】
図１に示すビジネスプロセス1処理要求100は、クライアント270がビジネスプロセス実行装置200のビジネスプロセス1定義251の実行をビジネスプロセス実行装置200のビジネスプロセス実行部230へ要求する際に送信するデータである。
ビジネスプロセス1処理要求100(図１参照)は、実行対象のビジネスプロセス定義名やビジネスプロセス1定義251を実行するために必要な入力データの他、サービス実行制御部233において使用する更新時刻閾値101および最大待機時間102を含む。図１に示すように、ビジネスプロセス1インスタンス231、232は、サービス実行に必要な情報の他、更新時刻閾値101および最大待機時間102をサービス実行制御部233へ渡してサービスの実行を依頼する。更新時刻閾値101および最大待機時間102のサービス実行制御部233における利用方法については後記する。
【００４３】
＜ビジネスプロセス実行履歴254＞
図３は、ビジネスプロセス実行履歴254の構成の一例を示す図である。
図３に示すビジネスプロセス実行履歴254は、データベース、ファイル等の記憶部であり、ビジネスプロセス定義の識別子であるビジネスプロセス名400、処理を行なったビジネスプロセスインスタンスの識別子であるインスタンスID401、処理対象ステップの識別子であるステップID402、ステップID402のステップのステップ種別であるステップ種別403、ビジネスプロセスインスタンスによるステップID402のステップの処理開始時刻であるステップ開始時刻404、および処理終了時刻であるステップ終了時刻405、ステップの処理状態であるステップ状態406、処理結果である実行結果407、ステップ処理時に障害が発生した場合の発生した障害種別である障害種別408で構成されている。
但し、図３に示す構成は一例であり、図３に示した情報以外の情報が含まれていても良い。
【００４４】
＜サービス実行制御部233＞
図１、図２に示すサービス実行制御部233は、サービスの稼動状態に応じて適切なタイミングでサービスを実行する処理部であり、ビジネスプロセス1インスタンス231、232によるサービスの実行を代行する。本制御部233における処理の詳細は後記する。
【００４５】
＜サービスAIF定義252、サービスBIF定義253＞
図１、図２に示すサービスAIF定義252、サービスBIF定義253には、それぞれサービスA280、サービスB281を実行するために必要な情報が記述されている。サービスを実行するために必要な情報とは、例えばサービス処理要求の送信先URL、サービス処理要求に含まれるべきデータのデータ構造、サービスからの応答に含まれる結果データのデータ構造等の情報である。
図１に示すように、サービス実行制御部233は、サービスA280を実行する場合、サービスAIF定義252を参照して処理データ111を含むサービスA処理要求110を生成してサービスA280へ送信する。同様に、サービスB281を実行する場合はサービスBIF定義253を参照して処理データ121を含むサービスB処理要求120を生成し、サービスB281へ送信する。
【００４６】
サービスからの応答に含まれるデータは、サービスの実行に成功した場合と失敗した場合とで異なる。
サービスAの実行に成功した場合、サービスA処理応答112には処理が成功したことを示す処理結果113と、処理の結果データである結果データ114が含まれる。一方、サービスBの実行に失敗した場合、サービスB処理応答122には処理が失敗したことを示す処理結果123と、サービスBの停止やサービスB実行装置の停止といった障害の種別を表す障害種別124が含まれる。
前記ビジネスプロセス1定義251、サービスAIF定義252、およびサービスBIF定義253は、ビジネスプロセス開発者がビジネスプロセス開発環境用のツールを使用して作成し、ビジネスプロセス実行装置200に配備する。この開発ツールや配備方法については従来技術で実現可能であるため、詳細な説明は省略する。
【００４７】
＜サービス状態管理部240＞
図１、図２に示すサービス状態管理部240は、サービスの稼動状態など、サービスの実行制御に必要な情報を保持し、サービス実行制御部233からの問い合わせに応じて情報を提供する処理部であり、サービス状態管理の処理を行なうサービス状態判定部241を有し構成されている。
サービス状態判定部241は、図１に示すように、サービスの最新の稼動状態を記録するサービス稼動状態解析部242およびサービスを実行するまでの待機時間を計算し記録するサービス待機時間計算部243で構成されている。
サービス稼動状態解析部242は、ビジネスプロセス実行履歴254を解析し、サービスの最新の稼動状態を稼動状態管理テーブル261へ記録する処理部である。
【００４８】
図４は、稼動状態管理テーブル261の構成を示す図である。
図４に示す稼動状態管理テーブル261は、サービス毎にサービスの稼動状態、停止している場合はその原因と、サービス実行までの待機時間を保持するテーブルである。
稼動状態管理テーブル261は、サービスの識別子であるサービス名500、サービスの稼動状態を示す稼動状態501、サービスが停止している場合の原因を示す障害種別502、該サービスが該障害を起こしている場合にサービス実行制御部233(図１参照)がサービス実行を待機する時間間隔である待機時間503、および各エントリの更新時刻である更新時刻504で構成される。
【００４９】
図１に示すサービス待機時間計算部243は、ビジネスプロセス実行履歴254に記録されるログの実行履歴情報を解析し、サービスを実行するまでの待機時間を算出し、待機時間管理テーブル262へ記録する処理部である。
【００５０】
図５は、待機時間管理テーブル262の構成を示す図である。
図５に示す待機時間管理テーブル262は、サービス毎、障害種別毎のサービスを実行するまでの待機時間を保持するテーブルである。
待機時間管理テーブル262は、サービスの識別子であるサービス名600、該サービスで発生したことがある障害の原因を示す障害種別601、および該サービスで障害種別601の障害が発生した場合にサービス実行制御部233がサービス実行を待機する時間間隔である待機時間602で構成されている。
【００５１】
＜＜ビジネスプロセス実行部230によるビジネスプロセス実行処理＞＞
次に、図１、図２に示すビジネスプロセス実行部230によるビジネスプロセス実行処理について図６に従って説明する。
なお、図６は、ビジネスプロセス実行部230によるビジネスプロセス実行処理の流れを示すフローチャートである。
ビジネスプロセス実行部230は、本来、クライアント270からの複数のビジネスプロセス実行要求を同時に受け付け、複数のビジネスプロセスインスタンスを並列に実行することができるが、図６では1つの処理要求を受け付けた場合の処理の流れを示す。図６を参照して、
【００５２】
(図６のステップ700)図１に示すように、ビジネスプロセス実行部230が、クライアント270から送信されるビジネスプロセス1処理要求100を受信する。
(ステップ701)ビジネスプロセス実行部230は、図１に示すように、ビジネスプロセス1処理要求100に応じて、インスタンスID：10001であるビジネスプロセス1インスタンス231を生成する。
(ステップ702) ビジネスプロセス1インスタンス231は、図１に示すように、ビジネスプロセス1定義251を読み込む。
(ステップ703)実行中ステップIDを示す変数iに1を代入する。
【００５３】
(ステップ704)ビジネスプロセス1インスタンス231は、ステップID iのステップ種別をビジネスプロセス1定義251(図１参照)から取得し、ステップ種別が「終了ステップ」か否か判断し、ステップ種別が「終了ステップ」であればステップ715へ移行し、それ以外であればステップ705へ移行する。
(ステップ705)ビジネスプロセス1インスタンス231は、図１に示すように、ビジネスプロセス実行履歴254(図３参照)へ以下のデータを記録する。ビジネスプロセス名400：ビジネスプロセス1、インスタンスID401：10001、ステップID402：i、ステップ種別403：ステップIDiのステップ種別、ステップ開始時刻404：現在時刻、ステップ終了時刻405：文字列"−"、ステップ状態406：文字列"実行中"、実行結果407：文字列"−"、障害種別408：文字列"−"。
【００５４】
(ステップ706) ステップ704で取得したステップID iのステップ種別が「サービス実行ステップ」か否か判断し、「サービス実行ステップ」であればステップ707へ移行し、それ以外であればステップ712へ移行する。
(ステップ707) ビジネスプロセス1インスタンス231は、サービス実行制御部233(図１参照)へサービス実行処理を依頼する。本処理の詳細は後記する。
(ステップ708)図１に示すように、サービスからの応答をサービス実行制御部233から受け取り、例外が発生していないかチェックする。すなわち、サービスA処理応答112に含まれる処理結果113を解析し、サービスの実行が成功した場合はステップ709へ移行し、失敗した場合はステップ714へ移行する
【００５５】
(ステップ709)サービスの実行結果を表す変数rに文字列"成功"、およびサービス処理応答から取得した結果データ114(図１参照)を格納する。また、サービス障害種別を表す変数eに文字列"−"を格納する。
(ステップ710) 図１に示すビジネスプロセス1インスタンス231はステップ705でビジネスプロセス実行履歴254(図３参照)に記録したデータを以下のデータで更新する。ステップ終了時刻405：現在時刻、ステップ状態406：文字列"完了"、実行結果407：変数rの内容、障害種別408：変数eの内容。
(ステップ711) 図１に示すように、ビジネスプロセス1インスタンス231は、ビジネスプロセス1定義251から、ステップID iの次のステップのステップIDを取得してiに格納し、ステップ704へ移行する。
【００５６】
(ステップ712)ステップID iのステップを実行し、サービスの実行結果を表す変数r、およびサービスの障害種別を表す変数eに文字列"−"を格納し、ステップ710へ移行する。
(ステップ713) サービスの実行結果を表す変数rに文字列"失敗"を格納する。また、サービスの障害種別を表す変数eにサービスB処理応答(図１参照)から取得した障害種別124を格納する。
【００５７】
(ステップ714) 図１に示すビジネスプロセス1インスタンス231はステップ705でビジネスプロセス実行履歴254(図３参照)に記録したデータを以下のデータで更新し、終了する。ステップ終了時刻405：現在時刻、ステップ状態406：文字列"エラー終了"、実行結果407：変数rの内容、障害種別408：変数eの内容。
【００５８】
(ステップ715) 図１に示すビジネスプロセス1インスタンス231はステップ705でビジネスプロセス実行履歴254(図３参照)に記録したデータを以下のデータで更新し、処理を終了する。ステップ終了時刻405：現在時刻、ステップ状態406：文字列"完了"、実行結果407：文字列"−"、障害種別408：文字列"−"。
【００５９】
＜＜サービス実行制御部233によるサービス実行制御処理＞＞
次に、図１、図２に示すサービス実行制御部233によるサービス実行制御処理について、図７に従って説明する。
図７は、図６のステップ707における、サービス実行制御部233によるサービス実行制御処理の詳細を示すフローチャートである。
サービス実行制御部233では、ビジネスプロセス1インスタンス231、232が実行を依頼したサービスA280、サービスB281等のサービスの稼動状態をサービス状態管理部240(図１参照)から取得し、依頼されたサービスが稼動していればサービスを実行する一方、稼動していなく停止していれば図４に示す稼動状態管理テーブル261の待機時間503だけサービスの実行を延期する。
【００６０】
サービス実行制御部233の動作を制御するパラメータとして図１に示す更新時刻閾値101および最大待機時間102を指定することができる。
更新時刻閾値101は、図４に示す稼動状態管理テーブル261が保持する情報の鮮度に対する制約であり、稼動状態管理テーブル261に登録された情報が更新時刻閾値101よりも古い情報であった場合は無効と判断し、稼動状態管理テーブル261が示すサービスの稼動状態501が"停止"であってもサービスを実行する。
【００６１】
最大待機時間102は、サービス実行制御部233での待機時間の上限値であり、稼動状態管理テーブル261の待機時間503が最大待機時間102を超える場合、処理に用いる実際の待機時間として最大待機時間102を採用する。これにより、レスポンスタイムに対する要求が高いクライアント270(図１、図２参照)は、最大待機時間102を短く設定することでサービス実行制御部233にてクライアント270の想定よりも長時間待機してしまうことを防ぐことができる。
【００６２】
本実施形態では、図１に示すように、更新時刻閾値101および最大待機時間102はクライアント270が設定し、ビジネスプロセス1処理要求100に含めてビジネスプロセス実行部230へ送信する。更新時刻閾値101および最大待機時間102はサービス毎に異なる値を設定しても良い。
但し、図１の構成は一例であり、例えばビジネスプロセス1定義251に開発者が設定する、またはビジネスプロセス実行部230へ運用者が設定するといった方法でも実現可能であり、その設定方法は限定されない。
【００６３】
図１に示すビジネスプロセス1インスタンス231、232は、サービス実行制御部233へ処理を依頼する際、サービスA280、B281へそれぞれ送信する処理データ111、121、実行対象ビジネスプロセス定義名、実行対象サービス名、インスタンスID、ステップID、ステップ開始時刻、更新時刻閾値101、最大待機時間102といったサービスの実行に必要な情報をサービス実行制御部233へ渡す。そして、サービス実行制御部233は、これらの情報を用いて以下の処理を行なう。図７を参照し、
【００６４】
(ステップ800)図４に示す稼動状態管理テーブル261から、実行対象サービスの稼動状態501、更新時刻504を取得する。
(ステップ801)ステップ800で取得した稼動状態501が停止中か否か判断し、停止中であればステップ802へ移行し、稼動中または該当するデータがなければステップ807へ移行する。
(ステップ802)現在時刻からステップ800で取得した更新時刻504を減算した値が、更新時刻閾値101より小さいか否か判断され、小さければステップ803へ移行する一方、以上であればステップ807へ移行する。
(ステップ803)実行対象サービスの待機時間を図４示す稼動状態管理テーブル261の待機時間503から取得し、待機時間を表す変数tへ格納する。
【００６５】
(ステップ804)ステップ803で取得した待機時間tが、最大待機時間102(図１参照)より小さければステップ806へ移行する一方、以上であればステップ805へ移行する。
(ステップ805)待機時間tに最大待機時間102を格納する。
(ステップ806)待機時間tだけ、処理を待機する。待機時間tが経過したらステップ807へ移行する。
(ステップ807)図１に示すように、実行対象サービスのサービスAIF定義252等のサービスIF定義、およびビジネスプロセス1インスタンス231等のビジネスプロセスインスタンスから取得した情報を元にサービスA処理要求110等のサービス処理要求を生成し、サービスA280等のサービスへ送信し、応答を受信する。
【００６６】
＜＜サービス待機時間計算部243による待機時間管理テーブル262の更新処理＞＞
次に、図１、図２に示すサービス待機時間計算部243による待機時間管理テーブル262(図５参照)の更新処理について、図８に従って説明する。
なお、図８は、図１に示すサービス状態判定部241のサービス待機時間計算部243がビジネスプロセス実行履歴254を解析し、待機時間管理テーブル262を更新する処理の流れを示すフローチャートである。
本実施形態では、図８に示す処理は、図６のステップ705、ステップ710、ステップ711、ステップ714で実行されるビジネスプロセス実行履歴254の更新を検知して実行されるが、このタイミングは一例であり、例えばステップ710、714の更新のみを検知して図８の処理を行なっても良いし、図６の処理とは無関係に一定時間毎に図８の処理を行なっても良い。
【００６７】
また、本実施形態では図８の処理の度に全てのビジネスプロセス実行履歴254(図１参照)を読み込んで処理を行なっているが、図８に示す処理を２度以上行なう場合は前回読み込んだビジネスプロセス実行履歴254からの差分のみを読み込んで処理を行なっても良い。図８を参照し、
【００６８】
(ステップ900)図１に示すサービス状態判定部241が、ビジネスプロセス実行履歴254の更新を検知する。
(ステップ901)サービス状態判定部241が図３に示すビジネスプロセス実行履歴254に格納される情報を取得する。
【００６９】
(ステップ902)図１に示すサービス待機時間計算部243がビジネスプロセス実行履歴254を解析してサービス毎、障害種別毎にサービス実行待機時間を取得する。
サービス毎、障害種別毎のサービス実行待機時間は、ビジネスプロセス実行履歴254から以下のように計算する。あるサービスについて、サービスの実行結果が"失敗"のエントリのステップ開始時刻Tstartを取得する。次に、同一サービスの実行結果が"成功"で、ステップ終了時刻TendがTstartよりも新しく、かつ最も時刻が近いエントリを検索する。TendからTstartを引いた値が、該サービスの該障害種別によるサービス実行不可であった時間の1データにあたる。このようにして、サービス毎、障害種別毎にサービス実行不可時間を取得し、その平均値をサービス毎、障害種別毎のサービス実行待機時間とする。
【００７０】
図３に示す例では、エントリ421でサービスA280のサービス実行が失敗していることが解る。このときの障害種別408は"サービス停止"、ステップ開始時刻404は16:00:02である。エントリ421から最も近いサービスA280のサービス実行結果が成功のエントリはエントリ425であり、このときのステップ終了時刻405は16:10:35である。以上から、サービスA280の障害種別"サービス停止"におけるサービス実行不可時間の1データは16:10:35−16:00:02＝10分33秒となる。
【００７１】
(ステップ903)図１に示すサービス待機時間計算部243が、ステップ902で算出したサービス毎、障害種別毎のサービス実行待機時間を図５に示す待機時間管理テーブル262の待機時間602へ記録する。
【００７２】
＜＜サービス稼動状態解析部242による稼動状態管理テーブル261の更新処理＞＞
次に、図１、図２に示すサービス稼動状態解析部242による稼動状態管理テーブル261の更新処理について、図９に従って説明する。
なお、図９は、サービス状態判定部241(図１、図２参照)のサービス稼動状態解析部242がビジネスプロセス実行履歴254を解析し、稼動状態管理テーブル261を更新する処理の流れを示すフローチャートである。
【００７３】
本実施形態では、図９に示す処理は、図６のステップ705、ステップ710、ステップ711、ステップ714で実行されるビジネスプロセス実行履歴254の更新を検知して実行されるが、このタイミングは一例であり、例えばステップ711、714の更新のみを検知して図９の処理を行なっても良いし、図６の処理とは無関係に一定時間毎に図９の処理を行なっても良い。また、本実施形態では図９の処理の度に全てのビジネスプロセス実行履歴254を読み込んで処理を行なっているが、図９の処理を２度以上行なう場合は前回読み込んだビジネスプロセス実行履歴254からの差分のみを読み込んで処理を行なっても良い。図９を参照して、
【００７４】
(ステップ1000)図１に示すサービス状態判定部241が、ビジネスプロセス実行履歴254の更新を検知する。
(ステップ1001)サービス状態判定部241がビジネスプロセス実行履歴254に格納される情報を取得する。
(ステップ1002)図１に示すサービス稼動状態解析部242が、ビジネスプロセス実行履歴254(図３参照)を解析してサービス毎に最新の実行結果407および該エントリ420〜426、…のステップ終了時刻405を取得する。
【００７５】
(ステップ1003)サービスの実行結果407が成功か否かを判断し、実行結果407が"失敗"であればステップ1004に移行し、"成功"であればステップ1007に移行する。
(ステップ1004)稼動状態を表す変数sに文字列"停止"を格納する。また、障害種別を表す変数eへステップ1002で取得したエントリの障害種別408を格納する。
(ステップ1005)サービス稼動状態解析部242が、図５に示す待機時間管理テーブル262から該サービスの該障害種別における待機時間602を取得し、待機時間を表す変数tに格納する。もし、待機時間管理テーブル262に該当するエントリがなければ、システム運用者が設定したデフォルト値を待機時間を表す変数tに格納する。
【００７６】
(ステップ1006)図１に示すサービス稼動状態解析部242が、稼動状態管理テーブル261(図４参照)へサービス名500としてステップ1002で取得した各サービスのサービス名、稼動状態501として変数s、障害種別502として変数e、待機時間503として変数t、更新時刻504としてステップ1002で取得したステップ終了時刻405をそれぞれ格納し、終了する。
【００７７】
(ステップ1007) 図１に示すサービス稼動状態解析部242が、稼動状態を表す変数sに文字列"稼動"を、障害種別を表す変数eへ文字列"−"を、待機時間を表す変数tに文字列"−"をそれぞれ格納し、ステップ1006へ移行する。
このように、第１実施形態によるサービス実行制御部233およびサービス状態管理部240によれば、疎結合なシステムにおいて処理要求送信元であるビジネスプロセス実行装置200(図１、図２参照)においてサービスA280等の各サービスの稼動状態を検知することができる。
【００７８】
また、サービスの稼動状態に応じてサービスを直ぐに実行するか、または一定時間待機した後に実行するかを判断する。待機する場合は、図３に示すビジネスプロセス実行履歴254から算出したサービス毎、障害種別毎のサービス実行待機時間を待機時間602(図５参照)として設定する。
これにより、ビジネスプロセス実行装置200全体としてビジネスプロセスの実行失敗回数を低減することができる。
【００７９】
以下、例外失敗回数低減効果について述べる。
図１に示すように、あるビジネスプロセス1インスタンスが、サービスB281を実行し、サービスB281が停止していたために実行に失敗したとする。サービス状態管理部240はビジネスプロセス実行履歴254からサービスB281が停止していることを検知し、他のインスタンスによるサービスB281の実行を延期する。
【００８０】
図５に示す待機時間管理テーブル262のサービスBに関するエントリの待機時間602から、サービスB281が実行可能となるまで平均的に30秒かかっていることがわかる。サービス実行制御部233は、インスタンスによるサービスB281の実行を30秒間延期することで、過去の実績から停止していると推測される期間、サービスB281の実行を回避する。これによりサービスB281の実行失敗回数を低減することができる。30秒後にサービスB281を実行し、失敗した場合は、その情報を元に延期時間が延長される。
【００８１】
本第１実施形態は、1つのビジネスプロセスに対するクライアントからのビジネスプロセス実行要求が比較的短い間隔で多数発生しているようなシステムや、1つのサービスを複数のビジネスプロセスで利用しているようなシステムにおいて特に効果的である。これは、サービス実行要求が頻繁に発生するのでサービスの稼動状態が更新され易く、加えてサンプリング間隔が短いので延期時間の精度が高まるためである。
【００８２】
＜＜第２実施形態＞＞
次に、第２実施形態のビジネスプロセス処理システム２Ｓについて、図１０から図１７を用いて説明する。
＜第２実施形態のビジネスプロセス処理システム２Ｓの特徴＞
第１実施形態で用いたビジネスプロセス定義(図１参照)では、ビジネスプロセス定義から各サービスを直接実行していたため、単純に各サービスの稼動状態を確認している。
【００８３】
図１０は、第２実施形態のビジネスプロセス処理システムにおけるデータの流れを示す図である。
ところで、例えば、図１０に示すように、ビジネスプロセス2インスタンス1201がサービス実行制御部233へビジネスプロセス1定義251の実行を依頼した場合、ビジネスプロセス1自身の配備状態のみを条件としてビジネスプロセス1を実行する。しかし、仮にサービスB281が何らかの障害により停止している場合、ビジネスプロセス1の実行に失敗し、ビジネスプロセス2インスタンス1201が異常終了してしまう。
【００８４】
そのため、ビジネスプロセス定義から他のビジネスプロセス定義を実行する場合、実行される側のビジネスプロセス定義の実行可否を判定するためには、実行される側のビジネスプロセス定義の配備状態に加え、実行される側のビジネスプロセス定義が利用する各サービスの稼動状態も確認する必要がある。
【００８５】
ここで、「ビジネスプロセス定義aから他のビジネスプロセス定義bを実行する」とは、ビジネスプロセス定義aのビジネスプロセスインスタンスが、ビジネスプロセス定義bが配備されたビジネスプロセス実行部へ処理要求を送信し、ビジネスプロセス定義bのビジネスプロセスインスタンスが処理を行ない、その処理結果を処理要求送信元であるビジネスプロセス定義aのビジネスプロセスインスタンスが受信するまでの一連の処理を意味する。
【００８６】
第２実施形態のビジネスプロセス処理システム２Ｓは、ビジネスプロセス1定義251を実行するビジネスプロセス2定義1220を設け、あるビジネスプロセス定義から他のビジネスプロセス定義を実行する場合の処理にも本発明を適用可能とするものである。
第２実施形態のビジネスプロセス処理システム２Ｓでは、図１０に示すように、クライアント1240はビジネスプロセス実行部230へビジネスプロセス2処理要求1101を送信する。ビジネスプロセス実行部230はビジネスプロセス2インスタンス1201を生成する。ビジネスプロセス2インスタンス1201は、ビジネスプロセス2処理要求1101とビジネスプロセス2定義1220に従って処理を実行する。ビジネスプロセス2定義1220はビジネスプロセス1定義251を実行し、ビジネスプロセス1定義251は第１実施形態と同様に、サービスA280、サービスB281を実行する。ビジネスプロセス1定義251に関する動作は第１実施形態と同様なので、説明を省略する。
【００８７】
＜＜第２実施形態のビジネスプロセス処理システム２Ｓの概要＞＞
図１０に示す第２実施形態のビジネスプロセス処理システム２Ｓは、ビジネスプロセスからビジネスプロセスを実行するような複雑な構成において、該ビジネスプロセスが依存しているサービスの稼動状態まで考慮してビジネスプロセスの稼動状態を判定し、ビジネスプロセスの実行タイミングを制御することで、ビジネスプロセスの実行失敗を回避することを目的としている。
図１０に示すように、第２実施形態のビジネスプロセス処理システム２Ｓでは、サービス状態管理部240内に新たに設けた依存関係解析部1210が、ビジネスプロセス1定義251を解析し、ビジネスプロセス1定義251が利用するサービスの一覧を依存関係管理テーブル1232へ記録しておく。サービス実行制御部233は、ビジネスプロセス1定義251の実行の直前にビジネスプロセス1定義251の配備状態を問い合わせる。
【００８８】
ビジネスプロセス状態判定部1211はビジネスプロセス1定義251自体の配備状態だけでなく、ビジネスプロセス1定義251が利用するサービスの稼動状態を含めて実行可能かどうかを判定し、サービス実行制御部233へ回答する。
これにより、あるビジネスプロセスから他のビジネスプロセスを実行するような複雑な構成においても適切に実行可否を判定することができる。また、ビジネスプロセスとサービスの依存関係を解析する際には、必要以上にビジネスプロセスの稼動率を低く判定することを回避するため、条件分岐などビジネスプロセスの構造を考慮することとしている。
【００８９】
＜ハードウェア構成＞
図１１は、第２実施形態のビジネスプロセス処理システム２Ｓにおけるハードウェア構成の一例を示す図である。
図１１に示すように、第２実施形態のビジネスプロセス処理システム２Ｓは、処理要求を行うクライアント実行装置201、該処理を実行するビジネスプロセス実行装置200、該処理要求に係わるサービスA280、B281をそれぞれ実行するサービス実行装置202、203で構成されている。
【００９０】
クライアント実行装置201、ビジネスプロセス実行装置200、およびサービス実行装置202、203上に配置されている全ての処理部は専用のハードウェアとして実現されていても良いし、ＣＰＵによって実行されるプログラムとして実現されていても良いが、以下ではプログラムとして実現した場合について説明する。
クライアント実行装置201、ビジネスプロセス実行装置200、サービス実行装置202、203は、ネットワーク204を介して接続されている。ネットワーク204はＬＡＮやイントラネットなどのローカルネットワークであっても、インターネットなどのグローバルネットワークであってもよい。また、クライアント実行装置201、サービス実行装置202、203は複数台存在しても良い。
【００９１】
クライアント実行装置201については、第１実施形態とほぼ同様であるが、主記憶装置211にクライアント1240が配備されている点のみ異なる。図１０に示すように、クライアント1240は、ビジネスプロセス実行装置200へビジネスプロセス2処理要求1101を送信する処理部であり、ＣＰＵ210によって対応するプログラムが実行され、配備されている。
図１１に示すサービス実行装置202、203については第１実施形態と同様の構成であるため、説明を省略する。
【００９２】
＜ビジネスプロセス実行装置200＞
図１１に示すように、ビジネスプロセス実行装置200は、主記憶装置211内のビジネスプロセス実行部230にビジネスプロセス2インスタンス1201、ビジネスプロセス1インスタンス1202を設けている。また、サービス状態管理部240内に第２実施形態による依存関係解析部1210およびビジネスプロセス状態判定部1211を設けている。
なお、主記憶装置211内のビジネスプロセス実行部230、サービス状態管理部240等の各処理部は、ビジネスプロセス実行プログラム220がＣＰＵ210によって実行され、配備されている。
【００９３】
加えて、二次記憶装置212に、ビジネスプロセス2定義1220、ビジネスプロセス1インタフェース定義1221(以下、ビジネスプロセス1IF定義1221と称す)、ビジネスプロセス管理テーブル1223、および第２実施形態による依存関係管理テーブル1232を設けている。これ以外の構成については第１実施形態と同様であるため、説明を省略する。
以下、ビジネスプロセス実行装置200の各部の構成について説明する。
【００９４】
＜ビジネスプロセス2インスタンス1201＞
図１０に示すビジネスプロセス2インスタンス1201は、ビジネスプロセスの進捗状態やビジネスプロセス内部で使用する変数の値といった処理要求毎の実行状態を保持し、実行状態とビジネスプロセス2定義1220の内容に従って処理を行なう処理部であり、ビジネスプロセス実行部230が受信したビジネスプロセス2処理要求1101毎にビジネスプロセス実行部230が生成する。
【００９５】
＜ビジネスプロセス2定義1220＞
図１１に示すビジネスプロセス2定義1220内に、第２実施形態で使用するビジネスプロセス2定義1220の処理内容の一例を示す。
ビジネスプロセス2定義1220は、ビジネスプロセス2処理要求1101(図１０参照)を受け取りデータを抽出するステップID1であってステップ種別が開始ステップであるステップ1300、ビジネスプロセス1定義251を実行するステップID2であってステップ種別がサービス実行ステップであるステップ1301、および後処理を行なうステップID3であってステップ種別が終了ステップであるステップ1302によって構成されている。
【００９６】
但し、上記の内容はビジネスプロセス定義の一例であり、ビジネスプロセス定義言語で記述可能な範囲であればどのような処理フローが定義されていても良い。
ビジネスプロセス2定義1220が実行するビジネスプロセス1定義251(図１０、図１１参照)は、第１実施形態に示したものと同様なので、説明を省略する。
【００９７】
＜ビジネスプロセス1IF定義1221＞
図１０、図１１に示すビジネスプロセス1IF定義1221には、ビジネスプロセス1定義251を実行するために必要な情報が記述されている。例えば、入力として必要なデータのデータ構造や、ビジネスプロセス1定義251が応答するデータのデータ構造である。ビジネスプロセス2インスタンス1201からビジネスプロセス1を実行するよう指示を受けたサービス実行制御部233(図１０参照)は、ビジネスプロセス1IF定義1221に従ってビジネスプロセス1処理要求1102を生成し、ビジネスプロセス実行部230へ送信する。ビジネスプロセス1処理要求1102を受け取ったビジネスプロセス実行部230は、ビジネスプロセス1インスタンス1202を生成する。ビジネスプロセス1インスタンス1202は、ビジネスプロセス1処理要求1102とビジネスプロセス1定義251に従って処理を行なう。
【００９８】
＜依存関係解析部1210＞
図１０、図１１に示す依存関係解析部1210は、ビジネスプロセス1定義251、ビジネスプロセス2定義1220を解析して各ビジネスプロセス定義が利用するサービスの一覧を取得し、依存関係管理テーブル1232へ登録する処理部である。本処理部における処理の詳細は後記する。
【００９９】
＜依存関係管理テーブル1232＞
図１２は、依存関係管理テーブル1232の構成を示す図である。
図１２に示す依存関係管理テーブル1232は、ビジネスプロセス定義毎に、該ビジネスプロセス定義が実行するビジネスプロセス名およびサービス名を保持するテーブルである。
依存関係管理テーブル1232は、ビジネスプロセス定義の識別子であるビジネスプロセス名1400、該ビジネスプロセス定義が利用するサービスおよびビジネスプロセスの識別子一覧である依存サービス(ビジネスプロセス)名1401で構成されている。
【０１００】
＜ビジネスプロセス状態判定部1211＞
図１０、図１１に示すビジネスプロセス状態判定部1211は、サービス状態管理部240が保持する情報からビジネスプロセスの稼動状態を判定し、稼動状態管理テーブル1230へ登録する処理部である。本処理部における処理の詳細は後記する。
【０１０１】
＜ビジネスプロセス管理テーブル1223＞
図１３は、ビジネスプロセス管理テーブル1223の構成の一例を示す図である。
図１３に示すビジネスプロセス管理テーブル1223は、ビジネスプロセス定義自体の配備状態を保持するテーブルであり、ビジネスプロセス定義の識別子であるビジネスプロセス名1500、ビジネスプロセス定義の状態1501で構成されている。
ビジネスプロセス定義の状態1501としては、ビジネスプロセス実行装置200へ配備済みであるが処理要求は受け付けていない"配備済み"、およびビジネスプロセス実行装置200へ配備済みであり、かつ処理要求を受け付け可能である"稼動中"といった状態がある。
【０１０２】
なお、図１３の構成は一例であり、上記以外の情報が含まれていても良い。ビジネスプロセス管理テーブル1223への情報の登録は、ビジネスプロセス実行プログラム220に含まれる処理部が行なっても良いし、他の処理部が行なっても良いが、既存技術によって実現可能であるため詳細は省略する。
【０１０３】
＜稼動状態管理テーブル1230＞
図１４は、稼動状態管理テーブル1230の構成を示す図である。
図１４に示す稼動状態管理テーブル1230は、第１実施形態で例示した稼動状態管理テーブル261(図４参照)と同様の構成であるが、管理対象としてサービスだけでなく、ビジネスプロセスも含んでいる点が異なる(図１４のサービス(ビジネスプロセス)名1600参照)。
対象がビジネスプロセスの場合、ビジネスプロセス実行可否が稼動状態1601に、ビジネスプロセスが実行不可の場合の原因となる障害が障害種別1602に、ビジネスプロセス実行待機時間が待機時間1603に、以上のデータの更新時刻が更新時刻1604に格納される。
【０１０４】
＜待機時間管理テーブル1231＞
図１５は、待機時間管理テーブル1231の構成を示す図である。
図１５に示す待機時間管理テーブル1231は、第１実施形態で例示した待機時間管理テーブル262(図５参照)と同様の構成であるが、管理対象としてサービスだけでなく、ビジネスプロセスも含んでいる点が異なる(図１５のサービス(ビジネスプロセス)名1700参照)。対象がビジネスプロセスの場合、ビジネスプロセスが実行不可の場合の原因となる障害が障害種別1701に、ビジネスプロセス実行待機時間が待機時間1702に格納されている。
【０１０５】
＜＜ビジネスプロセス実行部230によるビジネスプロセス実行処理＞＞
第２実施形態におけるビジネスプロセス実行部230によるビジネスプロセス実行処理の流れは第１実施形態の図６とほぼ同様であるため、説明は省略するが、以下の点が異なる。(a)実行されるビジネスプロセス定義について、ビジネスプロセス1定義251(図１参照)からビジネスプロセス2定義1220(図１０参照)へ変更、(b)ビジネスプロセス1処理要求100(図１参照)をビジネスプロセス2処理要求1101(図１０参照)へ変更、(c)ビジネスプロセス1インスタンス2311(図１参照)をビジネスプロセス2インスタンス1201(図１０参照)へ変更。
【０１０６】
＜＜依存関係解析部1210による依存関係管理テーブル1232の更新処理＞＞
次に、依存関係解析部1210による依存関係管理テーブル1232の更新処理について、図１６に従って説明する。
図１６は、図１０に示す依存関係解析部1210がビジネスプロセス1定義251、ビジネスプロセス2定義1220を解析して依存関係管理テーブル1232を更新する処理の流れを示すフローチャートである。
本処理では、ビジネスプロセス定義およびサービスIF定義を解析することで、該ビジネスプロセスから利用されるサービスを該ビジネスプロセスの依存サービスとして依存関係管理テーブル1232へ登録する。全ての依存サービスが稼動している場合のみ、該ビジネスプロセスは実行可能と判定する。ここで、ビジネスプロセスから実行される全てのサービスを無条件に依存サービスとして登録すると、該ビジネスプロセスの稼動率を無駄に低く判定してしまうことが想定される。
【０１０７】
そこで、本第２実施形態では、ビジネスプロセスの構造のうち条件分岐および非同期サービスの実行に着目して、依存サービスとして登録するサービスに制限を加えることで、稼動率を低く判定してしまうことを回避している。
具体的には、ビジネスプロセス定義をフローの先頭から順に解析する際、以下の２点の何れかに該当した場合、その時点で解析を中止する。中止点以前に実行されるサービスのみを依存サービスとして登録し、中止点以降に実行されるサービスは依存サービスとしてはカウントしない。
【０１０８】
(ａ)  条件分岐ステップ
条件分岐ステップが存在する場合、実際に実行される経路はビジネスプロセス実行時まで不明である。このため、分岐先に配置された全てのサービスを依存サービスとして登録すると、実際には実行されないサービスまで依存サービスとして登録する場合が生じる。これを回避するため、条件分岐が存在するビジネスプロセスについては、条件分岐の前のステップまでを依存関係解析対象とする。
【０１０９】
(ｂ)  非同期サービスの実行
サービスの中には処理の実行が比較的長時間(数時間から数日)に渡るものが存在する。例えば人手による申請−承認処理を行なうようなサービスである。これらはビジネスプロセスからの処理要求に対して処理応答を非同期的に返すため、非同期サービスと呼ばれる。
非同期サービスの実行には時間がかかるため、非同期サービス以降のステップで実行されるサービスは、ビジネスプロセス実行開始時に稼動状態を判定しても実際にサービスを実行する際には稼動状態が変わっている可能性が高い。
【０１１０】
これを回避するため、非同期サービスの実行が存在するビジネスプロセスについては、非同期サービスの実行より前のステップまでを依存関係解析対象とする。
実行するサービスが非同期サービスかどうかは、図１０、図１１に示すサービスAIF定義252、サービスBIF定義253等のサービスIF定義から識別することができる。具体的には、サービスの実行メソッドの定義として、処理要求のデータ型のみ定義されており、処理応答に関する定義が無いものは非同期サービスと判定することができる。
以上を踏まえて、図１６に基づいて、依存関係管理テーブル1232の更新処理について説明する。
図１６を参照して、
【０１１１】
(ステップ1800)  図１０に示すサービス状態管理部240の依存関係解析部1210がビジネスプロセス実行装置200上に配備されたビジネスプロセス1定義251、ビジネスプロセス2定義1220、サービスAIF定義252、サービスBIF定義253を取得する。
(ステップ1801)取得した全てのビジネスプロセス定義について、ステップ1802からステップ1809の処理を実行する。
(ステップ1802)処理対象のビジネスプロセス定義を読み込む。
(ステップ1803)処理対象ステップIDを表す変数iに1を代入する。
【０１１２】
(ステップ1804)処理対象ビジネスプロセス定義のステップIDiのステップ種別が終了ステップまたは分岐ステップであるか判断し、終了ステップまたは分岐ステップであればステップ1809へ移行し、それ以外であればステップ1805へ移行する。
(ステップ1805)処理対象ビジネスプロセス定義のステップIDiのステップ種別がサービス実行ステップであるか否か判断され、サービス実行ステップであればステップ1806へ移行し、それ以外であればステップ1808へ移行する。
(ステップ1806)実行対象のサービスが非同期サービスであるか否か判断され、非同期サービスでなければステップ1807へ移行し、非同期サービスであればステップ1809へ移行する。
【０１１３】
(ステップ1807)図１２に示す依存関係管理テーブル1232へ、解析中のビジネスプロセスの依存サービスとしてステップID iで実行するサービス名(ビジネスプロセス名)を依存サービス名1401に追加する。
(ステップ1808)処理対象ビジネスプロセス定義から、ステップIDiの次のステップのステップIDを取得し、iへ代入し、ステップ1804へ移行する。
(ステップ1809)取得した全てのビジネスプロセス定義について処理が完了しているか否か判断し、取得した全てのビジネスプロセス定義について処理が完了していればステップ1810へ移行し、完了していなければステップ1802へ移行する。
【０１１４】
(ステップ1810)図１２に示す依存関係管理テーブル1232の全エントリを検索し、依存サービス(ビジネスプロセス)名1401にビジネスプロセスが登録されている場合、該ビジネスプロセスが依存している全てのサービス(ビジネスプロセス)を依存サービス(ビジネスプロセス)名1401として追加する。例えば本第２実施形態では、図１２に示すように、ビジネスプロセス2はビジネスプロセス1を利用し、ビジネスプロセス1はサービスA280およびサービスB281を利用している。このとき、依存関係管理テーブル1232には図１２に示す通り、ビジネスプロセス1の依存サービスとしてサービスA280、サービスB281が登録され、さらにビジネスプロセス2の依存サービスとしてビジネスプロセス1、およびビジネスプロセス1が依存しているサービスA280、サービスB281が登録される。
【０１１５】
＜＜ビジネスプロセス状態判定部1211による稼動状態管理テーブル1230への登録処理＞＞
次に、図１０、図１１に示すビジネスプロセス状態判定部1211による稼動状態管理テーブル1230への登録処理について、図１７に従って説明する。
なお、図１７は、ビジネスプロセス状態判定部1211が稼動状態管理テーブル1230、待機時間管理テーブル1231、ビジネスプロセス管理テーブル1223、依存関係管理テーブル1232に登録された情報からビジネスプロセスの稼動状態を判定し、稼動状態管理テーブル1230へ登録する処理の流れを示すフローチャートである。
【０１１６】
図１４に示す稼動状態管理テーブル1230に登録されるビジネスプロセスの稼動状態1601および待機時間1603の判定方法を簡単に説明する。
図１０、図１１に示すビジネスプロセス１定義251等のビジネスプロセス定義がビジネスプロセス実行装置200に配備されていてリクエストを受け付け可能な状態であり、かつ該ビジネスプロセスが利用するサービスが全て稼動している場合、ビジネスプロセスは実行可能と判定され、図１４の稼動状態1601として「稼動」が登録される。該ビジネスプロセス定義がリクエストを受け付けていないか、もしくは利用するサービスのうち1つ以上が停止している場合、ビジネスプロセスは実行不可と判定され、図１４の稼動状態1601として「停止」が登録される。稼動状態1601が停止の場合、ビジネスプロセスが利用するサービスのうち停止しているサービスのサービス実行待機時間を全て取得し、その中で最も待機時間が長いものを図１４の待機時間1603として登録する。
【０１１７】
本第２実施形態では、図１７に示す処理は、稼動状態管理テーブル1230または待機時間管理テーブル1231の更新を検知して実行されるが、このタイミングは一例であり、例えば該テーブル1230、1231の更新とは無関係に一定時間毎に図１７の処理を行なっても良い。また、本第２実施形態では図１７の処理の度に全ての図１０、図１１に示すビジネスプロセス実行履歴254を読み込んで処理を行なっているが、図１７の処理を２度以上行なう場合は、前回読み込んだビジネスプロセス実行履歴254(図３参照)からの差分のみを読み込んで処理を行なっても良い。
【０１１８】
図１７を参照し、
(ステップ1900)図１０に示すサービス状態管理部240が稼動状態管理テーブル1230または待機時間管理テーブル1231の更新を検知する。
(ステップ1901)図１４に示す稼動状態管理テーブル1230のビジネスプロセスに関するエントリを以下のデータで初期化する。サービス(ビジネスプロセス)名1600：(変更なし)、稼動状態1601：文字列"稼動"、障害種別1602：文字列"−"、待機時間1603：文字列"−"、更新時刻1604：文字列"−"。
(ステップ1902)稼動状態管理テーブル1230に登録されているエントリのうち、稼動状態1601が"停止"である全てのサービスSstopについて、ステップ1903からステップ1907の処理を実行する。
【０１１９】
(ステップ1903)図１４に示す稼動状態管理テーブル1230から、"停止"であるサービスSstopのサービス名1600および障害種別1602を取得し、障害種別を表す変数eへ格納する。また、待機時間1603を取得し、待機時間を表す変数t1へ格納する。また、更新時刻1604を取得し、更新時刻を表す変数trへ格納する。
(ステップ1904)図１２に示す依存関係管理テーブル1232から、"停止"であるサービスSstopに依存している全てのビジネスプロセスbpを取得する。
(ステップ1905)稼動状態管理テーブル1230(図１４参照)のサービス(ビジネスプロセス)名1600がビジネスプロセスbpであるエントリについて、待機時間1603が文字列"−"または待機時間の変数t1より小さいか否か判断し、待機時間1603が文字列"−"または待機時間の変数t1より小さい場合はステップ1906へ移行し、t1以上の場合はステップ1907へ移行する。
【０１２０】
(ステップ1906)図１４に示す稼動状態管理テーブル1230のサービス(ビジネスプロセス)名1600がビジネスプロセスbpであるエントリを以下のデータで更新する。稼動状態1601：文字列"停止"、障害種別1602：障害種別変数e、待機時間1603：待機時間変数t1、更新時刻1604：更新時刻変数tr。
(ステップ1907)図１４に示す稼動状態管理テーブル1230に登録されているエントリのうち、全ての稼動状態1601が停止のサービスSstopについて、処理が完了しているか否か判断し、処理が完了していればステップ1908へ移行し、完了していなければステップ1903へ移行する。
【０１２１】
(ステップ1908)図１３に示すビジネスプロセス管理テーブル1223に登録されているビジネスプロセスのうち、状態1501が停止である全てのビジネスプロセスBPstopについて、ステップ1909からステップ1913の処理を実行する。
(ステップ1909)図１５に示す待機時間管理テーブル1231から停止のビジネスプロセスBPstopの待機時間1702を取得し、待機時間を表す変数t2へ格納する。また、図１４に示す稼動状態管理テーブル1230の障害種別1602を取得して障害種別を表す変数e2へ格納する。また、更新時刻1604を取得し、更新時刻を表す変数tr2へ格納する。
【０１２２】
(ステップ1910)図１２に示す依存関係管理テーブル1232から、依存サービス(ビジネスプロセス)名1401に停止であるビジネスプロセスBPstopが含まれる全てのビジネスプロセス(ビジネスプロセス名1400)を取得し、ビジネスプロセス名を表す変数bpに格納する。
(ステップ1911)図１４に示す稼動状態管理テーブル1230のサービス(ビジネスプロセス)名1600がビジネスプロセス名の変数bpに含まれるエントリについて、待機時間1603が文字列"−"またはt2より小さいか否か判断し、待機時間1603が文字列"−"またはt2より小さい場合はステップ1912へ移行し、t2以上の場合はステップ1913へ移行する。
【０１２３】
(ステップ1912)図１４に示す稼動状態管理テーブル1230のサービス(ビジネスプロセス)名1600がビジネスプロセス名の変数bpであるエントリを以下のデータで更新する。稼動状態1601：文字列"停止"、障害種別1602：障害種別変数e2、待機時間1603：待機時間変数t2、更新時刻1604：更新時刻変数tr2。
(ステップ1913)図１３に示すビジネスプロセス管理テーブル1223に登録されているビジネスプロセスのうち、状態1501が停止である全てのビジネスプロセスBPstopについて、処理が完了しているか否か判断し、処理が完了していれば終了する。完了していなければステップ1909へ移行する。
以上が、図１０に示すビジネスプロセス状態判定部1211による稼動状態管理テーブル1230への登録処理である。
【０１２４】
上記第２実施形態による依存関係解析部1210およびビジネスプロセス状態判定部1211(図１０、図１１参照)によれば、あるビジネスプロセスから他のビジネスプロセスを実行するような複雑な構成においてもビジネスプロセスの稼動状態を判定することができる。また、条件分岐などビジネスプロセスの構造を考慮して依存関係を解析することで必要以上にビジネスプロセスの稼動率を低く判定することを回避できる。これにより、ビジネスプロセスの稼動状態に応じてビジネスプロセスの実行タイミングを制御することができ、ビジネスプロセス実行装置200全体としてビジネスプロセスの実行失敗回数を低減することができる。
【０１２５】
＜＜まとめ＞＞
本発明は、ビジネスプロセスが、ネットワーク上の複数のサービスを定義された順に実行して業務を遂行するビジネスプロセス処理システムにおいて、サービスの稼動状態に応じてサービスの実行タイミングを制御するものである。
このため、本発明では、図１に示すように、ビジネスプロセス実行装置200が保持するビジネスプロセス実行履歴254を解析してサービスA280、B281等のサービスの稼動状態、およびサービス毎、障害種別毎のサービス実行待機時間を取得する。サービスを実行する直前にサービスの稼動状態をチェックし、サービスの稼動状態に応じてサービスを直ぐに実行するか、または一定時間待機した後に実行するかを判断する。
【０１２６】
待機する場合の待機時間としては、前記サービス毎、障害種別毎のサービス実行待機時間を使用する。サービス稼動状態の取得に利用するビジネスプロセス実行履歴254には、ビジネスプロセス実行装置200に配備されている全てのビジネスプロセスの実行履歴が含まれている。従って、本発明では、あるビジネスプロセスによるサービスの実行結果は、ビジネスプロセス実行履歴254を介してビジネスプロセス実行装置200に配備されている全てのビジネスプロセスで共有される。
【０１２７】
さらに、ビジネスプロセス定義からビジネスプロセスとサービスの依存関係を取得し、依存関係やビジネスプロセスの構造、サービスの稼動状態などの情報からビジネスプロセスの稼動状態を判定し、ビジネスプロセスの稼動状態に応じてビジネスプロセスを直ぐに実行するか、または一定時間待機した後に実行するかを判断する。
【０１２８】
図１８を用いて解決手段の概要について説明する。
なお、図１８は、ビジネスプロセスが多段になっている場合に、サービスの稼動状態に応じてビジネスプロセスの実行タイミングを制御する処理の概念図である。
発注ビジネスプロセス1851から購入ビジネスプロセス1853を実行する処理を本発明によるサービス実行制御部233が代行する。サービス実行制御部233では、本発明によるサービス状態管理部240から購入ビジネスプロセスの稼動状態を取得する。サービス状態管理部240では、購入ビジネスプロセス1853がどのサービスを利用しているかを示す依存関係情報、および各サービスの稼動状態を示すサービス稼動情報から、購入ビジネスプロセス1853の実行可否を判定する。
【０１２９】
購入ビジネスプロセス1853は納期確認サービス1862および注文サービス1863を利用する。2つのサービスが稼動している場合、サービス実行制御部233はすぐに購入ビジネスプロセス1853を実行する。仮にどちらかのサービスが停止していた場合、購入ビジネスプロセス1853は実行不可と判定され、サービス実行制御部233は一定時間待機してサービスの復旧を待った後、購入ビジネスプロセス1853を実行する。以上の処理により、ビジネスプロセスの稼動状態に応じて実行タイミングを制御し、ビジネスプロセスの実効失敗を回避する。
【０１３０】
また、ビジネスプロセスとサービスの依存関係を解析する際には、ビジネスプロセスの構造を考慮する必要がある。この様子を図１９を用いて説明する。
なお、図１９は、ビジネスプロセスの構造に応じた依存関係解析範囲を表す図であり、(a)は処理の途中に条件分岐が含まれているビジネスプロセスを示す図であり、(b)は処理の途中に非同期サービスcの実行が含まれているビジネスプロセスを示す図である。
【０１３１】
図１９(a)に示すビジネスプロセスは、分岐結果が判明するまでサービスc、サービスdのどちらが実行されるか判定することはできない。この場合、サービスcおよびdの双方の稼動をビジネスプロセスの稼動状態判定の条件としてしまうと、無駄にビジネスプロセスの稼働率を低く判定してしまう可能性がある。このため、図１９(a)のケースでは分岐の前までを依存関係解析対象とする。
【０１３２】
また、図１９(b)に示すビジネスプロセスは、処理の途中に非同期サービスcの実行が含まれている。非同期サービスとは処理の開始から終了までにかかる時間が比較的長時間に及ぶサービスである。非同期サービスcの後に実行される同期サービスdの稼動状態は、ビジネスプロセスの処理開始時とは異なっている可能性が高い。この場合、同期サービスdの稼動をビジネスプロセスの稼動状態判定の条件としてしまうと、無駄にビジネスプロセスの稼働率を低く判定してしまう可能性がある。このため、図１９(b)に示すケースでは非同期サービスcより前を依存関係解析対象とする。
【０１３３】
このように、本発明ではビジネスプロセスの構造を考慮してビジネスプロセスとサービスの依存関係を判定する。
本発明によれば、あるビジネスプロセスがサービスの実行に失敗することでサービスが停止したことを検知し、後続のビジネスプロセスによる停止中サービスの実行を一時的に延期することで、ビジネスプロセス処理システム全体としてビジネスプロセスの実行失敗回数を低減することができる。
【０１３４】
さらにビジネスプロセスからビジネスプロセスを実行するような複雑な構成において、ビジネスプロセスの稼動状態を、該ビジネスプロセスが依存しているサービスの稼動状態まで考慮して判定することで、ビジネスプロセス処理システム全体としてビジネスプロセスの実行失敗回数を低減することができる。
【図面の簡単な説明】
【０１３５】
【図１】本発明に関わる第１実施形態のビジネスプロセス処理システムにおけるデータの流れを示す図である。
【図２】第１実施形態のビジネスプロセス処理システムのハードウェア構成の一例を示す図である。
【図３】ビジネスプロセス実行履歴の構成の一例を示す図である。
【図４】稼動状態管理テーブルの構成を示す図である。
【図５】待機時間管理テーブルの構成を示す図である。
【図６】ビジネスプロセス実行部によるビジネスプロセス実行処理の流れを示すフローチャートである。
【図７】サービス実行制御部によるサービス実行制御処理の詳細を示すフローチャートである。
【図８】サービス待機時間計算部が待機時間管理テーブルを更新する処理の流れを示すフローチャートである。
【図９】サービス稼動状態解析部が稼動状態管理テーブルを更新する処理の流れを示すフローチャートである。
【図１０】第２実施形態のビジネスプロセス処理システムにおけるデータの流れを示す図である。
【図１１】第２実施形態のビジネスプロセス処理システムにおけるハードウェア構成の一例を示す図である。
【図１２】依存関係管理テーブルの構成を示す図である。
【図１３】ビジネスプロセス管理テーブルの構成の一例を示す図である。
【図１４】稼動状態管理テーブルの構成を示す図である。
【図１５】待機時間管理テーブルの構成を示す図である。
【図１６】依存関係解析部が依存関係管理テーブルを更新する処理の流れを示すフローチャートである。
【図１７】ビジネスプロセス状態判定部が稼動状態管理テーブルへ登録する処理の流れを示すフローチャートである。
【図１８】ビジネスプロセスが多段になっている場合に、サービスの稼動状態に応じてビジネスプロセスの実行タイミングを制御する処理の概念図である。
【図１９】(ａ)は処理の途中に条件分岐が含まれているビジネスプロセスを示す図であり、(ｂ)は処理の途中に非同期サービスの実行が含まれているビジネスプロセスを示す図である。
【図２０】従来のビジネスプロセスが多段の場合の障害発生状況を示した図である。
【図２１】従来の障害の復旧作業の様子を示した図である。
【符号の説明】
【０１３６】
200    ビジネスプロセス実行装置
204    ネットワーク
230    ビジネスプロセス実行部
233    サービス実行制御部
242    サービス稼動状態解析部
243    サービス待機時間計算部
251    ビジネスプロセス1定義(ビジネスプロセス定義、他のビジネスプロセス定義)
254    ビジネスプロセス実行履歴(ビジネスプロセス実行履歴記憶部)
261    稼動状態管理テーブル(サービス稼動状態解析部)
270、1240  クライアント
280    サービスA
281    サービスB
503    待機時間 (請求項１のサービス実行待機時間)
602    待機時間 (請求項３の各サービスの実行失敗の原因毎のサービス実行待機時間)
1210    依存関係解析部
1211    ビジネスプロセス状態判定部
1220    ビジネスプロセス2定義(あるビジネスプロセス定義)
1230    稼動状態管理テーブル(サービス稼動状態解析部)
1862    納期確認サービス(他のビジネスプロセス定義が利用するサービス)
1863    注文サービス(他のビジネスプロセス定義が利用するサービス)
ａ      サービス(請求項７、請求項１７の条件分岐よりも前に実行されるサービス)
ｂ      サービス(請求項７、請求項１７の条件分岐よりも前に実行されるサービス)
ｃ      非同期サービス(請求項８、請求項１８の非同期のサービス)、
【図１】
2009282581.tif 000003
【図２】
2009282581.tif 000004
【図３】
2009282581.tif 000005
【図４】
2009282581.tif 000006
【図５】
2009282581.tif 000007
【図６】
2009282581.tif 000008
【図７】
2009282581.tif 000009
【図８】
2009282581.tif 000010
【図９】
2009282581.tif 000011
【図１０】
2009282581.tif 000012
【図１１】
2009282581.tif 000013
【図１２】
2009282581.tif 000014
【図１３】
2009282581.tif 000015
【図１４】
2009282581.tif 000016
【図１５】
2009282581.tif 000017
【図１６】
2009282581.tif 000018
【図１７】
2009282581.tif 000019
【図１８】
2009282581.tif 000020
【図１９】
2009282581.tif 000021
【図２０】
2009282581.tif 000022
【図２１】
2009282581.tif 000023