(57)【要約】【課題】リクエスト時に処理時間が変化したとしても、外部システムの時間制約内でリクエストが時間的に分散されて処理できるようにすることを目的とする。【解決手段】定期リクエストの時間制約情報とリクエスト内容とを含む予告情報を受信する受信手段と、前記受信手段により受信された前記予告情報に含まれる前記リクエスト内容に基づいて、前記定期リクエストに係る処理の処理時間を見積る見積手段と、前記受信手段により受信された前記予告情報に含まれる前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記定期リクエストを受け付ける受付期間を表すスケジュール情報を作成する作成手段と、前記定期リクエストに係る処理の実行状況と前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記スケジュール情報を修正する修正手段と、を有する。【選択図】図６
2016057916.tif 000002
【特許請求の範囲】
【請求項１】
定期リクエストの時間制約情報とリクエスト内容とを含む予告情報を受信する受信手段と、
前記受信手段により受信された前記予告情報に含まれる前記リクエスト内容に基づいて、前記定期リクエストに係る処理の処理時間を見積る見積手段と、
前記受信手段により受信された前記予告情報に含まれる前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記定期リクエストを受け付ける受付期間を表すスケジュール情報を作成する作成手段と、
前記定期リクエストに係る処理の実行状況と前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記スケジュール情報を修正する修正手段と、
を有するデータ共有システム。
【請求項２】
前記リクエスト内容には、前記定期リクエストの処理種別情報と処理データ種別情報とが含まれ、前記処理種別情報がデータ格納処理を示す情報である場合、前記リクエスト内容には、更に格納データ数情報が含まれ、
前記見積手段は、前記処理種別情報と前記処理データ種別情報と前記格納データ数情報とに基づいて前記定期リクエストに係る処理の処理時間を見積る請求項１記載のデータ共有システム。
【請求項３】
前記リクエスト内容には、前記定期リクエストの処理種別情報と処理データ種別情報とが含まれ、前記処理種別情報がデータ取得処理を示す情報である場合、前記リクエスト内容には、更にデータ検索条件情報が含まれ、
前記見積手段は、処理種別情報と処理データ種別情報と前記データ検索条件情報に基づき記憶部から検索される処理対象のデータ数とに基づいて前記定期リクエストに係る処理の処理時間を見積る請求項１又は２記載のデータ共有システム。
【請求項４】
前記修正手段は、前記定期リクエストの中のリクエストに係る処理の終了時刻が、前記スケジュール情報に表された前記リクエストに対応する受付期間の終了時刻をよりも後である場合、未処理のリクエストについての前記スケジュール情報を、前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、修正する請求項１乃至３何れか１項記載のデータ共有システム。
【請求項５】
前記時間制約情報には前記定期リクエストに係る処理の開始予定時刻と処理完了時刻とが含まれ、
前記作成手段は、前記開始予定時刻から前記処理完了時刻までの期間内に、前記見積手段により見積られた前記処理時間に基づいて、前記定期リクエストを受け付ける受付期間を重複しないように決定することでスケジュール情報を作成し、
前記修正手段は、前記定期リクエストの中のリクエストに係る処理の終了時刻が、前記スケジュール情報に表される前記リクエストに係る処理の受付期間の終了時刻より後である場合、前記開始予定時刻から前記処理完了時刻までの期間内に、前記見積手段により見積られた前記処理時間に基づいて、未処理のリクエストを受け付ける受付期間を重複しないように決定することで前記スケジュール情報を修正する請求項１乃至４何れか１項記載のデータ共有システム。
【請求項６】
前記作成手段は、前記リクエスト内容に基づいて前記定期リクエストの中のリクエストの優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を重複しないように決定することで前記スケジュール情報を作成し、
前記修正手段は、前記リクエスト内容に基づき前記定期リクエストの中のリクエストの優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を重複しないように決定することで前記スケジュール情報を修正する請求項１乃至５何れか１項記載のデータ共有システム。
【請求項７】
前記リクエスト内容には、前記定期リクエストの処理種別情報が含まれ、
前記作成手段は、前記処理種別情報に基づき前記定期リクエストの中のリクエストの優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を決定することで前記スケジュール情報を作成し、
前記修正手段は、前記処理種別情報に基づき前記定期リクエストの中のリクエストの優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を決定することで前記スケジュール情報を修正する請求項６記載のデータ共有システム。
【請求項８】
前記リクエスト内容には、前記定期リクエストの処理データ種別情報が含まれ、
前記作成手段は、前記処理データ種別情報に基づき優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を決定することで前記スケジュール情報を作成し、
前記修正手段は、前記処理データ種別情報に基づき優先順位を決定し、前記優先順位が最も高いものから順に、前記定期リクエストの中のリクエストの受付期間を決定することで前記スケジュール情報を修正する請求項６又は７記載のデータ共有システム。
【請求項９】
前記作成手段は、受付期間の重複がないように、前記定期リクエストの中のリクエストのうち処理時間が延長するリクエストについて前記リクエストの受付期間を決定し、前記受付期間にバッファ期間を決定し、前記バッファ期間に対して前記定期リクエストの中のリクエストのうち処理時間が延長しないリクエストの受付期間を決定することでスケジュール情報を作成し、
前記修正手段は、受付期間の重複がないように、前記定期リクエストの中のリクエストのうち処理時間が延長するリクエストについて前記リクエストの受付期間を決定し、前記受付期間にバッファ期間を決定し、前記バッファ期間に対して前記定期リクエストの中のリクエストのうち処理時間が延長しないリクエストの受付期間を決定することでスケジュール情報を修正する請求項１乃至８何れか１項記載のデータ共有システム。
【請求項１０】
リクエストに係る処理に関するエラーが発生した場合、前記エラーを示すレスポンスを前記リクエストのリクエスト元に対して送信する送信手段を更に有する請求項１乃至９何れか１項記載のデータ共有システム。
【請求項１１】
前記送信手段は、前記スケジュール情報に表された前記リクエストの受付期間外にリクエストを受け付けた場合、前記リクエストのリクエスト元に対してリクエストを禁止することを示すレスポンスを送信する請求項１０記載のデータ共有システム。
【請求項１２】
前記送信手段は、前記スケジュール情報に表されたリクエストの受付期間外に前記リクエストを受け付けた場合、前記リクエストのリクエスト元に対して前記リクエストを再び実行することを推奨することを示すレスポンスを送信する請求項１０又は１１記載のデータ共有システム。
【請求項１３】
前記送信手段は、前記スケジュール情報に表された前記リクエストの受付期間外にリクエストを受け付けた場合、前記リクエストのリクエスト元に対してリクエストを再び実行することを推奨することを示すレスポンスと前記リクエストを受け付ける時刻情報とを送信する請求項１０乃至１２何れか１項記載のデータ共有システム。
【請求項１４】
前記送信手段は、前記修正手段による前記スケジュール情報の修正が失敗した場合、受付期間の決定が失敗したリクエストのリクエスト元に対して、受付期間の決定が失敗したことを示すレスポンスを送信する請求項１０乃至１３何れか１項記載のデータ共有システム。
【請求項１５】
前記作成手段による前記スケジュール情報の作成が失敗した場合、前記スケジュール情報の作成が失敗したことを示す警告情報を出力部に出力する出力手段を更に有する請求項１乃至１４何れか１項記載のデータ共有システム。
【請求項１６】
前記出力手段は、前記作成手段による前記スケジュール情報の作成が失敗した場合、前記スケジュール情報の作成が失敗したことを示す警告情報を表示部に表示することで出力する請求項１５記載のデータ共有システム。
【請求項１７】
データ共有システムが実行する情報処理方法であって、
定期リクエストの時間制約情報とリクエスト内容とを含む予告情報を受信する受信ステップと、
前記受信ステップにより受信された前記予告情報に含まれる前記リクエスト内容に基づいて、前記定期リクエストに係る処理の処理時間を見積る見積りステップと、
前記受信ステップにより受信された前記予告情報に含まれる前記時間制約情報と前記見積りステップにより見積られた前記処理時間とに基づいて、前記定期リクエストを受け付ける受付期間を表すスケジュール情報を作成する作成ステップと、
前記定期リクエストに係る処理の実行状況と前記時間制約情報と前記見積りステップにより見積られた前記処理時間とに基づいて、前記スケジュール情報を修正する修正ステップと、
を含む情報処理方法。
【請求項１８】
コンピュータに、
定期リクエストの時間制約情報とリクエスト内容とを含む予告情報を受信する受信ステップと、
前記受信ステップにより受信された前記予告情報に含まれる前記リクエスト内容に基づいて、前記定期リクエストに係る処理の処理時間を見積る見積りステップと、
前記受信ステップにより受信された前記予告情報に含まれる前記時間制約情報と前記見積りステップにより見積られた前記処理時間とに基づいて、前記定期リクエストを受け付ける受付期間を表すスケジュール情報を作成する作成ステップと、
前記定期リクエストに係る処理の実行状況と前記時間制約情報と前記見積りステップにより見積られた前記処理時間とに基づいて、前記スケジュール情報を修正する修正ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ共有システム、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
マネージド・プリント・サービス（ＭＰＳ）は、企業のオフィス出力環境の現状を分析し、最適な出力環境を提案、構築するアウトソーシングサービスである。ＭＰＳを提供するベンダーは、顧客である企業のオフィス環境から設置された印刷デバイス、利用しているソフトウェア、サービス等の情報を収集、蓄積し、分析のために利用する。また、オフィス環境からの情報収集のためのシステムは、クラウドサービス上に移行される傾向にある。このため、印刷デバイスの販売会社は、独自のシステムを構築しなくても顧客である企業へＭＰＳを提供することができる。
ところで、各販売会社は、より品質の高いサービスを提供するため、他の販売会社に対する差別化を図るため、収集した情報の分析及び顧客企業への最適環境の提案を独自に行いたい場合がある。このため、販売会社は、それぞれ独自の分析システムを構築し、クラウドサービス上のＭＰＳ用システムとシステム間連携を行い、ＭＰＳ用システムに収集された情報を検索、取得する。
また、他方で、国際展開する顧客企業を対象とする販売会社は、各国の販売会社間で互いに収集した情報を交換、共有するための手段として、ＭＰＳ用システムを利用したい場合がある。より具体的には、ある販売会社のシステムが収集した情報がＭＰＳ用システムと連携したデータ共有システムに格納され、別の販売会社のシステムは、その情報を取得する。
【０００３】
上述のように、データ共有システムに対して、様々なシステムが接続し、アクセスを行う。データ共有システムと外部システムとなる複数のシステムとは、互いの存在を意識していない。また、データ共有を目的とする外部システムは、各システムの持つ時間制約の中で、データ共有システムを介して定期的なデータ連携を行う。ここで、時間制約とは、各システムにおける処理スケジュールに基づいた、アクセスリクエストの開始予定時刻とデータアクセスの処理完了期限（時刻）とである。アクセスリクエストの処理時間は、外部システムがデータ共有システムへリクエストを送信する時点のデータに依存するため、リクエスト毎に変化する可能性がある。例えば、データ取得リクエストに対する処理時間は、データ共有システムのデータベースにおける取得対象データ量に依存する。また、データ格納リクエストに対する処理時間は、外部システムが送信するリクエストのデータ量に依存する。
ＭＰＳを提供する販売会社の増加に従い、データ共有システムに接続するシステムは、次第に増加していくこととなる。そうなると、データ共有システム対するアクセスリクエストが集中する可能性が高くなる。データ共有システムは、アクセスリクエストが一時に集中すると、処理の待ち時間が増え、定期的なデータ連携を行う各外部システムの制約時間内にシステム連携を行うことができなくなる。接続する外部システムの数がデータ共有システムの性能限界に到達するまで、サーバ増強等のコストアップをせずにできるだけ多くの外部システムとのシステム連携が保証されるのが望ましい。
このような場合、各外部システムのアクセスタイミングが重ならないようにスケジューリングすれば、データ共有システムに対する負荷を分散することができる。従来、処理の予約情報を用いてスケジュールを作成し、スケジュールに従った処理を行う技術がある。例えば、特許文献１に示す技術は、車両の充電のため、充電の予約情報を用いてスケジュールを作成し、予約車両の到着時刻に応じたスケジュールを再作成するシステムである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１４９０３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、データ共有システムのリクエスト処理時間は、前述の通り、外部システムがデータ共有システムへアクセスリクエストを送信したタイミングで決まる対象データ量に従って変化する可能性がある。そのため、データ共有システムは、予め作成されたスケジュール通りに処理できるとは限らない。特許文献１に示す技術では、到着時刻の変更に対してスケジュールを再作成している。到着時刻の遅れに対して、予約した充電時間を確保できない場合には、車両のナビゲーション装置に通知する。しかし、データ共有システムでは、スケジュールに従って処理を起動するわけではなく、あくまでも外部システムからのリクエストを受信してから処理を行うことになる。そのため、各外部システムは、再作成されたスケジュールに従う動きをすることはできない。また、特許文献１に示す技術の場合には、処理時間（充電時間）の変化や、外部システム（車両）の時間制約が考慮されていない。データ共有システムでは、分散処理をするために予めスケジュールを作成しておいても、リクエスト時に処理時間が変化すると、スケジュール通りに処理できない場合があるという問題があった。
そこで、本発明は、リクエスト時に処理時間が変化したとしても、外部システムの時間制約内でリクエストが時間的に分散されて処理できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明のデータ共有システムは、定期リクエストの時間制約情報とリクエスト内容とを含む予告情報を受信する受信手段と、前記受信手段により受信された前記予告情報に含まれる前記リクエスト内容に基づいて、前記定期リクエストに係る処理の処理時間を見積る見積手段と、前記受信手段により受信された前記予告情報に含まれる前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記定期リクエストを受け付ける受付期間を表すスケジュール情報を作成する作成手段と、前記定期リクエストに係る処理の実行状況と前記時間制約情報と前記見積手段により見積られた前記処理時間とに基づいて、前記スケジュール情報を修正する修正手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、リクエスト時に処理時間が変化したとしても、外部システムの時間制約内でリクエストが時間的に分散されて処理できるようにすることができる。
【図面の簡単な説明】
【０００８】
【図１】データ共有システムのシステム構成の一例を示す図である。
【図２】データ共有システムの機能構成の一例を示す図である。
【図３】予告情報と処理時間見積との凡例を示す図である。
【図４】予告情報のソートの一例を示す図である。
【図５】スケジュール作成の一例を示す図である。
【図６】スケジュール作成の一例を示す図である。
【図７】リクエストとレスポンスとの凡例を示す図である。
【図８】リクエスト受信時のタイミングチャートの一例を示す図である。
【図９】リクエスト受信時のタイミングチャートの一例を示す図である。
【図１０】スケジュールエラーのタイミングチャートの一例を示す図である。
【図１１】予告情報入力処理及びスケジュール作成処理の一例を示すフローチャートである。
【図１２】件数集計処理及びスケジュール作成処理の一例を示すフローチャートである。
【図１３】スケジュール作成処理の一例を示すフローチャートである。
【図１４】グループ単位のスケジュール作成処理の一例を示すフローチャートである。
【図１５】リクエスト受信処理の一例を示すフローチャートである。
【図１６】スケジュール時間帯におけるリクエスト処理の一例を示すフローチャートである。
【図１７】処理延期時の再スケジュール処理の一例を示すフローチャートである。
【図１８】データ共有システム内のサーバ装置のハードウェア構成の一例を示す図である。
【図１９】リクエストタイミング返却のタイミングチャートの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、データ共有システム１００のシステム構成の一例を示す図である。
データ共有システム１００は、Ｗｅｂサーバ１１０と、ＤＢサーバ１１１と、アプリケーションサーバ１１２と、を含む。データ共有システムは、外部のネットワーク１２０に接続されたＷｅｂサーバ１１０を介して、外部システム１２１、１２２、１２３と通信を行い、データ共有によるシステム連携を行う。
外部システム１２１は、デバイス管理システムであり、マルチ・ファンクション・プリンタ（ＭＦＰ）１２５やシングル・ファンクション・プリンタ（ＳＦＰ）１２６等のデバイスと接続し、前記デバイスの情報を収集、管理する。外部システム１２２は、外部システム１２１と同様に接続したデバイスの情報を収集、管理する。外部システム１２１又は外部システム１２２は、データ共有システムへ、自身が収集、管理しているデバイスの情報を送信する。データ共有システム１００は、送信された前記デバイスの情報を格納し、他の外部システムからも利用できるようにする。一方、外部システムは、データ共有システム１００に格納されている前記デバイスの情報を取得し、分析等に利用する。外部システム１２３のようなデータを取得するだけの外部システムは、デバイスが接続されていない場合がある。図１に示す例において、外部システムとして３つが示されているが、データ共有システム１００に接続される外部システムの数は、３つに限られず、３よりも多くても少なくてもよい。また、外部システムには、ＭＦＰ、ＳＦＰ以外にもデバイスを接続してもよい。
【００１１】
図２は、データ共有システム１００の機能構成の一例を示す図である。
データ共有システム１００と外部システム１２１とは、図１における同番号のハードウェア構成に対応するものである。
データ共有システム１００は、複数の機能構成（１５０〜１６１）を持ち、接続された外部システム１２１と連携して動作する。
データ管理部１５２は、連携インタフェース部１５０を介して外部システム１２１から格納及び取得されるデータ（１７１〜１７２）、内部処理のための管理テーブル（１７３〜１７８）等のデータを管理する。機能構成（１５５〜１６０）は、データ管理部１５２にアクセスする際、ＤＢアクセス部１６１を介してアクセスする。データ管理部１５２は、本実施形態ではＳＱＬサーバ等のデータベースであるとするが、他のファイルシステム等でもよい。データ管理部１５２が管理するデータ（１７１〜１７２）、管理テーブル（１７３〜１７８）等のデータは、図１８で後述するＨＤＤ１０７、ＲＯＭ１０４等に記憶されているものとする。
【００１２】
連携インタフェース部１５０は、ＨＴＴＰの仕様に準拠したプロトコルを実装しているＨＴＴＰサーバ等であり、Ｗｅｂサーバ１１０上に実装されている。連携インタフェース部１５０は、クライアントとなる外部システム１２１からのＨＴＴＰリクエストを受信し処理し、処理の結果をレスポンスとして外部システム１２１へ返す。リクエスト受信部１５３は、前記ＨＴＴＰリクエストのリクエスト内容を抽出する。連携インタフェース部１５０、リクエスト受信部１５３は、本実施形態においてＨＴＴＰを利用したリクエストを受信することとして説明するが、他のプロトコルを利用したリクエストを受信することとしてもよい。
外部システム１２１からのリクエストには、格納リクエストと取得リクエストとの二種類がある。リクエストスケジュール判断部１５５は、リクエスト受信部１５３により抽出された前記リクエストのリクエスト内容が示す処理が、実行可能か否かを判断する。リクエストスケジュール判断部１５５にて処理が可能であると判断され、リクエストが格納リクエストである場合、格納処理部１５９は、前記リクエストに係る処理を実行する。リクエストスケジュール判断部１５５にて処理が可能であると判断され、リクエストが取得リクエストである場合、取得処理部１６０は、前記リクエストに係る処理を実行する。本実施形態における格納リクエストには、ＨＴＴＰのＰＯＳＴメソッドが用いられ、前記格納リクエストのヘッダ（ＵＲＩ）にて格納対象のデータ種が指定され、前記格納リクエストのボディで格納データが指定される。データ種は、処理データ種別情報の一例である。また、本実施形態における取得リクエストには、ＨＴＴＰのＧＥＴメソッドが用いられ、前記取得リクエストのヘッダ（ＵＲＩ）にて取得対象のデータ種と検索条件とが指定される。リクエストスケジュール判断部１５５にて、処理が不可能と判断された場合、レスポンス返信部１５４は、連携インタフェース部１５０を介して、即時レスポンスを外部システム１２１へ返す。取得リクエストに係る処理は、データ取得処理の一例であり、格納リクエストに係る処理は、データ格納処理の一例である。
【００１３】
格納処理部１５９は、外部システム１２１からの格納リクエストに従って、前記格納リクエストのボディに指定されたリソースをデータ管理部１５２に格納する。また、取得処理部１６０は、外部システム１２１からの取得リクエストに従って、前記取得リクエストで指定された検索条件に基づいて、データ管理部１５２のリソースを検索する。そして、取得処理部１６０は、検索結果データをレスポンス返信部１５４へ渡す。レスポンス返信部１５４は、連携インタフェース部１５０を介して、前記検索結果データを外部システム１２１へ返す。リソースは、格納・取得されるデータの単位を表しており、本実施形態においては、データ種とアクセス制御される単位であるテナントとの組み合わせを指す。更に、外部システム１２１は、取得リクエストにおいて、特定の条件を満たすデータを取得するためのクエリ文字列を検索条件として指定できる。
例えば、本実施形態における取得リクエストのＵＲＩの一例を以下に示す。前記ＵＲＩには、取得するデータの期間を日時で範囲指定が示されている。
「ｈｔｔｐ：／／ホスト名／２０００ＡＡＡ／ｊｏｂｌｏｇｓ／ｑｕｅｒｙ？＄ｆｉｌｔｅｒ＝最終更新日時＞＝当日００：００：００  ａｎｄ  最終更新日時＜翌日：００：００：００  ａｎｄ  ログ収集経路＝４  ａｎｄ  ジョブ完了日時＞＝当日−６０日＆＄ｏｒｄｅｒｂｙ＝最終更新日時」
前記ＵＲＩの一例の「２０００ＡＡＡ」は、テナントを示しており、「ｊｏｂｌｏｇｓ」は、データ種を示している。即ち、「２０００ＡＡＡ」及び「ｊｏｂｌｏｇｓ」の記載は、２０００ＡＡＡというテナントＩＤのジョブログをリソースとして指定する旨を示している。また、前記一例の「ｑｕｅｒｙ？」以降の文字列は、取得するデータの検索条件を表すクエリ文字列である。「ＵＲＩ」のクエリ文字列は、データ検索条件情報の一例である。テナントは、デバイスを管理するグループを示しており、例えば、販売会社がデバイスを管理するサービスを提供する顧客の単位に基づいて決定される。そして、データ共有システム１００のデータ共有サービスにおけるデータアクセスは、前記テナント単位で行われ、複数のテナントを跨ったデータアクセスは、行われない。
【００１４】
データ種としては、デバイスの状態情報であるデバイス構成情報１７１及びデバイスの履歴情報であるジョブログ１７２がある。本実施形態において、データ種の取りうる値は、前記２つであるとして説明する。しかし、データ種は、その他の状態情報、履歴情報等をとりうる値としてもよい。
予告情報入力部１５１は、外部システム１２１から定期リクエストの予告情報を受信し、データ管理部１５２の予告情報テーブル１７３に保存する。予告情報入力部１５１の入力インタフェースは、手動操作によるユーザインタフェースでもよいし、連携インタフェース部１５０と同様に自動登録が可能なネットワークインタフェースやＡＰＩでもよい。処理時間見積部１５７は、予告情報テーブル１７３、取得処理時間テーブル１７４、件数集計テーブル１７５、格納処理時間テーブル１７６の情報から、各予告情報に対応するリクエストの処理時間を見積る。そして、処理時間見積部１５７は、見積った前記処理時間に基づいて、予告情報テーブル１７３を更新する。スケジュール作成部１５８は、更に、予告情報テーブル１７３の情報からスケジュール情報を作成し、タイムスケジュールテーブル１７７に保存する。また、スケジュール作成部１５８は、リクエスト処理時には、処理実行時スケジュールテーブル１７８を更新する。
レコード数集計部１５６は、格納リクエストの処理及び定期的なバッチ処理により起動され、デバイス構成情報１７１及びジョブログ１７２のテナント別に日毎のレコード数を集計して、件数集計テーブル１７５へ記録する。
【００１５】
以下、各機能構成の処理の詳細について説明する。
予告情報入力部１５１は、外部システム１２１から定期リクエストの予告情報を受信する。
表Ａにデータ管理部１５２に保存されている予告情報テーブル１７３の例を示す。
【表１】
2016057916.tif 000003
表Ａにおいて、各行は、それぞれ予告情報入力部１５１により受信されたリクエストの予告情報と処理時間見積りとを表す。「予告情報番号」は、予告情報の識別子である番号である。「クライアントＩＤ」は、外部システムの識別子である。同じ「クライアントＩＤ」を持つ予告情報は、「クライアントＩＤ」に対応する同じ外部システムから入力されたことを示す。「メソッド」は、リクエストの種別である、格納（ＰＯＳＴ）あるいは取得（ＧＥＴ）を表す。「メソッド」は、処理種別情報の一例である。「ＵＲＩ」は、リクエストの内容を示すＵＲＩであり、前述のような文字列が保存されているものとする。
「格納予定件数」は、リクエストの種別が格納である場合の、格納予定件数である。「格納予定件数」は、格納データ数情報の一例である。「予告開始時刻」は、リクエストの予定時間である。「処理完了期限」は、外部システムにとって、リクエストのレスポンスが完了しなくてはならない期限の時刻である。「処理時間見積」は、処理時間見積部１５７によって更新される予測処理時間である。「グループ」は、スケジュール作成部１５８によって更新される、スケジュールを作成する単位であるグループを示す番号である。同じグループ番号を持つ予告情報は、一つのグループとしてスケジュールされる。
【００１６】
予告情報入力部１５１は、入力された予告情報を予告情報テーブル１７３の「クライアントＩＤ」から「処理完了期限」までの列に保存する。
なお、予告情報には、定期リクエストについての情報のみが含まれるものとする。したがって、データ共有システム１００は、一度予告情報を受信すると、同じ条件のリクエストを、定期的に受信するものとする。定期システム連携は、リクエスト条件が毎回変わることが無いため、予告情報によりスケジューリングすることが可能となるためである。本実施形態において、予告情報には、日毎を周期とする定期リクエストの情報が含まれるものとする。したがって、クエリ条件は、リクエスト「当日」を基準としたクエリを示すものとする。なお、周期については、日毎に限らず、週毎や月毎であってもよい。
データ共有システム１００は、対応するリクエストを受け付ける前に予告情報を外部システム１２１から受信する必要がある。
予告情報が入力又は更新された場合、処理時間見積部１５７は、予告情報に対応するリクエストの処理時間を見積る。処理時間見積部１５７は、処理時間の見積を取得処理と格納処理とで切り替える。
処理時間見積部１５７は、表Ａの「メソッド」の値がＧＥＴの場合、取得処理としての見積を行う。処理時間見積部１５７は、データ種及びクエリ文字列のパターンから単位レコード件数の処理時間と、ＵＲＩで指定されたテナントとデータ種とから求まる対象データのレコード件数と、に基づいて取得処理時間を見積る。
【００１７】
表Ｂにデータ管理部１５２に保存されている取得処理時間テーブル１７４の例を示す。
【表２】
2016057916.tif 000004
表Ｂの各行はそれぞれ、「クエリパターン」と「データ種」と「単位件数」と「単位時間」とを含む。クエリ文字列のパターンとデータ種との組み合わせに対応する単位件数と単位時間とから単位レコード件数当たりの処理時間が求まる。データ管理部１５２は、表Ｂに、定期システム連携をスケジュール対象とするためクエリパターンを予め持っておくことができる。また、データ管理部１５２は、実際のリクエスト処理時間を計測監視し、表Ｂに反映してもよい。データ共有システム１００は、表Ｂを参照することで、リクエストの重複したアクセスを避けるようスケジュールするため、他のリクエストの影響を受けていない性能値を見積りに利用することができる。
「クエリパターン」は、ＵＲＩの検索条件を表すクエリ文字列に対応する文字列である。データ共有システム１００は、表Ｂの「クエリパターン」と表Ａの「ＵＲＩ」における検索条件部分とを文字列比較することでパターンの一致を確認する。「データ種」は、ＵＲＩのデータ種に対応する。「単位件数」と「単位時間」とは、「クエリパターン」と「データ種」との組み合わせにおける「単位件数」の処理時間が「単位時間」であることを示している。「単位時間」の値の単位は、本実施形態では秒として説明するが、時間、分、ミリ秒等でもよい。
【００１８】
表Ｃにデータ管理部１５２に保存されている件数集計テーブル１７５の例を示す。
【表３】
2016057916.tif 000005
表Ｃの各行は、それぞれ、「テナントＩＤ」と「データ種」と「件数」とを含む。表Ｃの各行は、テナントとデータ種との組合せに対応するレコード件数を日毎に集計した結果を表す。「テナントＩＤ」は、テナントの識別子を示し、ＵＲＩにおけるアクセス対象テナントのテナントＩＤに対応する。同様に「データ種」は、ＵＲＩにおけるデータ種と対応する。「件数」は、「テナントＩＤ」と「データ種」とに対応するレコード件数の集計結果の件数を表す。集計単位は、定期連携の周期に合わせたものであり、本実施形態においては、定期連携も日毎を単位としているため、件数の集計も日毎としている。
データ共有システム１００は、表ＡのＵＲＩよりテナントＩＤとデータ種とを取得し、前記テナントＩＤと前記データ種との組合せに基づいて、表Ｃから見積り時の件数を取得する。より具体的には、データ共有システム１００は、表Ｃの行からテナントＩＤの列が表Ａから取得したテナントＩＤであるものを検索し、検索された行からデータ種の列が表Ａから取得したデータ種であるものを検索する。データ共有システム１００は、検索された行の件数を取得することで見積り時の件数を取得する。また、データ共有システム１００は、表ＡのＵＲＩより検索条件のクエリパターンとデータ種とを取得し、表Ｂから対応する単位件数と単位時間との組合せを取得する。より具体的には、データ共有システム１００は、表Ｂの行からクエリパターンの列が表Ａから取得したクエリパターンであるものを検索し、検索された行からデータ種の列が表Ａから取得したデータ種であるものを検索する。データ共有システム１００は、検索された行の単位件数と単位時間とを取得する。
【００１９】
例えば、表Ａの３行目に対応する集計件数が表Ｃの３行目に対応するとおくと、データ共有システム１００は、１日分２０００件と言う値を対象件数として得る。同様に、表Ａの３行目に対応する処理時間が表Ｂの１行目に対応するとおくと、データ共有システム１００は、単位件数１００００件当たり単位時間１２０（秒）という値を得る。データ共有システム１００は、表Ａ、Ｂ、Ｃから得た値に基づいて、１日分２０００件の処理時間として、
２４（秒）＝  １２０  ＊  ２０００  ／  １００００
という見積時間を得る。
処理時間見積部１５７は、表Ａの「メソッド」の値がＰＯＳＴの場合、格納処理としての見積を行う。処理時間見積部１５７は、データ種に基づく単位レコード件数の処理時間と、「格納予定件数」で指定された対象データのレコード件数と、から格納処理時間を見積る。
【００２０】
表Ｄにデータ管理部１５２に保存されている格納処理時間テーブル１７６の例を示す。
【表４】
2016057916.tif 000006
表Ｄの各行は、それぞれ、「データ種」と「単位件数」と「単位時間」とを含む。表Ｄの各行は、データ種に対応する単位レコード件数当りの格納処理時間を表す。
「データ種」は、ＵＲＩのデータ種に対応する。「単位件数」と「単位時間」とは、「データ種」における「単位件数」の処理時間が「単位時間」であることを示している。
例えば、表Ａの１行目では、格納予定件数は、２０００件である。更に、表Ａの１行目のＵＲＩにおけるデータ種に表Ｄの１行目が対応するとして、処理時間見積部１５７は、１００００件当たり１５０（秒）という値を得る。処理時間見積部１５７は、１日分２０００件の処理時間として、
３０（秒）＝  １５０  ＊  ２０００  ／  １００００
というように見積る。
以上のように、処理時間見積部１５７は、取得処理と格納処理とのそれぞれの場合で処理時間見積を行った結果の値で、表Ａの「処理時間見積」の列を更新する。
【００２１】
表Ｘにデータ管理部１５２に保存されているデバイス構成情報１７１の例を示す。
【表５】
2016057916.tif 000007
表Ｘの各行は、それぞれ、「更新日時」と「デバイスＩＤ」と「テナントＩＤ」と「モデル」と「ネットワークアドレス」と［オプション情報］とを含む。表Ｘの各行は、データ共有システムで管理されるデバイスの登録情報を表す。前記登録情報は、デバイス構成情報の取得リクエスト、格納リクエストの対象となる。
「更新日時」は、デバイスの登録情報の更新日時を示す。「デバイスＩＤ」は、登録情報におけるデバイスの識別子である。「テナントＩＤ」は、「デバイスＩＤ」に対応するデバイスを管理しているテナントの識別子であり、アクセスリクエストのＵＲＩで指定されたテナントＩＤに一致する情報だけがアクセスの対象となる。「モデル」は、「デバイスＩＤ」に対応するデバイスの機種を表すモデル情報である。「ネットワークアドレス」は、「デバイスＩＤ」に対応するデバイスがネットワーク接続に使用しているネットワークアドレスである。「オプション情報」は、「デバイスＩＤ」に対応するデバイスに接続されているオプション機器の情報である。
【００２２】
また、表Ｙにデータ管理部１５２に保存されている履歴情報の例であるジョブログ１７２の例を示す。
【表６】
2016057916.tif 000008
表Ｙの各行は、それぞれ、「更新日時」と「デバイスＩＤ」と「テナントＩＤ」と「ジョブ名」と「ジョブタイプ」と「ジョブ開始日時」と「ジョブ完了日時」とを含む。表Ｙの各行は、データ共有システムで管理しているデバイスの一つのジョブの情報を表す。前記情報は、ジョブログの取得リクエスト、格納リクエストの対象となる。
「更新日時」は、ジョブ情報の登録情報の更新日時を示す。「デバイスＩＤ」は、ジョブを処理したデバイスの識別子である。「テナントＩＤ」は、前記デバイスを管理しているテナントの識別子であり、アクセスリクエストのＵＲＩで指定されたテナントＩＤに一致する情報だけがアクセスの対象となる。「ジョブ名」は、例えば印刷であれば文書名などを表すジョブの名称である。「ジョブタイプ」は、印刷（「ＰＲＩＮＴ」）やスキャン（「ＳＣＡＮ」）等のジョブの種類を表す情報である。「ジョブ開始日時」はジョブが開始した日時である。「ジョブ完了日時」はジョブが完了した日時である。
【００２３】
スケジュール作成部１５８は、表Ａの情報に基づいて予告情報に対応するリクエストを受け付けるスケジュールを決定する。以下、図を用いて、複数の予告情報からスケジュールを作成する処理を説明する。
図３は、予告情報と処理時間見積との凡例を示す図である。図４以降の予告情報と処理時間見積との図示方法は、図３の凡例に則る。
矩形２００は、予告情報の時間制約を表しており、時間制約の左端２０２は予告開始時刻を、右端２０３は処理完了期限を表している。左端２０２の予告開始時刻、右端２０３の処理完了期限は、時間制約情報の一例である。前記予告開始時刻は、開始予定時刻の一例であり、前記処理完了期限は、処理完了時刻の一例である。以下で、前記予告開始時刻から前記処理完了期限までの期間を前記予告情報に係るリクエストの受付期間とする。また、矩形２０１は、スケジュール対象の処理を表しており、幅２０４は、処理時間見積を表している。更に、矩形２００の時間制約は、図４に示すスケジュール作成のためのソート段階では、軸２０６に示すように図示する。軸２０６では、矩形２００の時間制約等の時間制約は、矩形２０５のように塗りつぶされた矩形として図示する。図３の判例に示す図示方法に従って、以降の説明を続ける。
スケジュール作成部１５８は、リクエストスケジュールのソート及びグループ化を行う。
【００２４】
図４は、予告情報のソートの一例を示す図である。図４は、スケジュール作成のために、予告情報の制約条件に従ってソートする例を示す。
図４は、（ａ）、（ｂ）、（ｃ）の順でソート及びグループ化される様子を表している。
図４（ａ）は、ソート前のリクエストを表しており、予告情報テーブル１７３の初期状態では、図４（ａ）に図示されている順序に保存されているものとする。図４（ａ）は、リクエスト２１０〜２２１の１２個のリクエストがあることを表している。図４（ａ）の状態では、リクエスト２１０〜２２１は、制約条件ではソートされていない。次に、スケジュール作成部１５８は、リクエスト２１０〜２２１を制約条件の予告開始時刻順にソートする。スケジュール作成部１５８は、予告開始時刻が同じ場合には、制約条件の処理完了期限順とする。
【００２５】
図４（ｂ）は、図４（ａ）の各リクエストと同じ番号を付してソート結果を表している。
図４（ｂ）において、ソートされたリクエストにおいて、前のリクエストの処理完了期限よりも開始時間が後である場合、前記リクエストと前記前のリクエストとは、グループが分かれる。例えば、図４（ｂ）において、リクエスト２１８とリクエスト２１５とがグループの境界となり、図４に示すリクエストは、二つのスケジュールグループに分かれる。スケジュール作成部１５８は、前半の８つのリクエスト（リクエスト２２１、２１０、２１１、２１９、２１３、２１４、２１６、２１８）のスケジュールグループの値を１とする。また、スケジュール作成部１５８は、後半の４つのリクエスト（リクエスト２１５、２１７、２２０、２１２）のスケジュールグループの値を２とし、表Ａの「グループ」列を更新する。
更に、図４（ｂ）において、スケジュール作成部１５８は、リクエストの処理完了期限が前のリクエストの処理完了期限よりも早い場合には、処理完了期限が早い方のリクエストの順序を上へ移動させる。
以上のようにソートが完了して、スケジュールグループの値が１のリクエストを抜き出したものが図４（ｃ）である。スケジュール作成部１５８は、図４（ｃ）のようなグループ単位でスケジュール情報を作成し、タイムスケジュールテーブル１７７に記憶する。
【００２６】
表Ｅにデータ管理部１５２に保存されているタイムスケジュールテーブル１７７の例を示す。
【表７】
2016057916.tif 000009
表Ｅの各行は、それぞれ、「開始時刻」と「終了時刻」と「グループ」と「予告情報番号」と「エラー」とを含む。表Ｅの各行は、予告情報に対応するスケジュールを表す。
「開始時刻」と「終了時刻」とは、スケジュールされたリクエストの開始時刻と終了時刻である。スケジュール作成部１５８は、スケジュール作成によって決定した開始時刻と終了時刻とを「開始時刻」と「終了時刻」との列に保存する。「グループ」は、スケジュールのグループである。「予告情報番号」は、スケジュール対象の予告情報への参照を表す。スケジュール作成部１５８は、予告情報テーブル１７３の対応する予告情報番号を「予告情報番号」へコピーする。「エラー」は、制約条件を満たしつつ、他のリクエストと時間分散したスケジュール作成に失敗したリクエストを表すフラグ情報である。「エラー」の値が０ならばスケジュール作成成功、１ならばスケジュール作成失敗を表す。また、「エラー」の値は、０と１とに限られず、２値化できる値ならば何でもよい。
【００２７】
図５は、スケジュール作成の一例を示す図である。図５は、スケジュール作成部１５８によるソートとグループ作成後のスケジュール作成との例を示したものである。
８つの予告情報（予告情報２５０〜２５７）は、全て、同じ制約条件（時刻２４０、２４１）を持っている。リクエストの種類は、デバイス構成情報１７１の取得リクエストであるものとする。リクエストＡ１〜Ａ８は、それぞれ予告情報２５０〜２５７に対応するリクエストである。リクエストの種類がデバイス構成情報１７１の取得リクエストのみであるため、スケジュール作成部１５８は、軸３００に示すように、次の処理を行う。即ち、スケジュール作成部１５８は、制約条件の中で開始時刻から順に詰めるように、リクエストＡ１〜Ａ８の受け付けることができる期間の開始時刻を時刻３０１〜３０８に決定することでスケジュール情報を作成する。
【００２８】
図６は、スケジュール作成の一例を示す図である。図６は、図５とは別のスケジュール作成部１５８によるソートとグループ作成後のスケジュール作成例を示したものである。
図６では、図５における８つのリクエストであるデバイス構成情報取得リクエスト群２５８に加えて、ジョブログの取得リクエスト２５９とジョブログの格納リクエスト２６０とがある。デバイス構成情報取得リクエスト群２５８は、図示の便宜的にまとめられているが、図５における予告情報２５０〜２５７のように８つの予告情報を含むものとする。
時間帯２６１は、図６に示すスケジュールグループの時間帯を示しており、最も早い開始時刻（共通）である時刻２４０から最も遅い処理完了期限である時刻２４５までとなっている。
スケジュール作成部１５８は、図６に示すようにリクエスト種別とデータ種とに応じて次のようにスケジュールを作成する。
【００２９】
スケジュール作成部１５８は、まず、同一グループ内でソートされた順にリクエストを受け付ける期間を決定するが、取得リクエストの優先順位よりも格納リクエストの優先順位が高くなるように優先順位を決定して、前記優先順位が一番高いものから順に決定する。更に、スケジュール作成部１５８は、同じリクエスト種別でも状態情報を処理するリクエストの優先順位よりも履歴情報を処理するリクエストの優先順位が高くなるよう優先順位を決定する。そして、スケジュール作成部１５８は、前記優先順位が一番高いものから順に、リクエストを受け付ける期間を決定する。つまり、スケジュール作成部１５８は、履歴情報のＰＯＳＴ、状態情報のＰＯＳＴ、履歴情報のＧＥＴ、状態情報のＧＥＴ、の順でリクエストを受け付ける期間を決定する。また、スケジュール作成部１５８は、格納リクエストと履歴情報に対するリクエストとの受付期間を予告情報の時間制約の中で決定する。更に、スケジュール作成部１５８は、受付期間を決定したリクエストが格納リクエストの場合に前記リクエストの見積時間と同じ幅のバッファ時間を前記リクエストの受付期間の末尾に設ける。前記バッファ時間は、前記リクエストの見積時間と同じ幅に限定されず、前記見積時間よりも長くても短くてもよい。また、スケジュール作成部１５８は、受付期間を決定したリクエストのデータ種が履歴情報を表す場合にも、前記リクエストの見積時間と同じ幅のバッファ時間を前記リクエストの受付期間の末尾に設ける。前記バッファ時間は、前記リクエストの見積時間と同じ幅に限定されず、前記見積時間よりも長くても短くてもよい。スケジュール作成部１５８は、予告情報の時間制約の中で空いている隙間に順に状態情報の取得リクエストを受け付ける期間を決定する。
図６において、スケジュール作成部１５８は、まず、履歴情報の格納処理であるジョブログの格納リクエスト２６０から受付期間の決定を行う。格納リクエスト２６０の受付期間の決定処理の結果は、状況３１０である。状況３１０において、ジョブログの格納リクエスト２６０は、時刻３１３のタイミングに配置される。時刻３１３は、時刻２４４と時刻２４５とで示される時間制約を満たし、かつ、空いている時間帯の最も早いタイミングである。
【００３０】
次に、スケジュール作成部１５８は、履歴情報の取得処理であるジョブログの取得リクエスト２５９の受付期間を決定する。取得リクエスト２５９の受付期間の決定の結果は、状況３１１である。状況３１１において、ジョブログの取得リクエスト２５９は、時刻３１５のタイミングに配置される。時刻３１５のタイミングは、時刻２４２と時刻２４３とで示される時間制約を満たし、かつ、空いている時間帯の最も早いタイミング、ただし、直前のリクエストの受付期間及び前記受付期間と同じ幅３１４のバッファ期間をとったタイミングである。
そして、スケジュール作成部１５８は、状態情報の取得処理であるデバイス構成情報取得リクエスト群２５８の中のリクエストの受付期間を決定する。デバイス構成情報取得リクエスト群２５８の中のリクエストの受付期間の決定の結果は、状況３１２である。状況３１２において、スケジュール作成部１５８は、予告情報２５０〜２５７に対応するリクエストの受付期間を、それぞれ時刻３１６〜３２３のタイミングに配置する。スケジュール作成部１５８は、時刻３１６〜３２１を、格納リクエスト２６０に決定されたバッファ期間に収まる余裕がある場合、前記期間に配置する。そして、スケジュール作成部１５８は、時刻２４０と時刻２４１とで示される時間制約を満たし、かつ、空いている時間帯の最も早いタイミングに時刻３２２、３２３を配置する。
【００３１】
スケジュール作成部１５８は、図５又は図６のようにリクエストの受付期間を決定し、表Ｅの開始時刻と終了時刻とを更新する。以上でスケジュール作成が完了する。
次に、スケジュール作成部１５８によって作成されたスケジュールに従った定期リクエストの受け付け処理について説明する。
スケジュールグループの時間帯に入ると、リクエストスケジュール判断部１５５は、タイムスケジュールテーブル１７７から、該当するグループの中のリクエストのスケジュールを、処理実行時スケジュールテーブル１７８へコピーする。リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８の内容に従ってリクエストの受付処理を行い、リクエスト処理時間延長の場合には、処理実行時のグループ分だけ再スケジュールする。
【００３２】
表Ｆにデータ管理部１５２に保存されている処理実行時スケジュールテーブル１７８の例を示す。
【表８】
2016057916.tif 000010
表Ｆの各行は、それぞれ、「開始時刻」と「終了時刻」と「クライアントＩＤ」と「メソッド」と「ＵＲＩ」と「処理時間」と「予告開始時刻」と「処理完了期限」と「グループ」と「エラー」とを含む。表Ｆの各行は、リクエストの処理実行時のスケジュールを表す。
表Ｆの各項目は、タイムスケジュールテーブル１７７及びタイムスケジュールテーブル１７７から予告情報番号に基づいて参照された予告情報テーブル１７３の情報から、対象グループのリクエストの情報がコピーされて設定される。
【００３３】
図７は、リクエストとレスポンスとの凡例を示す図である。図８以降での定期リクエストの受付判断の例の図示は、図７の記法に則る。
図７において、矩形４０２は、データ共有システム１００がリクエストを受信して格納又は取得の処理をしている期間を表している。左端４００は、データ共有システム１００がリクエストを受信したタイミングを表している。右端４０１は、データ共有システム１００がリクエスト元にレスポンスを返し終えたタイミングを表している。左端４００から右端４０１までの期間は、データ共有システム１００がリクエストに対する実際の処理を行っている期間を表しており、場合によってはリクエストの内容からエラーになる場合もある。例えば、データ共有システム１００は、格納しようとしたデータが不適当な場合、格納データを受信したところでデータエラーのレスポンスを返すことができる。一方、リトライ推奨エラー４０３、リトライ禁止エラー４０４、スケジュールエラー４０５は、データ共有システム１００が受信したリクエストを処理せずに即エラーのレスポンスをリクエスト元に返していることを表している。リトライ推奨エラー４０３は、リクエストを送信した外部システムに対して、タイミングをずらし、改めてリクエストを送りなおすよう推奨するエラーレスポンスを返すことを表している。リトライ禁止エラー４０４は、リクエスト元に対して、リクエストが許可されていない期間であることを示すエラーレスポンスを返すことを表している。スケジュールエラー４０５は、リクエストに対応する予告情報の制約条件を満たしてスケジュール情報を作成できなかったことを示すエラーレスポンスをリクエスト元に返すことを表している。リクエストタイミング返却４０６は、更に、リクエストを再送すれば処理可能であるタイミング４０７の情報をレスポンスでリクエスト元に返すことを表している。
【００３４】
図８は、リクエスト受信時のタイミングチャートの一例を示す図である。図８は、リクエストスケジュール判断部１５５が、リクエストを受信した際に、図６に示すスケジュール作成の結果に対する挙動を示す。
図８において、時間帯４１２は、リクエスト受信判断をするスケジュールグループの時間帯を示す。図８において、時間帯４１２は、時間帯２６１と同じ時間帯となる。データ共有システム１００は、時間帯４１２の前後（時間帯４１１、４１３）では、リクエスト受信判断を行わずに通常のリクエスト受付を行う。スケジュール４１０はスケジュールグループにおけるスケジュール情報を表しており、図６における状況３１２に対応する。状況４１４は、デバイス構成情報取得リクエスト群２５８の予告情報に対応する実際のデバイス構成情報の取得リクエストが行われている状況を示す。状況４１５は、ジョブログの取得リクエスト２５９の予告情報に対応する実際のジョブログの取得リクエストが行われている状況を示す。状況４１６は、ジョブログの格納リクエスト２６０の予告に対応する実際のジョブログの格納リクエストが行われている状況を示す。状況４１７は、スケジュールグループに属さない、又は、定期リクエスト予告を入力していない臨時アクセスのリクエストが行われている状況を示す。
【００３５】
データ共有システム１００は、同一のスケジュールグループのリクエストであっても、スケジュールされた受付期間以外でリクエストを受信すると、リクエスト元にリトライ推奨エラーを即返却する（リトライ推奨エラー４５０、４５７、４６０）。データ共有システム１００は、リクエストの受付期間に前記リクエストを受信すると、前記リクエストを処理し、レスポンスをリクエスト元に返す（リクエスト処理４５１〜４５６、４５８、４５９、リクエスト４６１、４６３、レスポンス４６２、４６４）。
また、データ共有システム１００は、状況４１７のようにスケジュールグループの時間帯における、前記スケジュールグループに属さないリクエストを受信した場合、無条件でリトライ禁止エラー４６７をリクエスト元に返却する。データ共有システム１００は、スケジュールグループの時間帯以外（時間帯４１１、４１３）にリクエストを受信した場合、スケジュールの判断無く前記リクエストを処理する（リクエスト４６５、４６８、レスポンス４６６、４６９）。
【００３６】
図８は、実際のリクエストの処理が見積られた処理時間に基づいて決定された受付期間内に完了する場合の例を示している。次に、実際のリクエストの処理が前記受付期間を超過する場合の例を示す。
実際の処理が前記処理に対応する受付期間を越えてしまう場合には、二種類ある。一つ目は、格納リクエストにおいて、格納予定件数よりも多くのデータを格納するリクエストを受け付けた場合である。二つ目は、格納リクエストによってテーブルに格納されたレコード件数が増加した結果、取得リクエストの取得対象件数が増加してしまった場合である。一つ目の場合、データ共有システムは、前記格納リクエストに対応する受付期間にバッファが設けられているため、リクエスト処理時に処理時間が見積時間よりも延長した場合には、処理実行時スケジュールテーブル１７８を再スケジュールすることで対応する。二つ目の場合、データ共有システム１００は、レコード数集計部１５６において集計された結果で処理時間見積りを更新し、更新された見積りに基づいてタイムスケジュールテーブル１７７を再スケジュールすることで対応する。
【００３７】
図９は、リクエスト受信時のタイミングチャートの一例を示す図である。図９は、リクエストスケジュール判断部１５５が実際にリクエストを処理した結果、図６に示すスケジュール作成の結果に対して前記リクエストの処理時間が超過してしまった場合の挙動を示す。前記リクエストの処理時間が超過してしまったことは、実行状況の一例である。
図９において、状況４１８は、ジョブログの格納リクエスト２６０の予告情報に対応する実際のジョブログの格納リクエストが行われている状況を示す。リクエスト４８０でリクエストされた格納データ数が予告情報に基づいた格納データ数よりも多かったため、レスポンス４８１の時刻は、前記リクエストに対応する受付期間の終了時刻もりよりも後になっている。スケジュール４１９は、状況４１８によってスケジュール４１０のスケジュール情報から修正されたスケジュール情報を示す。状況４２０は、デバイス構成情報取得リクエスト群２５８の予告情報に対応する実際のデバイス構成情報の取得リクエストが行われている状況を示す。状況４２１は、ジョブログの取得リクエスト２５９の予告情報に対応する実際のジョブログの取得リクエストが行われている状況を示す。
【００３８】
スケジュール４１０に対応するスケジュール情報を修正し、スケジュール４１９に対応するスケジュール情報を作成する処理は、次のように行われる。即ち、データ共有システム１００は、ジョブログの格納処理終了時刻を実処理終了時刻として、前記スケジュール情報を再スケジュールする。結果、データ共有システム１００は、デバイス構成情報の取得リクエストを、時刻３３０、３３２〜３３８に受け付けるように受付期間を決定する。データ共有システム１００が再スケジュールする範囲は、処理中のスケジュールグループ内の未処理のリクエストについてだけとする。再スケジュールを実施するタイミングは、レスポンス４８１でジョブログの格納リクエスト２６０の処理が完了した後である。したがって、レスポンス４８１のタイミングまで、データ共有システム１００は、状況４２０と状況４２１とにおけるリトライ推奨エラー返却の判断を、スケジュール４１０に基づいて行う。状況４２１におけるリトライ推奨エラー４９３の返却判断は、元々ジョブログ取得リクエストのタイミングではないため、変わることはない。一方、状況４２０における期間４８３は、スケジュール４１０に従えば、デバイス構成情報の取得リクエストを受け付ける期間となる。図９に示す例において、データ共有システム１００は、前のリクエスト処理が、延長の可能性のある、格納リクエスト又は履歴情報を対象としたリクエストである場合、前のリクエストが処理中の場合にもリトライ推奨エラーを返却する。より具体的には、データ共有システム１００は、期間４８３において、リクエストがスケジュールされた受付期間外だからではなく、前のリクエストが格納リクエストで、かつ、前のリクエストが処理中であるため、リクエスト推奨エラーを返却する。他の挙動については、図８に示した例と同様である。
データ共有システム１００は、制約条件の中で余裕が無くなってくると、再スケジュールによって制約条件を満たせなくなる場合が出てくる。その場合には、データ共有システム１００は、優先順位の一番低いリクエストからエラーとする。
【００３９】
図１０は、スケジュールエラーのタイミングチャートの一例を示す図である。図１０は、スケジュール情報の修正処理において、スケジュールエラーが発生した場合の挙動を示す。図１０は、図９と同じ状況でデータ共有システム１００が再スケジュール作成を行い、デバイス構成情報の取得リクエストの一部がスケジュールエラーを起こした状況を図示している。図９と同じ部分には、同じ番号を付して、図９との差分を説明する。期間４２７は、デバイス構成情報の取得リクエストの制約条件を示す期間である。スケジュール４２５は、再スケジュール結果を表している。状況４２６は、デバイス構成情報の取得リクエストが行われている状況を示す。スケジュール４２５は、再スケジュールの結果、デバイス構成情報の取得リクエスト３４０、３４１、３４２が期間４２７の制約条件の範囲から外れてしまったことを表している。そのため、データ共有システム１００は、状況４２６に示すように、リクエスト元に対してスケジュールエラー４９６を返却する。
【００４０】
図１１は、予告情報入力処理及びスケジュール作成処理の一例を示すフローチャートである。図１１は、予告情報入力部１５１において実行される、予告情報入力時の処理の流れを示す。
Ｓ１０００において、予告情報入力部１５１は、外部システムからの予告情報の入力を検知すると、図１１に示す処理を開始する。
Ｓ１００１において、予告情報入力部１５１は、Ｓ１０００で検知した入力に含まれる予告情報をチェックする。
Ｓ１００２において、予告情報入力部１５１は、定期データ連携として、クエリ文字列のパターンが対応可能か否かを判定する。予告情報入力部１５１は、クエリ文字列のパターンが対応できないと判定した場合、ステップＳ１００６の処理へ進み、クエリ文字列のパターンが対応できると判定した場合、ステップＳ１００３の処理へ進む。
【００４１】
Ｓ１００３において、予告情報入力部１５１は、Ｓ１００１でチェックした予告情報を予告情報テーブル１７３に登録、又は、前記予告情報に基づき予告情報テーブル１７３を更新する。
Ｓ１００４において、予告情報入力部１５１は、処理時間見積部１５７に対して、Ｓ１００３で登録、更新された予告情報テーブル１７３に基づくリクエストの処理時間の見積り処理の実行を指示する。
Ｓ１００５において、予告情報入力部１５１は、スケジュール作成部１５８に対して、Ｓ１００４で処理時間見積部１５７により見積られた処理時間に基づくスケジュール情報の作成を指示する。
Ｓ１００６において、予告情報入力部１５１は、入力エラーとして予告情報を受け付けずに図１１に示す処理を終了する。
【００４２】
図１２は、件数集計処理及びスケジュール作成処理の一例を示すフローチャートである。図１２は、レコード数集計部１５６において実行される、レコード件数集計処理の流れを示すフローチャートである。
レコード件数集計処理は、本実施形態では、定期的なバッチ処理により起動されるものとするが、更新リクエストの処理に連動することとしてもよい。
Ｓ１０２０において、レコード数集計部１５６は、図１２に示す集計の処理を開始する。
Ｓ１０２１において、レコード数集計部１５６は、ジョブログ１７２の中の当日のテナント毎のレコード件数を集計し、集計した値で件数集計テーブル１７５の該当レコードを更新する。
Ｓ１０２２において、レコード数集計部１５６は、デバイス構成情報１７１中の当日のテナント毎のレコード件数を集計し、集計した値で件数集計テーブル１７５の該当レコードを更新する。
Ｓ１０２３において、レコード数集計部１５６は、処理時間見積部１５７へ処理時間見積りの更新を指示する。
Ｓ１０２４において、レコード数集計部１５６は、スケジュール作成部１５８に対して、Ｓ１０２３での指示に基づく処理時間見積部１５７による見積りの結果に基づくスケジュールの更新を指示する。
Ｓ１０２５において、レコード数集計部１５６は、図１２に示す処理を終了する。
【００４３】
図１３は、スケジュール作成処理の一例を示すフローチャートである。図１３は、スケジュール作成部１５８において実行されるスケジュール作成の処理の流れを示す。図１３の処理は、図１１のＳ１００５又はステップＳ１０２４での指示に基づいて起動される。
Ｓ１１００において、スケジュール作成部１５８は、スケジュール作成を開始する。
Ｓ１１０１において、スケジュール作成部１５８は、図４（ａ）、（ｂ）で示したように予告情報テーブル１７３のソートを行う。
Ｓ１１０２において、スケジュール作成部１５８は、図４（ｂ）で示したように、終了時間が早いものを前へ持ってくる。
Ｓ１１０３において、スケジュール作成部１５８は、図４（ｂ）から（ｃ）で示したようにスケジュールグループの設定を行う。
Ｓ１１０４において、スケジュール作成部１５８は、グループ単位のスケジュール作成を行う。
Ｓ１１０５において、スケジュール作成部１５８は、スケジュール作成が終了していないスケジュールグループが存在するか否かを判定する。スケジュール作成部１５８は、スケジュール作成が終了していないスケジュールグループが存在すると判定した場合、Ｓ１１０４の処理へ進み、スケジュール作成が終了していないスケジュールグループが存在しないと判定した場合、ステップＳ１１０６の処理へ進む。
Ｓ１１０６において、スケジュール作成部１５８は、図１３に示す処理を終了する。
【００４４】
図１４は、グループ単位のスケジュール作成処理の一例を示すフローチャートである。図１４は、図１３におけるステップＳ１１０４から呼び出されるグループ単位のスケジュール作成処理の詳細を示す。
Ｓ１１１０において、スケジュール作成部１５８は、図１４に示すグループ単位のスケジュール作成の処理を開始する。
Ｓ１１１１において、スケジュール作成部１５８は、処理対象のグループ全体の制約条件時間より前記グループ内の処理時間見積りの合計が大きいか否かを判定する。スケジュール作成部１５８は、前記処理時間見積りの合計が前記制約条件時間よりも大きいと判定した場合、ステップＳ１１１２の処理へ進む。スケジュール作成部１５８は、前記処理時間見積りの合計が前記制約条件時間よりも大きくないと判定した場合、Ｓ１１１３の処理へ進む。
【００４５】
Ｓ１１１２において、スケジュール作成部１５８は、タイムスケジュールテーブル１７７における、前記グループ内全てのリクエストのエラーフラグを１にセットする。スケジュール作成部１５８は、予告情報入力部１５１がユーザインタフェースを持つ表示画面を持つ場合、又は、データ共有システム１００の運用監視部がある場合、以下の処理を行うこととしてもよい。即ち、スケジュール作成部１５８は、スケジュールエラーを前記表示画面又は前記運用監視部に対して、報知することで出力してもよい。前記運用監視部は、出力部の一例である。前記表示画面は、表示部の一例である。スケジュールエラーは、警告情報の一例である。
Ｓ１１１３において、スケジュール作成部１５８は、予告情報テーブル１７３における前記グループの履歴情報の格納リクエストを上から順に各リクエスト予告情報の制約条件を満たすように受付期間を決定するべく開始時刻と終了時刻とを決める。スケジュール作成部１５８は、決定した開始時刻と終了時刻とをタイムスケジュールテーブル１７７に格納する。スケジュール作成部１５８は、格納リクエストの受付期間の末尾に前記受付期間と同じ時間の間隔を空ける。
Ｓ１１１４において、スケジュール作成部１５８は、状態情報の格納リクエストの受付期間を順に決定する。
Ｓ１１１５において、スケジュール作成部１５８は、更に、履歴情報の取得リクエストの受付期間を順に決定する。スケジュール作成部１５８は、履歴情報の取得リクエストの受付期間を決定する際、前のリクエストが格納リクエストの場合、前記前のリクエストの受付期間との間に前記格納リクエストのバッファ期間の幅の間隔を空けて、受付期間を決定する。スケジュール作成部１５８は、前記前のリクエストが取得リクエストの場合、前記前のリクエストの受付期間と間隔を空けずに受付期間を決定する。
【００４６】
Ｓ１１１６において、スケジュール作成部１５８は、状態情報の取得リクエストの受付期間を決定する。状態情報の取得リクエストは、他のリクエストに決定されたバッファ期間も利用して受付期間を決定する。
Ｓ１１１７において、スケジュール作成部１５８は、Ｓ１１１３〜Ｓ１１１６で制約条件を満たして受付期間を決定できなかったリクエストが存在するか否かを判定する。スケジュール作成部１５８は、前記リクエストが存在すると判定した場合、Ｓ１１１８の処理へ進む。スケジュール作成部１５８は、前記リクエストが存在しないと判定した場合、Ｓ１１１９の処理へ進む。
Ｓ１１１８において、スケジュール作成部１５８は、タイムスケジュールテーブル１７７における、前記リクエストのエラーフラグを１にセットする。スケジュール作成部１５８は、Ｓ１１１２と同様に、Ｓ１１１８でスケジュールエラーを報知することとしてもよい。
Ｓ１１１９において、スケジュール作成部１５８は、図１４に示す処理を終了する。
【００４７】
図１５は、リクエスト受信処理の一例を示すフローチャートである。図１５は、リクエストスケジュール判断部１５５等において実行されるリクエスト受信処理の流れを示す。データ共有システム１００がリクエストを受信すると、ステップＳ１１５０からの処理が開始する。
Ｓ１１５１において、リクエストスケジュール判断部１５５は、リクエスト受信時の時刻がどのスケジュールグループの時間帯に属しているかを、タイムスケジュールテーブル１７７を参照して確認する。
Ｓ１１５２において、リクエストスケジュール判断部１５５は、前記リクエスト受信時の時刻がどのスケジュールグループにも含まれない、非スケジュールの時間帯であるか否かを判定する。リクエストスケジュール判断部１５５は、非スケジュール時間帯であると判定した場合、Ｓ１１５７の処理へ進み、非スケジュール時間帯でないと判定した場合、Ｓ１１５３の処理へ進む。
Ｓ１１５３において、リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８の内容を確認する。
Ｓ１１５４において、リクエストスケジュール判断部１５５は、前記リクエスト受信時の時刻が含まれるスケジュールグループが処理実行時スケジュールテーブル１７８の示すスケジュールグループと一致するか否かを判定する。リクエストスケジュール判断部１５５は、前記リクエスト受信時の時刻が含まれるスケジュールグループが処理実行時スケジュールテーブル１７８の示すスケジュールグループと一致すると判定した場合、Ｓ１１５６の処理へ進む。リクエストスケジュール判断部１５５は、前記リクエスト受信時の時刻が含まれるスケジュールグループが処理実行時スケジュールテーブル１７８の示すスケジュールグループと一致しないと判定した場合、Ｓ１１５５の処理へ進む。
【００４８】
Ｓ１１５５において、リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８を更新する。より具体的には、リクエストスケジュール判断部１５５は、タイムスケジュールテーブル１７７と予告情報テーブル１７３とから処理実行時スケジュールテーブル１７８へ、前記リクエスト受信時の時刻を含むスケジュールグループのデータをコピーする。リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８において、スケジュールの時間が早い順にソートして格納する。
Ｓ１１５６において、データ共有システム１００は、処理実行時スケジュールテーブル１７８に従ったリクエスト受信処理を行う。
Ｓ１１５７において、データ共有システム１００は、通常のリクエスト処理を実施する。
Ｓ１１５８において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４へＳ１１５７の処理結果をレスポンスとしてリクエスト元に返却するよう指示する。レスポンス返信部１５４は、連携インタフェース部１５０を介して、リクエスト元である外部システムへレスポンスを返す。
Ｓ１１５９において、データ共有システム１００は、図１５に示す処理を終了する。
【００４９】
図１６は、スケジュール時間帯におけるリクエスト処理の一例を示すフローチャートである。図１６は、リクエストスケジュール判断部１５５等において実行される、処理実行時スケジュールテーブル１７８に従ったリクエスト受信処理の流れを示す。図１６の処理は、図１５におけるＳ１１５６から起動される。
Ｓ１２００において、リクエストスケジュール判断部１５５は、図１６に示す処理を開始する。
Ｓ１２０２において、リクエストスケジュール判断部１５５は、受信リクエストが処理中のスケジュールグループに属すか否かを判定する。リクエストスケジュール判断部１５５は、予告スケジュールに属すか否かを、処理実行時スケジュールテーブル１７８の内容と受信したリクエストの内容とを比較し、クライアントＩＤ、メソッド、ＵＲＩの比較結果に基づいて判定する。リクエストスケジュール判断部１５５は、受信リクエストが処理中のスケジュールグループに属すと判定した場合、Ｓ１２０３の処理へ進み、受信リクエストが処理中のスケジュールグループに属さないと判定した場合、Ｓ１２１０の処理へ進む。
Ｓ１２０３において、リクエストスケジュール判断部１５５は、前記受信リクエストに対応するスケジュールエラーフラグがセットされている（スケジュールエラーフラグの値が１である）か否かを判定する。リクエストスケジュール判断部１５５は、スケジュールエラーフラグが１である場合、Ｓ１２１１の処理へ進み、スケジュールエラーフラグが１でない場合、Ｓ１２０４の処理へ進む。
【００５０】
Ｓ１２０４において、リクエストスケジュール判断部１５５は、前記受信リクエストの受信時刻が前記受信リクエストの受付期間内であるか否かを判定する。リクエストスケジュール判断部１５５は、前記受信リクエストの受信時刻が前記受信リクエストの受付期間内であると判定した場合、Ｓ１２０５の処理へ進む。リクエストスケジュール判断部１５５は、前記受信リクエストの受信時刻が前記受信リクエストの受付期間内でないと判定した場合、Ｓ１２１６の処理へ進む。
Ｓ１２０５において、リクエストスケジュール判断部１５５は、前記受信リクエストの前のリクエストが処理中であるか否かを判定する。リクエストスケジュール判断部１５５は、前記受信リクエストの前のリクエストが処理中であると判定した場合、Ｓ１２１２の処理へ進み、前記受信リクエストの前のリクエストが処理中でないと判定した場合、Ｓ１２０６の処理へ進む。
Ｓ１２０６において、データ共有システム１００は、前記受信リクエストに対して通常のリクエスト処理を実行する。
Ｓ１２０７において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４にたいして、リクエスト元へＳ１２０６の処理の結果をレスポンスとして返却する指示を行う。
Ｓ１２０８において、リクエストスケジュール判断部１５５は、Ｓ１２０７のレスポンス時刻が前記受信リクエストに対応する受付期間の終了時刻よりも後であるか否かを判定する。リクエストスケジュール判断部１５５は、Ｓ１２０７のレスポンス時刻が前記受信リクエストに対応する受付期間の終了時刻よりも後であると判定した場合、Ｓ１２１４の処理へ進む。リクエストスケジュール判断部１５５は、Ｓ１２０７のレスポンス時刻が前記受信リクエストに対応する受付期間の終了時刻よりも後ではないと判定した場合、Ｓ１２０９の処理へ進む。
Ｓ１２１０において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４に対して、リクエスト元へのリクエスト禁止エラーの返却を指示する。
【００５１】
Ｓ１２１１において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４に対して、リクエスト元へのスケジュールエラーの返却を指示する。
Ｓ１２１２において、リクエストスケジュール判断部１５５は、前記受信リクエストの前のリクエストが格納リクエストであるか否かを判定する。リクエストスケジュール判断部１５５は、前記受信リクエストの前のリクエストが格納リクエストであると判定した場合、Ｓ１２１３の処理へ進み、前記受信リクエストの前のリクエストが格納リクエストでないと判定した場合、Ｓ１２０６の処理へ進む。
Ｓ１２１３において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４に対して、リクエスト元へのリトライ推奨エラーの返却を指示する。
Ｓ１２１４において、リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８における前記受信リクエストの終了時刻を実終了時刻に更新する。
Ｓ１２１５において、リクエストスケジュール判断部１５５は、処理実行時スケジュールテーブル１７８の再スケジュールを実行する。
Ｓ１２１６において、リクエストスケジュール判断部１５５は、レスポンス返信部１５４に対して、リクエスト元へのリトライ推奨エラーの返却を指示する。
Ｓ１２０９において、リクエストスケジュール判断部１５５は、図１６に示す処理を終了する。
【００５２】
図１７は、処理延期時の再スケジュール処理の一例を示すフローチャートである。図１７は、スケジュール作成部１５８等において実行され、リクエスト処理延長時に処理実行時スケジュールテーブル１７８の更新を行う再スケジュール作成の処理の流れを示す。図１７の処理は、図１１におけるステップＳ１００３、図１２におけるステップＳ１０２４から起動される。
Ｓ１３００において、スケジュール作成部１５８は、図１７に示す処理を開始する。
Ｓ１３０１において、スケジュール作成部１５８は、処理実行時スケジュールテーブル１７８の各リクエストのスケジュールを上から順にチェックし、チェックしたリクエストについてＳ１３０２〜Ｓ１３０６の処理を実行するよう制御する。
Ｓ１３０２において、スケジュール作成部１５８は、Ｓ１３０１でチェックされたリクエストのリクエスト種別を判定する。スケジュール作成部１５８は、前記リクエスト種別が格納リクエストであると判定した場合、ステップＳ１３０５の処理へ進み、前記リクエスト種別が取得リクエストである場合、ステップＳ１３０３の処理へ進む。
Ｓ１３０３において、スケジュール作成部１５８は、前記リクエストのデータ種を判定する。スケジュール作成部１５８は、前記データ種を履歴情報と判定した場合、Ｓ１３０５の処理へ進み、前記データ種を状態情報と判定した場合、Ｓ１３０４の処理へ進む。
Ｓ１３０４において、スケジュール作成部１５８は、前記リクエストの処理実行時スケジュールテーブル１７８における開始時刻と終了時刻とをクリアする。
Ｓ１３０５において、スケジュール作成部１５８は、前記リクエストの開始時間と終了時間とで示される受付期間が他のリクエストの受付期間と重複しているか否かを判定する。スケジュール作成部１５８は、前記リクエストの開始時間と終了時間とで示される受付期間が他のリクエストの受付期間と重複していると判定した場合、Ｓ１３０６の処理へ進む。スケジュール作成部１５８は、前記リクエストの開始時間と終了時間とで示される受付期間が他のリクエストの受付期間と重複していないと判定した場合、Ｓ１３０７の処理へ進む。
Ｓ１３０６において、スケジュール作成部１５８は、前記リクエストに対応するスケジュールエラーフラグを１にセットする。
Ｓ１３０７において、スケジュール作成部１５８は、全てのリクエストのスケジュールについてＳ１３０１〜Ｓ１３０６の処理が完了しているか否かを判定する。スケジュール作成部１５８は、全てのリクエストのスケジュールについてＳ１３０１〜Ｓ１３０６の処理が完了していると判定した場合、Ｓ１３０８の処理へ進む。スケジュール作成部１５８は、全てのリクエストのスケジュールについてＳ１３０１〜Ｓ１３０６の処理が完了していないと判定した場合、Ｓ１３０１の処理へ進む。
Ｓ１３０８において、スケジュール作成部１５８は、Ｓ１３０４でクリアされた前記リクエストの開始時刻と終了時刻を再度決定する。
Ｓ１３０９において、スケジュール作成部１５８は、処理完了期限までに受付期間を決定できなかったリクエストが存在するか否かを判定する。スケジュール作成部１５８は、処理完了期限までに受付期間を決定できなかったリクエストが存在すると判定した場合、Ｓ１３１０の処理へ進む。スケジュール作成部１５８は、処理完了期限までに受付期間を決定できなかったリクエストが存在しないと判定した場合、Ｓ１３１１の処理へ進む。
Ｓ１３１０において、スケジュール作成部１５８は、前記リクエストのスケジュールエラーフラグを１にする。
Ｓ１３１１において、スケジュール作成部１５８は、図１７に示す処理を終了する。
【００５３】
図１８は、データ共有システム内のサーバ装置のハードウェア構成の一例を示す図である。データ共有システム１００は、ネットワークインタフェース１０５を介して、互いに接続された１台あるいは複数台のサーバで構成される。また、及び外部システム１２１、１２２、１２３も、ネットワークインタフェース１０５を介して、互いに接続された１台あるいは複数台のサーバで構成される。サーバ１０１、Ｗｅｂサーバ１１０、ＤＢサーバ１１１は、それぞれサーバを示している。サーバ１０１のハードウェア構成は、Ｗｅｂサーバ１１０、ＤＢサーバ１１１、アプリケーションサーバ１１２のハードウェア構成を抽象化したものとなっている。サーバ１０１は、バス１０６を介して接続されたＣＰＵ１０２、ＲＡＭ１０３、ＲＯＭ１０４、ネットワークインタフェース１０５、ＨＤＤ１０７等を含む。ＣＰＵ１０２は、ＨＤＤ１０７、ＲＯＭ１０４、ＲＡＭ１０３に記録されたデータ及びプログラムを読み出して情報処理を実行する。ＨＤＤ１０７、ＲＯＭ１０４等は、記憶部の一例である。
ＣＰＵ１０２が、ＲＡＭ１０３又はＨＤＤ１０７、ＲＯＭ１０４に記憶されたプログラムに基づき処理を実行することによって、先述したＣＰＵ１０２を含むサーバを構成要素とするデータ共有システム１００の機能及びフローチャートの処理が実現される。また、データ共有システム１００の機能及びフローチャートの処理は、複数のサーバによる処理の連携によって実現することもできる。
ネットワークインタフェース１０５は、データ共有システム１００内のサーバ間の機能連携に使用されると共に、外部のネットワーク１２０を介して、外部システムと通信するためにも使用される。
【００５４】
本実施形態の処理により、データ共有システム１００は、処理時間が動的に変化する可能性のあるリクエストについて優先して受付期間の決定を行い、時間制約を満たす再スケジュールが可能なスケジュールを作成することができる。したがってデータ共有システム１００は、リクエスト時に変化する処理時間に対応できるようになる。
格納リクエストの処理（データの登録又は更新）は、データ管理部の保持するデータ量を変化させるため、取得処理時間の見積りに影響する。また、格納リクエストは、外部システム側の都合で、送信データ量が変化するため、リクエストの処理時間がデータ共有システムだけで決定できない場合がある。したがって、格納リクエストは、取得リクエストよりも優先される。
また、デバイスの履歴情報は、デバイスの利用状況又は利用頻度に応じてデータ量が増加する。したがって、データ共有システム１００は、現在のデータ量を監視して処理時間の見積りに反映すると共に、状態情報よりも履歴情報を優先するリクエストとする。
以上の優先度判断と、格納処理の間に処理時間変化のためのバッファ時間を設けることと、により、データ共有システム１００は、再スケジュール可能なスケジュールを作成できるようになる。
したがって、予告時とリクエスト時とで処理時間が変化したとしても、外部システムのリクエストが時間的に分散されて処理できるようになり、コストアップせずにできるだけ多くのシステム連携を保証できるようになる。
また、データ共有システム１００は、リクエスト処理のスケジュールを作成しても、スケジュール結果を外部システムへ通知しない。スケジュールがリクエスト処理時にも動的に変化する可能性があるためである。外部システムは、データ共有システムが作成したスケジュールを意識することなく、既存のインタフェースに従ってシステム連携を行うことができる。
【００５５】
＜実施形態２＞
実施形態２は、実施形態１と基本的な構成は同じであるため、実施形態１との差異を説明する。
図１９は、リクエストタイミング返却のタイミングチャートの一例を示す図である。図１９は、実施形態１における図９のスケジュールに対して処理時間が超過してしまった場合の挙動に相当する。図９と同じ構成については、同じ番号を付している。
状況４２８は、図６におけるデバイス構成情報取得リクエスト群２５８の予告情報に対応する実際のデバイス構成情報の取得リクエストが行われている状況を示す。状況４２９は、図６におけるジョブログの取得リクエスト２５９の予告情報に対応する実際のジョブログの取得リクエストが行われている状況を示す。
実施形態１において、データ共有システム１００は、スケジュールされた受付期間外でリクエストを受信すると、リトライ推奨エラーを即返却した。実施形態２において、データ共有システムは、受付期間外でリクエストを受信すると、エラーの即時返却と共に、処理実行時スケジュールテーブル１７８の内容に従って、前記リクエストの受付期間の開始時刻の時刻情報を返却するという処理を行う。データ共有システム１００は、前記処理を、図１６におけるＳ１２１６の処理においてリトライ推奨エラーを返却する際に、行う。また、データ共有システム１００は、リクエストを送信した外部システムに対して、処理実行時スケジュールテーブル１７８を参照して、前記リクエストの開始時刻を返却する。したがって、例えば、外部システムは、時刻５１１に対する時刻５１２のように、次にリクエストを送るタイミングを適切に選択することができるようになる。ただし、データ共有システム１００は、最初に処理実行時スケジュールテーブル１７８の内容に従って返したタイミングに、処理時間の延長、後の再スケジュール等によって、前記リクエストを受け付けられない場合がある。その場合、データ共有システム１００は、実施形態１と同様、リトライ推奨エラー５０１のように、前のリクエストの処理中にリトライ推奨エラーを返却する。そして、データ共有システム１００は、スケジュールの再作成後に改めて、リクエストの受付期間の開始時刻の時刻情報を返却（例えば時刻５０３のタイミング返却）する。
【００５６】
以上、本実施形態の処理により、データ共有システム１００は、リクエストタイミングを返却するようにすることで、例えば、一つの外部システムが同じ制約条件の中で複数のリクエストを予約してリクエスト送信するような場合に柔軟な対応が可能となる。より具体的には、外部システムは、返却されたリクエストタイミング情報を処理できるように実装することにより、リトライ推奨エラーが返却された際に、次にリトライするリクエストを適切に選択することが可能となる。したがって、データ共有システム１００は、リクエストタイミング情報を処理できるように実装していない外部システム、リクエストタイミング情報を処理できるように実装している外部システム、いずれの外部システムとも連携が可能となる。
【００５７】
＜実施形態３＞
実施形態１、実施形態２において、データ共有システム１００は、複数のサーバによって構成されるものとして説明したが、データ共有システム１００は、単体のサーバによって構成されるものとしてもよい。
【００５８】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５９】
１００  データ共有システム、１０２  ＣＰＵ、１２１  外部システム
【図１】
2016057916.tif 000011
【図２】
2016057916.tif 000012
【図３】
2016057916.tif 000013
【図４】
2016057916.tif 000014
【図５】
2016057916.tif 000015
【図６】
2016057916.tif 000016
【図７】
2016057916.tif 000017
【図８】
2016057916.tif 000018
【図９】
2016057916.tif 000019
【図１０】
2016057916.tif 000020
【図１１】
2016057916.tif 000021
【図１２】
2016057916.tif 000022
【図１３】
2016057916.tif 000023
【図１４】
2016057916.tif 000024
【図１５】
2016057916.tif 000025
【図１６】
2016057916.tif 000026
【図１７】
2016057916.tif 000027
【図１８】
2016057916.tif 000028
【図１９】
2016057916.tif 000029