(57)【要約】【課題】レコードデータ送信元のコンピュータシステムにおいて、通信ネットワークやレコード送信先コンピュータシステムの負荷が増大する事象の発生により更新完了信号の受信待ち時間が長くなっても、リアルタイムに自コンピュータシステムにおける送信レコードデータの更新を行えるようにする。【解決手段】複数のレコードデータを記憶するレコードデータ記憶部と、他コンピュータシステムからレコードデータを受信するレコードデータ受信部と、受信した前記レコードデータと前記レコードデータ記憶部の該当レコードデータとをカラムデータ毎に比較し、該比較結果と前記カラムデータの優先区分情報に基づき前記レコードデータ記憶部の該当レコードデータの更新を行うデータ比較・更新制御部と、更新完了を示す情報を前記他コンピュータシステムへ応答する更新完了応答部と、を有する。【選択図】図１１
2016062520.tif 000002
【特許請求の範囲】
【請求項１】
複数のレコードデータを記憶するレコードデータ記憶部と、
他コンピュータシステムからレコードデータをネットワークを介して受信するレコードデータ受信部と、
受信した前記レコードデータと前記レコードデータ記憶部の該当レコードデータとをカラムデータ毎に比較し、該比較結果と前記カラムデータの優先区分情報に基づき前記レコードデータ記憶部の該当レコードデータの更新を行うデータ比較・更新制御部と、
更新完了を示す情報を前記ネットワークを介して前記他コンピュータシステムへ応答する更新完了応答部と、を有する、
ことを特徴とするコンピュータシステム。
【請求項２】
前記データ比較・更新制御部は、
受信した前記レコードデータと前記レコードデータ記憶部の該当レコードデータとをカラムデータ毎に比較して一致するか否かを判定し、
不一致の場合に、該カラムデータの優先区分情報を参照し、
前記優先区分情報が当該コンピュータシステムのデータより前記他コンピュータシステムのデータを優先することを示す場合に、前記レコードデータ記憶部の該当カラムデータを更新する、
ことを特徴とする請求項１に記載のコンピュータシステム。
【請求項３】
前記データ比較・更新制御部は、
前記カラムデータ毎の比較結果が前記不一致の場合に、該カラムデータの優先区分情報を参照し、
前記優先区分情報が前記他コンピュータシステムのデータより当該コンピュータシステムのデータを優先することを示す場合に、前記不一致カラムデータを前記他コンピュータシステムへの送信対象データとする、
ことを特徴とする請求項２に記載のコンピュータシステム。
【請求項４】
前記データ比較・更新制御部は、
前記レコードデータ記憶部に、前記レコードデータ受信部により受信した前記レコードデータが無い場合、該受信レコードデータを新規レコードデータとして前記レコードデータ記憶部に登録する、
ことを特徴とする請求項１乃至請求項３の何れか１項に記載のコンピュータシステム。
【請求項５】
前記データ比較・更新制御部は、
前記レコードデータ記憶部のレコードデータの更新または前記レコードデータ記憶部への新規レコードデータの登録を行った後、予め決められたルールに基づき前記優先区分情報を更新する、
ことを特徴とする請求項４に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータシステム間でデータ同期を行う技術に関する。
【背景技術】
【０００２】
ソフトウェア開発の多様性に伴い、海外を含む遠距離多拠点で開発を行う開発形態が普及している。特に海外のオフショア開発拠点との共同開発では、上流工程の課題管理・問題管理・仕様変更管理や開発工程等で発生したバグの管理を行う問題管理システムが広く使われ、システム開発の現場で情報交換や作業エビデンスの手段として利用されている。
【０００３】
しかし、ソフトウェア開発で多く採用されるオフショア開発では、輸出管理やネットワークの制限により、海外から日本に設置の問題管理システム（サーバ）に直接アクセスできる端末が少ないため、海外拠点の開発者は、直接問題管理システムにアクセスし、管理データをリアルタイムに更新することができない。そこで、海外拠点では、開発の取り纏め担当者が、アクセス許可された端末から日本に設置の問題管理システムにアクセスし、管理データをＣＳＶなどのファイルでダウンロードし、そのＣＳＶファイルを共有モードで更新し、その更新結果を日本拠点のサーバにアップロードする作業が発生した。
【０００４】
したがって、このようは現状では、海外拠点の取り纏め担当者の作業負荷が高い反面、サーバのデータ更新が遅れ、日本拠点では海外拠点での作業状況をリアルタイムに把握することができない。さらに、海外拠点端末にＣＳＶファイルをダウンロードした時点から、日本拠点サーバの該当データに他のユーザがアクセスできない、いわゆるレコードロックの状態となる為、その間、日本拠点のユーザは該当レコードデータの更新を行うことができず、作業効率が低下するなど業務上の支障をきたす。
【０００５】
このような問題を解決可能な技術としては、例えば、特許文献１に記載の技術が知れている。この特許文献１は、遠隔地に、マスタサーバ側のコンピュータシステム（マスタサーバ、マスタデータベース、ファイル更新装置）と同様のコンピュータシステム（遠隔地サーバ、遠隔地データベース、ファイル更新装置）を設け、マスタサーバ側のコンピュータシステムが、マスタデータベースのデータファイル中のレコードデータの変更有無を、変更有無を表すフラグに基づき判断し、変更があればその変更レコードデータをネットワークを介して遠隔地サーバ側のコンピュータシステムに送信し、遠隔地サーバ側のコンピュータシステムは、受信した変更レコードデータに基づき遠隔地データベースのデータファイル中の該当レコードデータを一括して更新し、更新完了信号をマスタサーバ側のコンピュータシステムに送信し、マスタサーバ側のコンピュータシステムは、更新完了信号を受信すると、上記フラグをリセットすることで、両サーバ側のデータ同期を行う技術を開示する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−１６１９１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記従来技術では、次のような課題が発生する。例えば、一回の送信レコードデータ量が多かったり、レコードデータ受信コンピュータシステムにおけるレコードデータ更新処理が頻繁に発生しあるいは特定の時間帯に集中すると、ネットワークやレコードデータ受信コンピュータシステムの負荷が増大する。その結果、レコードデータ送信コンピュータシステムでは、レコードデータを相手コンピュータシステムへ送信してから更新完了信号を受信するまでの待ち時間が長くなり、その間、送信レコードデータの変更（更新）を行うことができないといった業務上の不都合が発生する。
【０００８】
本発明は、このような事情に鑑みてなされたものであり、レコードデータ送信元のコンピュータシステムにおいて、通信ネットワークやレコード送信先コンピュータシステムの負荷が増大する事象の発生により更新完了信号の受信待ち時間が長くなっても、リアルタイムに自コンピュータシステムにおける送信レコードデータの更新が可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するための本発明の代表的な一例は次の通りである。本発明のコンピュータシステムは、複数のレコードデータを記憶するレコードデータ記憶部と、他コンピュータシステムからレコードデータをネットワークを介して受信するレコードデータ受信部と、受信した前記レコードデータと前記レコードデータ記憶部の該当レコードデータとをカラムデータ毎に比較し、該比較結果と前記カラムデータの優先区分情報に基づき前記レコードデータ記憶部の該当レコードデータの更新を行うデータ比較・更新制御部と、更新完了を示す情報を前記ネットワークを介して前記他コンピュータシステムへ応答する更新完了応答部と、を有する。
【発明の効果】
【００１０】
本発明によれば、レコードデータ送信元のコンピュータシステムにおいて、通信ネットワークやレコード送信先コンピュータシステムの負荷が増大する事象の発生により更新完了信号の受信待ち時間が長くなっても、リアルタイムに自コンピュータシステムにおける送信レコードデータの更新を行うことができる。
【図面の簡単な説明】
【００１１】
【図１】本実施例に係る問題管理システム１００の全体構成例を示す図である。
【図２】バッチサーバ１１１のハードウェア構成及び機能概要を説明するための図である。
【図３】データベースサーバ１１２のハードウェア構成及び機能概要を説明するための図である。
【図４】アプリケーションサーバ１１３のハードウェア構成及び機能概要を説明するための図である。
【図５】問題管理テーブル３１１の構成例を示す図である。
【図６】優先区分テーブル３１２の構成例を示す図である。
【図７】優先区分コードテーブル３１３の構成例を示す図である。
【図８】問題管理データ・優先区分データ設定テーブル３１４の構成例を示す図である。
【図９】送信時刻定義テーブル３１５の構成例を示す図である。
【図１０】問題管理システム１００全体の動作概要を示すシーケンス図である。
【図１１】バッチサーバ１１１におけるデータ比較・更新制御部２２３及び優先区分設定部２２４の詳細処理を示すフローチャートである。
【図１２】データ比較・更新制御部２２３実行直前のデータベースサーバ１１２の問題管理テーブル３１１及び優先区分テーブル３１２の一例を示す図である。
【図１３】バッチサーバ１１６からバッチサーバ１１１へ送信される更新レコードデータの一例を示す図である。
【図１４】バッチサーバ１１１におけるデータ比較・更新制御部２２３の実行時、問題管理テーブル３１１のカラムデータの更新要否判定結果を示す図である。
【図１５】データ比較・更新制御部２２３実行直後の問題管理テーブル３１１の一例を示す図である。
【図１６】データ比較・更新制御部２２３実行直後の優先区分テーブル３１２の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施例について、図面を参照して詳細に説明する。
【００１３】
図１は、本実施例に係る問題管理システム１００の全体構成例を示す図である。問題管理システム１００は、上流工程の課題管理・問題管理・仕様変更履歴の管理や開発工程等で発生したバグの管理を行うシステムである。図１に示すように、本実施例に係る問題管理システム１００は、日本拠点のコンピュータシステム１０１と海外拠点のコンピュータシステム１０２とがＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１１５等のネットワークを介して接続されて構成されるコンピュータネットワークシステムである。
【００１４】
日本拠点のコンピュータシステム１０１は、バッチサーバ１１１、データベースサーバ１１２、アプリケーションサーバ１１３及び複数のユーザ端末１１４がＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１２０等のネットワークを介して相互に接続されている。同様に、海外拠点のコンピュータシステム１０２は、バッチサーバ１１６、データベースサーバ１１７、アプリケーションサーバ１１８及び複数のユーザ端末１１９がＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１２１等のネットワークを介して相互に接続されている。
【００１５】
このような問題管理システム１００において、例えば、海外拠点のコンピュータシステム１０２が管理データ中のレコードデータの更新（変更）を検知すると、その更新レコードデータをＷＡＮ１１５を介して日本拠点のコンピュータシステム１０１へ送信し、コンピュータシステム１０１は、受信したレコードデータと自コンピュータシステム１０１における管理データ中の該当レコードデータとを、カラムデータ単位で比較して一致/不一致を確認する。その結果、不一致の場合に、コンピュータシステム１０１は、そのカラムデータの優先区分情報（日本拠点コンピュータシステム１０１のデータ優先/海外拠点コンピュータシステム１０２のデータ優先など）に基づいて該当レコードの該当カラムデータの更新要否を判定し、更新要の場合に該当カラムデータの更新を行い、更新完了を表す情報（更新完了情報）をコンピュータシステム１０２へ応答する。
【００１６】
したがって、ＷＡＮ１１５や海外拠点のコンピュータシステム１０２における負荷が増大し、日本拠点のコンピュータシステム１０１における更新完了情報の受信待ち時間が長くなっても、コンピュータシステム１０１は、送信レコードデータのうち自コンピュータシステム１０１優先カラムデータの更新をリアルタイムに行うことができる。
【００１７】
次に、図２〜図９を参照して、各サーバのハードウェア構成、機能概要及び各種テーブルの構成について説明する。なお、日本拠点のコンピュータシステム１０１と海外拠点のコンピュータシステム１０２は、それぞれ同様のハードウェア構成で同様の機能を持つ為、ここでは、コンピュータシステム１０１を構成するバッチサーバ１１１、データベースサーバ１１２、アプリケーションサーバ１１３のハードウェア構成と機能概要及びコンピュータシステム１０１が具備する各種テーブルの構成について説明する。
【００１８】
図２は、バッチサーバ１１１のハードウェア構成及び機能概要を説明するための図である。バッチサーバ１１１は、一般的なコンピュータにより実現でき、ハードディスクドライブなどの不揮発性記憶装置で構成される記憶部２０１と、ＲＡＭなど揮発性記憶装置で構成されるメモリ２０３と、記憶部２０１に格納されているコンピュータプログラム２１０、２２０をメモリ２０３に読み出すなどして実行しバッチサーバ１１１自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等で構成される制御部２０２と、ＷＡＮ１１５と接続し通信処理を行うＷＡＮインタフェース部２０４と、ＬＡＮ１２０と接続し通信処理を行うＬＡＮインタフェース部２０５とを具備する。各部は、ＢＵＳ(バス)等の通信路により接続されている。
【００１９】
記憶部２０１には、本実施例のバッチサーバ１１１として必要な機能を実装するための送信プログラム２１０及び受信プログラム２２０が格納されている。送信プログラム２１０は、送信対象データ選別部２１１、データ送信部２１２、応答受信部２１３及び送信日時設定部２１４から構成される。受信プログラム２２０は、受信監視部２２１、データ受信部２２２、データ比較・更新制御部２２３、優先区分設定部２２４及び更新完了応答部２２５から構成される。
【００２０】
送信対象データ選別部２１１は、データベースサーバ１１２の問題管理テーブル３１１（図３、図５）から、海外拠点のバッチサーバ１１６への送信対象レコードデータを選別し取得する。データ送信部２１２は、送信対象データ選別部２１１により選別、取得されたレコードデータをＷＡＮ１１５を介してバッチサーバ１１６へ送信し、その送信時刻を記憶する。応答受信部２１３は、バッチサーバ１１６からＷＡＮ１１５を介して更新完了情報を受信する。送信日時設定部２１４は、応答受信部２１により更新完了情報を受信後、データ送信部２１２で記憶した送信日時を問題管理テーブル３１１の該当レコードの送信日時５１８に書き込む制御を行う。
【００２１】
受信監視部２２１は、バッチサーバ１１６からのデータ受信状況を監視する。データ受信部２２２は、バッチサーバ１１６からのデータを受信する。データ比較・更新制御部２２３は、バッチサーバ１１６から受信したレコードデータとデータベースサーバ１１２から取得した問題管理テーブル３１１の該当レコードデータとをカラムデータ単位で比較して一致/不一致を確認し、不一致の場合に優先区分情報に基づいてその不一致カラムデータの更新要否を判断し、更新要の場合に問題管理テーブル３１１の該当カラムデータを更新する制御を行う。優先区分設定部２２４は、データ比較・更新制御部２２３の実行後、問題管理データ・優先区分データ設定テーブル３１４のデータに基づいて、データベースサーバ１１２の優先区分テーブル３１２のデータを更新する制御を行う。更新完了応答部２２５は、データベースサーバ１１２からの更新完了情報をＷＡＮ１１５を介してバッチサーバ１１６へ応答する。
【００２２】
なお、上記プログラムは、予め記憶部２０１に格納されていても良いし、コンピュータが利用可能な可搬性を有する記憶媒体に格納しておき、図示していないデータ読取部を介して必要に応じて読み出されても良いし、あるいは、コンピュータが利用可能な通信媒体と接続された他の装置から必要に応じてダウンロードされて記憶部２０１に格納されるものであっても良い。
【００２３】
図３は、データベースサーバ１１２のハードウェア構成及び機能概要を説明するための図である。データベースサーバ１１２は、一般的なコンピュータにより実現でき、ハードディスクドライブなどの不揮発性記憶装置で構成される記憶部３０１と、ＲＡＭなど揮発性記憶装置で構成されるメモリ３０３と、記憶部３０１に格納されているコンピュータプログラム３１６をメモリ３０３に読み出すなどして実行しデータベースサーバ１１２自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等で構成される制御部３０２と、ＬＡＮ１２０と接続し通信処理を行うＬＡＮインタフェース部３０４とを具備する。各部は、ＢＵＳ(バス)等の通信路により接続されている。
【００２４】
記憶部３０１には、データ読出し・書込み制御を行うコンピュータプログラムとして実現するデータ更新部３１６と、業務用テーブルとして問題管理テーブル３１１、優先区分テーブル３１２、優先区分コードテーブル３１３及び問題管理データ・優先区分データ設定テーブル３１４と、通信用テーブルとして送信時刻定義テーブル３１５とが格納されている。データ更新部３１６は、バッチサーバ１１１と連携して問題管理テーブル３１１や優先区分テーブル３１２のデータを更新し、更新完了情報をバッチサーバ１１１に応答する。各種テーブル（３１１〜３１５）のデータ構成は後述する。
【００２５】
図４は、アプリケーションサーバ１１３のハードウェア構成及び機能概要を説明するための図である。アプリケーションサーバ１１３は、一般的なコンピュータにより実現でき、ハードディスクドライブなどの不揮発性記憶装置で構成される記憶部４０１と、ＲＡＭなど揮発性記憶装置で構成されるメモリ４０３と、記憶部４０１に格納されているコンピュータプログラム４１０、４２０をメモリ４０３に読み出すなどして実行しアプリケーションサーバ１１３自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等で構成される制御部４０２と、ＬＡＮ１２０と接続し通信処理を行うＬＡＮインタフェース部４０４とを具備する。各部は、ＢＵＳ(バス)等の通信路により接続されている。
【００２６】
一般ユーザプログラム４１０は、一般ユーザと管理者権限を持つユーザ（管理者）によるユーザ端末１１４への操作入力情報に基づき起動するプログラムであり、ユーザ認証部４１１、画面送信部４１２及び問題票更新部４１３から構成される。ユーザは、ユーザ認証部４１１で認証完了後、画面送信部４１２によるＷｅｂ画面などを通して、問題管理票へのデータの新規登録・更新・削除などの操作を行い、操作入力情報は問題票更新部４１３を通じてデータベースサーバ１１２の問題管理票テーブル３１１に反映される。また、ユーザの操作入力情報に基づき、問題票更新部４１３により、データベースサーバ１１２の問題管理データ・優先区分データ設定テーブル３１４のデータ設定等が行われる。
【００２７】
管理者プログラム４２０は、管理者による操作入力情報に基づき起動するプログラムであり、権限設定部４２１、送信間隔設定部４２２及び問題管理データ・優先区分データ設定部４２３から構成される。
【００２８】
管理者は、権限設定部４２１によりユーザ管理を行うことができる。また、送信間隔設定部４２２は、バッチサーバ１１１が、管理者による操作入力情報に基づいて、ＷＡＮ１１５へデータ送信を行う時刻を設定し、その時刻情報一覧をデータベースサーバ１１２の送信時刻定義テーブル３１５に登録する制御を行う。問題管理データ・優先区分データ設定部４２３は、管理者による操作入力情報に基づいて、データベースサーバ１１２の問題管理データ・優先区分データ設定テーブル３１４のデータを初期設定する制御を行う。
【００２９】
図５は、問題管理テーブル３１１の構成例を示す図である。この例では、問題管理の基本的な流れを、次の４つのステップとする。（１）起票：ある事象が発生し、起票者が問題票を提起する。（２）調査：調査担当者が事象の原因を調査する。（３）対策：調査結果に基づき、対策担当者が事象を解決するための対策を実施する。（４）確認：対策により事象が解決できたか、確認担当者が確認作業を実施する。上記各ステップの作業担当者として、日本拠点または海外拠点に所属の担当者が割り当てられる。問題管理テーブル３１１は、上記各ステップで各担当者が記入する問題票の内容及びシステムデータを管理する。
【００３０】
問題管理番号５０１は、問題票毎に付与される唯一の番号であり、問題管理テーブル３１１を検索する際の主キーとなる。問題管理番号５０１には、問題票を新規起票する際に、システムにより自動採番された情報が格納される。起票日５０２には、問題票を起票した日付情報がシステムにより自動採番され、格納される。
【００３１】
起票者５０３、件名５０４、事象５０５、調査依頼先５０６には、上記（１）起票ステップにおいて、起票者により問題票に入力された発生事象関連情報が格納される。具体的には、起票者５０３には、起票した担当者の氏名を表す情報が格納される。件名５０４には、発生した問題点の内容要約を表す情報が格納される。事象５０５には、発生した事象を表す情報が格納される。調査依頼先５０６には、調査担当者が所属する拠点を表す情報が格納される。
【００３２】
調査結果５０７、調査完了日５０８、調査担当者５０９、対策依頼先５１０には、上記（２）調査ステップにおいて、調査担当者により問題票に入力された調査関連情報が格納される。具体的には、調査結果５０７には本事象を起こした原因を表す情報が格納される。調査完了日５０８には、調査が完了した日付を表す情報が格納される。調査担当者５０９には、調査を行った担当者の氏名を表す情報が格納される。対策依頼先５１０には、対策担当者が所属する拠点を表す情報が格納される。
【００３３】
対策内容５１１、対策完了日５１２、対策担当者５１３には、上記（３）対策ステップにおいて、対策担当者により問題票に入力された対策関連情報が格納される。具体的には、対策内容５１１には、調査結果に基づき実施した対策内容を表す情報が格納される。対策完了日５１２には、対策が完了した日付を表す情報が格納される。対策担当者５１３には、対策を行った担当者の氏名を表す情報が格納される。
【００３４】
確認コメント５１４、確認日５１５、確認者５１６には、上記（４）確認ステップにおいて、確認担当者により問題票に記入された確認結果関連情報が格納される。具体的には、確認コメント５１４には、確認結果に対するコメント（問題有無など）を表す情報が格納される。確認日５１５には、確認が完了した日付を表す情報が格納される。確認者５１６には、確認を行った担当者の氏名を表す情報が格納される。
【００３５】
更新日時５１７には、問題票の更新が発生する度に、システムにより更新時刻を表す情報が格納される。送信日時５１８には、システムにより最後にバッチサーバ１１６へ送信した時刻を表す情報が格納される。起票拠点５１９には、起票時に、システムにより問題票を起票した拠点等でデータ更新の優先権を持つ拠点等を識別するコードが格納される。
【００３６】
図６は、優先区分テーブル３１２の構成例を示す図である。優先区分テーブル３１２の各カラムには、後述の問題管理データ・ 優先区分データ設定テーブル３１４（図８）に基づき、優先区分コードが格納される。優先区分テーブル３１２の各カラムは、図５で説明した各カラムと同一である、
図７は、優先区分コードテーブル３１３の構成例を示す図である。優先区分コードテーブル３１３は、優先区分コード７０１と拠点名７０２と分類７０３とからなるレコードの集合体である。
【００３７】
図７に示すように、優先区分コード「０」は、このコードが付与されたデータがシステムデータであることを意味し、日本拠点のデータと海外拠点のデータとの相違に左右されない。優先区分コード「９」は、このコードが付与されたデータについて日本拠点と海外拠点が同じ優先権を持つデータであることを意味し、日本拠点と海外拠点のデータに相違が発生した場合、問題管理テーブル３１１を参照し該当更新日時５１７が遅いデータを有効データとして扱う。優先区分コード「１」は、このコードが付与されたデータについて日本拠点のデータを海外拠点のデータより優先するデータであることを意味し、日本拠点のデータと海外拠点のデータに相違が発生した場合、日本拠点のデータを有効データとして扱う。優先区分コード「２」は、このコードが付与されたデータについて海外拠点のデータを日本拠点のデータより優先するデータであることを意味し、日本拠点のデータと海外拠点のデータに相違が発生した場合、海外拠点のデータを有効データとして扱う。なお、海外拠点の優先区分コードテーブルには、優先区分コード「２」が付与されたデータについて海外拠点のデータを日本拠点のデータより優先することを意味し、優先区分「１」が付与されたデータについて日本拠点のデータを海外拠点のデータより優先することを意味する。
【００３８】
図８は、問題管理データ・優先区分データ設定テーブル３１４の構成例を示す図である。問題管理データ・優先区分データ設定テーブル３１４は、問題管理テーブル３１１及び優先区分テーブル３１２へのデータ設定ルールを記憶する。データ項目８００は、ステップ８０１に示すように、起票、調査、対策、確認の４つの業務ステップ及びシステムの何れかのステップに分類される。問題管理テーブル３１１における起票、調査、対策、確認の４ステップの各業務データは、設定タイミング８０３に設定されたタイミングで、ユーザの操作入力情報に基づき設定される。問題管理テーブル３１１におけるシステムデータは、設定タイミング８０３に設定されたタイミングで、システムにより自動設定される。優先区分テーブル３１２における各データは、設定タイミング８０４に設定されたタイミングで、設定値５０５に設定されている設定値がシステムにより自動設定される。
【００３９】
図９は、送信時刻定義テーブル３１５の構成例を示す図である。送信時刻定義テーブル３１５は、日本拠点のバッチサーバ１１１が、海外拠点のサーバ１１６宛てのデータを送信する時刻が定義されたテーブルである。データ送信時刻は、実状況に応じて管理者により入力された送信時刻情報に基づき、アプリケーションサーバ１１３の送信間隔設定部４２２により設定される。なお、日本拠点のデータ送信時刻と海外拠点のデータ送信時刻は、必ずしも一致する必要はなく、各拠点のニーズに応じて設定できる。例えば、標準就業時間が９：００〜１８：００、昼休みが１２：００〜１３：００の場合、データ更新の頻度が少ない１２：００〜１３：００、１８：００〜翌日９：００の間のデータ送信間隔を長めに設定することで、ネットワーク負荷を分散できる。また、例えば、リアルタイム性を高める必要がある場合には、データ送信間隔を短く設定できる。
【００４０】
図１０は、問題管理システム１００全体の動作概要を示すシーケンス図である。なお、問題管理システム１００における日本拠点のコンピュータシステム１０１と海外拠点のコンピュータシステム１０２は、それぞれ同様の動作を行う為、ここでは、例として、コンピュータシステム１０１が、コンピュータシステム１０２からＷＡＮ１１５を介して更新レコードデータを受信し、受信したレコードデータと自コンピュータシステム１０１における問題管理テーブル３１１の該当レコードデータとを、カラムデータ単位で比較して一致/不一致を確認し、一致した場合に、そのカラムデータの優先区分コードに基づいて上記問題管理テーブル３１１の該当カラムデータを更新し、更新完了情報をＷＡＮ１１５を介してコンピュータシステム１０２へ応答する処理を説明する。
【００４１】
先ず、バッチサーバ１１６は、データベースサーバ１１７の送信時刻定義テーブルのデータを参照し、データ送信時刻になると、バッチを起動する（ステップＳ１００１）。そして、バッチサーバ１１６は、更新レコードデータの検索要求をＬＡＮ１２１を介してデータベースサーバ１１７へ送信する（ステップＳ１００２）。
【００４２】
データベースサーバ１１７は、更新レコードデータ検索要求を受信すると、この検索要求受信時の日時情報を記憶し（ステップＳ１００３）、更新レコードデータ検索要求に含まれる問題管理番号をキーにデータベースサーバ１１７の問題管理テーブルから前回更新レコードデータ送信後の更新レコードデータ（更新日時＞送信日時、の更新レコードデータ）を検索して取得し、その更新レコードデータをＬＡＮ１２１を介してバッチサーバ１１６に応答する（ステップＳ１００４）。
【００４３】
バッチサーバ１１６は、更新レコードデータを受信すると、その更新レコードデータをＷＡＮ１１５を介してバッチサーバ１１１へ送信する（ステップＳ１００５）。
【００４４】
バッチサーバ１１１は、更新レコードデータを受信すると、この更新レコードデータと、更新レコードデータに含まれる問題管理番号をキーにデータベースサーバ１１２の問題管理テーブル３１１から取得した該当レコードデータとをカラムデータ単位で比較して一致/不一致を確認し、一致した場合に、そのカラムデータの優先区分コードに基づいて問題管理テーブル３１１の該当カラムデータを更新する制御を行う（ステップＳ１００６、ステップＳ１００７）。また、詳細は後述するが、ステップＳ１００６とステップＳ１００７における処理において、バッチサーバ１１１は、問題管理データ・優先区分データ設定テーブル３１４のデータを参照して、優先区分テーブル３１２のデータを更新する制御を行う。
【００４５】
レコードデータ更新（ステップＳ１００７）後、データベースサーバ１１２は、更新完了情報をＬＡＮ１２０を介してバッチサーバ１１１に応答する（ステップＳ１００８）。
【００４６】
バッチサーバ１１１は、更新完了情報を受信すると、その更新完了情報をＷＡＮ１１５を介してバッチサーバ１１６へ送信する（ステップＳ１００９）。
【００４７】
バッチサーバ１１６は、更新完了情報を受信すると、その更新完了情報をＬＡＮ１２１を介してデータベースサーバ１１７へ送信する（ステップＳ１０１０）。
【００４８】
データベースサーバ１１７は、更新完了情報を受信すると、ステップＳ１００３で記憶した日時情報に基づきデータベースサーバ１１７の問題管理テーブルの該当送信日時の情報を更新する（ステップＳ１０１１）。なお、サーバ（１１１、１１２、１１６）やネットワーク（１２０、１１５、１２１）の一時的な性能低下等により、データベースサーバ１１７が更新完了情報を受信できない場合、ステップＳ１０１１の送信日時更新処理が行われない。しかし、本実施例では、次回、送信対象レコードデータの取得条件である「更新日時＞送信日時」に基づき、前回送信した更新レコードデータが再度送信対象の更新レコードデータとしてバッチサーバ１１１へ送信される為、サーバやネットワーク性能への依存度が低くなる。
【００４９】
図１１は、バッチサーバ１１１におけるデータ比較・更新制御部２２３及び優先区分設定部２２４の詳細処理を示すフローチャートである。データ比較・更新制御部２２３及び優先区分設定部２２４は、制御部２０１によりメモリ２０３に読み出され実行される。なお、ここでは、説明の便宜上、バッチサーバ１１１を動作の主体として各処理を説明する。
【００５０】
バッチサーバ１１１は、バッチサーバ１１６から問題管理番号を含む更新レコードデータを受信すると、レコード単位にステップＳ１１０１−ステップＳ１１１２の処理を行う。
【００５１】
先ずステップＳ１１０１では、バッチサーバ１１１は、データベースサーバ１１２からの該当レコードデータの検索要求の応答（検索結果）に基づき該当レコードデータの有無を判定する。判定の結果、該当レコードデータが有る場合（ステップＳ１１０１でＹＥＳ）、バッチサーバ１１１は、カラムデータ毎にステップＳ１１０２−ステップＳ１１０８の処理を行う。
【００５２】
ステップＳ１１０２では、バッチサーバ１１１は、受信した更新レコードデータのカラムデータと、検索結果である該当レコードデータのカラムデータとを比較し、その結果、両方のカラムデータが同じ場合（ステップＳ１１０２でＮＯ）、問題管理テーブル３１１の該当カラムデータを更新することなく、当該カラムデータの比較・更新制御処理を終了する。
【００５３】
受信した更新レコードデータのカラムデータと、検索結果である該当レコードデータのカラムデータとを比較した結果、カラムデータが不一致の場合（ステップＳ１１０２でＹＥＳ）、バッチサーバ１１１は、データベースサーバ１１２から問題管理番号をキーに優先区分テーブル３１２における該当カラムの設定値（優先区分コード）を取得し、その優先区分コードが「０」か否かを判定する。そして、判定の結果、優先区分コードが「０」の場合（ステップＳ１１０３でＹＥＳ）、バッチサーバ１１１は、優先区分コードテーブル３１３のデータを参照して受信カラムデータを「システムデータ」と判断し、問題管理テーブル３１１の該当カラムデータを更新することなく、当該カラムデータの比較・更新制御処理を終了する。
【００５４】
ステップＳ１１０３における判定の結果、優先区分コードが「０」でない場合（ステップＳ１１０３でＮＯ）、バッチサーバ１１１は、優先区分コードが「９」か否かを判定する（ステップＳ１１０４）。判定の結果、優先区分コードが「９」でない場合（ステップＳ１１０４でＮＯ）、バッチサーバ１１１は、優先区分コードが「１」か否かを判定する（ステップＳ１１０５）。判定の結果、優先区分コードが「１」でない（即ち、「２」）の場合（ステップＳ１１０５でＮＯ）、バッチサーバ１１１は、優先区分コードテーブル３１３のデータを参照して「海外拠点のデータを優先」と判断し、受信カラムデータに基づき、問題管理テーブル３１１の該当カラムデータを更新する制御を行う（ステップＳ１１０６）。具体的には、バッチサーバ１１１は、カラムデータの更新要求をＬＡＮ１２０を介してデータベースサーバ１１２へ送信し、データベースサーバ１１２は、この更新要求を受け、更新要求に含まれる問題管理番号とカラムデータに基づき問題管理テーブル１１３の該当カラムデータを更新する。
【００５５】
一方、ステップ１１０５において、優先区分コードが「１」の場合（ステップＳ１１０５でＹＥＳ）、バッチサーバ１１１は、優先区分コードテーブル３１３のデータを参照して「日本拠点のデータを優先」と判断し、日本拠点のデータと海外拠点のデータが不整合であることを表す自動訂正フラグ（ローカル変数）を設定し（ステップＳ１１０７）、問題管理テーブル３１１の該当カラムデータを更新することなく、当該カラムデータの比較・更新制御処理を終了する。
【００５６】
また、ステップＳ１１０４において、優先区分コードが「９」の場合（ステップＳ１１０４でＹＥＳ）、バッチサーバ１１１は、優先区分コードテーブル３１３のデータを参照し受信カラムデータを「共通データ」と判断する。そして、バッチサーバ１１１は、問題管理番号から特定した問題管理テーブル３１１の該当レコードの更新日時（５１７）とバッチサーバ１１６から受信した更新レコードデータに含まれる更新日時とを比較し、受信カラムデータと問題管理テーブル３１１の該当カラムデータの何れのカラムデータを有効データとするかを判定する（ステップＳ１１０８）。判定の結果、受信した更新レコードデータの更新日時が日問題管理テーブル３１１の更新日時より小さい場合（ステップＳ１１０８でＹＥＳ）、バッチサーバ１１１は、問題管理テーブル３１１の該当カラムデータを更新することなく、当該カラムデータの比較・更新制御処理を終了する。
【００５７】
一方、受信した更新レコードデータの更新日時が問題管理テーブル３１１の更新日時より大きい場合（ステップＳ１１０８でＹＥＳ）、バッチサーバ１１１は、受信した更新レコードデータを有効データと判断し、受信カラムデータに基づき問題管理テーブル３１１の該当カラムデータを更新する制御を行う（ステップＳ１１０６）。
【００５８】
一つのレコードの全カラムデータについてステップＳ１１０２−ステップＳ１１０８の処理が完了すると、次にバッチサーバ１１１は、自動訂正フラグの設定有無を判定し（ステップＳ１１０９）、自動訂正フラグが有る場合（ステップＳ１１０９でＹＥＳ）、当該カラムデータの問題管理番号をキーに問題管理テーブル３１１の該当更新日時５１７を現在時刻に更新する制御を行う（ステップＳ１１１０）。
【００５９】
このように、海外拠点の問題管理テーブルの一部のカラムデータが、日本拠点の問題管理テーブル３１１で更新されていない状況（日本拠点のデータと海外拠点のデータが不整合）が発生した場合、自動訂正フラグを用いることより、そのデータ不整合を回避して日本拠点の問題管理テーブル３１１のデータと海外拠点の問題管理テーブルのデータとを同期させることができる。即ち、次回、日本拠点のバッチサーバ１１１から、海外拠点のバッチサーバ１１６への送信対象レコードデータの取得条件である「更新日時５１７＞送信日時５１８」により、日本拠点のバッチサーバ１１１から海外拠点のバッチサーバ１１６に上記不整合データとして更新されていないデータが送信される為、海外拠点のバッチサーバにおけるデータ比較・更新制御により、最終的に日本拠点の問題管理テーブル３１１のデータと海外拠点の問題管理テーブルのデータとを一致させることができる。したがって、日本拠点の問題管理テーブル３１１のデータと海外拠点の問題管理テーブルのデータの一致性を常に確保できる為、日本拠点と海外拠点の各ユーザは、拠点間のデータ不一致を意識することなく、データ共有が可能になる。
【００６０】
ステップＳ１１１０の処理が完了すると、バッチサーバ１１１は、問題管理データ・優先区分データ設定テーブル３１４の設定値８０５に基づき、優先区分テーブル３１２を更新する制御を行う（ステップＳ１１１１）。
【００６１】
また、ステップＳ１１０１において、該当レコードデータが無い場合（ステップＳ１１０１でＮＯ）、バッチサーバ１１１１は、受信した更新レコードデータを新規レコードデータとして、問題管理テーブル３１１に登録する制御を行い（ステップＳ１１１２）、上述したステップＳ１１１１の優先区分テーブル３１２を更新する制御を行う。
【００６２】
このように、本実施例では、バッチサーバ１１６からバッチサーバ１１１への送信データを問題管理テーブル３１１のデータのみとし、一つのレコードデータを登録・更新する度に、問題管理テーブル３１１の最新の値を元に、優先区分テーブル３１２の更新制御を行うようにした。これにより、通信データ量を減らすことができる。
【００６３】
次に、具体的なデータ例を用いて、図１１に示した処理フローを説明する。
【００６４】
図１２は、データ比較・更新制御部２２３実行直前のデータベースサーバ１１２の問題管理テーブル３１１及び優先区分テーブル３１２の一例を示す図である。
【００６５】
図１３は、バッチサーバ１１６からバッチサーバ１１１へ送信される更新レコードデータの一例を示す図である。ここでは、図１３に示すレコードデータと、図１２に示す問題管理テーブル３１１の該当レコードデータとをカラムデータ単位で比較して一致/不一致を判定し、その結果、不一致カラムデータを、「事象」、「調査依頼先」、「調査結果」、「調査担当者」、「対策依頼先」、「更新日時」、「送信日時」とする。なお、上記更新レコードデータは、海外拠点の問題管理テーブル３１１の更新日時＞送信日時を満たすレコードデータとする。
【００６６】
図１４は、バッチサーバ１１１におけるデータ比較・更新制御部２２３の実行時、問題管理テーブル３１１のカラムデータの更新要否判定結果を示す図である。バッチサーバ１１１によるデータ比較・更新制御の結果、データベースサーバ１１２の問題管理テーブル３１１が受信カラムデータにより更新される場合を“○”、更新されない場合を“×”で示す。
【００６７】
本実施例では、バッチサーバ１１１がバッチサーバ１１６から更新レコードデータを受信すると、受信した１レコードデータ単位に、ステップＳ１１０１−ステップＳ１１１２の処理を行う。ここでは、問題管理番号１４０１が「ＢＡ−０００００１」のレコードについてカラムデータ（１４０２―１４１９）毎にステップＳ１１０２−ステップＳ１１０８の処理を行う。
【００６８】
起票日１４０２は、システムデータの為（ステップＳ１１０３でＹＥＳ）、更新されない。起票者１４０３及び件名１４０４は、カラムデータ一致（ステップＳ１１０２でＮＯ）の為、更新されない。事象１４０５は、日本拠点のデータが優先データの為（ステップＳ１１０５でＹＥＳ）、更新されない。また、この処理後、自動訂正フラグが設定される（ステップＳ１１０７）。調査依頼先１４０６は、共通データであり（ステップＳ１１０４でＹＥＳ）、かつ受信レコードデータの更新日時１３１７（２０１３/１０/１ １１：５０：００）＞問題管理テーブル３１１の更新日時５１７（２０１３/１０/１ １１：０５：００）（ステップＳ１１０８でＮＯ）の為、更新される（ステップＳ１１０６）。調査結果１４０７は、優先区分コードが「２」で海外拠点のデータが優先データの為（ステップＳ１１０５でＮＯ）、更新される（ステップＳ１１０６）。調査完了日１４０８は、データ一致（ステップＳ１１０２でＮＯ）の為、更新されない。調査担当者１４０９は、優先区分コードが「２」で海外拠点のデータが優先データの為（ステップＳ１１０５でＮＯ）、更新される（ステップＳ１１０６）。対策依頼先１４１０は、優先区分コードが「９」で共通データであり（ステップＳ１１０４でＹＥＳ）、かつ受信データの更新日時１３１８＞問題管理テーブル３１１の更新日時５１７の為（ステップＳ１１０８でＮＯ）、更新される（ステップＳ１１０６）。対策完了日１４１２―確認者１４１６は、カラムデータ一致の為（ステップＳ１１０２でＮＯ）の為、更新されない。更新日時１４１７は、優先区分が「９」で共通データであり（ステップＳ１１０４でＹＥＳ）、かつ受信データの更新日時１３１８＞問題管理テーブル３１１の更新日時５１７の為（Ｓ１１０８でＮＯ）、更新される（ステップＳ１１０６）。送信日時１４１８は、システムデータの為（ステップＳ１１０３でＹＥＳ）、更新されない。起票拠点１４１９は、システムデータの為（ステップＳ１１０３でＹＥＳ）、更新されない。ここまでの処理により、問題管理番号ＢＡ−０００００１のカラムデータ毎の処理が完了する。
【００６９】
また、事象１４０５は、データ比較・更新制御で自動訂正フラグが設定された為、更新日時１４１７が現在時刻に更新される（ステップＳ１１１０）。
【００７０】
以上説明した処理により、日本拠点の問題管理テーブル３１２における問題管理番号が「ＢＡ−０００００１」のデータ更新処理が完了し、その結果は図１５に示す通り、調査依頼先１５０６、調査結果１５０７、調査担当者１５０９、対策依頼先１５１０は、海外拠点からの受信データにより更新される。
【００７１】
引き続き、日本拠点の優先区分テーブル３１２の更新処理が行われる（ステップＳ１１１１）。ここでは、問題管理データ・優先区分データ設定テーブル３１４（図８）の優先区分テーブル３１２への設定ルール８０５に基づいて、問題管理テーブル３１１のデータを参照している優先区分テーブル３１２のデータ項目（調査結果、調査完了日、調査担当者、対策内容、対策完了日、対策担当者）の値を更新する。その結果、図１６に示す通り、調査結果１６０７、調査完了日１６０８、調査担当者１６０９の各値は、データ更新後の問題管理テーブル３１１（図１５）の調査依頼先１５０６の値に基づき、「１」に更新される。また、対策内容１６１１、対策完了日１６１２、対策担当者１６１３の各値は、問題管理テーブル３１１の対策依頼先１５１０（図１５）の値に基づき、「１」に更新される。
【００７２】
このように、本実施例では、バッチサーバ１１６から受信したレコードデータとデータベースサーバ１１２から取得した問題管理テーブル３１１の該当レコードデータとをカラムデータ単位で比較して一致/不一致を確認し、不一致の場合に優先区分情報に基づいてその不一致カラムデータの更新要否を判断し、更新要の場合に問題管理テーブル３１１の該当カラムデータを更新する制御を行う。その後、問題管理データ・優先区分データ設定テーブル３１４の優先区分テーブル３１２への設定ルール８０５に基づいて、優先区分テーブル３１２のデータを更新する制御を行う。このような制御を行う本実施例によれば、レコードデータ送信元のコンピュータシステム１０１において、更新完了信号の受信待ち時間の長短に関係なく、リアルタイムにコンピュータシステム１０１における送信レコードデータ（コンピュータシステム１０１優先データ）の更新を行うことができる。
【００７３】
以上、本発明の実施例を説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、上記実施例では、２つのコンピュータシステム間におけるデータ同期方法について説明したが、３つ以上のコンピュータシステムがあっても同様に本発明を適用できる。
【００７４】
また、上記プログラムを、例えば集積回路（ＬＳＩ）で設計すること等によりハードウェアにより実現しても良い。
【符号の説明】
【００７５】
１１１・・・日本拠点のバッチサーバ、１１２・・・日本拠点のデータベースサーバ、１１３・・・日本拠点のアプリケーションサーバ、１１４・・・日本拠点のユーザ端末、１２０・・・日本拠点のＬＡＮ、１１５・・・ＷＡＮ、１１６・・・海外拠点のバッチサーバ、１１７・・・海外拠点のデータベースサーバ、１１８・・・海外拠点のアプリケーションサーバ、１１９・・・海外拠点のユーザ端末、１２１・・・海外拠点のＬＡＮ。
【図１】
2016062520.tif 000003
【図２】
2016062520.tif 000004
【図３】
2016062520.tif 000005
【図４】
2016062520.tif 000006
【図５】
2016062520.tif 000007
【図６】
2016062520.tif 000008
【図７】
2016062520.tif 000009
【図８】
2016062520.tif 000010
【図９】
2016062520.tif 000011
【図１０】
2016062520.tif 000012
【図１１】
2016062520.tif 000013
【図１２】
2016062520.tif 000014
【図１３】
2016062520.tif 000015
【図１４】
2016062520.tif 000016
【図１５】
2016062520.tif 000017
【図１６】
2016062520.tif 000018