JPH09501809A - 自動呼分配システムにおけるリアルタイムデータのアクセス方法 - Google Patents

Abstract

(57)【要約】 複数のクライアントシステム（１２，１１２，２１２）及びリアルタイムでトランザクションを処理するための少なくとも１つのホストサーバシステム（１３）を有する自動呼分配（ＡＣＤ）システム（１０）でデータを実質的に他のデータと同期してかつ該データを生成するイベントと実質的にリアルタイムて生成し報告する方法において、ホストサーバシステム（１３）側で、要求が処理され、あたかもリレーショナル・データベースに向けられたものであるかのような問合わせとしてその要求を実行するのに必要な全ての知識を含む実行可能なマシンコードに直接変換する方法が得られる。リアルタイム・インタラクション形の問合わせを用いて、ホストサーバシステム（１３）の共用メモリ（４４）中のデータにアクセスし、情報、通常は関係するトランザクションに関する状態情報を、その要求を出しているクライアントシステム（１２、１１２または２１２）に報告する。データベース・マネージャ・モジュール（４６）を用いて、静的データベース（４８）中のデータをモニタするとともに、適切な情報をデータアクセス・モジュール（４２）がアクセスすることができるよう共用メモリ（４４）に供給する。

Description

【発明の詳細な説明】 自動呼分配システムにおけるリアルタイムデータのアクセス方法 著作権表示 この特許文書出で開示する内容の一部には、著作権保護の対象となる内容が含 まれている。この著作権の所有者は、何人によるものであれ、特許商標庁の特許 ファイルまたは特許記録に保管されている状態の当該特許文書または当該特許の 開示内容のそのままの複写に対して異議を唱えるものではないが、別途あらゆる 形態における全ての著作権を留保する。 発明の背景 本発明は、リアルタイム情報アクセス技術に関し、より詳しくは、動的リアル タイム情報が、あらかじめ静的記憶装置あるいは大容量記憶装置のデータ構造の 形で記憶されることなくリアルタイムで問い合わせられる自動呼分配（ＡＣＤ） システムの電話呼関連情報にアクセスするための方法に関する。本発明は、特に 、入来呼について最適な経路選択（ルーティング）を行うための上記のようなシ ステムの構成要素に関する。自動呼ディストリビュータ（分配装置）は、プロン プト（prompt）への発呼者応答によって、構内交換台または構内交換機（ＰＢＸ ）設備と共に入ってきた呼の自動ルーティングを行う。ＡＣＤは、比較的大きい 会社によって、遠隔のユーザに対するサービスのためあるいは販売する製品また はサービスに関する要求をルーティングするための電話ベースのサポートの一部 として、呼を予備選択するためにしばしば利用される。 ＡＣＤシステムの重要な要件は、連続的で実質的にリアルタイムなシステム動 作及びデータに対するアクセスの利用可能性が必要なことである。本発明に関係 のあるＡＣＤシステムにおいては、基本的ハードウェアの故障の影響を最小限に するために、システム構成が多大な冗長性を含む。 従来、周知のＡＣＤシステムには、共用メモリからリアルタイムデータをフレ キシブルに問い合わせる能力がなかった。フレキシブル問合わせ機構は、エンド ユーザがどのような特定のデータを検索すべきかをユーザ・インタフェースレベ ルで定義することを可能にする機構である。フレキシブルな問合わせは、大容量 記憶装置に記憶された静的データベースからの履歴データとのインタラクション に限定されて来た。共用メモリにおけるリアルタイムデータへのアクセスは、従 来、メーカーによって提供される一定の問合わせプリゼンテーションに限られて いた。このように、ＡＣＤに使用される従来のリアルタイムデータ収集システム においては、すぐに必要な重要なデータであり、常時流動状態にあるリアルタイ ムデータをフレキシブル問合わせ機構を介してアクセスすることはできなかった 。その問題点の一部は、従来、大量のデータを大容量記憶装置へ、あるいは大容 量記憶装置から転送する必要があり、これらの転送には遅延が伴うということに ある。 いくつかの従来技術のＡＣＤシステムにおいては、いわゆるリアルタイムデー タに向けられるエンドユーザの要求は、それらのエンドユーザ要求を満たすには 大きなデータのセットの小さなサブセットしか必要でないかも知れないのに、一 般に全てのファイルのデータの検索が必要であった。また、他の周知のＡＣＤシ ステムの要求／問合わせプロシージャでは、通常、まず大きいデータのセットを 検索してからでないと、適切な情報を調べかつまたは表示することができなかっ た。出信専用ダイヤリングシステムの一例が、１９９２年３月３１日付で発行さ れた米国特許第５，１０１，４２５号に開示されており、そのシステムでは、ク ライアントシステムがホストからデータを得、クライアント側でデータを処理し 、クライアント側でデータのサブセットを選択して表示するようになっている。 他の代表的なＡＣＤシステムが、ＡＴ＆Ｔ（ＰＢＸへ組込み型）及びロックウェ ル・インターナショナル（独立型ＡＣＤシステム）から提示されている。 さらに、従来技術のいくつかのＡＣＤシステムにおいては、中央のデータベー スサーバ（呼センターのホストサーバ）から遠隔のレポーティング・ステーショ ン（ローカルサイトまたは遠隔サイトの多重クライアントシステム）へ状態情報 を表すデータを転送するのに、プロセッサの負荷処理容量及びサイト間の通信リ ンクのデータ転送速度（バンド幅）容量の双方の制約による中央のデータベース サーバの性能に対するマイナスの影響を最小限にするために、さらに遅延が導入 される。従って、この面で必要とされているのは、表示されるデータの無欠性が 連続的にしかも下層にあるバックグランドプロセスの性能に悪影響を及ぼすこと なく実質的にリアルタイムで維持されるＡＣＤシステムにおけるデータ生成／デ ータ問合わせ技術である。 発明の概要 本発明は、複数のクライアントシステムと、トランザクションをリアルタイム で処理する少なくとも１つのホストサーバシステムとを有する自動呼分配（ＡＣ Ｄ）システムでデータを実質的に他のデータと同期してかつそのデータを生成す るイベントと実質的にリアルタイムで生成し、フレキシブルに報告するための方 法が提供される。要求を受け取って処理し、あたかも関連するデータベースに向 けられたものであるかのような問合わせとしてその要求を実行するのに必要な全 ての知識を含む実行可能なマシンコードにリアルタイムでその要求を直接変換す る第１のモジュールをホストサーバシステムに設け、かつその問合わせをリアル タイム・インタラクション方式で使用してホストサーバシステムの共用メモリ中 のデータにアクセスし、情報、通常は関係のあるトランザクションに関する状態 情報を、要求を発したクライアントシステムに報告する第２のモジュールを設け る。データのセット及びサブセットは、通常、クライアントシステム上で全てま とめて報告されるか、あるいは複数のクライアントからの問合わせに応答して実 質的にリアルタイムで同期して報告される。クライアント側からの問合わせは、 あらかじめ選択された更新間隔で発生するよう指定することもでき、その更新間 隔は、一部のデータサブセットについてはたまにだけ更新するよう、ユーザの必 要性に基づいて変えることができる。また、共用メモリから値を返すか、または 共用メモリ中のデータに対する計算に基づいて値を返すための方法及び手段が設 けられる。本発明においては、静的データベース中のデータをモニタし、適切な 情報をデータアクセス・モジュールがアクセスすることができるように共用メモ リに供給して、データアクセス・モジュールが静的データベースに直接アクセス しなくても済むようにするために、データベース・マネージャ・モジュールを使 用する。 以下、本発明を添付図面を参照しつつさらに詳細に説明する。 図面の簡単な説明 図１は、複数のホストシステムと複数のクライアントシステムを含む環境を示 すブロック図である。 図２は、本発明によるクライアントシステムとホストサーバの一実施形態を示 すブロック図である。 図３は、本発明による要求マネージャ・モジュールのフローチャートである。 図４は、本発明による問合わせコンパイラモジュールのフローチャートである 。 図５は、本発明によるデータアクセス・モジュールのフローチャートである。 図６は、本発明によるリアルタイムの冗長なコンピュータシステム用の「カッ ト・ツー・バックアップ（ｃｕｔ ｔｏ ｂａｃｋｕｐ）」制御動作のフローチ ャートである。 特定の実施形態の説明 まず図１を参照して、ＡＣＤシステム１０は、ＰＣ１，ＰＣ２、．．．．，Ｐ Ｃｊという番号を付したパーソナル・コンピュータのようなクライアント・コン ピュータシステム１２、１１２、２１２と、ネットワーク１６によって全て一つ に接続されたコールセンター、すなわちＣＣ１，ＣＣ２，．．．，ＣＣｎと表示 されているホストサーバ１３、１１３、２１３とで構成されている。ホストシス テム１３、１１３、２１３の各々の中には、主コントロールセンター・プロセッ サ（ＣＣ＿Ｐ１、ＣＣ＿Ｐ２、ＣＣ＿ＰＮ）１４、１１４、２１４、及び冗長コ ントロールセンター・プロセッサ（ＣＣ＿Ｂ１、ＣＣ＿Ｂ２、ＣＣ＿ＢＮ）１５ 、１１５、２１５がある。クライアント・コンピュータシステムのファンクショ ンは十分冗長である。詳しく言うと、各主コントロールセンター・プロセッサの ファンクションは、これらのプロセッサと各々ペアをなす冗長コントロールセン ター・プロセッサによって二重化されている。第１の主コントロールセンター・ プロセッサ１４は、複数のセッション１７、１９によってアクセス可能な共用メ モリ４４を有している。そのセッションのファンクションは、第１の冗長コント ロールセンター・プロセッサ１５にある二重化用のセッション１１７、１１９の よ うに、二重化用の共用メモリ４４１のサイクルに対して一致するサイクルである 。しかしながら、冗長コントロールセンター・プロセッサ１５は、図に示す第２ の主コントロールセンター・プロセッサ１１４の場合のように主コントロールセ ンター・プロセッサ１４が動作不能でない限り、動作上の役割を担わない。この ようにして、ホストサーバ１３、１１３、２１３は、クライアント・コンピュー タシステムによって、それぞれのクライアント・コンピュータシステム上のウィ ンドウに対応するセッションを処理する単一のプロセッサシステムと見なされる 。 各クライアントシステム１４、１１４、２１４のローカルな動作／表示環境中 には、複数のウィンドウＷ１、Ｗ２、Ｗ３、Ｗ４、Ｗ５、Ｗ６があり、これらの ウィンドウ内には、１つ以上のアクティブなセッション・プロセスがある。例え ば、ウィンドウＷ１中には、第３の主コントロールセンター・プロセッサ２１４ のセッションＳ７（５９）に関連するＳＰ７、及び第２の冗長コントロールセン ター・プロセッサ１１５のセッションＳ４（１５３）に関連するＳＰ４のような 異なる呼センターのセッション・プロセスがあり得る。同様に、ウィンドウＷ２ 中には、第１の主コントロールセンター・プロセッサ１４のセッションＳ１（１ ７）に関連するＳＰＬ第２の冗長コントロールセンター・プロセッサ１１５のセ ッションＳ３（１５３）に関連するセッション・プロセスＳ３４のようなセッシ ョン・プロセスがあり得る。ローカルのクライアントシステムの他のウィンドウ Ｗ３、Ｗ４、Ｗ５、Ｗ６中には、他のセッション・プロセスがあり得る。本発明 によれば、従って、１つのクライアントシステム（より一般的にはＰＣまたはワ ークステーションとして知られている）が、複数のホストサーバと同時に対話し て、共用メモリへのアクセスによりリアルタイムデータと履歴データの混合デー タに基づいて問合わせし、報告を得ることができ、これらのデータのフォーマッ トをクライアントシステム側でフレキシビリティをもって定義し、修正すること ができる。 関連の共用メモリを有する各セッション及びセッション・プロセスは、１つの システムと見なすことが可能である。図２は、本発明による機能的な動作システ ムを示す。ＡＣＤシステム１０は、クライアントシステムまたはワークステーシ ョン１２と呼センターまたはホストサーバ１３とを含む。後者のファンクショナ リティは、共用メモリ４４と関連し、クライアント・ネットワークインタフェー ス１８及びホスト・ネットワークインタフェース２０を介して相互接続された主 コントロール・プロセッサ１４のようなコントロール・プロセッサ上で走るセッ ション１７に組み込まれている。（説明の便宜上、以下ホスト側をホストサーバ １４と称する。）ネットワーク１６上のデータは、ネットワークを介しての伝送 の都合上、シリアルデータ・ストリームの形にパケット化される。このために、 クライアントシステム１２には受信データ用のシリアル‐パラレル・コンバータ ２２、及び送信データ用のパラレル‐シリアル・コンバータ２４があり、ネット ワークはＴＣＰ／ＩＰプロトコルをサポートしている。同様に、ホストサーバ１ ４には、受信データ用のシリアル‐パラレル・コンバータ２６、及び送信データ 用のパラレル‐シリアル・コンバータ２８がある。 クライアントシステム１２中には、本発明にとって適切な特殊なプロセッサ手 段がある。シリアル‐パラレル・コンバータ２４から入力を受け取るようにデー タルータ３０が結合されており、そのデータルータは、この入力をフォーマット し、処理してユーザ・インタフェース（ＵＩ）オブジェクトプロセッサ３２に入 力として供給する。オブジェクトプロセッサはオブジェクト指向ユーザ対話型イ ンタフェースを具備している。ＵＩオブジェクトプロセッサ３２は、データルー タ３０から受け取ったデータに基づくオブジェクト指向設定でユーザと対話し、 かつユーザ入力または自動プロセスに応答して、高水準出力をＳＱＬビルダー３ ４に入力として供給する。この場合、ユーザは、ローカルのワークステーション の同様の端末スクリーン上でディスプレイウィンドウを見る可能性があるサービ スエージェント、マネジメントまたはグループスーパバイザのためにレポート・ ディスプレイウィンドウを設計する個人である。本発明の一実施形態においては 、ＵＩオブジェクトプロセッサ３２は、オブジェクト指向ツールのベースセット 上に構築することも可能である。 ＳＱＬビルダー３４は、ＳＱＬ問合わせ言語を使用して高水準入力を適宜処理 し、ＳＱＬ言語構造に基づいた問合わせを作成する。より詳しくは、ＳＱＬビル ダー３４は、情報に対するユーザ要求を記述し、特徴付けるユーザにより構築さ れたオブジェクトを調べ、その要求に対応するＳＱＬ問合わせをリアルタイムで データを問合わせるのに適した形で構築する。データベース問合わせのみに適し た問合わせを形成することが可能な周知のＳＱＬビルダーと異り、本発明による ＳＱＬビルダー３４は、ホストサーバの共用メモリからリアルタイムで情報を検 索するのに適した問合わせを形成することが可能である。実際に利用可能な提案 したシステムの態様は、一般に、それぞれの特殊なタスクのために大きなＳＱＬ ボキャブラリを必要とすることはないので、本発明の特定の実施形態においては 、ＳＱＬコマンドのサブセットのみを実装すればよい。このファンクショナリテ ィのサブセットは、以下よりなる。 −ｊｏｉｎ −ｍｉｎ、ｍａｘ、ａｖｇ、ｓｕｍ及びｃｏｕｎｔを含むａｇｇｒｅｇ ａｔｅ −等号（＝）及び「ｉｎ」及び「ｗｈｅｒｅ」文節中の論理積を介して のｆｉｌｔｅｒｉｎｇ ＳＱＬビルダー３４は、シリアル化プロセス及びインタフェース１８、１６、 ２０等を介してメッセージ及びＳＱＬ問合わせをホストサーバ１４に送る。ワー クステーション側においては、下記のメッセージが含まれる。 Ｌｏｇｏｎ（ログオン） Ａｄｄ Ｒｅｑｕｅｓｔ Ａｌｔｅｒ Ｒｅｑｕｅｓｔ Ｒｅｍｏｖｅ Ｒｅｑｕｅｓｔ Ｓｙｎｃｈ Ｒｅｑｕｅｓｔ Ｖｅｒｓｉｏｎ Ｒｅｑｕｅｓｔ Ａｄｄ Ｒｅｑｕｅｓｔは、ＳＱＬセレクトステートメントに対応してリアル タイムメモリから何のデータが必要か、送るべきデータ行の行番号、データをク ライアントに送信する周波数の指定を含む。Ｒｅｍｏｖｅ Ｒｅｑｕｅｓｔは、 その補数である。Ａｌｔｅｒ Ｒｅｑｕｅｓｔは、要求された更新周波数及び行 への変更を含む。Ａｌｔｅｒ Ｒｅｑｕｅｓｔは、ＳＱＬ問合わせを変えること はできない。 本願の付録Ａは、パース付きＳＱＬ構造のリストを含め、本発明によるセッシ ョン・プロセスの解説書になっている。ホストは、下記のような一定のメッセー ジを返すことができる。 バージョンメッセージ データメッセージ エラーメッセージ データメッセージは、本発明において最も重要な要素である。 ホスト１４においては、問合わせ及びメッセージは要求マネージャ３６として 知られるモジュールによって分析され、ルーティングされる。要求マネージャ３ ６は、問合わせエグゼキュタ４０として知られるモジュールを制御するために以 下に説明するような問合わせコンパイラ３８として知られるモジュールと共に用 いられる。一方、問合わせエグゼキュタ４０は、データアクセス・モジュール４ ２と対話して、本発明による共用メモリ４４からリアルタイム情報を検索する。 ＳＱＬ問合わせに応じた回答は、ユーザがリアルタイムデータのリレーショナル ・データベース様のビューを受け取るように、問合わせエグゼキュタ４０及びデ ータアクセス・モジュール４２から要求マネージャ３６を介してクライアントシ ステム１２へ送られる。要素２０、２６、３８、３６、３８、４０、４２は、全 体で「セッション」、明確にはセッション１７（図１）を定義するファンクショ ナリティを形成する。各セッション毎にこのようなインスタンスが１つずつある 。 共用メモリは、全てのセッションに対してアクセス可能であり、外部ソース４ ５からリアルタイムデータを受け取る。また、共用メモリ４４はデータベース・ マネージャ４６によってもアクセスされて、これと通信し、一方、データベース ・マネージャ４６は共用メモリ４４の内容をトラッキングし、データベース４８ で必要になった変化を記録する。データベース４８は、一般にトランザクション の終了時にのみ更新されるので、データベース４８は履歴データしか含まない。 付録Ｈには、データベース・マネージャ４６が共用メモリ４４とどのようにして 対話するかを記述するソースコードのリストが記載されている。一方、共用メモ リは、以下に説明するように、データアクセス・モジュール４２によってアクセ スされる。 クライアントシステム１２、１１２、２１２に対してアクセス可能となる全て のデータは共用メモリに入っている。本発明によれば、共用メモリ４４は、デー タベース４８からデータベース・マネージャ４６によって供給された履歴データ の画像と共にフィールドにリアルタイムデータが書き込まれたテーブルを介して 見られる。一実施形態においては、共用メモリ４４は、整数タイプ、小数タイプ 、ストリングタイプのデータをサポートする約２００フィールドの１４のテーブ ルに編成される。いくつかのテーブルの中の選択されたフィールドは、共用メモ リ４４の他のフィールドから計算することも可能である。このように、データは 未加工形式でも計算された形式でもよく、これらの形式は外部アプリケーション に透過である。共用メモリには、待ち行列の形で待っている呼の数のような一時 的データ、平均データ、スローサイクル（半時間）更新データ、及び累積データ 等のいくつかの形のカレントデータが書き込まれている。 付録Ｂには、本発明の一実施形態におけるリアルタイムテーブル及びフィール ドの記述が記載されている。これらのテーブル及びフィールドについてここで説 明する。テーブルには、エージェント・テーブル、エージエントグループ・テー ブル、エージェントグループ３０分テーブル、エージェントライン・テーブル、 エージェント要約テーブル、アラート・テーブル、アプリケーション・テーブル 、アプリケーション呼待ち行列テーブル、アプリケーション半時間テーブル、シ ステム・テーブル、チーム・テーブル、トランク・テーブル、トランク群テーブ ル及びトランク群半時間テーブルがある。これらの各テーブルは、絶対データか 計算された形のデータ用の多数のフィールドを含む。詳細については、やはり付 録Ｂに記載されている。 共用メモリ４４は、他のプロセス４９を介してデータベース４８と通信するの で、セッション１７は共用メモリ４４を読みさえすればよく、データベース４８ を直接問合わせる必要がない。データの格納構造に関するデータベース構成情報 を得るために、ユーザ・インタフェース４７がデータベース４８に結合されてい る。 コンピュータプログラムとして実装される実施形態のセッション１７はＣ言語 で書かれる。ワークステーション１２上で動作するセッション・プロセスＳＰ１ は、コンピュータ言語Ｃ＋＋のような言語でオブジェクト指向環境に実装するこ とが好ましい。次に、セッション及びセッション・プロセスの具体的な実装例に ついて詳しく説明する。 図３は、本発明による要求マネージャ３６モジュールのフローチャートである 。要求マネージャ３６は、要求を処理するか、あるいはタイムアウトによってあ らかじめ定められた間隔で結果を報告するために、タイミング要素（図示省略） と関連して動作する。要求マネージャ３６は、時間をチェックするか、または要 求を取り込む（例えば割込みに応答する）（ステップＡ）。次に、要求マネージ ャは、タイムアウトかどうかをチェックする（ステップＢ）。タイムアウトでな ければ、“Ａｄｄ”形要求かどうかをチェックする（ステップＣ）。“Ａｄｄ” 形要求でなければ、リサイクルしてタイムアウトかどうかをチェックし（ステッ プＢ）、タイムアウトになるか、Ａｄｄ要求を受け取るまてこのモードを持続す る。Ａｄｄ要求が発生すると、その要求は直ちに機械可読形式に変換される。以 下に説明するように、問合わせコンパイラ３８を介して要求オブジェクトにコン パイルされる（ステップＤ）。この要求オブジェクトは、次に、問合わせエグゼ キュタ４０（コンピュータシステムのオペレーティング・システム）を用いて実 行され、結果が得られる（ステップＥ）。次に、この要求オブジェクトは、他の 要求オブジェクトと共にオブジェクトリストの形の待ち行列に入れられる（ステ ップＦ）。その後すぐに、要求マネージャ３６は、様々なクライアントに対する 報告機能を呼び出すために用いられるリフレッシュ速度に関するタイムアウトを チェックし、必要ならば調節する（短縮する）（ステップＧ）。このタイムアウ トは、待ち行列に入れられた要求オブジェクトのいずれについても最も短いリフ レッシュ速度に設定される。次に、このタイムアウトが再度チェックされ、タイ ムアウトが発生したならば（ステップＨ）、要求マネージャ３６は、最新のデー タによってカレント要求オブジェクトを更新し、そのデータをクライアントに供 給することができるように結果バッファに格納し（ステップＩ）、要求またはタ イムアウトのチェックに戻る（ステップＢ）。タイムアウトが発生しなかった場 合は、単に要求またはタイムアウトのチェックに戻る（ステップＢ）。 ここでタイムアウトが発生すると、要求マネージャ３６はオブジェクトリスト から次の要求オブジェクトを読み出し（ステップＪ）、時刻をチェックして、そ のオブジェクトを処理（実行）すべきかどうかを判断する（ステップＫ）。オブ ジェクトを実行すべきでない場合は、オブジェクトリストの次のオブジェクトを 読み出すステップ（ステップＪ）に戻る。要求マネージャ３６は、読み出したオ ブジェクトが実行すべきオブジェクトである場合、その要求オブジェクトを実行 して共用メモリのテーブルから結果を得（ステップＬ）、その結果を結果バッフ ァに格納する（ステップＭ）。次に、要求マネージャ３６は、オブジェクトリス トの終りに達したかどうかをチェックし（ステップＮ）、終りに達していなけれ ば、次の要求オブジェクトを読み出すステップ（ステップＪ）に戻る。オブジェ クトリストの終りに達した場合は、要求マネージャ３６は、結果をシリアル化器 ２８を介してクライアントに送り（ステップＰ）、リアルタイムサイクルの始め に戻る（ステップＡ）。 図４は、要求マネージャ３６によって制御される問合わせコンパイラ３８の動 作を説明したフローチャートである。問合わせコンパイラ３８は、ＳＱＬパース 付き問合わせ形の要求を受け取るとすぐに、供給されたパース付き問合わせに基 づいてマシンコードにコンパイルし（ステップＢＡ）、まずその問合わせをチェ ックして正当であるかどうかを決定する（ステップＢＢ）。問合わせコンパイラ ３８は、最初の機能ステップとして、どのテーブルがインデックスをＳＱＬ問合 わせの「ｗｈｅｒｅ」文節で参照されているかを識別し（ステップＢＣ）、次い で、処理時間を最小限にするために、パース付き問合わせに関連するテーブルを アクセスのための最適シーケンスに分類する（ステップＢＤ）。 その後すぐに、問合わせコンパイラ３８は、各テーブル毎に、データアクセス ・モジュール４２を呼び出すコードを生成する（ステップＢＥ）のと併せて、あ らかじめ設定されたインデックス付き参照に従ってテーブルを走査するために使 用するコードを生成する（ステップＢＦ）。その後、問合わせコンパイラ３８は 、データアクセス・モジュールに対する呼のためのコードを生成する（ステップ ＢＩ）のと併せて、ＳＱＬの「ｗｈｅｒｅ」文節の部分をチェックするために使 用するコードを生成し、速度を最適化するコードを選択する（ステップＢＪ）。 このプロセスが全てのテーブルが終わるまで実行される（ステップＢＧ、ＢＨ） 。その後、問合わせコンパイラ３８は、いわゆる累計（累積情報の参照）を必要 と しない中間結果または他の結果を計算するために使用するコードを生成し（ステ ップＢＯ）、併せて、データアクセス・モジュールへの呼に使用するコードを生 成し（ステップＢＫ）、結果を一時バッファに格納するために使用するコードを 生成する。この問合わせで累計情報が必要でない場合は（ステップＢＬ）、問合 わせコンパイラは実行のためのマシンコードを出力する（ステップＢＭ）。累計 情報が必要な場合は、問合わせコンパイラ３８は要求の累計に従って結果を圧縮 するために使用し、かつ累計結果を最終バッファに格納するために使用するコー ドを生成する（ステップＢＮ）。その結果得られるマシンコードは、要求マネー ジャによって指示されるに従って直ちに実行される出力である（ステップＢＭ） 。 図２において、問合わせエグゼキュタ４０は、要求マネージャ３６によって指 示されるに従い、かつデータアクセス・モジュール４２により与えられる機能に 基づいて問合わせコンパイラにより作成される機械実行可能コードに単に応答し 、これを実行するだけであるという意味において、従来のオペレーティング・シ ステムの要素であることが好ましい。問合わせエグゼキュタは、データアクセス ・モジュール４２を介して共用メモリ４４と対話し、要求マネージャ３６が必要 とするとき結果をバッファに返す。本発明によれば、問合わせコンパイラ３８に よって作成されたマシンコードは、要求マネージャ３６のコマンドと同時に直ち に実行することができ、要求マネージャ３６は、これによって、クライアントへ の情報の流れを実質的にリアルタイムで更新された状態に保つ。 図５は、共用メモリ４４と対話するように使用される場合におけるデータアク セス・モジュール４２の動作のフローチャートである。データアクセス・モジュ ール４２は、１つの見方では、共用メモリ４４の読取りで用いられる機能呼出し を集めたものである。問合わせコンパイラ３８は、データアクセス・モジュール ４２を呼び出し、問合わせエグゼキュタ４０を介してデータアクセス・モジュー ルを使用することにより共用メモリ４４にアクセスする。 動作について説明すると、図５において、データアクセス・モジュール４２は 、問合わせエグゼキュタ４０の呼に応答して共用メモリ４４の参照された記憶場 所にアクセスする（ステップＡＡ）。次に、データアクセス・モジュール４２は 、マシンコードに変換されたコードに従って共用メモリ４４を読み取る（ステッ プ ＡＢ）。フィールドの情報に対して計算が必要ならば（ステップＡＣ）、データ アクセス・モジュールのコードは、そのフィールドについての値を計算し（ステ ップＡＤ）、その結果を（一時バッファから）要求マネージャ３６に返す（ステ ップＡＥ）。計算が必要ない場合は（ステップＡＥ）、アクセスされたフィール ドの値は共用メモリから要求マネージャ３６へ直接返される（ステップＡＦ）。 データアクセス・モジュール４２の一例が、付録Ｃ乃至Ｇと共に付録Ｅに示し てある。付録Ｃはデータの論理的記述の要素を含むセッションマネージャの概要 である。付録Ｄには問合わせコンパイラ一部（ｂｕｉｌｄ.ｃ、ｐａｒｓｅ.ｃ） を含むデータフィード・コードが記載されている。付録Ｅはデータアクセス・モ ジュールである。付録Ｆには、問合わせコンパイラの構造の定義（ｂｕｉｌｄ. ｈ、ｐａｒｓｅ.ｈ）を含むデータタイプの定義が記載されている。付録Ｇには 、雑要素が記載されている。 ホスト側では、前に説明したように、結果が要求マネージャ３６によって報告 される。要求マネージャ３６は、その情報の報告をディスプレイの設計者（ユー ザ）により定義されたところに従って一定間隔で同時に更新する。ディスプレイ 上の結果の更新を同期させることによって、ディスプレイの変化の乱れが最小限 に抑えられる。 主及び冗長プロセッサを有するホストサーバ１３の動作の一部としては、動作 を試験して、欠陥のある主コントロールセンター・プロセッサ（ＣＣ Ｐ１）１ ４からこれに付随する冗長コントロールセンター・プロセッサ（ＣＣ Ｂ１）１ ５へ制御を移す仕組みがなければならない。動作については、図６において、「 バックアップへのカット（Ｃｕｔ ｔｏ Ｂａｃｋｕｐ）」、すなわち冗長コン トプロセッサへの制御転送では、一群のテストが用いられる。クライアントシス テム１２の制御プロセスにおいては、「トライ」カウンタがゼロに初期化され（ ステップＣＡ）、トライ・チョイス・セレクタ（Ｔｒｙ Ｃｈｏｉｃｅ Ｓｅｌ ｅｃｔｏｒ）は、クライアントシステム１２がデフォルトとして主コントロール ・プロセッサ１４を選択するように、「主」にセットされる（ステップＣＢ）。 クライアントシステム１２は、デフォルト設定とともに指定されたホストサーバ １３（呼センター）に接続することを試み（ステップＣＣ）、これに成功したな らば（ステップＣＤ）、接続を完了する（ステップＣＥ）。成功しなかった場合 は、クライアントシステム１２は、トライ・カウンタがそのカウトントアップ限 界、例えば５トライ・サイクルをオーバーフローしたかどうかチェックし（ステ ップＣＦ）、オーバーフローしている場合は、上記の接続の試みは指定されたホ ストが正しく動作していないという理由で中止される（ステップＣＧ）。次にカ ウントアップ限界を越えていない場合は、トライ・カウンタはインクリメントさ れて（ステップＣＨ）、トライ・チョイス・セレクタがチェックされる（ステッ プＣＩ）。そして、主コントロール・センターにセットされていれば、トライ・ チョイス・セレクタはバックアップ（リダンダント）に変えられ（ステップＣＪ ）、バックアップについて接続を試みるプロセスが繰り返される（ステップＣＣ ）。トライ・チョイス・セレクタがバックアップにセットされていれば（ステッ プＣＩ）、主コントロール・プロセッサに切り換えられ（ステップＣＫ）、主コ ントロール・プロセッサについて接続を試みるプロセスが繰り返される（ステッ プ、ＣＣ）。このプロセスは、接続が行われるか、あらかじめ選択された回数だ け接続の試みが失敗するまで続けられる。代替プロセッサに接続するオプション をクライアントシステムに組み入れることによって、本発明では、データの消失 や動作劣化のない動作が可能となる。 以上、本発明を特定の実施形態に関連して説明した。当業者にとっては、他の 実施形態も自明であろう。従って、本発明は、請求の範囲に記載するところ以外 によって限定されるものではない。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 イールリッチ，ジェイソン アメリカ合衆国 94538 カリフォルニア 州・フレモント・サヴァンナ ロード・ 3739 (72)発明者 ブロイレット，ジャン−リューク アメリカ合衆国 94306 カリフォルニア 州・パロアルト・ヴァードサ ウェイ・ 4060 【要約の続き】 ２）がアクセスすることができるよう共用メモリ（４ ４）に供給する。

Claims (1)

1. 【特許請求の範囲】 １．複数のクライアントシステム及びトランザクションをリアルタイムで処理す るための共用メモリを持つ少なくとも１つのホストサーバシステム有する自動電 話呼分配（ＡＣＤ）システムで、データを生成するイベントとともに実質的にリ アルタイムでデータを検索し、報告する方法において、 クライアントシステムのいずれか１つからの要求をホストサーバシステムで処 理するステップと、 上記要求を直ちに問合わせとして実行するのに必要な全ての知識を含む実行可 能なマシンコードにその要求を直接変換するステップと、 上記問合わせを要求オブジェクトとして実行するステップと、 その後、上記問合わせの実行結果として、上記共用メモリ中のライブデータに 直ちにアクセスして、上記要求を出しているクライアントシステムに共用メモリ の内容のみに基づいて結果を報告するステップと を具備した方法。 ２．上記要求を処理するステップが、ホストサーバシステムの要求マネージャを 使用して全ての要求の処理タイミングを設定するステップを含む請求項１記載の 方法。 ３．上記要求マネージャを使用して、要求の要求オブジェクトへのコンパイルを 開始させ、コンパイルされた要求オブジェクトの実行を開始させ、コンパイルし たａｄｄ形の要求オブジエクトをリストに待ち行列として入れる請求項２記載の 方法。 ４．上記要求マネージャを使用して、要求オブジェクトのリフレッシュ速度をい ずれかの要求オブジェクトの最も短いリフレッシュ速度にセットする請求項３記 載の方法。 ５．要求マネージャを使用して、最初の実行後及び上記要求を出しているクライ アントに結果を報告する前に、要求オブジェクトの更新を開始させる請求項４記 載の方法。 ６．上記要求マネージャを使用して、上記要求を出しているクライアントにタイ ムアウトが起こった時のみ結果を報告する請求項５記載の方法。 ７．パース付き問合わせによる情報へのアクセスを容易にするために、共用メモ リ中のデータをテーブル形式に編成するステップをさらに具備した請求項２記載 の方法。 ８．共用メモリから結果を取り出すために、上記クライアントシステムの各々１ つを使用して少なくとも１つの上記ホストサーバシステムに対して複数の要求を 出すステップをさらに具備した請求項１記載の方法。 ９．問合わせコンパイラを使用して、上記要求を出しているクライアントからパ ース付きＳＱＬ問合わせを受け取り、そのＳＱＬ問合わせの「ｗｈｅｒｅ」文節 でインデックスが参照されているテーブルを識別し、インデックス参照によって そのテーブルを走査するために使用することができるコードを生成するステップ をさらに具備した請求項１記載の方法。 １０．上記問合わせコンパイラを使用して、共用メモリから結果を検索すること ができるコードを生成する請求項９記載の方法。 １１．上記問合わせコンパイラを使用して、共用メモリからの結果を累計結果に 圧縮するために用いることができるコードを生成する請求項１０記載の方法。 １２．上記の問い合わせを実行するステップが、データアクセス・モジュール手 段を使用して、実質的にリアルタイムで共用メモリにアクセスするとともに、共 用メモリからの生の結果及び共用メモリ中のデータに基づく計算された情報を両 方とも上記要求マネージャに返すステップを具備する請求項２記載の方法。 １３．上記ホストサーバシステムが主コントロール・プロセッサ及びその主コン トロール・プロセッサの動作を二重化した形で同期して実行する冗長コントプロ セッサを含んでおり、上記クライアントシステムを使用して、主コントロール・ プロセッサとの接続をチェックし、その主コントロール・プロセッサとの接続が 達成されなかった時すぐに冗長コントロール・プロセッサとの接続を選択するス テップをさらに具備した請求項１記載の方法。 １４．上記クライアントシステムが、上記ホストシステムとの接続を達成するこ とができないということを示す所定の回数だけ、上記主コントロール・プロセッ サ及び冗長コントロール・プロセッサとの接続の有無を交互にチェックする請求 項１記載の方法。