(57)【要約】【課題】、実ファイルとファイル情報とを別個に保存する場合に、少ない負荷で実ファイルとファイル情報の不整合を抑制することができる情報処理システムを提供する。【解決手段】ファイル管理システムは、ファイルサーバ１１０、ファイル情報管理サーバ１２０、及びイベント情報管理サーバ１３０を備える。ファイルサーバ１１０は、実ファイルとメタ情報とを保存する。イベント情報管理サーバ１３０は、ファイルサーバ１１０に対する操作を検知し、該操作されたファイルに付随するメタ情報をファイルサーバ１１０から取得し、取得したメタ情報に基づき生成したファイル情報をファイル情報管理サーバ１２０に送信する制御を行う。【選択図】図１
2017045085.tif 000002
【特許請求の範囲】
【請求項１】
ファイルを保存する第１の保存手段と、
前記ファイルのファイル情報を保存する第２の保存手段と、
前記第１の保存手段に対する操作を検知し、該操作されたファイルに付随する情報を前記第１の保存手段から取得し、前記取得した情報に基づき生成した、前記ファイルに対応するファイル情報を第２の保存手段に送信する制御を行う制御手段と、を備える、
ことを特徴とする情報処理システム。
【請求項２】
前記制御手段は、前記第１の保存手段に対して少なくともファイルの新規保存、または更新が行われたことを検知する、
ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記制御手段は、
前記第１の保存手段を監視することで該第１の保存手段に対する操作を検知する監視手段と、
前記監視手段が検知した操作に応じた処理を実行するためのスクリプトを選択する選択手段と、
前記選択手段が選択したスクリプトを実行することで、前記ファイルと紐付くファイルのメタ情報を前記第１の保存手段から取得し、該取得したメタ情報に基づき前記ファイル情報を生成し、該生成したファイル情報を前記第２の保存手段に送信するスクリプト実行手段と、を備える、
ことを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記スクリプト実行手段は、前記第１の保存手段から取得したメタ情報に基づき該メタ情報と紐付く前記ファイルが不正であるか否かを判断し、
前記ファイルが不正であると判断した場合は、前記第１の保存手段から該ファイルを削除する、
ことを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記スクリプト実行手段が前記スクリプトの実行に失敗した場合に、前記スクリプトの処理を再度実行する再実行手段と、をさらに備える、
ことを特徴とする請求項３または４に記載の情報処理システム。
【請求項６】
クライアント装置から、前記第１の保存手段に新規保存または更新されるファイルと紐付くファイルのメタ情報を受信し、該メタ情報を加工したうえで前記第１の保存手段に送信する加工手段と、をさらに備え、
前記スクリプト実行手段は、前記加工が行われた情報を前記第１の保存手段から取得し、該取得した情報をファイル情報として前記第２の保存手段に送信する、
ことを特徴とする請求項３に記載の情報処理システム。
【請求項７】
ファイルを保存する第１の保存手段に対する操作を検知する検知手段と、
該操作されたファイルに付随する情報を前記第１の保存手段から取得し、前記取得した情報に基づき生成した、前記ファイルに対応するファイル情報を第２の保存手段に送信する制御を行う制御手段と、を備える
ことを特徴とする情報処理装置。
【請求項８】
ファイルを保存する第１の保存手段に対する操作を検知する工程と、
該操作されたファイルに付随する情報を前記第１の保存手段から取得し、前記取得した情報に基づき生成した、前記ファイルに対応するファイル情報を第２の保存手段に送信する制御を行う工程と、を有する
ことを特徴とする情報処理装置の制御方法。
【請求項９】
請求項８に記載の制御方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理システムの制御方法、及びプログラムに関する。
【背景技術】
【０００２】
特許文献１は、クライアントから文書データとサムネイルデータ受信し、ボリュームデータベースに保存する文書管理システムを開示している。また、特許文献１では、ボリュームデータベースに保存した文書データと、文書の属性情報及び検索用インデックスデータとを対応づけることを開示している。
【０００３】
特許文献２は、互いに独立した異なるクライアント・サーバシステムである電子ファイリングシステムと業務支援システムとの間でコンテンツを連携させるためのコンテンツ連携システムを開示している。特許文献２では、ＩＮＤＥＸ移行ツールにより、電子ファイリングサーバ上のデータベースに登録されているインデックスを業務支援システムの文書管理サーバのデータベース上に複製することが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−３１３４９１号公報
【特許文献２】特開２０００−０７６２６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ファイルの実体（実ファイル）と、ファイルに関する管理情報（ファイル情報）とを別個のサーバに保存するシステムが考えられる。ここで、クライアントが実ファイルとファイル情報とを登録する場合に、例えば、何らかの障害等によって、実ファイルは保存されたがそのファイル情報は登録されない、といった実ファイルとファイル情報の間でデータの不整合が発生することがある。
【０００６】
特許文献１では、文書データがクライアントからサーバに送信された後に、さらにボリュームデータベースに送信される。文書データのファイルサイズが大きい場合に、このようなデータの送受信を複数回行うことは、システム全体のパフォーマンスに大きな影響を及ぼす可能性がある。特に、ボリュームデータベースが、文書データの属性情報の管理を行うサーバとは別のサーバに設けられた場合には特に深刻である。
【０００７】
また、特許文献２では、複数の独立したシステムのそれぞれにおいてインデックスを保存している。このため、重複してインデックスを保存することになり、データベースが多く必要となってしまう。さらに、特許文献２では、電子ファイリングサーバに登録されているインデックスと文書管理サーバに登録されているインデックスとを比較した結果に基づいて移行対象のインデックスを特定するため、インデックスの移行処理に時間を要する。
【０００８】
本発明は、実ファイルとファイル情報とを別個に保存する場合に、少ない負荷で実ファイルとファイル情報の不整合を抑制することができる情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施形態の情報処理システムは、ファイルを保存する第１の保存手段と、前記ファイルのファイル情報を保存する第２の保存手段と、前記第１の保存手段に対する操作を検知し、該操作されたファイルと紐付く情報を前記第１の保存手段から取得し、前記取得した情報に基づき生成した、前記ファイルに対応するファイル情報を第２の保存手段に送信する制御を行う制御手段と、を備える。
【発明の効果】
【００１０】
本発明の情報処理システムによれば、実ファイルとファイル情報とを別個に保存する場合に、少ない負荷で実ファイルとファイル情報の不整合を抑制することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１実施形態に係るシステムの全体構成を示す図である。
【図２】第１実施形態に係るソフトウェア構成を示す図である。
【図３】第１実施形態に係るファイル情報登録処理を説明するシーケンス図である。
【図４】ファイルサーバへの操作を監視する処理を説明するフローチャートである。
【図５】スクリプト管理処理を説明するフローチャートである。
【図６】ファイル情報の登録処理を説明するフローチャートである。
【図７】第２実施形態に係るシステムの全体構成を示す図である。
【図８】第２実施形態に係るファイル情報登録処理を説明するシーケンス図である。
【図９】第３実施形態に係るシステムの全体構成を示す図である。
【図１０】第３実施形態に係るファイル情報登録処理を説明するシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
＜システム構成＞
本実施形態に係る情報処理システムの一例として、ファイル管理システムを例に説明する。
図１は、第１実施形態に係るシステムの全体構成を示す図である。
ファイル管理システムは、クライアントＰＣ１００、ファイルサーバ１１０、ファイル情報管理サーバ１２０、イベント情報管理サーバ１３０を備え、各々は、イーサネット（登録商標）などから成るＬＡＮ１４０に接続されている。
【００１３】
クライアントＰＣ１００は、実ファイルの保存、更新、登録、閲覧、削除等の機能を有するクライアントアプリケーションが動作する。ファイルサーバ１１０は、実ファイルの保管場所であり、クライアントＰＣ１００からの実ファイルの保存要求を受け付ける。ファイル情報管理サーバ１２０は、データベースとそれを制御する機能を備え、クライアントＰＣ１００がファイルサーバ１１０に保存したファイルに付随するファイルの名称、サイズ、作成日時、更新日時等の様々なファイル情報を管理する。
【００１４】
イベント情報管理サーバ１３０は、ファイルサーバ１１０の監視を行い、クライアントＰＣ１００が行ったファイルの保存、及び更新等、ファイルサーバ１１０に対する操作を検知する。また、操作を検知した際に、操作が行われた対象ファイルの保存先パス情報を取得し、イベント情報として生成する。そして、操作に対応する処理を実行するためのスクリプトにイベント情報を渡し、スクリプトを自動実行する機能を持つ。
【００１５】
＜ソフトウェア構成＞
図２は、ファイル管理システムのソフトウェア構成を示す図である。
クライアントＰＣ１００は、クライアントアプリケーション２００を備える。クライアントアプリケーション２００は、サービス通信部２０１、及び表示部２０２を含む。クライアントアプリケーション２００は、表示部２０２によりクライアントＰＣ１００の画面上にＵＩ（ユーザインターフェース）を表示させ、入力された内容に応じて、サービス通信部２０１によりファイルサーバ１１０と通信を行う。
【００１６】
サービス通信部２０１は、ファイルサーバ１１０に実ファイルの保存要求や更新要求を行う。また、本実施形態では、サービス通信部２０１は、実ファイルの保存要求と合わせて、ファイル情報をメタデータ形式に加工した上で送信する。表示部２０２は、クライアントＰＣ１００の画面上に、ファイルサーバへの実ファイルの保存結果や保存先の指定などを表示する。
【００１７】
ファイルサーバ１１０は、サービス通信部２１０、ストレージ管理部２１１、及びファイルストレージ領域２１２を備える。サービス通信部２１０は、クライアントＰＣ１００からの実ファイル保存要求に応じて送信された、実ファイル、及びファイル情報を含んだメタデータの保存を、ストレージ管理部２１１に要求する。また、サービス通信部２１０は、後述する登録イベントスクリプト２５１からのメタデータ取得要求に応じて、ストレージ管理部２１１にファイルの取得を要求する。ストレージ管理部２１１は、サービス通信部２１０からの実ファイルの保存要求や、メタデータ取得要求に応じて、ファイルストレージ領域２１２上のファイルの更新や取得を行う。ファイルストレージ領域２１２は、ファイルサーバ１１０のストレージ領域であり、実ファイル、及びそれに付随するメタデータが格納される。
【００１８】
ファイル情報管理サーバ１２０は、サービス通信部２２０、ファイル情報管理部２２１、及びファイル情報データベース２２２を備える。サービス通信部２２０は、後述する登録イベントスクリプト２５１からのファイル情報登録要求に応じて、ファイル情報管理部２２１にファイル情報の登録を要求する。ファイル情報管理部２２１は、サービス通信部２２０からのファイル情報の登録要求に応じて、ファイル情報データベース２２２のファイル情報を更新する。ファイル情報データベース２２２は、ファイルサーバ１１０に保存されている実ファイルのファイル情報を格納するデータベースである。
【００１９】
イベント情報管理サーバ１３０は、ファイルサーバ監視アプリケーション２３０、及びスクリプト管理アプリケーション２４０を備える。ファイルサーバ監視アプリケーション２３０は、サービス通信部２３１、及びファイル更新判断部２３２を含む。スクリプト管理アプリケーション２４０は、サービス通信部２４１、スクリプト管理部２４２、スクリプト２５０を含む。また、スクリプト２５０は、登録イベントスクリプト２５１、及び更新イベントスクリプト２５２から成る。
【００２０】
ファイルサーバ監視アプリケーション２３０のサービス通信部２３１は、ファイルサーバ１１０と通信を行い、ファイルサーバ１１０のファイル更新状況を取得し、通信結果をファイル更新判断部２３２に送信する。ファイルの更新（ファイルを新規に保存、または更新）があった場合、サービス通信部２３１は、ファイルの更新情報をイベント情報としてスクリプト管理アプリケーション２４０に送信する。
【００２１】
ファイル更新判断部２３２は、ファイルサーバ１１０のファイル更新状況からファイルが新規に保存されたか、またはファイルの更新が行われたか等の操作内容を判断する。ファイルの更新（ファイルを新規に保存、または更新）が行われたと判断した場合は、更新が行われたファイルの保存先情報と、操作内容とをイベント情報としてサービス通信部２３１に送信する。
【００２２】
スクリプト管理アプリケーション２４０のサービス通信部２４１は、ファイルサーバ監視アプリケーション２３０から送信されたイベント情報を受け、スクリプト管理部２４２にイベント情報に対応するスクリプトの実行を要求する。スクリプト管理部２４２は、イベント情報を受け、スクリプト２５０に存在するスクリプトの中から、イベント情報に含まれる操作内容に対応するスクリプトを実行する。例えば、クライアントＰＣ１００がファイルサーバ１１０に新規に実ファイルを保存した場合は、登録操作が行われたと判断し、登録イベントスクリプト２５１を実行する。また、クライアントＰＣ１００がファイルサーバ１１０に存在する実ファイルを上書き保存（更新）した場合は、更新操作が行われたと判断し、更新イベントスクリプト２５２を実行する。
【００２３】
登録イベントスクリプト２５１は、ファイルサーバ１１０に実ファイルが保存された場合に実行されるスクリプトである。登録イベントスクリプト２５１は、ファイルサーバ１１０に保存されたファイルに付随するメタデータからファイル情報を取得し、ファイル情報管理サーバ１２０に登録する。また、登録イベントスクリプト２５１は、このとき取得したメタデータに含まれるファイル情報に不足や不正な値が格納されていると判断した場合は、ファイルサーバ１１０に実ファイル、及びメタデータの削除要求を行う。更新イベントスクリプト２５２は、ファイルサーバ１１０の実ファイルが上書き保存（更新）された場合に実行されるスクリプトである。
【００２４】
＜ファイル情報登録処理シーケンス＞
図３は、ファイル情報登録処理を説明するシーケンス図である。
具体的には、実ファイルがファイルサーバに保存されてから、該ファイルに対応するファイル情報がファイル情報管理サーバに登録されるまでの処理を示す。
【００２５】
ステップＳ３００では、クライアントアプリケーション２００のサービス通信部２０１が実ファイル及びファイル情報を含むメタデータをファイルサーバ１１０に送信することで、ファイルの新規保存要求を行う。ステップＳ３０１では、ファイルサーバ１１０のサービス通信部２１０が実ファイルとファイル情報を含むメタデータを受信し、ストレージ管理部２１１がファイルストレージ領域２１２に実ファイルとメタデータとを関連付けて格納する。ステップＳ３０２では、ファイルサーバ１１０のサービス通信部２１０が、クライアントアプリケーション２００に実ファイル及びメタデータの新規保存が成功した旨を送信する。
【００２６】
ステップＳ３０３からステップＳ３０６では、ファイルサーバ監視アプリケーション２３０が、ファイルサーバ１１０にファイルが新規保存されたことを検知し、イベント情報を送信する処理を行う。この処理に関しては、図４のフローチャートを用いて説明する。
【００２７】
図４は、ファイルサーバ監視アプリケーションが、ファイルサーバに対する操作を検知する監視処理を説明するためのフローチャートである。
ステップＳ４００では、ファイルサーバ監視アプリケーション２３０のサービス通信部２３１が、ファイルサーバ１１０に新規保存、または上書き保存されたファイルが存在するかを差分のあったファイルの登録状況（差分ファイル登録状況）として取得する。
【００２８】
本実施形態では、ステップＳ３００でファイルが新規保存されているため、差分ファイル登録状況は、その旨がわかるようになっている。なお、本実施形態では、差分ファイル登録状況をファイルサーバ監視アプリケーション２３０が定期的に取得する方法をとっているが、手段は特に限定しないものとする。例えば、ファイルサーバ１１０にファイル保存操作が行われる度に、ファイルサーバ１１０がファイルサーバ監視アプリケーション２３０に差分ファイル登録状況を送信する方法でも良いものとする。
【００２９】
ステップＳ４０１では、ファイル更新判断部２３２が、差分ファイル登録状況を解析し、ファイルサーバ１１０に対してファイルの保存操作が行われたか否かを判断する。すなわち、ファイル更新判断部２３２は、差分ファイルが存在するか否かを判断する。ファイル更新判断部２３２が、ファイルの保存操作が行われたと判断した場合、すなわち、差分ファイルが存在すると判断した場合には、処理はステップＳ４０２に進む。ファイル更新判断部２３２が、ファイルの保存操作が行われていないと判断した場合は、以降の処理は行われず、処理は終了する。ステップＳ４０２とステップＳ４０８はループ端であり、全ての差分ファイルの確認が行われるまでステップＳ４０２からステップＳ４０８までの処理が繰り返される。
【００３０】
ステップＳ４０３では、ファイル更新判断部２３２が、差分ファイルに行われた操作が新規保存操作か否かを判断する。ファイル更新判断部２３２が、新規保存操作が行われたと判断した場合、処理はステップＳ４０４に進む。ファイル更新判断部２３２が、新規保存操作が行われていないと判断した場合、すなわち上書き保存操作が行われたと判断した場合、処理はステップＳ４０５に進む。なお、本実施形態では、ステップＳ３００において、ファイルが新規保存されているため、ステップＳ４０４に進む。
【００３１】
ステップＳ４０４では、ファイル更新判断部２３２が、登録イベント情報を作成する。ステップＳ４０６では、ファイル更新判断部２３２が、ステップＳ４０４またはステップＳ４０５で作成したイベント情報に差分ファイルの保存先パス情報を追加する。ステップＳ４０７では、サービス通信部２３１が、ステップＳ４０４からステップＳ４０６で作成されたイベント情報を、スクリプト管理アプリケーション２４０に送信する。ステップ４０８では、ループの終了判定が行われる。本実施形態では、差分ファイルは一つだけなので、ループはここで終了する。
【００３２】
以上のように、図４のフローチャートが実行されることによって、ファイルサーバ１１０にファイルが保存されたことを検知し、ファイルに対する操作内容と保存先パスをイベント情報としてスクリプト管理アプリケーション２４０に送信することができる。
【００３３】
図３の説明に戻る。図３のステップＳ３０７からステップＳ３０８では、スクリプト管理アプリケーション２４０が、受信したイベント情報を解析し、イベント情報に含まれる操作内容に対応するスクリプトを実行する。この処理に関しては、図５のフローチャートを用いて説明する。
【００３４】
図５は、スクリプト管理アプリケーションが、ファイルサーバ監視アプリケーションからイベント情報を受信し、イベント情報に応じたスクリプト実行を行うスクリプト管理処理を説明するためのフローチャートである。
ステップＳ５００では、スクリプト管理アプリケーション２４０のサービス通信部２４１が、ファイルサーバ監視アプリケーション２３０からイベント情報を受信する。
【００３５】
ステップＳ５０１では、スクリプト管理部２４２が、イベント情報を解析し、イベント情報に含まれる操作内容が登録であるか否かを判断する。スクリプト管理部２４２が、操作内容は登録であると判断した場合は、処理はステップＳ５０２に進む。また、スクリプト管理部２４２が、操作内容は登録でないと判断した場合は、処理はステップＳ５０３に進む。すなわち、スクリプト管理部２４２は、操作内容に応じた処理を実行するためのスクリプトを選択する。なお、本実施形態では、イベント情報に含まれる操作内容は登録であるため、ステップＳ５０２に進む。
【００３６】
ステップＳ５０２では、スクリプト管理部２４２が、登録イベントスクリプト２５１にイベント情報を送信し、スクリプトを実行する。本実施形態では、ここでスクリプト管理処理は終了する。一方、ステップＳ５０３では、スクリプト管理部２４２が、イベント情報に含まれる操作内容が更新であるか否かを判断する。スクリプト管理部２４２が、操作内容は更新であると判断した場合は、処理はステップＳ５０４に進む。スクリプト管理部２４２が、操作内容は更新でないと判断した場合は、処理を終了する。ステップＳ５０４では、スクリプト管理部２４２が、更新イベントスクリプト２５２にイベント情報を送信し、スクリプトを実行する。
【００３７】
以上のように、図５のフローチャートが実行されることによって、イベント情報に対応するスクリプト、すなわちファイルサーバに対する操作内容に応じた処理を実行することができる。
【００３８】
図３の説明に戻る。図３のステップＳ３０９からステップＳ３１４では、登録イベントスクリプト２５１が、ファイルサーバ１１０からメタデータを取得し、ファイル情報に変換し、ファイル情報管理サーバ１２０にファイル情報を登録する。この処理に関しては、図６のフローチャートを用いて説明する。
【００３９】
図６は、登録イベントスクリプトがファイル情報の登録を行う処理を説明するためのフローチャートである。
ステップＳ６００では、登録イベントスクリプト２５１が、スクリプト管理部２４２から登録イベント情報を取得する。ステップＳ６０１では、登録イベントスクリプト２５１が、登録イベント情報に含まれる保存先パスを取得し、処理対象ファイルであるか否かを判断する。処理対象ファイルであるか否かとは、例えば、保存先パスが特定のフォルダ以下である場合に、処理対象ファイルであるものとして処理を継続することが考えられる。ただし、これに限定するものではなく、任意の条件を設定できるものとする。
【００４０】
登録イベントスクリプト２５１が、処理対象ファイルであると判断した場合、処理はステップＳ６０２に進む。登録イベントスクリプト２５１が、処理対象ファイルでないと判断した場合、処理は終了する。なお、本実施形態では、ステップＳ６０１において、処理対象ファイルであると判断されたものとし、ステップＳ６０２に進む。
【００４１】
ステップＳ６０２では、登録イベントスクリプト２５１が、ファイルサーバ１１０から、イベント情報の保存先パスに対応するファイルのメタデータを取得し、ファイル情報に変換する。ステップＳ６０３では、登録イベントスクリプト２５１が、ステップＳ６０２で取得したファイル情報を解析し、ファイル情報の内容が正しいか否かを判断する。ファイル情報の内容が正しいか否かとは、例えば、ファイル情報が空である場合や、ファイル情報管理サーバ１２０で扱えない情報が記載されている場合、ファイル情報は正しくないと判断することが考えられる。ただし、これに限定するものではなく、任意の条件を設定できるものとする。
【００４２】
登録イベントスクリプト２５１が、ファイル情報が正しいと判断した場合、処理はステップＳ６０４に進む。登録イベントスクリプト２５１が、ファイル情報が正しくないと判断した場合、処理はステップＳ６０５に進む。なお、本実施形態では、ファイル情報は正しいと判断したものとし、処理はステップＳ６０４に進む。
【００４３】
ステップＳ６０４では、登録イベントスクリプト２５１が、ファイル情報管理サーバ１２０にファイル情報を送信し、ファイル情報の登録が行われるように制御する。一方、ステップＳ６０５では、ステップＳ６０３において不正なファイル情報であると判断したことを受けて、登録イベントスクリプトは、ファイルサーバ１１０と通信し、当該ファイル情報を削除する。ステップＳ６０６では、登録イベントスクリプト２５１が、ファイルサーバ１１０と通信し、当該実ファイルを削除するように制御する。
【００４４】
以上のように、図３〜図６の処理が実行されることによって、ファイルサーバ１１０にファイルが新規保存された場合に、即時的にファイル情報管理サーバ１２０にファイル情報の登録が行われる。また、ファイルサーバ１１０に不正なファイル情報が作成されたことを検知し、不正なファイル情報をファイル情報管理サーバ１２０に登録することを抑制すると同時に、不正なファイルをファイルサーバ１１０から削除することが可能となる。
【００４５】
なお、本実施形態では、ファイルサーバにファイルが新規保存された場合を例に説明したが、ファイルが上書き保存（更新）された場合についても同様に、ファイル情報管理サーバ１２０に保存されたファイル情報が即時的に更新される。具体的には、ファイルサーバ１１０においてファイルが上書き保存されたことがファイルサーバ監視アプリケーション２３０により検知され、図３〜図６の各処理において、上述したように操作内容が更新であった場合の処理が実行される。
【００４６】
以上のように、本実施形態によれば、実ファイルとファイル情報とを別個に保存する場合に、実ファイルが保存されたことを契機に、即時的にファイル情報の保存を行うことが可能となり、少ない負荷で実ファイルとファイル情報の不整合を抑制することができる。また、不正なファイルが登録されたことを検知することができるため、不正なファイルの登録をも抑制することが可能となる。
【００４７】
（第２実施形態）
次に、本発明の第２実施形態に係る情報処理システムについて説明する。第１実施形態では、ファイル情報の登録処理をスクリプトにより実行する形態について説明した。これに対して、本実施形態では、スクリプトによる実行が失敗した場合に、処理の移管先を用意することにより、スクリプトと同等の処理を再度実行することが可能となる。
【００４８】
本実施形態では、登録イベントスクリプト２５１がファイル情報の登録処理に失敗した場合に、登録イベントスクリプト２５１と同様の機能をもつキューに処理を移管する形態を提供する。例えば、スクリプト管理アプリケーション２４０がスクリプトの稼働時間を一定に定めているような場合に、ファイル情報の登録処理が失敗したことを受けて再実行を行う際に、時間切れとなる可能性がある。本実施形態では、このような場合を想定し、スクリプト管理アプリケーション２４０が登録処理に失敗した場合に、再実行処理をキューサービスサーバのキューに行わせることができる。
【００４９】
＜システム構成＞
図７は、第２実施形態に係るシステムの全体構成を示す図である。
なお、クライアントＰＣ１００、ファイルサーバ１１０、ファイル情報管理サーバ１２０、イベント情報管理サーバ１３０、及びＬＡＮ１４０は、図１と同一の構成のため、その説明は省略する。
【００５０】
キューサービスサーバ７００は、特定のプログラムをキューとして実行できる機能を持つサーバである。なお、第２実施形態においては、登録イベントスクリプト２５１と同様の機能をもつキューを実行できるものとする。なお、本実施形態では、スクリプトの実行を移管する装置として、キューサービスサーバを例に説明するが、これに限定されるものではない。例えば、イベント情報管理サーバと同様のソフトウェア構成をもつサーバであってもよく、スクリプトと同様の処理が実行できればよい。
【００５１】
＜ファイル情報登録処理シーケンス＞
図８は、第２実施形態に係るファイル情報の登録処理を説明するためのシーケンス図である。
ステップＳ８００からステップＳ８１２までの処理は、図３のステップＳ３００からステップＳ３１２と同様のため、説明は省略する。
【００５２】
ステップＳ８１３では、ファイル情報管理サーバ１２０が、アクセス集中などの理由により、ファイル情報を登録できず、メモリー不足エラーが発生したものとする。ステップＳ８１４では、ファイル情報管理サーバ１２０のサービス通信部２２０が、登録イベントスクリプト２５１にファイル情報の登録に失敗した旨を通知する。
【００５３】
ステップＳ８１５では、登録イベントスクリプト２５１が、ファイル情報の登録が失敗したことを受けて、キューサービスサーバ７００に登録イベント情報を送信し、ファイル情報を登録するキューの実行を要求する。キューサービスサーバ７００は、登録イベントスクリプト２５１からファイル情報の登録要求を受けて、ファイル情報を登録するキューを実行する。ファイル情報を登録するキューは、ステップＳ８１６から、ステップＳ８２０の処理を実行することにより、ファイル情報の登録を行う。なお、ステップＳ８１６からステップＳ８２０は、図３のステップＳ３０９からステップＳ３１４と同様の処理であるため、説明は省略する。
【００５４】
以上のように、本実施形態によれば、スクリプトが処理の途中で失敗したとしても、同様の機能をもつスクリプトに処理を移管できる。このため、例えば、スクリプトの実行時間に制限が設けられているような場合であっても、再実行処理による時間超過を発生させることを回避できる。
【００５５】
（第３実施形態）
次に、本発明の第３実施形態に係る情報処理システムについて説明する。第１実施形態では、ファイルサーバがクライアントアプリケーションから実ファイル及びファイル情報を含むメタ情報を保存する形態について説明した。これに対して、本実施形態では、ファイル情報を別個のサーバにおいて加工してからファイルサーバに保存することが可能となる。
【００５６】
本実施形態では、クライアントアプリケーション２００が、ファイル情報をファイル情報加工サーバに送信した上で、ファイル情報の登録を実現する形態を提供する。例えば、ファイル情報を別のサービスが受信し、タグ情報等を追加した上で、ファイル情報を登録したい場合が考えられる。本実施形態では、このような場合を想定し、クライアントＰＣが、ファイル情報を加工するサーバにファイル情報を送信した後に、ファイルサーバに実ファイルを保存する。
【００５７】
＜システム構成＞
図９は、第３実施形態に係るシステムの全体構成を示す図である。
なお、クライアントＰＣ１００、ファイルサーバ１１０、ファイル情報管理サーバ１２０、イベント情報管理サーバ１３０、及びＬＡＮ１４０は、図１と同一の構成のため、その説明は省略する。
【００５８】
ファイル情報加工サーバ９００は、クライアントＰＣ１００からファイル情報を受信し、ファイル情報にタグ情報を追記することによりファイル情報の加工を行う機能を有するサーバである。なお、タグ情報は、ファイルの集合を意味するグループ名や、ファイルを一意に識別するためのＩＤ等の情報を指定することができるものとする。
【００５９】
＜ファイル情報登録処理シーケンス＞
図１０は、第３実施形態に係るファイル情報の登録処理を説明するためのシーケンス図である。
ステップＳ１０００では、クライアントアプリケーション２００が、ファイル情報を含むメタデータをファイル情報加工サーバ９００に送信する。ステップＳ１００１では、ファイル情報加工サーバ９００が、ファイル情報を含むメタデータを受信し、特定のタグ情報をファイル情報に追記した上で、ファイルサーバ１１０に加工が行われたファイル情報を送信する。
【００６０】
なお、このとき実ファイルを示すファイルとファイル情報とを明示的に区別するため、ファイル情報加工サーバ９００は、ファイル情報の保存先パスを、ファイル情報を保存するためのフォルダ以下に格納するように要求する。また、実ファイルとファイル情報とを紐付けて保存するために、実ファイルの保存先情報のファイル名と同一となるようにファイル名を設定する。なお、ファイルの保存先については、これに限定されるものではなく、実ファイルに対応するファイル情報が登録イベントスクリプトにより後から取得できればよい。
【００６１】
ステップＳ１００２では、ファイルサーバ１１０が、ファイル情報を含むファイルを受信し、ファイルストレージ領域２１２に格納する。ステップＳ１００３では、ファイルサーバ１１０が、ファイル情報加工サーバ９００にファイル情報の保存が成功した旨を送信する。ステップＳ１００４では、ファイル情報加工サーバ９００が、クライアントアプリケーション２００にファイル情報の保存が成功した旨を送信する。
【００６２】
ステップＳ１００５では、クライアントアプリケーション２００が、実ファイルをファイルサーバ１１０に送信する。ステップＳ１００６では、ファイルサーバ１１０が、実ファイルを受信し、ファイルストレージ領域２１２に格納する。このとき、ステップＳ１００２でファイル情報を保存した保存先とは別の保存先に実ファイルが格納される。
【００６３】
ステップＳ１００７からステップＳ１０１４は、図３のステップＳ３０２からステップＳ３０９と同様の処理であるため、説明は省略する。
ステップＳ１０１５では、登録イベントスクリプト２５１が、ステップＳ１００２で保存されたファイル情報を取得する。このとき、実ファイルの保存先情報のファイル名と同一のファイル名を有するファイルをファイル情報格納先フォルダから検索し、ファイル情報を取得する。
ステップＳ１０１６からステップＳ１０１９は、図３のステップＳ３１１からステップＳ３１４と同様の処理であるため、説明は省略する。
【００６４】
以上のように、本実施形態によれば、ファイル情報を加工した上で保存した場合であっても、実ファイルが保存されたことを契機に、即時的にファイル情報の保存を行うことが可能となる。
【００６５】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６６】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【符号の説明】
【００６７】
１１０    ファイルサーバ
１２０    ファイル情報管理サーバ
１３０    イベント情報管理サーバ
２３０    ファイルサーバ監視アプリケーション
２５０    スクリプト
【図１】
2017045085.tif 000003
【図２】
2017045085.tif 000004
【図３】
2017045085.tif 000005
【図４】
2017045085.tif 000006
【図５】
2017045085.tif 000007
【図６】
2017045085.tif 000008
【図７】
2017045085.tif 000009
【図８】
2017045085.tif 000010
【図９】
2017045085.tif 000011
【図１０】
2017045085.tif 000012