(57)【要約】【課題】  障害が発生し、文書管理サーバがフェールオーバし場合に、文書管理システムの実質的なダウンタイムを最小限にすることを可能とした文書管理サーバ、文書管理システム、及び、文書管理プログラムとその記録媒体を提供する。【解決手段】  クライアント４〜６からの処理要求に基づいて文書管理処理を実行し、文書管理サーバ１に障害が発生した場合、文書管理処理を、待機中の文書管理サーバ２に引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバ１において、文書管理サーバ１に障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、障害発生時に文書管理サーバ１に接続していたクライアントに対して、再接続をさせるためのコールバックメッセージを送信するメッセージ送信手段を設ける。【選択図】  図１
2007058506.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの処理要求に基づいて文書管理処理を実行し、文書管理サーバに障害が発生した場合、前記文書管理処理を、待機中の文書管理サーバに引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバであって、
前記文書管理サーバに障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、前記障害発生時に前記文書管理サーバに接続していたクライアントに対して、再接続をさせるためのコールバックメッセージを送信するメッセージ送信手段を備えたことを特徴とする文書管理サーバ。
【請求項２】
前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を受信するメッセージ受信手段と、前記受信した処理要求に基づいて、文書管理データベースにアクセスして文書管理処理を実行する文書管理手段と、該文書管理サーバに障害が発生した場合、前記文書管理処理を、他の文書管理サーバに引き継ぐクラスタリング処理を実行、管理するクラスタリング管理手段と、前記クラスタリング管理手段に対して、フェールオーバが完了したか否かのシステム情報をポーリングするクラスタリング状態監視手段と、前記文書管理サーバに接続してきたクライアントを管理するための接続クライアント情報を記憶する接続ユーザリストと、前記接続ユーザリストを用いて該サーバに接続してきたクライアントを監視する接続ユーザ監視手段と、を具備し、
前記クラスタリング状態監視手段がフェールオーバ完了と判断した場合に、前記接続ユーザ監視手段は、前記接続ユーザリストから、前記文書管理サーバの障害発生時に該サーバに接続していたクライアントを検出し、前記メッセージ送信手段は、該検出したクライアントに対して、再接続をさせるためのコールバックメッセージを送信することを特徴とする請求項１記載の文書管理サーバ。
【請求項３】
前記接続クライアント情報は、クライアントの識別情報であるクライアント名と、クライアントを操作しているユーザ名を有することを特徴とする請求項２記載の文書管理サーバ。
【請求項４】
前記接続クライアント情報は、前記クライアントからの処理要求が完了したかどうかを示すステータス情報を有し、前記接続ユーザ監視手段は、前記接続ユーザリストから、前記文書管理サーバの障害発生時に該サーバに接続していたクライアントであって、前記ステータス情報が未完了となっているクライアントを検出することを特徴とする請求項２又は３に記載の文書管理サーバ。
【請求項５】
前記メッセージ送信手段が作成するメッセージは、“処理再実行”の旨のメッセージを更に含むものであることを特徴とする請求項４記載の文書管理サーバ。
【請求項６】
クライアントからの処理要求に基づいて文書管理処理を実行し、文書管理サーバに障害が発生した場合、前記文書管理処理を、待機中の文書管理サーバに引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバであって、
前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を特定するための、処理内容及びその処理を実行するためのパラメータを、時系列的に記憶したトランザクションログと、該トランザクションログを監視して所定の処理を実行するトランザクション監視手段と、を具備し、
前記文書管理サーバに障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、前記トランザクション監視手段が、前記トランザクションログに記載されているステータス情報が未完了となっている処理を、前記待機中の文書管理サーバに実行させることを特徴とする文書管理サーバ。
【請求項７】
前記トランザクション監視手段が、前記トランザクションログに記載されているステータス情報が未完了となっている処理を、前記待機中の文書管理サーバに実行させることに失敗した場合に、該実行に失敗した処理を発行したクライアント、及び、前記トランザクションログにおいて、前記実行に失敗した処理以降の処理を発行したクライアントに対して、要求処理のリトライをさせるためのコールバックメッセージを送信するメッセージ送信手段を備えたことを特徴とする請求項６記載の文書管理サーバ。
【請求項８】
前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を受信するメッセージ受信手段と、前記受信した処理要求に基づいて、文書管理データベースにアクセスして文書管理処理を実行する文書管理手段と、該文書管理サーバに障害が発生した場合、前記文書管理処理を、他の文書管理サーバに引き継ぐクラスタリング処理を実行、管理するクラスタリング管理手段と、前記クラスタリング管理手段に対して、フェールオーバが完了したか否かのシステム情報をポーリングするクラスタリング状態監視手段と、前記文書管理サーバに接続してきたクライアントを管理するための接続クライアント情報を記憶する接続ユーザリストと、前記接続ユーザリストを用いて該サーバに接続してきたクライアントを監視する接続ユーザ監視手段と、を備えたことを特徴とする請求項６又は７記載の文書管理サーバ。
【請求項９】
前記接続クライアント情報は、クライアントの識別情報であるクライアント名と、クライアントを操作しているユーザ名と、前記クライアントからの処理要求が完了したかどうかを示すステータス情報を有することを特徴とする請求項８記載の文書管理サーバ。
【請求項１０】
コンピュータに、請求項１から９のいずれか１項に記載の文書管理サーバの機能を実現させるための文書管理プログラム。
【請求項１１】
請求項１０記載の文書管理プログラムを記録したことを特徴とする記録媒体。
【請求項１２】
ネットワークを介してそれぞれが接続される、請求項１から９のいずれか１項に記載の文書管理サーバと、前記文書管理サーバに障害が発生した場合に、前記文書管理サーバが実行すべき文書管理処理を引き継ぐために待機している文書管理サーバと、文書管理データベースと、文書管理処理を要求するクライアントとを備えたことを特徴とする文書管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理サーバ、文書管理システム、及び、文書管理プログラムとその記録媒体に関する。
【背景技術】
【０００２】
エンタープライズ規模の文書管理システムにおいて、文書管理システムのダウンタイムが問題となる場合がある。例えば文書管理システムを基幹系システムで使用している場合、文書管理システムがダウンすることで、それを利用した基幹業務が続行できないという致命的な問題がある。
【０００３】
システムのダウンタイムを短縮するためにはシステムの可用性が求められ、その解決策の一つがフェールオーバ(Fail Over)型クラスタリング技術である。フェールオーバ型クラスタリング技術を用いれば、文書管理システムを複数台のサーバマシンで構成し、そのうちの1台（稼動系）で通常は文書管理システムを稼動させ、障害が発生した場合に、待機系サーバに文書管理処理を引き継ぐことができる。これにより、文書管理システムのダウンタイムを短縮することが可能となる。
【０００４】
従来のクラスタリング型文書管理システムについて、具体的に、図１２を用いて以下に説明する。図１２は、従来のクラスタリング型文書管理システムの概略構成図である。図１２に示すように、従来のクラスタリング型文書管理システムは、文書管理サーバ１、文書管理サーバ２、文書管理データベース３、及び、クライアント４〜６を備えている。通常は、文書管理サーバ１において、文書管理サーバ業務が実行されている。
【０００５】
ここで、文書管理サーバ１に障害が発生した場合、従来のクラスタリング型文書管理システムでは、自律的に文書管理サーバ２（待機系ノード）に業務を引き継ぐ（フェールオーバする）。しかし、クライアント４〜６は、フェールオーバ後に、その接続セッションで操作を要求した段階で文書管理サーバ１の障害を検知する。その後、再度クライアント４〜６は、文書管理サーバ２の文書管理サーバ業務に再接続することにより、文書管理処理を継続して実施することになる。
【０００６】
また、特許文献１では、文書管理システムが異常終了したときの復旧を自動的に行う技術が開示されている。特許文献２では、システム側の改変や環境変化等で電子文書ファイルが開けない事態が生じることを防止し、電子原本の見読性を確保することが可能な電子文書管理システム、プログラム、電子文書管理方法に関する技術が開示されている。
【特許文献１】特開２００３−２８０９６３号公報
【特許文献２】特開２００４−１９２２０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上述した様なフェールオーバ型クラスタリング技術を備えた文書管理システムでは、文書管理サーバに接続したクライアントは、障害が発生した次の処理要求を文書管理サーバに発行した時点で、はじめて文書管理サーバに障害が発生したことを認識する。その後、クライアントは文書管理サーバに再接続処理をすることにより、文書管理操作を継続して実行することになるが、一般的には再接続の指示は、システム管理者によるメール通知など運用に委ねられている部分が多い。つまり、障害が発生した文書管理サーバに対して再接続をするタイミングが早すぎると、文書管理サーバ業務のフェールオーバ中でエラーとなり、遅すぎると、業務が遅延するため問題となっていた。
【０００８】
本発明は、上記のような問題点に鑑み、障害が発生し、文書管理サーバがフェールオーバし、クライアントからの処理要求を受け付ける状態になった時点で、クライアントに再接続をさせるためのコールバックメッセージを送信することにより、クライアントからの操作を含めた文書管理システムの実質的なダウンタイムを最小限にすることを可能とした文書管理サーバ、文書管理システム、及び、文書管理プログラムとその記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００９】
請求項１記載の発明は、クライアントからの処理要求に基づいて文書管理処理を実行し、文書管理サーバに障害が発生した場合、前記文書管理処理を、待機中の文書管理サーバに引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバであって、前記文書管理サーバに障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、前記障害発生時に前記文書管理サーバに接続していたクライアントに対して、再接続をさせるためのコールバックメッセージを送信するメッセージ送信手段を備えた文書管理サーバとしたことを特徴とする。
【００１０】
請求項２記載の発明は、前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を受信するメッセージ受信手段と、前記受信した処理要求に基づいて、文書管理データベースにアクセスして文書管理処理を実行する文書管理手段と、該文書管理サーバに障害が発生した場合、前記文書管理処理を、他の文書管理サーバに引き継ぐクラスタリング処理を実行、管理するクラスタリング管理手段と、前記クラスタリング管理手段に対して、フェールオーバが完了したか否かのシステム情報をポーリングするクラスタリング状態監視手段と、前記文書管理サーバに接続してきたクライアントを管理するための接続クライアント情報を記憶する接続ユーザリストと、前記接続ユーザリストを用いて該サーバに接続してきたクライアントを監視する接続ユーザ監視手段と、を具備し、前記クラスタリング状態監視手段がフェールオーバ完了と判断した場合に、前記接続ユーザ監視手段は、前記接続ユーザリストから、前記文書管理サーバの障害発生時に該サーバに接続していたクライアントを検出し、前記メッセージ送信手段は、該検出したクライアントに対して、再接続をさせるためのコールバックメッセージを送信する請求項１記載の文書管理サーバとしたことを特徴とする。
【００１１】
請求項３記載の発明は、前記接続クライアント情報は、クライアントの識別情報であるクライアント名と、クライアントを操作しているユーザ名を有する請求項２記載の文書管理サーバとしたことを特徴とする。
【００１２】
請求項４記載の発明は、前記接続クライアント情報は、前記クライアントからの処理要求が完了したかどうかを示すステータス情報を有し、前記接続ユーザ監視手段は、前記接続ユーザリストから、前記文書管理サーバの障害発生時に該サーバに接続していたクライアントであって、前記ステータス情報が未完了となっているクライアントを検出する請求項２又は３に記載の文書管理サーバとしたことを特徴とする。
【００１３】
請求項５記載の発明は、前記メッセージ送信手段が作成するメッセージは、“処理再実行”の旨のメッセージを更に含む請求項４記載の文書管理サーバとしたことを特徴とする。
【００１４】
請求項６記載の発明は、クライアントからの処理要求に基づいて文書管理処理を実行し、文書管理サーバに障害が発生した場合、前記文書管理処理を、待機中の文書管理サーバに引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバであって、前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を特定するための、処理内容及びその処理を実行するためのパラメータを、時系列的に記憶したトランザクションログと、該トランザクションログを監視して所定の処理を実行するトランザクション監視手段と、を具備し、前記文書管理サーバに障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、前記トランザクション監視手段が、前記トランザクションログに記載されているステータス情報が未完了となっている処理を、前記待機中の文書管理サーバに実行させる文書管理サーバとしたことを特徴とする。
【００１５】
請求項７記載の発明は、前記トランザクション監視手段が、前記トランザクションログに記載されているステータス情報が未完了となっている処理を、前記待機中の文書管理サーバに実行させることに失敗した場合に、該実行に失敗した処理を発行したクライアント、及び、前記トランザクションログにおいて、前記実行に失敗した処理以降の処理を発行したクライアントに対して、要求処理のリトライをさせるためのコールバックメッセージを送信するメッセージ送信手段を備えた請求項６記載の文書管理サーバとしたことを特徴とする。
【００１６】
請求項８記載の発明は、前記文書管理サーバは、前記文書管理サーバに接続してきたクライアントからの処理要求を受信するメッセージ受信手段と、前記受信した処理要求に基づいて、文書管理データベースにアクセスして文書管理処理を実行する文書管理手段と、該文書管理サーバに障害が発生した場合、前記文書管理処理を、他の文書管理サーバに引き継ぐクラスタリング処理を実行、管理するクラスタリング管理手段と、前記クラスタリング管理手段に対して、フェールオーバが完了したか否かのシステム情報をポーリングするクラスタリング状態監視手段と、前記文書管理サーバに接続してきたクライアントを管理するための接続クライアント情報を記憶する接続ユーザリストと、前記接続ユーザリストを用いて該サーバに接続してきたクライアントを監視する接続ユーザ監視手段と、を備えた請求項６又は７記載の文書管理サーバとしたことを特徴とする。
【００１７】
請求項９記載の発明は、前記接続クライアント情報は、クライアントの識別情報であるクライアント名と、クライアントを操作しているユーザ名と、前記クライアントからの処理要求が完了したかどうかを示すステータス情報を有する請求項８記載の文書管理サーバとしたことを特徴とする。
【００１８】
請求項１０記載の発明は、コンピュータに、請求項１から９のいずれか１項に記載の文書管理サーバの機能を実現させるための文書管理プログラムとしたことを特徴とする。
【００１９】
請求項１１記載の発明は、請求項１０記載の文書管理プログラムを記録したことを特徴とする記録媒体としたことを特徴とする。
【００２０】
請求項１２記載の発明は、ネットワークを介してそれぞれが接続される、請求項１から９のいずれか１項に記載の文書管理サーバと、前記文書管理サーバに障害が発生した場合に、前記文書管理サーバが実行すべき文書管理処理を引き継ぐために待機している文書管理サーバと、文書管理データベースと、文書管理処理を要求するクライアントとを備えた文書管理システムとしたことを特徴とする。
【発明の効果】
【００２１】
本発明によれば、障害が発生し、文書管理サーバがフェールオーバし、クライアントからの処理要求を受け付ける状態になった時点で、クライアントに“再接続可能”というコールバックメッセージを通知することにより、クライアントからの操作を含めた文書管理システムの実質的なダウンタイムを最小限にすることを可能とした文書管理サーバ、文書管理システム、及び、文書管理プログラムとその記録媒体を実現することができる。
【発明を実施するための最良の形態】
【００２２】
本発明を実施するための最良の形態は、クライアントからの処理要求に基づいて文書管理処理を実行し、文書管理サーバに障害が発生した場合、文書管理処理を、待機中の文書管理サーバに引き継ぐフェールオーバ型クラスタリング機能を備えた文書管理サーバにおいて、文書管理サーバに障害が発生し、クラスタリング処理が実行されてフェールオーバが完了した場合に、障害発生時に文書管理サーバに接続していたクライアントに対して、再接続をさせるためのコールバックメッセージを送信するメッセージ送信手段を設ける。
【００２３】
以下に、本発明の好適な実施形態を添付図面に基づいて詳細に説明する。尚、以下に述べる実施形態は本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの実施形態に限られるものではない。
【００２４】
（実施形態１）
本実施形態の文書管理システムでは、文書管理サーバに障害が発生した際に、文書管理サーバにおいて、文書管理サーバ業務にアクセスしていたクライアントを記録しておき、文書管理サーバ業務が待機系サーバにフェールオーバし、クライアントからの接続が可能な状態になった場合、障害発生時に本システムに接続していたクライアントに「フェールオーバの完了と、再接続が可能なことをメッセージの内容としたコールバックメッセージを送信する機能を設けたことを特徴とする。
【００２５】
まず、本実施形態の文書管理システムの概略構成と各部の機能について、図１を用いて以下に説明する。図１は、本実施形態の文書管理システムの概略構成図である。図１に示すように、本実施形態の文書管理システムは、文書管理サーバ１、２、文書データを格納する文書管理データベース３、及び、クライアント４〜６を備えている。
【００２６】
文書管理サーバ１は、クラスタリング状態監視処理部７、メッセージ送受信処理部８、接続ユーザ監視処理部９、接続ユーザリスト１０、文書管理処理部１１、及び、クラスタリング管理処理部１２を備えている。尚、本実施形態の文書管理サーバ１は、パソコンサーバ（ＰＣサーバ）に限られるものではなく、例えば、本実施形態の文書管理サーバ１が備えるフォールオーバクラスタリング方式を有する機能を内部に実装したＭＦＰ（Multi Functional Peripheral）等であってもよい。
【００２７】
クラスタリング状態監視処理部７は、フェールオーバ発生等のシステム情報をポーリングする機能を有する。メッセージ送受信処理部８は、クライアントからの要求メッセージを送受信する機能を有する。接続ユーザ監視処理部９は、文書管理サーバ１にアクセスしてきたクライアントを監視する機能を有する。接続ユーザリスト１０は、アクセス中のクライアントを管理するための接続クライアント情報を記憶する機能を有する。文書管理処理部１１は、文書管理操作を実施する機能を有する。クラスタリング管理処理部１２は、クラスタリング処理を実行、管理する機能を有する。
【００２８】
次に、接続ユーザリスト１０について、主に図２を用いて以下に説明する。図２は、本実施形態の接続ユーザリスト１０を示した図である。図２に示すように、接続ユーザリスト１０は、図１に示すクライアント４〜６の位置情報（マシン名、ＩＰアドレス等）を示すクライアント名と、それぞれのクライアントで操作しているユーザを示す接続ユーザ名から構成される。
【００２９】
次に、本実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明する。図３は、本実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明するためのフローチャートである。
【００３０】
まず、図３に示すように、例えば、図１に示すクライアント４が、文書管理サーバ１の文書管理サーバ業務にアクセスすると、文書管理サーバ１は、クライアント４の処理要求を、図１に示すメッセージ送受信処理部８で受け付ける（ステップ１０１）。続いて、メッセージ送受信処理部８は、クライアント４からの処理要求の種別を判断し（ステップ１０２）、“接続開始要求”の場合、図１に示す接続ユーザ監視処理部９に処理を受け渡す（ステップ１０２YES→ステップ１０３）。
【００３１】
続いて、接続ユーザ監視処理部９は、図１に示す接続ユーザリスト１０にクライアント接続情報として、｛クライアントＡ、 Ａさん｝を記憶する（ステップ１０３）。
従って、クライアント４からの“接続開始要求”に対する処理後（ステップ１０３）、接続開始要求をしたクライアント４は、文書管理操作を実施することになる。
【００３２】
また、メッセージ送受信処理部８は、クライアント４からの処理要求の種別を判断し（ステップ１０２）、“接続開始要求”でなく、“接続終了要求”の場合は、図１に示す接続ユーザ監視処理部９に処理を受け渡し（ステップ１０２NO→ステップ１０４YES）、ユーザ監視処理部９は、上記“接続終了要求”をしているクライアント４に関するクライアント接続情報を接続ユーザリスト１０から削除する（ステップ１０５）。
【００３３】
また、メッセージ送受信処理部８は、クライアント４からの処理要求の種別を判断し（ステップ１０２）、“接続開始要求”でも、“接続終了要求”でもない他の処理要求の場合には、図１に示す文書管理処理部１１に処理を受け渡し、文書管理処理部１１は、クライアント４から要求されている処理（文書管理操作）を文書管理データベース３にアクセスすることにより実行する（ステップ１０２NO→ステップ１０４NO→ステップ１０６）。続いて、メッセージ送受信処理部８は、文書管理処理部１１で実行された結果から操作結果を作成し、クライアントに送信する（ステップ１０７）。
【００３４】
次に、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について図４を用いて説明する。図４は、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【００３５】
本説明では、本実施形態の文書管理システムにおいて、クライアント（ユーザ端末）が、文書管理サーバ１の稼動による文書管理サーバ業務にアクセスしている際、文書管理サーバ１で障害が発生し、文書管理サーバ２に文書管理サーバ業務がフェールオーバされる（引き継がれた）場合を想定する。
【００３６】
まず、図４に示すように、文書管理サーバ１のクラスタリング状態監視処理部７（図１参照。）は、クラスタリング管理処理部１２に対して定期的にポーリングを実行する（ステップ２０１→ステップ２０２NO→ステップ２０１の繰り返し）。
【００３７】
そして、クラスタリング状態監視処理部７が、文書管理サーバ１において何らかの障害が発生した場合において、クラスタリング管理処理部１２によりクラスタリング処理が実行され、文書管理サーバ１の稼動による文書管理サーバ業務を、文書管理サーバ２に引き継ぐフェールオーバが完了したと判断した場合は、接続ユーザ監視処理部９が、接続ユーザリスト１０に格納されているクライアントを検出する（ステップ２０２YES→ステップ２０３）。
【００３８】
尚、検出後は、接続ユーザリスト１０上の情報（データ）は全て削除される（ステップ２０３）。続いて、メッセージ送受信処理部８は、上述した、接続ユーザリスト１０から検出されたクライアント（フェールオーバ時に本システムに接続中だったクライアント）に対して、“再接続可能”メッセージ（コールバック通知）を作成して送信する（ステップ２０４）。
【００３９】
その後は、上述した“再接続可能”というメッセージ（コールバック通知）を受けたクライアント（図１に示すクライアント４〜６のうちコールバック通知を受けたクライアント）のユーザは、文書管理サーバ２に対して、再接続処理を実行することになる。
【００４０】
よって、本実施形態によれば、文書管理システムのフェールオーバ完了後、再度利用可能な状態になったことを、障害発生時に本システムに接続中だったクライアント全てにコールバック通知をすることで、その後の処理をクライアントに促すことにより、文書管理システムのクライアント操作を含めた、障害によるダウンタイムを最小限にすることができるという効果を得ることができる。
【００４１】
（実施形態２）
本実施形態は、実施形態１の応用例である。よって、共通する部分は説明を省略し、特徴的部分を中心に、本実施形態の文書管理システムについて添付図面を用いて以下に説明する。ところで、実施形態１では、文書管理サーバがフェールオーバした際、接続中だった全てのクライアントに対して、フェールオーバ完了後に、“再接続可能”というコールバックメッセージを送信していた。
【００４２】
しかし、クライアントによっては、処理要求は完了し、文書管理サーバとの接続だけが残っているという状況もある。このようなクライアントに対して“再接続可能”というコールバックメッセージを送ったとしても、それを受信して即座に文書管理サーバに再接続するということはない。このようなコールバックメッセージは、不要なものであり、ネットワーク負荷を上げることになる。また、クライアントの運用が煩雑になる。本実施形態は、このような問題に着目し、その解決策を提案するものである。
【００４３】
本実施形態では、図２に示した接続ユーザリスト１０に、処理要求が完了したかどうかを示す“ステータス”情報を追加し、文書管理サーバがフェールオーバした際、接続中だったクライアントのうち、ステータスが“未完了”だったクライアントのみに対して、フェールオーバ完了後、“再接続可能”というコールバックメッセージを送信することを特徴とする、
【００４４】
図５に、本実施形態の接続ユーザリスト１０を示す。図５に示すように、本実施形態の接続ユーザリスト１０は、図２で示した、実施形態１における接続ユーザリスト１０に対して、フェールオーバ時の文書管理操作の完了/未完了を示すステータス情報を追加したものである。
【００４５】
次に、本実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明する。図６は、本実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明するためのフローチャートである。
【００４６】
まず、図６に示すように、例えば、クライアント４が、文書管理サーバ１の文書管理サーバ業務にアクセスすると、文書管理サーバ１は、クライアント４の処理要求を、図１に示すメッセージ送受信処理部８で受け付ける（ステップ３０１）。続いて、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ３０２）、“接続開始要求”の場合、図１に示す接続ユーザ監視処理部９に処理を受け渡す（ステップ３０２YES→ステップ３０３）。
【００４７】
続いて、接続ユーザ監視処理部９は、図１に示す接続ユーザリスト１０にクライアント接続情報として、接続クライアント名、接続ユーザを記憶する（ステップ３０３）。
従って、クライアント４の“接続開始要求”に対する処理後（ステップ３０３）、クライアント４は、文書管理操作を実施することになる。
【００４８】
また、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ３０２）、“接続開始要求”でなく、“接続終了要求”の場合は、図１に示す接続ユーザ監視処理部９に処理を受け渡し（ステップ３０２NO→ステップ３０４YES）、ユーザ監視処理部９は、上記“接続終了要求”をしているクライアントに関するクライアント接続情報を接続ユーザリスト１０から削除する（ステップ３０５）。
【００４９】
また、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ３０２）、“接続開始要求”でも、“接続終了要求”でもない他の処理要求の場合には、図１に示す接続ユーザ監視処理部９が、接続ユーザリスト１０から接続クライアント（ここでは、クライアント４）のステータスを“未完了”とする（ステップ３０６）。そして、文書管理処理部１１は、クライアント４から要求されている処理（文書管理操作）を文書管理データベース３にアクセスすることにより実行する（ステップ３０７）。
【００５０】
続いて、メッセージ送受信処理部８は、文書管理処理部１１で実行された結果から、操作の結果作成し、クライアント４に送信する（ステップ３０８）。そして、接続ユーザ監視処理部９は、接続ユーザリスト１０から接続クライアントのステータスを“処理完了”とする（ステップ３０９）。
【００５１】
尚、上記、ステップ３０７、３０８において、障害が発生した場合、ステップ３０７、３０８の処理を破棄するか、その処理によって文書管理データベース３に与えた更新をロールバックするのが一般的であるが、これについては本実施形態では規定しない。図６に示すフローチャートでは、適切なロールバック処理等のエラー処理を実施し、クライアントアクセスを終了するものとする。
【００５２】
以上説明したように、本実施形態の文書管理システムによれば、接続ユーザ監視処理部９は、例えば、クライアント４からの操作要求がされた場合、まず、図５に示す接続ユーザリスト１０に記憶されたクライアント４のレコードを特定し、そのステータスフィールドに、これから要求された文書管理処理を開始するという意味で“未完了”と記憶する。
【００５３】
その後は、文書管理処理部１１が実際の文書管理処理を実行し、その結果をメッセージ送受信処理部８がクライアント４に返す。その後、接続ユーザリスト監視処理部９が、現在処理したクライアント４からの処理要求が完了したことを示すため、そのステータスフィールドに、“処理完了”と記憶する。また、クライアント５、６についても同様な処理をする。
【００５４】
次に、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について図７を用いて説明する。図７は、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【００５５】
本説明では、クライアント５、６の処理要求に応じて、文書管理処理部１１が文書管理操作を処理中に、文書管理サーバ１に障害が発生し、その後に、文書管理サーバ１から、文書管理サーバ２に文書管理サーバ業務がフェールオーバされる（引き継がれた）場合を想定する。
【００５６】
まず、図７に示すように、文書管理サーバ１のクラスタリング状態監視処理部７（図１参照。）は、クラスタリング管理処理部１２に対して定期的にポーリングを実行する（ステップ４０１→ステップ４０２NO→ステップ４０１の繰り返し）。
【００５７】
そして、クラスタリング状態監視処理部７が、文書管理サーバ１において何らかの障害が発生した場合において、クラスタリング管理処理部１２によりクラスタリング処理が実行され、文書管理サーバ１の稼動による文書管理サーバ業務を、文書管理サーバ２に引き継ぐフェールオーバが完了したと判断した場合は、接続ユーザ監視処理部９は、接続ユーザリスト１０に格納されているクライアントを検出する（ステップ４０２YES→ステップ４０３）。
【００５８】
ここで、検出されるクライアントは、上述したステータス情報が未完了と設定されているクライアントであり、ここでは、クライアント５、６である。尚、検出後は、接続ユーザリスト１０上の情報（データ）は全て削除される（ステップ４０３）。
【００５９】
続いて、メッセージ送受信処理部８は、クライアント５、６（ステータス情報が未完了と設定されているクライアント）のみに対して、“再接続可能かつ事前処理を再実行せよ”のメッセージ（コールバック通知）を作成し、送信する（ステップ４０４）。
その後、上述したコールバック通知を受けたクライアント５、６のユーザは、メッセージに従い、文書管理サーバ２に対して再接続処理を実行し、障害発生時に要求した処理のリトライを試みることになる。
【００６０】
よって、本実施形態によれば、実施形態１で示した効果に加えて、文書管理システムのフェールオーバ完了後に再接続された場合に、未完了処理をリトライする必要があるクライアントに対してのみ、“再接続可能かつ事前処理を再実行せよ”の旨を表すコールバックメッセージ（コールバック通知）をすることで、コールバックメッセージに伴うネットワーク負荷を軽減することができるという効果を得ることができる。
【００６１】
（実施形態３）
本実施形態は、実施形態１、２の応用例である。よって、共通する部分は説明を省略し、特徴的部分を中心に、本実施形態の文書管理システムについて添付図面を用いて以下に説明する。ところで、実施形態２は、文書管理サーバがフェールオーバした際、接続中のクライアントからの処理要求が“未完了”だった場合、その処理要求をクライアントからリトライするという機能を有するものである。
【００６２】
しかし、実施形態２においては、処理のリトライの実行可否がクライアントに一任されるため、一連の流れの処理が複数クライアントで実現されるような環境では、あるクライアントが処理をリトライしないため、一連の流れの処理が完了できないという問題がある。本実施形態は、このような問題に着目し、その解決策を提案するものである。
【００６３】
本実施形態は、実施形態２に対して、接続中のクライアントからの処理要求を、処理内容とその処理を実行するためのパラメータ等を時系列に記憶したトランザクションログを追加し、文書管理サーバがフェールオーバした際、トランザクションログに記載されているステータスが“未完了”と設定されている処理に対して、文書管理サーバが自動リトライするしくみと、自動リトライが失敗した場合、その失敗した処理要求を発行したクライアント、及び、トランザクションログ中で失敗した処理以降の処理を発行したクライアントのみに対して、要求処理のリトライをさせるためのコールバックメッセージを送信することを特徴とする。
【００６４】
まず、本実施形態の文書管理システムの概略構成について、図８を用いて以下に説明する。図８は、本実施形態の文書管理システムの概略構成図である。図８に示すように、本実施形態の文書管理システムは、図１で示した実施形態１の文書管理システムの文書管理サーバ１に、トランザクション監視処理部１３、及び、トランザクションログ１４を加えたものである。
【００６５】
ここで、トランザクションログ１４について、図９を用いて以下に説明する。図９は、本実施形態のトランザクションログ１４を示した図である。図９に示すように、トランザクションログ１４は、時系列に処理要求したクライアントを示すクライアント名と、そのクライアントが要求した処理内容と、その処理内容を実施する際に必要な処理パラメータと、その処理の完了/未完了を示すステータス情報で構成される。
【００６６】
次に、本実施形態の文書管理システムにおける、クライアントアクセス時のトランザクションログ１４の管理動作について説明する。図１０は、本実施形態の文書管理システムにおける、クライアントアクセス時のトランザクションログ１４の管理動作について説明するためのフローチャートである。
【００６７】
まず、図１０に示すように、例えば、クライアント４が、文書管理サーバ１の文書管理サーバ業務にアクセスすると、文書管理サーバ１は、クライアント４の処理要求を、図１に示すメッセージ送受信処理部８で受け付ける（ステップ５０１）。続いて、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ５０２）、“接続開始要求”の場合、図１に示す接続ユーザ監視処理部９に処理を受け渡す（ステップ５０２YES→ステップ５０３）。
【００６８】
続いて、接続ユーザ監視処理部９は、図１に示す接続ユーザリスト１０に、クライアント接続情報として、接続クライアント名、接続ユーザを記憶する（ステップ５０３）。そして、接続ユーザ監視処理部９が、接続ユーザリスト１０から接続クライアントのステータスを“処理完了”とする（ステップ５１１）。
【００６９】
また、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ５０２）、“接続開始要求”でなく、“接続終了要求”の場合は、図１に示す接続ユーザ監視処理部９に処理を受け渡し（ステップ５０２NO→ステップ５０４YES）、ユーザ監視処理部９は、上記“接続終了要求”をしているクライアントに関するクライアント接続情報を接続ユーザリスト１０から削除する（ステップ５０５）。そして、接続ユーザ監視処理部９は、接続ユーザリスト１０から接続クライアントのステータスを“処理完了”とする（ステップ５１１）。
【００７０】
また、メッセージ送受信処理部８は、クライアント４の処理要求の種別を判断し（ステップ５０２）、“接続開始要求”でも、“接続終了要求”でもない他の処理要求の場合には、図１に示す接続ユーザ監視処理部９が、接続ユーザリスト１０から接続クライアント（ここでは、クライアント４）のステータスを“未完了”とする（ステップ５０６）。続いて、トランザクション監視処理部１３は、クライアント４から要求されている処理（文書管理操作）を、トランザクションログ１４に記憶する（ステップ５０７）。トランザクションログ１４には、処理発行したクライアント名、処理内容、処理パラメータが記憶され、ステータスは“未完了”とされる（ステップ５０７）。
【００７１】
そして、文書管理処理部１１は、クライアント４から要求されている処理（文書管理操作）を文書管理データベース３にアクセスすることにより実行する（ステップ５０８）。続いて、メッセージ送受信処理部８が、文書管理処理部１１で実行された結果から、操作の結果作成し、クライアント４に送信する（ステップ５０８）。そして、トランザクション監視処理部１３は、クライアント４からされた処理要求が完了したことを、トランザクションログ１４に記憶する。この時、ステータスは“完了”とされる（ステップ５１０）。
【００７２】
そして、接続ユーザ監視処理部９は、接続ユーザリスト１０から接続クライアントのステータスを“処理完了”とする（ステップ５１１）。尚、上記、ステップ５０８、５０９において、障害が発生した場合、ステップ５０８、５０９の処理を破棄するか、その処理によって文書管理データベース３に与えた更新をロールバックするのが一般的であるが、これについては本実施形態では規定しない。図１０に示すフローチャートでは、適切なロールバック処理等のエラー処理を実施し、クライアントアクセスを終了するものとする。
【００７３】
以上説明したように、本実施形態の文書管理システムによれば、接続ユーザ監視処理部９は、例えば、クライアント４からの操作要求がされた場合、まず、図５に示す接続ユーザリスト１０に記憶されたクライアント４のレコードを特定し、そのステータスフィールドに、これから要求された文書管理処理を開始するという意味で“未完了”と記憶する。その後、図１０に示したフローチャートに従い、トランザクション監視処理部１３は、クライアント４からされた処理要求を、トランザクションログ１４に対して、処理発行したクライアント４を識別するクライアント名、処理内容、及び、処理を実行するためのパラメータを記憶し、これから処理を実行することを意味する“未完了”をステータスに記憶する。
【００７４】
その後は、文書管理処理部１１が実際の文書管理処理を実行し、その結果をメッセージ送受信処理部８がクライアント４に返す。続いて、トランザクション監視処理部１３が、現在処理したクライアント４からの処理要求が完了したことを示すため、トランザクションログ１４の、そのステータスフィールドに、“処理完了”と記憶する。また、クライアント５、６についても同様な処理をする。
【００７５】
次に、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について図１１を用いて説明する。図１１は、本実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【００７６】
本説明では、クライアント５、６の処理要求に応じて、文書管理処理部１１が文書管理操作を処理中に、文書管理サーバ１に障害が発生し、その後に、文書管理サーバ１から、文書管理サーバ２に文書管理サーバ業務がフェールオーバされる（引き継がれた）場合を想定する。
【００７７】
まず、図１１に示すように、文書管理サーバ１のクラスタリング状態監視処理部７（図１参照。）は、クラスタリング管理処理部１２に対して定期的にポーリングを実行する（ステップ６０１→ステップ６０２NO→ステップ６０１の繰り返し）。
【００７８】
そして、クラスタリング状態監視処理部７が、文書管理サーバ１において何らかの障害が発生した場合において、クラスタリング管理処理部１２によりクラスタリング処理が実行され、文書管理サーバ１の稼動による文書管理サーバ業務を、文書管理サーバ２に引き継ぐフェールオーバが完了したと判断した場合は、トランザクション監視処理部１３は、トランザクションログ１４を参照し、ステータスが“未完了”の処理を時系列に、メッセージ送受信処理部経由で、文書管理サーバ２の文書管理処理部（不図示）へ処理依頼する（ステップ６０２YES→ステップ６０３）。
【００７９】
続いて、文書管理サーバ２の文書管理処理部は、ステータスが“未完了”の処理（文書管理操作）を時系列に文書管理データベース３にアクセスすることにより実行する（ステップ６０４）。そして、文書管理サーバ２の文書管理処理部は、トランザクションログ１４に記憶された、ステータスが“未完了”の処理がなくなるまで処理を実行する（ステップ６０３→６０４→６０５→６０８の繰り返し）。
【００８０】
一方、文書管理サーバ２の文書管理処理部が、ステータスが“未完了”の処理（文書管理操作）の実行に失敗した場合（ステップ６０５NO）、例えば、図９に示すトランザクションログ１４において、クライアントＢ（クライアント５）の未完了処理の実行は成功したが、クライアントＣ（クライアント６）の未完了処理の実行が失敗した場合を想定する。
【００８１】
この場合、文書管理サーバ２の文書管理処理部が、図５に示すように、クライアントＣ（クライアント６）のサムネイル作成処理で失敗したので、クライアントＣ（クライアント６）と、トランザクションログ１４中の次の文書登録処理を依頼したクライアントＢ（クライアント５）に対して（処理失敗以降のトランザクションを発行したクライアントに対して）、文書管理サーバ１のトランザクション監視処理部１３は、処理の再実行を要請するように、メッセージ送受信処理部８に依頼する（ステップ６０６）。
【００８２】
すると、メッセージ送受信処理部８は、上記クライアント名（クライアントＢ、Ｃ）に対して要求処理のリトライをさせるためのコールバックメッセージを作成し、そのクライアント５、６に対して、そのメッセージ（コールバック通知）を送信する（ステップ６０７）。その後、コールバック通知を受けたクライアント５、６では、ユーザがメッセージに従い、文書管理サーバ２に対して再接続処理をし、指定された処理のリトライが試みられることになる。
【００８３】
ステップ６０８における、トランザクションログ１４に記憶されたステータスが“未完了”の処理がなくなった場合、又は、ステップ６０７における、コールバック通知がされた場合は、続いて、文書管理サーバ１のトランザクション監視処理部１３が、トランザクションログ１４をクリアする（ステップ６０９）。そして、接続ユーザ監視処理部９が、接続ユーザリスト１０をクリアする（ステップ６１０）。
【００８４】
以上説明したように、本実施形態によれば、文書管理サーバ１がフェールオーバ時、失敗した処理に対して、文書管理サーバ２がフェールオーバ完了後、自動リトライをするため、文書管理サーバ１、２側での処理の自動復旧が可能となる。このためクライアントに依存した処理のリトライがなくなり、システム運用の煩雑さが軽減されるという効果を得ることができる。
【図面の簡単な説明】
【００８５】
【図１】第１の実施形態における、文書管理システムの概略構成図である。
【図２】第１の実施形態における、接続ユーザリスト１０を示した図である。
【図３】第１の実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明するためのフローチャートである。
【図４】第１の実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【図５】第２の実施形態における、接続ユーザリスト１０を示した図である。
【図６】第２の実施形態の文書管理システムにおける、クライアントアクセス時の接続ユーザリスト１０の更新動作について説明するためのフローチャートである。
【図７】第２の実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【図８】第３の実施形態における、文書管理システムの概略構成図である。
【図９】第３の実施形態における、トランザクションログ１４を示した図である。
【図１０】第３の実施形態の文書管理システムにおける、クライアントアクセス時のトランザクションログの管理動作について説明するためのフローチャートである。
【図１１】第３の実施形態の文書管理システムにおける、フェールオーバ完了時のクライアントへのコールバック通知の動作について説明するためのフローチャートである。
【図１２】従来の文書管理システムの概略構成図である。
【符号の説明】
【００８６】
１    文書管理サーバ
２    文書管理サーバ
３    文書管理データベース
４、５、６    クライアント
７    クラスタリング状態監視処理部
８    メッセージ送受信処理部
９    接続ユーザ監視処理部
１０    接続ユーザリスト
１１    文書管理処理部
１２    クラスタリング管理処理部
１３    トランザクション監視処理部
１４    トランザクションログ
【図１】
2007058506.tif 000003
【図２】
2007058506.tif 000004
【図３】
2007058506.tif 000005
【図４】
2007058506.tif 000006
【図５】
2007058506.tif 000007
【図６】
2007058506.tif 000008
【図７】
2007058506.tif 000009
【図８】
2007058506.tif 000010
【図９】
2007058506.tif 000011
【図１０】
2007058506.tif 000012
【図１１】
2007058506.tif 000013
【図１２】
2007058506.tif 000014