(57)【要約】      （修正有）【課題】複数のＡＰサーバの中で連携処理を実行せずに待機中であるＡＰサーバが自らの判断で、連携処理を実行し稼働中のＡＰサーバと入れ替わることが可能な仕組みを提供する。【解決手段】ＤＢサーバと複数のＡＰサーバとが通信可能に接続されるサーバシステムにおいて、ＤＢサーバは、ＡＰサーバとして稼働させるサーバ情報を記憶し、複数のＡＰサーバからそれぞれ受信したＡＰサーバ毎の稼働状況を集約して、複数のＡＰサーバに送信する。ＡＰサーバは、ＤＢサーバから送信された他サーバの稼働状況と自サーバの稼働状況に基づいて、自サーバの稼働状況の方が他サーバの稼働状況よりも低く、かつ、自サーバがＡＰサーバとして待機中であると判断した場合に、サーバ情報に定義されている他サーバ情報を自サーバ情報に更新することで、稼働させるＡＰサーバの数を変えずに稼働させるＡＰサーバを入れ替える。【選択図】図７
2017090966.tif 000002
【特許請求の範囲】
【請求項１】
業務システムで用いられるシステムデータを管理するＤＢサーバと、前記管理されている前記システムデータの処理を実行する複数のＡＰサーバとが通信可能に接続されるサーバシステムであって、
前記ＤＢサーバは、
システムデータの前記処理を実行するＡＰサーバとして稼働させるサーバ情報を記憶する記憶手段と、
前記複数のＡＰサーバからそれぞれ受信した、ＡＰサーバ毎の稼働状況を集約して、前記複数のＡＰサーバにそれぞれ送信する送信手段と、
を備え、
前記複数のＡＰサーバはそれぞれ、
自サーバの、前記稼働状況を取得する自サーバ状況取得手段と、
前記取得した前記自サーバの稼働状況をＤＢサーバに送信する自サーバ状況送信手段と、
前記ＤＢサーバから送信された他サーバの前記稼働状況を取得する他サーバ状況取得手段と、
取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも低いか否かを判断する稼働状況判断手段と、
自サーバは、前記処理を実行するＡＰサーバとして待機中であるか否かを判断する待機判断手段と、
前記低いと判断し、かつ、前記待機中であると判断した場合に、前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替手段と、
前記ＤＢサーバが記憶するサーバ情報に基づいて、前記システムデータの前記処理を実行する実行手段と、
を備えることを特徴とするサーバシステム。
【請求項２】
前記高いと判断し、かつ、前記待機中であると判断した場合には、前記サーバ入替手段が前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新しないことを特徴とする請求項１に記載のサーバシステム。
【請求項３】
前記複数のＡＰサーバはそれぞれ、
前記稼働状況の閾値を記憶する記憶手段と、
取得した他サーバの前記稼働状況が前記閾値に到達したか否かを判断する閾値判断手段と、
前記到達したと判断した場合に、前記サーバ入替手段が前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新することを特徴とする請求項１または請求項２に記載のサーバシステム。
【請求項４】
前記複数のＡＰサーバはそれぞれ、
取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも高いか否かを判断する稼働状況判断手段と、
自サーバは、前記連携処理を実行するＡＰサーバとして稼働中であるか否かを判断する稼働判断手段と、
前記高いと判断し、かつ、前記稼働中であると判断した場合に、前記記憶するサーバ情報に定義されている自サーバ情報を前記記憶するサーバ情報に定義されていない他サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替手段と、
を備えることを特徴とする請求項１乃至請求項３のいずれか１項に記載のサーバシステム。
【請求項５】
前記低いと判断し、かつ、前記稼働中であると判断した場合には、前記サーバ入替手段が前記記憶するサーバ情報に定義されている自サーバ情報を前記記憶するサーバ情報に定義されていない他サーバ情報に更新しないことを特徴とする請求項４に記載のサーバシステム。
【請求項６】
業務システムで用いられるシステムデータを管理するＤＢサーバと、前記管理されている前記システムデータの処理を実行する複数のＡＰサーバとが通信可能に接続されるサーバシステムの制御方法あって、
前記ＤＢサーバは、
システムデータの前記処理を実行するＡＰサーバとして稼働させるサーバ情報を記憶する記憶手段を備え、
前記ＤＢサーバの送信手段が、前記複数のＡＰサーバからそれぞれ受信した、ＡＰサーバ毎の稼働状況を集約して、前記複数のＡＰサーバにそれぞれ送信する送信工程と、
を含み、
前記複数のＡＰサーバそれぞれの自サーバ状況取得手段が、自サーバの、前記稼働状況を取得する自サーバ状況取得工程と、
前記複数のＡＰサーバそれぞれの自サーバ状況送信手段が、前記取得した前記自サーバの稼働状況をＤＢサーバに送信する自サーバ状況送信工程と、
前記複数のＡＰサーバそれぞれの他サーバ状況取得手段が、前記ＤＢサーバから送信された他サーバの前記稼働状況を取得する他サーバ状況取得工程と、
前記複数のＡＰサーバそれぞれの稼働状況判断手段が、取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも低いか否かを判断する稼働状況判断工程と、
前記複数のＡＰサーバそれぞれの待機判断手段が、自サーバは、前記処理を実行するＡＰサーバとして待機中であるか否かを判断する待機判断工程と、
前記複数のＡＰサーバそれぞれのサーバ入替手段が、前記低いと判断し、かつ、前記待機中であると判断した場合に、前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替工程と、
前記複数のＡＰサーバそれぞれの実行手段が、前記ＤＢサーバが記憶するサーバ情報に基づいて、前記システムデータの前記処理を実行する実行工程と、
を含むことを特徴とする制御方法。
【請求項７】
業務システムで用いられるシステムデータを管理するＤＢサーバと、前記管理されている前記システムデータの処理を実行する複数のＡＰサーバとが通信可能に接続されるサーバシステムで読み取り実行可能なプログラムであって、
前記ＤＢサーバを、
システムデータの前記処理を実行するＡＰサーバとして稼働させるサーバ情報を記憶する記憶手段と、
前記複数のＡＰサーバからそれぞれ受信した、ＡＰサーバ毎の稼働状況を集約して、前記複数のＡＰサーバにそれぞれ送信する送信手段と、
して機能させ、
前記複数のＡＰサーバをそれぞれ、
自サーバの、前記稼働状況を取得する自サーバ状況取得手段と、
前記取得した前記自サーバの稼働状況をＤＢサーバに送信する自サーバ状況送信手段と、
前記ＤＢサーバから送信された他サーバの前記稼働状況を取得する他サーバ状況取得手段と、
取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも低いか否かを判断する稼働状況判断手段と、
自サーバは、前記処理を実行するＡＰサーバとして待機中であるか否かを判断する待機判断手段と、
前記低いと判断し、かつ、前記待機中であると判断した場合に、前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替手段と、
前記ＤＢサーバが記憶するサーバ情報に基づいて、前記システムデータの前記処理を実行する実行手段と、
して機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はサーバシステム、及びその制御方法とプログラムの技術に関する。
【背景技術】
【０００２】
企業内の業務システムは複数筐体、複数個所に分かれているため、各システム間で必要なデータの送受信が発生する。各システム個別に送受信を行うと個別最適となるため、企業内全体でデータ連携基盤として共通の処理を行う基盤を通常持つ。各業務を遂行するにあたり必要なデータとなるため、連携基盤に求められる非機能要件のうち、可用性は高くなる。万が一停止した場合、業務システムの損失は企業規模に依存するが、３０分の停止あたり数千万以上となる。
【０００３】
さらに、Ｗｅｂシステムと連携基盤の可用性を実現する方式の違いとして、インターネットを利用したＷｅｂシステム等ではクライアント側からのリクエストにより処理が実行されるため、リクエストを分散する負荷分散装置（ロードバランサ）により処理を実行するＷｅｂサーバを複数台ある中から選定する。このようにＷｅｂシステムは処理の起動がクライアント側の都合で始まる。
【０００４】
これに対し、業務システム側の都合により連携処理を実行したい場合、前述のＷｅｂシステムほどのリアルタイム性が求められない事や、業務システム側が連携の処理起動を負担しない場合が多い事から、連携を実行するサーバ側からの処理起動が通常採用される仕組みとなる。
【０００５】
連携基盤で可用性を確保するための一般的な連携システムでは、いわゆるソフトクラスタ方式のように先に複数台のＡＰサーバ間での相互通信により、複数台のＡＰサーバ間で互いの稼働状況を常時確認し合い、複数台のＡＰサーバ間で互いの稼働状況を共有してから処理実行を行うＡＰサーバを決める仕組みがある。
【０００６】
いわゆるソフトクラスタ方式では、複数台のＡＰサーバ間で互いの稼働状況を常時確認し合い、複数台のＡＰサーバ間で互いの稼働状況を共有してから処理実行を行うので、ＤＢサーバ側で多数のＡＰサーバの中から共通のプログラムを直ぐに実行出来るＡＰサーバがどれかを把握して実行要求する場合に、プログラムの実行要求するＡＰサーバを決めるまでに毎回その共有時間がかかってしまうといった問題が発生する。
【０００７】
また、特許文献１には、サービスを提供する正系サーバと待機系である副系サーバで構成された多数のＡＰサーバを管理下におく、監視サーバが、正系サーバの稼働台数を管理して、上限に余剰が発生した場合に、正系サーバが副系サーバになるように、サーバ定義ファイルを入れ替え、上限に不足が発生した場合に、副系サーバが正系サーバになるように、サーバ定義ファイルを入れ替える仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−１１３４９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１に開示されている技術では、監視サーバが稼働すべき台数を維持するように、入れ替えを管理するたけで、各ＡＰサーバの状況に問題ない状態で稼働と待機しているのかまでは監視サーバは把握していない。監視サーバがかってに各ＡＰサーバの状況に問題があるタイミングでも、ＡＰサーバの入れ替えを行ってしまうといったことが起こってしまう。
【００１０】
本願発明は、複数のＡＰサーバの中で連携処理を実行せずに待機中であるＡＰサーバが自らの判断で、連携処理を実行し稼働中のＡＰサーバと入れ替わることが可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本願発明は、業務システムで用いられるシステムデータを管理するＤＢサーバと、前記管理されている前記システムデータの処理を実行する複数のＡＰサーバとが通信可能に接続されるサーバシステムであって、前記ＤＢサーバは、システムデータの前記処理を実行するＡＰサーバとして稼働させるサーバ情報を記憶する記憶手段と、前記複数のＡＰサーバからそれぞれ受信した、ＡＰサーバ毎の稼働状況を集約して、前記複数のＡＰサーバにそれぞれ送信する送信手段と、を備え、前記複数のＡＰサーバはそれぞれ、自サーバの、前記稼働状況を取得する自サーバ状況取得手段と、前記取得した前記自サーバの稼働状況をＤＢサーバに送信する自サーバ状況送信手段と、前記ＤＢサーバから送信された他サーバの前記稼働状況を取得する他サーバ状況取得手段と、取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも低いか否かを判断する稼働状況判断手段と、自サーバは、前記処理を実行するＡＰサーバとして待機中であるか否かを判断する待機判断手段と、前記低いと判断し、かつ、前記待機中であると判断した場合に、前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替手段と、前記ＤＢサーバが記憶するサーバ情報に基づいて、前記システムデータの前記処理を実行する実行手段と、を備えることを特徴とする。
【００１２】
また、前記高いと判断し、かつ、前記待機中であると判断した場合には、前記サーバ入替手段が前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新しないことを特徴とする。
【００１３】
また、前記複数のＡＰサーバはそれぞれ、前記稼働状況の閾値を記憶する記憶手段と、取得した他サーバの前記稼働状況が前記閾値に到達したか否かを判断する閾値判断手段と、前記到達したと判断した場合に、前記サーバ入替手段が前記記憶するサーバ情報に定義されている他サーバ情報を自サーバ情報に更新することを特徴とする。
【００１４】
また、前記複数のＡＰサーバはそれぞれ、取得した自サーバの前記稼働状況と取得した他サーバの前記稼働状況に基づいて、自サーバの前記稼働状況の方が、他サーバの前記稼働状況よりも高いか否かを判断する稼働状況判断手段と、自サーバは、前記連携処理を実行するＡＰサーバとして稼働中であるか否かを判断する稼働判断手段と、前記高いと判断し、かつ、前記稼働中であると判断した場合に、前記記憶するサーバ情報に定義されている自サーバ情報を前記記憶するサーバ情報に定義されていない他サーバ情報に更新して、稼働させるＡＰサーバの数を変えずに、稼働させるＡＰサーバを入れ替えるサーバ入替手段と、を備えることを特徴とする。
【００１５】
また、前記低いと判断し、かつ、前記稼働中であると判断した場合には、前記サーバ入替手段が前記記憶するサーバ情報に定義されている自サーバ情報を前記記憶するサーバ情報に定義されていない他サーバ情報に更新しないことを特徴とする。
【発明の効果】
【００１６】
本願発明により、複数のＡＰサーバの中で連携処理を実行せずに待機中であるＡＰサーバが自らの判断で、連携処理を実行し稼働中のＡＰサーバと入れ替わることが可能な仕組みを提供することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明のデータ連携システムが各種業務システム連携に組み込まれた一例を示す社内業務システムの全体像である。
【図２】本発明のデータ連携システムを構成しているＤＢサーバと可用性を担保するための複数のＡＰサーバとが通信可能に接続されたものである。
【図３】ＡＰサーバ入れ替え前の、本発明のＤＢサーバが複数のＡＰサーバにプログラムを振り分けて実行するフローチャートである。
【図４】ＡＰサーバ入れ替え前の、ＤＢサーバの記憶部に予め登録されている定義情報や、プログラム実行中に動的に更新されるステイタス情報を示したものである。
【図５】業務システムのＤＢサーバ１が管理する連携データＩＤの管理テーブルの一例を示したものである。また、ＤＢサーバ１００が管理するプログラムＡの実行権制御用の管理テーブルの一例を示したものである。
【図６】図１に示したデータ連携システムを構築するために必要な、ＤＢンサーバ、ＡＰサーバに適用可能な各情報処理装置内部のハードウェア構成を示すブロック図である。
【図７】本発明の稼働中ＡＰサーバと待機中ＡＰサーバを動的に入れ替える処理実行するフローチャートである。
【図８】各ＡＰサーバが取得する負荷データのデータ構造の一例を示したものである。また、各ＡＰサーバが管理する閾値データの設定テーブルの一例を示したものである。
【図９】ＤＢサーバが取得する、全ＡＰサーバ負荷データのデータ構造の一例を示したものである。
【図１０】ＡＰサーバ入れ替え後の、ＤＢサーバの記憶部に予め登録されている定義情報や、プログラム実行中に動的に更新されるステイタス情報を示したものである。
【図１１】ＡＰサーバ入れ替え後の、本発明のＤＢサーバが複数のＡＰサーバにプログラムを振り分けて実行するフローチャートである。
【発明を実施するための形態】
【００１８】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１を説明する。
【００１９】
図１は、本発明のデータ連携システム２００が各種業務システム連携に組み込まれた一例を示す社内業務システムの全体像である。このように本発明のデータ連携システム２００が各種業務システム間でのデータのやり取り（送受信）に問題が起こらない様に、データの連携処理をおこなっている。
図２を説明する。
【００２０】
図２は、本発明のデータ連携システム２００を構成しているＤＢサーバ１００と可用性を担保するための複数のＡＰサーバとが通信可能に接続されたものである。
受注管理システムのＤＢサーバ１とは、共通の連携処理用プログラム実行前の連携元のシステムデータを管理しているサーバである。
生産管理システムのＤＢサーバ２とは、共通の連携処理用プログラム実行後の連携先のシステムデータを管理しているサーバである。
受注管理システムのＤＢサーバ１と生産管理システムのＤＢサーバ２はお互いに連携元と連携先が入れ替わることは言うまでもない。
【００２１】
なお、受注管理システムまたは生産管理システムは販売管理システム、工程管理システム等でもよく、業務上のシステムデータが管理されるシステムであればよい。
ＤＢサーバ１００とは、各業務システムで用いられるシステムデータを、業務システムが異なる複数の業務システム間で連携するサーバである。
【００２２】
複数のＡＰサーバ１０１、１０２、２０１とは、共通の連携処理用プログラムを用いて、異なる複数のシステム間でそれぞれ管理されているシステムデータの連携処理を、複数のＡＰサーバ間で、それぞれ分散して実行するサーバである。このように分散して共通の連携処理用プログラムを実行することで可用性を担保している。
このように３台のＡＰサーバの中で２台を常時稼働する場合、２台が稼働中の時に１台は待機中（バックアップ用）となる。
なお、実施例では複数のＡＰサーバ１０１、１０２、２０１と、ＤＢサーバ１００で構成されるシステムをサーバシステムとして説明する。
図３を説明する。
【００２３】
図３は、業務システムＡ（例えば受注管理システム）から業務システムＢ（例えば生産管理システム）にシステムデータを受け渡す際に、ＤＢサーバ１００が複数のＡＰサーバにプログラムを振り分けて実行するフローチャートの一例を示した図である。
まず、複数のＡＰサーバがそれぞれ読み取り実行可能なプログラムによるフローチャートを説明する。
【００２４】
Ｓ４０１では各ＡＰサーバ１０１、１０２において、自サーバの動作状況が良好であるか否かを判断している。自サーバの動作状況が良好であるとは、共通プログラムを用いて一元管理されているデータの連携処理を実行できる動作環境であり、少なくとも自サーバがＯＳ動作不具合やＯＳの動作停止やＡＰサーバ自体が電源ＯＦＦではない良好状態ということである。ここで、自サーバの動作状況が良好である（ＹＥＳ）の場合にはＳ４０２に進む。逆に自サーバの動作状況が良好ではない（ＮＯ）の場合、Ｓ４０４に進む。
【００２５】
Ｓ４０２では各ＡＰサーバ１０１、１０２において、Ｓ２０５におけるＤＢサーバからの情報に基づいて、共通プログラムを用いて一元管理されているデータの連携処理を現在実行中であるか否かを判断する（判断手段）。ここで、実行中である（ＹＥＳ）と判断した場合には、Ｓ４０８に進む。実行中ではない（ＮＯ）と判断した場合には、Ｓ４０３に進む。
【００２６】
Ｓ４０３では各ＡＰサーバ１０１、１０２において、自サーバの動作状況をＤＢサーバ１００に知らせる動作情報を、ＤＢサーバ１００に継続して常時送信している（動作情報送信手段）。つまり、自サーバの動作状況をＤＢサーバ１００に知らせる動作情報が送信できる場合、そのＡＰサーバは、少なくともＤＢサーバ１００との通信に関して、何ら問題が発生していないことになる。また、動作情報が送信できる場合には、そのＡＰサーバは、少なくとも電源ＯＦＦの状態ではないことになる。
【００２７】
さらに動作情報に自サーバの現在の状態（プログラム実行中情報、故障情報）等を含めることで、リアルタイムに自サーバの動作状況をＤＢサーバ１００に報告することができるので、良好な動作状況のＡＰサーバにいち早く、Ｓ２０５においてＤＢサーバ１００が共通プログラムを実行させる情報を送信することに繋がる。
【００２８】
Ｓ４０４ではＡＰサーバ１０１、１０２において、自サーバの動作状況をＤＢサーバ１００に知らせる動作情報をＤＢサーバ１００に継続して送信することに不具合が発生した場合には、自サーバの動作状況をＤＢサーバに知らせる動作情報をＤＢサーバ１００に継続して送信出来なくなる。
【００２９】
また、自サーバの動作状況をＤＢサーバ１００に知らせる動作情報をＤＢサーバ１００に継続して送信することは可能な場合には、自サーバの動作状況が良好に回復するまで動作情報の送信を停止してもよい。
【００３０】
さらに、その変形例として、自サーバの動作状況をＤＢサーバ１００に知らせる動作情報をＤＢサーバ１００に継続して送信することは可能な場合には、自サーバの動作状況が不具合中の間には、不具合動作情報を送信してもよい。
なお、本実施例では便宜的に、自サーバの動作状況が良好な場合に、ＤＢサーバ１００に常時送信する情報をＲＥＡＤＹ信号として定義する。
【００３１】
Ｓ４０８ではＡＰサーバ１０１、１０２において、自サーバで連携処理を現在実行中であると判断した場合であり、この連携処理を実行している間にはＤＢサーバ１００が自サーバには共通プログラムの実行をする情報を送信しないように、ＤＢサーバ１００に常時要求する（要求手段）。
【００３２】
このように自サーバには共通プログラムの実行をする情報を送信しないように、ＤＢサーバ１００に要求することで、ＤＢサーバ１００側では、リアルタイムに共通プログラムの実行中であるか否かのステイタス管理をすることができる。
【００３３】
Ｓ４０９では多数のＡＰサーバ１０１、１０２の中で、１つだけのＡＰサーバがＳ２０２でプログラム実行待ち状態であった未処理のシステムデータの共通プログラム（プログラムＡ）の実行権を取得することになる。つまり早いもの勝ちのＡＰサーバだけが、未処理のシステムデータに対する共通プログラム（プログラムＡ）の実行を任されることになる。
【００３４】
Ｓ４０５では、実行権を取得した１つだけのＡＰサーバが、受注管理システムのＤＢサーバ１にアクセスして、連携データの管理テーブル（例えば受注管理システム）の中の該当する未処理のシステムデータを読み出している。
【００３５】
Ｓ４０６ではＡＰサーバ１０１または１０２において、Ｓ２０５におけるＤＢサーバ１００からの情報に基づいて、共通プログラムを用いて、各業務システムで管理されているシステムデータの連携処理を実行する（プログラム実行手段）。このようにＳ４０６では、該当する未処理のシステムデータに対する共通プログラム（プログラムＡ）を実行する。
【００３６】
Ｓ４０７では、共通プログラム（プログラムＡ）を実行が終わり、生産管理システムのＤＢサーバ２にアクセスして、処理済のシステムデータへの更新が完了できたので、連携データの管理テーブル（例えば生産管理システム）の中の該当する処理済のシステムデータとして書き出している。
次に、ＤＢサーバが読み取り実行可能なプログラムによるフローチャートを説明する。
【００３７】
スケジューラにより所定の時刻や間隔になると、Ｓ２０１乃至Ｓ２０６のループ処理プログラムを起動させ、以下のＤＢサーバが読み取り実行可能なプログラムが始まる。
【００３８】
Ｓ２０１でＤＢサーバは図５上図に示したように、業務システムＡが管理している連携処理が必要な連携データの管理テーブル（例えば受注管理システム）中に連携処理が必要な未処理のシステムデータが残っているか否かを判断する。残っている（ＹＥＳ）と判断した場合には、Ｓ２０２に進む。残っていない（ＮＯ）と判断した場合に全ての未処理データの連携処理が完了する。
【００３９】
Ｓ２０２でＤＢサーバは、図５上図に示したように、業務システムＡが管理している連携処理が必要な連携データの管理テーブル（例えば受注管理システム）の中から、Ｓ２０５で１つだけのＡＰサーバに割り当てる未処理のシステムデータ（１つでもよく、複数でもよい）を選択した状態で待機状態とする。
【００４０】
Ｓ２０３でＤＢサーバは、複数のＡＰサーバ１０１，１０２それぞれに対して、動作情報を受信出来たか否かを継続して監視している（監視手段）。ここで、少なくとも１つのＡＰサーバから動作情報を受信出来た（ＹＥＳ）と判断した場合には、Ｓ２０４に進む。何れのＡＰサーバからも動作情報を受信出来ていない間は、Ｓ２０３の状態で、動作情報を受信出来たか否かを継続して監視している。
【００４１】
Ｓ２０４でＤＢサーバは、Ｓ２０３において受信した動作情報を送信したＡＰサーバ（送信元）を識別出来る情報（例えばサーバの番号、ＩＰアドレス、ＭＡＣアドレス等であればよい）に基づいて、サーバ定義情報（Ｓ２０５で共通プログラムの実行を許可するＡＰサーバ群）に該当するＡＰサーバであるか否かを判断している。ここでサーバ定義情報を参照した結果、サーバ定義情報に該当するＡＰサーバであることが確認出来た（ＹＥＳ）場合には、Ｓ２０５に進む。確認出来なかった（ＮＯ）場合には、該当するＡＰサーバではないとみなし、Ｓ２０５には進まずに受信した動作情報は破棄する。
【００４２】
Ｓ２０５でＤＢサーバは、監視しているＡＰサーバ（送信元）の動作情報を出来たか否かに基づいて、共通プログラムを実行させる１つのＡＰサーバを決定し、決定されたＡＰサーバに共通プログラムを実行させる情報を送信する（送信手段）。なお、ここで送信する共通プログラムを実行させる情報は、ＡＰサーバへの共通プログラムの実行命令でもよく、ＡＰサーバに対するプログラム実行権の提供であってもよい。
【００４３】
さらにここでは、監視手段による動作情報の受信が２つ以上のＡＰサーバから出来た場合も起こりうる。その場合には、監視手段による動作情報の受信を早く受け付けた方のＡＰサーバ（送信元）に決定し、共通プログラムを実行させる情報（割り当て）を送信することになる。
【００４４】
Ｓ２０６でＤＢサーバは、図５下図に示したように連携処理が必要な実行権制御用の管理テーブルの中で該当した未処理のシステムデータの状態を実行中から実行済に更新してステイタス管理する。
【００４５】
このときには、未処理のシステムデータは連携処理に必要な処理済のシステムデータデータとして、共通プログラム（プログラムＡ）によってそのデータ内容が変換または修正または加工されていることは言うまでもない。
図４を説明する。
図４はＤＢサーバ１００の記憶部に予め登録されている定義情報や、プログラムＡの実行中に動的に更新されるステイタス情報を示したものである。
【００４６】
サーバ定義情報には、Ｓ２０４において継続して監視するべき複数のＡＰサーバを識別出来る情報を記憶している（サーバ情報記憶手段）。５０１にはＤＢサーバ１００から監視する複数のＡＰサーバが登録されている。図の例ではＡＰサーバ１０１、１０２が登録されているので、ＡＰサーバ１０１、１０２のそれぞれから動作情報を受信出来たか否かを継続して監視することになる。
【００４７】
このように、サーバ情報記憶手段に登録されているサーバ情報が、システムデータの連携処理を実行するＡＰサーバとして稼働することになる。図４の例の場合、稼働するＡＰサーバとして１０１、１０２が設定されているので、２台が稼働することになる。さらに図１０の例の場合、稼働するＡＰサーバとして２０１、１０２が設定されているので、２台が稼働することになる。つまり稼働するＡＰサーバの数を固定して、待機しているＡＰサーバと１台ずつ入れ替えられることになる。
【００４８】
ＡＰサーバステイタスには、Ｓ２０５において現在プログラムＡの実行中または、故障中により実行権の提供から除外するＡＰサーバを判別するための複数のＡＰサーバを識別出来る情報を記憶している（サーバ情報記憶手段）。
５０２には、現在問題なく稼働中の複数のＡＰサーバが登録されている。該当するＡＰサーバがＳ２０５において実行権を提供する候補となる。
５０３には、現在プログラム実行中の複数のＡＰサーバが登録されている。ここに登録されている間、該当するＡＰサーバは実行権の提供から除外される。
図５を説明する。
図５の上図は受注管理システム（業務システムＡ）のＤＢサーバ１が管理する
【００４９】
連携データＩＤの管理テーブルの一例を示したものである。なお、生産管理システム（業務システムＢ）のＤＢサーバ２も同様の連携データＩＤの管理テーブルを管理し、互いに連携データの送受信ができるようになっている。
【００５０】
連携データＩＤ６０１とは、業務システムＡ（連携元）と業務システムＢ（連携先）で互いのシステムデータを連携するために、ＡＰサーバによるプログラムＡでの連携処理が必要なシステムデータを連携するための連携用ＫＥＹである。ＤＢサーバ１は、連携データＩＤの管理テーブルに登録された連携データＩＤに関する指示内容及び処理対象ステイタスを管理している。
【００５１】
指示内容６０２とは、業務システムＡ（連携元）から業務システムＢ（連携先）に対して依頼する内容を示したものである。「新規追加」とは例えば業務システムＢ（連携先）に対して新規にデータを追加指示するものである。「内容訂正」とは例えば業務システムＢ（連携先）に対してデータ内容の訂正を指示するものである。「削除」とは例えば業務システムＢ（連携先）に対して登録済みのデータの削除を指示するものである。
また、この指示内容６０２は本願発明における各業務システムで用いられるシステムデータである。
【００５２】
処理ステイタス６０３とは、連携データＩＤ６０１がプログラムＡによって連携処理されたか否かの状況を管理するものである。ここで「未処理」とはプログラムＡによって連携処理される前の状態であり、図３のフローチャート中のＳ２０２において、この「未処理」状態のシステムデータが選択されることになる。図示しない「処理済」状態であれば、図３のフローチャート中のＳ２０２においてシステムデータが選択されないことになる。
【００５３】
このように、この欄が、図示しない「処理中」、「処理済み」の状態に随時変遷することで、連携データＩＤ６０１がプログラムＡによって連携処理されたか否かの状況を管理している。この欄が「処理済」の場合は、プログラムＡが実行されて、該当するシステムデータは業務システムＢに連携された状態となっている。
図５の下図はＤＢサーバ１００が管理するプログラムＡの実行権制御用の管理テーブルの一例を示したものである。
【００５４】
連携データＩＤ７０１とは、業務システムＡ（連携元）と業務システムＢ（連携先）で互いのシステムデータを連携するために、ＡＰサーバによるプログラムＡでの連携処理が必要なシステムデータを連携するための連携用ＫＥＹである。ＤＢサーバ１００は、実行権制御用の管理テーブルに登録された連携データＩＤに関するプログラムＡの実行状況及び実行中のＡＰサーバの番号を管理している。
【００５５】
プログラム実行状況７０２とは、この実行権制御用の管理テーブルに登録された連携データＩＤが現在プログラムＡで「実行済み（ＣＯＭＰＬＥＴＥ）」、「実行中（ＲＵＮＮＩＮＧ）」、「実行前（ＷＡＩＴ）」いずれの状態かを管理している。
【００５６】
実行中のＡＰサーバ７０３とは、現在「実行中（ＲＵＮＮＩＮＧ）」の状態であるＡＰサーバがどのＡＰサーバなのかを管理している。つまりこの実行中のＡＰサーバ７０３により、ＤＢサーバ１００側から現時点で実行中のＡＰサーバを把握することができる。
図６を説明する。
【００５７】
図６において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。
【００５８】
２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００５９】
また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。なお、図２では、ＣＲＴ２１０と記載しているが、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じて管理者が使用するものである。
【００６０】
２０７はメモリコントローラで、ブートプログラム，各種のＡＰ，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００６１】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ４００）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００６２】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００６３】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。
【００６４】
また、本願発明におけるプログラムは、図３に示すフローチャートの処理方法をコンピュータが読み取り実行可能なプログラムであり、本願発明の記憶媒体は処理方法をコンピュータが実行可能なプログラムとして、外部メモリに記憶されている。  
【００６５】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本願発明の目的が達成されることは言うまでもない。  
【００６６】
この場合、記録媒体から読み出されたプログラム自体が本願発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。  
【００６７】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。  
【００６８】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。  
【００６９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。  
【００７０】
また、本願発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本願発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本願発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本願発明の効果を享受することが可能となる。  
【００７１】
さらに、本願発明を達成するためのプログラムをネットワーク上のサーバ，ＤＢ等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本願発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本願発明に含まれるものである。
図７を説明する。
図７は、複数のＡＰサーバ１０１、１０２、２０１の中で稼働するＡＰサーバを相互に入れ替えるフローチャートの一例を示した図である。
まず、複数のＡＰサーバがそれぞれ読み取り実行可能なプログラムによるフローチャートを説明する。
【００７２】
図７で示したフローチャートでは、便宜的に、図３の処理を実行するために現在稼働中のＡＰサーバを１０１、１０２として示し、図３の処理を実行せずに現在待機中のＡＰサーバを２０１として示している。
【００７３】
Ｓ３０１で複数のＡＰサーバ１０１、１０２、２０１はそれぞれ、各ＡＰサーバ別のタイミングや頻度で、自サーバの稼働状況を取得する（自サーバ状況取得手段）。ここで自サーバの稼働状況とは、自分自身のハードウエアリソースの使用率または使用量のことであり、例えばＣＰＵの現在の使用率８０１、メモリ（ＲＡＭ）の利用量８０２、ＣＰＵが処理すべきタスクの待ち行列数（ｒｕｎｑｕｅｕｅの値）８０３など、最新のハードウエアリソースの負荷状況を確認できる情報であればよい。
【００７４】
なお、一瞬の断片で自サーバの稼働状況を取得すると、瞬間的にハードウエアリソースの負荷が上がっているのかや、継続して負荷が上がっているのかの判断がつかないため、一定時間（例えば５分間）の間に例えば１秒間隔で稼働状況を取得し、一定間隔で取得した自サーバの稼働状況を自サーバ負荷データ８００の変数内に格納（更新）している。一定時間での取得が完了後にその平均値を算出して、ＤＢサーバ１００に送るための自サーバ負荷データ８００にして格納する。
例えば待機中のＡＰサーバ２０１の場合、Ｓ３０１で取得する自サーバの稼働状況は図８の自サーバ負荷データのようになる。
【００７５】
Ｓ３０２で複数のＡＰサーバ１０１、１０２、２０１はそれぞれ、Ｓ３０１で取得した自サーバの稼働状況をＤＢサーバ１００に送信している（自サーバ状況送信手段）。
【００７６】
Ｓ３０３で複数のＡＰサーバ１０１、１０２、２０１はそれぞれ、Ｓ５０２でＤＢサーバ１００から送信された他サーバの稼働状況を取得する（他サーバ状況取得手段）。
【００７７】
ここで他サーバの稼働状況とは、自分以外のＡＰサーバでのハードウエアリソースの使用率または使用量のことであり、例えばＣＰＵの現在の使用率、メモリ（ＲＡＭ）の利用量、ＣＰＵが処理すべきタスクの待ち行列数など、最新のハードウエアリソースの負荷状況を確認できる情報であればよい。
【００７８】
同時に、次おＳ３０４においてプログラム稼働ホストが適切かどうかの判断を行うために必要な情報として、現在のサーバ定義情報（図４の５０１）と図８の閾値データ１０００をＤＢサーバ１００から取得する。
【００７９】
例えば待機中のＡＰサーバ２０１の場合、Ｓ３０３で取得する他サーバの稼働状況は図８の他サーバ負荷データ９００のようになる。更に他サーバ負荷データ９００にはどのサーバの稼働状況かを識別するために他サーバの番号９０１と対応づけられている。
＜Ｓ３０４の第１の実施例＞
【００８０】
Ｓ３０４で現在稼働中のＡＰサーバ１０１、１０２はそれぞれ、グループで稼働しているＡＰサーバの状態が適切かどうかの判断を行う。Ｓ３０３で取得したサーバ定義情報５０１の稼働中のＡＰサーバを識別する番号を使い、稼働中のＡＰサーバに該当するＣＰＵ使用率、メモリ利用量、ｒｕｎｑｕｅｕｅの値を、閾値データ１０００のＣＰＵ使用率、メモリ利用量、ｒｕｎｑｕｅｕｅの値と比較する。
【００８１】
比較した結果、稼働中のＡＰサーバがグループ（ＡＰサーバ１０１とＡＰサーバ１０２が該当）の場合には、少なくとも１つのＡＰサーバの稼働状況が、閾値データ１０００を超えている場合にＮＧ（待機中のサーバと入れ替えるべきである）と判断する。稼働中のＡＰサーバ１０１のＣＰＵ使用率が閾値データ１０００を超えていた場合ＮＧとなる。
【００８２】
比較した結果、ＡＰサーバ１０１、ＡＰサーバ１０２の両方が、閾値データ１０００を超えない場合、ＯＫ（現時点で待機中のサーバと入れ替える必要はない）と判断する。
＜Ｓ３０４の変形例＞
また、Ｓ３０４をＡＰサーバの立場（稼働中または待機中）によって上述した判断手段を以下の様な変形例にしても良い。
【００８３】
待機中のＡＰサーバ２０１の場合、Ｓ３０１で取得した自サーバの稼働状況とＳ３０３取得した他サーバの稼働状況に基づいて、自サーバの稼働状況の方が、他サーバの稼働状況よりも一番低いか否かを判断する（稼働状況判断手段）。待機中であるＡＰサーバ２０１の稼働状況は、稼働中であるＡＰサーバ１０１、１０２の稼働状況よりも低くなるので、自サーバの稼働状況の方が、他サーバの稼働状況よりも低いか否かを判断することで、待機中であるＡＰサーバ２０１の方が他サーバとの入れ替えを判断することができる。
【００８４】
このように、待機中のＡＰサーバ２０１の場合、自サーバは、連携処理を実行するＡＰサーバとして待機中であるか否かを自ら判断しなければならない（待機判断手段）。自サーバは、連携処理を実行するＡＰサーバとして待機中であるか否かを判断は、Ｓ３０１で取得した自サーバの稼働状況によって判断してもよく、例えばＣＰＵの現在の使用率が所定時間継続して２０％を示していた場合に、待機中であると判断することができる。
【００８５】
待機中のＡＰサーバ２０１の場合、低いと判断し、かつ、待機中であると判断した場合に、Ｓ３０５に進む。逆に高いと判断し、かつ、待機中であると判断した場合に、Ｓ３０８に進むことになる。
【００８６】
稼働中のＡＰサーバ１０１や１０２の場合、Ｓ３０１で取得した自サーバの稼働状況とＳ３０３取得した他サーバの稼働状況に基づいて、自サーバの稼働状況の方が、他サーバの稼働状況よりも一番高いか否かを判断する（稼働判断手段）。稼働中であるＡＰサーバ１０１や１０２の稼働状況は、待機中であるＡＰサーバ２０１の稼働状況よりも高くなるので、自サーバの稼働状況の方が、他サーバの稼働状況よりも高いか否かを判断することで、稼働中であるＡＰサーバ１０１や１０２の方が他サーバとの入れ替えを判断することができる。
【００８７】
このように、稼働中のＡＰサーバ１０１や１０２の場合、自サーバは、連携処理を実行するＡＰサーバとして稼働中であるか否かを自ら判断しなければならない（待機判断手段）。自サーバは、連携処理を実行するＡＰサーバとして稼働中であるか否かを判断は、Ｓ３０１で取得した自サーバの稼働状況によって判断してもよく、例えばＣＰＵの現在の使用率が所定時間継続して７０％を示していた場合に、稼働中であると判断することができる。
【００８８】
稼働中のＡＰサーバ１０１や１０２の場合、高いと判断し、かつ、稼働中であると判断した場合に、Ｓ３０５に進む。逆に低いと判断し、かつ、稼働中であると判断した場合に、Ｓ３０８に進むことになる。
＜Ｓ３０５の第１の実施例＞
【００８９】
Ｓ３０５で現在稼働中のＡＰサーバ１０１、１０２はそれぞれ、Ｓ３０４の判定分岐でＮＯ（待機中のサーバと入れ替えるべきである）と判断した場合、入れ替える稼働中のＡＰサーバを選定する。サーバ定義情報５０１を保持しているので、サーバ定義情報５０１の中から閾値データ１０００を超えている稼働中のＡＰサーバを選択する。次に稼働中のＡＰサーバと入れ替える待機中のＡＰサーバを選定する。
【００９０】
Ｓ３０３で取得した他サーバの稼働状況によって、ＡＰサーバ２０１は全てのリソース値において閾値データ１０００を超えていないことが分かるので、入れ替える待機中のサーバはＡＰサーバ２０１となる。
＜Ｓ３０５の変形例＞
また、Ｓ３０５をＡＰサーバの立場（稼働中または待機中）によって上述した選択手段を以下の様な変形例にしても良い。
【００９１】
待機中のＡＰサーバ２０１の場合、図４のサーバ定義情報には、稼働するＡＰサーバとして定義されている他サーバ情報（１０１）を選択する。選択した理由としては、Ｓ３０３で取得した自分以外のＡＰサーバでのハードウエアリソースの使用率または使用量に基づいて、図４のサーバ定義情報に稼働するＡＰサーバとして定義されている他サーバ情報の中で、ＡＰサーバ１０１の稼働状況が最も負荷が高いと判断したからである。
【００９２】
稼働中のＡＰサーバ１０１や１０２の場合、図４のサーバ定義情報には、稼働するＡＰサーバとして定義されていない他サーバ情報（２０１）を選択する。選択した理由としては、Ｓ３０３で取得した自分以外のＡＰサーバでのハードウエアリソースの使用率または使用量に基づいて、他サーバ情報の中で、ＡＰサーバ２０１の稼働状況が最も負荷が低いと判断したからである。
＜Ｓ３０７の第１の実施例＞
【００９３】
Ｓ３０７で現在稼働中のＡＰサーバ１０１、１０２はそれぞれ、Ｓ３０６で選択した入れ替え対象のＡＰサーバの更新を実施する。その際にＳ３０３で取得した現在のサーバ定義情報（図４の５０１）を、入れ替え後のサーバ定義情報（図８の５０１）に書き換えて、ＤＢサーバ１００に送っても良く、ＤＢサーバ１００が保持するサーバ定義情報を、ＤＢサーバ１００側で書き換えるように、Ｓ３０６で選択した入れ替え対象のＡＰサーバの番号とともに、サーバ定義情報の書き換え要求を、ＤＢサーバ１００に送信してもよい。
＜Ｓ３０７の変形例＞
また、Ｓ３０７をＡＰサーバの立場（稼働中または待機中）によって上述した実施手段を以下の様な変形例にしても良い。
【００９４】
待機中のＡＰサーバ２０１の場合、図４の稼働するＡＰサーバとして定義されている他サーバ情報（１０１）を自サーバ情報（２０１）に更新する。そうすると図１０のように、自サーバ情報（２０１）が稼働するＡＰサーバとして定義されるようになる。
【００９５】
稼働中のＡＰサーバ１０１や１０２の場合、図４の稼働するＡＰサーバとして定義されている自サーバ情報（１０１）を他サーバ情報（２０１）に更新する。そうすると図１０のように、他サーバ情報（２０１）が稼働するＡＰサーバとして定義されるようになる。
【００９６】
このようにして、サーバ定義情報に基づいて稼働させるＡＰサーバの数は、サーバ定義情報の更新の前後で変えずに、ＡＰサーバを入れ替えている（サーバ入替手段）。
【００９７】
Ｓ３０８では、Ｓ３０４の結果によっては、Ｓ３０７に進まないので、サーバ定義情報の更新はせずに、各ＡＰサーバ１０１、１０２、２０１はそれぞれ、プリケーションサーバを入れ替えていないこともある。その後Ｓ３０１に戻って処理を繰り返す。
【００９８】
またＳ３０７から進んだ場合には、ＡＰサーバ２０１はＡＰサーバ１０１と入れ替わっているので、図１１に示したように、ＡＰサーバ２０１が、Ｓ４０９で共通プログラムの実行権を得ることになる。
次に、ＤＢサーバが読み取り実行可能なプログラムによるフローチャートを説明する。
【００９９】
スケジューラにより所定の時刻や間隔になると、Ｓ５０１乃至Ｓ５０５のループ処理プログラムを起動させ、以下のＤＢサーバが読み取り実行可能なプログラムが始まる。
Ｓ５０１でＤＢサーバ１００は、Ｓ３０２で各ＡＰサーバ１０１、１０２、２０１からそれぞれ送信してされた稼働状況を受信する。
【０１００】
Ｓ５０２でＤＢサーバ１００は、Ｓ５０１受信した、ＡＰサーバ毎のハードウエアリソースの使用率または使用量である稼働状況を集約して、複数のＡＰサーバにそれぞれ送信する（送信手段）。つまり、ＡＰサーバ２０１には、ＡＰサーバ１０１及び１０２の稼働状況を送信し、ＡＰサーバ１０１には、ＡＰサーバ２０１及び１０２の稼働状況を送信し、ＡＰサーバ１０２には、ＡＰサーバ２０１及び１０１の稼働状況を送信することになる。この際にＤＢサーバ１００にて集約される稼働状況は、図９のようになる。
【０１０１】
Ｓ５０４でＤＢサーバ１００は、Ｓ３０７において、稼働するＡＰサーバの更新情報がＡＰサーバ側から送信されて来た場合、その更新情報を受信して、保持する古い入れ替え前のサーバ定義情報をその新しいサーバ定義情報の更新情報に反映する。
Ｓ５０５でＤＢサーバ１００は、プログラムＡの実行権利を入れ替え後のＡＰサーバに提供し、図１１のように先着順にプログラムを実行するようになる。
図８を説明する。
さらに、各ＡＰサーバはそれぞれ、閾値データ１０００のような働状況の閾値を記憶している（閾値データ記憶手段）。
【０１０２】
この場合、Ｓ３０４で判断した条件に加えて、Ｓ３０３で取得した他サーバの稼働状況が閾値データ１００に到達したか否かをさらに判断して（閾値判断手段）到達したと判断した場合に、Ｓ３０７においてサーバ情報に定義されている他サーバ情報を自サーバ情報に更新するようにしてもよい。つまり閾値データ１０００のような働状況の閾値を記憶することで、閾値データ１０００をＳ３０７における入れ替えの条件にして、サーバ情報に定義されている他サーバ情報を自サーバ情報に更新する実施例も導入することができる。
図１０を説明する。
【０１０３】
サーバ定義情報の中の稼働するＡＰサーバに関して、ＡＰサーバ１０１をＡＰサーバ２０１に入れ替えた後の状態を示したものである。ＡＰサーバ２０１に入れ替えたので、今後はＡＰサーバ２０１が稼働するＡＰサーバとなり、ＡＰサーバ１０１は待機中のＡＰサーバとなる。
図１１を説明する。
【０１０４】
図１１は、図１０のようにサーバ定義情報の中の稼働するＡＰサーバ情報が更新されたので、ＡＰサーバ１０１をＡＰサーバ２０１に入れ替えた後の図３のフローチャートが変わった場合を示している。
【符号の説明】
【０１０５】
１  ＤＢサーバ（業務システムＡ）
２  ＤＢサーバ（業務システムＢ）
１００  ＤＢサーバ
１０１  ＡＰサーバ（稼働中→待機中）
１０２  ＡＰサーバ（稼働中）
２０１  ＡＰサーバ（待機中→稼働中）
２００  データ連携システム
【図１】
2017090966.tif 000003
【図２】
2017090966.tif 000004
【図３】
2017090966.tif 000005
【図４】
2017090966.tif 000006
【図５】
2017090966.tif 000007
【図６】
2017090966.tif 000008
【図７】
2017090966.tif 000009
【図８】
2017090966.tif 000010
【図９】
2017090966.tif 000011
【図１０】
2017090966.tif 000012
【図１１】
2017090966.tif 000013