(57)【要約】【課題】データ共有システムに接続する外部システム間で、格納と取得の連携が取れていない状態を検知および警告することが容易でない。【解決手段】情報処理装置であって、クライアントからデータの格納または取得のリクエストを受信する受信手段と、前記リクエストを履歴情報として保存する保存手段と、前記履歴情報に基づいて次のリクエストを受信する日時を予測する予測手段と、前記予測手段にて予測した日時に前記次のリクエストを受信しなかった場合、前記クライアントに通知する通知手段とを有する。【選択図】  図２
2015203980.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからデータの格納または取得のリクエストを受信する受信手段と、
前記リクエストを履歴情報として保存する保存手段と、
前記履歴情報に基づいて次のリクエストを受信する日時を予測する予測手段と、
前記予測手段にて予測した日時に前記次のリクエストを受信しなかった場合、前記クライアントに通知する通知手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記予測手段は、前記履歴情報に基づいて前記受信手段にて受信したリクエストの周期性を判定し、前記次のリクエストを受信する日時を予測することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記予測手段は、前記受信手段が受信したリクエストの中から、等間隔で周期的に受信する複数の格納のリクエストと、当該複数の格納のリクエストに対応して前記等間隔で周期的に受信する複数の取得のリクエストを特定することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記予測手段は、前記履歴情報に基づいて前記受信手段にて受信したリクエストの周期性を判定する際に、受信したリクエスト間の時間間隔に対し所定の誤差の範囲を設定することを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
前記予測手段は、リクエストの要求元および対象となるデータの種類に基づいて、リクエストの周期性を判定することを特徴とする請求項２乃至４のいずれか一項に記載の情報処理装置。
【請求項６】
前記予測手段は、前記予測した日時に前記次のリクエストを受信しなかった場合、前記次のリクエストを受信した際の履歴情報に基づいて、新たな周期性を判定することを特徴とする請求項２乃至５のいずれか一項に記載の情報処理装置。
【請求項７】
前記予測手段は、前記次のリクエストの受信する日時に対し、所定の誤差の範囲を設定することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
【請求項８】
前記通知手段は、取得のリクエストを受信した際に指定されたデータが、当該データの格納のリクエストを受信していないことにより格納されていない場合に、その旨を通知することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
【請求項９】
請求項１乃至８のいずれか一項に記載の情報処理装置と、複数のクライアントとを含むシステム。
【請求項１０】
クライアントからデータの格納または取得のリクエストを受信する受信工程と、
前記リクエストを履歴情報として記憶部に保存する保存工程と、
前記履歴情報に基づいて次のリクエストを受信する日時を予測する予測工程と、
前記予測工程にて予測した日時に前記次のリクエストを受信しなかった場合、前記クライアントに通知する通知工程と、
を有することを特徴とする情報処理装置の制御方法。
【請求項１１】
コンピュータを、
クライアントからデータの格納または取得のリクエストを受信する受信手段、
前記リクエストを履歴情報として保存する保存手段、
前記履歴情報に基づいて次のリクエストを受信する日時を予測する予測手段、
前記予測手段にて予測した日時に前記次のリクエストを受信しなかった場合、前記クライアントに通知する通知手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびその制御方法、並びにプログラムに関する。
【背景技術】
【０００２】
データを送受信するサービス間では、データが取得される前にデータが問題無く格納されている必要がある。具体的には、不測のシステムトラブルにより、データの格納が行われていない場合には、そのデータを格納および取得するサービスに対して異常を通知する、といった対応が必要である。また、別の例として、格納サービスが訂正データを上書き格納した時に、取得サービスが既にデータを取得してしまっている場合には、再取得等の判定のため取得サービスに格納リクエストがあったことを通知する必要性がある。
【０００３】
従来、サービス間で直接データ連携する場合、データの送信側と受信側で決められた判定基準に従って、格納と取得の連携に問題が無いかを判定あるいは監視する仕組みを実装している。例えば、連携するサービス自身が、格納されたデータの内容を確認してその正当性を判定するという技術がある（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３８１５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
二つのシステム間の連携の場合、当該システム間で必要な調整及びそれぞれのシステムで対応に必要な手段を実装することが出来る。しかしながら、データ共有システムを介したシステム連携の場合、独立した多数のシステム（例えば複数の販売会社によるシステム）がデータ共有システムと連携することになる。この場合、各国の商習慣の違いや販社毎の都合が様々あり、データ共有システムに接続する各システムが他のシステムの都合に実装を合わせることは難しい。したがって、データ共有システムに接続する各システムにとっては、極力単純な仕組みの実装で連携できることが望ましい。このため、複数のシステムの間に入るデータ共有システムがシステム間連携のためのデータの格納と取得の状態を支援することが求められている。
【０００６】
一方、データ共有システムは、システム連携の数が動的に変動、あるいは、増加していくため、監視対象のスケジュール（およびその組み合わせ）を予め設定・管理することは容易でない。販社システム側も、基本的には定期的なアクセスではあるものの、各国の商習慣の違いなどからスケジュールの約束を出来ない場合もある。また、データ共有システムには、様々な種類のデータが格納されるため、システム連携毎にデータ共有システムがデータの内容を判定するように管理・設定することも容易でない。
【０００７】
本発明は、手動で格納・取得スケジュールなどの連携情報を予め登録することなく、かつ、接続する各システムで判定する必要が無い、連携の異常を自動判定する仕組みを提供する。
【課題を解決するための手段】
【０００８】
上記課題を解決するために本願発明は以下の構成を備える。すなわち、情報処理装置であって、クライアントからデータの格納または取得のリクエストを受信する受信手段と、前記リクエストを履歴情報として保存する保存手段と、前記履歴情報に基づいて次のリクエストを受信する日時を予測する予測手段と、前記予測手段にて予測した日時に前記次のリクエストを受信しなかった場合、前記クライアントに通知する通知手段とを有する。
【発明の効果】
【０００９】
データ共有システムを介したシステム間データ連携において、データ連携の同期を監視し、同期状態の異常の判定および警告が可能となる。
【図面の簡単な説明】
【００１０】
【図１】データ共有システムのハードウェアの構成例を示す図。
【図２】データ共有システムの機能の構成例を示す図。
【図３】格納と取得の組み合わせ周期判定のタイミングを説明するための図。
【図４】格納周期判定のタイミングを説明するための図。
【図５】第二の格納周期判定のタイミングを説明するための図。
【図６】対象データの格納済み判定のタイミングを説明するための図。
【図７】アクセス履歴の構成例を示す図。
【図８】監視対象アラート日時テーブルの構成例を示す図。
【図９】定期格納監視テーブルの構成例を示す図。
【図１０】上書き系データのテーブルの構成例を示す図。
【図１１】履歴系データのテーブルの構成例を示す図。
【図１２】リクエスト処理のフローチャート。
【図１３】取得処理のフローチャート。
【図１４】格納処理のフローチャート。
【図１５】格納と取得の組み合わせ周期判定処理のフローチャート。
【図１６】格納周期判定処理のフローチャート。
【図１７】監視処理のフローチャート。
【発明を実施するための形態】
【００１１】
以下、本願発明に係る一実施形態を、図面を用いて説明する。なお、以下に示す構成は一例であり、これに限定するものではない。
【００１２】
［ハードウェア構成］
図１は、本実施形態に係るシステムのハードウェア構成の例を示す図である。データ共有システム１００は、ネットワークインタフェース１０５を介して互いに接続された１あるいは複数台のサーバで構成される。本実施形態において、サーバ１０１、１１０、１１１はそれぞれ同様の構成を持つ情報処理装置である。サーバ１０１は、バス１０６を介して接続されたＣＰＵ１０２、ＲＡＭ１０３、ＲＯＭ１０４、ネットワークインタフェース１０５、およびＨＤＤ１０７を含む。データ共有システム１００の各処理は、ＨＤＤ１０７あるいはＲＯＭ１０４、ＲＡＭ１０３に記録されたデータ及びプログラムを読み出してＣＰＵ１０２が実行することにより実現される。また、その機能は、複数のサーバの機能の連携によって実現される場合もある。ネットワークインタフェース１０５は、データ共有システム１００内のサーバ間の機能連携に使われると共に、外部のネットワーク１２０を介して、外部システム１２１、１２２、１２３と通信するためにも使用される。外部システム１２１〜１２３もデータ共有システム１００と同様に１台以上のサーバから構成されるものとする。
【００１３】
本実施形態において、以下に示す各処理部や処理のフローチャートは、データ共有システム１００が備えるＣＰＵ１０２がＲＯＭ１０４等の記憶部に格納されたプログラムを読み出して実行することにより、実現される。
【００１４】
［機能構成］
図２は、本実施形態におけるデータ共有システム１００の機能構成の例を示す。外部システム１２１は、データ共有システム１００にデータを格納するデータ格納サービスを提供する。外部システム１２２は、データ共有システム１００からデータを取得するデータ取得サービスを提供する。図２に示すデータ共有システム１００、および外部システム１２１、１２２は、図１の各装置に対応する。なお、図２に示す例においては、外部システムが２つのみ示されているが、接続される外部システムの数はこれに限らない。つまり、データ共有システム１００には、さらに多くの外部システムが接続され得る。
【００１５】
データ共有システム１００は、外部システム１２１、１２２と連携して動作する。データ管理部１５２は、Ｗｅｂサーバ１５０を介して格納および取得されるデバイス構成情報１６４およびジョブログ１６５、データへのアクセス履歴１６０、内部処理のための管理テーブル（１６１〜１６３）のデータを管理する。本明細書において、アクセス履歴１６０やジョブログ１６５などの履歴情報を履歴系データと呼び、メールアドレステーブル１６２やデバイス構成情報１６４などの設定・管理情報を上書き系データと呼ぶ。データ管理部１５２は、本実施形態ではＳＱＬサーバなどのデータベースを前提とするが、他のファイルシステム等でもよい。
【００１６】
Ｗｅｂサーバ１５０は、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）の仕様に準拠して実装されたＨＴＴＰサーバなどである。Ｗｅｂサーバ１５０は、クライアントとなる外部システム１２１、１２２からのＨＴＴＰリクエストを受信および処理し、クライアントに処理結果をレスポンスとして返す。本実施形態において、リクエストには格納リクエスト（ＰＯＳＴ）と取得リクエスト（ＧＥＴ）の二種類があり、それぞれリクエストの内容に従って格納処理部１５３あるいは取得処理部１５４にて処理される。格納処理部１５３は、外部システム１２１からの格納リクエストに従って、リクエストのボディに指定されたリソースをデータ管理部１５２に格納する。また、取得処理部１５４は、外部システム１２２からの取得リクエストに従って、リクエストで指定された条件でデータ管理部１５２からリソースの検索を実行し、検索結果データを返却する。
【００１７】
データ管理部１５２にて管理されるリソースは、格納・取得されるデータの単位を表す。本実施形態においては、データ種別とアクセス制御される単位であるテナントの組み合わせを指す。さらに、リソースの取得においては、特定の条件を満たすデータのみを取得するためのクエリ文字列を検索条件として指定できる。例えば、取得するデータの期間を日時指定で範囲指定できる。本実施形態において、データ種別として、デバイス構成情報１６４とジョブログ１６５を例に挙げたが、その他のデータ種別も同様に扱えるものとする。アクセス履歴記録部１５６は、Ｗｅｂサーバ１５０が受信したリクエストをデータ管理部１５２内のアクセス履歴１６０へ記録する。
【００１８】
データ共有システム１００は、対応する格納リクエストと取得リクエストの組み合わせが存在すると判定できる場合に、次のリクエストのタイミングを予測する。そして、そのリクエストが予測通りに受け付けられなかった場合、データ共有システム１００は、連携に異常が発生していると判定し、連携に関わる外部システムに対して警告を報知する。
【００１９】
連携に異常が発生していると判定する場合として、具体的には次の３パターンが考えられる。
【００２０】
（１）格納リクエストと取得リクエストの組み合わせが周期的に受信された場合、継続して周期的に両リクエストが入るものとする。この場合に、その周期性が崩れた場合に異常と判定する。
【００２１】
（２）取得リクエストが対象とするデータを格納する格納リクエストが周期的に受信された場合、継続して周期的に当該格納リクエストが入るものとする。この場合に、その周期性が崩れた場合に異常と判定する。
【００２２】
（３）取得リクエストが対象とするデータの範囲から、対応する格納リクエストが存在すべきタイミングを特定する。そして、特定したタイミングに格納リクエストが存在しなかった場合に異常と判定する。
【００２３】
アクセス履歴記録部１５６で記録されたアクセス履歴１６０が、上記の異常発生の有無の判定に使用される。格納・取得周期判定部１５７は、アクセス履歴１６０から格納リクエストと取得リクエストの組み合わせの周期性を検出し、次のリクエストが入るタイミング（日時）を予測して監視対象アラート日時テーブル１６１へ記録する。格納周期判定部１５８は、アクセス履歴１６０から格納リクエストの周期性を検出し、次の格納リクエストが入る日時を予測して、定期格納監視テーブル１６３へ記録する。格納・取得周期判定部１５７と格納周期判定部１５８はいずれも格納リクエストに関する周期性を検出するが、両処理部は互いに独立して動く。
【００２４】
アクセス監視部１５９は、リクエストの処理とは非同期でリクエストの有無を常時監視する。アクセス監視部１５９は、リクエストが監視対象アラート日時テーブル１６１あるいは定期格納監視テーブル１６３に記録された予測日時から外れた場合に検知した異常情報を報知手段へ渡す。異常情報の報知手段には、リクエストが入った時に異常を検出しそのリクエストに対する応答で異常に対する警告情報を返す手段と、異常が検出された時にリクエストとは非同期で報知する手段の２つがある。前者はＷｅｂサーバ１５０のレスポンスで返される。後者は非同期報知部１５５が行うものとする。非同期報知部１５５は、アクセス監視部１５９において、異常が検出された場合に、異常を報知すべき外部システムに対して異常の内容を示すメッセージを作成し、メールサーバ１５１からそのメッセージを送信する。メールの送信先はメールアドレステーブル１６２に記録されたメールアドレスから、監視対象アラート日時テーブル１６１に記録されている。
【００２５】
なお、本実施形態においては、非同期報知部１５５による報知方法としてメール送信を例に挙げたが、非同期で送信出来れば、他のメッセージ送信手段を使用してもよい。
【００２６】
［リクエストタイミング］
図３は、格納・取得周期判定部１５７にて判定される、同一リソースにおける、格納リクエストと取得リクエストの組み合わせに周期性があるアクセスの例を示している。受信タイミング３００〜３０９は、格納リクエストおよび取得リクエストを受信するタイミングを示している。受信タイミング３００、３０２、３０４、３０６、３０８は、格納リクエストの受信タイミングを示す。また、受信タイミング３０１、３０３、３０５、３０７、３０９は、取得リクエストの受信タイミングを示す。時間間隔３１０は、格納リクエストの受信タイミング３００から取得リクエストの受信タイミング３０１までの間の時間間隔を示している。同様に時間間隔３１１は、受信タイミング３０４から受信タイミング３０５の間の時間間隔を示し、時間間隔３１２は、受信タイミング３０８から受信タイミング３０９の間の時間間隔を示している。また、時間間隔３１３は、受信タイミング３００から受信タイミング３０４の間の時間間隔を示し、時間間隔３１５は、受信タイミング３０１から受信タイミング３０５の間の時間間隔を示している。同様に時間間隔３１４と時間間隔３１６も格納リクエストの受信タイミング間および取得リクエストの受信タイミング間の時間間隔を示している。図３は、時間間隔３１０、３１１、３１２が等しいことを示している。また、時間間隔３１３、３１４、３１５、３１６も等しいことを示している。なお、本実施形態において、等間隔であることを判定するに当たっては、正確に等間隔ではなく、ある程度の誤差を許容するものとして処理する。ここで扱う誤差の範囲については、後述する。
【００２７】
図３に示すような受信タイミングの関係を示す場合、格納リクエストと取得リクエストとの組み合わせには、定期的な連携を示すリクエスト間の関係性と一定の周期性があると判定できる。具体的には、格納リクエストの受信タイミング３０８を始点として、時間間隔３１４に示す時間を経過したタイミングで同じリソースに対する格納リクエストが入ることを予測できる。また、同様に、取得リクエストの受信タイミング３０９を始点として、時間間隔３１６に示す時間を経過したタイミングで、上記予測した格納リクエストに対応する取得リクエストの受信タイミングとなることが予測できる。
【００２８】
このように、時間的に等間隔の３つの格納リクエストがあり、さらに、同じ時間的に等間隔の３つの取得リクエストが各格納リクエストの間にある場合、格納リクエストと取得リクエストの組み合わせに周期性があるものとして抽出される。図３において、他にも格納リクエストおよび取得リクエストがあり、それぞれのリクエスト間の時間間隔が等しいものも存在するが、周期性に関する条件を満たすものは、時間間隔３１０〜時間間隔３１６に示す関係のリクエスト群となる。周期性に関する詳しい判定方法は図１５を用いて後述する。
【００２９】
図４は、格納周期判定部１５８にて判定される、同一リソースの格納リクエストにおけるアクセスタイミング例と周期性判定について説明するための図である。アクセス日時４００〜４０６は、格納リクエスト（テナントＩＤ、アクセス元、リソースで絞り込んだ状態）のアクセス日時を表している。ここで、アクセス日時４０４は、アクセス予定日時を示し、アクセス日時として実際にアクセス（リクエスト）は無かったことを表している。
【００３０】
アクセス日時４００および４０１のタイミングでは、格納リクエストの周期性は判定されなかったため、アクセス日時４００および４０１の格納リクエストは非定期的なリクエストであると判定される。アクセス日時４０２の格納リクエストが受信されると、過去のアクセス日時４００、４０１および４０２に示す格納リクエストのアクセス日時に基づいて、テナントＩＤ、アクセス元、およびリソースで定まる格納リクエストは定期的であると判定される。アクセス日時４０２の格納リクエストが定期的な格納リクエストであると判定された場合、次の格納リクエストがアクセス日時４０３のタイミングで来ることが予測される。予測タイミングであるアクセス日時４０３までに取得リクエストがくれば、対応するデータが正常に格納されているものとして、取得データのレスポンスを正常に返却する。予測タイミングであるアクセス日時４０３にて、また格納リクエストが来れば、格納リクエストが定期的であるという判定が継続される。
【００３１】
一方、アクセス日時４０４のように、予測タイミングに格納リクエストを受信しなかった場合、次の格納リクエストを受信するまで（期間４２３で示す期間）、取得リクエストに対して、定期的に格納されるべきデータが未格納である旨を示す警告情報をレスポンスとして返す。この場合において、格納リクエストを受け付けた際には、その格納リクエストは非定期的なリクエストとして扱われる。つまり、この時点において、取得リクエストに対しては、警告情報のレスポンスを返さない。さらにアクセス日時４０６のタイミングで格納リクエストを受け付け、その結果、アクセス日時４０３、４０５、４０６の間隔が等間隔となれば、この格納リクエストは定期的であると判定される。
【００３２】
図５は、格納周期判定部１５８にて判定される、格納リクエストに対する別の周期性判定の例である。図５において、受信タイミング４５０、４５１、４５２でリクエストを受け付け、受信タイミング４５２の時点でこれらが定期的な格納リクエストと判定されたことを示している。更に、受信タイミング４５３で示すように、次にリクエストが入ると予測されたタイミングよりも早くリクエストが受信されたため、受信タイミング４５３の格納リクエストは非定期リクエストと判定される。この場合、受信タイミング４５３の格納リクエストが入った時点で非定期的な格納リクエストと判定されるため、以後も、取得リクエストに対しては警告レスポンスを返さない。さらに受信タイミング４５４で格納リクエストが受信され、受信タイミング４５２、４５３、４５４の時間間隔が等間隔（ほぼ等間隔）となれば、これらの受信タイミングにおける格納リクエストは定期的であると判定される。
【００３３】
図６は、履歴系データであるログの更新と取得における、データの存在する範囲（期間）の関係を示したタイミングチャートである。図６において、タイミング５００は格納リクエストを受信したタイミングを示し、タイミング５０１は対応するリソースの取得リクエストを受信したタイミングを示す。タイミング５００で受信した格納リクエストでは、範囲５０２のタイムスタンプを持つログが格納される。また、タイミング５０１で受信した取得リクエストは、範囲５０３に生成されたデータを取得するためのクエリを指定しているものとする。
【００３４】
また、図６において、対象リソースの最後の格納リクエストがタイミング５００であるものとする。ここで、タイミング５００の格納リクエストでは、ログ５１０〜５１３に示すような分布のタイムスタンプのログが格納されたが、事象が発生しておらず存在しないタイミングのログは当然記録されていない。なお、タイミング５００で範囲５０２のログが格納されたということは、範囲５０２でログが存在しないタイミングには記録すべき事象が存在していなかったことも同時に示す。一方、格納リクエストが対象とする範囲外では、事象が存在するか否かが分からない。まだログが記録されていないだけかもしれないし、実際に事象が存在しないかもしれない。タイミング５０１の取得リクエストが指定する範囲５０３のうち、範囲５０４は、そのような時間範囲である。取得処理部１５４は、この状況を判定して、図６におけるタイミング５０１の取得リクエストに対しては、範囲５０４のような不定あるいは未格納情報が存在することを示す警告情報を返却する。
【００３５】
［データ構成］
図７は、本実施形態におけるアクセス履歴１６０の例である。リモートホスト７００は、アクセス元の外部システムであるリモートホストのネットワークアドレスを示す。認証ユーザ７０１は、アクセスする際に認証した認証ユーザを示す。アクセスにて指定されたリモートホスト７００と認証ユーザ７０１の組み合わせが一致する場合は、同一のアクセス元からのアクセスとみなす。本実施形態において、各データはテナントという単位でデータベースに格納されており、テナントにアクセスする権限のあるユーザのみが、そのテナントに属するデータにアクセスすることができる。なお、一般にユーザ認証に失敗した場合には、その旨がアクセス履歴に記録されるが、本実施形態においては、認証に失敗した場合のアクセスは、後述のアクセスの周期性の判定等の対象とはならないものとする。したがって、本実施形態においては、説明の簡略化のため、認証成功したアクセス履歴のみを示している。
【００３６】
アクセス日時７０２は、アクセス日時を示すタイムスタンプを示す。メソッド７０３は、アクセスのメソッドを示し、ＰＯＳＴならば格納リクエスト、ＧＥＴならば取得リクエストであることを示す。リソース７０４はアクセス対象のリソースを示す。リソースはＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）におけるリソースのパス部分を抽出したものであり、アクセス対象データ種別とテナントＩＤを特定する。なお、取得リクエストにおいて検索条件が指定されている場合には、カラムにクエリ文字列が保存される。特定されたリソースに対してＰＯＳＴは格納処理部１５３で処理され、ＧＥＴは取得処理部１５４で処理される。
【００３７】
図８は、アクセス監視部１５９が参照及び更新する、格納リクエストと取得リクエストの組み合わせの周期に関して、監視対象を記録するためのテーブルの構成例を示す。
【００３８】
図８（ａ）は、監視対象アラート日時テーブル１６１の一例である。アクセス監視部１５９は、このテーブルを参照してリクエストの監視を行い、図３にて説明した、格納リクエストと取得リクエストの組み合わせの周期性から外れたリクエストを受信した場合に警告を報知する。
【００３９】
リモートホスト７１０は、アクセス元のアドレスを示す。認証ユーザ７１１は、アクセスする認証ユーザ名を示す。メソッド７１２は、リクエストの種類を示す。リソース７１３は、リクエストの対象となるリソースパスを示している。予測日時７１４は、図３にて説明した周期性の判定に従って予測された、次のリクエストを受信する日時である。許容誤差７１５は、予測日時の許容誤差である。アクセス監視部１５９は、予測日時７１４および許容誤差７１５に基づくタイミングで、リモートホスト７１０から認証ユーザ７１１により、リソース７１３に対するメソッド７１２のリクエストが受信されなかった場合、非同期報知部１５５へその旨を通知する。これにより、非同期報知部１５５は、アラート先７１６とアラート先７１７で指定されたメールアドレスへ、警告情報を送信する。本実施形態において警告メッセージの送信先（アラート先）が二つ設けられている理由は、対応する格納リクエストと取得リクエストのそれぞれに対して送信するためである。格納リクエストが予測通りの日時に受信されなかった場合、非同期報知部１５５は、対応するリソースを格納する外部システムと取得する外部システムの両方に警告メッセージを送信する。取得リクエストが予測通りの日時に受信されなかった場合、非同期報知部１５５は、その取得リクエストを送るべき外部システムへ警告メッセージを送信する。
【００４０】
図８（ｂ）は、リモートホストに対応する警告メッセージの送信先を示すメールアドレステーブル１６２の一例である。メールアドレステーブル１６２は、手動にて予めデータ管理部１５２に登録されているものとする。図８（ａ）に監視対象リクエストを登録する際、図８（ｂ）を参照して、リクエスト種別とリモートホストの組み合わせから警告の送信先が登録される。なお、図８では、リモートホスト７１０と認証ユーザ７１１が一致するリクエストを対象リクエストとして判定しているが、リモートホスト７１０だけでリクエストの一致を判定することも処理の効率化の観点などから有効である。
【００４１】
図９は、定期格納監視テーブル１６３の例である。定期格納監視テーブル１６３は、格納リクエストの周期に関して、監視対象を記録する。アクセス監視部１５９は、定期格納監視テーブル１６３を参照してリクエストの監視を行い、図４および図５にて説明した、格納リクエストの周期性の状態に応じてステータスを変更する。格納リクエストの周期性に異常がある場合、アクセス監視部１５９は、対応する取得リクエストのレスポンスで警告情報を返す。
【００４２】
図９に示す項目のうち、７２０〜７２４は、図８（ａ）に示す監視対象アラート日時テーブル１６１と同様である。ステータス７２５は、予測リクエストの状態を表す。図４および図５における説明の通り、格納リクエストの周期性があると判定された場合、定期格納監視テーブル１６３にレコードが追加され、ステータス７２５が「ＯＫ」に設定される。対象レコードのステータスが「ＯＫ」の間は、リモートホスト７２０と認証ユーザ７２１にて示される要求元から、リソース７２２で示される要求先への格納リクエストは周期性があり、かつ、その周期に従って格納リクエストを受信していることを示している。
【００４３】
図５の受信タイミング４５３で示すように、格納リクエストに対して予測した周期よりも早く格納リクエストを受信した場合には、定期格納監視テーブル１６３からレコードが削除され、その格納リクエストは非定期リクエストとみなされる。格納リクエストの予測日時になっても格納リクエストを受信しない場合には、次の格納リクエストを受信するまで、対象レコードのステータス７２５に「ＮＧ」が設定される。対象レコードのステータスが「ＮＧ」の場合、そのリソースを取得する取得リクエストのレスポンスで警告情報が返される。そして、そのレコードに対応する格納リクエストが来た際に、定期格納監視テーブル１６３からそのレコードが削除され、非定期的なリクエストとみなされる。非定期的な格納リクエストに対応するリソースの取得リクエストでは、対応する格納リクエストの有無にかかわらず、警告情報は返されない。これは、対象とするリソースが元々不定期に更新されるものであるためである。
【００４４】
なお、図８（ａ）に示す監視対象アラート日時テーブル１６１と同様に、定期格納監視テーブル１６３においても、リモートホスト７２０だけでリクエストの一致を判定してもよい。
【００４５】
図１０は、本実施形態に係る対象とするリソースのデータ種別のうち上書き系データであるデバイス構成情報１６４の例を示している。デバイス構成情報１６４は、データ共有システム１００において、管理対象としているデバイスの登録状態を管理するための情報である。図１０では、デバイス構成情報１６４の主要な管理情報の一部を示している。
【００４６】
更新日時７３０は、データ共有システム１００に登録あるいは更新された日時を表している。デバイスＩＤ７３１は、そのレコードで管理するデバイスを一意に識別するための識別情報である。テナントＩＤ７３２は、そのデバイスが登録されている、つまり、そのデバイスを利用しているユーザが属するテナントの識別情報を示している。例えば、リソースとして、デバイス構成情報というデータ種を選択し、さらに、このテナントＩＤを指定することにより、指定されたテナントＩＤを値に持つレコードだけが格納および取得の対象となる。モデル７３３は、デバイスのモデル名である。ネットワークアドレス７３４は、そのデバイスが接続されているネットワークにおけるネットワークアドレスである。オプション情報７３５は、そのデバイスに接続されているオプション機器の情報を示している。
【００４７】
図１０に示すデバイス構成情報１６４のような上書き系データは、情報がいつでも更新される可能性があるため、更新日時７３０だけに基づいて、現在の状態が最新状態であるか否かを判定することはできない。したがって、通常、データ共有システム１００は、取得リクエストに対して、対象リソースが適切に更新されているかを判定することは出来ない。しかし、対象リソースを更新する格納リクエストが定期的に受信している状況において、その格納リクエストを受信しなくなった場合には、何らかの問題が発生していると考えることが出来る。特に、対応する取得リクエストが対象とするリソースの格納リクエストがこのような状態になった場合には、「定期的に更新されなくなった」ことを取得リクエストに応答して警告することで取得したデータの信頼性を確認するきっかけとすることが出来る。
【００４８】
図１１は、本実施形態に係る対象とするリソースのデータ種別のうち履歴系データであるジョブログ１６５の構成例を示している。ジョブログは、データ共有システム１００において、管理対象としているデバイスで処理されたジョブのログを記録するものである。図１１では、ジョブログの主要な情報の一部を示している。
【００４９】
更新日時７４０は、データ共有システム１００に登録された日時を表している。デバイスＩＤ７４１は、そのレコードで管理するデバイスを一意に識別するための識別情報である。テナントＩＤ７４２は、そのデバイスが登録されているテナントの識別情報を示している。ジョブ名７４３はジョブの名称を示す。ジョブタイプ７４４はジョブの種類を示す。ジョブ開始日時７４５とジョブ完了日時７４６はそれぞれジョブの開始日時と完了日時を示す。
【００５０】
図１１に示すジョブログ１６５のような履歴系データは、情報が発生してからデータ共有システム１００に登録されるため、例えば、ジョブ完了日時７４６のような情報は、更新日時７４０よりも過去のこととなる。外部システムが、所定範囲の期間にジョブ完了日時が含まれるようなクエリ条件の取得リクエストを送った場合、そこで指定されたリソースに対応する格納リクエストは、少なくとも指定クエリの範囲よりも後でなければならない。したがって、図６に示すような状態になった場合、「必要な情報が未だ格納されていない可能性がある」ことを取得リクエストに対して警告することで、取得したデータの信頼性をユーザ等が確認するきっかけとすることが出来る。
【００５１】
［処理フロー］
図１２は、データ共有システム１００のリクエスト処理の流れを示すフローチャートである。本実施形態において、本処理フローは、ＣＰＵ１０２が、ＲＯＭ１０４等に格納されたプログラムを読み出して実行する事により実現される。データ共有システム１００が処理を開始すると、以下の処理を繰り返す。
【００５２】
Ｓ１００１にて、Ｗｅｂサーバ１５０は、外部システムからのリクエストを待ち受ける。Ｓ１００２にて、Ｗｅｂサーバ１５０がリクエストを受信する。Ｓ１００３にて、アクセス履歴記録部１５６は、アクセス履歴を記録する。Ｓ１００４にて、Ｗｅｂサーバ１５０は、リクエストの種類を判定する。
【００５３】
リクエストされたＨＴＴＰメソッドがＰＯＳＴの場合（Ｓ１００４にてＹＥＳ）、Ｓ１００５にて、格納処理部１５３は格納処理を行う。本工程における処理については、図１４を用いて後述する。リクエストされたＨＴＴＰメソッドがＧＥＴの場合（Ｓ１００４にてＮＯ）、Ｓ１００６にて取得処理部１５４は、取得処理を行う。本工程における処理については、図１３を用いて後述する。Ｗｅｂサーバ１５０の処理として、他のＨＴＴＰメソッドに対応している場合には、他の処理へも分岐するが、本実施形態においては記載を省略する。なお、本フローチャートにおいては、処理を繰り返しで示しているが、リクエスト受信（Ｓ１００２）において複数の処理スレッドを生成し、複数のリクエストを並列で処理してもよい。
【００５４】
（取得処理）
図１３は、取得処理部１５４にて処理される、図１２のＳ１００６の処理の詳細を示したフローチャートである。
【００５５】
Ｓ１１０１にて、取得処理部１５４は、取得リクエストで指定された検索条件で、データ管理部１５２から返却データを検索する。検索処理が終了すると、Ｓ１１０２にて、取得処理部１５４は、処理結果を判定する。正常終了でない場合（Ｓ１１０２にてＮＯ）、Ｓ１１０９にて、取得処理部１５４は、エラーをリクエスト元へ返す。その後、本処理フローを終了し、図１２の処理へ戻る。
【００５６】
正常終了の場合（Ｓ１１０２にてＹＥＳ）、Ｓ１１０３にて、取得処理部１５４は、リソースのデータ種別を判定する。データ種別が履歴系データの場合（Ｓ１１０３にてＹＥＳ）、Ｓ１１０４にて、取得処理部１５４は、図６、図１１にて説明したように、取得を指定された期間に未格納の可能性がある期間が含まれているか否かを判定する。対象リソースの最終更新日時が取得の指定期間よりも前である場合（Ｓ１１０４にてＹＥＳ）、Ｓ１１０６にて、取得処理部１５４は、警告情報を付加して検索結果をリクエスト元へ返す。その後、Ｓ１１１０へ進む。指定期間よりも後である場合（Ｓ１１０４にてＮＯ）、Ｓ１１０７にて、取得処理部１５４は、正常終了で検索結果をリクエスト元へ返す。その後、Ｓ１１１０へ進む。
【００５７】
一方、データ種別が上書き系データの場合（Ｓ１１０３にてＮＯ）、Ｓ１１０５にて、取得処理部１５４は、図４、図５、図１０にて説明したように、対象データの格納リクエストの周期性に異常があるか否かを判定する。定期格納監視テーブル１６３において検索対象のリソースのステータス７２５が「ＮＧ」である場合（Ｓ１１０５にてＹＥＳ）、Ｓ１１０８にて、取得処理部１５４は、警告情報を付加して検索結果をリクエスト元へ返す。その後、Ｓ１１１０へ進む。ステータスが「ＮＧ」でない場合、Ｓ１１０７にて、取得処理部１５４は、正常終了で検索結果をリクエスト元へ返す。その後、Ｓ１１１０へ進む。
【００５８】
Ｓ１１１０にて、取得処理部１５４は、図３にて説明したように、格納リクエストと取得リクエストの組み合わせの周期性を判定する。本工程における詳細については、図１５を用いて詳細に説明する。
【００５９】
（格納処理）
図１４は、格納処理部１５３にて処理される、図１２のＳ１００５の処理の詳細を示したフローチャートである。
【００６０】
Ｓ１２０１にて、格納処理部１５３は、格納リクエストで指定されたデータをデータ管理部１５２へ格納する。格納処理が終了すると、Ｓ１２０２にて、格納処理部１５３は、処理結果を判定する。正常終了でない場合（Ｓ１２０２にてＮＯ）、Ｓ１２０６にて、格納処理部１５３は、エラーをリクエスト元へ返す。その後、本処理フローを終了し、図１２の処理に戻る。
【００６１】
一方、正常終了の場合（Ｓ１２０２にてＹＥＳ）、Ｓ１２０３にて、格納処理部１５３は、データ種別を判別する。上書き系データの場合（Ｓ１２０３にてＮＯ）、Ｓ１２０４にて、格納処理部１５３は、格納リクエストの周期性判定処理を行う。本工程における詳細は、図１６を用いて詳細に説明する。その後、Ｓ１２０５へ進む。
【００６２】
データ種別が履歴系データの場合（Ｓ１２０３にてＹＥＳ）、Ｓ１２０５にて、格納処理部１５３は、正常終了のステータスをリクエスト元へ返す。その後、本処理フローを終了し、図１２の処理に戻る。
【００６３】
（格納・取得組み合わせ周期性判定処理）
図１５は、格納・取得周期判定部１５７にて処理される、図１３のＳ１１１０の処理の詳細を示したフローチャートである。
【００６４】
Ｓ１３０１にて、格納・取得周期判定部１５７は、アクセス履歴から同一リソースに対する取得リクエストと格納リクエストだけを抽出する。以下、抽出した各取得リクエストのタイミング（日時）を図１３の処理時点からさかのぼって、新しい順に、Ｇ０、Ｇ１、…、Ｇｎとする。ここで、Ｇｎはアクセス履歴１６０中の最後の取得リクエストに対応する。また、Ｇ０は、図１３に示すフローチャートで処理した取得リクエストに対応する。また、抽出した各格納リクエストのタイミング（日時）を図１３の処理時点からさかのぼって、新しい順に、Ｐ０、Ｐ１、…、Ｐｍとする。ここで、Ｐｍは、アクセス履歴１６０中の最後の格納リクエストに対応する。
【００６５】
図１５に示すフローチャートでは、繰り返しを示すため、ｉ、ｊ、ｘ、ｙ、ｚという変数を用いて説明する。図１５は、Ｇ０を含む３つの取得リクエストの間隔と、その３つの取得リクエストの後半２つの間に最後の格納リクエストが入るような３つの格納リクエストの間隔が全て等間隔であるような計６つのリクエストを探すための処理を示す。なお、本実施形態では取得リクエストおよび格納リクエストそれぞれ３つが対象となっているが、これよりも多い数のリクエストを対象として処理してもよい。
【００６６】
Ｓ１３０３〜Ｓ１３３０では、Ｇ０の一つ過去の取得リクエストＧｉを決定するためのループを示している。３つの取得リクエストを取らなければならないため、Ｓ１３０３の判定条件においてｉはｎを含めない。Ｓ１３０３およびＳ１３３０は、ｉがｎより小さい間、ｉをインクリメントしながら（Ｓ１３２９）、Ｓ１３０４〜Ｓ１３２８の処理のループを示す。
【００６７】
Ｓ１３０４にて、格納・取得周期判定部１５７は、Ｇ０とＧｉが同じアクセス元からのリクエストであるか否かを判定する。同じアクセス元である場合（Ｓ１３０４にてＹＥＳ）、更にＧｊのリクエストを調べるためにＳ１３０５へ進む。同じアクセス元でない場合（Ｓ１３０４にてＮＯ）、次のＧｉを調べるためにＳ１３２９へ進む。
【００６８】
Ｓ１３０５にて、格納・取得周期判定部１５７は、Ｇｉの次のリクエストから順にリクエストを調べるためにｊをｉの次の値とする。Ｓ１３０６〜Ｓ１３２８では、Ｇ０の２つ過去の取得リクエストＧｊを決定するためのループを示している。Ｓ１３０６およびＳ１３２８は、ｊがｎ以下の間、ｊをインクリメントしながら（Ｓ１３２７）、Ｓ１３０７〜Ｓ１３２６の処理のループを示す。
【００６９】
Ｓ１３０７にて、格納・取得周期判定部１５７は、ＧｉとＧｊが同じアクセス元からのリクエストであるかを判定する。同じアクセス元である場合（Ｓ１３０７にてＹＥＳ）、Ｓ１３０８へ進む。同じアクセス元でない場合（Ｓ１３０７にてＮＯ）、Ｓ１３２７へ進む。
【００７０】
Ｓ１３０８にて、格納・取得周期判定部１５７は、この時点で仮決めした３つの取得リクエスト（Ｇ０、Ｇｉ、Ｇｊ）が所定の誤差を許容した上で等間隔であるかを判定する。本実施形態において、ここで用いる所定の誤差は、リクエスト間隔の差異を１１％以内とする。なお、１１％は、月単位の定期処理を考慮した時の閏年を含む最も誤差が大きくなる間隔差を許容するものである。ここでは等間隔（もしくは、ほぼ等間隔）であることを“≒”にて示す。
【００７１】
等間隔であると判定された場合（Ｓ１３０８にてＹＥＳ）、Ｓ１３０９にて、格納・取得周期判定部１５７は、さらに格納リクエストも含めて等間隔な格納リクエストを検索する。等間隔でないと判定された場合（Ｓ１３０８にてＮＯ）、Ｓ１３０７へ進み、次の取得リクエストを探すため処理を続ける。
【００７２】
Ｓ１３０９にて、格納・取得周期判定部１５７は、格納リクエストを最初から順に調べるため、ｘを最初の値を示す０とする。Ｓ１３１０〜Ｓ１３２６では、等間隔格納リクエストのうち最新の格納リクエストＰｘを決定するためのループを示す。ここで、Ｓ１３１０におけるＰｘの条件は、Ｇｉ（この時点で仮決めしている中央の取得リクエストのタイミング）よりも後のリクエストであることとする。これは、Ｇｉ以前のリクエストで等間隔の格納リクエストが見つかるとすれば、次の予測された格納リクエストのタイミングが現時点よりも過去になり、既に周期性が崩れていることになるからである。Ｓ１３１０およびＳ１３２６は、ＰｘがＧｉよりも後のリクエストである間、ｘをインクリメントしながら（Ｓ１３２５）、Ｓ１３１１〜Ｓ１３２４のループを示す。
【００７３】
Ｓ１３１１にて、格納・取得周期判定部１５７は、Ｐｘの次のリクエストから順にリクエストを調べるためにｙをｘの次の値とする。
【００７４】
Ｓ１３１２〜Ｓ１３２４では、Ｐｘの一つ過去の格納リクエストＰｙを決定するためのループを示している。３つの格納リクエストを取らなければならないため、ｙはｍを含めない（Ｓ１３１２）。Ｓ１３１２およびＳ１３２４は、ｙがｍよりも小さい間、ｙをインクリメントしながら（Ｓ１３２３）、Ｓ１３１３〜Ｓ１３２２の処理のループを示す。
【００７５】
Ｓ１３１３にて、格納・取得周期判定部１５７は、ＰｘとＰｙが同じアクセス元からのリクエストであるか否かを判定する。同じアクセス元である場合（Ｓ１３１３にてＹＥＳ）、Ｓ１３１４へ進む。同じアクセス元でない場合（Ｓ１３１３にてＮＯ）、Ｓ１３２３へ進む。
【００７６】
Ｓ１３１４にて、格納・取得周期判定部１５７は、この時点で仮決めした３つの取得リクエストおよび２つの格納リクエスト（Ｐｘ、Ｐｙ）が同上の所定誤差を許容した上で等間隔であるかを判定する。等間隔であると判定された場合（Ｓ１３１４にてＹＥＳ）、Ｓ１３１５へ進む。等間隔でないと判定された場合（Ｓ１３１４にてＮＯ）、格納・取得周期判定部１５７は、次の格納リクエストを探すため処理を続ける。
【００７７】
Ｓ１３１５にて、格納・取得周期判定部１５７は、Ｐｙの次のリクエストから順にリクエストを調べるためにｚをｙの次の値とする。
【００７８】
Ｓ１３１６〜Ｓ１３２２では、３番目の格納リクエストを決定するためのループを示している。Ｓ１３１６およびＳ１３２２は、ｚがｍ以下の間、ｚをインクリメントしながら（Ｓ１３２１）、Ｓ１３１７〜Ｓ１３２０の処理のループを示す。
【００７９】
Ｓ１３１７にて、格納・取得周期判定部１５７は、ＰｙとＰｚが同じアクセス元からのリクエストであるかを判定する。同じアクセス元である場合（Ｓ１３１７にてＹＥＳ）、Ｓ１３１８へ進む。同じアクセス元でない場合（Ｓ１３１７にてＮＯ）、Ｓ１３２１へ進む。
【００８０】
Ｓ１３１８にて、格納・取得周期判定部１５７は、３つの取得リクエストと３つの格納リクエストが同上のように等間隔であるか否かを判定する。等間隔であると判定された場合（Ｓ１３１８にてＹＥＳ）、Ｓ１３１９にて、格納・取得周期判定部１５７は、次の格納リクエストの日時を予測する。格納・取得周期判定部１５７は、Ｐｘ、Ｐｙのリクエスト間隔と同じ間隔で次の格納リクエストを受信すると予測し、図８で例示した監視対象アラート日時テーブル１６１にレコードを追加する。また、許容誤差７１５については、Ｐｘ、Ｐｙ間のリクエスト間隔に１１％分の幅を追加で持たせたものとする。
【００８１】
Ｓ１３２０にて、格納・取得周期判定部１５７は、次の取得リクエストの日時を予測する。格納・取得周期判定部１５７は、Ｐｘ、Ｐｙのリクエスト間隔と同じ間隔で次の取得リクエストを受信すると予測し、図８で例示した監視対象アラート日時テーブル１６１にレコードを追加する。また、許容誤差７１５については、Ｐｘ、Ｐｙ間のリクエスト間隔に１１％分の幅を追加で持たせたものとする。
【００８２】
等間隔でないと判定された場合（Ｓ１３１８にてＮＯ）、格納・取得周期判定部１５７は、次の格納リクエストを探すため処理を続ける。
【００８３】
（格納周期性判定処理）
図１６は、格納周期判定部１５８において処理される、図１４のＳ１２０４の処理の詳細を示したフローチャートである。
【００８４】
Ｓ１４０１にて、格納周期判定部１５８は、アクセス履歴１６０から図１４で処理した格納リクエストと同じアクセス元と同じリソースに対する格納リクエストを抽出する。Ｓ１４０２にて、格納周期判定部１５８は、図１４で処理した今回の格納リクエストのタイミングをＰ０とする。Ｓ１４０３にて、格納周期判定部１５８は、前回の格納リクエストのタイミングをＰ１とする。Ｓ１４０４にて、格納周期判定部１５８は、前々回の格納リクエストのタイミングをＰ２とする。
【００８５】
Ｓ１４０５にて、格納周期判定部１５８は、図９に示す定期格納監視テーブル１６３に、同アクセス元、かつ、同リソースのレコードが存在するかを確認する。レコードが存在する場合（Ｓ１４０５にてＹＥＳ）、Ｓ１４０６進む。レコードが存在しない場合（Ｓ１４０５にてＮＯ）、Ｓ１４０９に進む。
【００８６】
Ｓ１４０６にて、格納周期判定部１５８は、既存レコードのステータス７２５が周期性有り（「ＯＫ」）か否かを判定する。周期性がある場合（Ｓ１４０６にてＹＥＳ）、Ｓ１４０７ヘ進む。ステータス７２５が「ＮＧ」である場合（Ｓ１４０６にてＮＯ）、Ｓ１４０８にて、格納周期判定部１５８は、定期格納監視テーブル１６３から該当レコードを削除する。その後、本処理フローを終了し、図１４の処理に戻る。
【００８７】
Ｓ１４０７にて、格納周期判定部１５８は、今回の格納リクエストが定期格納監視テーブル１６３に記録されている予測範囲内のタイミングで受信したか否かを判定する。予測タイミングの範囲内で無い場合（Ｓ１４０７にてＮＯ）、格納周期判定部１５８は、予測タイミングよりも早く受信したと判定し、Ｓ１４０８にて、格納周期判定部１５８は、定期格納監視テーブル１６３から該当レコードを削除する。なお、予測タイミングになってもリクエストが来なかった場合、格納周期判定部１５８は、図１７に示す監視処理において、ステータス７２５を「ＮＧ」に変更する。予測タイミングの範囲内でリクエストを受信した場合（Ｓ１４０７にてＹＥＳ）、Ｓ１４１２へ進む。
【００８８】
Ｓ１４０９にて、格納周期判定部１５８は、３つの取得リクエスト（Ｐ０、Ｐ１、Ｐ２）が所定の誤差を許容した上で等間隔であるかを判定する。本実施形態において所定誤差は、前述のようにリクエスト間隔から１１％以内の差異とする。等間隔である場合（Ｓ１４０９にてＹＥＳ）Ｓ１４１０へ進む。等間隔でない場合（Ｓ１４０９にてＮＯ）、本処理フローを終了し、図１４の処理に戻る。
【００８９】
Ｓ１４１０にて、格納周期判定部１５８は、定期格納監視テーブル１６３に該当レコードを追加する。Ｓ１４１１にて、格納周期判定部１５８は、当該レコードのステータス７２５を「ＯＫ」とする。Ｓ１４１２にて、格納周期判定部１５８は、次の予測日時７２３を、Ｐ０、Ｐ１のリクエスト間隔とおなじ間隔で次の格納リクエストを受信すると予測して設定する。Ｓ１４１３にて、格納周期判定部１５８は、許容誤差７２４を、Ｐｘ、Ｐｙ間のリクエスト間隔に１１％分の幅を追加で持たせたものを設定する。その後、本処理フローを終了し、図１４の処理に戻る。
【００９０】
（監視処理）
図１７は、アクセス監視部１５９における処理の流れを示すフローチャートである。データ共有システム１００が動作を開始すると、図１７に示す処理は、図１２に示すリクエスト処理とは並行して動作する。
【００９１】
Ｓ１５０１〜Ｓ１５０８では、アクセス監視部１５９は、図８に示す監視対象アラート日時テーブル１６１を順に走査し、現在日時が、記録されているリクエストの予測日時に達したか否かを確認する。
【００９２】
Ｓ１５０２にて、アクセス監視部１５９は、予測日時７１４と現在時刻を比較する。Ｓ１５０３にて、アクセス監視部１５９は、Ｓ１５０２の比較の結果、予測日時に達したか否かを判定する。予測時間でない場合（Ｓ１５０３にてＮＯ）、アクセス監視部１５９は、次のレコードに対する確認へ進む。予測日時に達した場合（Ｓ１５０３にてＹＥＳ）、Ｓ１５０４にて、アクセス監視部１５９は、図７に示すアクセス履歴１６０を確認する。
【００９３】
Ｓ１５０４の確認の結果、アクセス監視部１５９は、許容誤差を含め、予測の範囲内でアクセスがある場合（Ｓ１５０５にてＹＥＳ）、Ｓ１５０７にて、アクセス監視部１５９は、監視対象アラート日時テーブル１６１から該当レコードを削除する。
【００９４】
確認の結果、アクセスがなければ（Ｓ１５０５にてＮＯ）、Ｓ１５０６にて、アクセス監視部１５９は、監視対象アラート日時テーブルのアラート先７１６、７１７にあるメールアドレスへ、予測通りにリクエストを受信しなかった旨の警告メッセージを送信する。その後、Ｓ１５０７へ進む。
【００９５】
Ｓ１５０９〜Ｓ１５１３では、アクセス監視部１５９は、図９に示す定期格納監視テーブル１６３を順に走査し、現在日時が、記録されているリクエストの予測日時が来たか否かを確認する。Ｓ１５１０にて、アクセス監視部１５９は、予測日時７２３と現在日時を比較する。Ｓ１５１１にて、アクセス監視部１５９は、Ｓ１５１０の比較の結果、許容誤差７２４を踏まえた予測日時を超過したか否かを判定する。予測日時を過ぎている場合（Ｓ１５１１にてＹＥＳ）、Ｓ１５１２にて、アクセス監視部１５９は、当該レコードのステータス７２５を「ＮＧ」とする。
【００９６】
以上により、データ共有システムがアクセス履歴から連携すべき格納リクエストと取得リクエストの存在を判定し、対象となるリクエストの有無からリクエスト元へ連携状態の異常の警告を報知することが出来る。これにより、連携すべき外部システムの組み合わせが存在する場合に、各外部システムにてそれぞれ特別な手段を持たなくとも、データ共有による連携状態の監視を行うことが可能となる。また、監視のスケジュールに関する設定を手動で個別に行う必要もない。
【００９７】
報知手段としては、メールによる非同期での警告通知とアクセスＩＦにおけるレスポンスとして警告情報を返すという二つの手段で報知することが出来るため、外部システムの種類や事情により、両方あるいはいずれかの手段も選択することが出来る。なお、本実施形態においては、非同期での通知手段としてメール送信を例に挙げたが、その他のイベント通知手段を使用してもよい。
【００９８】
＜その他の実施形態＞
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００９９】
１００  データ共有システム、１２１  外部システム、１２２  外部システム、１５２  データ管理部、１５３  格納処理部、１５４  取得処理部、１５５  非同期報知部、１５６  アクセス履歴記録部、１５７  格納・取得周期判定部、１５８  格納周期判定部、１５９  アクセス監視部 
【図１】
2015203980.tif 000003
【図２】
2015203980.tif 000004
【図３】
2015203980.tif 000005
【図４】
2015203980.tif 000006
【図５】
2015203980.tif 000007
【図６】
2015203980.tif 000008
【図７】
2015203980.tif 000009
【図８】
2015203980.tif 000010
【図９】
2015203980.tif 000011
【図１０】
2015203980.tif 000012
【図１１】
2015203980.tif 000013
【図１２】
2015203980.tif 000014
【図１３】
2015203980.tif 000015
【図１４】
2015203980.tif 000016
【図１５】
2015203980.tif 000017
【図１６】
2015203980.tif 000018
【図１７】
2015203980.tif 000019