説明

データ転送システム、データ転送方法及びデータ転送プログラム

【課題】効率的にクライアント端末からのデータをホストシステムに転送するためのデータ転送システム、データ転送方法及びデータ転送プログラムを提供する。
【解決手段】電文を受信した締上げ管理サーバ40の制御部41は、締上げ処理を実行する。そして、この電文を送信電文保管部43に保管する。そして、制御部41は、稼動状態のメインHUB30を特定して電文の送信処理を実行する。その後、送信した電文に対して「通信エラー」の戻り電文を受信した場合、制御部41は迂回回数を加算する。そして、迂回回数が基準値を超えていない場合、制御部41は、送信電文保管部43において保管されている電文を取得し、再送信を行なう。一方、正常に送信された場合には、制御部41は、保管電文を削除する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、クライアント端末からのデータをホストシステムに転送するためのデータ転送システム、データ転送方法及びデータ転送プログラムに関する。
【背景技術】
【0002】
クライアント端末において生成した処理依頼電文を、ネットワークを利用して、ホストシステムに送信し、この電文についての処理をホストシステムにおいて実行させる場合がある。例えば、金融機関においても、店舗に設置された端末から、銀行のホストシステムに処理依頼電文を送信することがある。この場合、ネットワークに接続されているシステムにおける特定アプリケーションの稼動状態を把握しておく必要がある。このために、特定アプリケーションの動作状態を判別するコンピュータシステムについての技術が検討されている(例えば、特許文献1参照。)。この文献に記載されたコンピュータシステムにおいては、業務処理用コンピュータが所定の業務処理を行なうと共に、定期的に生存通知を送信する。そして、業務処理用コンピュータと通信回線を介して接続された別のコンピュータは生存通知を受信し、最後に生存通知を受信してからの経過時間に基づいて動作状態を判別する。
【0003】
また、金融機関では、各店舗で管理している現金等の精査等を行なう勘定の締上げ処理が行なわれている。具体的には、ホストシステムが、自動取引装置における入金金額、入金件数、支払い金額、支払い件数等のデータ(ホスト計)を記憶する。また、自動取引装置が、この自動取引装置における入金金額、入金件数、支払い金額、支払い件数等のデータ(端末計)を記憶する。そして、ホスト計と端末計とを突き合わせることによって締上げ処理を実行する。
【0004】
このような締上げ処理の負担を低減し、営業店の業務効率を向上させるための締上げ処理システムも検討されている(例えば、特許文献2参照。)。この文献に記載された締上げ処理システムは、金融取引を行なう自動機と、金融機関のホストコンピュータと、自動機に接続された業務センタのサーバとを備える。この自動機は、自動機における入出金に関する記録を格納し、ホストコンピュータは、自動機における入出金に関する記録を格納する。そして、サーバは、自動機に格納された記録とホストコンピュータに格納された記録とを突き合わせて自動機の締上げ処理を実行する。
【特許文献1】特開2007−265215号公報(図1)
【特許文献2】特開2005−234677号公報(図1)
【発明の開示】
【発明が解決しようとする課題】
【0005】
ところで、ネットワークにおいて、障害に迅速に対応するために、複数の通信中継装置、処理装置を準備している場合がある。ここで、システムの稼動状態を確認できない場合には、迅速に代替装置に切り替えて、速やかにデータの転送ができることが望ましい。特に、締上げ処理のように、システム間のデータ転送を伴う業務管理サーバを利用する場合には、障害発生時に障害対応の負荷が利用者にかかるが、このような負荷を軽減できることが望ましい。
【0006】
本発明は、上記課題を解決するためになされたものであり、その目的は、効率的にクライアント端末からのデータをホストシステムに転送するためのデータ転送システム、データ転送方法及びデータ転送プログラムを提供することにある。
【課題を解決するための手段】
【0007】
上記問題点を解決するために、請求項1に記載の発明は、処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムであって、前記業務管理サーバが、前記クライアント端末から処理依頼電文を受信した場合、前記処理依頼電文を用いて業務管理処理を実行する業務管理手段と、前記処理依頼電文を一時保存する保管管理手段と、前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムに転送し、前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を削除させる通信管理手段とを備えたことを要旨とする。
【0008】
請求項2に記載の発明は、請求項1に記載のデータ転送システムにおいて、前記業務管理サーバが、処理依頼電文を送信したクライアント端末の利用者を特定し、前記処理依頼電文に対応して、前記利用者の業務状況の集計情報の更新処理を実行することを要旨とする。
【0009】
請求項3に記載の発明は、請求項1又は2に記載のデータ転送システムにおいて、前記業務管理サーバが、前記通信中継装置から、正常又は異常の稼動状態を識別するためのステータス情報を取得するステータス確認手段を更に備え、前記通信管理手段は、前記ステータス確認手段が正常のステータス情報を取得した通信中継装置を特定し、この通信中継装置を用いてデータ転送することを要旨とする。
【0010】
請求項4に記載の発明は、請求項1〜3のいずれか1つに記載のデータ転送システムにおいて、前記業務管理サーバが、前記通信中継装置に対して、前記業務管理サーバの稼動状態を識別するためのステータス情報を送信する生存通知手段を更に備えたことを要旨とする。
【0011】
請求項5に記載の発明は、請求項1〜4のいずれか1つに記載のデータ転送システムにおいて、前記保管管理手段は、前記通信中継装置から転送不可を示す戻り電文を受信した場合、迂回回数を記憶し、前記迂回回数が基準値以上になった場合には、前記クライアント端末に障害通知を送信する処理を更に実行することを要旨とする。
【0012】
請求項6に記載の発明は、処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムを用いてデータ転送を行なう方法であって、前記業務管理サーバが、前記クライアント端末から処理依頼電文を受信した場合、前記処理依頼電文を用いて業務管理処理を実行する業務管理段階と、前記処理依頼電文を一時保存する保管管理段階と、前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムに転送し、前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理段階において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理段階において一時保存した処理依頼電文を削除させる通信管理段階とを実行することを要旨とする。
【0013】
請求項7に記載の発明は、処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムを用いてデータ転送を行なうプログラムであって、前記業務管理サーバを、前記クライアント端末から処理依頼電文を受信した場合
、前記処理依頼電文を用いて業務管理処理を実行する業務管理手段、前記処理依頼電文を一時保存する保管管理手段、前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムにデータ転送し、前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を削除させる通信管理手段として機能させることを要旨とする。
【0014】
(作用)
請求項1、6又は7に記載の発明によれば、業務管理サーバが、クライアント端末から処理依頼電文を受信した場合、処理依頼電文を用いて業務管理処理を実行する。そして、処理依頼電文を一時保存し、通信中継装置を介して、処理依頼電文をホストシステムに転送する。ここで、通信中継装置から転送不可を示す戻り電文を受信した場合、保管管理手段において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、ホストシステムに転送する。一方、通信中継装置から転送完了を示す戻り電文を受信した場合、保管管理手段において一時保存した処理依頼電文を削除させる。これにより、業務管理サーバにおいて業務管理処理を実行するとともに、通信障害が発生した場合にも、一時記憶された電文を用いて迅速に対応することができる。
【0015】
請求項2に記載の発明によれば、業務管理サーバが、処理依頼電文を送信したクライアント端末の利用者を特定し、処理依頼電文に対応して、利用者の業務状況の集計情報の更新処理を実行する。これにより、ホストシステムで処理される処理依頼電文を用いて、業務管理を行なうことができる。
【0016】
請求項3に記載の発明によれば、業務管理サーバが、通信中継装置から、正常又は異常の稼動状態を識別するためのステータス情報を取得する。そして、通信管理手段は、ステータス確認手段が正常のステータス情報を取得した通信中継装置を特定し、この通信中継装置を用いてデータ転送する。これにより、正常に稼動している通信中継装置にデータ転送を行なうことができる。
【0017】
請求項4に記載の発明によれば、業務管理サーバが、通信中継装置に対して、業務管理サーバの稼動状態を識別するためのステータス情報を送信する。これにより、通信中継装置は、業務管理サーバの稼動状態を把握して、通信方法を制御することができる。
【0018】
請求項5に記載の発明によれば、保管管理手段は、通信中継装置から転送不可を示す戻り電文を受信した場合、迂回回数を記憶し、迂回回数が基準値以上になった場合には、クライアント端末に障害通知を送信する処理を実行する。これにより、障害が継続している場合には、利用者に通知することができる。
【発明の効果】
【0019】
本発明によれば、効率的にクライアント端末からのデータをホストシステムに転送することができる。
【発明を実施するための最良の形態】
【0020】
以下、本発明を具体化した一実施形態を、図1〜5に従って説明する。本実施形態では、クライアント端末からのデータを中継してホストシステムに転送する場合に用いるデータ転送システム、データ転送方法及びデータ転送プログラムとして説明する。ここでは、図1に示すように、ネットワークを介して、クライアント端末としての営業店端末10と端末制御サーバ20とが接続されている。そして、端末制御サーバ20は、通信中継装置としてのメインHUB30を介して、業務管理サーバとしての締上げ管理サーバ40や、
銀行ホストシステム50に接続される。本実施形態では、複数のメインHUB30からなるメインHUB群と、複数の締上げ管理サーバ40からなる締上げ管理サーバ群を用いて、データ転送処理を実行する。
【0021】
営業店端末10は、営業店から銀行ホストシステム50に対して各種取引処理依頼電文を送信する場合に用いるコンピュータ端末である。
一方、銀行ホストシステム50は、営業店端末10から受信した取引処理依頼電文を用いて金融取引処理を実行する。具体的には、口座管理処理、振込処理や振替処理等を実行する。
【0022】
端末制御サーバ20は、各営業店端末10からの取引処理依頼電文を受信するサーバコンピュータシステムである。端末制御サーバ20は、受信した取引処理依頼電文をメインHUB30に転送する。
【0023】
メインHUB30は、ネットワークの中継機器であり、端末制御サーバ20、締上げ管理サーバ40や銀行ホストシステム50等から受信した電文を、他のシステムに転送する処理を実行する。このメインHUB30は、図2に示すように、制御部31やステータス管理部32を備える。この制御部31は、図示しないCPU等の制御手段、RAM及びROM等のメモリを有し、後述する処理(通信状況監視段階、ステータス通知段階、生存確認段階、転送管理段階等を含む処理)を行なう。このためのデータ転送プログラムを実行することにより、制御部31は、通信状況監視手段311、ステータス通知手段312、生存確認手段313、転送管理手段314等として機能する。
【0024】
通信状況監視手段311は、ネットワークにおける通信状態の監視処理を実行する。
ステータス通知手段312は、各締上げ管理サーバ40に対してステータス通知を送信する処理を実行する。このステータス通知は、銀行ホストシステム50とメインHUB30との間の接続状態(正常や異常)を通知するための制御電文である。このステータス通知手段312は、構成定義ファイルに記録された一定時間間隔で締上げ管理サーバ40にステータス通知を送信する。また、メインHUB30が非稼動となる場合には、ステータス通知手段312は、「NG」のステータス通知を送信し、その後に転送管理手段314は処理を停止する。
【0025】
生存確認手段313は、締上げ管理サーバ40から受信した生存通知に基づいて、ステータス管理部32に記録されたステータス情報を更新する処理を実行する。
転送管理手段314は、受信した電文を他のシステムに転送する処理を実行する。転送管理手段314は、締上げ管理サーバ40に対してデータを転送する場合、ステータス管理部32を用いて、生存通知の受信日時から基準時間が経過していない締上げ管理サーバ40を特定して送信する。
【0026】
ステータス管理部32には、図3(a)に示すように、締上げ管理サーバ40の稼働状況を記録したステータス管理レコード320が格納される。このステータス管理レコード320は、締上げ管理サーバ40から生存通知を受信した場合に更新記録される。このステータス管理レコード320は、サーバ識別子、受信日時に関するデータを含んで構成される。
【0027】
サーバ識別子データ領域には、生存通知を送信した締上げ管理サーバ40を特定するための識別子に関するデータが記録される。
受信日時データ領域には、この締上げ管理サーバ40から生存通知を受信した日付や時刻に関するデータが記録される。
【0028】
一方、締上げ管理サーバ40は、各営業店において行なわれた取引についての集計等を行ない、出納業務における勘定の適否を検証するための締上げ処理(業務管理処理)を実行するサーバコンピュータシステムである。このために、営業店端末10と銀行ホストシステム50との間で通信される電文を中継する。この締上げ管理サーバ40は、図2に示すように、制御部41やステータス管理部42、送信電文保管部43を備える。そして、制御部41は、営業店端末10から受信した電文に基づいて締上げ処理を実行するとともに、各電文を他のシステムに転送する処理を実行する。この制御部41は、図示しないCPU等の制御手段、RAM及びROM等のメモリを有し、後述する処理(ステータス確認段階、生存通知段階、業務管理段階、通信管理段階、保管管理段階等を含む処理)を行なう。このためのデータ転送プログラムを実行することにより、制御部41は、ステータス確認手段411、生存通知手段412、締上げ管理手段413、通信管理手段414、保管管理手段415等として機能する。
【0029】
ステータス確認手段411は、メインHUB30から受信したステータス通知に基づいて、ステータス管理部42に記録されたステータス情報を更新する処理を実行する。更に、ステータス確認手段411が、メインHUB30から最後にステータス通知を受信した受信日時から待機基準時間を経過しても、このメインHUB30からステータス通知を受信できない場合には、ステータス管理部42にタイムアウトフラグを設定する。
【0030】
生存通知手段412は、ステータスフラグが正常を示す「OK」のメインHUB30に対して、一定の時間間隔で、生存通知を送信する処理を実行する。そして、後述するステータス管理部42のステータスフラグが異常を示す「NG」となった場合、及びステータス通知を所定時間、受信していない場合には、このメインHUB30への生存通知の送信を停止する。
【0031】
締上げ管理手段413は業務管理手段として機能し、業務管理として締上げを行なうために、取引処理依頼電文に基づいて、営業店端末10を特定し、営業店(クライアント端末の利用者)毎に入金金額、入金件数、支払い金額、支払い件数等の集計を行なうための集計情報を蓄積する。そして、所定の時刻(例えば、業務終了後)に締上げを行なう取引により締上げ処理を実行する。
【0032】
通信管理手段414は、電文の通信管理を行なう。具体的には、通信管理手段414は、送信先テーブルを保持しており、受信した電文の内容に応じて、業務ロジックに対応する送信先のシステムを決定する。例えば、通信管理手段414は、端末制御サーバ20を介して、営業店端末10から受信した取引処理依頼電文を、メインHUB30を介して銀行ホストシステム50に送信する。また、通信管理手段414は、電文の内容に応じて後続の処理が必要な場合(連携処理の場合)には、銀行ホストシステム50からメインHUB30を介して受信した電文を、再度メインHUB30を介して銀行ホストシステム50に返信する。ここで、連携処理とは、複数の個別取引を連続して一連の取引として扱う処理であり、締上げ管理サーバ40は各個別取引において締上げ管理を行なう。
【0033】
更に、通信管理手段414は、ステータス管理部42を用いて、ステータスフラグが「OK」であり、かつタイムアウトフラグが記録されていないメインHUB30を特定して、このメインHUB30に対する電文の送信処理を実行する。
【0034】
保管管理手段415は、メインHUB30に送信する電文を送信電文保管部43に一時保管する。そして、メインHUB30を介して通信処理を実行できない場合には、迂回の可否を判定する。このため、保管管理手段415は、迂回可否を判定するための迂回回数の基準値を記憶している。
【0035】
ステータス管理部42には、図3(b)に示すように、メインHUB30の稼働状況が記録されたステータス管理レコード420が格納される。このステータス管理レコード420は、メインHUB30の通信状態を検知した場合に更新記録される。このステータス管理レコード420は、HUB識別子、タイムアウトフラグ、受信日時、ステータスフラグに関するデータを含んで構成される。
【0036】
HUB識別子データ領域には、ステータス通知を送信したメインHUB30を特定するための識別子に関するデータが記録される。
タイムアウトフラグデータ領域には、このメインHUB30との通信について、前回のステータス通知から待機基準時間を経過した時刻においても、新たなステータス通知を受信していない場合に、タイムアウトを特定するためのフラグに関するデータが記録される。
【0037】
受信日時データ領域には、このメインHUB30からステータス通知を受信した日付や時刻に関するデータが記録される。
ステータスフラグデータ領域には、このメインHUB30の稼動状態(HUBステータス)を特定するフラグに関するデータが記録される。本実施形態では、稼動状態にある場合にはステータスフラグとして「OK」が記録され、非稼動状態の場合にはステータスフラグとして「NG」が記録される。
【0038】
また、送信電文保管部43には、図3(c)に示すように、締上げ管理サーバ40が、メインHUB30に送信した電文を一時的に保管するための保管管理レコード430が格納される。この保管管理レコード430は、締上げ管理サーバ40が、電文を送信した場合に格納され、送信先において正常に処理された場合に削除される。この保管管理レコード430は、電文識別子、送信日時、迂回回数、送信電文に関するデータを含んで構成される。
【0039】
電文識別子データ領域には、メインHUB30に対して送信した電文を特定するための識別子に関するデータが記録される。
送信日時データ領域には、メインHUB30に対して電文を送信した日付や時刻に関するデータが記録される。
【0040】
迂回回数データ領域には、複数のメインHUB30を利用して迂回した回数に関するデータが記録される。
送信電文データ領域には、メインHUB30に対して送信した電文が記録される。
【0041】
上記のように構成されたシステムを用いて、営業店端末10と銀行ホストシステム50との間の通信を転送する転送制御処理手順を図4、5に従って説明する。
(転送制御処理)
図4に示すように、締上げ管理サーバ40の制御部41は、端末制御サーバ20から送信された電文の受信処理を実行する(ステップS1−1)。具体的には、制御部41の通信管理手段414は、営業店端末10から送信された処理依頼電文を、メインHUB30を介して受信する。
【0042】
この場合、締上げ管理サーバ40の制御部41は、取引情報の蓄積処理を実行する(ステップS1−2)。具体的には、制御部41の通信管理手段414は、受信した処理依頼電文を締上げ管理手段413に供給する。そして、締上げ管理手段413は、締上げ処理のために、この処理依頼電文に関する情報(集計情報)を記憶する。この集計情報は、業後に締上げ処理を行なうために利用される。
【0043】
次に、締上げ管理サーバ40の制御部41は、電文の保管処理を実行する(ステップS1−3)。具体的には、制御部41の通信管理手段414は、受信した処理依頼電文を保管管理手段415に供給する。この保管管理手段415は、メインHUB30に送信する電文を、この電文の電文識別子に関連付けて送信電文保管部43に一時記憶する。この場合、保管管理手段415は、システムタイマから現在時刻を取得し、保管管理レコード430に送信日時を記録する。更に、保管管理手段415は、保管管理レコード430において、迂回回数として「0」を記録する。
【0044】
次に、締上げ管理サーバ40の制御部41は、送信先サーバの決定処理を実行する(ステップS1−4)。具体的には、制御部41の通信管理手段414は、送信先テーブルを用いて、この電文の内容に応じて、送信先サーバを決定する。
【0045】
次に、締上げ管理サーバ40の制御部41は、送信先HUBの決定処理を実行する(ステップS1−5)。具体的には、制御部41の通信管理手段414は、ステータス管理部42からステータスフラグとして「OK」が記録されているステータス管理レコード420を抽出し、稼働状態であるメインHUB30を特定する。
【0046】
そして、締上げ管理サーバ40の制御部41は、電文の送信処理を実行する(ステップS1−6)。具体的には、制御部41の通信管理手段414は、先のステップにおいて特定したメインHUB30に電文を送信する。
【0047】
そして、締上げ管理サーバ40の制御部41は、戻り電文の待機処理を実行する(ステップS1−7)。具体的には、制御部41の通信管理手段414は、送信時刻からの経過時間を計測しながら、送信先であるメインHUB30からの戻り電文を待機する。
【0048】
この待機処理においては、図5に示すように、締上げ管理サーバ40の制御部41は、戻り電文を受信したかどうかについての判定処理を実行する(ステップS2−1)。具体的には、制御部41の通信管理手段414は、メインHUB30から送信電文に対応する戻り電文の受信の有無を判定する。
【0049】
戻り電文を受信していない場合(ステップS2−1において「NO」の場合)には、締上げ管理サーバ40の制御部41は、タイムアウトしたかどうかの判定処理を実行する(ステップS2−2)。具体的には、制御部41の通信管理手段414は、タイムアウトを判断するための待機基準時間に関するデータを保持しており、この待機基準時間と送信時刻からの経過時間とを比較する。経過時間が待機基準時間を越えておらず、タイムアウトしていない場合(ステップS2−2において「NO」の場合)には、再度、戻り電文を待機する。
【0050】
一方、経過時間が待機基準時間を越えて、タイムアウトした場合(ステップS2−2において「YES」の場合)には、締上げ管理サーバ40の制御部41は、エラー通知電文の作成処理を実行する(ステップS2−3)。具体的には、制御部41の通信管理手段414は、電文を送信できなかったことを示すエラー通知電文を生成する。ここでは、通信管理手段414は、エラーの原因(タイムアウト)に応じて、送信できなかったことを示すエラー通知電文を作成する。
【0051】
次に、締上げ管理サーバ40の制御部41は、保管電文の削除処理を実行する(ステップS2−4)。具体的には、制御部41の通信管理手段414は、エラーになった電文識別子(ここでは、タイムアウトした電文の電文識別子)を特定し、この電文識別子に関連付けられた保管管理レコード430を送信電文保管部43から削除する。
【0052】
そして、締上げ管理サーバ40の制御部41は、電文の返信処理を実行する(ステップS2−5)。具体的には、制御部41の通信管理手段414は、作成したエラー通知電文を、端末制御サーバ20を介して営業店端末10に送信する。
【0053】
一方、戻り電文を受信した場合(ステップS2−1において「YES」の場合)、締上げ管理サーバ40の制御部41は、「業務エラー」の戻り電文かどうかについての判定処理を実行する(ステップS2−6)。具体的には、制御部41の通信管理手段414が、戻り電文において「業務エラー」を示すフラグが含まれているかどうかを確認する。
【0054】
「業務エラー」の戻り電文を受信した場合(ステップS2−6において「YES」の場合)には、締上げ管理サーバ40の制御部41は、エラー通知電文の作成処理を実行する(ステップS2−3)。具体的には、制御部41の通信管理手段414は、業務エラーになったことを示すエラー通知電文を生成する。そして、締上げ管理サーバ40の制御部41は、エラーになった電文識別子(ここでは、戻り電文に含まれる電文識別子)を特定し、保管電文の削除処理(ステップS2−4)、電文(エラー通知電文)の返信処理(ステップS2−5)を実行する。
【0055】
「業務エラー」の戻り電文でない場合(ステップS2−6において「NO」の場合)、締上げ管理サーバ40の制御部41は、転送不可を示す「通信エラー」の戻り電文かどうかについての判定処理を実行する(ステップS2−7)。具体的には、制御部41の通信管理手段414が、戻り電文において「通信エラー」を示すフラグが含まれているかどうかを確認する。
【0056】
ここで、「通信エラー」以外の戻り電文を受信した場合(ステップS2−7において「NO」の場合)、転送完了を示す戻り電文を受信したことになる。この場合には、締上げ管理サーバ40の制御部41は、連携処理における後続取引があるかどうかについての判定処理を実行する(ステップS2−8)。具体的には、まず、制御部41の通信管理手段414は、電文の内容に基づいて連携処理の対象かどうかを判断する。そして、連携処理の場合には、送信先テーブルの業務ロジックにおいて後続取引が必要かどうかを判断する。ここで、送信先テーブルにおいて連携処理の後続取引が残っている場合(ステップS2−8において「YES」の場合)には、この電文を銀行ホストシステム50に返信するため、ステップS1−2からの処理を繰り返す。
【0057】
一方、連携処理の対象でない場合や連携処理においてすべての処理を完了している場合(ステップS2−8において「NO」の場合)には、保管電文の削除処理を実行する(ステップS2−9)。具体的には、制御部41の通信管理手段414は、戻り電文において電文識別子を特定し、この電文識別子に関連付けられた保管管理レコード430を送信電文保管部43から削除する。
【0058】
そして、締上げ管理サーバ40の制御部41は、電文の返信処理を実行する(ステップS2−5)。具体的には、制御部41の通信管理手段414は、銀行ホストシステム50における処理結果を示す戻り電文を、端末制御サーバ20を介して営業店端末10に送信する。
【0059】
また、「通信エラー」の戻り電文を受信した場合(ステップS2−7において「YES」の場合)、締上げ管理サーバ40の制御部41は、迂回回数の加算処理を実行する(ステップS2−10)。具体的には、制御部41の保管管理手段415は、送信電文保管部43に記録された保管管理レコード430において、この電文についての保管管理レコード430を特定し、迂回回数に「1」を加算する(インクリメント)。
【0060】
次に、締上げ管理サーバ40の制御部41は、迂回回数が基準値を超えているかどうかについての判定処理を実行する(ステップS2−11)。具体的には、制御部41の保管管理手段415は、この迂回回数と基準値とを比較する。
【0061】
迂回回数が基準値を超えていない場合(ステップS2−11において「NO」の場合)、締上げ管理サーバ40の制御部41は、保存電文の呼出処理を実行する(ステップS2−12)。具体的には、制御部41の保管管理手段415は、送信電文保管部43において保管されている電文を取得し、通信管理手段414に供給する。そして、再送信を行なうため、通信管理手段414はステップS1−5からの処理を繰り返す。
【0062】
一方、迂回回数が基準値を超えている場合(ステップS2−11において「YES」の場合)、締上げ管理サーバ40の制御部41は、エラー通知電文の作成処理を実行する(ステップS2−3)。具体的には、制御部41の通信管理手段414は、迂回回数が基準値を超えていることを示すエラー通知電文を生成する。
【0063】
そして、締上げ管理サーバ40の制御部41は、保管電文の削除処理(ステップS2−4)、電文の返信処理(ステップS2−5)を実行する。
本実施形態によれば、以下のような効果を得ることができる。
【0064】
・ 本実施形態においては、締上げ管理サーバ40の制御部41は、端末制御サーバ20から電文を受信した場合(ステップS1−1)、取引情報の蓄積処理(ステップS1−2)を実行する。そして、制御部41は、電文の送信処理を実行する(ステップS1−6)。これにより、ネットワーク上で通信される電文を利用して締上げ処理を実現することができる。
【0065】
・ 本実施形態においては、メインHUB30の制御部31は、通信状況監視手段311、ステータス通知手段312、生存確認手段313、転送管理手段314等として機能する。ステータス通知手段312は、各締上げ管理サーバ40に対してステータス通知を送信する処理を実行する。そして、転送管理手段314は、締上げ管理サーバ40に対してデータを転送する場合、ステータス管理部32を用いて、生存通知の受信日時から基準時間が経過していない締上げ管理サーバ40を特定する。
【0066】
また、締上げ管理サーバ40の制御部41は、ステータス確認手段411、生存通知手段412、締上げ管理手段413、通信管理手段414、保管管理手段415等として機能する。生存通知手段412は、ステータスフラグが「OK」のメインHUB30に対して、一定時間間隔で、生存通知を送信する処理を実行する。そして、転送管理手段314は、ステータス管理部42を用いて、ステータスフラグが「OK」であり、ステータス通知の受信日時から基準時間が経過していないメインHUB30を特定する。これにより、メインHUB30や締上げ管理サーバ40は、稼動状態にあるシステムを選択して、確実に通信を行なうことができる。
【0067】
・ 本実施形態においては、締上げ管理サーバ40の制御部41は、電文の保管処理を実行する(ステップS1−3)。そして、通信エラーの戻り電文を受信した場合(ステップS2−7において「YES」の場合)、制御部41は、迂回回数の加算処理を実行する(ステップS2−10)。そして、制御部41は、迂回回数と基準値とを比較し、迂回回数が基準値を超えていない場合(ステップS2−11において「NO」の場合)、締上げ管理サーバ40の制御部41は、保存電文を呼び出す(ステップS2−12)。そして、この電文を用いて、制御部41は、電文の送信処理を実行する(ステップS1−6)。これにより、通信エラーが生じた場合にも、速やかに代替経路を利用して通信を行なうことができる。
【0068】
なお、上記各実施形態は以下のように変更してもよい。
○ 上記実施形態では、本発明のデータ転送方法を締上げ管理サーバ40に適用したが、データ転送方法の適用対象はこれに限定されるものではなく、ネットワークの中継装置に広く適用することができる。
【0069】
○ 上記実施形態では、保管管理手段415は、迂回可否を判定するための迂回回数の基準値を記憶している。そして、保管管理手段415は、メインHUB30に送信する電文を送信電文保管部43に一時保管する。そして、メインHUB30を介して通信処理を実行できない場合には、迂回の可否を判定する。ここで、この基準回数は、電文の取引処理依頼内容(依頼種別)に応じて、変更するように構成してもよい。この場合には、保管管理手段415には、依頼種別に対応して迂回回数を決定するためのテーブルを保持させておく。そして、戻り電文を取得した場合、依頼種別に対応して迂回回数を決定して、迂回の可否を判断する。これにより、電文の内容に応じて、臨機応変な対応を実現することができる。
【0070】
○ 上記実施形態では、端末制御サーバ20から電文を受信した締上げ管理サーバ40の制御部41は、締上げ処理のために取引情報の蓄積処理を実行する(ステップS1−2)。これに加えて、通信状態や戻り電文の状況に応じて、締上げ管理手段413が処理状況を記録するように構成することも可能である。これにより、処理依頼の完結状況によって、締上げ処理を的確に行なうことができる。
【0071】
○ 上記実施形態では、迂回回数が基準値を超えている場合(ステップS2−11において「YES」の場合)、締上げ管理サーバ40の制御部41は、エラー通知電文の作成処理を実行する(ステップS2−3)。これに加えて、連携処理について、1回目の取引処理の完了後に、2回目の取引処理ができなかった場合、銀行ホストシステム50において完了している取引処理を取り消すようにしてもよい。この処理を、図6を用いて説明する。
【0072】
この場合、締上げ管理サーバ40の制御部41は、連携処理における後続取引かどうかについての判定処理を実行する(ステップS3−1)。具体的には、制御部41の通信管理手段414は、電文の内容に基づいて連携処理の後続取引かどうかを判断する。連携処理における後続取引でない場合(ステップS3−1において「NO」の場合)には、締上げ管理サーバ40の制御部41は、そのままエラー通知電文の作成処理を実行する(ステップS2−3)。
【0073】
一方、連携処理における後続取引である場合(ステップS3−1において「YES」の場合)には、締上げ管理サーバ40の制御部41は、先行取引の特定処理を実行する(ステップS3−2)。具体的には、制御部41の通信管理手段414は、送信先テーブルを用いて、電文の内容に対応する業務ロジックに基づいて先行取引を特定する。
【0074】
そして、締上げ管理サーバ40の制御部41は、先行取引の成立照会処理を実行する(ステップS3−3)。具体的には、制御部41の通信管理手段414は、特定した先行取引の状況を照会するための照会電文を作成し、メインHUBを介して、銀行ホストシステム50に送信する。
【0075】
次に、締上げ管理サーバ40の制御部41は、先行取引が成立したかどうかについての判定処理を実行する(ステップS3−4)。具体的には、制御部41の通信管理手段414は、照会電文に対応する照会結果電文を銀行ホストシステム50から取得し、先行取引の成立状況を判断する。
【0076】
そして、先行取引が成立していない場合(ステップS3−4において「NO」の場合)には、締上げ管理サーバ40の制御部41は、そのままエラー通知電文の作成処理を実行する(ステップS2−3)。一方、先行取引が成立している場合(ステップS3−4において「YES」の場合)には、締上げ管理サーバ40の制御部41は、先行取引の取消処理を実行する(ステップS3−5)。具体的には、制御部41の通信管理手段414は、成立した取引を取り消すための取消電文を作成し、メインHUBを介して、銀行ホストシステム50に送信する。
【0077】
連携処理においては、複数の個別取引を成立させる必要があるが、後続取引ができない場合には、先行取引の意義がなくなる。この場合、締上げ管理サーバ40の制御部41が先行取引を取り消すため、営業店端末10における取消作業を不要にして、利用者の負荷を軽減することができる。
【図面の簡単な説明】
【0078】
【図1】本発明の実施形態のシステム概略図。
【図2】締上げ管理サーバ及びメインHUBの機能ブロックの説明図。
【図3】各データ記憶部に記録されたデータの説明図であって、(a)はメインHUBのステータス管理部、(b)は締上げ管理サーバのステータス管理部、(c)は送信電文保管部に記録されたデータの説明図。
【図4】本実施形態の処理手順の説明図。
【図5】本実施形態の処理手順の説明図。
【図6】他の実施形態の処理手順の説明図。
【符号の説明】
【0079】
10…営業店端末、20…端末制御サーバ、30…メインHUB、31…制御部、311…通信状況監視手段、312…ステータス通知手段、313…生存確認手段、314…転送管理手段、32…ステータス管理部、40…締上げ管理サーバ、41…制御部、411…ステータス確認手段、412…生存通知手段、413…締上げ管理手段、414…通信管理手段、415…保管管理手段、42…ステータス管理部、43…送信電文保管部、50…銀行ホストシステム。

【特許請求の範囲】
【請求項1】
処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムであって、
前記業務管理サーバが、
前記クライアント端末から処理依頼電文を受信した場合、前記処理依頼電文を用いて業務管理処理を実行する業務管理手段と、
前記処理依頼電文を一時保存する保管管理手段と、
前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムに転送し、
前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、
前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を削除させる通信管理手段と
を備えたことを特徴とするデータ転送システム。
【請求項2】
前記業務管理サーバが、処理依頼電文を送信したクライアント端末の利用者を特定し、
前記処理依頼電文に対応して、前記利用者の業務状況の集計情報の更新処理を実行することを特徴とする請求項1に記載のデータ転送システム。
【請求項3】
前記業務管理サーバが、
前記通信中継装置から、正常又は異常の稼動状態を識別するためのステータス情報を取得するステータス確認手段を更に備え、
前記通信管理手段は、前記ステータス確認手段が正常のステータス情報を取得した通信中継装置を特定し、この通信中継装置を用いてデータ転送することを特徴とする請求項1又は2に記載のデータ転送システム。
【請求項4】
前記業務管理サーバが、前記通信中継装置に対して、前記業務管理サーバの稼動状態を識別するためのステータス情報を送信する生存通知手段を更に備えたことを特徴とする請求項1〜3のいずれか1つに記載のデータ転送システム。
【請求項5】
前記保管管理手段は、
前記通信中継装置から転送不可を示す戻り電文を受信した場合、迂回回数を記憶し、
前記迂回回数が基準値以上になった場合には、前記クライアント端末に障害通知を送信する処理を更に実行することを特徴とする請求項1〜4のいずれか1つに記載のデータ転送システム。
【請求項6】
処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムを用いてデータ転送を行なう方法であって、
前記業務管理サーバが、
前記クライアント端末から処理依頼電文を受信した場合、前記処理依頼電文を用いて業務管理処理を実行する業務管理段階と、
前記処理依頼電文を一時保存する保管管理段階と、
前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムに転送し、
前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理段階において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、
前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理段階にお
いて一時保存した処理依頼電文を削除させる通信管理段階と
を実行することを特徴とするデータ転送方法。
【請求項7】
処理依頼電文を送信するクライアント端末及び処理依頼電文に応じて処理を実行するホストシステムに対して、複数の通信中継装置を介して接続された業務管理サーバを備えたデータ転送システムを用いてデータ転送を行なうプログラムであって、
前記業務管理サーバを、
前記クライアント端末から処理依頼電文を受信した場合、前記処理依頼電文を用いて業務管理処理を実行する業務管理手段、
前記処理依頼電文を一時保存する保管管理手段、
前記通信中継装置を介して、前記処理依頼電文を前記ホストシステムに転送し、
前記通信中継装置から転送不可を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を取得し、他の通信中継装置を介して、前記ホストシステムに転送し、
前記通信中継装置から転送完了を示す戻り電文を受信した場合、前記保管管理手段において一時保存した処理依頼電文を削除させる通信管理手段
として機能させることを特徴とするデータ転送プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate


【公開番号】特開2009−237789(P2009−237789A)
【公開日】平成21年10月15日(2009.10.15)
【国際特許分類】
【出願番号】特願2008−81406(P2008−81406)
【出願日】平成20年3月26日(2008.3.26)
【出願人】(592131906)みずほ情報総研株式会社 (187)
【出願人】(592259978)株式会社みずほ銀行 (117)
【Fターム(参考)】