JP2019200577A - 制御方法、システム及びプログラム - Google Patents

Abstract

【課題】ネットワークデバイスから収集されて蓄積されたイベントデータを取得する場合の取得漏れを防止すること。【解決手段】サーバ102のイベント処理部321は、MFP101から受信したイベントデータに、イベントの発生時刻とイベントごとにユニークな識別子とからなる時間情報（イベント発生時刻）を付与し、イベント格納部322に格納する。また、イベント取得部322は、クライアント103から指定された時刻と識別子とを含む情報を第１パラメータに設定し（S521）、現在時刻から既定の時間を差し引いた時間情報を第２パラメータに設定し（S522）、第１パラメータ及び第２パラメータを用いて特定されたイベントデータを取得し（S523）、クライアント103に送信する（S524）。【選択図】図５

Description

本発明は、ネットワークデバイスで発生したイベントに係るイベントデータを管理するシステムの制御に関する。

近年、クラウドコンピューティングの普及に伴い、PCやスマートフォンだけでなく、様々なデバイスがインターネットに接続されるようになってきた。デバイスをインターネット上のサーバに接続することで、デバイスの機器情報を取得し一元管理したり、集計・分析を行いユーザにデバイスの利用状況をフィードバックしたりすることが可能となった。また、取得したデバイスの機器情報を蓄積し、蓄積したデータやそれらを集計したデータをAPIとして提供するサービスや関連技術も存在する。

例えば、特許文献１では、時刻や期間を指定して、データベースから指定期間内に発生した履歴データを取得する技術が提案されている。
また、プリンタ等のデバイスから発生した消耗品切れ等のイベントを蓄積し、イベントをWebAPIとして提供するサーバと、そのサーバからイベントを取得するために時刻を指定してポーリングを行うクライアントから構成されるシステムも存在する。このクライアントは、イベントの発生時刻を指定してサーバに対してリクエストを送信し、取得できたイベントの最新時刻を次回のポーリング時に指定することで、継続的にイベントを取得することができる。このようなシステム構成の場合、ポーリングを行うクライアント側で、どの時刻までのイベントを取得したかを管理する必要がある。

特開２０１４−９２９５３号公報

従来技術として上述した時刻指定でポーリングするシステムでは、ポーリングで取得できるイベントが毎回重複しないように、次回のポーリング時には前回取得できたイベントの最新時刻より後の時刻でイベントを取得する仕組みを有する。
一方で、データベースからデータを取得する場合、コンピュータリソースの制限により一度のクエリで取得できるデータの件数に上限を設けることが多い。特に、WebAPIなどのインターネット上のサードパーティに公開するようなAPIの場合、大容量のデータ取得によるリソースの枯渇からサーバを守るために、データの取得件数に上限を設けることは必須である。

しかし、一度で取得できる件数に上限が設けられていると、時刻指定で取得する場合、同一発生時刻のイベントが上限をまたいで存在した場合に、上限により切り捨てられたイベントが取得できないという課題があった。次回のポーリング時には、前回取得できたイベントの最新時刻より後の時刻でイベントを取得するため、同一時刻のイベントは以降取得できないからである。

さらに、イベントを蓄積する側であるサーバにおいて、その時々のサーバの状態によってはデバイスから発生したイベントをデータベースに書き込むまでに遅延が生じる場合がある。このようなシステムでは、大量のイベントを処理するためにアプリケーションが並列で稼働していることが一般的であり、一部の処理に遅延が生じた際に新しいイベントが古いイベントを追い越してデータベースに書き込まれるケースが考えられる。このような、イベントの発生は先であるがデータベースにはまだ書き込まれていない、という現象が発生すると、取得のタイミングによっては後発のイベントが先に取得されてしまうため、先発のイベントが以降、取得できないという課題があった。

本発明は、上記の課題を解決するためになされたものである。本発明は、ネットワークデバイスから収集されて蓄積されたイベントデータを取得する場合の取得漏れを防止できる仕組みを提供することを目的とする。

本発明は、ネットワークデバイスで発生したイベントのそれぞれに係るイベントデータを、イベントの発生時刻とイベントごとにユニークな識別子とからなる時間情報をそれぞれに付与して管理するデータベースから、少なくとも一部のイベントデータを取得するためのシステムにおける制御方法であって、指定された時刻と識別子とを含む情報を第１パラメータとして設定する第１設定工程と、現在時刻から既定の時間を差し引いた時間情報を第２パラメータとして設定する第２設定工程と、前記データベースから、前記第１パラメータ及び前記第２パラメータを用いて特定されたイベントデータを取得する取得工程と、を有することを特徴とする。

本発明によれば、ネットワークデバイスから収集されて蓄積されたイベントデータを取得する場合の取得漏れを防止することができる。よって、一度に取得できるイベントデータの数に上限がある場合でも、またイベントデータの格納処理に遅延が生じた際に新しいイベントデータが古いイベントデータを追い越して格納される可能性がある場合でも、漏れなくイベントデータを取得できる。

本実施形態のネットワークシステムのネットワーク構成を例示する図。 本実施形態のネットワークシステムのハードウェア構成を例示する図。 本実施形態のネットワークシステムのソフトウェア構成を例示する図。 本実施形態のイベント格納に関する処理の一例を示すフローチャート。 本実施形態のイベント取得に関する処理の一例を示すフローチャート。 イベントの発生と格納に関するタイミングチャート。

以下、本発明を実施するための形態について図面を用いて説明する。
＜ネットワーク構成＞
図１は、本発明の一実施形態を示す管理システムを含むネットワークシステムの構成の一例を示す図である。
図１に示すように、本実施形態のネットワークシステムは、MFP101と、サーバ102、クライアント103を含む。なお、MFPは「Multifunction Peripheral」の略称であり、多機能周辺装置を示す。

サーバ102は、MFP101を管理する本実施形態の管理システムを構成する。なお、本実施形態において、サーバ102は、複数の物理マシン（情報処理装置）で構成されるものとし、クラウドサーバ等で構成されていてもよい。例えば、サーバ102は、パブリッククラウドサービス等を利用して構築することが可能である。また、サーバ102は、１台の物理マシンで構成することも可能である。さらに、本実施形態では、サーバ102で管理するネットワークデバイスの一例としてMFP101等の画像形成装置を用いて説明するが、画像形成装置以外のネットワークデバイスであってもよい。

MFP101、サーバ102、クライアント103は、ネットワーク104を介して通信可能に接続される。ネットワーク104は、例えばインターネットや、LAN、WAN、電話回線、専用デジタル回線、ATMやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか又はこれらの組み合わせで実現されるいわゆる通信ネットワークである。

クライアント103は、パーソナルコンピュータ（PC）、タブレット型コンピュータ、スマートフォン等の情報処理装置であっても、１台以上の物理マシンで構成される外部の別システムであってもよい。

＜情報処理装置の内部構成＞
図２は、本実施形態のネットワークシステムを構成する各装置のハードウェア構成の一例を示す図である。
図２（A）は、サーバ102、クライアント103を構成する情報処理装置のハードウェア構成の一例を示す図である。
CPU201は、RAM202、ROM203、記憶装置206などから読み込んだプログラムを実行する。RAM202は、CPU201のメモリやワークエリアとして機能する。ROM203は、プログラムや各種データを記憶する。記憶装置206は、プログラムや各種データを記憶する。

ディスクコントローラ204は、ハードディスクドライブ（HDD）、ソリッドステートドライブ（SSD）等の記憶装置206へのデータアクセスを制御する。ネットワークI/F205は、LANなどのネットワークに接続されて、ネットワークに接続された他の機器との通信を可能にする。上記201〜205などハードウェアを構成する各部は、内部バス207を介して接続されている。

＜MFPの内部構成＞
図２（B）は、MFP101のハードウェア構成の一例を示す図である。
CPU221は、RAM222、ROM223、記憶装置224などから読み込んだプログラムを実行し、内部バス230を介して各リソースを統括的に制御する。RAM222は、CPU221のメモリやワークエリアとして機能する。ROM223は、プログラムや各種データを記憶する。記憶装置224は、プログラムや各種データを記憶するHDD、SSDなどである。ネットワークI/F225は、LANなどのネットワークに接続されて、外部のネットワーク機器と片方向または双方向にデータとの通信を可能にする。

デバイス制御部226は、プリント部227を制御する。入出力装置229は、MFP101における入出力を担う複数の構成を備える。具体的には、入出力装置229は、ユーザからの入力（ボタン入力など）を受け付け、該入力に対応する信号を入出力I/F228によって前述した各処理部へ伝える。他にも、入出力装置229は、ユーザに対して必要な情報を提供したり、ユーザ操作を受付けたりするための表示装置（タッチパネルなど）も備える。さらに、原稿を読み取り、入力として電子データを受付けるためのスキャン装置が、入出力装置229に含まれていてもよい。

図３は、本実施形態のネットワークシステムのソフトウェア構成の一例を示す図である。まず、MFP101、サーバ102、クライアント103が備える主なソフトウェアについて説明し、その後、具体的なデータと処理について説明する。

＜ソフトウェアシステム構成＞
図３（A）は、MFP101のソフトウェア構成の一例を示す図である。
図３（A）に示すソフトウェア構成は、CPU221がRAM222、ROM223、記憶装置224などから読み込んだプログラムを実行することにより実現される。

イベント生成部311は、MFP101内部で発生した消耗品切れ、パーツ故障といったイベントをデータとして生成するソフトウェアモジュールである。該イベントには、例えば、MFP101の識別番号や型番、能力、ロケール、タイムゾーンなどの情報に加え、デバイス種別特有の情報も含まれている。

イベント格納部312は、イベント生成部311が生成したイベントを記憶装置224に格納するためのデータベース等のソフトウェアである。
イベント送信実行部313は、イベントを外部に送信、あるいは外部からの要求に応じてイベントを返却（送信）する判断を行うソフトウェアモジュールである。
通信部314は、ネットワークI/F225を介してサーバ102などの外部の機器と通信するためのソフトウェアモジュールである。

図３（B）は、サーバ102のソフトウェア構成の一例を示す図である。
図３（B）に示すソフトウェア構成は、サーバ102を構成する情報処理装置のCPU201が、RAM202、ROM203、記憶装置206などから読み込んだプログラムを実行することにより実現される。

なお、サーバ102におけるイベント処理部321やイベント取得部323は、サーバレスコンピューティングやFaaS（Function as a Service）と呼ばれるアーキテクチャ上で実行される。そのため、サーバ102には、イベント処理部321やイベント取得部323の実行条件ごとのコードが存在し、それらのコードは予め記憶装置206に記憶されている。また、それらのコードは、実行される度にメモリやCPUなどのコンピュータリソースが割り当てられ、所定時間内で実行された後、リソースが解放される。所定時間内に処理を終えない場合は、コード実行部325により処理が終了（タイムアウト）されるが、既定の範囲内（例えば「上限５分」）であれば、イベント処理部321やイベント取得部323等の実行条件ごとにタイムアウト時間を設定できる。このようなアーキテクチャでは、コードが実行される度にリソースが割り当てられるため、同じ実行条件が連続的に満たされた場合には、同一コードであっても異なるリソース上で並行して実行される。さらに、同一コードを実行したとしても、処理するデータによっては時間がかかったり、割り当てられたリソースに不具合があったりする場合もある。したがって、同一コードの実行に際して後発の処理が先発の処理を追い越す場合があり、処理の実行順序は保障されていない。

イベント処理部321は、MFP101から受信したイベントを整形し、イベント格納部322に格納する処理の主体となるソフトウェアモジュールである。イベント処理部321の実行コード（第１の実行コード）は、サーバ102を構成する情報処理装置の記憶装置206に記憶されている。イベント処理部321は、継続的に発生するMFP101のイベントを処理するために、並行して実行される。

イベント格納部322は、イベント処理部321で処理されたイベントを記憶装置206に格納するためのデータベース等のソフトウェアである。イベント格納部322には、結果整合性を有するデータベースを用いているため、トランザクション処理がサポートされておらず、書き込みに遅延が発生することも許容している。

イベント取得部323は、クライアント103からのリクエストに応じてイベント格納部322からイベントを取得する処理の主体となるソフトウェアモジュールである。イベント取得部323の実行コード（第２の実行コード）は、サーバ102を構成する情報処理装置の記憶装置206に記憶されている。イベント取得部323は、イベント格納部322に対してイベントの発生時刻を条件に期間指定で検索することで、対象期間のイベントを取得する。処理手順の詳細については後述する。なお、本実施形態において用いる「時刻」には年月日の情報も含まれる。

通信部324は、ネットワークI/F205を介してMFP101やクライアント103などの外部の機器と通信するためのソフトウェアモジュールである。
コード実行部325は、予め登録されたいくつかの条件を管理し、通信部324により受信した外部からのリクエスト、データの内容がいずれかの条件を満たす場合に、その条件に対応するコードの実行制御を行う。この実行制御に従い、前述したイベント処理部321やイベント取得部323による処理が実現されることになる。コード実行部325は、イベント処理部321やイベント取得部323などの処理を包括的に管理し、コードの実行制御に加え、リソースの割り当てや所定時間内に終えないコードの処理を終了する手段も備えている。

図３（C）は、クライアント103のソフトウェアの構成例を示す図である。
図３（C）に示すソフトウェア構成は、クライアント103を構成する情報処理装置のCPU201が、RAM202、ROM203、記憶装置206などから読み込んだプログラムを実行することにより実現される。

ポーリング処理部331は、サーバ102から、該サーバ102で管理されるMFP101のイベントを取得するために定期的にポーリングを行うソフトウェアモジュールである。
カーソル格納部332は、ポーリング処理部331が時刻を指定してポーリングを行う際に、どの時刻までのイベントまで取得したかを記憶するための情報（以下「カーソル」）を、クライアント103の記憶装置206に格納するためのソフトウェアである。
カーソル格納部332は、例えばデータベース等である。

イベント格納部333は、ポーリング処理部331が取得したイベントを、クライアント103の記憶装置206に格納するためのデータベース等のソフトウェアである。
通信部334は、ネットワークI/F205を介してサーバ102などの外部の機器と通信するためのソフトウェアモジュールである。

本実施形態のネットワークシステムは、MFP101が生成したイベントをサーバ102に格納する処理系と、サーバ102に格納したイベントをクライアント103がポーリングで取得する処理系の、主に２つの処理系を備えている。

以下、これら２つの処理系を図４及び図５のフローチャートと、図６のタイミングチャートを用いて説明する。なお、本ネットワークシステムでは、MFP101、サーバ102、クライアント103間で通信するために認証を行う必要があるが、認証処理は本発明の特徴ではないため省略する。本実施形態におけるシステム間の認証方法は、特に限定されるものではない。

＜サーバ102におけるイベントの格納＞
図４は、サーバ102の通信部324でMFP101のイベント送信実行部313からのイベントデータを受信した際に、コード実行部325によって実行されるイベント処理部321の処理（イベントを格納する処理系）の一例を示すフローチャートである。イベント処理部321は、第１の実行コードをサーバ102のリソース（メモリやCPU等）を用いて実行することによって実現される、本フローチャートの処理の主体となるソフトウェアモジュールである。なお、イベントを格納する処理系では、MFP101のイベント送信実行部313が通信部314によりサーバ102に対して送信されたイベントデータを、サーバ102で受信することでイベント格納処理が開始される。

S411において、イベント処理部321は、MFP101から受信したイベントがイベント格納条件に合致しているか否かを判定する。イベント格納条件とは、同一のイベントが既に格納されていないか、本システムで収集対象となっているMFP101のイベントであるか等の条件である。これらの条件を満たしている場合に、イベント処理部321は、MFP101から受信したイベントがイベント格納条件に合致していると判定する。一方、これらの条件を満たしていない場合には、イベント処理部321は、MFP101から受信したイベントがイベント格納条件に合致していないと判定する。

上記S411において、MFP101から受信したイベントがイベント格納条件に合致していないと判定した場合（S411でNoの場合）、イベント処理部321は、イベントデータを格納することなく、本フローチャートの処理を終了する。
一方、上記S411において、MFP101から受信したイベントがイベント格納条件に合致していると判定した場合（S411でYesの場合）、イベント処理部321は、S412に処理を進める。

S412において、イベント処理部321は、MFP101から受信したイベントデータの整形を行う。前述した通り、イベントデータには、MFP101に関する様々な情報が含まれているが、システムの要件に応じて不要なデータを排除したり、データフォーマットを変換する必要がある。

次にS413において、イベント処理部321は、イベントの発生時刻を生成し、MFP101から取得したイベントに発生時刻を追加する。このときイベント処理部321が生成するイベントの発生時刻は、サーバ102の現在時刻に一意な識別子を付与したものである。一意な識別子には、例えばUUID（Universally Unique Identifier）を用いる。サーバ102の現在時刻に一意な識別子を付与する理由は、後のイベントをポーリングする処理系で説明する。ここで、上記S412及びS413を経て整形されたイベントをJSON（JavaScript（登録商標） Object Notation）形式で表したものを以下に示す。このイベントはMFP101のイベント生成部311で生成された消耗品（トナーカートリッジ）切れのイベントを整形した例であり、“occurred_at”はイベントの発生時刻を示している。

{
”event”: {
”id”: ”c327d5eb-5fc6-4e5b-ad74-07aa119ccb65”,
”occurred_at”: ”2018-01-01T12:57:45.920Z_c327d5eb-5fc6-4e5b-ad74-07aa119ccb65”,
”device_id”: ”a9e431dc-1a48-406a-8c01-138f2e396062”,
”properties”: {
”consumable_type”: ”toner”,
”color”: ”cyan”,
”remaining_level”: ”Low”,
”cartridge_serial”: ”22b38b0f-46b0-402e-8219-4d62edf5209f”
}
}
}

次にS414において、イベント処理部321は、上記S412及びS413で整形済みのイベントデータを、イベント格納部322に格納し、本フローチャートの処理を終了する。このように、サーバ102は、MFP101で発生したイベントのそれぞれに係るイベントデータを、イベントの発生時刻とイベントごとにユニークな識別子とからなる時間情報（イベント発生時刻）をそれぞれに付与してイベント格納部322で管理する。

なお、管理システムに格納されたこれらのイベントデータは、分析や追跡のために長期間残されることを想定しているが、記憶装置206のリソース上の制限により、一定期間を過ぎたイベントを削除する等の仕組みを備えていてもよい。

＜イベントのポーリング＞
図５は、イベントをポーリングで取得する処理系におけるイベント取得部323とポーリング処理部331の処理の一例を示すフローチャートである。
図５（A）は、クライアント103のポーリング処理部331の処理の一例を示すフローチャートである。このフローチャートの処理は、クライアント103を構成する情報処理装置のCPU201が、RAM202、ROM203、記憶装置206などから読み込んだプログラムを実行することにより実現される。なお、クライアント103のポーリング処理部331は、既定の間隔でサーバ102に対してイベントを取得するためのリクエストを送信する。以下、ポーリング処理部331を処理の主体として説明する。

まずS511において、ポーリング処理部331は、カーソル格納部332からカーソルの取得を試み、カーソルが取得できたか否かを判定する。このカーソルは、ポーリング処理部331がサーバ102からどの時刻までのイベントを取得したかを記憶するためのものである。例えば、前述したイベントの例の“occurred_at”に示した時刻やシーケンス番号のような単調増加する値であり、本システムではカーソルとして、この時刻を採用している。具体的には、ポーリング処理部331で取得済みのイベントデータの最新の時刻（“occurred_at”の値）に対応する。

上記S511において、カーソルが取得できたと判定した場合（S511でYesの場合）、ポーリング処理部331は、S512に処理を進める。
一方、上記S511において、カーソルが取得できなかったと判定した場合（S511でNoの場合）、ポーリング処理部331は、S513に処理を進める。

S512において、ポーリング処理部331は、カーソル格納部332から取得したカーソルを指定してサーバ102に対してイベントを取得するためのリクエストを送信する。本システムでは、ポーリングでイベントを取得するための通信プロトコルとして例えばHTTP（Hypertext Transfer Protocol）を使用している。例えば、ポーリング処理部331は以下のようなリクエストをサーバ102に対して送信する。ここでは説明を簡略化するために、HTTPリクエストヘッダは省略している。
GET https://api.sample.com/event?from=2018-01-01T12:56:43.687Z_f368c048-5c60-4eb6-9cae-ffe447fdcd26

なお、サーバ102の通信部324で上記リクエストが受信された場合、コード実行部325は、イベント取得部323を実行し、後述する図５（B）のフローチャートの処理を実行し、クライアント103にイベントデータを返却する。これを、ポーリング処理部331が取得する。

上記S512において送信したリクエストがサーバ102で正常に処理されると、ポーリング処理部331は、以下に例示するような、カーソルで指定した時刻より後の０件以上のイベントデータを取得することができる。

{
”events”: [
{
”id”: ”c327d5eb-5fc6-4e5b-ad74-07aa119ccb65”,
”occurred_at”: ”2018-01-01T12:57:45.920Z_c327d5eb-5fc6-4e5b-ad74-07aa119ccb65”,
”device_id”: ”a9e431dc-1a48-406a-8c01-138f2e396062”,
”properties”: {
”consumable_type”: ”toner”,
”color”: ”cyan”,
”remaining_level”: ”Low”,
”cartridge_serial”: ”22b38b0f-46b0-402e-8219-4d62edf5209f”
}
},
{
”id”: ”a58b5915-dbe6-4a83-9c9c-3ae5ee7394ee”,
”occurred_at”: ”2018-01-01T12:57:46.345Z_a58b5915-dbe6-4a83-9c9c-3ae5ee7394ee”,
”device_id”: ”5919e52b-f81b-4249-b813-0455a20eaf81”,
”properties”: {
”consumable_type”: ”toner”,
”color”: ”magenta”,
”remaining_level”: ”Empty”,
”cartridge_serial”: ”f1887d40-ea99-4c3d-ac92-6ab7f5da5d8e”
}
},
{
”id”: ”42b4f7c1-c950-4485-8102-39aa4c9ba3fa”,
”occurred_at”: ”2018-01-01T12:57:47.324Z_42b4f7c1-c950-4485-8102-39aa4c9ba3fa”,
”device_id”: ”beeee118-06d7-4ba3-b761-7f10816dee3b”,
”properties”: {
”consumable_type”: ”toner”,
”color”: ”yellow”,
”remaining_level”: ”Low”,
”cartridge_serial”: ”8db99bb5-6073-4947-9d4a-fe936351ec57”
}
}
]
}

上述したリクエストの例では、URLクエリパラメータで“from”（イベント取得対象期間の始点）しか指定されていないが、“to”（イベント取得対象期間の終点）に相当するパラメータは、後述するサーバ102のイベント取得部323で補完される。サーバ102のイベント取得部323は、イベント格納部322から、以下の条件に合致する発生時刻のイベントを取得する。
「取得対象期間の始点の時刻 ＜ イベント発生時刻 ≦ 取得対象期間の終点の時刻」
なお、詳細は図５（B）で示す。

また、S513において、ポーリング処理部331は、デフォルト値をカーソルとして指定してイベントの取得リクエストを送信する。このとき、ポーリング処理部331は以下のようなリクエストをサーバ102に対して送信する。
GET https://api.sample.com/event?from=2000-01-01T00:00:00.000Z

このリクエストに応じて、ポーリング処理部331がサーバ102から取得できるイベントデータは、上述したS512のリクエストで取得できるものと同様である。
なお、デフォルト値がカーソルとして使用されるのは、主に初回のポーリング時や何らかの理由によりカーソル格納部332がリセットされた場合などである。

ポーリング処理部331は、上記S512又は上記S513の処理によりサーバ102から取得できるイベントデータを取得すると、S514に処理を進める。
S514において、ポーリング処理部331は、取得したイベントデータをクライアント103のイベント格納部333に格納する。それと共に、ポーリング処理部331は、取得できたイベントのうち、最新のイベントの発生時刻（“occurred_at”に相当）を次回のポーリング時に指定するカーソルとしてカーソル格納部332に格納し、本フローチャートの処理を終了する。

ポーリング処理部331は、図５（A）の処理を繰り返し実行することで、発生し続けるMFP101のイベントを時系列順かつ重複することなく、継続的に取得することができる。

ここで、カーソルとして使用するイベントの発生時刻に、時刻と一意な識別子を付与する理由を説明する。ポーリング処理部331は、上述したようなURLに、URLクエリパラメータを指定してサーバ102に対してリクエストを送信する。本システムでは、リクエストのURLクエリパラメータの“from”に指定された時刻を始点に、サーバ102のイベント取得部323が補完した時刻を終点とする期間で、サーバ102のイベント格納部322からイベントデータを取得する。

一般的に、このようなWebAPIでは一度に取得できるデータに上限が設定されていることが多く、本システムにおいても上限が設定されることを想定している。サーバ102の一度に取得できるイベントデータの上限が、例えば100件であった場合、100件を超えるイベントデータはイベント取得部323が切り捨てられた上でレスポンスが返却される。すなわち、この場合、取得対象のイベントデータのうち一部しか取得されない。ここで、URLクエリパラメータに指定する時刻に、一意な識別子を付与しないでイベント格納部322に格納するケースについて考える。
表１に、イベントの発生時刻に一意な識別子を付与しないでイベント格納部322に格納されているイベントとその発生時刻の例を示す。

なお、表１に示すイベント番号列は説明の便宜上用いた属性であるため、本システムで扱うイベントに含まれている属性ではない。
クライアント103は、カーソルを管理しているため、イベント取得部323がイベントを切り捨てた場合でも次回のポーリング時に取得することが可能である。しかし、同一発生時刻のイベント（例えば表１の「イベント100」と「イベント101」）が、一度に取得できるデータの上限をまたいで存在した場合に問題が発生する。以下、詳細に説明する。

ポーリング処理部331は、表１に示す「イベント1」〜「イベント100」を取得できた場合、クライアント103のカーソルを「イベント100」の時刻で更新する。しかし、次回のポーリングでは「イベント100」の時刻より後の時刻（つまり「イベント102」以降）のイベントが取得対象となる。このように、発生時刻に一意な識別子を付与しないでイベントデータを管理するケースでは、「イベント100」と発生時刻が等しい「イベント101」の区別ができないため、「イベント101」は取得漏れになってしまう。すなわち、取得すべきイベントデータの一部が取得できないといった事態が発生する。

そこで、本実施形態では、イベントの発生時刻に一意な識別子を付与し、同一時刻に発生したイベントを区別することで、上述したような取得漏れを防止する。
表２に、イベントの発生時刻に一意な識別子を付与してイベント格納部322に格納されているイベントとその発生時刻の例を示す。

イベント取得部323は、イベント格納部322からイベントを取得する期間の条件として、時刻に一意な識別子を付与した文字列を指定する。イベント取得部323がイベント格納部322から表２の「イベント100」までを取得した際に、クライアント103のカーソルとして更新されるのは「イベント100」の発生時刻となる。次回のポーリング時に、ポーリング処理部331が「イベント100」の発生時刻を指定すると、イベント取得部323が文字列比較によって「イベント100」の発生時刻の次に大きい値（イベント発生時刻）を取得対象とする。したがって、「イベント100」の発生時刻の次に大きいのは、「イベント101」の発生時刻であるため、同一時刻に発生したイベントであっても漏れなく取得できる。

図５（B）は、サーバ102の通信部324でクライアント103のポーリング処理部331からのリクエストを受信した際に、コード実行部325によって実行されるイベント取得部323の処理の一例を示すフローチャートである。イベント取得部323は、第２の実行コードをサーバ102のリソース（メモリやCPU等）を用いて実行することによって実現される、本フローチャートの処理の主体となるソフトウェアモジュールである。なお、イベントを取得する処理系では、クライアント103のポーリング処理部331が通信部334によりサーバ102に対して送信されたリクエストを、サーバ102で受信することでイベント取得処理が開始される。

S521において、イベント取得部323は、サーバ102のイベント格納部322に対して、イベントの発生時刻を条件に期間指定で検索をかける際の始点となる時刻（第１パラメータ）を設定する。イベント取得部323は、図５（A）のS512あるいはS513で指定されたURLクエリパラメータ（カーソル）を始点として設定する。

S522において、イベント取得部323は、サーバ102のイベント格納部322に対して、イベントの発生時刻を条件に期間指定で検索をかける際の終点となる時刻（第２パラメータ）を設定する。イベント取得部323は、サーバの現在時刻から既定の時間を差し引いた時刻を設定する。

ここで、イベント取得部323が、イベント取得対象期間の終点にサーバの現在時刻から既定の時間を差し引いた時刻を設定する理由を、イベントの追い越しが発生する場合を例に説明する。
表３に、ある期間でのイベントの発生時刻と、イベント処理部321が実際にサーバ102のイベント格納部322に格納した時刻の例を示す。

表３の例は、イベント処理部321にて「イベント1001」に対する処理が先に開始され、発生時刻も先に生成されたが、実際にイベント格納部322への格納は「イベント1002」より後である、というイベント処理の追い越しが発生した状態を示す。これは、「イベント1001」を処理するためのイベント処理部321に割り当てられたリソースに不具合があったり、イベント格納部322の処理に一時的な遅延が発生した場合などに起こり得る。

この状態で、イベントを取得する期間の終点が例えば“2018-01-01T20:00:00.000Z”であった場合、「イベント1001」は本来取得対象のイベントであるがその時点でイベント格納部322に格納されていないため取得できない。しかも、イベント取得部323は「イベント1001」を取得せずに「イベント1002」を取得し、クライアント103のカーソルも「イベント1002」の発生時刻で更新される。このため、次回のポーリングで取得できるのは「イベント1003」以降のイベントとなる。したがって、ポーリング処理部331は「イベント1001」を取得できず、「イベント1001」の取得漏れが発生する。

図６は、イベントの発生と格納に関するタイミングチャートである。
図６（A）は、イベントの取得漏れが発生するケースを例示するタイミングチャートである。
TO1は、イベント1001の発生時刻である。
TO2は、イベント1002の発生時刻である。

TS1は、イベント1001がイベント処理部321によりイベント格納部322に格納された時刻である。
TS2は、イベント1002がイベント処理部321によりイベント格納部322に格納された時刻である。

TIは、イベント取得対象期間の始点とする時刻である。TIは、ポーリング処理部331が指定したカーソルの時刻に対応する。
TEは、イベント取得対象期間の終点とする時刻である。
図６（A）において各処理の時刻の関係は以下の通りである。
TI ＜ TO1 ＜ TO2 ＜ TS2 ＜ TE ＜ TS1

図６（A）の場合、イベント処理部321は、イベント格納部322にイベント1001を格納する前にイベント1002を格納するため、時刻TEをイベント取得対象期間の終点として指定すると、イベント1001の取得漏れが発生する。

図６（B）は、イベントの取得漏れを防止する構成を説明するタイミングチャートである。
TO1、TO2、TS2、TS1の時刻関係は、図６（A）と同じである。
上述したようにイベント処理部321は、アーキテクチャの制限上、所定時間内に処理を終える必要があるが、割り当てられたリソースの不具合等により、コード実行部325によって処理が終了させられる（タイムアウトする）場合がある。本実施形態では、このタイムアウト時間を利用してイベント処理の追い越しによるイベントの取得漏れを防止する。

まず、図６（B）において、TT1は、イベント処理部321が処理する「イベント1001」のタイムアウト予定時刻を表している。
時間P1は、イベント処理部321のタイムアウト時間であり、時間P1は、時刻TT1とTO1の差に対応する。時刻T0は、現在時刻である。

時間P2は、上述した課題を解決するために使用するP1以上の時間、すなわち上述のタイムアウト時間以上の時間である。ここでは、イベント処理部321のタイムアウト時間がP1であるため、イベント処理部321が処理中のイベントの中には、現在時刻からP1以上過去に発生したイベントは存在しない。
従って、イベント取得対象期間の終点を現在時刻からP1以上過去に設定することで、仮に「イベント1002」が「イベント1001」の処理を追い越しても、現在時刻においてこれらのイベントは取得対象期間外のイベントであるため取得されることはない。

ここで、「イベント1001」を処理するイベント処理部321が時刻TT1でタイムアウトした場合について考える。この場合でも、「イベント1001」を新規イベントとして発生時刻を設定しリトライすることで、いつかはイベント格納部322に格納され、そのイベントを取得することができるようになる。

以上のように、イベント取得部323が以下の式を満たすイベント取得対象期間の終点時刻（TE）を設定することで、イベント処理の追い越しによるイベントの取得漏れを防止することが可能となる。
TE = T0 - P2 （ただし、P2 ≧ P1）

なお、サーバ側の処理であるイベント取得部323にてイベント取得対象期間の終点時刻を設定する理由は、クライアント103が自由にこの時刻を指定してしまうと上記の式を満たすことができなくなってしまうからである。
このように、現在時刻からタイムアウト時間を差し引くことで、イベント処理の追い越しに起因するイベントの取得漏れを防止することが可能となる。

以下、図５（B）の説明に戻る。
S523において、イベント取得部323は、S521で設定したポーリング処理部331が指定したURLクエリパラメータ（カーソル）を始点、S522で設定した現在時刻からタイムアウト時間を差引いた時刻を終点としイベント取得対象期間を設定する。そして、イベント取得部323は、イベント格納部322から指定された期間分のイベントを取得する。すなわち、イベント取得部323は、上記始点と終点で特定されるイベント取得対象期間に含まれるイベント発生時刻を有するイベントデータを取得する。

次にS524において、イベント取得部323は、イベント格納部322から取得したイベントを通信部324によりレスポンスとして、要求元のポーリング処理部331に返却（送信）し、本フローチャートの処理を終了する。

以上の構成により、サーバ102に格納されたイベントデータを時刻指定でポーリングする場合でも、漏れなく取得することが可能になる。一方で、ポーリング処理部331は一定の間隔で繰り返しポーリングを行うが、サーバ102の一度に取得できるイベントの上限により、既定のポーリング間隔ではイベントの取得が追い付いつかなくなる可能性がある。その場合、ポーリング処理部331は、取得したイベントの発生時刻と現在時刻を比較して、一定の差が開いたタイミングでポーリング間隔を短くするなどの処理を実行するとよい。

上述したように、本実施形態で説明したイベントの収集対象となるネットワークデバイスは、MFPに限定されるものではない。例えば、PCやスマートフォン、タブレットなどのデバイスをはじめ、通信機能を有する家電や、ネットワークカメラ等を含む防犯設備、センサ、自動車などのいわゆるIoT（Internet of Things）機器であってもよい。

以上のように、イベント発生時刻を指定して定期的にイベントデータを取得する場合、一度に取得できるイベントデータの件数に上限があり、同一発生時刻のイベントデータがその上限をまたいで存在している場合でも、取得漏れを防止できる。また、サーバ102内で実行される複数のイベント処理に追い越しが発生する場合でも、イベントデータの取得漏れを防止できる。例えば、クラウド上で提供されるアプリケーションを用いて構成される、データベースに登録された大量のログの中の未送信のログを取得して、外部の別システムに提供するシステムに、時刻指定でポーリングする場合でも、ログの取得漏れを防止できる。よって、MFP101等のネットワークデバイスから収集されてサーバ102に蓄積されるイベントデータを、クライアントから時刻を指定して漏れなく取得することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施形態を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施形態）
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路（例えば、ASIC）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (11)

1. ネットワークデバイスで発生したイベントのそれぞれに係るイベントデータを、イベントの発生時刻とイベントごとにユニークな識別子とからなる時間情報をそれぞれに付与して管理するデータベースから、少なくとも一部のイベントデータを取得するためのシステムにおける制御方法であって、
   指定された時刻と識別子とを含む情報を第１パラメータとして設定する第１設定工程と、
   現在時刻から既定の時間を差し引いた時間情報を第２パラメータとして設定する第２設定工程と、
   前記データベースから、前記第１パラメータ及び前記第２パラメータを用いて特定されたイベントデータを取得する取得工程と、
   を有することを特徴とする制御方法。
2. 前記取得工程では、前記第１パラメータと前記第２パラメータとで特定される期間に含まれる時間情報を有するイベントデータを、前記データベースから取得することを特徴とする請求項１に記載の制御方法。
3. 前記第１パラメータとして設定される前記時刻と識別子とを含む情報は、イベントデータの取得を要求する要求元から指定されるものであり、
   前記取得工程で取得されたイベントデータを、前記要求元に送信する送信工程を有することを特徴とする請求項１又は２に記載の制御方法。
4. 前記要求元から指定される前記時刻と識別子とを含む情報は、前記要求元で取得済みのイベントデータの最新の時間情報に対応することを特徴とする請求項３に記載の制御方法。
5. 前記既定の時間は、前記イベントデータをデータベースに格納する処理のタイムアウト時間以上の時間であることを特徴とする請求項１〜４のいずれか１項に記載の制御方法。
6. コンピュータに、請求項１〜５のいずれか１項に記載の制御方法を実行させるためのプログラム。
7. ネットワークデバイスで発生したイベントのそれぞれに係るイベントデータを管理するためのデータベースから、少なくとも一部のログを取得するためのシステムであって、
   ネットワークデバイスから受信したイベントデータに、イベントの発生時刻とイベントごとにユニークな識別子とからなる時間情報を付与する付与手段と、
   前記時間情報が付与されたイベントデータを前記データベースに格納する格納手段と、
   指定された時刻と識別子とを含む情報を第１パラメータとして設定する第１設定手段と、
   現在時刻から既定の時間を差し引いた時間情報を第２パラメータとして設定する第２設定手段と、
   前記データベースから、第１パラメータ及び第２パラメータを用いて特定されたイベントデータを取得する取得手段と、
   を有することを特徴とするシステム。
8. 前記取得手段は、前記第１パラメータと前記第２パラメータとで特定される期間に含まれる時間情報を有するイベントデータを、前記データベースから取得することを特徴とする請求項７に記載のシステム。
9. 前記第１パラメータとして設定される前記時刻と識別子とを含む情報は、イベントデータの取得を要求する要求元から指定されるものであり、
   前記取得手段で取得されたイベントデータを、前記要求元に送信する送信手段を有することを特徴とする請求項７又は８に記載のシステム。
10. 前記要求元から指定される前記時刻と識別子とを含む情報は、前記要求元で取得済みのイベントデータの最新の時間情報に対応することを特徴とする請求項９に記載のシステム。
11. 前記既定の時間は、前記イベントデータをデータベースに格納する処理のタイムアウト時間以上の時間であることを特徴とする請求項７〜１０のいずれか１項に記載のシステム。