JP2010257262A - 通信制御プログラム、通信システム、通信制御装置および通信制御方法 - Google Patents

Abstract

【課題】送信側プロセスで生じた障害を受信側プロセスに効率的に通知すること。
【解決手段】格納手段１ｅは、実行手段１ａから送信情報を順次受け付け、受け付けた送信情報それぞれを送信情報記憶手段１ｃに格納する。取出手段１ｆは、実行手段１ｂから送信情報の取得要求を順次受け付け、受け付けた各取得要求に応じて送信情報記憶手段１ｃに記憶された各送信情報を取得し、取得した各送信情報を実行手段１ｂに出力する。制御手段１ｇは、障害が発生した旨を示す障害情報を格納手段１ｅから取得すると、通知情報記憶手段に記憶され障害の内容を定義した通知情報を取出手段１ｆに取得させ、実行手段１ｂからの取得要求に応じて、この通知情報を実行手段１ｂへ出力させる。
【選択図】図１

Description

本発明は、プロセス間のデータ通信を制御する通信制御プログラム、通信システム、通信制御装置および通信制御方法に関する。

コンピュータは、ユーザに利便性の高い様々な機能を提供する。コンピュータでは、基本的な機能を制御するオペレーティングシステム（ＯＳ：Operating System）が実行される。ＯＳは、サービスに応じた複数のアプリケーションプログラム（以下、単にアプリケーションという）を動作させる。アプリケーションの実行は、プロセスと呼ばれる単位処理で管理される。ＯＳは、各プロセスを実行するためのハードウェアリソースを各プロセスに割り当てる。ＯＳは、複数のプロセスを協調して動作させることで、単一または複数のアプリケーションの機能をコンピュータ上に実現する。

ここで、複数のプロセス間のデータ通信をキュー（Queue）やスタック（Stack）と呼ばれるバッファを用いて行うことが考えられる。キューは、データの先入れ先出し（ＦＩＦＯ：First In First Out）を行うためのデータ構造である。また、スタックはデータの後入れ先出し（ＬＩＦＯ：Last In First Out）を行うためのデータ構造である。

キューなどのバッファを用いることで、送信側プロセスが送信したデータを一時保存しておくことができ、送信側プロセスと受信側プロセスとの間での非同期でのデータ通信を可能とする。これにより、送信側プロセスと受信側プロセスとのデータ通信における関係を疎に保つことができる。例えば、送信側プロセスを実行するアプリケーションと受信側プロセスを実行するアプリケーションとの処理をそれぞれ独立に行うことも可能である。具体的には、受信側のアプリケーションが障害などで停止していても、送信側のアプリケーションはキューなどにデータを格納する処理を継続して行える。また、送信側のアプリケーションが障害などで停止していても、受信側のアプリケーションはキューなどに格納されたデータを取得して処理を継続して行える。また、動作中のアプリケーションに影響を及ぼさずに、停止中のアプリケーションに対する保守作業を行うこともできる。その結果、各アプリケーションの稼働率の向上を図ることができる。

ところで、システムの運用管理において、コンピュータで稼動するＯＳやアプリケーションの実行状態の監視が行われる。そして、例えばアプリケーションのエラーやリソース不足などが発生した場合には、管理者にその旨が通知される。管理者は、この通知を受けて、アプリケーションの処理が正常に行われていないことを認識し、対処することができる。

プロセス間通信を行う情報処理システムでも、このような監視による通知が行われる。例えば、依頼元コンピュータから受け付けた処理依頼の内容が、処理を実行する依頼先コンピュータの最大許容資源枠内で実行不可である場合には、該当の処理依頼をキューに登録せずに、その旨を依頼元コンピュータに通知する方法が知られている（例えば、特許文献１参照）。

特開平１０−３０１８８３号公報

ここで、上述のバッファを用いてプロセス間のデータ通信を行う場合、受信側プロセスは、バッファに対してデータの取得要求を行う。バッファでは、この取得要求に応じてＦＩＦＯまたはＬＩＦＯの手順により受信側プロセスにデータを送信する。このとき、バッファにデータが格納されていない場合、受信側プロセスとバッファとは、送信側プロセスによりデータが格納されるのを待機することが考えられる。しかし、送信側プロセスが障害などでデータを格納することができない場合に、受信側プロセスやバッファで待機を継続することは、該当のプロセスに割り当てられたリソースを無駄に使用することになる。

そこで、送信側プロセスは、障害などによりデータをバッファに格納できない場合に、バッファに対して発生している取得要求を解放するよう指示する解放要求を行うことが考えられる。そして、バッファは、解放要求を受け付けると、受信側プロセスから受け付けた取得要求に対して、例えばＮＵＬＬを返信することが考えられる。

しかし、単にＮＵＬＬを返信するのみでは、送信側プロセスなどで生じた障害などを受信側プロセスで把握することができないという問題がある。このため、受信側プロセス（または受信側のアプリケーション）で、送信側プロセスの障害などに応じた後処理を行うことが困難であるという問題がある。

一方、バッファを介したプロセス間通信とは別個の通信経路で送信側プロセスの障害を受信側プロセスに通知することも考えられる。しかし、この方法では、通知用の通信経路を新たに設けなければならないという問題がある。また、このようにすると、各アプリケーション間で連携が発生し、上述した送信側のアプリケーションと受信側のアプリケーションとの独立性が損なわれる可能性があるという問題がある。

本発明はこのような点に鑑みてなされたものであり、送信側プロセスで生じた障害を受信側プロセスに効率的に通知する通信制御プログラム、通信システム、通信制御装置および通信制御方法を提供することを目的とする。

上記課題を解決するために、通信制御プログラムが提供される。この通信制御プログラムは、コンピュータを格納手段、取出手段および制御手段として機能させる。格納手段は、所定の第１の処理を実行する第１の実行手段から送信情報を順次受け付け、受け付けた送信情報それぞれを送信情報記憶手段に格納する。取出手段は、所定の第２の処理を実行する第２の実行手段から送信情報の取得要求を順次受け付け、受け付けた取得要求それぞれに応じて送信情報記憶手段に記憶された送信情報それぞれを取得し、取得した送信情報それぞれを第２の実行手段に出力する。制御手段は、障害が発生した旨を示す障害情報を格納手段から取得すると、障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された通知情報を取出手段に取得させ、取得要求に応じて、この通知情報を第２の実行手段へ出力させる。

また、上記課題を解決するためにネットワークを介して接続された送信装置と受信装置と、送信装置および受信装置の間のデータ通信を中継する通信制御装置とを備えた通信システムが提供される。この通信システムの通信制御装置は、第１の実行手段、格納手段、取出手段、第２の実行手段および制御手段を有する。第１の実行手段は、送信装置から送信情報を受信する。格納手段は、第１の実行手段から送信情報を順次受け付け、受け付けた送信情報それぞれを送信情報記憶手段に格納する。取出手段は、送信情報の取得要求を順次受け付け、受け付けた取得要求それぞれに応じて送信情報記憶手段に記憶された送信情報それぞれを取得し、取得した送信情報それぞれを取得要求の送信元に出力する。第２の実行手段は、送信情報の取得要求を取出手段に出力し、出力した取得要求に応じて取出手段から送信情報を取得し、取得した送信情報を受信装置に送信する。制御手段は、障害が発生した旨を示す障害情報を格納手段から取得すると、障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された通知情報を取出手段に取得させ、送信情報の取得要求に応じて、この通知情報を第２の実行手段へ出力させる。

また、上記課題を解決するために、上記通信制御プログラムを実行するコンピュータと同様の機能を有する通信制御装置が提供される。また、上記課題を解決するために、上記通信制御プログラムを実行するコンピュータと同様の処理を行う通信制御方法が提供される。

上記通信制御プログラム、通信システム、通信制御装置および通信制御方法によれば、送信側プロセスで生じた障害を受信側プロセスに効率的に通知することができる。

本実施の形態の概要を示す図である。 電子商取引システムの構成を示す図である。 受付サーバのハードウェア構成を示す図である。 受付サーバの機能構成を示す図である。 キューの構造例を示す図である。 発注レコードのデータ構造例を示す図である。 障害区分管理テーブルのデータ構造例を示す図である。 エラー管理テーブルのデータ構造例を示す図である。 ユーザ管理テーブルのデータ構造例を示す図である。 エラー通知情報の具体例を示す図である。 エラー通知画面の表示例を示す図である。 データ通信処理の手順を示すフローチャートである。 障害通知の流れの具体例を示すシーケンス図である。 障害対応の第１の具体例を示す図である。 障害対応の第２の具体例を示す図である。

以下、本実施の形態を図面を参照して詳細に説明する。
図１は、本実施の形態の概要を示す図である。コンピュータ１は、実行手段１ａ，１ｂ、送信情報記憶手段１ｃ、通知情報記憶手段１ｄ、格納手段１ｅ、取出手段１ｆおよび制御手段１ｇを有する。

実行手段１ａは、所定の単位処理を実行する送信側プロセスまたはアプリケーションである。実行手段１ａは、実行手段１ｂに実行させる処理に用いる送信情報を送信する。
実行手段１ｂは、所定の単位処理を実行する受信側プロセスまたはアプリケーションである。

ここで、送信情報記憶手段１ｃ、取出手段１ｆ、格納手段１ｅおよび制御手段１ｇは、実行手段１ａと実行手段１ｂとの間のデータ通信を中継するバッファの機能を有し、キューまたはスタックのデータ構造を備える。データ構造をキューまたはスタックの何れとするかは、実行手段１ａ，１ｂが実行する処理に応じて決定される。例えば、データの入力順序が実行手段１ｂの処理に影響を与える場合には、キューが選択される。

送信情報記憶手段１ｃは、実行手段１ａが実行手段１ｂに送信する送信情報を一時的に記憶する。
通知情報記憶手段１ｄは、実行手段１ａで発生し得る障害の内容を示す通知情報を記憶する。通知情報記憶手段１ｄは、例えば障害の内容を識別する障害識別情報に対応付けて通知情報を記憶している。

格納手段１ｅは、実行手段１ａから順次受け付けた送信情報を送信情報記憶手段１ｃに格納する。
取出手段１ｆは、実行手段１ｂから順次受け付けた取得要求に応じて、送信情報記憶手段１ｃに記憶された送信情報をＦＩＦＯまたはＬＩＦＯの手順に従って取り出し、実行手段１ｂに出力する。

制御手段１ｇは、格納手段１ｅから実行手段１ａで障害が発生した旨を示す障害情報を受け付けると、通知情報記憶手段１ｄに記憶された通知情報を取出手段１ｆに取得させる。そして、制御手段１ｇは、実行手段１ｂから取出手段１ｆへの取得要求に応じて、取出手段１ｆにより取得させた通知情報を実行手段１ｂに対して出力させる。

ここで、制御手段１ｇは、例えば格納手段１ｅから障害情報として障害識別情報を含む情報を受け付ける。そして、制御手段１ｇは、この障害識別情報に対応する通知情報を取出手段１ｆに取得させる。

コンピュータ１によれば、格納手段１ｅにより、実行手段１ａから実行手段１ｂへ送信する送信情報が順次受け付けられ、この送信情報それぞれが送信情報記憶手段１ｃに格納される。また、取出手段１ｆにより、実行手段１ｂから送信情報の取得要求が順次受け付けられ、この取得要求それぞれに応じて送信情報記憶手段１ｃに記憶された送信情報それぞれが取得され、この送信情報それぞれが実行手段１ｂに出力される。制御手段１ｇにより、障害が発生した旨を示す障害情報が格納手段１ｅから取得されると、通知情報記憶手段１ｄに記憶された通知情報が取出手段１ｆにより取得される。そして、取出手段１ｆにより、実行手段１ｂからの取得要求に応じて、取得された通知情報が実行手段１ｂへ出力される。

これにより、送信側で生じた障害を受信側に効率的に通知することができる。具体的には、障害が発生した旨を示す通知情報が、実行手段１ａと実行手段１ｂとのバッファを介したデータ通信と同じ通信経路で送信可能なので、別個に通信経路を設ける必要がない。また、通知情報を受け付ける実行手段１ｂは、取出手段１ｆに対する送信情報の取得要求を継続的に送信していれば、その応答として通知情報を適宜取得できるので、データ通信以外の処理手順を新たに設ける必要もない。

また、通知情報記憶手段１ｄに実行手段１ａで生じ得る障害ごとに、障害の内容を示す情報を格納しておけば、実行手段１ａで生じた障害を実行手段１ｂは的確に把握することができる。このため、実行手段１ｂは、実行手段１ａで生じた障害に応じた後処理を行うこともできる。

ところで、コンピュータ１は、例えばネットワークを介して商品の発注・受注を行う電子商取引システムで発注側システムと受注側システムとの間のデータ通信を中継する手段として用いることができる。この場合、コンピュータ１は、発注側システムから発注情報を受け付け、一時的に格納する。そして、受注側システムから受け付ける発注情報の取得要求に応じて、発注情報を受注側システムに送信する。以下では、このような電子商取引システムを例に採り、更に具体的に説明する。

なお、電子商取引システムでは、取引の順序（注文して、その注文をキャンセルするなど）が処理に影響する。したがって、コンピュータ１が備えるバッファとしては、キューが選択される。このため、以下ではキューを用いた場合を例示して説明するが、データ受け渡しの順序が処理に影響しない情報処理システムでは、スタックを用いて同様の処理機能を実現することもできる。

図２は、電子商取引システムの構成を示す図である。電子商取引システム１０は、発注システム１１、受注システム１２および受付サーバ１００を有する。
発注システム１１は、顧客からの商品注文を受け付けるシステムである。発注システム１１では、ネットワーク２０に端末装置２１，２２，２３，・・・が接続されている。ネットワーク２０は、例えば、インターネットまたは広域ＬＡＮ（Local Area Network）である。端末装置２１，２２，２３，・・・は、顧客が電子商取引に用いるコンピュータである。

受注システム１２は、顧客からの商品注文に応じて商品の取引業務を行うシステムである。受注システム１２では、ネットワーク３０に業務サーバ２００が接続されている。ネットワーク３０は、例えば、ＬＡＮである。業務サーバ２００は、商品注文に応じて商品の取引業務を行うコンピュータである。業務サーバ２００は、取引の結果を受付サーバ１００を介して端末装置２１，２２，２３，・・・に応答する。

受付サーバ１００は、ネットワーク２０，３０の間の通信を中継する。受付サーバ１００は、端末装置２１，２２，２３，・・・からの商品発注の内容に応じた発注情報を生成して一時的に格納するキューを備えている。受付サーバ１００は、業務サーバ２００から発注情報の取得要求を受け付けると、ＦＩＦＯの手順に従って、キューに格納された発注情報を業務サーバ２００に送信する。

端末装置２１，２２，２３，・・・を利用するユーザは、例えば、受付サーバ１００が提供する所定のインタフェースを端末装置２１，２２，２３，・・・上の所定のブラウザを閲覧・操作することで、電子商取引システム１０に商品の発注を行うことができる。受付サーバ１００は、例えば、このインタフェースを利用させるために、ユーザに対してユーザＩＤ（IDentifier）やパスワードによる認証を行う。このように、受付サーバ１００は、電子商取引システム１０を利用するユーザの管理も行う。

電子商取引システム１０は、発注システム１１と受注システム１２との間のデータ通信を受付サーバ１００を介して行うことで、両システムの連携を疎に保つことができる。このため、例えば、受注システム１２が停止したとしても、発注システム１１により商品発注の受け付けを継続して行うことができる。また、発注システム１１が停止したとしても、受注システム１２は、受付サーバ１００に格納された発注情報により、取引業務を継続して行うことができる。

図３は、受付サーバのハードウェア構成を示す図である。受付サーバ１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ１０３、グラフィック処理装置１０４、入力インタフェース１０５および通信インタフェース１０６，１０７を有する。

ＣＰＵ１０１は、受付サーバ１００全体の動作を制御する。
ＲＡＭ１０２は、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションソフトウェア（以下、アプリケーションという）のプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、ＣＰＵ１０１による処理に必要な各種データを記憶する。

ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションのプログラムを記憶する。また、ＨＤＤ１０３は、ＣＰＵ１０１による処理に必要な各種データを記憶する。なお、ＨＤＤ１０３の代わりに例えばＳＳＤ（Solid State Drive）などの他の不揮発性の記憶装置を用いることもできる。

グラフィック処理装置１０４は、モニタ５１と接続される。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って画像をモニタ５１の画面に表示させる。
入力インタフェース１０５は、キーボード５２とマウス５３と接続される。入力インタフェース１０５は、キーボード５２やマウス５３から送られてくる信号をＣＰＵ１０１に送信する。

通信インタフェース１０６は、ネットワーク２０と接続され、端末装置２１，２２，２３，・・・との間でデータの送受信を行う。通信インタフェース１０７は、ネットワーク３０と接続され、業務サーバ２００との間でデータの送受信を行う。

なお、端末装置２１，２２，２３，・・・および業務サーバ２００に関しても、受付サーバ１００と同様のハードウェア構成により実現できる。
図４は、受付サーバの機能構成を示す図である。受付サーバ１００は、ＰＵＴ側処理部１１０、キュー処理部１２０およびＧＥＴ側処理部１３０を有する。これらの機能は、ＣＰＵ１０１が所定のプログラムを実行することで実現される。ただし、これらの機能のうち、少なくとも一部または全部を専用のハードウェアで実現してもよい。また、ＰＵＴ側処理部１１０、キュー処理部１２０およびＧＥＴ側処理部１３０は、それぞれ別個のアプリケーションにより実現される。そして、ＰＵＴ側処理部１１０とＧＥＴ側処理部１３０との間で、キュー処理部１２０を介したプロセス間通信が行われる。

ＰＵＴ側処理部１１０は、顧客からの商品注文を受け付けるアプリケーションである。ＰＵＴ側処理部１１０は、端末装置２１から商品発注を受け付けると、商品発注の内容に応じた発注情報を生成する。ＰＵＴ側処理部１１０は、キュー処理部１２０に対して、生成した発注情報の格納依頼（以下、ＰＵＴ要求という）を出力する。

ＰＵＴ側処理部１１０は、発注受付部１１１、発注情報生成部１１２および通知情報記憶部１１３を有する。
発注受付部１１１は、端末装置２１から商品発注の所定の入力を受け付ける。発注受付部１１１は、受け付けた商品発注の内容を発注情報生成部１１２に出力する。

発注情報生成部１１２は、発注受付部１１１から取得する商品発注の内容に基づいて、発注情報を生成する。発注情報とは、発注を行ったユーザのユーザＩＤ、対象商品および商品価格などを含む情報である。発注情報生成部１１２は、生成した発注情報を含むＰＵＴ要求をキュー処理部１２０に出力する。

また、発注情報生成部１１２は、ＰＵＴ側処理部１１０で発生した障害により、発注情報を生成できない場合、障害が発生している旨を示す障害情報をキュー処理部１２０に出力する。この障害情報には、障害の内容を識別するための障害識別情報や、該当の発注を行った顧客を特定または絞り込むための情報が含まれる（詳細は後述する）。

通知情報記憶部１１３は、ＰＵＴ側処理部１１０の各機能で発生し得る障害の内容を示す通知情報を障害識別情報に対応付けて記憶する。具体的には、ＰＵＴ側処理部１１０の機能を実現するアプリケーションで発生したエラーや、端末装置２１との通信処理における不具合の内容を示す情報などが考えられる。通知情報は、例えば受付サーバ１００の管理者によって予め作成され、通知情報記憶部１１３に格納されている。

ここで、ＰＵＴ側処理部１１０というアプリケーションに対して、発注受付部１１１や発注情報生成部１１２をプロセスと呼ぶことができる。また、発注受付部１１１や発注情報生成部１１２の機能を更に細分化してプロセスとしてもよい。この点は、キュー処理部１２０およびＧＥＴ側処理部１３０に関しても同様である。

キュー処理部１２０は、ＰＵＴ側処理部１１０から受け付けるＰＵＴ要求に含まれる発注情報を一時的に格納するためのアプリケーションである。キュー処理部１２０は、ＧＥＴ側処理部１３０から発注情報の取得要求（以下、ＧＥＴ要求という）を受け付けると、ＦＩＦＯの手順により発注情報を順次応答する。

キュー処理部１２０は、発注情報用キュー１２１、通知情報記憶部１２２、データ格納部１２３、データ取出部１２４および制御部１２５を有する。
発注情報用キュー１２１は、ＰＵＴ側処理部１１０で生成された発注情報を一時的に記憶する。

通知情報記憶部１２２は、ＰＵＴ側処理部１１０の通知情報記憶部１１３に記憶されたた通知情報と同一の情報を記憶する。
データ格納部１２３は、発注情報生成部１１２から受け付けたＰＵＴ要求に含まれる発注情報を発注情報用キュー１２１に順次格納する。また、データ格納部１２３は、受付サーバ１００の起動時などには、通知情報記憶部１１３に記憶された通知情報を取得して、通知情報記憶部１２２に格納する。

更に、データ格納部１２３は、発注情報生成部１１２から障害情報を受け付けると、受け付けた障害情報を制御部１２５に出力する。
データ取出部１２４は、ＧＥＴ側処理部１３０からＧＥＴ要求を受け付けると、発注情報用キュー１２１が記憶する発注情報のうち、最も過去に格納された発注情報を取り出す。そして、データ取出部１２４は、取り出した発注情報をＧＥＴ側処理部１３０に出力する。また、データ取出部１２４は、制御部１２５の指示に基づいて、通知情報記憶部１２２に記憶された通知情報を取り出す。データ取出部１２４は、ＧＥＴ側処理部１３０からのＧＥＴ要求に応じて取り出した通知情報をＧＥＴ側処理部１３０に出力する。

制御部１２５は、データ格納部１２３から障害情報を受け付けると、データ取出部１２４にデータの取り出し元を通知情報記憶部１２２に切り替えるよう指示する。
ＧＥＴ側処理部１３０は、業務サーバ２００と連携し、業務サーバ２００に発注情報を送信するためのアプリケーションである。ＧＥＴ側処理部１３０は、キュー処理部１２０が保持する発注情報を取得し、業務サーバ２００に送信する。また、ＧＥＴ側処理部１３０は、キュー処理部１２０から通知情報を受け付け、通知情報を管理者に通知する、また、業務サーバ２００に送信する。ＧＥＴ側処理部１３０は、発注情報抽出部１３１、障害対応処理部１３２および発注情報送信部１３３を有する。

発注情報抽出部１３１は、業務サーバ２００からのリクエストに応じてキュー処理部１２０にＧＥＴ要求を送信する。また、発注情報抽出部１３１は、ＧＥＴ要求に応じてキュー処理部１２０から取得した発注情報を発注情報送信部１３３に出力する。また、発注情報抽出部１３１は、キュー処理部１２０に送信したＧＥＴ要求に応じて通知情報を通知した場合、取得した通知情報を障害対応処理部１３２に出力する。

障害対応処理部１３２は、発注情報抽出部１３１から取得した通知情報で示される障害に応じてＧＥＴ側処理部１３０の所定の障害対応処理を行う。このような対応処理としては、例えば、ＧＥＴ側処理部１３０が通信する業務サーバ２００側のプロセスと連携して、障害の内容に応じた後処理を行うことが考えられる。

具体的には、発注を行ったユーザに対して、業務サーバ２００側から電子メールなどで注文が正常に受け付けられなかった旨を通知するなどの処理が考えられる。このようにすると、ＰＵＴ側処理部１１０が障害によってメッセージ送信できないような場合でも、ユーザに対する通知を確実に行うことができる。

また、例えば、業務サーバ２００側の関連プロセスからの注文情報の取得要求に対して障害理由を通知した上で、障害のメンテナンスのために該当の関連プロセスとの通信を一時的に停止することなどが考えられる。このようにすると、例えば、業務サーバ２００が複数の受付サーバとデータ通信する場合に、障害の起こった受付サーバ１００からの注文情報の取得が停止される。このため、業務サーバ２００側での無用なプロセスの発生を抑止することができる。

更に、障害対応処理部１３２は、管理者に対してＰＵＴ側処理部１１０の障害を通知するための通知画面を生成する。
発注情報送信部１３３は、発注情報抽出部１３１から取得した発注情報を業務サーバ２００に送信する。

図５は、キューの構造例を示す図である。発注情報用キュー１２１は、リングバッファにより実現できる。発注情報用キュー１２１では、記憶領域としてサイズＮの固定領域が割り当てられている。すなわち、アドレスが０からＮ−１までの記憶領域が割り当てられている。ここで、データ格納部１２３が発注情報用キュー１２１に発注情報に対応するデータ（発注レコード）を格納する場合は、記憶領域の先頭（アドレスが０の位置）から開始して、データ格納済み領域の末尾に順にデータを追加していく。また、データ取出部１２４が発注情報用キュー１２１からデータを取り出す場合は、データ格納済み領域の先頭から順にデータを取り出す。なお、格納するデータのサイズは、固定長であってもよいし、可変長であってもよい。

発注情報用キュー１２１では、データ格納済み領域の先頭を示すＨｅａｄポインタと、データ格納済み領域の末尾を示すＴａｉｌポインタとが設定される。Ｈｅａｄポインタは、データが取り出されるごとに、次のデータの先頭に移動する。Ｔａｉｌポインタは、データが追加されるごとに、新たに追加されたデータの末尾の位置に移動する。そして、Ｔａｉｌポインタは、記憶領域の末尾（アドレスがＮ−１）を超えると、記憶領域の先頭（アドレスが０）に戻る。このようにして、発注情報用キュー１２１では、固定領域が順次再利用される。なお、データが取り出された場合には、例えば該当の領域のデータをクリア（または、取り出し済みを示すフラグを格納）する。このようにすると、発注情報用キュー１２１に未取り出しのデータが存在するか否かの検出を行うことができる。

図６は、発注レコードのデータ構造例を示す図である。発注レコード１２１ａは、発注情報生成部１１２によって生成される。そして、発注レコード１２１ａは、データ格納部１２３により発注情報用キュー１２１に格納される。発注レコード１２１ａには、オーダーＩＤを示す項目、顧客ＩＤを示す項目、注文商品コードを示す項目、数量を示す項目および価格を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つの発注レコードを示す。

オーダーＩＤを示す項目には、発注レコードを識別するためのＩＤが設定される。顧客ＩＤを示す項目には、顧客を識別するためのＩＤが設定される。注文商品コードを示す項目には、注文対象の商品を識別するためのコードが設定される。数量を示す項目には、注文対象の商品の注文数量が設定される。価格を示す項目には、該当の商品注文の該当の数量分の価格が設定される。

発注レコード１２１ａには、例えば、オーダーＩＤが“００１２３４”、顧客ＩＤが“Ｃ０００１”、注文商品コードが“０１２３４５６７８９”、数量が“２”、価格が“１００，０００”という情報が設定される。

図７は、障害区分管理テーブルのデータ構造例を示す図である。障害区分管理テーブル１２２ａは、受付サーバ１００の起動時などにデータ格納部１２３により通知情報記憶部１１３から読み出され、通知情報記憶部１２２に格納される。障害区分管理テーブル１２２ａには、エラーＩＤを示す項目および障害区分を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つの障害区分に関する情報を示す。

エラーＩＤを示す項目には、エラーを識別するＩＤの範囲を示す情報が設定される。障害区分を示す項目には、該当のエラーＩＤに対応する障害の区分（障害が発生したプロセスなどを特定するための情報）が設定される。

障害区分管理テーブル１２２ａには、例えば、エラーＩＤが“Ｅ００００〜Ｅ００９９”、障害区分が“発注受付処理エラー”という情報が設定される。これは、エラーＩＤ範囲“Ｅ００００〜Ｅ００９９”に含まれるエラーＩＤによって識別されるエラーの区分が発注受付部１１１で発生した障害を示すものであることを示している。

また、障害区分管理テーブル１２２ａには、例えば、エラーＩＤが“Ｅ０１００〜Ｅ０１９９”、障害区分が“発注情報生成処理エラー”という情報が設定される。これは、エラーＩＤ範囲“Ｅ０１００〜Ｅ０１９９”に含まれるエラーＩＤによって識別されるエラーの区分が発注情報生成部１１２で発生した障害を示すものであることを示している。

図８は、エラー管理テーブルのデータ構造例を示す図である。エラー管理テーブル１２２ｂ−１，１２２ｂ−２，１２２ｂ−３，・・・は、受付サーバ１００の起動時などにデータ格納部１２３により通知情報記憶部１１３から読み出され、通知情報記憶部１２２に格納される。エラー管理テーブル１２２ｂ−１，１２２ｂ−２，１２２ｂ−３，・・・は、障害区分管理テーブル１２２ａの障害区分に対応付けられる。例えば、エラー管理テーブル１２２ｂ−１は、障害区分“発注受付処理エラー”に対応付けられている。

以下では、エラー管理テーブル１２２ｂ−１に関してのみ説明するが、エラー管理テーブル１２２ｂ−２，１２２ｂ−３，・・・に関しても同様の構成である。
エラー管理テーブル１２２ｂ−１には、エラーＩＤを示す項目および送信メッセージを示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、エラーに関する情報を示す。

エラーＩＤを示す項目には、エラーを識別するＩＤが設定される。エラー詳細を示す項目には、該当のエラーＩＤに対応するエラーの内容を示す情報が設定される。
エラー管理テーブル１２２ｂ−１には、例えば、エラーＩＤが“Ｅ００００”、エラー詳細が“ｏｕｔ ｏｆ ｍｅｍｏｒｙ ｅｒｒｏｒ”という情報が設定される。これは、発注受付部１１１において、メモリ不足によるエラーが発生していることを示している。

図９は、ユーザ管理テーブルのデータ構造例を示す図である。ユーザ管理テーブル１２２ｃは、受付サーバ１００の起動時などにデータ格納部１２３により通知情報記憶部１１３から読み出され、通知情報記憶部１２２に格納される。ユーザ管理テーブル１２２ｃには、ポート番号を示す項目および顧客ＩＤを示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、ユーザに関する情報を示す。

ポート番号を示す項目には、端末装置２１，２２，２３，・・・に発注受付のサービスを提供するためにＰＵＴ側処理部１１０が使用するポート番号が設定される。顧客ＩＤを示す項目には、該当のポート番号を用いて通信する顧客の顧客ＩＤが設定される。

ユーザ管理テーブル１２２ｃには、例えば、ポート番号が“２１００１”、顧客ＩＤが“Ｃ０００１”という情報が設定される。これは、ポート番号“２１００１”で通信する通信先の端末装置を利用するユーザの顧客ＩＤが“Ｃ０００１”であることを示している。例えば、企業などに発注受付のサービスを提供する場合、このようにポート番号と顧客ＩＤとが一対一に対応付けられる。

また、ユーザ管理テーブル１２２ｃには、例えば、ポート番号が“２５００１〜２６０００”、顧客ＩＤが“Ｃ１００１〜Ｃ２０００”という情報が設定される。これは、ポート番号“２５００１〜２６０００”で通信する通信先の端末装置を利用するユーザの顧客ＩＤが“Ｃ１００１〜Ｃ２０００”であることを示している。例えば、不特定多数のユーザにサービスを提供する場合、このように複数のポートを複数の顧客ＩＤに対して割り当てる。

発注情報生成部１１２は、キュー処理部１２０に出力する障害情報に、該当の発注を受け付けた際の上記ポート番号を含める。データ取出部１２４は、制御部１２５から、障害情報に含まれるポート番号を取得し、通知情報記憶部１２２に記憶されたユーザ管理テーブル１２２ｃを参照することで、エラーが発生した顧客の顧客ＩＤを特定することができる。

図１０は、エラー通知情報の具体例を示す図である。（Ａ）は、通信パケットの所定の領域に複数の項目を設けて送信する場合を例示している。（Ｂ）は、ＸＭＬ文書で送信する場合を例示している。

エラー通知情報１２４ａは、データ取出部１２４によって生成され、ＧＥＴ側処理部１３０に送信される。エラー通知情報１２４ａには、エラーＩＤを示す領域、エラー区分を示す領域、エラー詳細を示す領域、発生日を示す領域、発生時刻を示す領域および対象顧客ＩＤを示す領域が設けられている。

エラーＩＤを示す領域には、エラーを識別するＩＤが設定される。エラー区分を示す領域には、該当のエラーＩＤに対応するエラー区分を示す情報が設定される。エラー詳細を示す項目には、エラーＩＤに対応するエラー内容の詳細を示すメッセージが設定される。発生日を示す項目には、該当のエラーの発生日付が設定される。発生時刻を示す項目には、該当のエラーの発生時刻が設定される。対象顧客ＩＤを示す項目には、該当のエラーが発生した注文を行ったユーザの顧客ＩＤが設定される。

エラー通知情報１２４ｂは、データ取出部１２４によってエラー通知情報１２４ａに替えて生成される。エラー通知情報１２４ｂには、エラー通知情報１２４ａに含まれる各項目の情報を、所定のタグによって識別することができる。

ＧＥＴ側処理部１３０や業務サーバ２００は、エラー通知情報１２４ａ，１２４ｂの内容に応じて、管理者への通知や所定のリカバリ処理を実行することができる。
エラー通知情報１２４ａ，１２４ｂの何れを生成するかは、ＧＥＴ側処理部１３０や業務サーバ２００が取り扱うデータの形式に応じて選択される。なお、以下では、データ取出部１２４は、エラー通知情報１２４ａを生成するものとする。

図１１は、エラー通知画面の表示例を示す図である。エラー通知ウィンドウ１５０は、障害対応処理部１３２により、エラー通知情報１２４ａに基づいて生成され、モニタ５１に表示される。エラー通知ウィンドウ１５０には、エラーの詳細な内容を示すエラー表示領域１５１が設けられている。エラー表示領域１５１には、ＰＵＴ側処理部１１０でエラーが発生した旨を示すメッセージ（例えば、“発注受付サービスでエラーが発生しました”など）や発生したエラーに関する情報が表示される。例えば、該当のエラーの発生日、発生時刻、障害区分、エラーＩＤ、対象顧客ＩＤおよびエラー詳細が表示される。障害対応処理部１３２は、エラー通知情報１２４ａに含まれる情報を参照して、これらの情報を取得することができる。

管理者は、エラー通知ウィンドウ１５０に表示された内容を閲覧することで、ＰＵＴ側処理部１１０で発生したエラーを認識し、該当の障害に対する対応作業を行える。
次に、以上のような構成を有する受付サーバ１００の処理に関して説明する。

図１２は、データ通信処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］受付サーバ１００が起動する。そして、ＰＵＴ側処理部１１０、キュー処理部１２０およびＧＥＴ側処理部１３０が起動する。

［ステップＳ１２］キュー処理部１２０は、発注情報用キュー１２１を実現するための領域をＲＡＭ１０２上に確保する。
［ステップＳ１３］キュー処理部１２０は、通知情報記憶部１２２を実現するための領域をＲＡＭ１０２上に確保する。

［ステップＳ１４］データ格納部１２３は、通知情報記憶部１１３に記憶された障害区分管理テーブル１２２ａ、エラー管理テーブル１２２ｂ−１，１２２ｂ−２，１２２ｂ−３，・・・およびユーザ管理テーブル１２２ｃを取得し、通知情報記憶部１２２に格納する。これにより、ＰＵＴ側処理部１１０とＧＥＴ側処理部１３０との間のキュー処理部１２０を介したデータ通信を行う準備が整う。

［ステップＳ１５］データ格納部１２３は、発注情報生成部１１２からＰＵＴ要求を受け付けたか否かを判定する。受け付けた場合、処理がステップＳ１６に移される。受け付けていない場合、処理がステップＳ１７に移される。

［ステップＳ１６］データ格納部１２３は、ＰＵＴ要求に含まれる発注レコードを発注情報用キュー１２１に格納する。
［ステップＳ１７］データ取出部１２４は、発注情報抽出部１３１からＧＥＴ要求を受け付けたか否かを判定する。受け付けた場合、処理がステップＳ１８に移される。受け付けていない場合、処理がステップＳ１９に移される。

［ステップＳ１８］データ取出部１２４は、発注情報用キュー１２１に最も過去に格納された発注レコードを取り出す。データ取出部１２４は、取り出した発注レコードを発注情報抽出部１３１に送信する。

［ステップＳ１９］制御部１２５は、データ格納部１２３を介してＰＵＴ側処理部１１０から障害情報を受け付けたか否か（または、既に受け付け済みか否か）を判定する。受け付けた（または、既に受け付け済みである）場合、制御部１２５は障害情報を受け付けた日時を取得して、処理がステップＳ２０に移される。受け付けていない場合、処理がステップＳ１５に移される。なお、本ステップにおいて「障害情報を既に受け付け済みである場合」とは、「障害情報を受け付け後、発注情報用キュー１２１に格納された発注情報が全てＧＥＴ側処理部１３０に送信されるまでの間」に制御部１２５が判定し得る状態である。このため、この場合には制御部１２５は既に障害情報を受け付けた日時を取得済みであるので、この日時取得処理は省略される。

［ステップＳ２０］制御部１２５は、障害情報を受け付けた旨をデータ取出部１２４に通知する。データ取出部１２４は、発注情報用キュー１２１に格納された発注レコードが全て送信済みであるか否かを判定する。全て送信済みである場合、処理がステップＳ２１に移される。全て送信済みでない場合、処理がステップＳ１７に移される。

［ステップＳ２１］データ取出部１２４は、制御部１２５から障害情報に含まれるエラーＩＤ、障害が発生したタイミングで注文を受け付けたポート番号および上記ステップＳ１９で制御部１２５が取得した障害発生の日時を取得する。そして、データ取出部１２４は、取得したエラーＩＤに基づき通知情報記憶部１２２に記憶された障害区分管理テーブル１２２ａを参照して障害区分を取得する。また、データ取出部１２４は、取得したエラーＩＤに基づき通知情報記憶部１２２に記憶されたエラー管理テーブル１２２ｂ−１，１２２ｂ−２，１２２ｂ−３，・・・を参照してエラー詳細を取得する。更に、データ取出部１２４は、取得したポート番号に基づきユーザ管理テーブル１２２ｃを参照して、対象のユーザの顧客ＩＤを取得する。データ取出部１２４は、これらの情報を用いてエラー通知情報１２４ａを生成する。

［ステップＳ２２］データ取出部１２４は、発注情報抽出部１３１からＧＥＴ要求を取得したか否かを判定する。取得した場合、処理がステップＳ２３に移される。取得していない場合、処理がステップＳ２２に移される（すなわち、ＧＥＴ要求を待機する）。

［ステップＳ２３］データ取出部１２４は、上記ステップＳ２１で生成したエラー通知情報１２４ａを発注情報抽出部１３１に送信する。
［ステップＳ２４］発注情報抽出部１３１は、受信したエラー通知情報１２４ａを障害対応処理部１３２に出力する。障害対応処理部１３２は、エラー通知情報１２４ａに基づいて、エラー通知ウィンドウ１５０を生成し、管理者にＰＵＴ側処理部１１０で障害が発生していることを通知する。また、障害対応処理部１３２は、ＰＵＴ側処理部１１０の障害に応じた所定の対応処理を実行する。

このようにして、受付サーバ１００では、ＰＵＴ側処理部１１０の通知情報をシステム起動時にキュー処理部１２０の通知情報記憶部１２２に予め登録する。そして、ＰＵＴ側処理部１１０で障害が発生した場合には、キュー処理部１２０は、その障害を識別するための情報を受け付け、通知情報記憶部１２２を参照して該当の障害に対応する通知情報をＧＥＴ側処理部１３０に送信する。

図１３は、障害通知の流れの具体例を示すシーケンス図である。以下、図１３に示す処理をステップ番号に沿って説明する。
［ステップＳ３１］ＰＵＴ側処理部１１０は、端末装置２１，２２，２３，・・・から商品発注を受け付けると、キュー処理部１２０に対して発注レコードを含むＰＵＴ要求を送信する。キュー処理部１２０は、ＰＵＴ要求を受け付けると、ＰＵＴ要求に含まれる発注レコードを発注情報用キュー１２１に格納する。

［ステップＳ３２］キュー処理部１２０は、ＰＵＴ側処理部１１０からＰＵＴ要求を受け付け、ＰＵＴ要求に含まれる発注レコードを発注情報用キュー１２１に格納する。
［ステップＳ３３］ＧＥＴ側処理部１３０は、業務サーバ２００から発注レコード取得のリクエストを受け付けると、キュー処理部１２０に対してＧＥＴ要求を送信する。

［ステップＳ３４］キュー処理部１２０は、ＧＥＴ要求に応じて発注情報用キュー１２１から発注レコードを取り出し、ＧＥＴ側処理部１３０に送信する。
［ステップＳ３５］キュー処理部１２０は、ＰＵＴ側処理部１１０からＰＵＴ要求を受け付け、ＰＵＴ要求に含まれる発注レコードを発注情報用キュー１２１に格納する。

［ステップＳ３６］ＧＥＴ側処理部１３０は、キュー処理部１２０に対してＧＥＴ要求を送信する。
［ステップＳ３７］キュー処理部１２０は、ＧＥＴ要求に応じて発注情報用キュー１２１から発注レコードを取り出し、ＧＥＴ側処理部１３０に送信する。以降、上記ステップＳ３１〜Ｓ３７と同様の処理が繰り返される。

［ステップＳ３８］ＰＵＴ側処理部１１０は、発注の受付処理に関する障害を検知する。
［ステップＳ３９］ＰＵＴ側処理部１１０は、キュー処理部１２０に対して検知した障害に応じた障害情報を送信する。キュー処理部１２０は、ＰＵＴ側処理部１１０から障害情報を受信する。ただし、この時点でキュー処理部１２０に格納された発注レコードに未送信のものが存在するものとする。この場合、キュー処理部１２０は、ＧＥＴ側処理部１３０に対するエラー通知を保留する。

［ステップＳ４０］ＧＥＴ側処理部１３０は、キュー処理部１２０に対してＧＥＴ要求を送信する。
［ステップＳ４１］キュー処理部１２０は、ＧＥＴ要求に応じて発注情報用キュー１２１から発注レコードを取り出し、ＧＥＴ側処理部１３０に送信する。

［ステップＳ４２］ＧＥＴ側処理部１３０は、キュー処理部１２０に対してＧＥＴ要求を送信する。
［ステップＳ４３］キュー処理部１２０は、ＧＥＴ要求に応じて発注情報用キュー１２１から発注レコードを取り出し、ＧＥＴ側処理部１３０に送信する。ここで、キュー処理部１２０は、全ての発注レコードをＧＥＴ側処理部１３０に対して送信済みであることを検知するものとする。すると、キュー処理部１２０は、上記ステップＳ３９で受信した障害情報に基づいてエラー通知情報の生成を行う。

［ステップＳ４４］ＧＥＴ側処理部１３０は、キュー処理部１２０に対してＧＥＴ要求を送信する。
［ステップＳ４５］キュー処理部１２０は、ＧＥＴ要求に応じて上記ステップＳ４３で生成したエラー通知情報をＧＥＴ側処理部１３０に送信する。ＧＥＴ側処理部１３０は、受信したエラー通知情報に応じて、所定の対応処理を実行する。

このように、キュー処理部１２０は、ＰＵＴ側処理部１１０から障害情報を受信した後、キュー処理部１２０が保持する注文レコードを全てＧＥＴ側処理部１３０に送信済みとなったタイミングでエラー通知情報をＧＥＴ側処理部１３０に送信する。このため、キュー処理部１２０が正常に受け付けた発注レコードに関しては、通常通り業務サーバ２００に送信して、その後の受注処理を行うことができる。

なお、ＧＥＴ側処理部１３０が実行する対応処理として、受付サーバ管理者に対する障害の通知が行われる。管理者は、ＧＥＴ側処理部１３０がモニタ５１に表示するエラー通知ウィンドウ１５０を参照して障害の詳細な内容を把握し、対応作業を行うことができる。

また、例えば、ＧＥＴ側処理部１３０が通信する業務サーバ２００側のプロセスと連携して、障害の内容に応じた後処理を行うことが考えられる。
具体的には、発注を行ったユーザに対して、業務サーバ２００側から電子メールなどで注文が正常に受け付けられなかった旨を通知するなどの処理が考えられる。このようにすると、ＰＵＴ側処理部１１０が障害によってメッセージ送信できないような場合でも、ユーザに対する通知を確実に行うことができる。

また、例えば、業務サーバ２００側の関連プロセスからの注文情報の取得要求に対して障害理由を通知した上で、障害のメンテナンスのために該当の関連プロセスとの通信を一時的に停止することなどが考えられる。このようにすると、例えば、業務サーバ２００が複数の受付サーバとデータ通信する場合に、障害の起こった受付サーバ１００からの注文情報の取得が停止される。このため、業務サーバ２００側での無用なプロセスの発生を抑止することができる。

図１４は、障害対応の第１の具体例を示す図である。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳＴ１０１］ＧＥＴ側処理部１３０は、端末装置２１との通信に対して障害が発生したことを検知する。

［ステップＳＴ１０２］ＧＥＴ側処理部１３０は、業務サーバ２００に障害が発生した旨を通知する。
［ステップＳＴ１０３］ＧＥＴ側処理部１３０と業務サーバ２００とは、障害の内容に応じた対応処理を行う。例えば、ＧＥＴ側処理部１３０と業務サーバ２００との間の関連するプロセス間通信を一時的に停止するなどの後処理が考えられる。また、業務サーバ２００側から、端末装置２１のユーザに対して注文が正常に受け付けられなかった旨の通知を電子メールなどによって行うことが考えられる。

［ステップＳＴ１０４］ＧＥＴ側処理部１３０は、モニタ５１にエラー通知ウィンドウを表示して、管理者に障害が発生したことを通知する。
［ステップＳＴ１０５］受付サーバ１００の管理者は、エラー通知ウィンドウにより発生した障害の詳細を確認して、該当の障害に対する対応を行う。

このように、受付サーバ１００では、ＰＵＴ側処理部１１０で発生し得る障害の内容をキュー処理部１２０に予め格納する。そして、ＰＵＴ側処理部１１０は、キュー処理部１２０に少なくとも障害の識別情報および該当のポート番号を送信するのみで、ＧＥＴ側処理部１３０に発生した障害の詳細を通知することができる。

このようにすることで、たとえＰＵＴ側処理部１１０の機能が障害によって制限された場合でも、ＧＥＴ側処理部１３０で障害内容を確実に検知できるようになる。また、ＧＥＴ側処理部１３０側での業務サーバ２００との間の関連プロセスにおける後処理を確実に実行することができる。

更に、障害の通知に際して、キュー処理部１２０を介した通信経路を活用できるので、ＰＵＴ側処理部１１０とＧＥＴ側処理部１３０との間に、このための新たな通信経路を設ける必要がない。

なお、電子商取引システム１０において、受注システム１２から発注システム１１にデータを送信する場合も考えられる。具体的には、受注内容に応じて取引上の約款や取引の契約内容を端末装置２１，２２，２３，・・・に送信することが考えられる。

このため、受付サーバに、受注システム１２から発注システム１１へのデータ通信を行うためのＰＵＴ側処理部、キュー処理部およびＧＥＴ側処理部と同様の構成が更に設けられた場合を考えることができる。なお、これらの構成は、発注システム１１から受注システム１２へのデータ通信を行うためのＰＵＴ側処理部１１０、キュー処理部１２０およびＧＥＴ側処理部１３０の構成とは別個に設けられるものである。この場合、受注システム１２から発注システム１１へのデータ通信に対しても、上述した機能を実現することができる。

以下では、このような構成の電子商取引システムの障害対応の具体例を説明する。
図１５は、障害対応の第２の具体例を示す図である。以下、図１５に示す処理をステップ番号に沿って説明する。なお、電子商取引システム１０ａが有する受付サーバ１００ａは、発注システム１１から受注システム１２へのデータ通信に上述の発注情報用キューを介したプロセス間通信を行うほか、受注システム１２から発注システム１１へのデータ通信に関しても約款などを格納するためのキューを介したプロセス間通信を行う。また、受付サーバ１００ａにおいて業務サーバ２００側から約款などのデータを受け付けるアプリケーションをＰＵＴ側処理部と呼ぶこととする。また、ＰＵＴ側処理部が受け付けたデータを格納するキューを応答情報用キューと呼ぶこととする。応答情報用キューからデータを取り出して端末装置２１，２２，２３，・・・に送信するアプリケーションをＧＥＴ側処理部と呼ぶこととする。

［ステップＳＴ２０１］ＧＥＴ側処理部は、応答情報用キューからのエラー通知により、業務サーバ２００との通信に対して障害が発生したことを検知する。
［ステップＳＴ２０２］ＧＥＴ側処理部は、業務サーバ２００に障害が発生した旨を通知する。

［ステップＳＴ２０３］業務サーバ２００は、障害の内容に応じた対応処理を行う。例えば、業務サーバ２００とＰＵＴ側処理部との間の関連するプロセス間通信を一時的に停止するなどの後処理が考えられる。また、業務サーバ２００側から、通信対象のユーザに対してデータ送信が正常に受け付けられなかった旨の通知を電子メールなどによって行うことが考えられる。

［ステップＳＴ２０４］ＧＥＴ側処理部は、モニタ５１にエラー通知ウィンドウを表示して、管理者に障害が発生したことを通知する。
［ステップＳＴ２０５］受付サーバ１００ａの管理者は、エラー通知ウィンドウにより発生した障害の詳細を確認して、該当の障害に対する対応を行う。

このように、発注システム１１と受注システム１２との間の双方向のデータ通信に関して、ＰＵＴ側処理部１１０、キュー処理部１２０およびＧＥＴ側処理部１３０に対応する構成を別個に設けることで、双方向のデータ通信それぞれについて、発生した障害の詳細を確実に取得することが可能となる。また、双方向のデータ通信それぞれについて、障害に応じた後処理を適宜実行することができる。

以上説明したように、受付サーバ１００によればＰＵＴ側処理部１１０で生じた障害をＧＥＴ側処理部１３０に効率的に通知することができる。具体的には、障害が発生した旨を示す通知情報が、キュー処理部１２０を介したデータ通信と同じ通信経路で送信可能なので、別個に通信経路を設ける必要がない。また、ＧＥＴ側処理部１３０は、発注情報用キューに対する発注レコードの取得要求を継続的に送信していれば、その応答としてエラー通知情報を適宜取得できるので、データ通信以外の処理手順を新たに設ける必要もない。

また、以上の説明では、受付サーバ１００にキューを設けることとしたが、受け付けたデータの順序がＧＥＴ側処理部１３０または業務サーバ２００における処理に影響を及ぼさない場合には、キューに替えてスタックとすることもできる。

なお、受付サーバ１００が有すべき機能は、コンピュータにより実現することができる。その場合には、これらの処理機能の処理内容を記述したプログラムが提供される。そして、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録された光ディスクなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、そのプログラムを、サーバコンピュータからネットワークを介して他のコンピュータに転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、そのプログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上、本発明の通信制御プログラム、通信システム、通信制御装置および通信制御方法を図示の実施の形態に基づいて説明したが、これらに限定されるものではなく、各部の構成は同様の機能を有する任意の構成のものに置き換えることができる。また、他の任意の構成物や工程が付加されてもよい。また、本発明は前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ コンピュータ
１ａ，１ｂ 実行手段
１ｃ 送信情報記憶手段
１ｄ 通知情報記憶手段
１ｅ 格納手段
１ｆ 取出手段
１ｇ 制御手段

Claims (8)

1. コンピュータを、
   所定の第１の処理を実行する第１の実行手段から送信情報を順次受け付け、当該送信情報それぞれを送信情報記憶手段に格納する格納手段、
   所定の第２の処理を実行する第２の実行手段から前記送信情報の取得要求を順次受け付け、当該取得要求それぞれに応じて前記送信情報記憶手段に記憶された前記送信情報それぞれを取得し、当該送信情報それぞれを前記第２の実行手段に出力する取出手段、
   障害が発生した旨を示す障害情報を前記格納手段から取得すると、前記障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された前記通知情報を前記取出手段に取得させ、前記取得要求に応じて当該通知情報を前記第２の実行手段へ出力させる制御手段、
   として機能させることを特徴とする通信制御プログラム。
2. 前記通知情報記憶手段は、前記障害を識別するための障害識別情報と前記通知情報とを対応付けて記憶しており、
   前記制御手段は、前記取出手段から取得した前記障害情報に含まれる前記障害識別情報を抽出し、前記通知情報記憶手段を参照して、当該障害識別情報に対応する前記通知情報を前記取出手段に取得させる、
   ことを特徴とする請求項１記載の通信制御プログラム。
3. 前記取出手段は、前記制御手段から前記通知情報の取得を指示されると、前記送信情報記憶手段に記憶された全ての前記送信情報を前記第２の実行手段に出力した後に、前記通知情報を前記第２の実行手段へ出力する、
   ことを特徴とする請求項１または２の何れか１項に記載の通信制御プログラム。
4. 前記取出手段は、前記取得要求を受け付けると、前記送信情報記憶手段に記憶された前記送信情報のうち、前記格納手段により最も過去に格納された送信情報を取得することを特徴とする請求項１乃至３の何れか１項に記載の通信制御プログラム。
5. 前記取出手段は、前記取得要求を受け付けると、前記送信情報記憶手段に記憶された前記送信情報のうち、前記格納手段により最も新しく格納された送信情報を取得することを特徴とする請求項１乃至３の何れか１項に記載の通信制御プログラム。
6. ネットワークを介して接続された送信装置と受信装置と、前記送信装置および前記受信装置の間のデータ通信を中継する通信制御装置とを備えた通信システムであって、
   前記送信装置から送信情報を受信する第１の実行手段と、
   前記第１の実行手段から送信情報を順次受け付け、当該送信情報それぞれを送信情報記憶手段に格納する格納手段と、
   前記送信情報の取得要求を順次受け付け、当該取得要求それぞれに応じて前記送信情報記憶手段に記憶された前記送信情報それぞれを取得し、当該送信情報それぞれを前記取得要求の送信元に出力する取出手段と、
   前記取得要求を前記取出手段に出力し、当該取得要求に応じて前記取出手段から前記送信情報を取得し、当該送信情報を前記受信装置に送信する第２の実行手段と、
   障害が発生した旨を示す障害情報を前記格納手段から取得すると、前記障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された前記通知情報を前記取出手段に取得させ、前記取得要求に応じて当該通知情報を前記第２の実行手段へ出力させる制御手段と、
   を備える前記通信制御装置、
   を有することを特徴とする通信システム。
7. 所定の第１の処理を実行する第１の実行手段から送信情報を順次受け付け、当該送信情報それぞれを送信情報記憶手段に格納する格納手段と、
   所定の第２の処理を実行する第２の実行手段から前記送信情報の取得要求を順次受け付け、当該取得要求それぞれに応じて前記送信情報記憶手段に記憶された前記送信情報それぞれを取得し、当該送信情報それぞれを前記第２の実行手段に出力する取出手段と、
   障害が発生した旨を示す障害情報を前記格納手段から取得すると、前記障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された前記通知情報を前記取出手段に取得させ、前記取得要求に応じて当該通知情報を前記第２の実行手段へ出力させる制御手段と、
   を有することを特徴とする通信制御装置。
8. コンピュータの通信制御方法であって、
   格納手段が、所定の第１の処理を実行する第１の実行手段から送信情報を順次受け付け、当該送信情報それぞれを送信情報記憶手段に格納し、
   取出手段が、所定の第２の処理を実行する第２の実行手段から前記送信情報の取得要求を順次受け付け、当該取得要求それぞれに応じて前記送信情報記憶手段に記憶された前記送信情報それぞれを取得し、当該送信情報それぞれを前記第２の実行手段に出力し、
   制御手段が、障害が発生した旨を示す障害情報を前記格納手段から取得すると、前記障害の内容を定義した通知情報を記憶する通知情報記憶手段に記憶された前記通知情報を前記取出手段に取得させ、前記取得要求に応じて当該通知情報を前記第２の実行手段へ出力させる、
   ことを特徴とする通信制御方法。

Images