(57)【要約】【課題】連携元サーバのデータベースからデータが削除されることに応じて保存される履歴に基づいて、連携元サーバから連携先サーバに対して適切にデータの削除指示を送信することの可能な仕組みを提供すること【解決手段】連携元サーバ１０１は、クライアント端末１０４またはシステム管理端末１０３からデータベースのデータの削除要求を受信するとデータベースから当該データの削除を実行する。そして、この削除要求のうち、クライアント端末１０４からユーザの指示により削除指示があった場合には、操作履歴を残しておく。連携元サーバ１０１は、連携先サーバ１０２に対してもデータの削除を指示する場合に、操作履歴にあるデータのみ削除要求を送信する。【選択図】図１
2014130575.tif 000002
【特許請求の範囲】
【請求項１】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムであって、
前記クライアント端末は、
ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの削除を指示する第１の削除指示手段と、
前記連携元サーバに対して前記第１のデータベースに含まれるデータのうち、有効期限の切れたデータの削除を指示する第２の削除指示手段と
を備え、
前記連携元サーバは、
前記第１の削除指示手段、または前記第２の削除指示手段で指示されたデータの削除を前記第１のデータベースに対して実行する第１の削除手段と、
前記第１の削除指示手段からの指示に応じて前記削除手段で削除されたデータの履歴を保存する削除履歴保存手段と、
前記第１の削除手段で削除したデータのうち、前記削除履歴保存手段で保存された履歴に存在するデータの削除指示を前記連携先サーバに送信する第３の削除指示手段と
を備え、
前記連携先サーバは、
前記第３の削除指示手段で指示されたデータの削除を前記第２のデータベースに対して実行する第２の削除手段
を備えることを特徴とするデータ連携システム。
【請求項２】
前記連携元サーバは、
前記第２の削除手段で削除が実行された履歴を反映済みとして更新する削除履歴更新手段を更に備え、
前記第３の削除指示手段は、前記削除履歴保存手段で保存された履歴のうち、未反映となっているデータの削除指示を、前記連携先サーバに送信することを特徴とする請求項１に記載のデータ連携システム。
【請求項３】
前記削除履歴保存手段は、削除指示を行ったユーザに応じて、削除履歴を保存するか否かを決定することを特徴とする請求項１または２に記載のデータ連携システム。
【請求項４】
前記第１の削除手段及び前記第２の削除手段における削除は、物理削除であることを特徴とする請求項１乃至３のいずれか１項に記載のデータ連携システム。
【請求項５】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムの制御方法であって、
前記クライアント端末の第１の削除指示手段が、ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの削除を指示する第１の削除指示ステップと、
前記クライアント端末の第２の削除指示手段が、前記連携元サーバに対して前記第１のデータベースに含まれるデータのうち、有効期限の切れたデータの削除を指示する第２の削除指示ステップと
前記連携元サーバの第１の削除手段が、前記第１の削除指示ステップ、または前記第２の削除指示ステップで指示されたデータの削除を前記第１のデータベースに対して実行する第１の削除ステップと、
前記連携元サーバの削除履歴保存手段が、前記第１の削除指示ステップからの指示に応じて前記削除手段で削除されたデータの履歴を保存する削除履歴保存ステップと、
前記連携元サーバの第３の削除指示手段が、前記第１の削除ステップで削除したデータのうち、前記削除履歴保存ステップで保存された履歴に存在するデータの削除指示を前記連携先サーバに送信する第３の削除指示ステップと、
前記連携先サーバの第２の削除手段が、前記第３の削除指示ステップで指示されたデータの削除を前記第２のデータベースに対して実行する第２の削除ステップと
を備えることを特徴とするデータ連携システムの制御方法。
【請求項６】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムの制御方法を実行可能なプログラムであって、
前記クライアント端末を、
ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの削除を指示する第１の削除指示手段と、
前記連携元サーバに対して前記第１のデータベースに含まれるデータのうち、有効期限の切れたデータの削除を指示する第２の削除指示手段
として機能させ、
前記連携元サーバを、
前記第１の削除指示手段、または前記第２の削除指示手段で指示されたデータの削除を前記第１のデータベースに対して実行する第１の削除手段と、
前記第１の削除指示手段からの指示に応じて前記削除手段で削除されたデータの履歴を保存する削除履歴保存手段と、
前記第１の削除手段で削除したデータのうち、前記削除履歴保存手段で保存された履歴に存在するデータの削除指示を前記連携先サーバに送信する第３の削除指示手段と
として機能させ、
前記連携先サーバを、
前記第３の削除指示手段で指示されたデータの削除を前記第２のデータベースに対して実行する第２の削除手段
として機能させることを特徴とするプログラム。
【請求項７】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムであって、
前記クライアント端末は、
ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの物理削除を指示する第１の物理削除指示手段
を備え、
前記連携元サーバは、
前記第１の物理削除指示手段で指示されたデータの物理削除を前記第１のデータベースに対して実行する第１の物理削除手段と、
前記第１の物理削除手段で削除したデータの論理削除の指示を前記連携先サーバに送信する論理削除指示手段と、
前記論理削除指示手段で論理削除の指示をしてから所定時間経過した場合に、前記論理削除指示手段で論理削除の指示がなされたデータの物理削除指示を前記連携先サーバに送信する第２の物理削除指示手段と
を備え、
前記連携先サーバは、
前記論理削除指示手段で指示されたデータの論理削除を前記第２のデータベースに対して実行する論理削除手段と、
前記第２の物理削除指示手段で指示されたデータの物理削除を前記第２のデータベースに対して実行する第２の物理削除手段と
を備えることを特徴とするデータ連携システム。
【請求項８】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムの制御方法であって、
前記クライアント端末の第１の物理削除指示手段が、ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの物理削除を指示する第１の物理削除指示ステップと、
前記連携元サーバの第１の物理削除手段が、前記第１の物理削除指示ステップで指示されたデータの物理削除を前記第１のデータベースに対して実行する第１の物理削除ステップと、
前記連携元サーバの論理削除指示手段が、前記第１の物理削除ステップで削除したデータの論理削除の指示を前記連携先サーバに送信する論理削除指示ステップと、
前記連携元サーバの第２の物理削除指示手段が、前記論理削除指示ステップで論理削除の指示をしてから所定時間経過した場合に、前記論理削除指示ステップで論理削除の指示がなされたデータの物理削除指示を前記連携先サーバに送信する第２の物理削除指示ステップと、
前記連携先サーバの論理削除手段が、前記論理削除指示ステップで指示されたデータの論理削除を前記第２のデータベースに対して実行する論理削除ステップと、
前記連携先サーバの第２の物理削除手段が、前記第２の物理削除指示ステップで指示されたデータの物理削除を前記第２のデータベースに対して実行する第２の物理削除ステップと
を備えることを特徴とするデータ連携システムの制御方法。
【請求項９】
第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムの制御方法を実行可能なプログラムであって、
前記クライアント端末を、
ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの物理削除を指示する第１の物理削除指示手段
として機能させ、
前記連携元サーバを、
前記第１の物理削除指示手段で指示されたデータの物理削除を前記第１のデータベースに対して実行する第１の物理削除手段と、
前記第１の物理削除手段で削除したデータの論理削除の指示を前記連携先サーバに送信する論理削除指示手段と、
前記論理削除指示手段で論理削除の指示をしてから所定時間経過した場合に、前記論理削除指示手段で論理削除の指示がなされたデータの物理削除指示を前記連携先サーバに送信する第２の物理削除指示手段
として機能させ、
前記連携先サーバを、
前記論理削除指示手段で指示されたデータの論理削除を前記第２のデータベースに対して実行する論理削除手段と、
前記第２の物理削除指示手段で指示されたデータの物理削除を前記第２のデータベースに対して実行する第２の物理削除手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースのデータ管理に関し、特に異なるデータベース間で連携すべきデータとそうでないデータとを判定し、適切に連携することの可能なデータ連携システム、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、企業のシステム等で利用するためにデータベースが活用されている。データベースには、企業のシステムで利用するための各種データがデータベースに格納されており、必要に応じて登録、更新、削除等の編集作業が行われている。
【０００３】
基本的にこのようなデータベースは、１つではない。このデータベースに障害が発生した場合でも企業の業務に影響を与えることのないよう、バックアップ用のデータベースが用意されている。バックアップ用のデータベースは、夜間バッチ等によってメインのデータベースに反映されたデータを適宜更新している。そして、メインのデータベースに障害が発生した場合には、システム管理者は、バックアップ用のデータベースに切り替えて、メインのデータベースの復元作業を行うことができる。
【０００４】
このようなバックアップ用のデータベースを作成するための仕組みとして、下記の特許文献１には、異なる論理構造を持つ更新先データベースと更新元データベースにおいて、更新元テーブルの更新レコードデータをリアルタイムに更新先データベースに転送すると共に、更新先データベースがダウンしている場合には、復元後に更新元テーブルに蓄積された未反映更新レコードデータを転送する仕組みが開示されている。
【０００５】
また、下記の特許文献２には、分散コンピューティング環境において、一部のサーバが停止していても複数のデータベース間の整合性を取るために、メインサーバに対して発行されたＳＱＬ文に従って生成された、ＳＱＬ文を格納したファイルをメインサーバに保存し、サブサーバが起動しているときに、このファイルを転送し、ファイルに格納されたＳＱＬ文を実行する仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−１９４７１７号公報
【特許文献２】特開２００１−２６５６３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
近年、企業における情報システムには、企業の業務及びサービスの中核を担う基幹系システムの他に、システム利用者(エンドユーザ)が、基幹系システムに蓄積された情報を直接的に活用し、個々の必要な用途に応じて加工・編集することを目的として情報系システムが構築されることがある。
【０００８】
このような物理的に異なるデータベースが複数存在する場合、データの整合性を保つため、業務データが蓄積される基幹系システムから情報系システムへ日々データの連携を行う必要がある。例えば、図１４に示すように、クライアント端末からデータの登録、更新、削除を基幹系システムのサーバに要求すると、データの登録、更新、削除がなされた後、情報系システムのサーバに変更内容の転送が行われる。こうすることで、情報系システムにデータを蓄積し、それを用いてデータの閲覧、加工、分析等を行うことができる。
【０００９】
この連携を実現するにあたり、従来の先行技術では、基幹系システムに蓄積されているデータを単純にそのまま情報系システムに連携することが多かったが、情報系システムはサービス利用者の利用要件によって多様な形態を有することが多く、基幹系システムと情報系システムでデータの保持要件が異なるケースがある。この場合、従来のような単純な連携では情報系システムの要件を満たすことが出来ないため、異なる保持用件を満たしたデータ連携を行うことができる専用のシステムを構築する必要がある。
【００１０】
データの保持要件の例を挙げる。例えば、基幹系システムでは、企業の業務、サービスの中核を担うデータベースを持っている。このデータベースでは、日々膨大な業務データを蓄積しているため、データの肥大化抑制やごみデータの排除、また処理の高速化を図るため、一定期間、特定の条件を満たしたデータを随時物理的に削除する処理が行われている。従って、データ保持要件は、個々に定められた有効な保持期間内のデータのみを保持することである。一方、情報系システムでは、システム利用者が、業務の効率化を図る目的や顧客のニーズを解析するためなどに利用するデータベースを持っている。このデータベースでは、過去の情報についても半永久的に保持することが求められている。従って、データ保持要件は、全てのデータを半永久的に保持することである。
【００１１】
このように、データ保持要件が異なることにより、単純にデータ連携を行うことができない場合、連携先データベースの保持要件に合致している場合は連携を行い、合致していない場合は連携しないという判定処理が必要となるが、この連携要否の判定をユーザが判断するとなると、システム運用を行う上で、非常に非効率となる。
【００１２】
特に、データを物理削除する場合には、データ保持要件を考慮しないといけない。物理削除とは、論理削除のようにデータは残して削除フラグを立てて削除されたことにするのではなく、データベースからデータを削除してしまうことである。
【００１３】
図１５に示すように、連携元である基幹系システムの物理削除には、入力ミスで誤って登録してしまったデータを削除する場合と、データ保持要件にもある通り、データの肥大化抑制やごみデータの排除、また処理の高速化を図るため、一定期間、特定の条件を満たしたデータを随時物理的に削除する場合の２通りがある。従来の仕組みであれば、基幹系システムの連携元データベースからデータが物理削除されると、どのような物理削除であっても、情報系システムの連携先データベースからも物理削除が行われてしまっていた。しかしながら、情報系システムのデータ保持要件は、全てのデータを半永久的に保持することであり、物理削除が行われてよいのは、入力ミスで誤って登録してしまったデータを削除する場合である。よって、基幹系システムと情報系システムでデータベースの連携を行う場合には、単純に連携するのではなく、データの保持要件を考慮しないと、どちらかのデータベースに不備が発生してしまう問題があった。
【００１４】
更には、入力ミスで誤って登録してしまったデータを物理削除したが、当該物理削除が誤りであった場合、連携先データベース及び連携元データベースの両方から物理削除されてしまっているので、当該データが復元できなくなってしまう問題もある。ユーザの運用でヒューマンエラーを完全に防ぐことは困難であるため、当該データを復元できる仕組みが望まれている。
【００１５】
本発明は上記の課題を鑑みてなされたもので、連携元サーバのデータベースからデータが削除されることに応じて保存される履歴に基づいて、連携元サーバから連携先サーバに対して適切にデータの削除指示を送信することの可能な仕組みを提供することを第１の目的とする。
【００１６】
また、本発明は上記の課題を鑑みてなされたもので、ユーザからデータの物理削除が指示された場合であっても、当該データを所定時間復元することの可能な状態にする仕組みを提供することを第２の目的とする。
【課題を解決するための手段】
【００１７】
上記の第１の目的を達成するために、本発明のデータ連携システムは、第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムであって、前記クライアント端末は、ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの削除を指示する第１の削除指示手段と、前記連携元サーバに対して前記第１のデータベースに含まれるデータのうち、有効期限の切れたデータの削除を指示する第２の削除指示手段とを備え、前記連携元サーバは、前記第１の削除指示手段、または前記第２の削除指示手段で指示されたデータの削除を前記第１のデータベースに対して実行する第１の削除手段と、前記第１の削除指示手段からの指示に応じて前記削除手段で削除されたデータの履歴を保存する削除履歴保存手段と、前記第１の削除手段で削除したデータのうち、前記削除履歴保存手段で保存された履歴に存在するデータの削除指示を前記連携先サーバに送信する第３の削除指示手段とを備え、前記連携先サーバは、前記第３の削除指示手段で指示されたデータの削除を前記第２のデータベースに対して実行する第２の削除手段を備えることを特徴とする。
【００１８】
また、上記の第２の目的を達成するために、第１のデータベースを備える連携元サーバと、第２のデータベースを備える連携先サーバと、前記第１のデータベースを操作するクライアント端末とを備えるデータ連携システムであって、前記クライアント端末は、ユーザからの指示に応じて、前記連携元サーバに対して前記第１のデータベースに含まれるデータの物理削除を指示する第１の物理削除指示手段を備え、前記連携元サーバは、前記第１の物理削除指示手段で指示されたデータの物理削除を前記第１のデータベースに対して実行する第１の物理削除手段と、前記第１の物理削除手段で削除したデータの論理削除の指示を前記連携先サーバに送信する論理削除指示手段と、前記論理削除指示手段で論理削除の指示をしてから所定時間経過した場合に、前記論理削除指示手段で論理削除の指示がなされたデータの物理削除指示を前記連携先サーバに送信する第２の物理削除指示手段とを備え、前記連携先サーバは、前記論理削除指示手段で指示されたデータの論理削除を前記第２のデータベースに対して実行する論理削除手段と、前記第２の物理削除指示手段で指示されたデータの物理削除を前記第２のデータベースに対して実行する第２の物理削除手段とを備えることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、ユーザが削除指示を行った場合に、操作履歴を連携元サーバに残し、削除されたデータを連携先サーバに連携する際に、当該データに関する操作履歴があるか否かに応じて連携の要否を決定することが可能となるので、連携先データベースと連携元データベースのデータ保持要件が異なる場合であっても、適切にデータを連携することのできる効果を奏する。また、物理削除が指示された場合であっても、連携先サーバに対しては論理削除を指示するため、連携先サーバからデータを復元することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の実施形態におけるデータ連携システム１００の一例を示す構成図である。
【図２】図１に示す連携元サーバ１０１、連携先サーバ１０２、システム管理端末１０３、クライアント端末１０４のハードウェア構成の一例を示す構成図である。
【図３】図１に示す連携元サーバ１０１、連携先サーバ１０２、システム管理端末１０３、クライアント端末１０４のモジュール構成の一例を示す構成図である。
【図４】本発明の実施形態における一連の処理の流れを示すフローチャートである。
【図５】連携元サーバ１０１と連携先サーバ１０２に記憶された業務データテーブル５００の構成の一例を示す構成図である。
【図６】業務データ編集画面６００の一例を示す構成図である。
【図７】システム管理端末から論理削除の要求を送信する際の一連の処理の流れを示すフローチャートである。
【図８】データ転送対象テーブル８００及びデータ転送対象カラムテーブル８１０の一例を示す構成図である。
【図９】論理削除転送処理の詳細を示すフローチャートである。
【図１０】物理削除処理の詳細を示すフローチャートである。
【図１１】操作履歴テーブル１１００の一例を示す構成図である。
【図１２】システム管理端末から業務データの消し込みを要求する際の一連の処理の流れを示す構成図である。
【図１３】物理削除転送処理の詳細を示すフローチャートである。
【図１４】従来の基幹系システムと情報系システムにおける業務データの論理削除の処理の流れを示す概要図である。
【図１５】従来の基幹系システムと情報系システムを物理削除で運用する場合の問題点を示す概要である。
【図１６】第２の実施形態における、物理削除処理の詳細を示すフローチャートである。
【図１７】第２の実施形態における、操作履歴テーブル１１００の一例を示す構成図である。
【図１８】第２の実施形態における、物理削除転送処理の詳細を示すフローチャートである。
【図１９】第２の実施形態における、論理削除後、一定時間が経過している業務データの物理削除指示を送信する処理の詳細を示すフローチャートである。
【図２０】第２の実施形態における、業務データを復元するための処理の詳細を示すフローチャートである。
【図２１】第２の実施形態の処理概要を示す図である。
【発明を実施するための形態】
【００２１】
以下、図面を参照して、本発明の実施の形態の一例について説明する。
【００２２】
図１は、本発明のデータ連携システム１００のシステム構成の一例を示す図である。本発明のデータ連携システム１００は、連携元サーバ１０１、連携先サーバ１０２、システム管理端末１０３が設置されており、それら装置はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０５を介して相互にデータ通信可能に接続されている。また、クライアント端末１０４−１やクライアント端末１０４−２（以下、クライアント端末１０４）は、ＬＡＮ等のネットワーク１０６を介して連携元サーバ１０１と相互にデータ通信可能に接続されている。図１のネットワーク１０５及びネットワーク１０６上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００２３】
連携元サーバ１０１は、基幹系システムを動作させるサーバである。クライアント端末１０４にインストールされたアプリケーションを通じて、基幹系システムで管理しているデータベースの登録、更新、削除を行う。本実施形態における基幹系システムは、企業の管理業務で利用されるシステムとして説明を行うが、これに限らない。
【００２４】
また、連携元サーバ１０１は、連携先サーバ１０２とデータの連携を行う。クライアント端末１０４からデータベースの登録、更新、削除が行われると、連携先サーバ１０２に存在する同様のデータベースに対して、クライアント端末１０４から操作された内容の反映を指示するようになっている。または、システム管理端末１０３からの定期的な要求によっても、同様に動作する。
【００２５】
連携先サーバ１０２は、情報系システムを動作させるサーバである。情報系システムは、連携元サーバ１０１の基幹系システムに蓄積された情報を活用して、データの加工、分析を行うためのシステムである。また、連携先サーバ１０２の情報系システムには、連携元サーバ１０１に記憶されたデータベースと同様のものが記憶されており、連携元サーバ１０１からの要求に応じて、データベースの登録、更新、削除を実行する。本実施形態における情報系システムは、データの加工、分析を行うためのシステムとして説明を行うが、これに限らない。
【００２６】
システム管理端末１０３は、連携元サーバ１０１や連携先サーバ１０２に記憶されたデータベースの管理を行う装置である。また、連携元サーバ１０１に対して、有効期限を過ぎたデータの削除命令を定期的に送信する。
【００２７】
クライアント端末１０４は、連携元サーバ１０１に記憶されたデータベースの登録、更新、削除を要求する装置である。クライアント端末１０４にインストールされたアプリケーションを通じて、これらの操作を受け付けて、連携元サーバ１０１の基幹系システムのデータベースを操作する。
【００２８】
図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。
【００２９】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００３０】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ)やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００３１】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００３２】
また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。
【００３３】
ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。
【００３４】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３５】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００３６】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３７】
本発明の連携元サーバ１０１、連携先サーバ１０２、システム管理端末１０３、クライアント端末１０４が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。
【００３８】
次に、連携元サーバ１０１、連携先サーバ１０２、システム管理端末１０３、クライアント端末１０４のモジュール構成を示す機能構成図について、図３を用いて説明する。尚、図３の各種端末あるいはサーバのモジュール構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００３９】
連携元サーバ１０１は、送受信制御モジュール３０１、判定制御モジュール３０２、業務テーブル管理モジュール３０３、操作履歴テーブル管理モジュール３０４、データ転送管理情報管理モジュール３０５、削除モジュール３０６を備える。
【００４０】
送受信制御モジュール３０１は、連携先サーバ１０２やシステム管理端末１０３、クライアント端末１０４と各種情報を送受信するためのモジュールである。各装置との送受信のプロトコルは、特に問わない。各装置間で各種情報の送受信ができる、適切なプロトコルを適宜選択する。
【００４１】
判定制御モジュール３０２は、連携元サーバ１０１が各種情報に応じて各種判定をするためのモジュールである。処理を分岐させるための分岐条件や、処理を反復する場合の反復終了条件に応じて、処理の流れを決定するために動作させる。
【００４２】
業務テーブル管理モジュール３０３は、後述する図５に示す業務データテーブル５００を管理するためのモジュールである。また、操作履歴テーブル管理モジュール３０４は、後述する図１１に示す操作履歴テーブル１１００を管理するためのモジュールである。また、データ転送管理情報管理モジュール３０５は、後述する図８のデータ転送管理情報（データ転送対象テーブル８００とデータ転送対象カラムテーブル８１０）を管理するためのモジュールである。これらの管理モジュールは、システム管理端末１０３やクライアント端末１０４からの要求に応じて、各テーブルの登録、更新、削除を行う。更に、登録、更新、削除が行われると、当該操作がなされたデータを読み出して、送受信制御モジュール３０１を介して、連携先サーバ１０２に送信する。また、システム管理端末１０３やクライアント端末１０４からの要求に応じて、必要なデータを読み出して、これらの装置に送信する。
【００４３】
削除モジュール３０６は、業務テーブル管理モジュール３０３が管理している業務データテーブル５００のデータベースに登録されたデータの論理削除または物理削除を実行するためのモジュールである。論理削除とは、後述する削除フラグ５０２を立てて、基幹系システムでは削除したものと見なす処理である。一方、物理削除とは、データベースからデータを削除してしまう処理である。論理削除はデータを残しておくが、物理削除はデータを残さずに削除してしまう点に違いがある。
【００４４】
連携先サーバ１０２は、送受信制御モジュール３１１、業務テーブル管理モジュール３１２、削除モジュール３１３を備える。
【００４５】
送受信制御モジュール３１１、業務テーブル管理モジュール３１２、削除モジュール３１３は、前述した連携元サーバ１０１が備える送受信制御モジュール３０１、業務テーブル管理モジュール３０３、削除モジュール３０６と同様の機能を有する。
【００４６】
システム管理端末１０３は、送受信制御モジュール３２１、判定制御モジュール３２２、表示制御モジュール３２３、定期削除モジュール３２４を備える。
【００４７】
送受信制御モジュール３２１、判定制御モジュール３２２は、前述した連携元サーバ１０１の送受信制御モジュール３２１、判定制御モジュール３０２と同様の機能を有する。
【００４８】
表示制御モジュール３２３は、各種情報や画面をＣＲＴ２１０に表示させるためのモジュールである。表示させるＣＲＴ２１０は、システム管理端末１０３に備えられたＣＲＴ２１０であってもよいし、システム管理端末１０３に接続されたＣＲＴ２１０であってもよい。または、ネットワークを通じてクライアント端末１０４のＣＲＴ２１０に表示させてもよい。表示先は特に問わない。
【００４９】
定期削除モジュール３２４は、連携元サーバ１０１に蓄積されたデータを定期的に削除するための要求を発信するモジュールである。連携元サーバ１０１は、基幹系システムを動作させているので、有効期限を過ぎた不要なデータは定期的に削除する必要がある。よって、定期削除モジュール３２４は、連携元サーバ１０１に対して、定期的に有効期限切れデータの削除要求を送信する。
【００５０】
クライアント端末１０４は、送受信制御モジュール３３１、判定制御モジュール３３２、表示制御モジュール３３３を備える。
【００５１】
送受信制御モジュール３３１、判定制御モジュール３３２、表示制御モジュール３３３は、前述したシステム管理端末１０３の送受信制御モジュール３３１、判定制御モジュール３３２、表示制御モジュール３３３と同様の機能を有する。
【００５２】
次に、本発明の実施形態における連携元サーバ１０１とクライアント端末１０４によって行われる一連の処理について、図４に示すフローチャートを用いて説明する。尚、ステップＳ４０１、ステップＳ４０２、ステップＳ４０６乃至ステップＳ４０９、ステップＳ４１３乃至ステップＳ４１７の各ステップは、クライアント端末１０４におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ４０３乃至ステップＳ４０５、ステップＳ４１０乃至ステップＳ４１２の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【００５３】
また、この処理を連携元サーバ１０１とクライアント端末１０４に実行させるためのプログラムは、連携元サーバ１０１、クライアント端末１０４にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００５４】
ステップＳ４０１では、クライアント端末１０４は、クライアント端末１０４の外部メモリ２１１に記憶された基幹系システムのアプリケーションを起動する。そして、ステップＳ４０２では、クライアント端末１０４は、起動したアプリケーションで表示するための業務データの取得要求を連携元サーバ１０１に送信する。
【００５５】
ステップＳ４０３では、連携元サーバ１０１は、クライアント端末１０４から送信された業務データの取得要求を受信する。そして、ステップＳ４０４では、連携元サーバ１０１は、その取得要求に応じて、業務データテーブル５００から業務データを取得する。業務データは、業務データテーブル５００に格納されたデータである。業務データテーブル５００の１レコードを業務データとしてもよいし、特定のカラムのデータを業務データとしてもよい。
【００５６】
ステップＳ４０５では、連携元サーバ１０１は、ステップＳ４０４で取得した業務データをクライアント端末１０４に送信する。
【００５７】
ステップＳ４０６では、クライアント端末１０４は、連携元サーバ１０１から送信された業務データを受信する。そして、ステップＳ４０７では、クライアント端末１０４は、ステップＳ４０６で受信した業務データを埋め込んだ業務データ編集画面６００（図６参照）を、クライアント端末１０４のＣＲＴ２１０に表示させる。そして、ユーザからの操作を受け付ける。業務データ編集画面６００は、表示された業務データの検索や、編集、削除（論理削除）、完全削除（物理削除）を行うことができる画面である。業務データ編集画面６００には、検索ボタン６０１、編集ボタン６０２、削除ボタン６０３、完全削除ボタン６０４が備えられており、これらのボタンの押下に応じて各種処理を実行する。論理削除と物理削除が行える画面であれば、これに限らない。
【００５８】
ステップＳ４０８では、クライアント端末１０４は、ユーザからの操作により、業務データの論理削除が指示されたか否かを判定する。具体的には、業務データ編集画面６００に表示された任意の業務データが選択された状態で、削除ボタン６０３が押下されたか否かを判定すればよい。削除ボタン６０３は、論理削除を行うためのボタンである。論理削除が指示されたと判定された場合には、ステップＳ４０９に処理を進め、そうでない場合には、ステップＳ４１４に処理を進める。
【００５９】
ステップＳ４０９では、クライアント端末１０４は、ユーザから削除指示された業務データを取得し、連携元サーバ１０１に対して当該業務データの論理削除要求を送信する。
【００６０】
ステップＳ４１０では、連携元サーバ１０１は、クライアント端末１０４から送信された業務データの削除要求を受信する。そして、ステップＳ４１１では、連携元サーバ１０１は、ステップＳ４１０で受信した削除要求に応じて、当該業務データの論理削除を実行する。論理削除は、前述した通りデータを削除するわけではない。あくまで、削除フラグを立てるだけである。よって、ステップＳ４０９で送信される論理削除要求とは、削除フラグの更新要求である。この論理削除要求を受け付けると、業務データテーブル５００に格納された業務データの削除フラグ５０２を「０」から「１」に変更する。つまり、削除フラグを立てる。こうすることで、削除したものと見なして、業務データは残しておく。
【００６１】
業務データテーブル５００（図５参照）は、テーブルＩＤ５１１、主キー５０１、削除フラグ５０２、登録日時５０３、登録者ＩＤ５０４、登録ＰＧ（プログラム）ＩＤ５０５、登録端末名５０６、更新日時５０７、更新ＰＧ（プログラム）ＩＤ５０８、更新端末名５０９、リビジョン５１０から構成される。テーブルＩＤ５１１は、業務データテーブル５００を一意に識別するための識別子を示す情報である。業務データテーブル５００は、目的等に応じて複数存在する。そのため、テーブルＩＤ５１１で、この複数の業務データテーブル５００を識別している。テーブルＩＤ５１１は、各サーバ内で一意であればよい。主キー５０１は、業務データの内容を示す。例えば、勘定科目やその金額、販売物流等の情報である。削除フラグ５０２は、論理削除による業務データの削除を行っているか否かを判定するためのフラグである。この削除フラグ５０２の値により削除済のデータかどうかが判別される。登録日時５０３、登録者ＩＤ５０４、登録ＰＧＩＤ５０５、登録端末名５０６は、業務データの登録が行われた時に格納される情報である。登録された日時、登録したユーザのユーザＩＤ、登録したプログラムのＩＤ、登録したクライアント端末１０４の端末名を格納しておく。また、更新日時５０７、更新ＰＧＩＤ５０８、更新端末名５０９も同様に、更新時に格納される情報である。そして、リビジョン５１０は、データ更新されるたびにカウントアップされる項目であり、データ更新時の排他制御処理等で使用される。業務データテーブル５００の構成は一例であり、他のカラムが含まれてもよい。
【００６２】
ステップＳ４１２では、連携元サーバ１０１は、ステップＳ４１１で実行された論理削除の処理結果をクライアント端末１０４に送信する。そして、ステップＳ４１３では、クライアント端末１０４は、連携元サーバ１０１から送信された処理結果を受信し、ステップＳ４１４に処理を進める。ここで処理が失敗していることがわかった場合には、再度ステップＳ４０９を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【００６３】
ステップＳ４１４では、クライアント端末１０４は、ユーザからの操作により、業務データの物理削除が指示されたか否かを判定する。具体的には、業務データ編集画面６００に表示された任意の業務データが選択された状態で、完全削除ボタン６０４が押下されたか否かを判定すればよい。完全削除ボタン６０４は、物理削除を行うためのボタンである。物理削除が指示されたと判定された場合には、ステップＳ４１５に処理を進め、そうでない場合には、ステップＳ４１６に処理を進める。
【００６４】
ステップＳ４１５では、クライアント端末１０４は、選択された業務データを物理削除するための処理を実行する。物理削除処理の詳細は、後述する図１０に示す。
【００６５】
ステップＳ４１６では、クライアント端末１０４は、ユーザからの操作により、基幹系システムのアプリケーションの終了指示がなされたか否かを判定する。終了が指示されたと判定された場合には、ステップＳ４１７に処理を進め、そうでない場合には、ステップＳ４０８に処理を戻す。
【００６６】
ステップＳ４１７では、クライアント端末１０４は、ステップＳ４０１で起動したアプリケーションを終了し、本一連の処理を終了する。
【００６７】
次に、本発明の実施形態における連携元サーバ１０１とシステム管理端末１０３によって行われる論理削除した業務データの転送処理について、図７に示すフローチャートを用いて説明する。尚、ステップＳ７０１、ステップＳ７０５、ステップＳ７０６、ステップＳ７１０乃至ステップＳ７１２、ステップＳ７１７の各ステップは、システム管理端末１０３におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ７０２乃至ステップＳ７０４、ステップＳ７０７乃至ステップＳ７０９の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【００６８】
また、この処理を連携元サーバ１０１とシステム管理端末１０３に実行させるためのプログラムは、連携元サーバ１０１、システム管理端末１０３にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００６９】
まず、ステップＳ７０１では、システム管理端末１０３は、データ転送対象テーブル８００（図８参照）の情報を取得するために、連携元サーバ１０１に対してデータ転送管理情報の取得を要求する。データ転送管理情報とは、データ転送対象テーブル８００とデータ転送対象カラムテーブル８１０の２つから成る情報である。つまり、この２つのテーブルの取得要求を送信することになる。
【００７０】
データ転送対象テーブル８００は、テーブルＩＤ（送信元）８０１、テーブルＩＤ（送信先）８０２、主キー項目数８０３、最終取込日８０４、最終取込時刻８０５から構成される。テーブルＩＤ（送信元）８０１、テーブルＩＤ（送信先）８０２は、連携元サーバ１０１に記憶された業務データテーブル５００のテーブルＩＤ５１１と、連携先サーバ１０２に記憶された業務データテーブル５００のテーブルＩＤ５１１とを示す情報である。業務データテーブル５００は、基幹系システムの構成に応じて、複数存在する。よって、連携元サーバ１０１と連携先サーバ１０２にそれぞれ記憶されたテーブルが、どういう対応関係にあるのかをこのカラムで定義している。主キー項目数８０３は、主キーの項目数を示す。尚、このテーブルＩＤ（送信元）８０１、テーブルＩＤ（送信先）８０２、主キー項目数８０３は、あらかじめデータ転送対象テーブル８００に設定しておくものである。最終取込日８０４と最終取込時刻８０５は、連携先サーバ１０２に対して論理削除の指示を行った年月日時分を示す情報である。
【００７１】
データ転送対象カラムテーブル８１０は、テーブルＩＤ（送信元）８１１、主キー項目物理名８１２から構成される。送信元の業務データテーブル５００の転送するカラムを設定している。データ転送対象カラムテーブル８１０は、各業務データテーブル５００における主キー項目数分、レコードが作成される。
【００７２】
ステップＳ７０２では、連携元サーバ１０１は、システム管理端末１０３から送信されたデータ転送管理情報の取得要求を受信する。そして、ステップＳ７０３では、連携元サーバ１０１は、データ転送管理情報（データ転送対象テーブル８００、データ転送対象カラムテーブル８１０）を外部メモリ２１１等から取得する。ステップＳ７０４では、連携元サーバ１０１は、ステップＳ７０３で取得したデータ転送管理情報をシステム管理端末１０３に送信する。
【００７３】
ステップＳ７０５では、システム管理端末１０３は、連携元サーバ１０１から送信されたデータ転送管理情報を受信する。そして、ステップＳ７０６では、システム管理端末１０３は、ステップＳ７０５で受信したデータ転送管理情報を元に、データ転送対象のテーブル（送信元）から、最終取込日８０４、最終取込時刻８０５以降に論理削除された業務データを取得するよう、連携元サーバ１０１に要求する。
【００７４】
ステップＳ７０７では、連携元サーバ１０１は、システム管理端末１０３から送信された論理削除された業務データの取得要求を受信する。そして、ステップＳ７０８では、連携元サーバ１０１は、ステップＳ７０７で受信した論理削除された業務データの取得要求に応じて、外部メモリ２１１に記憶された業務データテーブル５００から論理削除した業務データを取得する。論理削除した業務データは、転送する業務データテーブル５００のテーブルＩＤ５１１がテーブルＩＤ（送信元）８０１に設定されているデータ転送対象テーブル８００を特定し、当該特定されたデータ転送対象テーブル８００の最終取込日８０４と最終取込時刻８０５以降に更新されたデータを、転送する業務データテーブル５００の更新日時５０７に基づいて取得する。ステップＳ７０９では、連携元サーバ１０１は、ステップＳ７０８で取得した業務データをシステム管理端末１０３に送信する。ステップＳ７０８で論理削除した業務データが取得できなかった場合、つまり最終取込日８０４、最終取込時刻８０５以降に論理削除された業務データが存在しない場合には、取得できなかった旨を送信する。
【００７５】
ステップＳ７１０では、システム管理端末１０３は、連携元サーバ１０１から送信された情報を受信する。そして、ステップＳ７１１では、システム管理端末１０３は、ステップＳ７１０で取得した情報に応じて、論理削除した業務データがあったか否かを判定する。論理削除した業務データがあったと判定された場合には、ステップＳ７１２に処理を進め、そうでない場合には、本一連の処理を終了する。
【００７６】
ステップＳ７１２では、システム管理端末１０３は、ステップＳ７１０で受信した業務データの転送要求を連携元サーバ１０１に送信する。
【００７７】
ステップＳ７１３では、連携元サーバ１０１は、システム管理端末１０３から送信された業務データの転送要求を受信する。そして、ステップＳ７１４では、連携元サーバ１０１は、ステップＳ７１３で受信した、論理削除された業務データの転送処理を実行する。論理削除転送処理の詳細は、後述する図９に示す。
【００７８】
ステップＳ７１５は、連携元サーバ１０１は、連携元サーバ１０１に記憶されたデータ転送対象テーブル８００を更新する。データ転送対象テーブル８００の最終取込日８０４と最終取込時刻８０５を現在時刻に更新する。そして、ステップＳ７１６では、連携元サーバ１０１は、ステップＳ７１４及びステップＳ７１５で実行した処理結果をシステム管理端末１０３に送信する。
【００７９】
ステップＳ７１７は、システム管理端末１０３は、連携元サーバ１０１から送信された処理結果を受信し、本一連の処理を終了する。尚、ここで処理が失敗していることがわかった場合には、再度ステップＳ７１２を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【００８０】
次に、本発明の実施形態における連携元サーバ１０１と連携先サーバ１０２によって行われる論理削除転送処理について、図９に示すフローチャートを用いて説明する。尚、ステップＳ９０１、ステップＳ９０５の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ９０２乃至ステップＳ９０４の各ステップは、連携先サーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００８１】
また、この処理を連携元サーバ１０１と連携先サーバ１０２に実行させるためのプログラムは、連携元サーバ１０１、連携先サーバ１０２にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００８２】
まず、ステップＳ９０１では、連携元サーバ１０１は、前述したステップＳ７１３で受信した論理削除の転送要求がなされた業務データを取得し、当該業務データの論理削除要求を送信する。論理削除は、前述した通り、削除フラグ５０２を「０」から「１」に変更するだけなので、実質的には削除フラグ５０２の更新要求である。
【００８３】
ステップＳ９０２では、連携先サーバ１０２は、連携元サーバ１０１から送信された論理削除要求を受信する。そして、ステップＳ９０３では、連携先サーバ１０２は、ステップＳ９０２で受信した論理削除要求に応じて、連携先サーバ１０２に記憶された業務データテーブル５００の当該業務データの削除フラグ５０２を「０」から「１」に変更する。ステップＳ９０４では、ステップＳ９０３で実行した処理結果を連携元サーバ１０１に送信する。
【００８４】
ステップＳ９０５では、連携元サーバ１０１は、連携先サーバ１０２から送信された処理結果を受信し、論理削除転送処理を終了する。尚、ここで処理が失敗していることがわかった場合には、再度ステップＳ９０１を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【００８５】
次に、本発明の実施形態におけるクライアント端末１０４と連携元サーバ１０１によって行われる物理削除処理について、図１０に示すフローチャートを用いて説明する。尚、ステップＳ１００１乃至ステップＳ１００３、ステップＳ１００７、ステップＳ１００８、ステップＳ１０１３の各ステップは、クライアント端末１０４におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１００４乃至ステップＳ１００６、ステップＳ１００９乃至ステップＳ１０１２の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【００８６】
また、この処理をクライアント端末１０４と連携元サーバ１０１に実行させるためのプログラムは、クライアント端末１０４、連携元サーバ１０１にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【００８７】
ステップＳ１００１では、クライアント端末１０４は、前述したステップＳ４０１で起動したアプリケーションに設定されたユーザを識別するためのユーザＩＤを取得する。ユーザＩＤは、ステップＳ４０１でアプリケーションを起動するときにログインＩＤとして入力されたものを取得してもよいし、クライアント端末１０４ごとにユーザＩＤがあらかじめ設定されており、それを取得するようにしてもよい。
【００８８】
ステップＳ１００２では、クライアント端末１０４は、ステップＳ１００１で取得したユーザＩＤに基づいて、操作履歴の登録が必要か否かを判定する。具体的には、ユーザＩＤからユーザを特定できるので、当該ユーザがシステム管理者か否かを判定することができる。通常のユーザであれば、操作履歴を残すことで、当該ユーザが物理削除を指示したことを残す必要がある。しかし、システム管理者であれば例外的に操作履歴を残さずに操作したい場合もある。例えば、業務データテーブル５００に不整合が発生した場合のメンテナンス等である。本実施形態では、ユーザＩＤからユーザを特定しているが、ＭＡＣアドレス等により、クライアント端末１０４か、システム管理端末１０３かを判定してもよい。操作履歴の登録が必要であると判定された場合には、ステップＳ１００３に処理を進め、そうでない場合には、ステップＳ１００８に処理を進める。
【００８９】
ステップＳ１００３では、クライアント端末１０４は、連携元サーバ１０１に対して操作履歴の登録要求を送信する。操作履歴の登録要求には、物理削除指示がなされた業務データを特定する情報が含まれている。この情報は物理削除指示がなされた業務データを特定できれば何でもよい。
【００９０】
ステップＳ１００４では、連携元サーバ１０１は、クライアント端末１０４から送信された操作履歴の登録要求を受信する。そして、ステップＳ１００５では、連携元サーバ１０１は、ステップＳ１００４で受信した操作履歴の登録要求に応じて、操作履歴テーブル１１００（図１１参照）に操作履歴を登録する（削除履歴保存手段）。
【００９１】
操作履歴テーブル１１００は、テーブルＩＤ１１０１、主キー１１０２、反映済みフラグ１１０３から構成される。テーブルＩＤ１１０１は、物理削除が指示された業務データテーブル５００のテーブルＩＤ５１１が格納される。主キー１１０２は、物理削除が指示された業務データテーブル５００の主キー５０１を示す情報が格納される。そして、反映済みフラグ１１０３は、連携先サーバ１０２においても物理削除指示が反映されたか否かを示すフラグが格納される。操作履歴テーブル１１００に登録されたデータのうち、反映済みフラグ１１０３が未反映を示すデータを連携先サーバ１０２に転送する。この操作履歴テーブル１１００に登録された情報に基づいて、物理削除データのＳＱＬ文を作成するために使用される。連携先サーバ１０２に物理削除指示の転送が行われた業務データについては、反映済みフラグ１１０３を反映済みに更新される。
【００９２】
ステップＳ１００６では、連携元サーバ１０１は、ステップＳ１００５で実行された処理結果をクライアント端末１０４に送信する。
【００９３】
ステップＳ１００７では、クライアント端末１０４は、連携元サーバ１０１から送信された処理結果を受信し、ステップＳ１００８に処理を進める。尚、ここで処理が失敗していることがわかった場合には、再度ステップＳ１００３を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【００９４】
ステップＳ１００８では、クライアント端末１０４は、前述したステップＳ４１４で選択された業務データの物理削除指示を連携元サーバ１０１に送信する（第１の削除指示手段）。
【００９５】
ステップＳ１００９では、連携元サーバ１０１は、クライアント端末１０４から送信された業務データの物理削除指示を受信する。そして、ステップＳ１０１０では、連携元サーバ１０１は、ステップＳ１００９で受信した物理削除指示に応じて、業務データの物理削除を実行する（第１の削除手段）。ステップＳ４１１とは異なり、フラグを立てることで削除したことにするのではなく、連携元サーバ１０１に記憶された業務データテーブル５００から対象の業務データを削除する。
【００９６】
ステップＳ１０１１では、連携元サーバ１０１は、連携元サーバ１０１で物理削除されたので、連携先サーバ１０２でも削除すべく、物理削除の転送処理を実行する。物理削除転送処理の詳細は、後述する図１３に示す。
【００９７】
ステップＳ１０１２では、連携元サーバ１０１は、ステップＳ１０１０、ステップＳ１０１１で実行した処理結果をクライアント端末１０４に送信する。
【００９８】
ステップＳ１０１３では、クライアント端末１０４は、連携元サーバ１０１から送信された処理結果を受信し、物理削除処理を終了する。尚、ここで処理が失敗していることがわかった場合には、再度ステップＳ１００８を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【００９９】
次に、本発明の実施形態におけるシステム管理端末１０３と連携元サーバ１０１によって定期的に行われる物理削除の処理について、図１２に示すフローチャートを用いて説明する。尚、ステップＳ１２０１、ステップＳ１２０２、ステップＳ１２０７の各ステップは、システム管理端末１０３におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１２０３乃至ステップＳ１２０６の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１００】
また、この処理をシステム管理端末１０３と連携元サーバ１０１に実行させるためのプログラムは、システム管理端末１０３、連携元サーバ１０１にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１０１】
まず、ステップＳ１２０１では、システム管理端末１０３は、業務データの消し込み時期になったか否かを判定する。システム管理端末１０３のアプリケーションに設定された所定の日時になったかどうかで判定すればよい。または、本一連の処理を前回実行した日時から所定の日時を経過したかどうか判定する。本一連の処理は、定期的に実行されるものであるので、その実行時期かどうかを判定できればよい。
【０１０２】
ステップＳ１２０２では、システム管理端末１０３は、業務データの消し込み時期であると判定されたので、有効期限が切れた業務データの物理削除要求を送信する（第２の削除指示手段）。
【０１０３】
ステップＳ１２０３では、連携元サーバ１０１は、システム管理端末１０３から送信された、有効期限が切れた業務データの物理削除要求を受信する。そして、ステップＳ１２０４では、連携元サーバ１０１は、有効期限の切れた業務データの物理削除を実行する（第１の削除手段）。有効期限が切れたか否かは、業務データテーブル５００の登録日時５０３を参照して、登録されてから所定期間経過したか否かを判定すればよい。または、更新日時５０７を用いてもよい。登録されてからの有効期限か、最終更新されてからの有効期限かは、企業によって決めておけばよい。そして、有効期限が切れた業務データを特定し、特定された業務データを物理削除する。
【０１０４】
ステップＳ１２０５では、連携元サーバ１０１は、連携先サーバ１０２に物理削除された業務データの転送処理を実行する。物理削除転送処理の詳細は、後述する図１３に示す。業務データの消し込みを行う場合には操作履歴が残らないので、後述する図１３の物理削除転送処理では、連携先サーバ１０２に対して物理削除の指示がなされない。つまり、データの肥大化抑制やごみデータの排除、また処理の高速化を図るために、連携元サーバ１０１において物理削除されたデータは、半永久的にデータを保持する連携先サーバ１０２においては物理削除されない。尚、データ消し込みの際にはステップＳ１２０５を実行しない形態も考えられるが、連携元サーバ１０１は、クライアント端末１０４から物理削除要求が送信されると、ステップＳ１００９乃至ステップＳ１０１２やステップＳ１２０３乃至ステップＳ１０６に示すように、あらかじめ決められた一連の処理を実行する仕組みになっている。つまり、物理削除要求を受け付けると、連携元サーバ１０１が備えるモジュールを実行する仕組みとなっている。本実施形態のようにすることで当該モジュールに手を入れることなく、必要な物理削除指示だけを連携先サーバ１０２に送信することが可能となる。
【０１０５】
ステップＳ１２０６では、連携元サーバ１０１は、ステップＳ１２０４、ステップＳ１２０５で実行した処理結果をシステム管理端末１０３に送信する。
【０１０６】
ステップＳ１２０７では、システム管理端末１０３は、連携元サーバ１０１から送信された処理結果を受信し、本一連の処理を終了する。尚、ここで処理が失敗していることがわかった場合には、再度ステップＳ１２０２を実行するようにしてもよいし、エラー画面を表示してユーザに通知してもよい。
【０１０７】
次に、本発明の実施形態における連携元サーバ１０１と連携先サーバ１０２によって行われる物理削除転送処理について、図１３に示すフローチャートを用いて説明する。尚、ステップＳ１３０１乃至ステップＳ１３０３、ステップＳ１３０７、ステップＳ１３０８の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１３０４乃至ステップＳ１３０６の各ステップは、連携先サーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１０８】
また、この処理を連携元サーバ１０１と連携先サーバ１０２に実行させるためのプログラムは、連携元サーバ１０１、連携先サーバ１０２にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１０９】
まず、ステップＳ１３０１では、連携元サーバ１０１は、連携元サーバ１０１に記憶された操作履歴テーブル１１００を取得する。そして、ステップＳ１３０２では、連携元サーバ１０１では、ステップＳ１３０１で取得した操作履歴テーブル１１００に反映済みフラグ１１０３が未反映となっているレコードが存在するか否かを判定する。存在すると判定された場合には、ステップＳ１３０３に処理を進め、そうでない場合には、本一連の処理を終了する。
【０１１０】
前述した図１２の処理では、システム管理端末１０３が定期的に業務データを物理削除していた。これは、連携元サーバ１０１の基幹系システムのデータ肥大化抑止等のために実行しているものである。よって、連携先サーバ１０２においても同じデータを物理削除する必要はない。しかしながら、図１０に示す処理では、ユーザからの指示に応じて物理削除が実行されている。つまり、入力ミス等で登録されてしまった業務データを完全に削除したい場合である。この場合には、連携先サーバ１０２からも削除しないと、余計なデータが混じってしまい、データの分析の際に誤動作を起こしてしまう可能性がある。そのため、ユーザから指示された場合には操作履歴として残し、そうでない場合には操作履歴を残さないことで、ステップＳ１３０２において連携先サーバ１０２の業務データテーブル５００からも物理削除すべきかどうかを判定することができるようになる。
【０１１１】
ステップＳ１３０３では、連携元サーバ１０１は、操作履歴テーブル１１００に登録された業務データの物理削除指示を連携先サーバ１０２に対して送信する（第３の削除指示手段）。
【０１１２】
ステップＳ１３０４では、連携先サーバ１０２は、連携元サーバ１０１から送信された物理削除指示を受信する。そして、ステップＳ１３０５では、連携先サーバ１０２は、ステップＳ１３０４で受信した物理削除指示に応じて、連携先サーバ１０２に記憶された業務データテーブル５００から該当する業務データを物理削除する（第２の削除手段）。
【０１１３】
ステップＳ１３０６では、連携先サーバ１０２は、ステップＳ１３０５で実行した処理結果を連携元サーバ１０１に送信する。
【０１１４】
ステップＳ１３０７では、連携元サーバ１０１は、連携先サーバ１０２から送信された処理結果を受信する。そして、ステップＳ１３０８では、連携元サーバ１０１は、連携先サーバ１０２で物理削除された業務データについて、操作履歴テーブル１１００の反映済みフラグ１１０３を反映済みに更新し、物理削除転送処理を終了する（削除履歴更新手段）。
【０１１５】
以上説明したように、本実施形態によれば、ユーザが削除指示を行った場合に、操作履歴を連携元サーバに残し、削除されたデータを連携先サーバに連携する際に、当該データに関する操作履歴があるか否かに応じて連携の要否を決定することが可能となるので、連携先データベースと連携元データベースのデータ保持要件が異なる場合であっても、適切にデータを連携することのできる効果を奏する。
【０１１６】
次に、本発明の第２の実施形態について説明を行う。前述した実施形態では、ユーザが物理削除を指示した操作履歴が残っていれば、連携元サーバ１０１から連携先サーバ１０２に対して物理削除指示を送信していた。しかしながら、連携先サーバ１０２から物理削除がなされてしまうと、ユーザが誤って物理削除指示を行った場合に、物理削除したデータを復元することができない問題がある。
【０１１７】
図２１を用いて、詳細に説明する。図２１の２１００は、前述した実施形態の処理内容を示す図である。２１０１に示すように、連携元サーバ１０１と連携先サーバ１０２の業務データテーブル５００には、「業務データＡ」と「業務データＢ」が格納されている。ここで、２１０２に示すように、クライアント端末１０４から「業務データＡ」の物理削除要求を連携元サーバ１０１が受け付けると、連携元サーバ１０１は「業務データＡ」を物理削除する。そして、操作履歴を残す。操作履歴が残っているので、「業務データＡ」を連携先サーバ１０２からも物理削除するべく、連携元サーバ１０１から連携先サーバ１０２に対して物理削除要求を送信する。すると、連携先サーバ１０２の業務データテーブル５００からも「業務データＡ」が物理削除される。連携元サーバ１０１から連携先サーバ１０２に対する物理削除要求を送信するタイミングによっては、連携元サーバ１０１から物理削除されると同時に連携先サーバ１０２からも削除されてしまう。そのため、ユーザが誤って「業務データＡ」の物理削除要求がなされた場合には、復元できないことになってしまう。
【０１１８】
そこで、第２の実施形態では、２１１０に示す処理を実行する。まず、２１１１に示すように、連携元サーバ１０１と連携先サーバ１０２の業務データテーブル５００には、「業務データＡ」と「業務データＢ」が格納されている。ここで、２１１２に示すように、前述した実施形態と同様に、クライアント端末１０４から「業務データＡ」の物理削除要求がなされると、連携元サーバ１０１の業務データテーブル５００から「業務データＡ」を物理削除する。そして、操作履歴の有無を判定し、操作履歴があれば連携先サーバ１０２に対して物理削除要求ではなく、論理削除要求を送信する。連携元サーバ１０１は、クライアント端末１０４から物理削除要求を受けたとしても、連携先サーバ１０２に対しては論理削除要求を送信することで、復元できるようにデータを保持させておく。
【０１１９】
そして、２１１３に示すように、復元が必要であれば連携先サーバ１０２から「業務データＡ」を復元する。また、物理削除が指示されたにも関わらず、論理削除がなされたままだと、物理削除を指示したユーザの意図が反映されないことになってしまう。よって、操作履歴に基づいて、論理削除がなされてから一定時間経過したデータについては、あらためて連携元サーバ１０１から連携先サーバ１０２に対して物理削除要求を送信する。こうすることで、確実に物理削除を実行しつつ、誤って物理削除してしまったデータを復元することが可能となる。以下、この第２の実施形態について説明を行う。
【０１２０】
第２の実施形態におけるシステム構成、ハードウェア構成、機能構成については、前述した実施形態と同様であるので、説明を省略する。また、前述した実施形態と同様である部分については、前述した実施形態で示した符号と同じ符号を用いるものとする。また、図４、図７、図９に示す各処理は、第２の実施形態においても同様であるので、説明を省略する。
【０１２１】
次に、本発明の第２の実施形態におけるクライアント端末１０４と連携元サーバ１０１によって行われる物理削除処理について、図１６に示すフローチャートを用いて説明する。尚、ステップＳ１００１乃至ステップＳ１００３、ステップＳ１００７、ステップＳ１００８、ステップＳ１０１３の各ステップは、クライアント端末１０４におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１００４、ステップＳ１００６、ステップＳ１００９乃至ステップＳ１０１２、ステップＳ１６０１の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１２２】
また、この処理をクライアント端末１０４と連携元サーバ１０１に実行させるためのプログラムは、クライアント端末１０４、連携元サーバ１０１にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１２３】
ステップＳ１００１乃至ステップＳ１０１３は、前述した図１０のステップＳ１００１乃至ステップＳ１０１３と同様であるので、説明を省略する。尚、ステップＳ１００８は第１の物理削除指示手段であり、ステップＳ１０１０は第１の物理削除手段である。
【０１２４】
ステップＳ１６０１では、連携元サーバ１０１は、ステップＳ１００４で受信した操作履歴の登録要求に応じて、図１７に示す操作履歴テーブル１１００に操作履歴を登録する。
【０１２５】
図１７に示す操作履歴テーブル１１００は、テーブルＩＤ１１０１、主キー１１０２、反映済みフラグ１７０１、論理削除反映日時１７０２、物理削除反映日時１７０３から構成される。テーブルＩＤ１１０１、主キー１１０２については、前述した実施形態と同様である。反映済みフラグ１７０１は、前述した実施形態と同様に、連携先サーバ１０２においても物理削除指示が反映されたか否かを示すフラグが格納される。第２の実施形態においては、反映済みフラグ１７０１には、４種類のフラグが格納される。まず、「０」と格納されていた場合には、「未反映」を示す。「１」と格納されていた場合には、「論理削除反映済み」を示す。「９」と格納されていた場合には、「物理削除反映済み」を示す。そして、「９９」と格納されていた場合には、「データ復元済み」を示す。フラグの種類はあくまで一例であって、これに限らない。論理削除反映日時１７０２は、クライアント端末１０４からの物理削除要求に応じて、連携元サーバ１０１が連携先サーバ１０２に対して論理削除を要求した日時を示す。物理削除反映日時１７０３は、当該論理削除が実行された後、所定時間経過後に連携元サーバ１０１が連携先サーバ１０２に対して物理削除を要求した日時を示す。
【０１２６】
ステップＳ１６０１では、この操作履歴テーブル１１００に新たなレコードを作成し、テーブルＩＤ１１０１に物理削除の要求がなされたデータを含む業務データテーブル５００のテーブルＩＤ５１１を格納し、主キー１１０２には物理削除の要求がなされたデータである主キー５０１を示す情報を格納する。そして、反映済みフラグ１７０１に「０」を格納し、論理削除反映日時１７０２と物理削除反映日時１７０３には何も格納しない。
【０１２７】
次に、本発明の第２の実施形態における連携元サーバ１０１と連携先サーバ１０２によって行われる物理削除転送処理について、図１８に示すフローチャートを用いて説明する。尚、ステップＳ１８０１乃至ステップＳ１８０３、ステップＳ１８０７、ステップＳ１８０８の各ステップは、連携元サーバ１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１８０４乃至ステップＳ１８０６の各ステップは、連携先サーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１２８】
また、この処理を連携元サーバ１０１と連携先サーバ１０２に実行させるためのプログラムは、連携元サーバ１０１、連携先サーバ１０２にインストールされているアプリケーションの一部、若しくはアドオンプログラムとして用意されていてもよいし、アプリケーションとは別にインストールされたプログラムとして用意されていてもよい。
【０１２９】
まず、ステップＳ１８０１では、連携元サーバ１０１は、連携元サーバ１０１に記憶された操作履歴テーブル１１００を取得する。そして、ステップＳ１８０２では、連携元サーバ１０１では、ステップＳ１８０１で取得した操作履歴テーブル１１００に反映済みフラグ１７０１が「０」、つまり「未反映」となっているレコードが存在するか否かを判定する。存在すると判定された場合には、ステップＳ１８０３に処理を進め、そうでない場合には、本一連の処理を終了する。
【０１３０】
ステップＳ１８０３では、連携元サーバ１０１は、操作履歴テーブル１１００に登録された業務データの論理削除指示を連携先サーバ１０２に対して送信する（論理削除指示手段）。前述した実施形態では、ここで物理削除指示を送信していたが、第２の実施形態では論理削除指示を送信する。ここで論理削除指示を送信しておくことで、連携先サーバ１０２から対象の業務データが物理削除されないので、ユーザが誤って物理削除を指示してしまった場合でも、連携先サーバ１０２から復元することが可能となる。
【０１３１】
ステップＳ１８０４では、連携先サーバ１０２は、連携元サーバ１０１から送信された論理削除指示を受信する。そして、ステップＳ１８０５では、連携先サーバ１０２は、ステップＳ１８０４で受信した論理削除指示に応じて、連携先サーバ１０２に記憶された業務データテーブル５００から該当する業務データを論理削除する（論理削除手段）。より具体的には、対象の業務データテーブル５００に含まれる業務データの削除フラグ５０２に論理削除がなされたことを示すフラグを立てておく。
【０１３２】
ステップＳ１８０６では、連携先サーバ１０２は、ステップＳ１８０５で実行した処理結果を連携元サーバ１０１に送信する。
【０１３３】
ステップＳ１８０７では、連携元サーバ１０１は、連携先サーバ１０２から送信された処理結果を受信する。そして、ステップＳ１８０８では、連携元サーバ１０１は、連携先サーバ１０２で論理削除された業務データについて、操作履歴テーブル１１００の反映済みフラグ１１０３を「１」、つまり「論理削除反映済み」に更新し、更には、論理削除反映日時１７０２に論理削除を行った現在日時を格納する。処理が完了したら、物理削除転送処理を終了する。以上のようにして、クライアント端末１０４から物理削除指示を受け付けた場合であっても、連携先サーバ１０２に対しては論理削除を指示する。つまり、連携元サーバ１０１では物理削除を実行する（ステップＳ１０１０）が、連携先サーバ１０２では論理削除を実行する（ステップＳ１８０５）。
【０１３４】
次に、連携元サーバ１０１で定期的に実行される、ステップＳ１８０５で論理削除された業務データを物理削除するための一連の処理について、図１９を用いて説明する。尚、ステップＳ１９０１乃至ステップＳ１９０３、ステップＳ１９０７、ステップＳ１９０８の各ステップは、連携元サーバ１０１のＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１９０４乃至ステップＳ１９０６の各ステップは、連携先サーバ１０２のＣＰＵ２０１の制御の下、処理が行われる。
【０１３５】
まず、ステップＳ１９０１では、連携元サーバ１０１は、図１７に示す操作履歴テーブル１１００を取得する。そして、ステップＳ１９０２では、連携元サーバ１０１は、ステップＳ１９０１で取得した操作履歴テーブル１１００に格納された操作履歴のうち、前述したステップＳ１８０５で論理削除が実行されてから一定時間が経過したものが存在するか否かを判定する。より具体的には、図１７に示す操作履歴テーブル１１００の反映済みフラグ１７０１が「１」、つまり「論理削除反映済み」になっているレコードのうち、論理削除反映日時１７０２から一定時間経過しているレコードがあるか否かを判定する。
【０１３６】
前述した図１８で連携先サーバ１０２に対しては論理削除を要求したが、本来はクライアント端末１０４から物理削除の要求を受け付けているので、連携先サーバ１０２に対しても物理削除を要求しなければならない。そこで、論理削除から一定期間経過している業務データについては、連携先サーバ１０２からも物理削除するようにすることで、ユーザの意図を反映させる。つまり、一定時間は論理削除としておくことで業務データを復元できる状態にしておき、一定時間が経過したら物理削除するようにすることで、誤ってユーザが物理削除を指示した場合でも一定時間だけ復元できるようにし、かつ確実に物理削除を実行できるようにしている。
【０１３７】
尚、前述した一定時間はあらかじめ連携元サーバ１０１に設定された任意の時間とする。復元するための猶予を与えられれば、どんな時間であってもよい。
【０１３８】
論理削除が実行されてから一定時間が経過したものが存在すると判定した場合には、ステップＳ１９０３に処理を進める。論理削除が実行されてから一定時間が経過したものが存在しないと判定された場合には、本一連の処理を終了する。
【０１３９】
ステップＳ１９０３では、連携元サーバ１０１は、論理削除してから一定時間が経過した業務データの物理削除要求を連携先サーバ１０２に対して送信する（第２の物理削除指示手段）。物理削除する業務データは、図１７に示す操作履歴テーブル１１００のテーブルＩＤ１１０１と主キー１１０２、更にはデータ転送対象テーブル８００から識別可能であるので、これらに基づいて要求を出せばよい。
【０１４０】
ステップＳ１９０４では、連携先サーバ１０２は、連携元サーバ１０１から送信されてきた物理削除要求を受信する。そして、ステップＳ１９０５では、連携先サーバ１０２は、要求された対象の業務データの物理削除を実行する（第２の物理削除手段）。
【０１４１】
ステップＳ１９０６では、連携先サーバ１０２は、ステップＳ１９０５で実行した処理結果を連携元サーバ１０１に送信する。
【０１４２】
ステップＳ１９０７では、連携元サーバ１０１は、連携先サーバ１０２から送信された処理結果を受信する。そして、ステップＳ１９０８では、連携元サーバ１０１は、連携先サーバ１０２で物理削除された業務データについて、操作履歴テーブル１１００の反映済みフラグ１１０３を「９」、つまり「物理削除反映済み」に更新し、更には、物理削除反映日時１７０３に物理削除を行った現在日時を格納する。処理が完了したら、本一連の処理を終了する。以上のようにして、ユーザから物理削除の指示がなされた操作履歴が残っており、当該物理削除指示に応じて連携先サーバ１０２に対して論理削除を要求してから所定時間が経過した場合に、あらためて物理削除の実行を要求することで、確実に物理削除を実行することができる。
【０１４３】
次に、ユーザが誤って物理削除を要求してしまった場合に、連携先サーバ１０２から業務データを復元するための一連の処理について、図２０を用いて説明する。尚、ステップＳ２００１、ステップＳ２０１３の各ステップは、クライアント端末１０４のＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２００２乃至ステップＳ２００４、ステップＳ２０９乃至ステップＳ２０１２の各ステップは、連携元サーバ１０１のＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２００５乃至ステップＳ２００８の各ステップは、連携先サーバ１０２のＣＰＵ２０１の制御の下、処理が行われる。
【０１４４】
まず、ステップＳ２００１では、クライアント端末１０４は、誤って削除してしまった業務データの復元要求を連携元サーバ１０１に送信する。ユーザから誤って削除してしまった業務データを識別する情報の入力を受け付け、その情報に応じて連携先サーバ１０２に対して復元要求を送信する。
【０１４５】
ステップＳ２００２では、連携元サーバ１０１は、クライアント端末１０４から送信されてきた業務データの復元要求を受信する。そして、ステップＳ２００３では、連携元サーバ１０１は、復元の要求がなされた業務データの反映済みフラグ１１０３が「１」、つまり「論理削除反映済み」か否かを判定する。他のフラグであった場合には、復元することができないため、ステップＳ２００２でこのような判定を行っている。反映済みフラグ１１０３が「論理削除反映済み」であると判定された場合には、ステップＳ２００４に処理を進める。反映済みフラグ１１０３が「論理削除反映済み」でないと判定された場合には、ステップＳ２０１２に処理を進める。
【０１４６】
ステップＳ２００４では、連携元サーバ１０１は、クライアント端末１０４で復元要求のあった業務データの取得要求を連携先サーバ１０２に送信する。
【０１４７】
ステップＳ２００５では、連携先サーバ１０２は、連携元サーバ１０１から要求された業務データの復元要求を受信する。そして、ステップＳ２００６では、連携先サーバ１０２は、復元要求のあった業務データを復元する。より具体的には、対象の業務データの削除フラグ５０２を取り消す、つまり論理削除を取り消す。こうすると、連携先サーバ１０２では、当該業務データが復元されたことになる。連携元サーバ１０１において復元するのであれば、それに同期して連携先サーバ１０２でも復元しないと、整合性が取れない。そのため、ステップＳ２００６では、連携先サーバ１０２において対象の業務データを復元している。
【０１４８】
ステップＳ２００７では、連携先サーバ１０２は、ステップＳ２００５で復元した業務データを業務データテーブル５００から取得する。そして、ステップＳ２００８では、連携先サーバ１０２は、取得した業務データを連携元サーバ１０１に送信する。
【０１４９】
ステップＳ２００９では、連携元サーバ１０１は、連携先サーバ１０２から送信された業務データを受信する。そして、ステップＳ２０１０では、連携元サーバ１０１は、ステップＳ２００９で受信した業務データを業務データテーブル５００に追加する。より具体的には、ユーザから復元要求のあった業務データテーブル５００を特定し、当該業務データテーブル５００に新しくレコードを作成する。そして、新しく作成したレコードに受信した業務データを格納する。これにより、連携元サーバ１０１からの復元が完了する。
【０１５０】
ステップＳ２０１１では、連携元サーバ１０１は、図１７に示す操作履歴テーブル１１００を更新する。より具体的には、図１７の操作履歴テーブル１１００に格納されたレコードのうち、復元した業務データに関する操作履歴を示すレコードの反映済みフラグ１７０１を「９９」、つまり「データ復元済み」を示すフラグに更新する。こうすることで、データを復元した履歴を残しておくことができる。本実施形態では、復元した業務データの操作履歴を残しておくものとするが、削除してしまってもよい。そうすることで、操作履歴テーブル１１００の肥大化を防ぐことができる。
【０１５１】
ステップＳ２０１２では、連携元サーバ１０１は、ステップＳ２００３乃至ステップＳ２０１１で実行した処理結果をクライアント端末１０４に送信する。
【０１５２】
ステップＳ２０１３では、クライアント端末１０４は、連携元サーバ１０１から送信された処理結果を受信して、本一連の処理を終了する。
【０１５３】
以上説明したように、第２の実施形態によれば、物理削除が指示された場合であっても、連携先サーバに対しては論理削除を指示するため、連携先サーバからデータを復元することが可能となる。
【０１５４】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１５５】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１５６】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１５７】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１５８】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１５９】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１６０】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１６１】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１６２】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１６３】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１６４】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１６５】
１００  データ連携システム
１０１  連携元サーバ
１０２  連携先サーバ
１０３  システム管理端末
１０４  クライアント端末
１０５  ネットワーク
１０６  ネットワーク
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆ（インターフェース）コントローラ
２０９  入力装置
２１０  ディスプレイ装置
２１１  外部メモリ
【図１】
2014130575.tif 000003
【図２】
2014130575.tif 000004
【図３】
2014130575.tif 000005
【図４】
2014130575.tif 000006
【図５】
2014130575.tif 000007
【図６】
2014130575.tif 000008
【図７】
2014130575.tif 000009
【図８】
2014130575.tif 000010
【図９】
2014130575.tif 000011
【図１０】
2014130575.tif 000012
【図１１】
2014130575.tif 000013
【図１２】
2014130575.tif 000014
【図１３】
2014130575.tif 000015
【図１４】
2014130575.tif 000016
【図１５】
2014130575.tif 000017
【図１６】
2014130575.tif 000018
【図１７】
2014130575.tif 000019
【図１８】
2014130575.tif 000020
【図１９】
2014130575.tif 000021
【図２０】
2014130575.tif 000022
【図２１】
2014130575.tif 000023