JP2009026221A - ビジネスプロセス運用管理システム、方法、プロセス運用管理装置およびそのプログラム - Google Patents

Abstract

【課題】複数のサービス呼出ステップから構成されるプロセスにおいて、リソース不足が発生した場合に、適切なリソースの追加を可能とする手段を提供すること。
【解決手段】ビジネスプロセス運用管理装置１２００は、サービス実行装置１５１０等の負荷が増大した場合、当該サービス実行装置１５１０等のサービス実行処理部１５１１等を呼び出しているサービス呼出ステップの状態を判定する。その状態がボトルネックの状態であれば、当該サービス実行処理部１５１１等を呼び出している他のプロセスにおけるサービス呼出ステップの状態を判定する。その状態においてボトルネック以外の状態が無い場合には当該サービス実行装置１５１０等に対するリソースの追加を決定し、スループットを制限できる状態がある場合にはスループットを制限する決定をする。
【選択図】図１

Description

本発明は、ビジネスプロセスを運用管理するシステム等に関する。

複数サーバ間での負荷分散を行うことにより、一台の高性能サーバと同等以上の大量の処理を行うことができるようにする技術の開発が進んでいる。例えば、特許文献１では、負荷分散クラスタ内のサーバ台数を動的に変化させて、遊休リソースを効率よく使用してリソースの稼働率を向上させるグリッド技術が開示されている。

一方でビジネスの変化に迅速に対応できるよう、既存のソフトウェアの提供するサービス群を柔軟に組み合わせて、ビジネスプロセスを実行するシステムを構築する技術も進んでいる。例えば、特許文献２では、このようなビジネスプロセスを実行するシステムの運用を容易にするための技術が開示されている。

ここでのサービスとは、計算機上で稼動するアプリケーションが提供する機能のことである。また、サービスは標準のインターフェースを使って利用できるアプリケーションとして実装されるものが多い。例えば、在庫量を取得するリクエストに、製品名、店舗名を付加して送信すると、指定された製品の指定された店舗にある在庫量をレスポンスとして返すという機能を持つ、在庫照会サービスなどが考えられる。

また、ビジネスプロセスは前記のサービスを呼び出す主体のひとつである。例えば、個別に存在する、注文受付サービス、在庫照会サービス、出荷サービスの３つのサービスがあった場合、これらを呼び出す順序等を定義してサービスを組み合わせて注文を処理する一連の処理を実行するものをビジネスプロセスと呼ぶ。ビジネスプロセスはサービスと同様に、標準のインターフェースを使って利用できるアプリケーションとして実装されるものが多い。また、前記のサービスの呼出順序等を定義したビジネスプロセス定義言語の代表的なものとして、ＢＰＥＬ（Business Process Execution Language）があり、標準化が進められ注目を集めている。
以上説明したグリッド技術とビジネスプロセス実行する技術とを組み合わせて、リソースを効率よく活用し、かつビジネスの変化に迅速に対応できる業務システムを構築することが考えられる。
特開２００３−１２４９７６号公報 特開２００５−１４１６０５号公報

従来の技術を単純に組み合わせた構成、すなわちビジネスプロセスが呼び出すサービスをグリッド環境で実行する構成では、次のような問題点がある。

１つ目の問題点は、グリッド環境で実行されるサービスに対して行われるリソースの追加が、サービスのスループット向上にはつながっても、ビジネスプロセスとしてのスループット向上につながらないケースがあることである。図２４は、グリッド環境で異なるサービスを実行している２つのサーバのＣＰＵ（Central Processing Unit）負荷が高くなり、リソースの追加として、追加用の空きサーバの割り当てが行われようとしている状況である。

ビジネスプロセス実行環境では、ビジネスプロセスＡにおけるサービス呼出ステップＤのスループットの低下が、リクエストの滞留を招き、ビジネスプロセスＡ全体のボトルネックとなっている。このような場合、空きリソースが少ない場合にはビジネスプロセスＡのスループットを向上させるためにサービス呼出ステップＤに対して、リソースを追加すべきだが、例えばサーバのＣＰＵ負荷増大検知のタイミング次第では、同じくスループットが低下しているサービス呼出ステップＢにリソースを追加してしまう。この場合、サービス呼出ステップＤのスループットは向上しないため、リソースを追加したとしてもビジネスプロセスＡの処理の停滞を解消することはできない。

２つ目の問題点は、ビジネスプロセスのスループット向上につながらないサービス呼出ステップの消費するリソースが、他のビジネスプロセスのスループットに影響を与えてしまうことである。例えば、図２５は、図２４における状況に加えて、ビジネスプロセスＢが実行され、ビジネスプロセスＡおよびビジネスプロセスＢがサービスＢを共有している状況である。

図２５に示した環境において、ビジネスプロセスＡのボトルネックは、サービス呼出ステップＤであり、サービス呼出ステップＢにリソースを追加して大量にリクエストを処理しても、ビジネスプロセスＡのスループット向上につながらない。そして、ビジネスプロセスAのサービス呼出ステップＢがサーバのＣＰＵを多く使用してしまうと、ビジネスプロセスＢのサービス呼出ステップＢにおいて使用するＣＰＵを圧迫して、結果的にビジネスプロセスＢのスループットが低下してしまう。

したがって、本発明は、複数のサーバをサービス呼出ステップによりに呼び出して実行されるプロセスにおいて、サーバがリソース不足に陥った場合に、ビジネスプロセスのスループットが向上するよう、適切なリソースの追加を可能とする手段を提供することを目的とする。

本発明に係るビジネスプロセス運用管理システムは、
所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムであって、
前記プロセス運用管理装置は、
前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットを少なくとも保持したサービス呼出ステップ管理テーブルを格納した記憶部と、
前記サービス呼出ステップ管理テーブルから、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出し、
この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、スループットを制限できる状態であるか、またはそれら以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理テーブルに記憶するサービス呼出ステップ管理部と、
前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得すると、
前記サービス呼出ステップ管理テーブルから、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定し、
ボトルネックの状態であれば、前記アプリケーションサーバ上のサービス実行処理部を呼び出している他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外の状態があるか否かを判定し、ボトルネック以外の状態が無い場合には、当該アプリケーションサーバに対するリソースの追加を決定し、
他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合には、他のプロセスのサービス呼出ステップのスループットを制限する決定をする負荷増大対処決定部とを備える
ことを特徴とする。
本発明のその他の態様については、後記する実施の形態において詳しく説明する。

本発明によると、プロセスのボトルネックとなるサービス呼出ステップを特定できるため、サービス呼出ステップにおいてリソース不足が発生した場合に、適切なリソースの追加を実行することができる。また、本発明によると、サーバ追加が実施されてもビジネスプロセスのスループットが向上しないケースや、ビジネスプロセスのスループットが向上しないにもかかわらず計算機リソースを多く使用して他のビジネスプロセスのスループットへ悪影響を与えるケースを防ぐことができる。そのため、ビジネスプロセスのスループットが向上するように、適切なリソース追加を実施することができる。

以下、本発明の好適な実施の形態について、添付した図面を参照しつつ説明する。
［第１実施形態］
本発明の第１実施形態に係る処理は、サービスを提供するサーバ群の負荷と、前記サービスを適宜呼び出して利用するビジネスプロセス群の状況を定期的に監視する処理と、サーバの負荷増大の検知を契機として各ビジネスプロセスの状況に応じて対処を決定する処理から構成される。
ここでビジネスプロセスの状況とは、ビジネスプロセスでサービスが呼び出される順序と、ビジネスプロセスにおいて、サービスを呼び出すステップ（以下、サービス呼出ステップ）ごとのスループットの値から決定した各サービス呼出ステップの状態のことを指す。

ここで、各サービス呼出ステップの状態は、各サービス呼出ステップの順序およびそのスループットの値を相互に比較した結果から、「通常」状態、「ボトルネック」状態、「流量制限可能」状態の３つの状態とする。
「ボトルネック」状態は、当該ビジネスプロセスの処理のボトルネックとなっているサービス呼出ステップにあてはまる状態のことで、当該サービス呼出ステップのスループットが向上すればビジネスプロセスのスループットが向上することが見込めるステップであることを示している。
「流量制限可能」状態は、当該ステップのスループットをある値まで低下させてもビジネスプロセスのスループットには影響を与えないサービス呼出ステップにあてはまる状態のことである。

後記するビジネスプロセス運用管理装置が、サーバの負荷増大通知を受け付けると、当該サーバ上で稼動するサービスを呼び出しているすべてのサービス呼出ステップの状態および状態の組み合わせに応じて対処を次のように決定する。

前記サービス呼出ステップのうち、ひとつも「ボトルネック」状態のサービス呼出ステップがない場合は対処を実行しない。
また、前記サービス呼出ステップのうち、「ボトルネック」状態と「流量制限可能」状態とのサービス呼出ステップがそれぞれ１つ以上ある場合は、「流量制限可能」状態であるサービス呼出ステップの流量制限を実施する。
さらに、前記サービス呼出ステップのうち、１つ以上「ボトルネック」状態のサービス呼出ステップがあり、「流量制限可能」状態のサービス呼出ステップがない場合は、負荷が高くなっているサーバへリソースを追加する。

以下、本実施形態のシステム構成例について説明し、次にその動作の様子を、ＰＡＤ図を用いて説明し、最後にある状況を想定した本発明の動作例（動作例１、および動作例２）を示す。

図１は、本実施形態のビジネスプロセス実行環境のシステム構成図の例である。本実施形態でのシステムは、複数のサービスを実行するサービス実行装置（１５１０〜１５４０）群、このサービス実行装置群（１５１０〜１５４０）を管理するリソース管理装置１４００、ビジネスプロセスを実行するビジネスプロセス実行装置１１００、ビジネスプロセスの運用を管理するビジネスプロセス運用管理装置１２００、ビジネスプロセスとサービス間でやり取りされるメッセージの中継、およびリソース管理装置１４００とビジネスプロセス運用管理装置間でやり取りされるイベント通知や命令伝達の中継を行うビジネスプロセス・サービス間中継装置１３００、および各装置を相互に接続するネットワーク１６００を備えて構成される。
以下、各装置について詳細に説明する。

（サービス実行装置）
サービス実行装置群（１５１０〜１５４０）は、それぞれが１台のサーバまたは複数台のサーバの集合であり、動的にサーバを追加して処理能力を向上させることのできる装置である。また、前記各サーバは仮想的なサーバであっても構わない。仮想的なサーバである場合、１つの仮想的なサーバが使用できるＣＰＵやメモリなどの計算機リソースの利用量を変更することで、同様に処理能力を向上させることができる。ここで、図２は、本実施形態におけるサービス実行装置１５１０の装置構成例を示す図面である。ここでは、例としてサービス実行装置１５１０について説明するが、その他のサービス実行装置（１５２０〜１５４０）の装置構成も同様である。

サービス実行装置１５１０は、通信制御装置２１００、ＣＰＵ２２００、ディスプレイ２３００、キーボード２４００、システムバス２５００、１次記憶装置２６００、および２次記憶装置２７００を備えて構成される。

通信制御装置２１００は、ＣＰＵ２２００の指示に従いネットワーク１６００上のメッセージを送受信する。ディスプレイ２３００およびキーボード２４００は、管理者がセットアップを行う際に使用する。１次記憶装置２６００にはサービス実行処理部１５１１、リソース監視エージェント１５１３およびＯＳ（Operating System）２６０１が格納され、ＣＰＵ２２００によって実行される。２次記憶装置２７００は、１次記憶装置２６００に格納されたプログラムが使用するデータが格納され、ＣＰＵ２２００の指示に従って情報の読み出しおよび格納を行う。

サービス実行処理部１５１１は、当該処理部に実装されているサービスを実行する。サービスは、ビジネスプロセス実行装置１１００の後記するビジネスプロセス実行処理部１１１０からの呼び出しに応じて応答を返す処理を実行する。ビジネスプロセス実行処理部１１１０から、サービス実行処理部１５１１を呼び出す処理、およびサービス実行処理部１５１１からビジネスプロセス実行処理部１１１０へ応答を返す処理とは、ネットワーク１６００およびビジネスプロセス・サービス間中継装置１３００を介したメッセージのやり取りを行うことであり、ＨＴＴＰ(Hyper Text Transfer Protocol)や、ＳＯＡＰ(Simple Object Access Protocol)などを使って行われる。なお、サービス実行処理部１５１１に実装されているサービスの処理内容は、サービス実行装置（１５１０〜１５４０）の種類に応じて設定される。

また、サービスを実行する処理とは、前記したサービスの呼び出しに応じた処理を実行し、応答に必要な情報を抽出する処理である。サービスの一例として、ある製品名を指定して当該製品の残りの在庫量を要求する呼び出しに応じて、指定された製品の残りの在庫量を計算し、応答として残りの在庫数を返すという機能を持つ、在庫照会サービスなどが考えられる。このサービスの例における呼び出しに応じた処理とは、呼び出された際に受け取った製品名を使って当該製品の残りの在庫量を取得する処理に相当する。

リソース監視エージェント１５１３は、サービス実行装置１５１０のＣＰＵ利用率を監視し、値を記憶する。当該ＣＰＵ利用率の値は、後記するリソース監視部１４１１から定期的に読み出される。サービス実行処理部１５１１およびリソース監視エージェント１５１３は、ＣＰＵによって実行されるプログラムとして実装される。

なお、本実施形態では、サービス実行装置群（１５１０〜１５４０）は、それぞれ別個のサーバとして示したが、各サービス実行装置は、１台のサーバ上で実行されるプログラムとして具現される仮想的な装置であっても構わない。また、サービス実行処理部１５１１およびリソース監視エージェント１５１３をハードウェア（集積回路チップ等）で実装する構成とすることもできる。

（リソース管理装置）
次に、リソース管理装置１４００について説明する。ここで、図３は、本実施形態におけるリソース管理装置１４００の装置構成例を示す図面である。リソース管理装置１４００は、通信制御装置２１１０、ＣＰＵ２２１０、ディスプレイ２３１０、キーボード２４１０、システムバス２５１０、１次記憶装置２６１０、および２次記憶装置２７１０を備えて構成される。

通信制御装置２１１０は、ＣＰＵ２２１０の指示に従いネットワーク１６００上のメッセージを送受信する。ディスプレイ２３１０およびキーボード２４１０は、管理者がセットアップを行う際に使用する。１次記憶装置２６１０にはリソース管理処理部１４１０およびＯＳ２６１１が格納され、ＣＰＵ２２１０によって実行される。２次記憶装置２７１０は、リソース管理テーブル１４２１が格納され、ＣＰＵ２２１０の指示に従って情報の読み出しおよび格納を行う。また、リソース管理処理部１４１０は、リソース監視部１４１１とリソース構成管理部１４１２とを内包して構成される。
本実施形態では、リソース管理処理部１４１０は、プログラムとして実装されることとしたが、ハードウェアとして実装することもできる。

リソース監視部１４１１は、定期的に、サービス実行装置（１５１０〜１５４０）のリソース監視エージェント（１５１３〜１５４３）から、サービス実行装置（１５１０〜１５４０）のＣＰＵ利用率を収集し、サービス実行装置（１５１０〜１５４０）のＣＰＵ利用率のうちいずれかが、８０％を超過していた場合に、ビジネスプロセス・サービス間中継装置１３００を介してビジネスプロセス運用管理装置１２００に、サービス実行装置（１５１０〜１５４０）において負荷の増大が発生したことを示す負荷増大イベントを送信する。

リソース構成管理部１４１２は、ビジネスプロセス運用管理装置１２００がビジネスプロセス・サービス間中継装置１３００を介して送信するサーバ追加要求に従って、指定されたサービス実行装置（１５１０〜１５４０）のいずれかへのサーバ追加（リソースの追加）を実行する。

リソース管理テーブル１４２１には、リソースの構成情報と負荷情報を保持する。ここで、図４は、本実施形態におけるリソース管理テーブル１４２１に保持される情報の例を示す図面である。リソース管理テーブル１４２１には、「リソース名」３１００、「平均ＣＰＵ利用率」３２００、および「負荷状態」３３００の情報を保持する。「リソース名」３１００は、サービス実行装置（１５１０〜１５４０）を一意に識別するための名前であり、管理者が設定する。

また、「平均ＣＰＵ利用率」３２００は、サービス実行装置（１５１０〜１５４０）のリソース監視エージェント（１５１３〜１５４３）から収集したサービス実行装置（１５１０〜１５４０）の平均ＣＰＵ利用率であり、リソース監視部１４１１によって定期的に値が更新される。「負荷状態」３３００は、「平均ＣＰＵ利用率」３２００から決定される負荷の状態を示す値であり、「平均ＣＰＵ利用率」３２００の値が８０％以上であれば「高負荷」が、８０％未満であれば「通常」がそれぞれ設定される。なお、「負荷状態」３３００は、「平均ＣＰＵ利用率」３２００の値が更新されるタイミングと同じタイミングで更新される。

（ビジネスプロセス実行装置）
次に、ビジネスプロセス実行装置１１００について説明する。ここで、図５は、本実施形態におけるビジネスプロセス実行装置１１００の装置構成例を示す図面である。ビジネスプロセス実行装置１１００は、通信制御装置２１２０、ＣＰＵ２２２０、ディスプレイ２３２０、キーボード２４２０、システムバス２５２０、１次記憶装置２６２０、および２次記憶装置２７２０を備えて構成される。

通信制御装置２１２０は、ＣＰＵ２２２０の指示に従いネットワーク１６００上のメッセージを送受信する。ディスプレイ２３２０およびキーボード２４２０は、管理者がセットアップを行う際に使用する。１次記憶装置２６２０にはビジネスプロセス実行処理部１１１０およびＯＳ２６２１が格納され、ＣＰＵ２２２０によって実行される。２次記憶装置２７２０は、ビジネスプロセス定義格納部１１２１およびステップ単位リクエスト送受信履歴格納部１１２２が格納され、ＣＰＵ２２２０の指示に従って情報の読み出しおよび格納を行う。また、ビジネスプロセス実行処理部１１１０は、ビジネスプロセス定義読出し部１１１１、ステップ単位流量制御部１１１２およびステップ単位流量監視部１１１３を内包して構成される。本実施形態では、ビジネスプロセス実行処理部１１１０は、プログラムとして実装されることとしたが、ハードウェアとして実装することもできる。

ここでビジネスプロセスとは、２つ以上のサービスの組み合わせであり、図示しないクライアントプログラムから要求を受け付け、処理を実行する。ビジネスプロセス定義格納部１１２１には、呼び出すサービスの名称および呼び出す順序が管理者によって格納される。

ビジネスプロセス実行処理部１１１０は、リクエストを受け付けた際に、ビジネスプロセス定義読み出し部１１１１を使ってビジネスプロセスの定義情報をビジネスプロセス定義格納部１１２１から読み出し、当該定義情報に記録されているサービス群を、指定された実行順序で実行する。

例えば、定義情報に記録されているサービス群が、注文受付サービス、在庫照会サービス、出荷サービスの３つのサービスであり、この３つのサービスが３つのサービス実行装置（１５１０，１５２０，１５３０）上で稼動している場合を考える。ここで、注文受付サービス、在庫照会サービス、出荷サービスの順に実行するビジネスプロセスを、注文処理ビジネスプロセスとして定義し、ビジネスプロセス定義格納部１１２１に格納する。

ビジネスプロセス実行処理部１１１０は、前記の注文処理ビジネスプロセスに対するリクエストを受け付けると、ビジネスプロセス定義格納部１１２１から実行順序を読み出し、読み出した実行順序に従ってサービス（各サービス実行装置（１５１０，１５２０，１５３０））を呼び出し、ビジネスプロセスを実行する。

ステップ単位流量制御部１１１２は、ビジネスプロセスの各サービス呼び出しステップからビジネスプロセス・サービス間中継装置１３００を介してサービス（各サービス実行装置（１５１０，１５２０，１５３０））へ送信されるリクエスト量を制御する。

ステップ単位流量監視部１１１３は、ビジネスプロセスの各サービス呼び出しステップから送受信されるメッセージを監視し、サービス呼び出しが正常に終了した時刻、ビジネスプロセス名および呼び出しサービス名を含む履歴情報を、ステップ単位リクエスト送受信履歴格納部１１２２に格納する。ステップ単位リクエスト送受信履歴格納部１１２２に格納された履歴情報は、ビジネスプロセス運用管理装置１２００内の処理部によって、スループットの計算に使用される。

（ビジネスプロセス・サービス間中継装置）
次に、ビジネスプロセス・サービス間中継装置１３００について説明する。ここで、図６は、本実施形態におけるビジネスプロセス・サービス間中継装置１３００の装置構成例を示す図面である。ビジネスプロセス・サービス間中継装置１３００は、通信制御装置２１３０、ＣＰＵ２２３０、ディスプレイ２３３０、キーボード２４３０、システムバス２５３０、１次記憶装置２６３０、および２次記憶装置２７３０を備えて構成される。

ビジネスプロセス・サービス間中継処理部１３１０は、サービス管理テーブル１３２１の情報を使用してビジネスプロセス実行装置１１００とサービス実行装置（１５１０〜１５４０）との間でやり取りされるメッセージ、およびビジネスプロセス運用管理装置１２００とリソース管理装置１４００との間でやり取りされるメッセージ（サーバの負荷増大を示すイベントメッセージやサーバ追加命令を伝達するためのメッセージ）を中継する。
また、本実施形態では、ビジネスプロセス・サービス間中継処理部１３１０は、プログラムとして実装した例を示したが、ハードウェアにより実装する構成であってもよい。

ここで、図７は、本実施形態におけるサービス管理テーブル１３２１に保持される情報の例を示す図面である。図７に示すように、サービス管理テーブル１３２１には、ビジネスプロセスが呼び出す「サービス名」４１００と、サービスが稼動している「稼動先リソース名」４２００との対応関係を管理するものであり、管理者が設定する。

（ビジネスプロセス運用管理装置）
次に、ビジネスプロセス運用管理装置１２００について説明する。ここで、図８は、本実施形態におけるビジネスプロセス運用管理装置１２００の装置構成を示す図面である。図８に示すように、ビジネスプロセス運用管理装置１２００は、通信制御装置２１４０、ＣＰＵ２２４０、ディスプレイ２３４０、キーボード２４４０、システムバス２５４０、１次記憶装置２６４０、および２次記憶装置２７４０を備えて構成される。

通信制御装置２１４０は、ＣＰＵ２２４０の指示に従いネットワーク１６００上のメッセージを送受信する。ディスプレイ２３４０およびキーボード２４４０は、管理者がセットアップを行う際に使用する。１次記憶装置２６４０にはビジネスプロセス運用管理処理部１２１０およびＯＳ２６４１が格納され、ＣＰＵ２２４０によって実行される。２次記憶装置２７４０は、サービス呼出ステップ管理テーブル１２２１が格納され、ＣＰＵ２２４０の指示に従って情報の読み出しおよび格納を行う。

１次記憶装置２６４０に格納されるビジネスプロセス運用管理処理部１２１０は、サービス呼出ステップ管理部１２１１および負荷増大対処決定部１２１２を内包している。サービス呼出ステップ管理部１２１１は、サービス呼出ステップ管理テーブル１２２１に格納された情報に基づいて、各ビジネスプロセスの構成や状況をサービス呼出ステップ単位で管理する。

ここで、図９は、サービス呼出ステップ管理テーブル１２２１に格納される情報の例を示す図面である。サービス呼出ステップ管理テーブル１２２１の「ビジネスプロセス名」５１００、「呼び出しサービス名」５２００および「呼び出し順序」５３００の値は、管理者がビジネスプロセス実行装置１１００のビジネスプロセス定義格納部１１２１に格納されているビジネスプロセスの定義情報をもとに入力する。また、「スループット」５４００は、サービス呼出ステップ管理部１２１１が、ビジネスプロセス実行装置１１００のステップ単位リクエスト送受信履歴格納部１１２２の情報を元に計算した値を格納する。さらに、「スループット」５４００の値は、ビジネスプロセス実行装置１１００のステップ単位リクエスト送受信履歴格納部に格納された履歴情報に含まれる、各サービス呼び出しステップからのサービス呼出が正常に終了した回数を、１分間ごとに計算することによって算出される。

また、「ステップの状態」５５００に格納されている値は、各サービス呼出しステップの状態を表す。この「ステップの状態」５５００に格納されている値は、各「ステップの呼び出し順序」５３００と「スループット」５４００との比較結果から、「通常」、「ボトルネック」、「流量制限可能」の３つの値のいずれかに決定される。

ここで、「ボトルネック」は、ビジネスプロセスの処理のボトルネックである状態を示す値であり、当該ステップのスループットが向上すればビジネスプロセスのスループットが向上することが見込めるステップであることを示している。
また、「流量制限可能」は、当該ステップのスループットをある値まで低下させてもビジネスプロセスのスループットには影響を与えないステップであることを示している。これらの値を決定して、サービス呼出ステップ管理テーブル１２２１に格納する処理は、前記した「スループット」５４００の値を更新した後に実行する。「ステップの状態」５５００の値を決定してサービス呼出ステップ管理テーブル１２２１に格納する処理の詳細は後記する。

負荷増大対処決定部１２１２は、リソース管理装置１４００からビジネスプロセス・サービス間中継装置１３００を介して送信されてくる「負荷増大イベント」を受け付け、サービス呼出ステップ管理テーブル１２２１の情報に基づいて、これに対する対処を決定・指示する。対処の決定・指示する処理の詳細については後記する。

（各装置の動作）
本実施形態のビジネスプロセス運用管理装置１２００の動作を、図１０、図１３に示したＰＡＤ図を用いて説明する。なお、図１０に示したＰＡＤ図は、定期的にサービス実行装置群（１５１０〜１５４０）の負荷と、ビジネスプロセス群の状況とを監視する処理である「性能監視・管理」フェーズの手順を示し、図１３に示したＰＡＤ図は、サーバの負荷増大の検知を契機としてビジネスプロセスの状況に応じて対処を決定する処理である「負荷増大対処」フェーズの手順を示している。
また、ビジネスプロセス・サービス間中継装置１３００が、リソース管理装置１４００からビジネスプロセス運用管理装置１２００へ送信する負荷増大イベントメッセージを中継する手順を、図１２に示したＰＡＤ図を用いて併せて説明する。ここで、負荷増大イベントとは、サービス実行装置（１５１０〜１５４０）の負荷が増大したという事象のことである。

（性能情報監視・管理フェーズ）
まず「性能情報監視・管理」フェーズについて説明する。ここで、図１０は、ビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理部１２１１が、定期的にビジネスプロセスの状況を更新する処理例を示すＰＡＤ図である。
具体的には、ビジネスプロセス実行装置１１００のステップ単位流量監視部１１１３が、ステップ単位リクエスト送受信履歴格納部１１２２へ出力した履歴情報に基づいて、サービス呼出ステップごとの現在のスループットをサービス呼出ステップ管理部１２１１が算出し、この算出したスループットとサービス呼出ステップの実行順序から各サービス呼出ステップの状態を決定し、この決定に対応する値をサービス呼出ステップ管理テーブル１２２１へ格納するまでの処理の流れである。

まず、ステップ６００１では、ビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理部１２１１が、ステップ６００２からステップ６００７までの処理を一定間隔（例えば、１分間隔）で繰り返す。
そして、ステップ６００２では、サービス呼出ステップ管理部１２１１が、ビジネスプロセス実行装置１１００から、ステップ単位リクエスト送受信履歴格納部１１２２に格納された履歴情報を、ネットワーク１６００を介して受信し、すべてのビジネスプロセスの各サービス呼出ステップについて、過去１分以内にサービスの実行が正常に終了した旨を示すメッセージ受信した回数（１分間のスループット）を計算する。そして、この計算結果は、サービス呼出ステップ管理テーブル１２２１の各サービス呼出ステップに対応するレコードの「スループット」５４００に格納する。なお、スループットを計測する時間間隔は、任意に変更可能である。

次に、ステップ６００３では、サービス呼出ステップ管理部１２１１は、サービス呼出ステップ管理テーブル１２２１（図９参照）から、同じ「ビジネスプロセス名」５１００の値を有するレコードを抽出し、この抽出したレコードごとに、すべてのビジネスプロセスについて、後記するステップ６００４からステップ６００７の処理を繰り返す。
そして、ステップ６００４では、ステップ６００３で抽出したレコードから、同一ビジネスプロセスのレコードのうち、「スループット」５４００の値が一番低いレコードを抽出する。このとき、一番低い「スループット」５４００の値をもつレコードが複数ある場合には、それらすべて抽出する。

次に、ステップ６００５では、ステップ６００４で抽出した一番スループットが低いレコードのうち、「呼び出し順序」５３００の値が一番小さいサービス呼出ステップ、すなわち実行順序が一番早いサービス呼出ステップを抽出し、この抽出したサービス呼出ステップの「ステップの状態」５５００の値を「ボトルネック」に更新する。この更新した「ステップの状態」５５００の値は、サービス呼出ステップ管理テーブル１２２１に格納される。

次に、ステップ６００６では、サービス呼出ステップ管理部１２１１が、サービス呼出ステップ管理テーブル１２２１において、同一の「ビジネスプロセス名」５１００の値を有するすべてのレコードのうち、ステップ６００５で決定した「ボトルネック」状態のレコードの「呼び出し順序」５３００の値より小さい「呼び出し順序」５３００の値を持つ、すなわち、「ボトルネック」状態のサービス呼出ステップよりも実行順序の早いすべてのレコードの「ステップの状態」５５００の値を、「流量制限可能」に更新し、この値をサービス呼出ステップ管理テーブル１２２１に格納する。

そして、ステップ６００７では、サービス呼出ステップ管理テーブル１２２１において、同一の「ビジネスプロセス名」５１００の値を有するレコードのうち、ステップ６００５で決定した「ボトルネック」状態のレコードの「呼び出し順序」５３００の値より大きい「呼び出し順序」５３００の値を持つ、すなわち、「ボトルネック」状態のサービス呼出ステップよりも実行順序の遅いすべてのレコードの「ステップの状態」５５００の値を、「通常」に更新し、この値をサービス呼出ステップ管理テーブル１２２１に格納する。

以上、図１０に示した処理手順を実行することによってビジネスプロセスの各サービス呼び出しステップが、そのビジネスプロセスにおける「ボトルネックの」状態であるのか、後記する適切な流量まで流量制限を実施してもビジネスプロセスのスループットに影響を与えない「流量制限可能」状態であるのか、または「通常」の状態であるのか、をサービス呼出ステップ管理テーブル１２２１で管理することができる。

また、図１０に示した処理手順を通して更新されたサービス呼出ステップ管理テーブル１２２１に格納された情報は、必要に応じて、電子ファイルや、図示しないプリンタなどを用いて印字出力したり、ディスプレイの表示される表示画面として出力することもできる。ここで、図１１は、サービス呼出ステップ管理テーブル１２２１に格納された情報を表示するビジネスプロセス実行状態表示画面の例を示す図面である。図１１に示したビジネスプロセス実行状態表示画面５００１では、図９に示したサービス呼出ステップ管理テーブル１２２１に格納された情報が表示されていることがわかる。

このビジネスプロセス実行状態表示画面５００１を参照することで、当該ビジネスプロセス実行環境の管理者は、ビジネスプロセス実行装置１１００において実行されるビジネスプロセスにおいて、どのサービス呼出ステップがスループットのボトルネックとなっているかを確認することができ、この情報に基づいてサーバ等のリソースの増強計画を立案することができる。また、ビジネスプロセスのスループットが停滞した場合の対処を迅速に行うこともできる。

（負荷増大イベントの通知）
次に、リソース管理装置１４００のリソース監視部１４１１が、サービス実行装置（１５１０〜１５４０）の負荷を定期的に監視し、負荷の高いサービス実行装置（１５１０〜１５４０）があることを検出した際に、負荷増大イベントを送信する処理について説明する。
リソース監視部１４１１は、定期的に、リソース監視エージェント（１５１３〜１５４３）から各サービス実行装置（１５１０〜１５４０）の平均ＣＰＵ利用率を収集してリソース管理テーブル１４２１（図４参照）の「平均ＣＰＵ利用率」３２００に値を格納し、平均ＣＰＵ利用率の値が８０％未満であるサービス実行装置に対応するレコードでは、負荷が「通常」状態であることを示す「通常」を「負荷状態」３３００に格納し、８０％以上であるサービス実行装置（１５１０〜１５４０）に対応するレコードでは、高負荷状態であることを示す「高負荷」を「負荷状態」３３００に格納する。高負荷状態を検知した場合は、ビジネスプロセス・サービス間中継装置１３００に、負荷の増大が発生したことを示す負荷増大イベントと、高負荷になったサービス実行装置のリソース名を送信する。

ここで、図１２は、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０が、負荷増大イベントおよび高負荷のリソース名を、リソース管理装置１４００からビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２への送信を中継する処理の流れを示すＰＡＤ図の例である。

まず、ステップ７００１では、リソース管理装置１４００のリソース監視部１４１１から、負荷増大イベントと、負荷が高くなったリソース名とを受信する。
次に、ステップ７００２では、ビジネスプロセス・サービス間中継装置１３００のサービス管理テーブル１３２１から、ステップ７００１で受信したリソース名に対応するサービス名をすべて取得する。
そして、ステップ７００３では、負荷増大イベントと、ステップ７００２で取得したサービス名を、ビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２へ送信する。

以上の手順により、ビジネスプロセス・サービス間中継装置１４００がメッセージを中継することにより、リソース管理装置１４００が送信するリソース名が、当該リソース上で稼動するサービス名に変換されてビジネスプロセス運用管理装置１２００に伝えられる。

（負荷増大対処フェーズ）
次に、「負荷増大対処」フェーズについて説明する。図１３は、ビジネスプロセス・サービス間中継装置１３００が、ビジネスプロセス運用管理装置１２００に、負荷増大イベントと、それに対応するサービス名を送信した後、ビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２がその対処を決定するまでの処理の流れを示すＰＡＤ図の例である。

まず、ステップ８００１では、図１２に示したＰＡＤ図のステップ７００３において、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０が送信した、負荷増大イベントおよび対象となるサービス名を、ビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２が受信する。

次に、ステップ８００２では、負荷増大対処決定部１２１２が、サービス呼出ステップ管理テーブル１２２１（図９参照）から、ステップ８００１で受信したサービス名と一致するすべてのレコードを取得する。
そして、ステップ８００３では、ステップ８００２で取得したレコードの「ステップの状態」５５００の値が、「ボトルネック」であるレコードが存在しない場合は（ステップ８００３でＮｏ）、そのまま処理を終了し、１つ以上存在する場合は（ステップ８００３でＹｅｓ）、ステップ８００４に進む。
なお、「ボトルネック」であるレコードが存在しない場合は、この負荷増大イベントに対して、何らかの対処を行ってもビジネスプロセスのスループットの向上は見込めないため、何も対処しないことになる。

次に、ステップ８００４では、ステップ８００２で取得したレコードに、「ステップの状態」５５００の値が、「流量制限可能」であるレコードが１つも存在しない場合は（ステップ８００４でＮｏ）、ステップ８００５に進み、１つ以上存在する場合は（ステップ８００４でＹｅｓ）、ステップ８００６に進む。
ここで、「流量制限可能」であるレコードが存在しない場合、ステップ８００５では、ビジネスプロセス・サービス間中継装置１３００に、負荷増大対処決定部１２１２が、リソースの追加を要求する情報であるリソース追加要求およびステップ８００１で受信したサービス名を送信する。

ステップ８００５において、負荷増大対処決定部１２１２が、ビジネスプロセス・サービス間中継装置１３００に、リソース追加要求とサービス名を送信した後、これを受信したビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０は、サービス管理テーブル１３２１に基づいて、受信した「サービス名」に対応する「リソース名」を抽出して１次記憶装置２６３０に記憶し、リソース管理装置１４００のリソース構成管理部１４１２に、リソース追加要求およびその対象となるリソース名を送信する。そして、前記リソース追加要求とリソース名を受信したリソース構成管理部１４１２は、受信したリソース名に対応するサービス実行装置（１５１０〜１５４０）のリソースを追加する。なお、リソースの追加手順については、公知技術を適用することができる。

一方、ステップ８００４において、「流量制限可能」であるレコードが１つ以上存在する場合に進むステップ８００６では、負荷増大対処決定部１２１２が、ステップ８００２で取得したレコードのうち、「ステップの状態」５５００の値が「流量制限可能」であるレコードの「ビジネスプロセス名」５１００および「呼び出しサービス名」５２００の値を取得する。そして、「ビジネスプロセス名」５１００の値が同一であるレコード群から、「スループット」５４００の値の最低値を取得する。
そして、ステップ８００７では、負荷増大対処決定部１２１２が、ビジネスプロセス実行装置１１００のステップ単位流量制御部１１１２に、リクエスト量の流量の制限を要求する流量制限要求と、ステップ８００６で取得した「ビジネスプロセス名」、「呼び出しサービス名」および「スループット」の最低値とを送信する。

ステップ８００７において負荷増大対処決定部１２１２が送信した、「流量制限要求」、「ビジネスプロセス名」、「呼び出しサービス名」および「スループット」を、ステップ単位流量制御部１１１２が受信し、「ビジネスプロセス名」と「呼び出しサービス名」とが一致するサービス呼出ステップが送信するリクエストの量を、受信したスループットの値まで制限する。流量の制限方法としては、例えば、１分以内に送信したリクエスト量が、ステップ８００７で受信したスループットの最低値と同じになった場合、当該１分間は、リクエストを送信せず、当該１分間が経過するまで待機させる方法が考えられる。
なお、スループットを制限する方法はこれに限定されるものではなく、様々に変更可能である。

以上の処理により、負荷増大イベントが発生した際に、対象となるサービス呼出ステップが、ビジネスプロセスにおけるボトルネックでなければ、当該負荷増大イベントに対して対処することがないため、当該ビジネスプロセスのスループットを向上させることができない無駄な対処を実行することを防止できる。

また、負荷増大イベントが発生した際に、対象となるサービス呼出ステップが、ボトルネックである場合には、当該サービス呼出ステップを提供するサービス実行装置（１５１０〜１５４０）が実行するその他のサービス呼出ステップに、流量制限可能なものがあるか否かを判定し、その他のサービス呼出ステップで流量制限できない場合にのみ、リソースを追加するため、リソースの追加を最小限に抑えることができる。

（流量制限後の動作）
流量制限を実施してもリソースが不足している場合も考えられる。このような場合には、流量制限後にリソース追加を実施することによってリソース不足を解消することができる。具体的には、流量制限を実施した場合、実施したことをサービス呼出ステップ管理テーブル１２２１に記憶し、負荷増大対処決定部１２１２がサービスの負荷増大イベントを新たに受け取った際に、当該サービスに対して既に流量制限が実施されている場合はリソース追加をすると判断することで実現できる。この、流量制限実施後、リソース不足が解消されない場合にリソース追加を実施する動作のことを、以下では「流量制限後の２次動作」と呼ぶ。
流量制限後の２次動作は、サービス呼出ステップ管理テーブル１２２１および負荷増大対処決定部１２１２を後記の構成とすることによって実現できる。

図２６は、流量制限後の２次動作を実現する際のサービス呼出ステップ管理テーブル１２２１の構成と格納する情報の例である。図２６では、図９のサービス呼出ステップ管理テーブル１２２１に比べ、流量制限中フラグ２６１００が追加されている。流量制限中フラグ２６１００は、各サービス呼出ステップが流量制限中であるか否かをＯＮ／ＯＦＦで表し、同一のサービスを呼び出すサービス呼出ステップの流量制限中フラグ２６１００の値は同一となる。流量制限中フラグ２６１００の値は、負荷増大対処決定部１２１２によって更新が行われるため、値の更新手段の詳細は後記の負荷増大対処決定部１２１２の説明にて示す。

図２７は、図１３に示す負荷増大対処処理に加え、流量制限後の２次動作を実現する際の負荷増大対処決定部１２１２が行う処理を示すＰＡＤ図である。

ステップ２７００１では、図１２に示したＰＡＤ図のステップ７００３において、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０が送信した、負荷増大イベントおよび対象となるサービス名を、ビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２が受信する。

次に、ステップ２７００２では、負荷増大対処決定部１２１２が、サービス呼出ステップ管理テーブル１２２１（図２６参照）から、ステップ２７００１で受信したサービス名と一致するすべてのレコードを取得する。

そして、ステップ２７００３では、ステップ２７００２で取得したレコードの「ステップの状態」５５００の値が、「ボトルネック」であるレコードが存在しない場合は（ステップ２７００３でＮｏ）、そのまま処理を終了し、１つ以上存在する場合は（ステップ２７００３でＹｅｓ）、ステップ２７００４に進む。

ステップ２７００４では、ステップ２７００２で取得したレコードのうち、ステップの状態５５００の値が「流量制限可能」、かつ流量制限中フラグ２６１００の値が「ＯＦＦ」のレコードが１つ以上存在する場合（ステップ２７００４でＹｅｓ）、すなわち流量制限ができるサービス呼出ステップが１つ以上存在する場合はステップ２７００９に進み、存在しない場合は（ステップ２７００４でＮｏ）、ステップ２７００５に進む。ステップ２７００５では、ビジネスプロセス・サーバ間中継装置１３００にリソース追加要求とステップ２７００１で受信したサービス名を送信する。ステップ２７００６では、ステップ２７００２で取得したレコード全ての流量制限中フラグ２６１００の値が「ＯＮ」であるか否かを判断し、「ＯＮ」である場合には（ステップ２７００６でＹｅｓ）、ステップ２７００７に進み、「ＯＮ」でない場合には（ステップ２７００６でＮｏ）、そのまま処理を終了する。ステップ２７００７では、ステップ単位流量制御部１１１２に流量制限解除要求と、ステップ２７００１で取得したサービス名を送信する。ステップ２７００８では、ステップ２７００２で取得したレコード全ての流量制限中フラグ２６１００の値を「ＯＦＦ」に更新する。

ステップ２７００９では、負荷増大対処決定部１２１２が、ステップ２７００２で取得したレコードのうち、「ステップの状態」５５００の値が「流量制限可能」であり、かつ流量制限中フラグ２６１００の値が「ＯＦＦ」であるレコードの「ビジネスプロセス名」５１００および「呼び出しサービス名」５２００の値を取得する。そして、「ビジネスプロセス名」５１００の値が同一であるレコード群から、「スループット」５４００の値の最低値を取得する。ステップ２７０１０では、ステップ単位流量制御部１１１２に流量制限要求とステップ２７００９で取得したビジネスプロセス名、呼び出しサービス名およびスループットの最低値を送信する。ステップ２７０１１では、ステップ２７００２で取得したレコード全ての流量制限中フラグ２６１００の値を「ＯＮ」に更新する。

以上の処理により、流量制限を実施してもリソース不足が解消されない場合には、リソース追加が実施される。

（動作例１）
以下では、より具体的なサービスとビジネスプロセスとを例示して本実施形態のビジネスプロセス運用管理装置１２００の動作を説明する。
まず、サービス実行装置（１５１０〜１５４０）上で行われるリソース追加がビジネスプロセスのスループット向上につながらないケースを、本実施形態のビジネスプロセス運用管理装置１２００によって回避する例を説明する。図１４は、本実施形態例で用いるビジネスプロセス実行装置およびサービス実行装置群の構成を簡略化して示したものである。なお、図１４ではいくつかの装置を省略しているが、省略している装置の構成は図１に示す装置の構成と同様である。

本実施形態例のサービス実行装置（９３１０〜９３５０）では、各サービス実行処理部（９３１１〜９３５１）において、注文受付サービス９３１２、在庫照会サービス９３２２、出荷確認サービス９３３２、決済サービス９３４２および出荷サービス９３５３がそれぞれ稼動している。これらのサービス群を組み合わせて一連の注文処理を実行する注文処理ビジネスプロセス９１００が、ビジネスプロセス実行処理部１１１０で実行されている。このような構成において、在庫照会サービス９３２２を実行するサービス実行装置９３２０のＣＰＵ負荷および決済サービス９３４２を実行するサービス実行装置９３４０のＣＰＵ負荷が高くなり、注文処理ビジネスプロセス９１００の決済サービス呼び出しステップ９１０Ｄが、何らかの理由で注文処理ビジネスプロセス９１００のボトルネックになっている状況を想定する。

ここで、図１５〜１７は、このような状況におけるリソース管理装置１４００のリソース管理テーブル１４２１、ビジネスプロセス・サービス間中継装置１３００のサービス管理テーブル１３２１、およびビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理テーブル１２２１を示す図面である。

図１５に示したリソース管理テーブル１４２１の「リソース名」３１００に格納されている値「サーバ１」、「サーバ２」、「サーバ３」、「サーバ４」および「サーバ５」は、サービス実行装置（９３１０〜９３５０）をそれぞれ特定する値である。図１５では、「リソース名」３１００の値が「サーバ２」であるレコード１５０１、および「リソース名」３１００の値が「サーバ４」であるレコード１５０２の「負荷状態」３３００の値はどちらも「高負荷」であることを表している。

ここで、まず、「サーバ２」の負荷増大イベントを送信し、対処が決定するまでの様子を説明する。図１５に示したリソース管理テーブル１４２１において、「サーバ２」に該当するレコード１５０１の「負荷状態」３３００の値が「高負荷」であることから、リソース管理装置１４００のリソース管理処理部１４１０は、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０に、負荷増大イベントとリソース名「サーバ２」を送信する。
当該イベントを受信したビジネスプロセス・サービス間中継処理部１３１０は、図１６に示すサービス管理テーブル１３２１を参照し、「稼動先リソース名」４２００の値が、「サーバ２」であるレコード１６０１を探し当て、当該レコードの「サービス名」４１００の値「在庫照会」を取得する。

ビジネスプロセス・サービス間中継処理部１３１０は、負荷増大イベントと、前記取得した「サービス名」４１００の値「在庫照会」を、ビジネスプロセス運用管理装置１２００のビジネスプロセス運用管理処理部１２１０へ送信する。
負荷増大イベントとサービス名とを受信したビジネスプロセス運用管理処理部１２１０は、図１７に示すサービス呼出ステップ管理テーブル１２２１から、「呼び出しサービス名」５２００の値が「在庫照会」であるレコード１７０１を探し当て、当該レコードの「ステップの状態」５５００の値「流量制限可能」を取得する。この、ビジネスプロセス運用管理処理部１２１０がイベントを受信した処理と、サービス呼出ステップ管理テーブル１２２１から「流量制限可能」の値を取得した処理は、図１３に示した負荷増大イベントに対する対処を決定するフローのステップ８００１およびステップ８００２に相当する。

ステップ８００３では、サービス呼出ステップ管理テーブル１２２１（図１７参照）から取得した「ステップの状態」５５００の値に、「ボトルネック」があるか否かを判定し、判定結果に応じて分岐する。この場合は、取得した値が「流量制限可能」であるため、当該負荷増大イベントに対する対処決定の処理フローは終了する。すなわち、サーバ２すなわちサービス実行装置１５２０で発生した負荷増大イベントに対して、何も対処を行わないということである。
これは、注文処理ビジネスプロセス９１００において、処理のボトルネックはサーバ２で稼動する在庫照会サービス９３２２ではないため、リソース追加を実施しても注文処理ビジネスプロセス９１００のスループット向上は見込めないという判断である。これによって、不必要なリソース追加を抑え、リソースを節約することができる。

次に、サーバ４の負荷増大イベントを送信し、対処が決定するまでの手順を説明する。前記したように図１５からサーバ４に該当するレコード１５０２の負荷状態３３００の値が「高負荷」であることから、リソース管理処理部１４１０からビジネスプロセス・サービス間中継処理部１３１０へ負荷増大イベントとリソース名「サーバ４」とを送信する。
負荷増大イベントとリソース名「サーバ４」とを受信したビジネスプロセス・サービス間中継処理部１３１０は、図１６に示すサービス管理テーブル１３２１を参照し、稼動先リソース名４２００の値が「サーバ４」であるレコード１６０２を探し当て、当該レコードのサービス名４１００の値「決済」を取得する。
ビジネスプロセス・サービス間中継処理部１３１０は、負荷増大イベントと、前記取得した「サービス名」４１００の値「決済」を、ビジネスプロセス運用管理処理部１２１０へ送信する。

負荷増大イベントとサービス名を受信したビジネスプロセス運用管理処理部１２１０は、図１７に示すサービス呼出ステップ管理テーブル１２２１から「呼び出しサービス名」５２００の値が「決済」であるレコード１７０２を探し当て、当該レコードの「ステップの状態」５５００の値「ボトルネック」を取得する。
このイベントを受信した処理と、サービス呼出ステップ管理テーブル１２２１から、「ボトルネック」の値を取得した処理は、図１３の負荷増大イベントに対する対処を決定するフローのステップ８００１およびステップ８００２に相当する。以下、図１３参照のこと。

次に、ステップ８００３では、サービス呼出ステップ管理テーブル１２２１から取得した「ステップの状態」５５００の値に、「ボトルネック」があるか否かを判定し、判定結果に応じて分岐する。この場合は、取得した値が「ボトルネック」であるため、ステップ８００４に進む。
そして、ステップ８００４では、サービス呼出ステップ管理テーブル１２２１から取得した値に「流量制限可能」があるか否かを判定し、判定結果に応じて分岐する。この場合は、取得した値が「ボトルネック」であるため、ステップ８００５に進む。

次に、ステップ８００５では、負荷増大対処決定部１２１２が、ビジネスプロセス・サービス間中継装置１３００に、リソース追加要求とサービス名「決済」を送信し、これに応じてビジネスプロセス・サービス間中継装置１３００は、サーバ４（サービス実行装置９３４０）にリソース追加を実施する。これは、注文処理ビジネスプロセス９１００において、処理のボトルネックはサーバ４で稼動する決済サービス９３４２であり、リソース追加の実施によって注文処理ビジネスプロセス９１００のスループット向上が見込めると判断したということである。

以上のように、リソース追加の可否を、ビジネスプロセスの各サービス呼出ステップの状況を表すサービス呼出ステップ管理テーブル１２２１を使って判断することにより、不要なリソース追加が抑止できるという効果を奏することができる。

（動作例２）
次に、前記のケースのように、ビジネスプロセスのスループット向上につながらないサービス呼出ステップが存在する場合に、当該サービス呼出ステップがリソースを必要以上に消費することにより、他のビジネスプロセスのスループットに影響を与えることを回避できることを、具体例を用いて説明する。図１８は、本実施形態例の説明で用いるビジネスプロセス実行装置およびサービス実行装置群の構成を簡略化して示したものである。図１８は、前記の第１実施形態例で示した図１４の構成に、要求受付サービス１８３６２、在庫集計サービス１８３７２、結果報告サービス１８３８２を実行するサービス実行装置（１８３６０〜１８３９０）が追加されている。さらに、ビジネスプロセス実行装置１１００で実行されるビジネスプロセスとして、要求受付サービス１８３６２、在庫集計サービス１８３７２、結果報告サービス１８３８２と、注文処理ビジネスプロセス９１００と共用する在庫照会サービス９３２２を組み合わせて、一連の在庫集計処理を実行する在庫集計ビジネスプロセス１８２００が追加されている。
なお、図１８ではいくつかの装置を省略しているが、省略している装置の構成は図１の装置の構成と同様である。

図１８に示した構成において、在庫照会サービス９３２２を実行するサービス実行装置９３２０のＣＰＵ負荷が高く、注文処理ビジネスプロセス９１００の決済サービス呼び出しステップ９１０Ｄおよび在庫集計ビジネスプロセス１８２００の在庫照会サービス呼び出しステップ１８２０Ｂがそれぞれのビジネスプロセスのボトルネックになっている状況を想定する。ここで、注文処理ビジネスプロセス９１００の決済サービス呼び出しステップ９１０Ｄがボトルネックとなっているため、当該サービス呼出ステップより早い順序で実行される在庫照会サービス呼出ステップ９１０Ｂは、決済サービス呼び出しステップ９１０Ｄがボトルネック状態である限り、必要以上のリクエスト量を処理してリソースを消費していることになる（つまり、流量制限可能状態にある）。このことが影響して在庫集計ビジネスプロセス１８２００の在庫照会サービス呼出ステップ１８２０Ｂが、当該ビジネスプロセスのボトルネックとなっている。

ここで、図１９、図２０は、このような状況におけるビジネスプロセス・サービス間中継装置１３００のサービス管理テーブル１３２１およびビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理テーブル１２２１の例を示す図面である。
また、この実施形態例におけるリソース管理装置１４００のリソース管理テーブル１４２１は、図４に示したリソース管理テーブル１４２１を用いることにする。図４におけるリソース管理テーブル１４２１の「リソース名」３１００に格納されている値、「サーバ１」、「サーバ２」、「サーバ３」、「サーバ４」、「サーバ５」、「サーバ６」、「サーバ７」、「サーバ８」は、サービス実行装置（９３１０〜９３５０，１８３６０〜１８３８０）を特定する値で、ここではそれぞれサービス実行装置（９３１０〜９３５０、１８３６０〜１８３９０）と対応している。
さらに、図４では、リソース名３１００の値が「サーバ２」であるレコード３００１の「負荷状態」３３００の値が、「高負荷」であることを表している。このような状況を想定して、サーバ２の負荷増大イベントが送信され、その対処が決定するまでの処理を説明する。

図４に示したリソース管理テーブル１４２１の「サーバ２」に該当するレコード３００１の「負荷状態」３３００の値が「高負荷」であることから、リソース管理装置１４００のリソース管理処理部１４１０は、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０へ負荷増大イベントとリソース名「サーバ２」とを送信する。
負荷増大イベントとリソース名とを受信したビジネスプロセス・サービス間中継処理部１３１０は、図１９に示すサービス管理テーブル１３２１を参照し、「稼動先リソース名」４２００の値が「サーバ２」であるレコード１９０１を探し当て、当該レコードの「サービス名」４１００の値「在庫照会」を取得する。そして、ビジネスプロセス・サービス間中継処理部１３１０は、負荷増大イベントと、前記取得したサービス名「在庫照会」とを、ビジネスプロセス運用管理装置１２００のビジネスプロセス運用管理処理部１２１０へ送信する。

負荷増大イベントとサービス名とを受信したビジネスプロセス運用管理処理部１２１０は、図２０に示すサービス呼出ステップ管理テーブル１２２１から「呼び出しサービス名」５２００の値が「在庫照会」であるレコード２００１およびレコード２００２を探し当て、当該レコードの「ステップの状態」５５００の値「流量制限可能」および「ボトルネック」の２つの値を取得する。
このイベントを受信した処理と、サービス呼出ステップ管理テーブル１２２１から「流量制限可能」および「ボトルネック」の値を取得した処理は、図１３の負荷増大イベントに対する対処を決定するフローのステップ８００１およびステップ８００２に相当する。以下、図１３参照のこと。

次に、ステップ８００３では、サービス呼出ステップ管理テーブル１２２１から取得した「ステップの状態」５５００の値に、「ボトルネック」があるか否かを判定し、判定結果に応じて分岐する。この場合は、取得した「ステップの状態」５５００の値が、「流量制限可能」および「ボトルネック」であり、「ボトルネック」があるため、ステップ８００４に進む。

次に、ステップ８００４では、前記サービス呼出ステップ管理テーブル１２２１から取得した「ステップの状態」５５００の値に、「流量制限可能」があるか否かを判定し、判定結果に応じて分岐する。この場合は、取得した「ステップの状態」５５００の値が「流量制限可能」および「ボトルネック」であり、「流量制限可能」があるためステップ８００６に進む。

次に、ステップ８００６およびステップ８００７では、「流量制限可能」状態である注文処理ビジネスプロセス９１００の在庫照会サービス呼出ステップ９１０Ｂのスループットを、当該ビジネスプロセスのボトルネック状態である決済サービス呼び出しステップ２００４と同じスループットまで制限する。すなわち、複数のビジネスプロセスが共有しているサービスが稼動するサーバの負荷が高くなった際、必要以上にサーバのリソースを使用しているビジネスプロセスのスループットを、当該ビジネスプロセス全体のスループットに影響がない値まで制限する。

これによって、同一のサービス呼出ステップが複数のビジネスプロセスで共有される環境において、一方のビジネスプロセスで当該サービス呼出ステップがボトルネックとなった場合に、流量調整可能と判定された他方のビジネスプロセスにおけるスループットを低減させることで、他方のビジネスプロセス全体のスループットは低減することなく、一方のビジネスプロセス全体のスループットを向上できるという効果を奏する。

［第２実施形態］
以下、本発明を適用した第２実施形態について第１実施形態と異なる点を中心に説明する。前記の第１実施形態では、サービス実行装置の負荷増大を検知した場合（負荷増大イベントの発生）における、ビジネスプロセス運用管理装置１２００の対処が「何もしない」、「流量制限を実施する」または「リソースを追加する」の３種類であったが、本実施形態では、「何も対処しない」または「リソースを追加する」の２種類とした点が大きく異なる。

本実施形態のビジネスプロセス運用管理装置１２００の構成は、第１実施形態のビジネスプロセス運用管理装置１２００の構成と比べて、サービス呼出ステップ管理テーブル１２２１に格納される情報、サービス呼出ステップ管理部１２１１および負荷増大対処決定部１２１２における処理が異なる。なお、その他の装置構成については、図１に示した第１実施形態の全体構成と同様であるため、その説明は省略する。

ここで、本実施形態におけるサービス呼出ステップ管理テーブル１２２１に格納される情報の例を図２１に示す。図２１に示すように、「ステップの状態」１０５００に格納される値は、参照符号１０００１，１０００２，１０００３および１０００５で示すレコードのように「通常」、または参照符号１０００４で示すレコードのように「ボトルネック」の２種類である。
以下、本実施形態のビジネスプロセス運用管理装置１２００の動作について説明する。

（性能情報監視・管理フェーズ）
まず、本実施形態の「性能情報監視・管理」フェーズについて説明する。ここで、図２２は、ビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理部１２１１が、定期的にビジネスプロセスの状況を更新する処理例を示すＰＡＤ図の例である。
図２２に示したＰＡＤ図において、ステップ１１００１からステップ１１００５までの処理は、図１０に示した第１実施形態のＰＡＤ図におけるステップ６００１からステップ６００５までの処理と同様であるためその説明は省略する。

次に、ステップ１１００６では、ビジネスプロセス運用管理装置１２００のサービス呼出ステップ管理部１２１１が、サービス呼出ステップ管理テーブル１２２１（図２１参照）から、ステップ１１００５で「ステップの状態」１０５００の値を「ボトルネック」に更新したレコード以外のレコードを抽出し、この抽出したレコードの「ステップの状態」１０５００の値を「通常」に更新して終了する。

ここで、例えば、ステップ１１００５で、図２１に示したサービス呼出ステップ管理テーブル１２２１の参照符号１０００４で示すレコードの「ステップの状態」１０５００の値を「ボトルネック」に更新したとすれば、ステップ１１００６では、参照符号１０００１，１０００２，１０００３および１０００５で示すレコードの「ステップの状態」１０５００の値が「通常」に更新される。
なお、図２２に示したＰＡＤ図における処理の終了後に、第１実施形態の図１１に示したビジネスプロセス実行状態表示画面６００１と同様の構成を有する表示画面をディスプレイ２３４０に表示させることもできる。この場合、表示画面に表示される情報は、図２１に示したサービス呼出ステップ管理テーブル１２２１の情報に基づいて作成される。

（負荷増大イベントの通知）
本実施形態において、ビジネスプロセス・サービス間中継装置１３００のビジネスプロセス・サービス間中継処理部１３１０が、リソース管理装置１４００からビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２へ送信するイベントを中継する処理については、図１２に示した第１実施形態における処理と同様であるため、その説明は省略する。

（負荷増大対処フェーズ）
次に、本実施形態における「負荷増大対処」フェーズについて説明する。ここで、図２３は、本実施形態において、リソース管理装置１４００のリソース監視部１４１１が、負荷増大イベントを送信した後、ビジネスプロセス運用管理装置１２００の負荷増大対処決定部１２１２によって対処を決定するまでの処理の流れを示すＰＡＤ図の例である。

図２３に示したＰＡＤ図において、ステップ１２００１およびステップ１２００２は、図１３に示した第１実施形態の負荷増大対処決定部１２１２における処理であるステップ８００１およびステップ８００２と同様であるためその説明は省略する。
次に、ステップ１２００３では、ステップ１２００２で取得した、サービス呼出ステップ管理テーブル１２２１のレコードの「ステップの状態」１０５００の値が「ボトルネック」であるレコードが存在しない場合は（ステップ１２００３でＹｅｓ）、処理を終了し、存在する場合は（ステップ１２００３でＮｏ）、ステップ１２００４に進む。そして、ステップ１２００４では、ビジネスプロセス・サービス間中継装置１３００にリソース追加要求と、ステップ１２００１で取得したサービス名とを送信して処理を終了する。

ステップ１２００４において送信された、リソース追加要求およびサービス名を受信したビジネスプロセス・サービス間中継装置１３００は、サービス名を対応するリソース名に変換し、リソース構成管理部１４１２へリソース追加要求とリソース名を送信する。前記リソース追加要求とリソース名を受信したリソース構成管理部１４１２は受信したリソース名に対応するサービス実行装置（１５１０〜１５４０）のリソースを追加する。

ここで、例えば、ステップ１２００２で、図２１に示したサービス呼出ステップ管理テーブル１２２１の参照符号１０００４で示すレコードを取得したとすると、ステップ１２００３では、このレコードの「ステップの状態」１０５００の値が「ボトルネック」であるため、ステップ１２００４に進み、リソース追加要求と、このレコードのサービス名「Ｄ」とを送信することになる。

以上、説明した本実施形態に係るビジネスプロセス運用管理装置１２００によると、ビジネスプロセスにおいて、スループット向上のためのボトルネックとなっているリソースにのみ、リソースの追加を行うことができ、無駄なリソースの追加を防止することができる。また、第１実施形態と比べて、サービス実行装置においてスループットを調整する処理がないため、より汎用的な環境に本発明を適用することができる。

ビジネスプロセス実行環境のシステム構成図である。 サービス実行装置の装置構成を示す図面である。 リソース管理装置の装置構成を示す図面である。 リソース管理テーブルに保持される情報を示す図面である。 ビジネスプロセス実行装置の装置構成を示す図面である。 ビジネスプロセス・サービス間中継装置の装置構成を示す図面である。 サービス管理テーブルに保持される情報を示す図面である。 ビジネスプロセス運用管理装置の装置構成を示す図面である。 サービス呼出ステップ管理テーブルに格納される情報を示す図面である。 定期的にサービス実行装置群の負荷と、ビジネスプロセス群の状況とを監視する処理である「性能監視・管理」フェーズの手順を示すＰＡＤ図である。 ビジネスプロセス実行状態表示画面を示す図面である。 負荷増大イベントの通知を、ビジネスプロセス運用管理装置に送信する手順を示すＰＡＤ図である。 サーバの負荷増大の検知を契機としてビジネスプロセスの状況に応じて対処を決定する処理である「負荷増大対処」フェーズの手順を示すＰＡＤ図である。 ビジネスプロセス実行装置およびサービス実行装置群の構成を簡略化して示した図面である。 リソース管理テーブルに保持される情報を示す図面である。 サービス管理テーブルに保持される情報を示す図面である。 サービス呼出ステップ管理テーブルに保持される情報を示す図面である。 ビジネスプロセス実行装置およびサービス実行装置群の構成を簡略化して示した図面である。 サービス管理テーブルに保持される情報を示す図面である。 サービス呼出ステップ管理テーブルに保持される情報を示す図面である。 サービス呼出ステップ管理テーブルに保持される情報を示す図面である。 ビジネスプロセス運用管理装置のサービス呼出ステップ管理部が、定期的にビジネスプロセスの状況を更新する手順を示すＰＡＤ図である。 ビジネスプロセス運用管理装置の負荷増大対処決定部によって負荷増大イベントに対する対処を決定する手順を示すＰＡＤ図である。 リソースの追加として、追加用の空きサーバの割り当てが行われようとしている状況を説明する図面である。 図２４に示した状態で、ビジネスプロセスＢが実行され、ビジネスプロセスＡおよびビジネスプロセスＢがサービスＢを共有している状況を説明する図面である。 図９のサービス呼出ステップ管理テーブルに、流量制限による効果が不十分であった場合にリソース追加を実施するケースに対応するためのカラムが追加された図面である。 図１３の対処決定処理に加え、流量制限による効果が不十分であった場合にリソース追加を実施するケースに対応するための処理が追加されたＰＡＤ図である。

符号の説明

１１００ ビジネスプロセス実行装置
１２００ ビジネスプロセス運用管理装置
１２１０ ビジネスプロセス運用管理処理部
１２１１ サービス呼出ステップ管理部
１２１２ 負荷増大対処決定部
１２２１ サービス呼出ステップ管理テーブル
１５１０，１５２０，１５３０，１５４０ サービス実行装置
１６００ ネットワーク

Claims (17)

1. 所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムであって、
   前記プロセス運用管理装置は、
   前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットを少なくとも保持したサービス呼出ステップ管理テーブルを格納した記憶部と、
   前記サービス呼出ステップ管理テーブルから、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出し、
   この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、スループットを制限できる状態であるか、またはそれら以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理テーブルに記憶するサービス呼出ステップ管理部と、
   前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得すると、
   前記サービス呼出ステップ管理テーブルから、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定し、
   ボトルネックの状態であれば、前記アプリケーションサーバ上のサービス実行処理部を呼び出している他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外の状態があるか否かを判定し、ボトルネック以外の状態が無い場合には、当該アプリケーションサーバに対するリソースの追加を決定し、
   他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合には、他のプロセスのサービス呼出ステップのスループットを制限する決定をする負荷増大対処決定部とを備える
   ことを特徴とするビジネスプロセス運用管理システム。
2. 所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムであって、
   前記プロセス運用管理装置は、
   前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットを少なくとも保持したサービス呼出ステップ管理テーブルを格納した記憶部と、
   前記サービス呼出ステップ管理テーブルから、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出し、
   この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、またはそれ以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理テーブルに記憶するサービス呼出ステップ管理部と、
   前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得すると、
   前記サービス呼出ステップ管理テーブルから、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定し、
   ボトルネックの状態であれば、当該アプリケーションサーバに対するリソースの追加を決定する負荷増大対処決定部とを備える
   ことを特徴とするビジネスプロセス運用管理システム。
3. 前記プロセス運用管理装置は、
   前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記サービス呼出ステップ管理テーブルから、前記スループットを制限できる状態であるサービス呼出ステップと同一のプロセスで、かつボトルネックの状態であるサービス呼出ステップのスループットを抽出し、
   前記スループットを制限できる状態であるサービス呼出ステップのスループットを、前記抽出したボトルネックの状態のサービス呼出ステップのスループットまで制限することを決定する
   ことを特徴とする請求項１に記載のビジネスプロセス運用管理システム。
4. 前記プロセス運用管理装置は、
   前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記スループットを制限できる状態であるサービス呼出ステップのスループットを、所定値まで制限することを決定する
   ことを特徴とする請求項１に記載のビジネスプロセス運用管理システム。
5. 前記アプリケーションサーバは、１つのサーバ装置内で実行される仮想的な１以上のサーバである
   ことを特徴とする請求項１ないし請求項４のいずれか１項に記載のビジネスプロセス運用管理システム。
6. 所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムにおけるビジネスプロセス運用管理方法であって、
   前記プロセス運用管理装置において、
   前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットをサービス呼出ステップ管理記憶手段に格納し、
   前記サービス呼出ステップ管理記憶手段から、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出し、
   この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、スループットを制限できる状態であるか、またはそれら以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理記憶手段に記憶し、
   前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得すると、
   前記サービス呼出ステップ管理記憶手段から、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定し、
   ボトルネックの状態であれば、前記アプリケーションサーバ上のサービス実行処理部を呼び出している他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外の状態があるか否かを判定し、ボトルネック以外の状態が無い場合には、当該アプリケーションサーバに対するリソースの追加を決定し、
   他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合には、他のプロセスのサービス呼出ステップのスループットを制限する決定をするように実行する
   ことを特徴とするビジネスプロセス運用管理方法。
7. 前記プロセス運用管理装置において、
   前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記サービス呼出ステップ管理記憶手段から、前記スループットを制限できる状態であるサービス呼出ステップと同一のプロセスで、かつボトルネックの状態であるサービス呼出ステップのスループットを抽出し、
   前記スループットを制限できる状態であるサービス呼出ステップのスループットを、前記抽出したボトルネックの状態のサービス呼出ステップのスループットまで制限することを決定するように実行する
   ことを特徴とする請求項６に記載のビジネスプロセス運用管理方法。
8. 前記プロセス運用管理装置において、
   前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記スループットを制限できる状態であるサービス呼出ステップのスループットを、所定値まで制限することを決定するように実行する
   ことを特徴とする請求項６に記載のビジネスプロセス運用管理方法。
9. 前記アプリケーションサーバは、１つのサーバ装置内で実行される仮想的な１以上のサーバである
   ことを特徴とする請求項６ないし請求項８のいずれか１項に記載のビジネスプロセス運用管理方法。
10. 所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムに用いられる前記プロセス運用管理装置であって、
    前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットを少なくとも保持したサービス呼出ステップ管理テーブルを格納した記憶部と、
    前記サービス呼出ステップ管理テーブルから、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出し、
    この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、スループットを制限できる状態であるか、またはそれら以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理テーブルに記憶するサービス呼出ステップ管理部と、
    前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得すると、
    前記サービス呼出ステップ管理テーブルから、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定し、
    ボトルネックの状態であれば、前記アプリケーションサーバ上のサービス実行処理部を呼び出している他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外の状態があるか否かを判定し、ボトルネック以外の状態が無い場合には、当該アプリケーションサーバに対するリソースの追加を決定し、
    他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合には、他のプロセスのサービス呼出ステップのスループットを制限する決定をする負荷増大対処決定部とを備える
    ことを特徴とするプロセス運用管理装置。
11. 前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記サービス呼出ステップ管理テーブルから、前記スループットを制限できる状態であるサービス呼出ステップと同一のプロセスで、かつボトルネックの状態であるサービス呼出ステップのスループットを抽出し、
    前記スループットを制限できる状態であるサービス呼出ステップのスループットを、前記抽出したボトルネックの状態のサービス呼出ステップのスループットまで制限することを決定する
    ことを特徴とする請求項１０に記載のプロセス運用管理装置。
12. 前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記スループットを制限できる状態であるサービス呼出ステップのスループットを、所定値まで制限することを決定する
    ことを特徴とする請求項１０に記載のプロセス運用管理装置。
13. 前記アプリケーションサーバは、１つのサーバ装置内で実行される仮想的な１以上のサーバである
    ことを特徴とする請求項１０ないし請求項１２のいずれか１項に記載のプロセス運用管理装置。
14. 所定のサービスを提供する機能を有するサービス実行処理部を備える複数のアプリケーションサーバと、前記サービス実行処理部を呼び出して利用するサービス呼出ステップから構成されたプロセスを実行するプロセス実行処理部を備えるプロセス実行装置と、前記プロセス実行時の前記サービス呼出ステップの処理状況を判定するプロセス運用管理装置とを、ネットワークを介して相互に接続して構成されるビジネスプロセス運用管理システムに用いられる前記プロセス運用管理装置のプログラムであって、
    前記プログラムは、前記プロセス運用管理装置のコンピュータに、
    前記プロセスごとに、当該プロセスで実行される前記サービス呼出ステップに対応した当該プロセスにおける実行順序および当該サービス呼出ステップのスループットをサービス呼出ステップ管理記憶手段に格納する処理と、
    前記サービス呼出ステップ管理記憶手段から、前記プロセスごとに前記サービス呼出ステップについてのスループットおよび実行順序を抽出する処理と、
    この抽出したスループットおよび実行順序から、前記プロセスにおけるサービス呼出ステップの状態を、ボトルネックの状態であるか、スループットを制限できる状態であるか、またはそれら以外の状態であるかを決定して、それぞれ前記サービス呼出ステップ管理記憶手段に記憶する処理と、
    前記ネットワークを介して、前記アプリケーションサーバの負荷が増大したことを示す情報を取得する処理と、
    前記サービス呼出ステップ管理記憶手段から、負荷が増大したアプリケーションサーバ上のサービス実行処理部を呼び出しているサービス呼出ステップの状態を抽出し、この抽出した状態がボトルネックの状態であるか否かを判定する処理と、
    ボトルネックの状態であれば、前記アプリケーションサーバ上のサービス実行処理部を呼び出している他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外の状態があるか否かを判定し、ボトルネック以外の状態が無い場合には、当該アプリケーションサーバに対するリソースの追加を決定する処理と、
    他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合には、他のプロセスのサービス呼出ステップのスループットを制限する決定をする処理と、
    を実行させることを特徴とするプロセス運用管理装置のプログラム。
15. 前記プログラムは、前記プロセス運用管理装置のコンピュータに、
    前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記サービス呼出ステップ管理記憶手段から、前記スループットを制限できる状態であるサービス呼出ステップと同一のプロセスで、かつボトルネックの状態であるサービス呼出ステップのスループットを抽出する処理と、
    前記スループットを制限できる状態であるサービス呼出ステップのスループットを、前記抽出したボトルネックの状態のサービス呼出ステップのスループットまで制限することを決定する処理と、
    を実行させることを特徴とする請求項１４に記載のプロセス運用管理装置のプログラム。
16. 前記プログラムは、前記プロセス運用管理装置のコンピュータに、
    前記他のプロセスにおけるサービス呼出ステップの状態においてボトルネック以外でスループットを制限できる状態がある場合に、前記スループットを制限できる状態であるサービス呼出ステップのスループットを、所定値まで制限することを決定する処理と、
    を実行させることを特徴とする請求項１４に記載のプロセス運用管理装置のプログラム。
17. 前記アプリケーションサーバは、１つのサーバ装置内で実行される仮想的な１以上のサーバである
    ことを特徴とする請求項１４ないし請求項１６のいずれか１項に記載のプロセス運用管理装置のプログラム。

Images