JP5493031B1 - 端末装置、シナリオ実行制御方法、及びプログラム - Google Patents

Abstract

【課題】端末装置が自動化ツールを実行することにより業務システム等における操作を自動的に行う環境において、業務システムや端末装置等の機器に過度の負荷がかからないようにするための技術を提供する。
【解決手段】アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置において、アプリケーションプログラムを実行するサーバの負荷情報を取得し、当該負荷情報を解析し、当該負荷情報が所定の条件を満たすか否かを判定する解析部と、前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部とを備える。
【選択図】図１

Description

本発明は、業務システム等に対する操作を端末装置において自動的に行う自動化ツールを使用する環境において、業務システムや端末装置の負荷を軽減させる技術に関するものである。

業務システムにおいて、ユーザが端末装置から当該業務システムを操作できるようにコマンドラインによるインターフェース（ＣＬＩ）が設けられることの他に、より直感的に業務システムを操作できるように、グラフィカルユーザインターフェース（ＧＵＩ）が開発されるのが一般的である。

ＧＵＩを用いても、多量の業務を人間が行うとすると、多大な稼働が必要になる。そこで、ＧＵＩ上における人間の操作をエミュレートして、業務を自動化するソフトウェア（以下、「自動化ツール」）が提案されている。

例えば、ＮＴＴ研究所により、自動化ツール「ＵＭＳ」が開発されている。このツールは、アプリケーションプログラムのユーザインターフェースと、キーボード・マウス等の入出力デバイスとの間にアダプタを介在させ、当該アダプタからコマンドを実行したり、アプリケーションプログラムの出力結果を取得したりすることを可能としている（特許文献１、非特許文献１参照）。

自動化ツールにより、定型的なＧＵＩ操作を、人手を介さずに、高速かつ正確に実行することが可能である。

特開２０１０−２０４８４０号公報

「オペレータの操作を自動化するソフトウェア『ＵＭＳ』」、ＮＴＴ技術ジャーナル、２０１１．５

業務システムは、通常、端末装置におけるＧＵＩを人間が操作するスピードを前提として設計される。具体的には、同時に操作する人間の数や単位時間あたりの処理量の見込みから、それを許容できるような仕様が決定される。

ここで、端末装置において自動化ツールを実行すると、人間による通常の操作と比べて遙かに高速な操作が行われ、業務システムや端末装置の側に想定外の負荷がかかるおそれがある。

特に、前記従来技術のようにアダプタを備える自動化ツールを用いる場合、業務システムの側からＧＵＩ上の操作が人間によるものか自動化ツールによるものか判別するのは困難であるため、有効な対処を講じることはできない。

本発明は、上記の点に鑑みてなされたものであり、端末装置が自動化ツールを実行することにより業務システム等における操作を自動的に行う環境において、業務システムや端末装置等の機器に過度の負荷がかからないようにするための技術を提供することを目的とする。

上記の課題を解決するために、本発明は、アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
アプリケーションプログラムを実行するサーバの負荷情報を取得し、当該負荷情報を解析し、当該負荷情報が所定の条件を満たすか否かを判定する解析部と、
前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部とを備えることを特徴とする端末装置として構成される。

また、本発明は、アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
アプリケーションプログラムのＧＵＩを表示する前記端末装置の負荷情報を取得し、当該負荷情報を解析し、当該負荷情報が所定の条件を満たすか否かを判定する解析部と、
前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部とを備えることを特徴とする端末装置として構成することもできる。

また、本発明は、アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
前記端末装置により実行された各ノードの処理時間を解析し、当該処理時間が所定の条件を満たすか否かを判定する解析部と、
前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部とを備えることを特徴とする端末装置として構成することもできる。

また、本発明は、前記端末装置により実行されるシナリオ実行制御方法、及び、コンピュータを、前記端末装置の各部として機能させるためのプログラムとして構成することもできる。

本発明によれば、端末装置が自動化ツールを実行することにより業務システム等における操作を自動的に行う環境において、業務システムや端末装置等の機器に過度の負荷がかからないようにすることができ、自動化ツールを安定して動作させることができる。

本発明の実施の形態に係るシステム構成図である。 シナリオの例を示す図である。 過負荷状態検出時のシステムの動作手順を示すフローチャートである。 サーバ負荷低減処理の例を示す図である。 変形例における過負荷状態検出時のシステムの動作手順を示すフローチャートである。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

本実施の形態では、自動化ツールを実行する端末装置の側において、業務システムを構成するアプリケーションサーバや端末装置自身等の機器の負荷状況を逐次監視し、各機器の負荷が許容レベルを超えないように、自動化ツールの実行速度等を制御する。以下、本実施の形態についてより詳細に説明する。

（システム構成）
図１に、本発明の実施の形態におけるシステムの構成図を示す。図１に示すように、本実施の形態のシステムは、端末装置１００とアプリケーションサーバ２００とが通信ネットワークを介して接続された構成を有する。なお、図１は、端末装置１００及びアプリケーションサーバ２００において本発明の実施の形態に特に関係する機能部のみを示すものであり、例えば、端末装置１００には図示した機能部以外にも、キーボード・マウス等の入出力デバイス、表示デバイス等が備えられている。

図１に示すように、端末装置１００は、自動化ツール１１０、アプリケーション１２０、インターフェース（ＩＦ）１３０を有する。自動化ツール１１０は、前述したようにＧＵＩ上における人間の操作をエミュレートして、操作を自動化するソフトウェアにより実現される機能部であり、従来技術による上記のエミュレート機能に加えて、本発明に係る機能を有する。本実施の形態に係る自動化ツール１１０の詳細については後述する。

アプリケーション１２０は、ＧＵＩ１２１を表示するプログラム（例：Ｗｅｂブラウザ）により実現される機能部である。ＩＦ１３０は、アプリケーションサーバ２００と通信を行うインターフェースである。

アプリケーションサーバ２００は、端末装置１００にＩＦ２２０を介してＧＵＩ１２１を提供するとともに、自機において、例えば業務システムとして機能するアプリケーションプログラムを実行する。図１にはアプリケーションサーバ２００における本発明の実施形態に関係する機能部として、アプリケーションプログラム実行により生成されるログをＩＦ２２０を介して端末装置１００に送信するログ送信部２１０が示されている。

＜自動化ツール１１０の詳細＞
図１に示すとおり、自動化ツール１１０は、制御部１１１、シナリオ１１２、アダプタ１１３、ログ解析部１１４、ログ生成部１１５を備える。

シナリオ１１２は、端末装置１００の記憶装置（メモリ、ＨＤＤ等）に格納される情報であり、シナリオ１１２には自動化ツール１１０で実行する操作プロセスが定義されている。シナリオ１１２で定義された操作プロセスを制御部１１１が解釈することで、当該操作プロセスの自動実行が実現される。

図２に、シナリオ１１２の一例を示す。図２に示すように、シナリオ１１２はノードとリンクにより表現される。

シナリオ１１２中の各ノードは、アプリケーションプログラムのＧＵＩ上における操作（アクション）の内容を表す。例えば、「マウスクリックアクション」ノードでは、マウス操作の種類（左クリック、右クリック、左ダブルクリック等）、ウィンドウ内におけるマウス操作の座標位置が定義される。

例えば、「指定時間待機アクション」ノードでは、待機時間（秒数）が定義される。例えば、「リンククリックアクション」ノードでは、ＧＵＩで形成されているリンク（例：Ｗｅｂサイトへのリンク）を識別、および当該リンクのクリック動作が定義される。

シナリオ１１２中の各ノードはリンクにより結合される。リンクは、ノードの実行順序を表現する。シナリオ１１２の「開始」端点から始まり、リンクに従って各ノードで定義されたアクションが順次実行される。シナリオの「終了」端点に到達すると、シナリオの実行が終了する。

また、シナリオ１１２の実行順序を制御するノードを設けることができる。例えば、「条件分岐」ノードでは、ＧＵＩの状態や自動化ツール内部で保持する値などが所定の条件式に合致するか否かを判定する。判定結果がｔｒｕｅである場合と、ｆａｌｓｅである場合それぞれについて、次に実行するべきノード／リンクを定義できる。

また、同一のシナリオを連続して実行させて、複数のデータの処理を実行することもできる。このとき、処理すべきデータは、フィールド／レコード形式で定義される。自動化ツール１１０は、１レコードごとにデータを読み込み、繰返しシナリオを実行する。

シナリオ１１２は、電子ファイルの形式で端末装置１００の記憶装置（ＨＤＤ等）に記憶させることができる。例えばシナリオ１１２を、当該端末装置１００以外の端末装置に格納することで、当該端末装置においても自動化ツールを実行する際に、制御部にシナリオ１１２を読み込ませることができ、端末装置１００における自動操作と同様の自動操作を実現できる。

図１に示すアダプタ１１３は、シナリオ１１２のノードで定義されたプロセスをアプリケーション１２０に適合するコマンドに変換する。また、端末装置１００上で実行されるアプリケーション１２０の動作や、端末装置１００のＩＦ１３０に入出力される信号を監視し、自動化ツール１１０に適合するメッセージに変換する。自動化ツール１１０の制御部１１１は、このようにアダプタ１１３により変換されたメッセージを必要に応じて解釈することで、端末装置１１０やアプリケーション１２０の状態に応じたシナリオ実行が可能になる。

例えば、図２に示した「ウィンドウ状態待機アクション」ノードでは、アダプタ１１３が、監視対象のアプリケーション１２０のウィンドウの状態（例えば、ウィンドウが前面に表示されているか、ウィンドウが最大化されているか、等）を取得する。取得された状態を示す情報を、例えば前記「条件分岐」ノードに適用することにより、シナリオ実行の制御に用いることができる。

制御部１１１は、シナリオ１１２に従って自動化ツール１１０の実行を制御する。自動化ツール１１０の実行に先立ち、シナリオ１１２を読み込み、シナリオ１１２の実行時には、シナリオ１１２に含まれる各ノードの処理内容をアダプタ１１３に出力しＧＵＩ操作を実行する他、アダプタ１１３により変換され出力されたメッセージに従い、条件分岐等のシナリオ１１２の実行制御を行う。

また、制御部１１１は、シナリオ１１２の実行速度を設定することができる。この設定では、シナリオ１１２上で連続するノード（アクション）があるとき、各アクションの間に挿入する遅延時間の長さを設定できる。例えば、実行速度を０から１００の指数で表し、指数が「１００」のときは遅延時間を０秒とし、指数を減らすとその分遅延時間を加算する。例えば、指数を１０減らし「９０」とすると、遅延時間が１００ミリ秒に設定され、さらに１０減らし「８０」とすると、遅延時間が２００ミリ秒に設定される。

ログ解析部１１４は、ログメッセージ（後述）に含まれる情報から、アプリケーションサーバ２００や端末装置１００の負荷に関する値を抽出し、アプリケーションサーバ２００や端末装置１００が過負荷状態にかるか否かを判定する。例えば、ログメッセージがアプリケーションサーバ２００から取得される場合、ログメッセージ中の所定の値（例えば、ＣＰＵ使用率）が所定の閾値（例えば８０％）を超過すると、当該アプリケーションサーバ２００が過負荷状態にあると判定する。

ログメッセージが端末装置１００から取得される場合、同様に、ログメッセージ中の所定の値と所定の閾値を基に、当該端末装置１００が過負荷状態にあると判定する。

また、図１に示すように、自動化ツール１１０は、自動化ツール１１０のシナリオ１１２に含まれるノードの実行時刻等を含むログメッセージを生成するログ生成部１１５を備えてもよい。この場合、自動化ツール１００のシナリオ１１２に含まれるノードの実行に関する所要時間から、アプリケーションサーバ２００又は端末装置１００の負荷状態を推定し、これらが過負荷状態にあるか否かを判定することができる。

本実施の形態に係る端末装置１００における自動化ツール１１０は、コンピュータに、本実施の形態で説明する自動化ツール１１０の処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、自動化ツール１１０は、コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、自動化ツール１１０の各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

（動作例）
本実施の形態に係るシステムの動作例を図３を参照して説明する。図３は、特に自動化ツール１１０の制御部１１１とログ解析部１１２、及びアプリケーションサーバ２００における処理動作を示している。

＜ログメッセージ取得に係る処理＞
制御部１１１はシナリオ１１２を読み込み、ノード（アクション）を実行することで、ＧＵＩ操作が行われ、アプリケーション１２０によるアプリケーションサーバ２００へのアクセスが発生する（ステップ１０１）。

本実施の形態におけるアプリケーションサーバ２００では、自機の負荷を示す情報、例えばＣＰＵ使用率やメモリ占有率等を逐次取得している。

アプリケーションサーバ２００は、その情報を定期的に、又は他装置からの要求を受けて、ログメッセージとして他の機器に送信する機能を有している。例えば、ｓｙｓｌｏｇのように、アプリケーションサーバ２００が定期的又はイベント発生時にログメッセージを出力することとし、当該ログメッセージの送信先を端末装置１００として設定することができる。なお、ネットワーク環境によっては、ログメッセージ送信先を個々の端末装置にするのではなく、中継サーバを設置して当該中継サーバを出力先に設定し、当該中継サーバから個々の端末装置にログメッセージを送信することが適切な場合もある。

上記のようにログメッセージの送信先を端末装置１００として設定されたアプリケーションサーバ２００からログメッセージが端末装置１００に送信され、端末装置１００は、アプリケーションサーバ２００から送信されたログメッセージを受信する（ステップ１０２）。このとき、アプリケーションプログラムの操作に用いる通信インターフェース１３０と同じインターフェースで受信してもよいし、ログメッセージ受信用の通信インターフェースを別に設け、その通信インターフェースで受信してもよい。

端末装置１００は、受信したログメッセージを、いったんメモリ等の記憶部に蓄積（キャッシュ）した後、当該端末装置１００で動作する自動化ツール１１０のログ解析部１１４に渡す。ログメッセージは、端末装置１００が受信するたびに逐一ログ解析部１１４に渡してもよいし、自動化ツール１１０の制御部１１１によりログメッセージ取得が許可又は要求されたタイミングでのみ渡すこととしてもよい。後者の場合、制御部１１１がログメッセージの取得を要求するタイミングを、シナリオ中に「ログ取得アクションノード」を設けることで任意に定義することしてもよい。

また、負荷情報（ログメッセージ）受信のためのモニタリングプロセス（モニタリング部）を自動化ツール１１０と別に並列的に動作させてもよい。このとき、端末装置１００は、ログメッセージを当該モニタリングプロセスに渡し、当該モニタリングプロセスと自動化ツール１１０との間でログメッセージの送受信をする。つまり、モニタリングプロセスから自動化ツール１１０のログ解析部１１４にログメッセージが送信され、ログ解析部１１４が当該ログメッセージを受信する。

なお、ログメッセージの送信に関するプログラム自体がアプリケーションサーバ２００の負荷を高める可能性があるため、ログメッセージの送信間隔やイベントの重要性の定義等を予め調整することが望ましい。

また、端末装置１００からアプリケーションサーバ２００にリモートログインし、アプリケーションサーバ２００の動作ログを逐次取得するようにしてもよい。例えば端末装置１００上でパフォーマンスモニタプログラムを起動させておき、アプリケーションサーバ２００から定期的にＣＰＵ使用率等の値を取得する。このとき、アプリケーションサーバ２００でアカウント権限の管理がされていれば、ログ取得の可能なアカウントで予めログインすることが必要である。パフォーマンスモニタでは、取得したアプリケーションサーバ２００のログを、ログファイルの形式で端末装置１００内に保存してもよいし、予め設定した閾値を超えたときにアラームを出力するように設定してもよい。このように取得したログは、負荷情報を示すログメッセージとして、ログ解析部１１４に渡される。

＜ログ解析に係る処理＞
ログ解析部１１４にログメッセージが渡されると、ログ解析部１１４は、所定の条件により、アプリケーションサーバ２００の負荷に関係する値（負荷情報）をログメッセージから抽出する。負荷情報としては、具体的には、ＣＰＵ使用率（Ｐｒｏｃｅｓｓｏｒ＿Ｔｉｍｅ）、実行プロセス数（Ｓｙｓｔｅｍ＿Ｐｒｏｃｅｓｓｅｓ）、メモリの未使用容量（Ｍｅｍｏｒｙ＿Ａｖａｉｌａｂｌｅ＿ＭＢｙｔｅｓ）、送受信パケット量（Ｎｅｔｗｏｒｋ＿Ｍｂｐｓ）、ハードディスクの読み書き処理の割合（ＤｉｓｋＴｉｍｅ）などがある。

自動化ツール１１０の制御部１１１が、シナリオ１１２中のノードを実行する（ステップ１０１）と、その実行直後のアプリケーションサーバ２００の負荷状況の解析を、ログ解析部１１４へ要求する（ステップ１０３）。制御部１１１がそれぞれのノードについて実行直後に要求を出してもよいし、シナリオ１１２中に「負荷状態取得アクションノード」というものを設けて、このノードの実行直後でのみ要求を出してもよい。

ログ解析部１１４は、上記要求を受け、ログメッセージから抽出した負荷情報の最新値が所定の条件を満たすか否かを判定する（ステップ１０４）。ＣＰＵ使用率であれば、例えば８０％を閾値に設定し、８０％超を過負荷状態と判定する。なお、ログメッセージに含まれる複数の値を組み合わせて条件判定を行っても良い（例えば、ＣＰＵ使用率５０％超、かつ、メモリの未使用容量５０％以下の場合に過負荷状態と判定する）。また、最新の値の他、過去の履歴を含めた負荷状況を解析することとしてもよい。例えば、統計的な解析により、突発的な負荷増大が見られたときに過負荷状態と判定する。

また、上記のように要求に基づき負荷状態判定を行うことの他、ログ解析部１１４を制御部１１１と並行して実行させ、ログ解析部１１４が過負荷状態を検知したときに制御部１１１による処理に割り込むよう構成してもよい。

＜過負荷状態の解消に係る処理＞
ログ解析部１１４によりアプリケーションサーバ２００の過負荷状態が検知された場合（ステップ１０５のＹｅｓ）、ログ解析部１１４は、制御部１１１へ、過負荷状態を通知する（ステップ１０６）。この過負荷状態通知を受けると、制御部１１１は、シナリオ１１２中で次に実行するべきアクションの直前に、指定時間待機アクションノードを挿入する（ステップ１０７）。つまり、例えば図４の例１に示すように、アクションＡを実行した後に過負荷を検出した場合に、当該アクションＡの後で、次に実行するべきアクションＢの直前に指定時間待機アクションノードを挿入する。

こうすることで、アプリケーションサーバ２００の過負荷状態が解消されるのを待って、次のノードの実行に移ることができる。依然過負荷状態が解消されない場合は、次の指定時間待機アクションノード挿入において、待機時間をより長く設定する。

なお、最後に実行したノードがアプリケーションサーバ２００を過負荷状態に陥らせる原因と想定されるならば、指定時間待機アクションノードを、最後に実行したノードの直前に挿入してもよい。一度挿入したノードは、その後のデータ処理においても保存されているので、再びアプリケーションサーバ２００を過負荷状態に陥らせることを予防することができる。

指定時間待機アクションノードに設定する待機時間は、一律に既定値としてもよいし、過負荷状態が解消されるまで漸次増加させても良い。

なお、シナリオ１１２の中の任意の位置に指定時間待機アクションノードを挿入すると、シナリオ全体のプロセス実行に不都合が生じる場合がある。そのため、自動的に指定時間待機アクションノードを挿入することが可能な位置や不可能な位置、待機時間の上限値の設定などを、シナリオ１１２中にあらかじめ定義することとしてもよい。

また、過負荷状態を解消させるための他の例として、図４の例２に示すように、各ノードに定義されたアクションの実行間隔を広げるよう、実行速度を遅くする（ノード間に遅延時間を挿入する）こととしてもよい。例えば、ログ解析部１１４により判定の結果、システムの過負荷状態が検知されると、その後に連続したアクションの実行の前に、一律に遅延時間を挿入して、シナリオ１１２全体の実行速度を低減させる。

なお、シナリオ実行速度を低減させて過負荷状態を解消させるための処理として、指定時間待機アクションノードを挿入する処理と、アクションの実行間隔を広げる処理の両方を行うこととしてもよい。

このように一度実行速度を低減させた後、実行速度を増加させないことにより、アプリケーションサーバ２００にかかる負荷を低減させたままでのシナリオ実行が可能になる。なお、継続してアプリケーションサーバ２００のログメッセージを取得して、過負荷状態が解消されたことが確認されれば、元の実行速度を回復するよう、実行速度を復帰又は漸増させてもよい。このとき、ログ解析部１１４は、実行速度を復帰又は漸増させるための条件を別に保持し、アプリケーションサーバ２００のログメッセージが示す負荷状態が当該条件を満たすか否かを判定する。

（変型例１）
自動化ツール１１０の実行によって、アプリケーションサーバ２００の他にも、当該自動化ツール１１０を実行する端末装置１００に負荷をかけるケースも考えられる。このため、端末装置１００が、自機の負荷状態を示すログメッセージを生成し、自動化ツール１１０が当該ログメッセージを取得してログ解析部１１４に渡すことで、ログ解析部１１４が端末装置１００の過負荷状態を判定するように構成することもできる。この変形例１では、ログメッセージの送信元が端末装置１００に変わること以外は、前述の動作と同様の動作が行われる。

なお、端末装置１００の負荷状態を判定し、負荷状態に応じてシナリオ実行速度を低減させる処理は、前述したアプリケーションサーバ２００の負荷状態を判定し、負荷状態に応じてシナリオ実行速度を低減させる処理と並行して行ってもよいし、どちらか一方を行うこととしてもよい。並行して行う場合、ログ解析部１１４は、アプリケーションサーバ２００が過負荷状態であることを示す所定の条件を満たすか否かを判定するととともに、端末装置１００が過負荷状態であることを示す所定の条件を満たすか否かを判定することになる。

負荷状態を示すログメッセージは、さらに他の機器から取得し、解析してもよい。システム全体でボトルネックとなる機器からログメッセージを取得して当該機器の負荷状態を監視することで、より効率的に自動化ツールの実行を制御することができる。

他の機器の例としては、ネットワークを構成するスイッチ、ルータ、プロキシサーバ、ロードバランサ、ファイアウォール等がある。また、通信に関わるスループットやジッタ等を負荷情報として扱ってもよい。

（変形例２）
これまでに説明した例のように、ログメッセージから直接的にアプリケーションサーバ２００の負荷情報を解析するのではなく、シナリオ１１２中の各ノードに係る処理時間を計測し、当該処理時間が所定の閾値を超えたときにアプリケーションサーバ２００が過負荷状態となっていると判定することもできる。この場合の例を変形例２として図５を参照して説明する。

アプリケーションサーバ２００の設定やネットワーク設計等によっては、端末装置１００側でアプリケーションサーバ２００のログメッセージを受信できないケースがあるが、自動化ツール１１０自身のログメッセージを手がかりに、アプリケーションサーバ２００の負荷状態を間接的に推定することができる。

変形例２では、自動化ツール１１０がログ生成部１１５を備えており、ノードを実行するたびに、ログ生成部１１５がログメッセージを生成し（図５のステップ２０２）、ログメッセージをメモリ等の記憶装置に蓄積する。このログメッセージには、実行したノードの識別情報（ノードＩＤ）及び当該ノードを実行した時間に関する情報（ノード実行時刻等）が含まれる。

ログ解析部１１４は、例えば制御部１１１からの要求（ステップ２０３）に応じて、ログ生成部１１５が出力したログメッセージを解析し、ノードの実行に要した所要時間を算出する（ステップ２０４、２０５）。この所要時間が所定の閾値を超えた場合、アプリケーションサーバ２００のレスポンスが低下した（処理速度が遅くなった、過負荷状態である）、又は端末装置１００のレスポンスが低下した（処理速度が遅くなった、過負荷状態である）と判定する（ステップ２０６のＹｅｓ）。そして、前述した動作と同様に、制御部１１１は、シナリオの実行速度を低減させるための処理を行う（ステップ２０８）。

上記所定の閾値は、ノードで定義されるアクションの種類ごとに設定してもよいし、一律に設定してもよい。また、ユーザによるシナリオ作成時に、各ノードに任意の閾値を設定してもよい。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１００ 端末装置
１１０ 自動化ツール
１１１ 制御部
１１２ シナリオ
１１３ アダプタ
１１４ ログ解析部
１１５ ログ生成部
１２０ アプリケーション
１２１ ＧＵＩ
１３０ ＩＦ
２００ アプリケーションサーバ
２１０ ログ送信部
２２０ ＩＦ

Claims (9)

1. アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
   アプリケーションプログラムを実行するサーバの負荷情報を取得し、当該負荷情報を解析し、当該負荷情報が所定の条件を満たすか否かを判定する解析部と、
   前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部と
   を備えることを特徴とする端末装置。
2. アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
   アプリケーションプログラムのＧＵＩを表示する前記端末装置の負荷情報を取得し、当該負荷情報を解析し、当該負荷情報が所定の条件を満たすか否かを判定する解析部と、
   前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部と
   を備えることを特徴とする端末装置。
3. アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置であって、
   前記端末装置により実行された各ノードの処理時間を解析し、当該処理時間が所定の条件を満たすか否かを判定する解析部と、
   前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる制御部と
   を備えることを特徴とする端末装置。
4. 請求項１ないし請求項３のうちいずれか１項に記載の端末装置であって、
   前記制御部は、シナリオに含まれるノード間の待機時間を長くすることにより、シナリオの実行速度を低減させることを特徴とする端末装置。
5. 請求項１ないし請求項４のうちいずれか１項に記載の端末装置であって、
   前記制御部は、シナリオの実行を待機するためのノードをシナリオに挿入することにより、シナリオの実行速度を低減させることを特徴とする端末装置。
6. 請求項１ないし請求項５のうちいずれか１項に記載の端末装置であって、
   前記解析部は、前記サーバが過負荷状態であることを示す所定の条件を満たすか否かを判定することを特徴とする端末装置。
7. 請求項１ないし請求項６のうちいずれか１項に記載の端末装置であって、
   前記解析部は、前記端末装置が過負荷状態であることを示す所定の条件を満たすか否かを判定することを特徴とする端末装置。
8. アプリケーションプログラムのＧＵＩにおける操作を実行するためのアダプタを介して、前記操作の単位となるノードにより構成されたシナリオに従って前記操作を実行する端末装置により実行されるシナリオ実行制御方法であって、
   前記端末装置は、
   アプリケーションプログラムを実行するサーバから、負荷情報を受信し、
   前記受信した負荷情報を解析し、
   当該負荷情報が所定の条件を満たすか否かを判定し、
   前記解析部により所定の条件を満たすと判定された際に、シナリオの実行速度を低減させる
   ことを特徴とするシナリオ実行制御方法。
9. コンピュータを、請求項１ないし７のうちいずれか１項に記載の前記端末装置の各部として機能させるためのプログラム。

Images