(57)【特許請求の範囲】
【請求項１】
外部のノード端末から送信されるデータをバッチ処理することにより情報処理サービスを提供する業務情報システムとして、正系システムおよび副系システムを備え、
前記正系システムには複数の情報処理サービスに対応して複数のサーバが含まれており、前記副系システムには前記複数の情報処理サービスのうちの一部の情報処理サービスに対応するサーバが欠けている状況において、
前記正系システムと前記副系システムは、前記バッチ処理を時間的に並行してそれぞれ実行し、
前記副系システムは、前記バッチ処理において、前記欠けているサーバに関する処理については、その処理を無効またはその処理の代わりとなる処理を実行し、
前記正系システムの正常作動時においては、前記正系システムのみが前記バッチ処理の結果を正式な結果データとして出力し、
前記副系システムは、前記正系システムの異常が検出されたときには、前記正系システムに代わって、前記副系システムによる前記バッチ処理の結果を正式な結果データとして出力することを特徴とする耐障害業務情報システム。
【請求項２】
前記副系システムは、前記欠けているサーバに関する処理の代わりとなる処理として、前記正系システムに含まれる前記欠けているサーバに対応するサーバからデータを取得する処理を実行することを特徴とする請求項１に記載の耐障害業務情報システム。
【請求項３】
前記副系システムは、前記バッチ処理において、前記欠けているサーバからのデータ取得命令を実行する代わりに前記正系システムにデータを要求するためのデータ要求命令を実行し、
前記正系システムは、前記データ要求命令が受信されたとき、前記正系システムに含まれる前記欠けているサーバのデータを前記副系システムに送信することを特徴とする請求項１または２に記載の耐障害業務情報システム。
【請求項４】
前記副系システムは、前記正系システムの異常が検出されたときには、前記正系システムから取得されるべきデータのうちの所定データについては、異常検出前に取得したデータに基づいて前記バッチ処理を続行することを特徴とする請求項２または３に記載の耐障害業務情報システム。
【請求項５】
前記副系システムは、前記欠けているサーバへのデータ入力命令を無効化することを特徴とする請求項１に記載の耐障害業務情報システム。
【請求項６】
前記正系システムと前記副系システムは、同一のコンピュータ・プログラムにより前記バッチ処理を時間的に並行してそれぞれ実行し、
前記副系システムは、前記正系システムの異常が検出されたか否かに応じて、前記コンピュータ・プログラムの設定を変更することを特徴とする請求項１から５のいずれかに記載の耐障害業務情報システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務情報システムに関連し、特に、その障害対策技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支える業務情報システム、いわゆるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤となっている。業務情報システムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力することにより、複雑化する組織マネジメントを支えている。企業基盤、ひいては社会基盤ともいうべき業務情報システムには、高い信頼性が求められる。
【０００３】
一例として、小売店・チェーンを管理するための業務情報システムを想定する。この業務情報システムを構成するサーバ群は、札幌のデータセンターに集積されているとする。この場合、地震により札幌のデータセンターが機能停止すると、全国的にサービスが停止してしまう。
【０００４】
そこで、札幌とは地理的に充分離れた場所、たとえば、那覇にもバックアップ用の業務情報システムを設置しておく。通常時は札幌の業務情報システムにより情報処理サービスを提供し、札幌の被災時には那覇の業務情報システムが情報処理サービスを提供する。札幌と那覇が同時期に被災しない限りサービスを継続できる。札幌に設置される通常時用の業務情報システムは「正系システム」、那覇に設置される非常時用の業務情報システムは「副系システム」とよばれる。
【０００５】
通常時において札幌の正系システムは、全国の小売店から送られてくる売上情報をバッチ処理し、売れ行きの解析、在庫管理、商品発注といったさまざまな情報処理サービスを提供する。バッチ処理の結果は、札幌のデータベースと那覇のデータベースの両方に記録される。札幌が被災すると、那覇の副系システムが正系システムに代わって売上情報をバッチ処理し、情報処理サービスを提供する。那覇のデータベースには、被災前のバッチ処理の結果が保存されているので、正系システムから副系システムに切り替わっても、業務の継続性が保たれる。
【特許文献１】特開２００７−２６５０３０号公報
【特許文献２】特開２００６−０４８１０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ただし、業務情報システム、特に、大規模な業務情報システムの起動には、多くの作業員が携わる。たとえば、札幌の正系システムが所定データベースへの書き込み中に、札幌が被災し、那覇の副系システムがこのデータベースから処理結果を引き継ぐ場合、那覇の副系システムを起動する際には、データベースにおいて有効に確定しているデータと未確定の状態にあるデータを特定し、そのうえで、関連するデータ間の整合性を保つために、一部のデータを更新前の状態に戻すなどの作業が発生する。このため、札幌が被災したときに那覇の副系システムを速やかに起動するためには、すぐに那覇に作業員を派遣するか、あるいは、あらかじめ充分な作業員を那覇に常駐させておかなければならない。また、業務情報システムの起動自体にも時間がかかる。那覇に十分な作業員がいたとしても、札幌の正系システムが停止してから、那覇の副系システムが起動するまでは、ある程度のサービス停止期間が発生せざるを得ない。特に、近年の業務情報システムの大規模化にともない、その起動コストは益々高くなりつつある。
【０００７】
本発明は、上記課題に基づいて完成された発明であり、その主たる目的は、正系システムから副系システムへの切り換えを短時間にて実行するための技術、を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のある態様は、業務情報システムに関する。
この業務情報システムは、正系システムおよび副系システムを備え、外部のノード端末から送信されるデータをバッチ処理することにより情報処理サービスを提供する。副系システムは、正系システムが被災した場合の想定被災範囲外に設置される。正系システムと副系システムは、同じバッチ処理を時間的に並行してそれぞれ実行する。通常時においては正系システムのみがバッチ処理の結果を正式な結果データとして出力し、被災時においては副系システムがバッチ処理の結果を正式な結果データとして出力する。
【０００９】
なお、以上に示した各構成要素の任意の組み合わせ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、正系システムから副系システムへの切り換えを短時間にて実行できる。
【発明を実施するための最良の形態】
【００１１】
図１は、業務情報システム１００のハードウェア構成図である。
業務情報システム１００は、正系システム１０２と副系システム１０４を含む。正系システム１０２と副系システム１０４は専用回線により接続される。正系システム１０２は、札幌のデータセンターに設置される。
【００１２】
副系システム１０４は、正系システム１０２が被災したときの想定被災範囲外に設置される。札幌に震度５以上の地震が発生したときには、正系システム１０２を停止させるとする。過去の事例から、震度５以上の範囲の平均半径は１００ｋｍであるとする。この場合、想定被災範囲は札幌を中心とした半径１００ｋｍの地域である。副系システム１０４は札幌から１００ｋｍ以上離れた地域に設置されることが望ましい。想定被災範囲は、地震や津波、火事、テロ等のさまざまな外部要因について、過去の事例やシミュレーションから決定すればよい。
【００１３】
以上の理由に基づき、本実施例の副系システム１０４は那覇のデータセンターに設置される。以下、正系システム１０２および副系システム１０４を特に区別せずにいうときには、単に「システム」とよぶ。情報処理サービスの提供主体となる側のシステムのことを「主システム」とよび、反対側を「従システム」とよぶ。通常時においては、札幌の正系システム１０２が主システム、那覇の副系システム１０４が従システム（バックアップ）である。非常時、すなわち、札幌被災時においては、那覇の副系システム１０４が主システムとなる。
【００１４】
本実施例の業務情報システム１００は、全国の小売店の売り上げを集計し、在庫状態や売れ筋を分析し、商品発注を行う。正系システム１０２で実行されるコンピュータ・プログラム（以下、「制御プログラム」とよぶ）は、副系システム１０４で実行される制御プログラムと全くの同一である。ただし、制御プログラムは、後述の実行モードに応じて一部の処理内容が変化するようにコーディングされている。
【００１５】
業務情報システム１００は、インターネット１０８などの通信回線を介して、ノード端末１０６ａ、１０６ｂ、・・・、１０６ｃ（以下、単に「ノード端末１０６」とよぶ）と接続される。本実施例のノード端末１０６は、主として、各店舗に設置されるＰＯＳ（Point Of Sales）端末である。各ノード端末１０６は、各店舗の売上情報を業務情報システム１００に送信する。業務情報システム１００は、売上情報を収集・蓄積し、どの店舗やどの地域でどのような商品がいつどのくらい売れているかを分析する。
【００１６】
たとえば、地域Ａの各店舗の売上情報を集計し、地域Ａ全体における商品Ｂの在庫状態を把握し、商品Ｂが品薄となっているときには、商品Ｂを発注する。地域Ａで商品Ｂが品薄でも、隣の地域Ｃで商品Ｂの在庫が潤沢であれば、地域Ｃの集配センターに指示して、商品Ｂを地域Ａに配送させてもよい。地域Ｄに比べて地域Ｅの方が商品Ｆの売り上げが好調であれば、地域Ｄの集配センターに指示して、商品Ｆを地域Ｅに配送させてもよい。業務情報システム１００は、各店舗の売上情報を入力データとして、小売店・チェーン全体を統括する。
【００１７】
全国の売上情報は、正系システム１０２と副系システム１０４の双方に入力される。
本実施例においては、東日本のノード端末１０６は売上情報を正系システム１０２へ送信し、西日本のノード端末１０６は売上情報を副系システム１０４に送信する。正系システム１０２は東日本の売上情報を副系システム１０４に送信し、副系システム１０４は西日本の売上情報を正系システム１０２に送信する。このような処理方法により、正系システム１０２と副系システム１０４はいずれも全国の売上情報を取得する。
【００１８】
正系システム１０２と副系システム１０４は、１日４回、売上情報をそれぞれバッチ処理する。バッチ処理の開始タイミングは、３：００、１０：００、１６：００、２２：００であるとする。３：００〜１０：００に受信された売上情報は、１０：００になると、正系システム１０２と副系システム１０４により別々にバッチ処理される。バッチ処理の結果（以下、「結果データ」とよぶ）は、後続システム１１０に送信される。後続システム１１０は、別の業務情報システムであってもよいし、単なるデータベースであってもよい。
【００１９】
正系システム１０２の制御プログラムと副系システム１０４の制御プログラムは同一であるため、正系システム１０２の結果データと副系システム１０４の結果データも同一となる。ただし、通常時においては、正系システム１０２のみが結果データを後続システム１１０に送信し、副系システム１０４の結果データは破棄される。通常時において、副系システム１０４のバッチ処理は、後続システム１１０に影響しない。すなわち、通常時においては、正系システム１０２と副系システム１０４は、同一の売上情報を同一のタイミングにて同一の制御プログラムによりバッチ処理し、同一の結果データを生成するが、結果データを有効に出力するのは正系システム１０２のみである。
【００２０】
札幌被災時、すなわち、非常時においては、正系システム１０２は停止し、副系システム１０４が主システムとなる。非常時においては、副系システム１０４のみが全国の売上情報をバッチ処理し、結果データを後続システム１１０に送信する。後続システム１１０は、通常時も非常時も業務情報システム１００から結果データを受け取ることができる。
【００２１】
副系システム１０４は非常時に起動されるのではなく、常に、正系システム１０２と並行して動作している。非常時において副系システム１０４を起動する作業が不要であるため、正系システム１０２から副系システム１０４へ主システムを速やかに切り換えることができる。
【００２２】
小売店本部の管理者は、管理端末１１２を介して、業務情報システム１００に「リアルタイム命令」を送信することもできる。リアルタイム命令とは、たとえば、特定商品の販売を中止させたり、特定店舗の現状報告を要求したりといった、即時の対応を必要とする命令である。業務情報システム１００は、リアルタイム命令を受信すると、該当するリアルタイム処理を実行する。リアルタイム処理の処理主体は主システムのみである。リアルタイム処理については、図８に関連して詳述する。
【００２３】
図２は、業務情報システム１００の内部構成図である。
正系システム１０２は、サーバＡ〜Ｄの４種類のサーバと正系データベース１１６を含む。１台あたりの処理負荷を軽減するため、サーバＡは多重化されている。また、サーバＡの多重化は、正系システム１０２の信頼性向上にも資する。同様の理由から、サーバＤも多重化されている。
各サーバの役割は、以下の通りである。
サーバＡ：ノード端末１０６から売上情報を収集・蓄積し、バッチ処理の開始タイミングに至ると、売上情報を「売上ファイル」としてファイル化する。
サーバＢ：店舗や地域ごとに各商品の在庫量を計算する。計算結果を「在庫ファイル」としてファイル化する。
サーバＣ：店舗や地域ごとの売れ筋商品を特定したり、売れ筋商品を予測する。計算結果を「売れ筋ファイル」としてファイル化する。
サーバＤ：在庫ファイルや売れ筋ファイルに基づいて、発注対象商品と発注先店舗を特定し、その結果を「発注ファイル」としてファイル化する。
【００２４】
副系システム１０４は、サーバＡ、Ｂ、Ｄと副系データベース１１８を含む。副系システム１０４には、サーバＣが欠けている。副系システム１０４においても正系システム１０２と同一の制御プログラムが実行され、非常時においては副系システム１０４が主システムとなるため、正系システム１０２と副系システム１０４は同一のサーバ構成であることが望ましい。
【００２５】
しかし、副系システム１０４は、非常時のみにしか主システムとして機能しないため、すべてのサーバを副系システム１０４にも導入することはＴＣＯ（Total Cost of Ownership）の観点から必ずしも実際的ではない。本実施例の副系システム１０４には、特に基幹的機能を担うサーバＡ、Ｂ、Ｄのみが導入されている。同様の理由から、サーバＡやサーバＤは多重化されていない。
制御プログラムは、このようにハードウェア構成が互いに異なる正系システム１０２と副系システム１０４のいずれにおいても動作可能なプログラムである。
【００２６】
図３は、制御プログラム１２０の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置との協働により実現される。制御プログラム１２０は、システム内の複数のサーバにより分散実行される。
【００２７】
制御プログラム１２０を構成する命令群は、ＩＦ（インタフェース）部１２２と実行部１４０に大別される。ＩＦ部１２２は、ノード端末１０６、後続システム１１０および管理端末１１２に対するインタフェースとなる部分である。ＩＦ部１２２は、正系データベース１１６や副系データベース１１８等とのインタフェースとしても機能する。実行部１４０は、バッチ処理やリアルタイム処理を実行する部分である。
【００２８】
制御プログラム１２０は、３種類の実行モードＭ１、Ｍ２、Ｍ３を有する。
Ｍ１：通常時における正系システム１０２での実行モード
Ｍ２：通常時における副系システム１０４での実行モード
Ｍ３：非常時における副系システム１０４での実行モード
非常時においては正系システム１０２は停止するため、正系システム１０２の実行モードはＭ１のみである。
【００２９】
ＩＦ部１２２は、データ収集部１２４、データ出力部１２８、設定部１３０、リアルタイム命令取得部１３２および異常信号取得部１３４を含む。設定部１３０は、システムの環境設定ファイルを参照し、実行モードを設定する。正系システム１０２であれば実行モードＭ１、副系システム１０４であれば実行モードＭ２を設定する。副系システム１０４の実行モードＭ２時に後述する異常信号が検出されたときには、実行モードＭ３を設定する。
【００３０】
データ収集部１２４は、各ノード端末１０６から売上情報を受信する。データ収集部１２４は、データ交換部１２６を含む。正系システム１０２のデータ交換部１２６（Ｍ１）は東日本の売上情報を副系システム１０４のデータ交換部１２６（Ｍ２）に送信する。一方、副系システム１０４のデータ交換部１２６（Ｍ２）は西日本の売上情報を正系システム１０２のデータ交換部１２６（Ｍ１）に送信する。非常時の副系システム１０４（Ｍ３）の場合、データ収集部１２４は全国のノード端末１０６から売上情報をまとめて受信する。非常時においては、副系システム１０４のデータ交換部１２６（Ｍ３）は、正系システム１０２とのデータ交換を実行しない。
【００３１】
データ出力部１２８は、正系データベース１１６、副系データベース１１８、後続システム１１０、ノード端末１０６、管理端末１１２等に各種データを出力する。リアルタイム命令取得部１３２は、リアルタイム命令を取得する。リアルタイム命令を取得するのは正システム（Ｍ１、Ｍ３）だけであり、従システム（Ｍ２）はリアルタイム命令を取得しない。非常時において、管理者は管理端末１１２を介して、正系システム１０２（Ｍ１）を緊急停止させると共に副系システム１０４（Ｍ２）に「異常信号」を送信する。実行モードＭ２時に異常信号が受信されると、設定部１３０は実行モードをＭ２からＭ３に変更し、副系システム１０４は、以後、主システムとなる。
【００３２】
制御プログラム１２０の一部は、
if(mode == M1)
...code1
else if(mode == M2)
...code2
else
...code3
という条件分岐文形式にてコーディングされており、実行モードに応じてその処理内容を変化させる。上記擬似コードでは、実行モードＭ１時にはcode1、実行モードＭ２時にはcode2、実行モードＭ３時にはcode3が実行される。
【００３３】
図４は、通常時におけるバッチ処理の流れを示す模式図である。
正系システム１０２のサーバＡと副系システム１０４のサーバＡの双方には、全国の売上情報が蓄積される。
正系システム１０２（実行モードＭ１）：
サーバＡは、売上情報を取得し（Ｙ１）、売上ファイルを生成し、サーバＢに渡す（Ｙ２）。サーバＢは、売上ファイルを参照し、店舗および地域ごとの在庫量を計算し、在庫ファイルを生成する。売上ファイルはサーバＢからサーバＣに渡される（Ｙ３）。サーバＣは、この売上ファイルを参照し、売れ筋の特定および予測を実行し、その処理結果を示す売れ筋ファイルを生成する。売れ筋ファイルはサーバＢに渡される（Ｙ４）。サーバＤは、サーバＢから、在庫ファイルと売れ筋ファイルを受け取り（Ｙ５）、発注対象商品と発注先店舗を決定し、発注ファイルを生成する。発注ファイルは後続システム１１０に渡される（Ｙ６）。後続システム１１０は、発注ファイルにしたがって、商品配送を手配する。
【００３４】
副系システム１０４（実行モードＭ２）：
副系システム１０４においても、基本的な処理内容は同様である。サーバＡは、売上情報を取得し（Ｏ１）、サーバＢに売上ファイルを渡す（Ｏ２）。サーバＢは、売上ファイルを参照し、在庫ファイルを生成する。売上ファイルはサーバＢからサーバＣにも渡されるべきであるが（Ｙ３に対応）、副系システム１０４にはサーバＣが存在しない。実行モードＭ２においては、副系システム１０４に存在しないサーバＣに対するデータ入力命令が無効化される。具体的には、
if(mode == M1)
...サーバＣに売上ファイルを入力するデータ入力命令
else if(mode == M2)
...NOP（No Operation）
else
...NOP（No Operation）
という形式にてコーディングされている。
【００３５】
副系システム１０４にはサーバＣが存在しないので、副系システム１０４のサーバＢは正系システム１０２のサーバＢにアクセスし、正系システム１０２のサーバＣが生成した売れ筋ファイルを取得する（Ｏ３）。具体的には、
if(mode == M1)
...サーバＣから売れ筋ファイルを受け取るデータ取得命令
else if(mode == M2)
...正系システム１０２に売れ筋ファイルを要求するデータ要求命令
else
...NOP（No Operation）
という形式にてコーディングされている。データ要求命令は、ＦＴＰ（File Transfer Protocol）のget命令のように、既存の通信プロトコルの応用により実現される。データ取得命令の代わりにデータ要求命令を実行することにより、サーバＣを有しない副系システム１０４であっても、売れ筋ファイルを取得できる。サーバＤは、サーバＢから、在庫ファイルと売れ筋ファイルを受け取り（Ｏ４）、発注対象商品と発注先店舗を決定し、発注ファイルを生成する。ただし、実行モードＭ２時においては、発注ファイルは後続システム１１０に渡されない。
このように、正系システム１０２と副系システム１０４のサーバ構成が不一致であっても、同一のデータ（売上情報）に基づいて、同一の制御プログラムにより同一のバッチ処理が並行実行される。
【００３６】
図５は、通常時におけるバッチ処理の基本的な流れを示すフローチャートである。
制御プログラム１２０（Ｍ１またはＭ２）は、各ノード端末１０６からの売上情報を取得する（Ｓ１０）。次に、実行部１４０の機能として、ジョブを実行すべきサーバを特定する（Ｓ１２）。正系（Ｍ１）であれば（Ｓ１４のＹ）、該当のサーバが該当の処理を実行する（Ｓ１８）。副系（Ｍ２）であるが（Ｓ１４のＮ）、処理主体となるべきサーバが存在しているときにも（Ｓ１６のＹ）、該当の処理が実行される（Ｓ１８）。図４のサーバＣのように、処理主体となるべきサーバが存在しないときには（Ｓ１４のＮ、Ｓ１６のＮ）、正系システム１０２から処理結果を取得する（Ｓ２０）。
【００３７】
バッチ処理が未了のときには（Ｓ２２のＮ）、次に処理主体となるべきサーバを特定する（Ｓ１２）。バッチ処理が完了したとき（Ｓ２２のＹ）、正系（Ｍ１）であれば（Ｓ２４のＹ）、データ出力部１２８は結果データとしての発注ファイルを後続システム１１０に出力する（Ｓ２６）。副系（Ｍ２）の場合には（Ｓ２２のＹ、Ｓ２４のＮ）、発注ファイルは破棄される。
【００３８】
図６は、非常時におけるバッチ処理の流れを示す模式図である。
正系システム１０２が被災したとき、管理者は管理端末１１２を介して異常信号を副系システム１０４に送信する。正系システム１０２は停止される。
変形例として、正系システム１０２は定期的に生存信号を副系システム１０４に送信し、副系システム１０４は生存信号の受信失敗により正系システム１０２の異常や停止を検出してもよい。たとえば、所定期間以上生存信号が受信されなければ、正系システム１０２が異常であると判定してもよい。
更に変形例として、札幌のデータセンター内に通信機能付きの震度計を設置してもよい。所定震度以上、たとえば、震度５以上が計測されたとき、震度計は正系システム１０２に停止信号を送信し、副系システム１０４に異常信号を送信してもよい。いずれにしても、正系システム１０２の異常が検出されると、副系システム１０４の実行モードはＭ２からＭ３に移行する。
【００３９】
非常時において正系システム１０２は停止するため、全国の売上情報は副系システム１０４のみに入力される。札幌被災時においては、札幌近辺のノード端末１０６からの売上情報を取得できなくなるかもしれないが、被災地域以外、たとえば、九州地方や中国地方からの売上情報は継続して取得できるかもしれない。非常時においては、副系システム１０４は、取得可能な売上情報に基づいてバッチ処理を実行する。
【００４０】
副系システム１０４（実行モードＭ３）：
サーバＡは、売上情報を取得し（Ｏ１）、サーバＢに売上ファイルを渡す（Ｏ２）。サーバＢは、売上ファイルを参照し、店舗および地域ごとの在庫量を計算して在庫ファイルを生成する。実行モードＭ３においては、副系システム１０４に存在しないサーバＣへデータを入力する命令（データ入力命令）は無効化される。
【００４１】
また、正系システム１０２は停止中であるため、通常時（実行モードＭ２）のように正系システム１０２から売れ筋ファイルを取得することもできない。このため、実行モードＭ３においては、正系システム１０２から売れ筋ファイルを要求するためのデータ要求命令も無効化される。
【００４２】
結果として、サーバＤは、サーバＢから在庫ファイルのみを取得する（Ｏ４）。そして、発注対象商品と発注先店舗を決定し、発注ファイルを生成し、後続システム１１０に発注ファイルを送信する（Ｏ４）。通常時（実行モードＭ１、Ｍ２）においては、在庫ファイルと売れ筋ファイルに基づいて発注ファイルが生成されるが、非常時（実行モードＭ３）においては在庫ファイルのみに基づいて発注ファイルが生成される。非常時においては、サーバＣによる売れ筋商品の特定や予測サービスは停止することになる。サーバＣを副系システム１０４に導入するか否かは、サーバＣにより実現される機能の重要性とサーバＣの導入コストに鑑みて決定されればよい。
【００４３】
なお、副系システム１０４は、正系システム１０２から取得したデータを副系データベース１１８に適宜保存する。たとえば、図４のＯ３において、サーバＢから取得した売れ筋ファイルは副系データベース１１８に保存される。非常時においては、副系システム１０４は、通常時において取得していた売れ筋ファイルに基づいて、バッチ処理を実行してもよい。たとえば、１０：００にバッチ処理を実行したあと、１３：１２に地震が発生し、副系システム１０４が主システム（実行モードＭ３）となったとする。副系システム１０４は、正系システム１０２による１０：００のバッチ処理の結果として生成された売れ筋ファイルを保持している。次のバッチ処理の開始タイミングである１６：００になっても正系システム１０２が復旧していなければ、副系システム１０４（実行モードＭ３）は、１０：００の売れ筋ファイルと１６：００の在庫ファイルに基づいて、発注ファイルを生成してもよい。
【００４４】
更に次回のバッチ処理の開始タイミングである２２：００になっても正系システム１０２が復旧していない場合、副系システム１０４は２２：００の在庫ファイルのみに基づいて、発注ファイルを生成してもよい。１０：００の売れ筋ファイルは、２２：００に使用するには「鮮度」が低すぎるとの判断に基づく。
売れ筋ファイルの最新データが存在しないからといって、発注ファイルを生成する処理が停止してしまうと業務上の影響は大きくなる。そもそも、売れ筋ファイルは比較的重要度の低いデータであり、最新データが存在しなくても業務上の影響は小さい。そこで、売れ筋ファイルを新たに受け取れなくても、サービスの継続性が保たれるように設計されている。
【００４５】
図７は、非常時におけるバッチ処理の基本的な流れを示すフローチャートである。
同図のフローチャートは実行モードＭ３の制御プログラムによる処理内容を示す。副系システム１０４において、実行モードＭ３の制御プログラム１２０は、各ノード端末１０６からの売上情報を取得する（Ｓ３０）。次に、ジョブを実行すべきサーバを特定する（Ｓ３２）。処理主体となるべきサーバが存在していれば（Ｓ３４のＹ）、該当の処理が実行される（Ｓ３６）。図６のサーバＣのように、処理主体となるべきサーバが存在しないときには（Ｓ３４のＮ）、Ｓ３６はスキップされる。
【００４６】
バッチ処理が未了のときには（Ｓ３８のＮ）、次に処理主体となるべきサーバを特定する（Ｓ３２）。バッチ処理が完了したとき（Ｓ３８のＹ）、データ出力部１２８は結果データとしての発注ファイルを後続システム１１０に出力する（Ｓ４０）。
【００４７】
上述したように、制御プログラムはＭ１〜Ｍ３の３つの実行モードに応じて処理内容の一部が変化するが、正系システム１０２用と副系システム１０４用に別々の制御プログラムを用意する必要はない。このため、制御プログラムのメインテナンスに要する負荷が大きく軽減される。
【００４８】
図８は、リアルタイム処理の流れを示す模式図である。
同図は、通常時におけるリアルタイム処理の流れを示している。通常時において、管理端末１１２から、商品Ｘの販売中止を指示したとする。この指示は各店舗に即時の対応を求める「リアルタイム命令」である。業務情報システム１００は、リアルタイム命令を受信すると、商品Ｘを販売禁止設定し、各ノード端末１０６に通達する。このようなリアルタイム処理は、主システム（Ｍ１またはＭ３）のみが処理主体となる。
【００４９】
まず、管理端末１１２は通常時の主システムである正系システム１０２（Ｍ１）にリアルタイム命令を送信する（Ｒ１）。サーバＢが販売禁止設定を担当する。サーバＢは、商品Ｘを所定の販売禁止ファイルに登録し、正系データベース１１６に保存する（Ｒ２）。サーバＢはサーバＡを介して、各ノード端末１０６に商品Ｘの販売禁止を一斉通知する。こうして、サーバＢによるリアルタイム処理は実質的に完了する。
【００５０】
サーバＢは、リアルタイム処理の完了後、完了信号を副系システム１０４（Ｍ２）に送信する（Ｒ３）。副系システム１０４は、リアルタイム命令取得部１３２の機能により、完了信号を受信する。副系システム１０４は、正系データベース１１６から販売禁止ファイルを取得し（Ｒ４）、販売禁止ファイルを副系データベース１１８にも保存する（Ｒ５）。実際にリアルタイム処理を実行するのは正系システム１０２（Ｍ１）だけであるが、リアルタイム処理の結果を示す販売禁止ファイルは正系システム１０２と副系システム１０４の双方に保持される。実行のタイミングが不定で処理内容が多様なリアルタイム処理の処理主体は、主システムのみである。このため、業務情報システム１００全体としての処理負荷が軽減されている。
【００５１】
非常時においては、副系システム１０４（Ｍ３）のみがリアルタイム処理を実行する。ただし、副系システム１０４（Ｍ３）は、リアルタイム処理が完了しても完了信号を正系システム１０２に送信しない。正系システム１０２が停止しているためである。正系システム１０２は復旧に際して、副系システム１０４から各種処理の結果を取得する。
【００５２】
以上、実施例に基づいて業務情報システム１００について説明した。
業務情報システム１００によれば、正系システム１０２のバッチ処理中に副系システム１０４も同一データをバッチ処理する。このため、非常時に副系システム１０４を起動する必要がなく、速やかな主システムの切り換えを実現できる。また、正系システム１０２と副系システム１０４のサーバ構成が異なっても、同一の制御プログラム１２０を実行できるため、制御プログラム１２０のメンテナンスにともなう作業負担が軽減される。更に、リアルタイム処理を主システムのみにより実行することにより業務情報システム１００全体としての処理負荷を抑制しつつ、正系システム１０２と副系システム１０４のデータ同期を保つことができる。
【００５３】
非常時に副系システム１０４の起動作業が不要であるため、副系システム１０４の所在地に作業員を派遣・常駐させるためのコストを大きく低減できる。このため、那覇のように交通至便な地域に限らず、交通の不便な地域であっても地震などの天災が少ない地域を副系システム１０４の設置場所として選択しやすくなる。
【００５４】
以上、本発明について実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５５】
リアルタイム処理に関し、業務情報システム１００は、
外部の管理端末からリアルタイム処理の実行を指示するためのリアルタイム命令を受信したときには、前記正系システムのみが前記リアルタイム処理を実行し、
前記正系システムは、前記リアルタイム処理の実行後に前記副系システムに前記リアルタイム処理の完了を通知し、
前記副系システムは、前記リアルタイム処理の完了を通知されたとき前記正系システムから前記リアルタイム処理の結果を取得する、としてもよい。
【００５６】
また、業務情報システム１００において、
前記副系システムは、前記正系システムの異常が検出された後に前記リアルタイム命令を受信したことを条件として、前記正系システムに代わって前記リアルタイム処理を実行する、としてもよい。
【図面の簡単な説明】
【００５７】
【図１】業務情報システムのハードウェア構成図である。
【図２】業務情報システムの内部構成図である。
【図３】制御プログラムの機能ブロック図である。
【図４】通常時におけるバッチ処理の流れを示す模式図である。
【図５】通常時におけるバッチ処理の基本的な流れを示すフローチャートである。
【図６】非常時におけるバッチ処理の流れを示す模式図である。
【図７】非常時におけるバッチ処理の基本的な流れを示すフローチャートである。
【図８】リアルタイム処理の流れを示す模式図である。
【符号の説明】
【００５８】
１００  業務情報システム、  １０２  正系システム、  １０４  副系システム、  １０８  インターネット、  １０６  ノード端末、  １１０  後続システム、  １１２  管理端末、  １１６  正系データベース、  １１８  副系データベース、  １２０  制御プログラム、  １２２  ＩＦ部、  １２４  データ収集部、  １２６  データ交換部、  １２８  データ出力部、  １３０  設定部、  １３２  リアルタイム命令取得部、  １３４  異常信号取得部、  １４０  実行部。
【図１】
0005283970.tif 000002
【図２】
0005283970.tif 000003
【図３】
0005283970.tif 000004
【図４】
0005283970.tif 000005
【図５】
0005283970.tif 000006
【図６】
0005283970.tif 000007
【図７】
0005283970.tif 000008
【図８】
0005283970.tif 000009