JP2003288221A - データ処理システム - Google Patents

Abstract

(57)【要約】 【課題】 サーバコンピュータへの処理要求送信後のク
ライアントコンピュータの待ち時間を短くしてユーザの
ストレス感を軽減し作業効率を向上することを課題とす
る。 【解決手段】 クライアントコンピュータ１１が送信し
たデータ処理要求に応じたタスクをサーバコンピュータ
５１が実行し、その結果をクライアントコンピュータ１
１に返信するデータ処理システムにおいて、クライアン
トコンピュータ１１からのデータ処理要求を受け付ける
受付管理部５１Ａと、該管理部５１Ａが受け付けた処理
要求の統計情報を作成し、かつ該処理要求に対応するタ
スク５１Ｅをデータベース５２に対して実行する実行管
理部５１Ｄと、上記統計情報に基いて、タスク５１Ｅの
実行時間が短くなるように、該タスク５１Ｅの新規登録
又は属性変更を行う管理者用コンピュータ５３とを設け
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントコン
ピュータとサーバコンピュータとを通信回線で接続した
データ処理システムに関し、コンピュータネットワーク
の技術分野に属する。

【０００２】

【従来の技術】従来、インターネット技術を利用した企
業内イントラネットは概ね次のように構築されている。
本社のコンピュータセンタにあるサーバコンピュータに
Ｗｅｂサーバを搭載し、支社のクライアントコンピュー
タにＷｅｂブラウザを搭載する。クライアントコンピュ
ータはＵＲＬでＷｅｂサーバのアドレスを指定すること
によりインターネットを介してサーバコンピュータにア
クセスし、ブラウザ画面で本社のデータベースに対する
登録や照会等のデータ処理要求を送信する。サーバコン
ピュータは処理要求を受け取ると、該要求に対応する処
理タスクを実行し、その処理結果をクライアントコンピ
ュータに返信する。このように、クライアント側からサ
ーバ側への処理要求の送信、サーバ側でのタスクの実
行、そしてサーバ側からクライアント側への処理結果の
返信という一連の動作が行われる。

【０００３】

【発明が解決しようとする課題】それゆえ、サーバ側で
のタスク実行に時間がかかると、クライアント側では結
果が返信されてくるまでの間ただ待つしかなく、ユーザ
のストレス感が大きくなる。また、クライアントコンピ
ュータの占有時間が長くなり、例えば、いったん１群の
処理要求を出した後に、すぐにまた別の処理要求を追加
で行うこと等ができず、時間が無駄に消費されて作業効
率が低下する。

【０００４】本発明は、上記のような不具合に対処する
もので、処理要求送信後のクライアント側での無駄な待
ち時間を可及的に短くし、これによりユーザのストレス
感の軽減及び作業効率の向上を図ることを主たる課題と
する。以下、さらにその他の課題を含め、本発明を詳し
く説明する。

【０００５】

【課題を解決するための手段】上記課題を解決するた
め、特許請求の範囲の請求項１に記載の発明は、クライ
アントコンピュータが送信したデータ処理要求に応じた
タスクをサーバコンピュータが実行し、その結果をクラ
イアントコンピュータに返信するデータ処理システムで
あって、クライアントコンピュータからのデータ処理要
求を受け付ける処理要求受付手段と、上記受付手段が受
け付けた処理要求の統計情報を作成する統計情報作成手
段と、同じく上記受付手段が受け付けた処理要求に対応
するタスクをデータベースに対して実行するタスク実行
手段と、上記統計情報作成手段が作成した統計情報に基
いて、タスク実行時間が短くなるように、上記タスク実
行手段が実行するタスクの新規登録又は属性変更を行う
タスク設定手段とが設けられていることを特徴とする。

【０００６】この発明によれば、クライアント側からの
処理要求の統計情報に基いて、サーバ側のタスク実行時
間が短くなるように、タスクが新規登録されたり、ある
いは属性が変更される。例えば、ある時間帯に、ある処
理要求が集中するようなときは、その処理要求に対応す
るタスクを新規に登録して、なるべく多くのタスクで対
応するようにする。あるいは、１回の要求取出件数を多
くして、なるべく多くの要求を１度に処理するようにす
る。これにより、サーバ側のタスク実行時間が可及的に
短くなり、よって処理要求送信後のクライアント側の無
駄な待ち時間が可及的に短くなり、その結果、ユーザの
ストレス感が軽減し、また作業効率が向上する。

【０００７】次に、請求項２に記載の発明は、請求項１
に記載の発明において、クライアントコンピュータから
の処理結果の返信要求を受け付ける返信要求受付手段
と、上記受付手段が受け付けた返信要求に基いて、処理
結果が出ているときは処理結果を、処理結果が出ていな
いときは処理中である旨を、クライアントコンピュータ
に返信する返信手段とが設けられていることを特徴とす
る。

【０００８】この発明によれば、クライアント側から処
理結果の返信要求があった場合において、すでにタスク
が完了し、処理結果が出ていれば、処理結果をクライア
ント側に返信する一方、まだタスクが完了しておらず、
処理結果が出ていないときでも、処理中である旨をクラ
イアント側に報告するから、たとえ結果の返信を待ち合
わせている間でも、ユーザのストレス感や不安感が軽減
する。

【０００９】つまり、請求項１に記載の発明では、サー
バ側でのタスク実行時間を可及的に短くすることで、ユ
ーザの待ち時間を短くし、それによりストレス感を軽減
しようとするのに対し、この請求項２に記載の発明で
は、サーバ側でのタスク実行時間が短いかどうかとはま
た別の観点から、処理結果が返信されてくるまでの間に
おいても処理中であるという進捗状況をユーザに知らせ
ることによって、ユーザのストレス感、及び、本当に要
求した処理が行われているかどうかの懐疑心や不安感を
軽減しようとするものである。

【００１０】次に、請求項３に記載の発明は、請求項１
又は２に記載の発明において、処理要求受付手段が受け
付けた処理要求を蓄積する処理要求蓄積手段が設けら
れ、タスク実行手段は、上記蓄積手段が蓄積した処理要
求を、上記受付手段の受付動作と非同期に順に処理して
いくことを特徴とする。

【００１１】この発明によれば、例えばキューイングの
手法を用いることにより、処理要求の受付けと、タスク
の実行とを切り離して個々別々に動作させることがで
き、タスクは、ユーザがクライアントコンピュータを操
作しているバックグラウンドで進行する。その結果、ユ
ーザは、処理要求をサーバコンピュータに送信し、サー
バコンピュータが処理要求を受け付けた後は、サーバコ
ンピュータからの結果返信の有無やそのタイミングに束
縛されることなく、いつでもまた再び（たとえ前に送っ
た要求に対するサーバコンピュータからの返信がまだ届
いていなくても）別の要求を続けて送信することが可能
となる。よって、たとえサーバ側の処理に長い時間がか
かり、結果の返信が時間的にかなり遅れて返ってきて
も、ユーザはその間クライアントコンピュータの前で徒
に待ち合わせる必要がなくなり、ストレス感が大きくな
らず、また作業効率の低下も解消される。

【００１２】つまり、請求項１に記載の発明では、サー
バ側でのタスク実行時間を可及的に短くすることで、ユ
ーザの待ち時間を短くし、それによりストレス感を軽減
し、また作業効率を向上しようとするのに対し、この請
求項３に記載の発明では、サーバ側でのタスク実行時間
が短いかどうかとはまた別の観点から、クライアント側
からサーバ側への処理要求の送信と、サーバ側でのタス
クの実行とを、一連の動作としてではなく、非同期に、
相互に独立して行える動作とすることによって、ユーザ
のストレス感の軽減及び作業効率の向上を図ろうとする
ものである。

【００１３】次に、請求項４に記載の発明は、請求項１
から３のいずれかに記載の発明において、クライアント
コンピュータとサーバコンピュータとはインターネット
で接続されていることを特徴とする。

【００１４】この発明によれば、通信プロトコルとして
ｈｔｔｐが採用されるインターネット技術を利用した企
業内イントラネット等において、上記請求項１から３に
記載の発明と同様の作用効果が得られる。この場合、例
えば、サーバコンピュータのＷｅｂサーバには、クライ
アント側からの処理要求や返信要求の受付け等、比較的
負荷の軽い機能のみ担当させる。一方、負荷の重いタス
クの実行は、サーバコンピュータに常駐する、独立・専
用の、例えばデータベースサーバに行わせる。こうする
ことで、１回性の単純な通信プロトコルであるｈｔｔｐ
は、クライアント−サーバ間における負荷の軽い要求の
受付動作のみに関与するから、ユーザの待ち時間は短く
て済む。そして、ｈｔｔｐによるコンピュータ間の通信
とは切り離されたバックグラウンドにおいて、要求され
た処理タスクが非同期に実行されることになる。以下、
発明の実施の形態を通して、本発明をさらに詳しく説明
する。

【００１５】

【発明の実施の形態】図１に示すように、本実施の形態
に係るデータ処理システムは、インターネットＸを利用
した、例えば銀行や商社等の企業内イントラネットに適
用されている。本店のコンピュータセンタに２つのサー
バコンピュータ５１，５２が備えられている。一方のサ
ーバ５１にはＷｅｂサーバが搭載され、他方のサーバ５
２にはデータベースサーバが搭載されている。サーバコ
ンピュータ５１はデータベースサーバ５２と連携したト
ランザクション機能を具備する。もちろん１台のコンピ
ュータに集約してもよい。これらのサーバコンピュータ
５１，５２は、システム管理者用のクライアントコンピ
ュータ５３を始め、本店内の多数のノードとＬＡＮで接
続されている。システム管理者は、管理クライアント用
コンピュータ５３を用いて、当該イントラネットの運用
パフォーマンスを管理し、その集計・統計結果に応じて
タスクの新規登録や属性変更等を行う。

【００１６】地方の各支店（２つの支店のみ図示）にも
それぞれＬＡＮが構築されている。各支店の担当者が扱
うクライアントコンピュータ１１，２１はＷｅｂブラウ
ザを搭載している。クライアント１１，２１はＵＲＬで
Ｗｅｂサーバのアドレスを指定することにより、支店Ｌ
ＡＮのルータ１９，２９、インターネットＸ、本店ＬＡ
Ｎのルータ５９を介して、サーバコンピュータ５１と接
続される。

【００１７】このようなネットワーク化されたコンピュ
ータシステムにあっては、従来、一般に、サーバ５１に
Ｗｅｂサーバを搭載し、ユーザのクライアントコンピュ
ータ１１，２１より、ブラウザ画面にて、データベース
５２の更新や照会の要求を出す。要求はｈｔｔｐプロト
コルを利用して、Ｗｅｂサーバ５１が受け取り、要求に
応じた処理を行い、その結果を端末１１，２１に返信す
る。これが、インターネット技術・Ｗｅｂ技術を用いた
データ登録・照会システムの一般的な形態である。この
ようなネットワークシステムでは、クライアント側には
Ｗｅｂブラウザだけを搭載すれば済む。一方、Ｗｅｂ技
術を用いない、いわゆるオーダメイド型の企業内情報シ
ステムにあっては、サーバや当該システムに合わせて各
クライアントコンピュータにも全ての必要なアプリケー
ションを搭載しなければならなかった。よって、上記の
ようにＷｅｂ技術を用いると、クライアント・サーバ型
システムに比べて、ユーザのクライアントコンピュータ
にはブラウザのみあればよく、データ通信システム、デ
ータ処理システムの導入が容易になるという利点があ
る。しかし、その反面、データ登録等の更新業務や帳票
照会等の照会業務では、次のような問題が生じる。

【００１８】第１には、処理の一連性の問題がある。更
新・照会要求は基本的にサーバ上のＷｅｂサーバになさ
れる。Ｗｅｂサーバはこの要求を契機にデータベースへ
の更新・照会処理プログラムを起動する。そして、Ｗｅ
ｂサーバはこの問い合わせ結果を待ち合わせたうえで、
要求を上げたブラウザへ通知するのが一般的な形態であ
る。なぜなら、Ｗｅｂサーバ自身は１つの要求に対する
処理や返答を要求と非同期に行ったり、結果を返答する
機能を有さないからである。これは、厳密には、Ｗｅｂ
で用いられるｈｔｔｐプロトコルが、１度要求を出し
て、その返信を受けたら完結する、という１回性のシン
プルなプロトコルであることに起因する。したがって、
ｈｔｔｐプロトコルを用いる場合は、またＷｅｂサーバ
を用いる場合は、システム的には、要求、更新又は照
会、返信という処理を、不可分の一連の処理として実装
せざるを得ない。すると、多くのユーザが同時に集中し
て要求を出す場合や、処理時間が数分間にも亘るような
場合は、この方式では不都合が生じる。すなわち、デー
タベースの性能や、登録・照会処理の性能が、そのまま
Ｗｅｂサーバの待ち合わせ時間に影響を与えるからであ
る。そして、一度に多数のユーザが集中すればなおさら
問題が大きくなる。ここで、上記のようにサーバ側の処
理に時間がかかるのは、例えば、膨大な量の情報を蓄積
したデータベースに対してデータの登録や照会等の処理
タスクを行う場合や、あるいは、上記のように、同一の
タスクに対して要求が集中している場合等が挙げられ
る。

【００１９】２つめには、クライアント側でブラウザが
占有される問題がある。例えば、ブラウザ画面で必要デ
ータを入力して、更新要求を出し、その後、実際にサー
バ上のデータベースを更新するまで、端末側のブラウザ
の操作や制御は占有されてしまう。つまり、前述のよう
に、要求受付処理と、更新・照会処理とが一連の処理と
して行われるため、１つの要求に対する結果の出力が完
結するまで次の要求が行えないのである。

【００２０】３つめには、負荷分散の問題がある。この
ような形態のシステムでサーバコンピュータにかかる負
荷分散を考えた場合、複数のＷｅｂサーバを準備するこ
とが考えられる。しかし、要求の種類毎や、要求を出す
部署や支店毎に、どのようにＷｅｂサーバを振り分ける
かが問題であり、例えば、単に１支店に１Ｗｅｂサーバ
とかいう単純な割り振り方をすると、その後の状況の変
化に伴う臨機応変な対応・変更ができず、効率的なシス
テムの運用が困難となる。

【００２１】そこで、本システムでは、まず、クライア
ント１１，２１側からの要求の受付動作を、キューイン
グ方式を採用して、サーバ５１，５２側のタスクの実行
動作から独立させた。すなわち、要求受付処理と、更新
又は照会処理と、結果返信処理とを、不可分の一連の処
理としてではなく、それぞれ相互に非同期に独立して実
行可能な個々別々の機能として実装した。

【００２２】本システムでは、（１）ユーザの要求を受
け付けて、エントリするまで（図２に示す要求受付管理
テーブル５１Ｂ，５１Ｃに要求を挿入してキューに加え
るまで）の「受付管理」（受付管理部５１Ａで行われ
る）と、（２）要求エントリ５１Ｂ，５１Ｃを定期的に
監視し、取り出し、実行モジュール５１Ｅに引き渡し、
終了ステータスを要求エントリ５１Ｂ，５１Ｃに反映さ
せる「実行管理」（実行管理部５１Ｄで行われる）と、
（３）処理モジュール５１Ｅが処理した結果をユーザの
要求に応じて返信する「還元管理」（還元管理部５１Ｇ
で行われる）という、３つの独立した機能５１Ａ，５１
Ｄ，５１Ｇを具備する。各機能５１Ａ，５１Ｄ，５１Ｇ
は相互に独立して非同期に実行される。

【００２３】受付管理部５１Ａは、クライアントコンピ
ュータ１１，２１からの要求を受けると、要求管理テー
ブル（キュー）５１Ｂ，５１Ｃへ要求をエントリする。
実行管理部５１Ｄは、要求管理テーブル５１Ｂ，５１Ｃ
を一定間隔で監視し、新たなエントリがあれば、該当す
るデータベース５２への登録・照会処理５１Ｅを起動す
る。そして、処理完了後、要求エントリ５１Ｂ，５１Ｃ
のステータスを処理完了に更新する。処理完了となった
要求エントリ５１Ｂ，５１Ｃに対して、ユーザが結果の
返信要求を出すと、還元管理部５１Ｇは、処理結果（帳
票照会結果ファイル）５１Ｆをクライアントコンピュー
タ１１，２１に返信する。

【００２４】ここで、Ｗｅｂサーバ５１には、「受付管
理」５１Ａと「還元管理」５１Ｇという比較的負荷の軽
い機能だけを担当させている。「実行管理」５１Ｄは、
サーバ５１上の別の常駐の専用タスクが受け持ち、Ｗｅ
ｂサーバが行う「受付管理」５１Ａと「還元管理」５１
Ｇとは非同期に処理が行われる。もちろん、これに代え
て、例えばデータベースサーバ５２が「実行管理」５１
Ｄを担当してもよい。

【００２５】このように構成した本システムの特徴は、
第１に、ユーザ側コンピュータ１１，２１における操作
の自由度が増すことである。ユーザ側では、必要な要求
を、サーバ５１側の実行処理５１Ｄとは非同期に、かつ
短時間のうちに連続して繰返し行うことができ（５１
Ａ）、要求を出すサイクルを格段に短くできる。状況照
会（５１Ｇ）に関しても、後でまとめて一括して印刷す
ること等ができ、時間を効率的に使える。

【００２６】第２に、本システムでは、モジュール５１
Ｅが処理した結果ファイル５１Ｆだけでなく、未だ処理
中であれば、処理の進捗情報をユーザに還元するように
している。ユーザは、要求受付キュー５１Ｂ，５１Ｃの
ステータス情報を照会することができ、自己が出したデ
ータ処理要求の進捗具合を把握できる。これにより、結
果ファイル５１Ｆが作成され、最終的に結果がユーザに
還元・返信されるまで、ユーザが待たされるストレス感
や、処理が実行されているかどうかの懐疑心・不安感が
軽減する。また、タスク実行５１Ｄが、処理要求の受付
５１Ａと非同期に行われるから、比較的時間のかかる負
荷の重い処理タスクでも、気にせず実行可能となる。ま
た、この例のように、Ｗｅｂサーバ５１（受付管理５１
Ａ、還元管理５１Ｇ）と、データベースサーバ５２（実
行管理５１Ｄ）とを、別マシンとして機能別に配置する
ことも容易にできる。

【００２７】従来は、複数の処理をブラウザから一度に
要求・依頼したとき、全ての処理が終了するまで結果が
返ってこないので、全ての処理が完了するまで、後続の
処理（例えば、追加の処理要求や、あるいは、照会され
た帳票にユーザがコメント等を入力して印刷する、とい
ったような処理等）を続けて行うことができなかった。
これに対し、本システムでは、複数の処理を一度に依頼
して、サーバコンピュータがその処理を受け付けた後に
おいては、次の要求の受付けはいつでもしてくれるの
で、気兼ねなく後続の処理をすることができるし、ま
た、個々の処理の進捗状況が分かるので、終了した処理
から、順次、後続の作業（例えば、上でいうコメントの
入力後に印刷する作業）をすることができる。換言すれ
ば、待ち時間なく作業が継続できるという利点がある。
さらに、ユーザの側からは、複数の処理要求を周囲に気
兼ねすることなく（処理時間を気にせずに）、サーバに
対して依頼することができるというメリットもある。

【００２８】第３には、本システムでは、受付管理テー
ブル５１Ｂ，５１Ｃを監視するタスクの属性を、管理ク
ライアントコンピュータ５３で変更・修正することによ
り、柔軟な負荷分散制御を可能としている。要求受付キ
ュー５１Ｂ，５１Ｃを監視するタスクは、複数起動が可
能であり、それぞれが担当する要求の種類や、部署、最
大取出個数や、取出間隔、あるいは稼働時間等の属性を
予め登録しておくことができる。また、動的に、新たな
処理タスクを追加起動することも可能である。これによ
り、要求頻度の高い部署や、要求頻度の高い種類に対し
て、多数の処理タスクを割り当てたり、要求が集中する
時間帯だけ自動的に多くのタスクを起動したり、臨機応
変な対応・負荷制御が、１つのＷｅｂサーバ上で可能に
なる。

【００２９】第４に、本システムは統計情報集計機能を
有し、それにより負荷分散計画を支援できるようにして
いる。要求受付キュー５１Ｂ，５１Ｃは例えば任意の日
数で保存しておくことが可能である。これには、要求受
付時間、要求の種類、要求を出した部署、利用者、処理
時間等の情報が含まれており、例えば要求や処理状態の
時間帯別で統計情報を得ることができる。この情報を前
述の処理タスク設定時の状況分析情報として用いること
で、より効率的な負荷分散計画を立案することが可能と
なる。

【００３０】サーバコンピュータ５１は、図３に示すよ
うなタスクのスケジュールテーブル５１Ｈを格納してい
る。１つのタスク毎に、使用開始日や、タスクＩＤ、起
動するタイマー間隔（時間間隔）、対象とする支店の番
号（店番号）、対象とする帳票のＩＤ、最大取出件数
（１回の動作でまとめて処理する件数の最大値）、処理
の開始時刻や終了時刻等、種々の属性がレコードされて
いる。

【００３１】同じく、サーバコンピュータ５１は、図４
に示すような照会受付管理テーブル５１Ｃを格納してい
る。１つの処理要求がある毎に、受付番号が連番で付さ
れ、店番号が記録され、その他、受付日時や、帳票Ｉ
Ｄ、対応するタスクのＩＤ等、種々のデータが、受付順
に、このテーブル５１Ｃに登録・挿入される（キューイ
ング）。なお、図示しないが、登録受付管理テーブル５
１Ｂも同様の構成である。また、これらの各テーブル５
１Ｂ，５１Ｃ，５１Ｈは、管理コンピュータ５３で監視
することが可能である。

【００３２】次に、このデータ処理システムにおいて、
支店のユーザが端末１１，２１から本店のサーバコンピ
ュータ５１にアクセスして行う各種の業務を説明する。
まず、帳票照会業務から説明する。図５は、ユーザがク
ライアントコンピュータ１１，２１でサーバコンピュー
タ５１にログインしたときのブラウザ画面のうち、画面
左のメニュにおいて、帳票照会業務のうちの「帳票照
会」をクリックすると現われる帳票照会の画面である。
ユーザは、店番、科目、口座番号、照会したい帳票等の
必要事項を入力し、実行ボタン１０１をクリックする。
このとき、件数として複数入力が可能である。図例では
１０件をまとめて入力することが可能であり、そのうち
の４件分をまとめて帳票照会しようとしている（伝票１
〜４）。

【００３３】実行ボタン１０１をクリックすると、照会
要求がサーバコンピュータ５１に送信されると共に、端
末側１１，２１では図６に示す状況照会（帳票）の画面
に移行する。処理状況の欄に「処理待ち」あるいは「処
理中」と表示され、伝票１〜４の照会がいずれも未だ完
了していないことが示されている。よって、編集や印刷
の欄も「不可」表示がなされている。これは、照会要求
を出してからまだあまり時間が経過していないからであ
る。なお、「処理待ち」とは、送信した要求が照会受付
管理テーブル５１Ｃにエントリされたが、未だ対応する
タスクが起動・実行されていない状態をいい、「処理
中」とは、対応するタスクが起動・実行されているが、
未だ帳票照会結果ファイル５１Ｆが作成されていない状
態をいう。

【００３４】この状態で、少し時間が経過した後、最新
状態ボタン１０２をクリックすると、図７に示す状況照
会（帳票）の画面に移行する。処理状況のすべての欄に
「完了」と表示され、伝票１〜４の照会タスクがいずれ
も完了したことが示されている。すなわち、伝票１〜４
を照会するために必要なデータを集めた帳票照会結果フ
ァイル５１Ｆが全件（伝票１〜４）において作成された
のである。ただし、伝票２は、編集ができないようにロ
ックされている。しかし、印刷は全ての伝票１〜４で可
能である（チェックボックスをクリックして実行す
る）。その結果、編集ボタン１０３をクリックすれば、
図８に示すように、作表のためのアプリケーションソフ
トが起動し、帳票（図例では、伝票１）を表示したペー
ジが出現する。その際、帳票照会結果ファイル５１Ｆに
まとめられたデータがこのページ上に貼り付け展開され
る。

【００３５】このように、最終的に帳票照会が完了する
まで、ユーザは、適宜、最新状態ボタン１０２を押すこ
とにより、自己の要求した処理の現在の進捗状況をいつ
でも確認することができる。これにより、ユーザは待た
されるストレス感や不安感から開放される。なお、図７
には、全４件（伝票１〜４）がみな処理完了した状態を
図示したが、これに限らず、１件でも処理が完了すれ
ば、その件から、編集・印刷が可能になる。これによ
り、ユーザの待ち合わせ時間が可及的に短くなり、スト
レス感が一層軽減するし、また作業効率も向上する。

【００３６】以上のような動作を実現する具体的制御の
一例を図９から図１３を参照して説明する。まず、図９
のフローチャートは、タスクを管理しているスケジュー
ルテーブル５１Ｈ（図３参照）からタスクＩＤを取得し
た後、照会受付管理レコードを照会受付管理テーブル５
１Ｃに追加登録（エントリ：キューイング）するまでの
動作である。つまり、ユーザが処理要求を送信したとき
に受付管理部５１Ａが行う動作である。図５の帳票照会
画面で、照会する帳票を選択した後、実行ボタン１０１
を押すとこのプログラムが起動する。なお、参考とし
て、図２に、以下に説明する各ステップの番号をできる
限り付してある。

【００３７】まず、ステップＳ１で、受付店番号、帳票
ＩＤ、及び現在時刻を用いて、図３に示すスケジュール
テーブル５１Ｈを検索する。その結果、ステップＳ２
で、タスクＩＤを取得する（割り出す）。そして、ステ
ップＳ３で、図４に示す照会受付管理テーブル５１Ｃに
１件分のレコードを挿入する（エントリ：キューイン
グ）。レコードには、ステップＳ３に示したように、受
付番号（連番）や受付ユーザＩＤ等が含まれる他、進捗
状況コードに「処理待ち」、処理開始時刻に現在時刻が
セットされる。また、処理終了時刻として「未（だ）」
を入力する。

【００３８】次に、図１０は、図６の状況照会（帳票）
画面で最新状態ボタン１０２を押すとスタートする動作
である。つまり、ユーザが結果返信要求を送信したとき
に還元管理部５１Ｇが行う動作である。ステップＳ１１
で、照会受付管理テーブル５１Ｃを検索して、結果返信
要求又は状況照会要求がユーザ側から送られてきている
件を受付ユーザＩＤで抽出し、その後、ステップＳ１２
で、その結果をクライアント端末１１，２１の状況照会
画面に表示する。ただし、自分自身が登録した照会処理
のみが画面に表示され、他人が照会している分は表示さ
れない。

【００３９】次に、図１１は、図７のように、１つでも
完了した件が含まれる状況照会（帳票）画面で編集ボタ
ン１０３を押すと起動する動作である。これも、ユーザ
が結果返信要求を送信したときに還元管理部５１Ｇが行
う動作である。帳票のフォームである表を作成するため
の作表アプリケーションソフトを起動し、そのページに
帳票照会結果のデータ５１Ｆを展開・セットする。すな
わち、ステップＳ２１で、帳票照会結果ファイル５１Ｆ
をサーバコンピュータ５１から端末１１，２１にダウン
ロードする。次に、ステップＳ２２で、作表のためのア
プリケーションソフトを起動し、帳票照会結果ファイル
５１Ｆの中の該当するレコードをサーバコンピュータ５
１からクライアントコンピュータ１１，２１にダウンロ
ードする。

【００４０】一方、図１２及び図１３は、上記のような
Ｗｅｂサーバとクライアントコンピュータ１１，２１と
のやりとりと非同期に、独立して、そのバックグラウン
ドで動いている実行管理部５１Ｄが行うタスクの実行処
理である。図１２はタスクのメインフローチャートであ
り、スケジュールテーブル５１Ｈと照会受付管理テーブ
ル５１Ｃを参照して、実行すべき照会処理を抽出する。
ステップＳ３１で、現在時刻が、（処理開始時刻＋タイ
マ間隔）を経過しており、かつ状態コードが「実行中」
（タスクは「実行」又は「停止」のいずれか状態に選択
的に切り換えられる：例えば図２３のシステム監視業務
のうちのタスク監視ボタン参照）である照会受付管理レ
コードを最大取出件数内で抽出する。そして、ステップ
Ｓ３２で、抽出したレコードをすべて処理したか否かを
判定し、すべて処理するまで、ステップＳ３３で、最大
取出件数分の照会受付管理レコードについて照会処理タ
スクを繰り返し実行する。

【００４１】図１３は、図１２のステップＳ３３の照会
処理のより詳しい具体的内容である。すなわち、ステッ
プＳ４１で、照会受付管理テーブル５１Ｃの該当するレ
コードの進捗状況コードを「処理中」に書き換える。そ
れまでは、進捗状況コードは、「処理待ち」であった
（図９のステップＳ３参照）。また、次のステップＳ４
３では、進捗状況コードは「完了」に書き換える。これ
らの進捗状況コードの記録が、図６や図７の処理状況の
欄に反映されるのはいうまでもない。そして、ステップ
Ｓ４２で、帳票照会結果ファイル５１Ｆ（作表アプリケ
ーションに渡すデータファイル）を出力した後、ステッ
プＳ４３で、処理終了時刻を現在時刻に更新し（それま
では、図９のステップＳ３に示したように、「未」と記
されていた）、かつ上記したように、進捗状況コードを
「完了」に書き換える。以上の動作を、ステップＳ４４
で、抽出したすべての件で処理したと判定するまで繰り
返し実行する。

【００４２】次に、データの登録に関する業務を説明す
る。まず、図１４は、ユーザがクライアントコンピュー
タ１１，２１でサーバコンピュータ５１にアクセスした
ときのブラウザ画面のうち、画面左のメニュにおいて、
「登録内容照会」をクリックすると現われる登録内容照
会の画面である。ユーザは、店番、科目、口座番号、照
会したいデータ等の必要事項を入力し、実行ボタン１０
４をクリックすると、図１５に示す登録内容一覧の画面
に移行する。これにより、ユーザは、どのようなデータ
が登録されているかを把握することができる。

【００４３】次に、図１６は、ユーザがクライアントコ
ンピュータ１１，２１でサーバコンピュータ５１にアク
セスしたときのブラウザ画面のうち、画面左のメニュに
おいて、データ登録業務のうちの「データ照会」をクリ
ックすると現われるデータ照会の画面である。帳票照会
業務のときと同様、ユーザは、店番、科目、口座番号、
照会したいデータ等の必要事項を入力し、実行ボタン１
０５をクリックする。このとき、件数として複数入力が
可能である。図例では１０件をまとめて入力することが
可能であり、そのうちの５件分をまとめてデータ照会し
ようとしている。

【００４４】実行ボタン１０５をクリックすると、デー
タの照会要求がサーバコンピュータ５１に送信されると
共に、端末側１１，２１では図１７に示す状況照会（デ
ータ）の画面に移行する。処理状況の欄には「処理中」
と「完了」とが混在している。処理が完了した件の編集
ボタン１０６をクリックすると、図１８に示すように、
アプリケーションソフトが起動し、データ（この場合、
取引状況１）を表示したページが出現する。登録内容を
変更・修正したいときは、このページ上の登録シート作
成ボタン１０７をクリックする。すると、図示しない
が、データの書き換え専用の登録シートが現れ、該シー
ト上で登録内容を変更する作業を行う。

【００４５】然る後、図１９のデータ登録画面に移行
し、最新状態ボタン１０８を押して、登録内容の変更作
業にエラーがないことを確認した後、画面左下の登録ボ
タン１０９をクリックすることにより、登録要求が登録
受付管理テーブル５１Ｂにエントリされる。

【００４６】以上のような動作を実現する具体的制御の
一例を図２０から図２２を参照して説明する。まず、図
２０のフローチャートは、図１８の登録シート作成ボタ
ン１０７を押すとスタートする動作であり、ステップＳ
５１で、クライアントコンピュータ１１，２１上に登録
データを作成する。図２１のフローチャートは、図１９
の最新状態ボタン１０８を押すと起動する動作であり、
ステップＳ６１で、登録受付管理テーブル５１Ｂを検索
して、登録要求がユーザ側から送られてきている件を受
付ユーザＩＤで抽出し、その後、ステップＳ６２で、そ
の結果をクライアント端末１１，２１のデータ登録画面
に表示する。図２２のフローチャートは、図１９の登録
ボタン１０９を押すと起動する動作であり、ステップＳ
７１で、登録データをクライアントコンピュータ１１，
２１からサーバコンピュータ５１に送信する。そして、
ステップＳ７２で、登録受付管理テーブル５１Ｂに１件
分のレコードを挿入する（エントリ：キューイング）。
レコードには、帳票照会業務のステップＳ３と同様、受
付番号（連番）や受付ユーザＩＤ等が含まれる他、進捗
状況コードに「処理待ち」、処理開始時刻に現在時刻、
処理終了時刻に「未」が記入される。

【００４７】次に、このデータ処理システムにおいて、
本店のシステム管理者が管理用クライアントコンピュー
タ５３を操作して行うシステム監視業務、特に、登録・
照会状況の監視業務を説明する。図２３は、システム管
理コンピュータ５３の画面左のメニュにおいて、登録・
照会状況監視ボタン１１１をクリックすると現われる状
況監視画面である。図例では、伝票３について、個別
に、朝８時から夜８時までの間で、６０分毎に、データ
の登録要求及び照会要求がどのような分布で行われてい
るかの統計情報を作成する場合を示している。そして、
再度、状況監視ボタン１１１をクリックすると、図２４
に示すように、その統計結果がグラフ表示される。この
場合、朝８時から９時までの間に照会要求ばかり７件、
朝９時から１０時までの間にやはり照会要求ばかり３件
が集中していることが分かる。

【００４８】この動作をフローチャートで示すと、およ
そ図２５のようになる。すなわち、ステップＳ８１で、
集計対象の日時（例えば、昨日の朝８時から夜８時まで
の間等）、集計対象の帳票ＩＤ（例えば、カード１、伝
票１等）を検索の条件にして、照会受付管理テーブル５
１Ｃと登録受付管理テーブル５１Ｂとから、該当するレ
コードを抽出する。そして、ステップＳ８２で、その抽
出したレコードについて、入力された時間間隔毎（例え
ば、６０分毎等）に、集計結果を管理用コンピュータ５
３の画面に表示する。

【００４９】システム管理者は、この統計情報に基い
て、管理用コンピュータ５３を操作して、タスク実行時
間が短くなるように、タスクを新規登録し、あるいはタ
スクの属性を変更する。図２６は、システム管理コンピ
ュータ５３の画面左のメニュにおいて、タスク登録（新
規登録・属性変更）ボタンをクリックすると現われるタ
スク登録画面である。このページの右上の新規登録ボタ
ン１１２を押すと、図２７のステップ９１に示したよう
に、タスクを１件追加登録できる。その場合、上記例で
いえば、朝８時から９時あるいは１０時までの間に、伝
票３の照会要求に対応するタスクを追加するとよい。あ
るいは、図２６の一覧表をそのまま操作して各タスクの
属性を変更することもできる。その場合は、例えば、伝
票３の照会要求に対応するタスクの最大取出件数を多く
すればよい。いずれも、結果的に、サーバ５１側のタス
ク実行時間が短くなり、ひいては、処理要求送信後のク
ライアント１１，２１側の無駄な待ち時間が可及的に短
くなり、その結果、ユーザのストレス感が軽減し、また
作業効率が向上する。

【００５０】また、クライアント１１，２１側から処理
結果の返信要求があった場合において、すでにタスクが
完了し、処理結果５１Ｆが出ていれば、該処理結果５１
Ｆをクライアント１１，２１側に返信する一方、まだタ
スクが完了しておらず、処理結果５１Ｆが出来ていない
ときでも、図６に示したように、「処理中」や「処理待
ち」である旨をクライアント１１，２１側に報告するか
ら、たとえ結果の返信を待ち合わせている間でも、ユー
ザのストレス感や不安感が軽減する。

【００５１】また、処理要求の受付け５１Ａと、タスク
の実行５１Ｄとを切り離して個々別々に動作させること
ができ、タスク５１Ｅは、ユーザがクライアントコンピ
ュータ１１，２１を操作しているバックグラウンドで進
行する。その結果、ユーザは、処理要求をサーバコンピ
ュータ５１に送信した後において、サーバコンピュータ
５１からの結果返信の有無やそのタイミングに束縛され
ることなく、たとえ前に送った処理要求に対するサーバ
コンピュータ５１からの処理完了の返信がまだ届いてい
なくても、処理を受け付けた後は、いつでもまた再びク
ライアントコンピュータ１１，２１を用いて次の要求を
続けてサーバコンピュータ５１に送信することが可能と
なる。よって、たとえサーバ５１側の処理に長い時間が
かかり、結果５１Ｆの返信が時間的にかなり遅れて返っ
てきても、ユーザはその間クライアントコンピュータ１
１，２１の前で徒に待ち合わせる必要がなくなり、スト
レス感が大きくならず、また作業効率の低下も解消され
る。

【００５２】また、サーバコンピュータ５１のＷｅｂサ
ーバには、クライアント１１，２１側からの処理要求や
返信要求の受付け５１Ａ，５１Ｇ等、比較的負荷の軽い
機能のみ担当させ、負荷の重いタスクの実行５１Ｅは、
サーバコンピュータ５１に常駐する、独立・専用の、例
えばデータベースサーバ５１Ｄに行わせるようにしたか
ら、１回性の単純な通信プロトコルであるｈｔｔｐは、
クライアントコンピュータ１１，２１とサーバコンピュ
ータ５１との間における負荷の軽い要求の受付動作のみ
に関与するから、ユーザの待ち時間は短くて済む。そし
て、ｈｔｔｐによるコンピュータ間の通信とは切り離さ
れたバックグラウンドにおいて、要求された処理タスク
５１Ｄ，５１Ｅが非同期に実行されることになる。

【００５３】なお、本発明の趣旨を逸脱しない範囲で以
上の実施の形態を種々変更することが可能であることは
いうまでもなく、また図面に示した画面上のページの構
成や各要素のレイアウト等は一例に過ぎない。

【００５４】

【発明の効果】以上説明したように、本発明によれば、
処理要求送信後のクライアント側での無駄な待ち時間を
可及的に短くし、これによりユーザのストレス感の軽減
及び作業効率の向上を図ることができる。本発明は、ク
ライアントコンピュータとサーバコンピュータとを通信
回線で接続した企業内イントラネット等のデータ処理シ
ステム、ひいてはコンピュータネットワーク一般への広
汎な利用が期待できる。

【図面の簡単な説明】

【図１】 本発明の実施の形態に係るデータ処理システ
ムの全体構成図である。

【図２】 同システムの要部ブロック図である。

【図３】 同システムのサーバコンピュータに格納され
たタスクスケジュールテーブルである。

【図４】 同じく照会受付管理テーブルである。

【図５】 クライアントコンピュータの画面に表れる帳
票照会画面である。

【図６】 同じく状況照会画面である。

【図７】 同じく状況照会画面である。

【図８】 帳票を表わしたアプリケーションソフトが起
動した状態の画面である。

【図９】 帳票照会業務の具体的動作の一例を表わすフ
ローチャートである。

【図１０】 同フローチャートである。

【図１１】 同フローチャートである。

【図１２】 同フローチャートである。

【図１３】 同フローチャートである。

【図１４】 クライアントコンピュータの画面に表れる
登録内容照会画面である。

【図１５】 同じく登録内容一覧画面である。

【図１６】 同じくデータ照会画面である。

【図１７】 同じく状況照会画面である。

【図１８】 データを表わしたアプリケーションソフト
が起動した状態の画面である。

【図１９】 同じくデータ登録画面である。

【図２０】 データ登録業務の具体的動作の一例を表わ
すフローチャートである。

【図２１】 同フローチャートである。

【図２２】 同フローチャートである。

【図２３】 クライアントコンピュータの画面に表れる
登録・照会状況監視画面である。

【図２４】 同じく登録・照会状況の統計情報をグラフ
表示する画面である。

【図２５】 登録・照会状況の統計動作の具体的一例を
表わすフローチャートである。

【図２６】 クライアントコンピュータの画面に表れる
タスク登録画面である。

【図２７】 タスク登録動作の具体的一例を表わすフロ
ーチャートである。

【符号の説明】

１１，２１ クライアントコンピュータ ５１ サーバコンピュータ ５１Ａ 受付管理部（処理要求受付手段） ５１Ｂ 登録受付管理テーブル（処理要求蓄積手
段） ５１Ｃ 照会受付管理テーブル（処理要求蓄積手
段） ５１Ｄ 実行管理部（統計情報作成手段、タスク実
行手段） ５１Ｅ 更新・照会モジュール（タスク） ５１Ｆ 帳票照会結果ファイル（処理結果） ５１Ｇ 還元管理部（返信要求受付手段、返信手
段） ５１Ｈ タスクスケジュールテーブル ５２ データベース ５３ 管理用コンピュータ（タスク設定手段） Ｘ インターネット

Claims (4)

【特許請求の範囲】
1. 【請求項１】 クライアントコンピュータが送信したデ
   ータ処理要求に応じたタスクをサーバコンピュータが実
   行し、その結果をクライアントコンピュータに返信する
   データ処理システムであって、クライアントコンピュー
   タからのデータ処理要求を受け付ける処理要求受付手段
   と、上記受付手段が受け付けた処理要求の統計情報を作
   成する統計情報作成手段と、同じく上記受付手段が受け
   付けた処理要求に対応するタスクをデータベースに対し
   て実行するタスク実行手段と、上記統計情報作成手段が
   作成した統計情報に基いて、タスク実行時間が短くなる
   ように、上記タスク実行手段が実行するタスクの新規登
   録又は属性変更を行うタスク設定手段とが設けられてい
   ることを特徴とするデータ処理システム。
2. 【請求項２】 クライアントコンピュータからの処理結
   果の返信要求を受け付ける返信要求受付手段と、上記受
   付手段が受け付けた返信要求に基いて、処理結果が出て
   いるときは処理結果を、処理結果が出ていないときは処
   理中である旨を、クライアントコンピュータに返信する
   返信手段とが設けられていることを特徴とする請求項１
   に記載のデータ処理システム。
3. 【請求項３】 処理要求受付手段が受け付けた処理要求
   を蓄積する処理要求蓄積手段が設けられ、タスク実行手
   段は、上記蓄積手段が蓄積した処理要求を、上記受付手
   段の受付動作と非同期に順に処理していくことを特徴と
   する請求項１又は２に記載のデータ処理システム。
4. 【請求項４】 クライアントコンピュータとサーバコン
   ピュータとはインターネットで接続されていることを特
   徴とする請求項１から３のいずれかに記載のデータ処理
   システム。