JP2007293444A - 帳票配信システム、および帳票配信方法 - Google Patents

Abstract

【課題】従来技術では、帳票管理サーバから帳票出力サーバへの帳票データを送信中に帳票管理サーバがダウンした場合、またはネットワーク異常が発生した場合、帳票出力サーバで印刷を続行できなくなってしまうという課題があった。
【解決手段】本発明は、複数の帳票管理サーバと帳票出力サーバと負荷分散装置とを備えた帳票配信システムであって、接続された帳票管理サーバは、帳票出力サーバに帳票データを転送し、帳票出力サーバは、転送された帳票データのブロック番号を記憶し、システムエラーまたはネットワーク接続障害があった場合にエラーを検知し、エラー発生直前の帳票ブロック番号を読み出し、再接続要求し、負荷分散装置は、再接続の要求を受けた場合に、負荷の少ない他の１つの帳票管理サーバと接続し、他の１つの帳票管理サーバは、エラー発生直前の帳票ブロック番号に基づいて帳票ブロック番号から帳票データを帳票出力サーバに転送し再開する。
【選択図】 図１

Description

この発明は、複数のコンピュータから１台のプリンタへ同時に印刷を行った場合に、帳票の出力順序を保証する帳票配信システム、および帳票配信方法に関し、特に、ネットワーク負荷を軽減するとともに、プリントサーバ(出力サーバ)の負荷を軽減し、システム等にエラーが生じた場合であっても即時復旧することができる帳票配信システム、および帳票配信方法に関するものである。

通常、例えば、図１４に示すように、Ｗｉｎｄｏｗｓ（登録商標）のＭＳリモート印刷やＵＮＩＸ（登録商標）のｌｐｒコマンドなどのＯＳ標準の印刷機能では、図１５に示すように、複数のコンピュータ（印刷サーバ）から１台のプリンタへ同時に印刷を行った場合、出力結果が混じってしまう。従って、複数のコンピュータから出力された印刷データを、印刷データが混じることなく印刷された順序通りにプリンタへ出力するためには、何らかの工夫が必要となる。

図１６に示すように、特許文献１に示す従来の方式は、印刷クライアント上でスプールデータを生成し、生成したスプールデータをプリントサーバに転送する方式が知られている。なお本従来の方式は、印刷クライアント側に「Windows（登録商標） Spooler」という構成要素が記載されていることから、MSリモート印刷を指しているものである。従来の方式では、印刷順序を保証するために、「グループ印刷ジョブ内のすべての印刷ジョブの準備ができていないと判断される場合は、グループ印刷ジョブの印刷を保留する。そして、グループ印刷ジョブ内のすべての印刷ジョブの準備ができた時点で印刷を開始」するものである。

特開２００１−７５７６８号公報

しかしながら、印刷クライアント上でスプールデータを生成し、生成したスプールデータをプリントサーバに転送する従来の方式では、ネットワーク上をスプールデータが流れることになり、一般的にスプールデータは、印刷前データよりもサイズ大であることから、ネットワークに負荷がかかってしまう。また、従来の方式では、印刷順序を保証するために、グループ印刷ジョブ内のすべての印刷ジョブの準備ができていないと判断される場合は、グループ印刷ジョブの印刷を保留し、グループ印刷ジョブ内のすべての印刷ジョブの準備ができた時点で印刷を開始するので、複数の印刷クライアントから、同時に印刷が行われた場合、プリントサーバに負荷がかかり、印刷性能が劣化する。

特に、従来技術では、帳票管理サーバから帳票出力サーバへの帳票データを送信中に帳票管理サーバがダウンした場合、またはネットワーク異常が発生した場合、帳票出力サーバで印刷を続行できなくなってしまうという課題があった。

本発明は、上記に鑑みてなされたもので、従来の方式と比較して、ネットワーク負荷を軽減することができ、また、プリントサーバ(出力サーバ)の負荷を軽減することができる、帳票配信システム及び帳票配信制御方法を提供することができる帳票配信システム、および帳票配信制御方法を提供することを目的とする。

特に、帳票配信管理システムをマルチサーバシステムとして構成した場合に、印刷データ転送元サーバの１台がダウンした場合でも、別の転送元サーバがデータ送信を引き継ぎ、性能劣化、および重複して印刷されることなく自動的に継続することができる帳票配信システム、および帳票配信制御方法を提供することを目的とする。

このような目的を達成するため、請求項１に記載の帳票配信システムは、複数の帳票管理サーバ装置と、ネットワークに接続された帳票出力サーバ装置と、該複数の帳票管理サーバ装置と該ネットワークとの間に接続された負荷分散装置と、を備えた帳票配信システムにおいて、上記帳票出力サーバ装置は、複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に帳票データの転送を要求する転送要求手段と転送された帳票データのブロック番号を記憶する帳票ブロック番号記憶手段と、システムエラーまたはネットワーク接続障害を検知するエラー検出手段と、上記エラー検知手段によって、帳票データの転送時にエラーが検知された場合に、上記帳票ブロック番号記憶手段から、エラー発生直前の帳票ブロック番号を読み出し、上記帳票管理サーバ装置に再接続を要求する再接続要求手段と、を備え、上記負荷分散装置は、上記転送要求手段によって上記帳票出力サーバ装置から要求があった場合に、上記複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に接続する管理サーバ接続手段と、上記再接続要求手段によって、再接続の要求を受けた場合に、負荷の少ない他の複数の帳票管理サーバ装置の一と接続する他サーバ接続手段とを備え、上記複数の帳票管理サーバ装置は、上記帳票出力サーバ装置に帳票データを転送する帳票データ転送手段と、上記他サーバ接続手段によって接続された場合に、通知されたエラー発生直前の帳票ブロック番号に基づいて、該帳票ブロック番号から帳票データを帳票出力装置に転送する帳票転送再開手段と、を備えたことを特徴とする。

また、請求項２に記載の帳票配信サーバ装置は、複数の帳票管理サーバ装置と、ネットワークに接続された帳票出力サーバ装置と、該複数の帳票管理サーバ装置と該ネットワークとの間に接続された負荷分散装置と、を備えた帳票配信システムにおける帳票配信方法であって、上記帳票出力サーバ装置において実行される、複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に帳票データの転送を要求する転送要求ステップと上記負荷分散装置において実行される、上記転送要求ステップによって上記帳票出力サーバ装置から要求があった場合に、上記複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に接続する管理サーバ接続ステップと、上記複数の帳票管理サーバ装置において実行される、上記管理サーバ接続ステップによって接続された場合に、上記帳票出力サーバ装置に帳票データを転送する帳票データ転送ステップと、上記帳票出力サーバ装置において実行される、上記帳票データ転送ステップによって転送された帳票データのブロック番号を記憶する帳票ブロック番号記憶ステップと、システムエラーまたはネットワーク接続障害を検知するエラー検出ステップと、上記エラー検知ステップによって、帳票データの転送時にエラーが検知された場合に、帳票ブロック番号記憶手段から、エラー発生直前の帳票ブロック番号を読み出し、再接続を要求する再接続要求ステップと、上記負荷分散装置において実行される、上記再接続要求ステップによって、再接続の要求を受けた場合に、負荷の少ない他の複数の帳票管理サーバ装置の一と接続する他サーバ接続ステップと上記複数の帳票管理サーバ装置のうち他の１つの帳票管理サーバ装置において実行される、上記他サーバ接続ステップによって接続された場合に、通知されたエラー発生直前の帳票ブロック番号に基づいて、該帳票ブロック番号から帳票データを帳票出力装置に転送する帳票転送再開ステップと、を含んだことを特徴とする。

帳票管理サーバが複数サーバで動作するように構成したので、帳票管理サーバのどれか1台がダウンした場合でも、ダウンした帳票管理サーバの処理を、他の帳票管理サーバが自動的に引き継ぐことにより、24時間365日連続稼動を実行させることができるというマルチサーバシステムの利点を有する一方、帳票データファイルおよび帳票資源は共有ディスク上に格納複数台の帳票管理サーバから、同一のファイルをアクセス可能にすることによって、帳票データの矛盾を生じさせることがないという効果を奏する。

また、マルチサーバのデータベース上の配信スレッド監視テーブルを使用して、他の帳票管理サーバのダウン検知と出力順序の保証を行えるよう構成したので、複数台の帳票管理サーバから帳票を登録した場合でも、登録された順序で帳票が配信・出力できるという効果を奏する。

さらに、負荷分散装置により、帳票管理サーバのどれか1台がダウンした場合でも、他の帳票管理サーバから、帳票データファイルを取り出せるようにしたので、負荷分散装置がダウンしたとしても、システム全体が稼動不可能になることが無く、帳票の取出し処理を多重化することができる。

以下に、本発明にかかる帳票配信システム、および帳票配信制御方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［本発明の概要］
以下、本発明の概要について説明し、その後、本発明の構成および処理等について詳細に説明する。

本発明は、概略的に、以下の基本的特徴を有する。

つまり、本発明は、複数の帳票管理サーバ装置と、ネットワークに接続された帳票出力サーバ装置と、複数の帳票管理サーバ装置とネットワークとの間に接続された負荷分散装置と、を備えた帳票配信システムであることを前提とする。

つぎに、帳票出力サーバ装置は、複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に帳票データの転送を要求する。

そして、負荷分散装置は、帳票出力サーバ装置から要求があった場合に、複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に接続する。

つづいて、接続された帳票管理サーバ装置は、帳票出力サーバ装置に帳票データを転送する。

そして、帳票出力サーバ装置は、転送された帳票データのブロック番号を記憶する。

また、帳票出力サーバ装置は、システムエラーまたはネットワーク接続障害があった場合にエラーを検知し、帳票データの転送時にエラーが検知された場合に、エラー発生直前の帳票ブロック番号を読み出す。ここで記憶、読み出しを行う装置は、ディスク装置などの静的な媒体に限らず、印刷プロセスのメモリ等に保持してもよい。

つぎに、負荷分散装置は、再接続の要求を受けた場合に、負荷の少ない他の複数の帳票管理サーバ装置の一と接続する。

接続された他の１つの帳票管理サーバ装置は、通知されたエラー発生直前の帳票ブロック番号に基づいて、帳票ブロック番号からの帳票データを帳票出力装置に対して転送する。

ここで、帳票出力サーバ装置は、出力手段と一体に印刷装置等として構成してもよく、また、出力手段として、印刷手段、ファイル出力手段等を用いることができる。

以上が、本発明の概要である。

［システム構成］
本帳票配信システムの構成について、以下に図１を参照して説明する。

図１は、この発明の帳票配信システムの構成図である。図１において、帳票配信システムは、センターに、複数の管理サーバ１と、データベースサーバ２と、共有ディスク１２と、負荷分散装置４とを備えている。また、各拠点に、複数の出力サーバ３と、出力装置６とを備えており、ネットワーク５を介して複数の管理サーバ１と接続されている。

管理サーバ１は、センターにおいて、ユーザアプリケーション９が出力した帳票を一元管理している。また、管理サーバ１は、配信手段１０、取出し手段１１を備えている。配信手段２１の配信スレッド２２は、帳票データ転送手段として機能する。１台の管理サーバ１がデータベースサーバ２に格納する配信スレッド監視テーブル１３を用いて１つの論理デバイスの処理を占有する。また、管理サーバ１から出力サーバ３へ出力データそのものではない出力要求を配信手段１０によって送信する。

また、管理サーバ１は、共有ディスク１２に格納する印刷前帳票データファイルを取出し手段１１によって取出し、印刷前帳票データファイルを出力サーバ３へ送信する。

詳しくは、取出し手段１１は、ユーザアプリケーション９から帳票の登録を制御する帳票登録ＡＰＩ（Application Program Interface）１１ａと、配信手段に配信の実行を支持する印刷指示ＡＰＩ１１ｂと、共有ディスク１２にアクセスし、帳票ファイルを取り出す帳票取出しＡＰＩ１１ｃとから構成されている。帳票取出しＡＰＩ１１ｃは、エラー発生後の再接続時に既に転送した帳票を読み飛ばす帳票転送再開手段としても機能する。

負荷分散装置４は、出力サーバ３が管理サーバ１へアクセスし帳票データファイルを取り出す時に、帳票データファイルを取出す管理サーバ１を切替える管理サーバ接続手段および他サーバ接続手段を備えている。例えば、配信スレッド監視テーブル１３のホスト名を、負荷の少ない管理サーバの管理サーバ名に書き換えることにより行う。

各拠点に設置された出力サーバ３は、制御手段１８、ディスク１９、印刷プロセス２０を備えており、管理サーバ１から送信された出力要求を管理する。詳しくは、受信した帳票データファイルを管理サーバ１から送信された出力要求を先に到着したものから順にディスク１９に格納（キューイング）する。ディスク１９は、該帳票データのブロック番号を記憶する帳票ブロック番号記憶手段としても機能する。制御手段１８は出力要求を受けて１台の出力装置６に対して、１つずつ印刷プロセス２０を起動する。印刷プロセス２０は、受信した帳票データファイルを元に管理サーバ１へアクセスする転送要求手段であるとともに、帳票データファイルを取り出し、エラーを検出するエラー検出手段、エラー発生時に再接続を要求する再接続要求手段、帳票データファイルを基づいてユーザが指定した出力装置に対し、帳票をフォーマット出力する出力手段を備えている。

なお、共有ディスク１２に格納する帳票データファイルは、圧縮された帳票データファイルとすることが望ましく、出力サーバ３から管理サーバ１へアクセスし、圧縮された帳票データファイルを取り出し、印刷プロセス２０で帳票データファイルを解凍して出力する。

また、制御手段１８は、出力要求を受けて出力の多重度を制御し出力サーバ３の負荷を制御する印刷多重度制御サービス１８ａと、優先度を判定し印刷順を決定する印刷優先度制御手段とから構成される。さらに、印刷多重度制御サービス１８ａは、出力要求を受けて出力の優先度を制御し、帳票データファイルを優先度の高い論理あて先から順次取り出す。

ここで、管理サーバ１がデータベースサーバ２に格納する他のテーブルについて図１３を参照して説明する。図１３（ａ）は、論理あて先定義テーブル１４の一例を示す図である。

図１３に示すように、論理あて先名は、ユーザアプリケーションが帳票の出力先として指定する仮想的な論理あて先名を指定する。優先度は、論理あて先の優先度を指定する。この例では、優先度を１〜１０とし、１は優先度が最も低く、１０は優先度が最も高いことを示す。論理デバイス名は、論理あて先に対応する論理デバイス名を指定しており、ある管理サーバ装置が１つの論理デバイスを占有するように構成される。

図１３（ｂ）は、論理デバイス定義テーブル１５の一例を示す。論理デバイス名は、上記の通り論理デバイス名を指定し、端末名は、出力サーバの端末名（帳票の配信先端末名）を指定する。プリンタ名は、出力サーバに接続されているプリンタ名を指定する。

図１３（ｃ）は、キュー管理テーブル１６の構成の一例を示す。論理あて先名は、ユーザアプリケーションが帳票の登録時に指定した論理あて先名を指定する。帳票データの識別子は、帳票の取出し処理で転送する帳票データを識別するための情報（帳票データファイル名、帳票ＩＤ、配信通番、再送通番などの内部情報）を指定する。キュー登録日時は、キュー管理テーブルに出力要求を登録した日時を設定する。なお、キュー管理テーブルの１件のレコードが、１件の出力要求に相当する。

前記の例において、論理あて先「ＬＤ−１」「ＬＤ−２」は、ともに論理デバイス「ＬＤＥＶ−Ａ」に対応付けされている。また、論理あて先「ＬＤ−３」は論理デバイス「ＬＤＥＶ−Ｂ」に対応付けされている。例えば、ユーザアプリケーション９が、帳票１を、論理あて先「ＬＤ−１」に登録した場合、出力サーバ「ＨＯＳＴ−１」に接続されているプリンタ「ＰＲＩＮＴＥＲ−１」から、帳票１が印刷される。

また、例えば、ユーザアプリケーション９は、帳票１を、論理あて先「ＬＤ−１」、ユーザアプリケーション９ｂは、帳票２を、論理あて先「ＬＤ−２」に対して、同時に登録した場合、論理あて先「ＬＤ−２」の方が優先度は高いため、出力サーバ「ＨＯＳＴ−１」に接続されているプリンタ「ＰＲＩＮＴＥＲ−１」から、帳票２、帳票１の順番で印刷される。

［システムの処理］
まず、帳票の登録から出力までの基本的な流れについて、以下に説明する。

［(1)帳票の登録］
ユーザアプリケーション９は、論理あて先(仮想的な出力先)を指定し、帳票を登録する。つまり、帳票の出力データは、帳票データファイルに格納する。ここで、ユーザアプリケーション９のプロセス上から、帳票の出力データを、帳票データファイルとして圧縮出力する。

詳しくは、取出し手段１１を構成するデーモンプロセス上の帳票登録ＡＰＩ（Application Program Interface）１１ａが、ユーザアプリケーション９のプロセスで作成された、一時名の帳票データファイルを、正式な名前にリネームする。帳票の管理情報(帳票のタイトル、部数など)は、帳票登録ＡＰＩ１１ａから、データベースに格納する。

［(2)出力要求の配信］
配信手段１０は、取出し手段１１から、帳票の印刷指示を受けて、データベースのキュー管理テーブル１６から出力要求を取り出す。さらに、取り出した出力要求を出力サーバ３に配信する。

［(3)印刷プロセスの起動］
出力サーバ３上で動作する制御手段１８の一つである印刷多重度制御サービス１８ａは、管理サーバ１から送信された出力要求を受信し、出力要求キュー１９ａに保存する。さらに、印刷を同時実行する多重度、および、出力要求の優先度を比較し、適切なタイミングで適切な印刷プロセス２０を起動する。

［(4)帳票データの取り出し］
（３）で起動された印刷プロセス２０は、管理サーバ１の取出し手段１１に対し、ネットワーク接続を行い、帳票取出しＡＰＩ１１ｃを介して、帳票データファイルを受信する。

［(5)帳票をフォーマット出力］
受信した帳票データファイルを元に、ユーザが指定した出力装置に対し、帳票をフォーマット出力する。

［(6)レジューム機能処理］
（４）で機能する印刷プロセス２０は、帳票データファイルを受信できなかった場合に、帳票ブロック番号とともに再度、他の管理サーバ１に接続要求を行う。

すなわち、図１のブロック図において、出力サーバ３は、印刷プロセス２０の処理により、管理サーバ３に帳票データの転送を要求する。

つぎに、負荷分散装置４は、出力サーバ３から管理サーバ１へアクセスし帳票データファイルを取り出す時に、帳票データファイルを取出す管理サーバ１を切替える。

そして、接続された管理サーバ１は、配信スレッド２２の処理により、出力サーバ３に帳票データを転送する。

出力サーバ３は、印刷プロセス２０の処理により、転送された帳票データのブロック番号をディスク１９に記憶し、システムエラーまたはネットワーク接続障害があった場合には、印刷プロセス２０の処理により、エラーを検知し、エラー発生直前の帳票ブロック番号を読み出し、再接続要求する。

負荷分散装置４は、再接続の要求を受けた場合に、負荷の少ない他の１つの管理サーバ１と接続させる。

そして接続された他の１つの管理サーバ１は、帳票取出しＡＰＩ１１ｃの処理により、エラー発生直前の帳票ブロック番号に基づいて、既に転送した帳票ブロックを読み飛ばして帳票データを出力サーバ３に転送することを再開する。

これにて、帳票の登録から出力までの基本的な流れについての説明を終える。次に、このように構成された本実施の形態における本システムの処理の一例について、以下に図を参照して詳細に説明する。

［順序制御処理］
順序制御について詳細に説明する。図２は、この発明の帳票配信システムの順序制御の概念図である。

図２に示すように、管理サーバから、出力サーバへと、スプールデータそのものが流れることはなく、（１）出力要求(サイズ極小)、および、（３）圧縮された帳票データファイル(サイズ中)が流れる。そして、出力サーバ上で、圧縮された帳票データファイルを解凍し、（４）印刷を実行(スプールデータを生成)する。これにより、管理サーバから、出力サーバへはスプールデータそのものが流れることはなく、ネットワーク負荷が少ないという効果を得る。

また、管理サーバから出力サーバへと、（１）出力要求(サイズ極小)のみ送信し、出力要求を出力サーバにいったんキューイングする。その後、出力サーバ上では、１台のプリンタに対して、（２）１つずつ(１多重で)、順序制御しながら印刷プロセスを起動する。印刷プロセスは、管理サーバから、圧縮された帳票データファイル(サイズ中)を取り出し、解凍し、印刷を実行する。これにより、多数の出力要求が、１台の出力サーバに多数同時に転送された場合でも、印刷性能が極端に劣化することはない。

なお、共有ディスク１２に格納する帳票データファイルは、圧縮された印刷前データとすることが望ましく、出力サーバ３から管理サーバ１へアクセスし、圧縮された帳票データファイルを取り出し、印刷プロセス２０で帳票データファイルを解凍して出力する。

また、制御手段１８は、出力要求を受けて出力の多重度を制御し出力サーバ３の負荷を制御する。さらに、出力要求を受けて出力の優先度を制御し、帳票データファイルを優先度の高い論理あて先から順次取り出す。

[論理デバイス占有処理]
つぎに、１台の管理サーバが１つの論理デバイスの処理を占有する処理について説明する。図３は、この発明の帳票配信システムの管理サーバの構成図である。

図３において、データベースサーバ２に格納する配信スレッド監視テーブル１３は、１つの論理デバイスを１台の管理サーバ１で占有するために使用するものであり、以下の構成からなる。論理デバイス名は、配信対象となる論理デバイス名を設定する。ホスト名は、配信する管理サーバのホスト名を設定する。更新日時は、配信開始時、配信終了時にデータベースサーバ２を管理するデータベースサーバの時間を設定する。

管理サーバ１は、配信手段１０（配信サービス）として、監視スレッド２１と、配信スレッド２２とを備えている。監視スレッド２１は、配信サービス上で、１つだけ常駐するもので、一定時間間隔で、配信スレッド監視テーブル１３をチェックする。引き継ぎ対象の論理デバイス名を発見した場合は、他の管理サーバから、論理デバイスの処理を引き継ぎ、配信スレッド２２を起動する。なお、ユーザアプリ、コマンドなどから、帳票の配信依頼があった場合にも、配信スレッド２２を起動する。

［配信スレッド処理］
つぎに、配信スレッド処理の詳細について図４を参照して説明する。図４は、この発明の帳票配信システムの配信スレッドの処理を説明するフローチャートである。

ステップＳ０１において、処理の順番を確認し、１件目であればステップＳ０２に進む。

ステップＳ０２において、配信スレッド監視テーブル１３へ論理デバイス名、ホスト名、更新日時を挿入する。なお、更新日時には、前述のデータベースサーバ２を管理するデータベースサーバの日時を設定する。これにより、管理サーバの時間がずれていても、実際に帳票を登録した順番で、配信されることが保証される。

ステップＳ０３において、配信スレッド監視テーブル１３への挿入が成功したか判断し、挿入が成功すればステップＳ０４に進む。挿入が成功しなければ、配信スレッドの処理を終了する。

ステップＳ０４において、配信する帳票の情報をデータベースサーバ２に格納するキュー管理テーブル１６から取得する。

ステップＳ０５において、配信する帳票は存在するか判断し、存在する場合はステップＳ０６に進み、出力サーバ３への帳票配信処理を実行して、ステップＳ０１に戻る。配信する帳票が存在しない場合は、ステップＳ０７に進み、配信スレッド監視テーブル１３からレコードを削除し、ステップＳ０８において、データベースをコミット（直前の処理を確定）して配信スレッドの処理を終了する。

なお、前記のステップＳ０１において、処理の順番が２件目以降、又は引継ぎ時は、ステップＳ０９で、データベースをコミット（直前の処理を確定）し、ステップＳ１０において、配信スレッド監視テーブル１３のレコードを更新（更新日時を現在の日時に更新）し、ステップＳ１１において、更新は成功したか判断し、更新が成功した場合は、ステップＳ０４に進む。更新が成功しなかった場合は、配信スレッドの処理を終了する。

［出力要求処理・キューイング処理］
次に、管理サーバ１から出力サーバ３へ出力データそのものではない出力要求を送信し、前記出力要求を出力サーバ３にいったんキューイングする構成を図５を参照して説明する。図５は、この発明の帳票配信システムの印刷多重度制御サービスの構成図である。

図５において、出力サーバ３における印刷順序の制御は、印刷多重度制御サービス１８ａ（制御手段１８の一）が行う。印刷多重度制御サービス１８ａは、ディスク１９と、出力要求通知オブジェクト２７と、多重度制御カウンタ２９と、出力要求受信スレッド２５と、多重度制御スレッド２８と、印刷プロセス起動スレッド３０とを構成する。

出力要求キュー１９ａは、管理サーバ１から受信した出力要求を先に到着したものから順に格納（出力要求キューにキューイング）する。出力要求通知オブジェクト２７は、印刷多重度制御サービス１８ａで動作するスレッド間で、帳票出力のタイミングを通知し合うためのオブジェクトである。多重度制御カウンタ２９は、現在、動作中の印刷プロセス２０の数をカウントするためのオブジェクトである。

出力要求受信スレッド２５は、印刷多重度制御サービス１８ａ上で、管理サーバ１から出力要求を受信する度に起動される。受信した出力要求を先に到着したものから順にディスク１９に格納する。多重度制御スレッド２８は、印刷多重度制御サービス１８ａ上に、１つだけ常駐し、出力要求受信スレッド２５及び印刷プロセス起動スレッド３０からの出力要求を受けて、ディスク１９に格納する出力要求キュー１９ａから出力要求を１つ取出し、印刷プロセス起動スレッド３０を起動する。印刷プロセス起動スレッド３０は、印刷プロセス２０を起動する。

［多重度制御］
次に、出力サーバで出力要求を受けて出力の多重度を制御する構成を、図６を参照して説明する。図６は、この発明の帳票配信システムの出力要求キューの構成図である。

図６において、ディスク１９に格納する出力要求キュー１９ａは、プリンタキューと、論理あて先キューと、出力要求とを構成し、１台の出力サーバで動作する印刷プロセスの最大値を設定することができる。すなわち、印刷多重度の設定が可能である。また、１台のプリンタに対しては、１つの印刷プロセスのみが動作するように制御する。すなわち、出力結果が混ざらないようにする。また、同一のプリンタにつながっている論理あて先キューは、論理あて先の優先度順につながっている。すなわち、優先度の高い論理あて先の出力要求から順番に処理され、これにより帳票の出力順序は優先度の高い順番に保証される。

出力サーバは、出力要求を受けて出力の多重度を制御し出力サーバの負荷を制御するので、多数の出力要求が、１台の出力サーバに多数同時に転送された場合でも、出力サーバの負荷を軽減することができ、従来の方式と比較して、印刷性能が劣化することはないという効果を奏する。

［出力要求受信スレッドの処理］
つぎに、出力サーバ３において実行される、出力受信スレッド処理について図７を参照して、説明する。図７は、この発明の帳票配信システムの出力要求受信スレッドの処理を説明するフローチャートである。

図７に示すように、ステップＳ２１において、管理サーバ１から出力要求を受信する。ステップＳ２２において、前述の論理あて先定義テーブル１４、及び論理デバイス定義テーブル１５を用いて、該当するプリンタキュー・論理あて先キュー配下の末尾に、出力要求を帳票単位で格納する。ステップＳ２３において、出力要求通知オブジェクト２７に出力要求を通知し、出力要求受信スレッドの処理を終了する。これによって、多重度制御スレッド２８に出力要求イベントが通知される。

［多重度制御スレッドの処理］
つぎに、印刷多重度制御サービス１８ａにおいて実行される印刷制御スレッドについて、図８を参照して説明する。図８は、この発明の帳票配信システムの多重度制御スレッドの処理を説明するフローチャートである。

図８に示すように、ステップＳ３１において、出力要求受信スレッド２５からの出力要求通知、あるいは、印刷プロセス起動スレッド３０からの出力要求通知を待つ。すなわち、印刷プロセスの起動処理が開始されるタイミングは、管理サーバ１から出力要求を受信したタイミングと、他の印刷プロセスが終了したタイミングとする。

ステップＳ３２において、出力要求通知を受け、ステップＳ３３において、出力要求キュー１９ａの中の処理すべき出力要求を特定する。すなわち、優先度の高い論理あて先のもので、先に配信されたものから順番に特定する。

ステップＳ３４において、出力要求キュー１９ａの処理すべき出力要求は存在するか判断する。存在する場合は、ステップＳ３５に進む。存在しない場合は、ステップＳ３１に戻る。

ステップＳ３５において、多重度制御カウンタ２９の値（現在、動作中の印刷プロセスの数）はＭＡＸか判断する。ＭＡＸでなければステップＳ３６に進む。ＭＡＸであればステップＳ３１に戻る。

ステップＳ３６において、プリンタの印刷フラグを確認し、ステップＳ３７において、印刷フラグの値はＯＦＦか判断する。ＯＦＦであればステップＳ３８に進み、プリンタキューの印刷フラグをＯＮ（使用中）に設定し、ステップＳ３９で、多重度制御カウンタ２９の値を増やす。ステップＳ４０において、処理する出力要求をディスク１９に格納する出力要求キュー１９ａから取出す。ステップＳ４１において、印刷プロセス起動スレッド３０を起動する。これによって、印刷プロセス起動スレッドの処理につながる。

ステップＳ３７において、印刷フラグの値がＯＦＦでないならばステップＳ４２に進み、出力要求キュー１９ａ中の、次に処理すべき出力要求を特定する。

なお、多重度制御スレッド２８の処理において、ここでは、印刷プロセス起動スレッド３０の終了待ち合わせは行わない。また、多重度制御カウンタ２９、及びプリンタの印刷フラグは、ここでは戻さずに、印刷プロセス起動スレッド３０で、印刷プロセス２０が終了した後に戻す。

［印刷起動スレッド処理］
図９は、この発明の帳票配信システムの印刷プロセス起動スレッドの処理を説明するフローチャートである。

ステップＳ５１において、印刷プロセス２０を起動する。これにより、印刷プロセスにつながる。ステップＳ５２において、印刷プロセスの終了を待ち合わせる。ステップＳ５３において、プリンタキューの印刷フラグをＯＦＦに設定し、ステップＳ５４において、多重度制御カウンタ２９の値を減らす。ステップＳ５５において、出力要求を出力要求通知オブジェクト２７に通知（これにより、多重度制御スレッド２８が出力要求通知を受け取る）して印刷プロセス起動スレッドの処理を終了する。

［帳票データ取出し処理］
次に、出力サーバから管理サーバへアクセスして出力データを取り出し、出力する構成を、図１０を参照して説明する。図１０は、この発明の帳票配信システムの出力サーバから管理サーバへアクセスして出力データを取り出す構成図である。

図１０において、出力要求の配信元の管理サーバ１ａの情報は、出力要求データの中に入っている。出力サーバ３から管理サーバ１へアクセスすると、通常は、負荷分散装置４に接続することにより、管理サーバ１ａ，管理サーバ１ｂ，管理サーバ１ｃのいずれかの管理サーバに接続要求が振り分けられる。なお、負荷分散装置４への接続に失敗した場合は、出力要求データに格納されている配信元の管理サーバ１ａに接続を試みる。

［出力データ取り出し出力処理］
つぎに、この発明の帳票配信システムの出力サーバから管理サーバへアクセスして出力データを取り出し出力する処理を、図１１を参照して説明する。図１１の点線で囲った部分は、印刷プロセス２０が管理サーバへアクセスして出力データを取り出し出力する処理のフローチャートである。

まず、ブロック番号と接続リトライ回数をクリアし（ステップＳ６１）、ステップＳ６２において、負荷分散装置４に接続し、ステップＳ６３において、接続処理結果を確認する。ステップＳ６３において、接続失敗か判断し、接続失敗、又は負荷分散装置４ダウンの時は、ステップＳ６４に進み、出力要求データに格納されている要求配信元の管理サーバ１ａに接続する。

ステップＳ６５において、接続処理結果を確認し、ステップＳ６５において、接続成功か判断し、接続成功ならばステップＳ６６に進む。そして、要求配信元の管理サーバ１ａから帳票データ（圧縮された帳票データファイル）を受信し、ステップＳ７０において、帳票をフォーマット出力（帳票データファイルを解凍し、スプールデータを生成する）して、印刷プロセスの処理を終了する（リジューム機能の説明は後述する）。

なお、ステップＳ６３において、負荷分散装置４への接続に成功した場合は、ステップＳ６６に進み、管理サーバ１ａ、管理サーバ１ｂ、管理サーバ１ｃのいずれかに接続され、接続した管理サーバから前記と同様に帳票データを受信する。以下の例では、管理サーバ１ｂを負荷の少ない管理サーバとして説明を行う。

［リジューム処理］
つづいて、図１１と図１２参照しながら、リジューム処理について説明を行う。

リジューム機能とは、印刷プロセスから負荷分散装置を経由して管理サーバ１ａ、１ｂ、１ｃのいずれかに接続し、帳票データを受信・再生する処理の途中に異常が発生した場合、別の管理サーバに再接続し、帳票の出力処理を自動的に継続する機能であり、印刷プロセス２０と帳票取出しＡＰＩ１１ｃなどが共同して実現する。以下にリジューム機能を実現するための処理について、図１１を参照して、詳細する。

まず、出力サーバ３は、印刷プロセス２０の処理により、印刷プロセス２０のメモリ等に帳票ブロック番号を記憶することによって、エラー発生直前までどこまでの帳票データを受信したかを読み出すことができるよう構成されている。

つぎに、管理サーバ１ａと接続が成功した出力サーバ３は、印刷プロセス２０の処理により、管理サーバ１ａに対し、取出し要求を送信し、併せてブロック番号を送信する（ステップＳ６６）。つまり、印刷プロセス２０は、エラーが発生する直前まで受信していた帳票データの、続きのデータから受信を再開する場合に備えて、帳票データ中に受信を再開したいデータの位置情報を記憶し、管理サーバ１に送る。この位置情報のことを、「ブロック番号」と呼んでいる。

つぎに、取出し要求を受信した、管理サーバ１ａは、帳票取出しＡＰＩ１１ｃの処理により帳票データを出力サーバ３に送信するので、通信に問題等がない場合、出力サーバ３は、帳票データ（１ブロック）を受信する（ステップＳ６７）。

つづいて、出力サーバ３は、印刷プロセス２０の処理により、サーバのシステムダウンやネットワーク接続に障害が生じた場合などのエラーが発生した場合など、その異常がないか判定を行う（ステップＳ６８）、受信成功の場合は（ステップＳ６８、Ｙｅｓ）、ブロック番号カウンタをインクリメントし（ステップＳ６９）、出力装置６にフォーマット出力する（ステップＳ７０）。

そして、出力サーバ３は、印刷プロセス２０の処理により、エラーの発生があった場合には（ステップＳ６８、Ｎｏ）、つづいて、印刷プロセス２０の処理により、リカバリ可能なエラーか否か判定を行う（ステップＳ７２）。

ここで「リカバリ可能なエラー」とは、別の管理サーバに再接続することで帳票出力の続行が見込めるエラーのことを言う。例えば、管理サーバとの通信が途絶えた場合や、接続に係る管理サーバでメモリ不足が発生した場合などである。

つぎに、印刷プロセス２０は、リカバリ可能なエラーであると判断した場合に（ステップＳ７２、Ｙｅｓ）、リトライ回数の上限を超えていないか確認後（ステップＳ７３）、管理サーバ１ｂに再接続を要求する。この際、印刷プロセス２０は、接続リトライ回数のカウンタをインクリメントする（ステップＳ７４）。

これにて、再接続要求を受けた負荷分散装置４は、複数の管理サーバ１から負荷の少ない１つの管理サーバ１ｂに接続を行う（ステップＳ６２）。上記処理（ステップＳ６２〜６８、ステップＳ７２〜７４）は、管理サーバと出力サーバの接続・ダウンロードが確立するまで繰り返されるが、所定のリトライ回数を超えた場合は（ステップＳ７３、Ｙｅｓ）、印刷プロセス２０は、失敗であるとして処理を終了する。

ステップＳ６８の説明に戻り、管理サーバ１からの接続と帳票データの受信に成功した出力サーバ３の印刷プロセス２０は、ブロック番号をインクリメントする（ステップＳ６９）。

そして、出力サーバ３は、印刷プロセス２０の処理により、ダウンロードした帳票データを出力装置６に出力する（ステップＳ７０）。

そして、印刷プロセス２０は、ブロック番号から、さらにダウンロードすべき帳票データがあるか否か判断する（ステップＳ７１）。

帳票データが終わりであると判断した場合は（ステップＳ７１、Ｙｅｓ）、印刷プロセス２０を、成功であるとして終了し、まだダウンロードすべき帳票データがあると判断した場合は（ステップＳ７１，Ｎｏ）、ステップＳ６７に戻って、出力サーバ３の印刷プロセス２０は、次の帳票データのダウンロードを受ける（ステップＳ６７）。

これにてシステム処理の説明を終える。上記リジューム処理により、帳票出力中に管理サーバのシステムダウンやネットワーク接続障害等のエラーが発生した場合でも、自動的に他の管理サーバに接続するので、印刷処理を遅滞なく再開することができる。また、印刷プロセスにおいて帳票ブロック番号を管理することとしたので、印刷を継続する場合に出力結果の重複が生じないという効果を奏する。

つまり、エラーが生じた場合であっても、正常時と比較して印刷が中断するなどの極端な性能劣化を発生することなく印刷プロセスを自動再開することができる。

［帳票データ転送スレッドの処理］
一方、管理サーバ１側で実現されるリジューム機能について、上記出力サーバ３の印刷プロセス２０の処理によるリジューム処理の際の、接続されている管理サーバ１の帳票取出しＡＰＩ１１ｃの処理の詳細について説明する。

図１２に示すように、出力サーバ３の印刷プロセス２０から取出し要求を受けた管理サーバ１ｂ（現在接続に係る管理サーバ１であり管理サーバ１ｂに限らない）の帳票取出しＡＰＩ１１ｃは、ブロック番号を受信する（ステップＳ８１）。

つぎに、管理サーバ１ｂは、帳票取出しＡＰＩ１１ｃの処理により、共有ディスク１２に格納された帳票データファイルを開く（ステップＳ８２）。

つづいて、管理サーバ１ｂは、帳票取出しＡＰＩ１１ｃの処理により、受信したブロック番号を判断する（ステップＳ８３）。

ブロック番号が１以上の場合、帳票取出しＡＰＩ１１ｃの処理により、帳票データファイルのデータをブロック番号分だけ読み飛ばして（ステップＳ８４）、残りの帳票データを出力サーバ３に送信する（ステップＳ８５）。

一方、ブロック番号が０の場合は、読み飛ばしを行わず、全ての帳票データファイルを出力サーバ３に送信する（ステップＳ８５）。

以上で、帳票取出しＡＰＩ１１ｃの処理の説明を終える。

上記のように、管理サーバ１の帳票取出しＡＰＩ１１ｃと出力サーバ３の印刷プロセス２０が連動して、帳票の管理を行うことにより、エラーが生じた場合でも、既にダウンロードされた帳票データを読み飛ばして、ダウンロードを再開することができるので、再度はじめから帳票データを送受信することがなく、帳票配信出力処理の時間を軽減することができる。また、これにより、出力の重複がなく、エラーが生じた時点から出力を再開することができるので、出力順序を保証することができる。

［他の実施の形態］
さて、これまで本発明の実施の形態について説明したが、本発明は、上述した実施の形態以外にも、上記特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施の形態にて実施されてよいものである。

特に、本帳票配信管理システムの実施の形態では出力サーバ３は、出力装置６に接続された構成を、一例として示したが、本帳票配信管理システムはこれに限られず、出力サーバ３と出力装置６が一体として同一筐体に印刷装置等として構成されていてもよい。

また、実施の形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

このほか、上記文献中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データ等のパラメータを含む情報、データベース構成については、特記する場合を除いて任意に変更することができる。

また、図示の各構成要素は機能概略的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、管理サーバ１、出力サーバ２または負荷分担装置４の各装置が備える処理機能、特に取出し手段１１、配信手段１０、制御手段１８にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）および当該ＣＰＵにて解釈実行されるプログラムにて実現することができ、あるいは、ワイヤードロジックによるハードウェアとして実現することも可能である。尚、プログラムは、後述する記録媒体に記録されており、必要に応じて機械的に読み取られる。すなわち、ＲＯＭまたはＨＤなどの記憶部などには、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）として協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、本発明の方法をコンピュータに実行させるコンピュータプログラムは、任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本発明に係るプログラムを、コンピュータ読み取り可能な記録媒体に格納することもできる。ここで、この「記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等の任意の「可搬用の物理媒体」、あるいは、ＬＡＮ、ＷＡＮ、インターネットに代表されるネットワークを介してプログラムを送信する場合の通信回線や搬送波のように、短期にプログラムを保持する「通信媒体」を含むものとする。

また、「プログラム」とは、任意の言語や記述方法にて記述されたデータ処理方法であり、ソースコードやバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）に代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施の形態に示した各装置において記録媒体を読み取るための具体的な構成、読み取り手順、あるいは、読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

各装置の記憶部に格納されるデータベースまたは格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラムやテーブルやデータベースやウェブページ用ファイル等を格納する。

また、各装置は、既知のパーソナルコンピュータ、ワークステーション等の情報処理装置を接続し、該情報処理装置に本発明の方法を実現させるソフトウェア（プログラム、データ等を含む）を実装することにより実現してもよい。

更に、各装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じた任意の単位で、機能的または物理的に分散・統合して構成することができる。特に本発明の実施の形態では、ユーザアプリケーション９を管理サーバ１内で稼動するよう構成したが、これに限られず、管理サーバ１とは、別筐体の制御部でユーザアプリケーション９の機能を実現していてもよく、さらに、該別筐体は、センター外のネットワークで接続された場所に配置・構成されていてもよい。

この発明の帳票配信システムの構成図である。 この発明の帳票配信システムの順序制御の説明図である。 この発明の帳票配信システムの管理サーバの構成図である。 この発明の帳票配信システムの配信スレッドの処理を説明するフローチャートである。 この発明の帳票配信システムの印刷多重度制御サービスの構成図である。 この発明の帳票配信システムの出力要求キューの構成図である。 この発明の帳票配信システムの出力要求受信スレッドの処理を説明するフローチャートである。 この発明の帳票配信システムの多重度制御スレッドの処理を説明するフローチャートである。 この発明の帳票配信システムの印刷プロセス起動スレッドの処理を説明するフローチャートである。 この発明の帳票配信システムの出力サーバから管理サーバへアクセスして出力データを取り出す構成図である。 この発明の帳票配信システムの出力サーバから管理サーバへアクセスして出力データを取り出し出力する処理およびリジューム機能を説明するフローチャートである。 配信スレッドで実現するリジューム機能を示す図である。 この発明の帳票配信システムのテーブルの説明図である。 従来一般のＭＳリモート印刷の説明図である。 従来一般の技術を示す図である。 従来技術の順序制御の説明図である。

符号の説明

１、１ａ、１ｂ、１ｃ：管理サーバ
２：データベース
３：出力サーバ
４：負荷分散装置
５：ネットワーク
６：出力装置
９：ユーザアプリケーション
１０：配信手段
１１：取出し手段
１１ａ：帳票登録ＡＰＩ
１１ｂ：印刷指示ＡＰＩ
１１ｃ：帳票取出しＡＰＩ
１２：共有ディスク
１３：配信スレッド監視テーブル
１４：論理あて先定義テーブル
１５：論理デバイス定義テーブル
１６：キュー管理テーブル
１８：制御手段
１８ａ：印刷多重度制御サービス
１９：ディスク
１９ａ：出力要求キュー
２０：印刷プロセス
２１：監視スレッド
２２：配信スレッド
２５：出力要求受信スレッド
２７：出力要求通知オブジェクト
２８：多重度制御スレッド
２９：多重度制御カウンタ
３０：印刷プロセス起動スレッド

Claims (2)

1. 複数の帳票管理サーバ装置と、ネットワークに接続された帳票出力サーバ装置と、該複数の帳票管理サーバ装置と該ネットワークとの間に接続された負荷分散装置と、を備えた帳票配信システムにおいて、
   上記帳票出力サーバ装置は、
   複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に帳票データの転送を要求する転送要求手段と、
   転送された帳票データのブロック番号を記憶する帳票ブロック番号記憶手段と、
   システムエラーまたはネットワーク接続障害を検知するエラー検出手段と、
   上記エラー検知手段によって、帳票データの転送時にエラーが検知された場合に、上記帳票ブロック番号記憶手段から、エラー発生直前の帳票ブロック番号を読み出し、上記帳票管理サーバ装置に再接続を要求する再接続要求手段と、
   を備え、
   上記負荷分散装置は、
   上記転送要求手段によって上記帳票出力サーバ装置から要求があった場合に、上記複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に接続する管理サーバ接続手段と、
   上記再接続要求手段によって、再接続の要求を受けた場合に、負荷の少ない他の複数の帳票管理サーバ装置の一と接続する他サーバ接続手段と、
   を備え、
   上記複数の帳票管理サーバ装置は、
   上記帳票出力サーバ装置に帳票データを転送する帳票データ転送手段と、
   上記他サーバ接続手段によって接続された場合に、通知されたエラー発生直前の帳票ブロック番号に基づいて、該帳票ブロック番号から帳票データを帳票出力装置に転送する帳票転送再開手段と、
   を備えたことを特徴とする帳票配信システム。
2. 複数の帳票管理サーバ装置と、ネットワークに接続された帳票出力サーバ装置と、該複数の帳票管理サーバ装置と該ネットワークとの間に接続された負荷分散装置と、を備えた帳票配信システムにおける帳票配信方法であって、
   上記帳票出力サーバ装置において実行される、
   複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に帳票データの転送を要求する転送要求ステップと、
   上記負荷分散装置において実行される、
   上記転送要求ステップによって上記帳票出力サーバ装置から要求があった場合に、上記複数の帳票管理サーバ装置のうち１つの帳票管理サーバ装置に接続する管理サーバ接続ステップと、
   上記複数の帳票管理サーバ装置において実行される、
   上記管理サーバ接続ステップによって接続された場合に、上記帳票出力サーバ装置に帳票データを転送する帳票データ転送ステップと、
   上記帳票出力サーバ装置において実行される、
   上記帳票データ転送ステップによって転送された帳票データのブロック番号を記憶する帳票ブロック番号記憶ステップと、
   システムエラーまたはネットワーク接続障害を検知するエラー検出ステップと、
   上記エラー検知ステップによって、帳票データの転送時にエラーが検知された場合に、帳票ブロック番号記憶手段から、エラー発生直前の帳票ブロック番号を読み出し、再接続を要求する再接続要求ステップと、
   上記負荷分散装置において実行される、
   上記再接続要求ステップによって、再接続の要求を受けた場合に、負荷の少ない他の複数の帳票管理サーバ装置の一と接続する他サーバ接続ステップと、
   上記複数の帳票管理サーバ装置のうち他の１つの帳票管理サーバ装置において実行される、
   上記他サーバ接続ステップによって接続された場合に、通知されたエラー発生直前の帳票ブロック番号に基づいて、該帳票ブロック番号から帳票データを帳票出力装置に転送する帳票転送再開ステップと、
   を含んだことを特徴とする帳票配信方法。

Images