複数のイベント制御サーバからなるイベント制御層と、複数の業務サーバとからなる業務アプリケーション層と、からなるイベント処理システムにおいて、前記イベント制御サーバは、イベント発生源インタフェースと、イベント制御部と、複数の業務サーバインタフェースとから構成され、前記イベント制御部は、受信したイベント内容に基づいて、前記業務サーバへのアクセスの排他制御と流量制御とを考慮したシナリオを作成し、このシナリオに基づいて、前記業務サーバにアクセスするように前記イベント制御サーバを制御することを特徴とするイベント処理システム。請求項1に記載のイベント処理システムであって、前記業務サーバから、エラー応答を受信したとき、前記イベント制御部は、リトライまたはリカバーを選択して前記エラー応答を送信した業務サーバまたは他の業務サーバにアクセスするように前記イベント制御サーバを制御することを特徴とするイベント処理システム。通信事業者のOSS/BSS基盤イベント処理システムでは、大量の処理イベントが集中する。このため、イベント処理システムは、多数のサーバ群によるシステム構成となる。このようなサーバ群で同時にイベントを実行する場合、サーバ群全体でのイベントの制御が必要になってくる。このため、業務アプリケーションに制御ロジックの組み込みが必要になり、開発が複雑化している。そこで、メンテナンス性運用性を担保し、業務アプリケーション開発の単純化を実現するアーキテクチャを検討する必要がある。イベントの制御と業務アプリケーション開発を明確に分離したシステムアーキテクチャとし、業務処理実装の単純化効率化する仕組みとする。各種入力チャネルからOSS/BSS基盤に対する入力データを、業務アプリケーションが直接インタフェースせずに、入力チャネルと業務アプリケーションの間に、イベント制御層を設ける。ここで、各種入力チャネルとは、オンライン申込、外部システム等である。イベント制御層では、業務アプリケーションと入力チャネルとの仲介連携を行ない、各イベントの制御を行なう。ここで、イベントとは、具体的には入力されたデータである。イベントの各種インタフェースやステータス管理、シーケンス制御、流量制御、複数業務アプリケーションへのロードバランス、エラー制御等の非機能要件非業務処理要件は、全てイベント制御層で行なう。ここで、エラー制御とは、具体的にはリトライ、リカバリである。上述した課題は、複数のイベント制御サーバからなるイベント制御層と、複数の業務サーバとからなる業務アプリケーション層と、からなるイベント処理システムにおいて、イベント制御サーバは、イベント発生源インタフェースと、イベント制御部と、複数の業務サーバインタフェースとから構成され、イベント制御部は、受信したイベント内容に基づいて、業務サーバへのアクセスの排他制御と流量制御とを考慮したシナリオを作成し、このシナリオに基づいて、業務サーバにアクセスするようにイベント制御サーバを制御するイベント処理システムにより、解決できる。イベント制御層を設けたことにより、イベント制御と業務アプリケーションの役割を明確化し、業務アプリケーションでは制御ロジックを排除し、開発の単純化を実現できる。以下、本発明の実施の形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。図1を参照して、イベント処理システム500を説明する。図1において、イベント処理システム500は、通信回線109を介して入力チャネルと相互接続されたイベント制御層と、通信回線110を介して、イベント制御層と接続された業務アプリケーションAP層とで構成されている。入力チャネルは、複数のイベント発生源100で構成されている。イベント発生源100からのデータは、具体的には、オンライン申込Web、他システムからのデータである。イベント発生源100は、それらデータの送信元であるサーバまたは端末機である。イベント制御層は、複数のイベント制御サーバ200で構成されている。イベント制御サーバ200は、入力イベントの制御ロジックが実装されたサーバである。業務アプリケーション層は、複数の業務APサーバ300で構成されている。異なる業務APを実行する業務APサーバ300は、業務APサーバ300A~300Dと区別する。同一の業務APを実行する業務APサーバ300Aは、業務APサーバ300A-1~300A-2と区別する。業務APサーバ300は、業務アプリケーションが実装されたサーバである。図1において、各サーバ100、200、300は、数台しか示されていないが、勿論、実際にはこれ以上のサーバ構成でも良い。本実施例のイベント処理システムでは、業務アプリケーションが直接イベント発生源からのデータを受信せず、イベント発生源と業務アプリケーションの間に、イベント制御サーバイベント制御層を設ける。図2を参照して、イベント制御層を構成するイベント制御サーバ200の構成を説明する。図2において、イベント制御サーバ200は、イベント発生源インタフェース201、イベント制御部202、4台の業務APインタフェース203から構成される。イベント制御サーバ200は、イベントDB207、イベントデータDB208と接続されている。イベント発生源インタフェース201は、イベント発生源からの処理要求イベントと結果通知を送受信する。イベント制御部202は、シーケンス制御、流量制御、複数業務アプリケーションへのロードバランス、エラー制御を実行する。業務APインタフェース203は、業務アプリケーションへの業務処理命令と処理結果を送受信する。業務APインタフェース203は、業務APを実行する業務APサーバ300に対応して、業務APインタフェース203A~203と区別する。イベントDB207は、受信した処理要求イベントの制御情報を格納する。イベントデータDB208は、受信した処理要求イベントのデータを格納する。図3を参照して、イベントデータベースおよびイベントデータデータベースのレコードを説明する。ここで、図3aは、イベントDBのレコードを説明する図である。また、図3bは、イベントデータDMのレコードを説明する図である。図3aにおいて、イベントDBのレコード400は、イベント種別401、イベントID402、イベントステータス403、シーケンスキー404、イベント受付時刻405から構成されている。一方、図3bにおいて、イベントデータDBのレコード410は、イベントID411、イベントデータ412から構成されている。図3aにおいて、イベント種別401は、必要な業務処理シナリオを特定し、イベント制御機能が処理要求する業務アプリケーションを選択する。また、イベント種別401は、エラー時の制御も決定する。イベントID402、411は、イベントの実データ412を特定する。イベントステータス403は、イベントのステータス結果を管理する。シーケンスキー404は、デッドロック更新順序不正を発生させないために、同一キーを持つ処理を順序通りシーケンス制御させる。イベント受付時刻405は、文字通りイベント制御サーバ200の受付時刻である。図4を参照して、イベント制御層を適用したイベント処理システムのシーケンスを説明する。図4において、イベント発生源100は、イベント発生源インタフェース201にイベント発生を通知するS101。イベント発生源インタフェース201は、イベントDB207に受け付けたイベントの管理情報を記録するS102。イベント発生源インタフェース201は、イベントデータDB208に受け付けたイベントの実データを記録するS103。ここで、イベント発生源インタフェース201は、管理情報と実データとを、イベントIDで紐付する。イベント発生源インタフェース201は、イベント発生源100にイベント応答を送信するS104。イベント制御部202は、イベント発生源インタフェース201が受け付けたイベントを受け付けた順にイベントDB207から取り込み、イベントの実データをイベントデータDB208から取り込むS106。イベント制御部202は、取り込んだイベントのイベント種別に基づいてシナリオを作成するS107。ここで、シナリオは、1つの業務アプリケーションだけを実行するシナリオと、複数の業務アプリケーションを実行する必要があるシナリオがある。複数ある場合は、実行順序が決められている。イベント制御部202は、業務APインタフェース203Aに処理要求を送信するS108。ここで、処理要求には、実データイベントデータDB208の内容が含まれている。業務APインタフェース203Aは、業務APサーバ300Aとのインタフェース機能を有し、業務APサーバ300Aに処理要求を送信するS109。業務APサーバ300Aは、業務アプリケーションプログラムを実行し図示省略:以下同様、業務APインタフェース203Aに処理結果を送信するS111。業務APインタフェース203Aは、イベント制御部202に処理結果を送信するS112。イベント制御部202は、イベントDB207のイベントのステータスを更新するS113。イベント制御部202は、シナリオを確認するS114。ここでは、2件目の業務アプリケーションの実行があるので、イベント制御部202は、業務APインタフェース203Cに処理要求を送信するS116。業務APインタフェース203Cは、業務APサーバ300Cに処理要求を送信するS117。業務APサーバ300Cは、業務APインタフェース203Cに処理結果を送信するS118。業務APインタフェース203Cは、イベント制御部202に処理結果を送信するS119。イベント制御部202は、イベントDB207のステータスを更新するS121。イベント発生源100は、イベント発生源インタフェース201に結果照会を送信するS123。イベント発生源インタフェース201は、イベントDB207からイベントの処理結果を取得するS124。イベント発生源インタフェース201は、イベント発生源100に結果通知を送信するS126。図5を参照して、図6のイベント取り込み時点でのイベントDB207の状態を説明する。図5において、イベントDB207AのイベントID001、002のシーケンスキー404は共に50である。同じ、シーケンスキーを持つレコードは、シーケンス制御が必要であることを表す。したがって、イベントIDの大きい002は、イベントステータス403が実行待ちとなっている。これに対して、イベントIDの小さい002と、シーケンスキーが異なるイベントID003は、イベントステータス403が実行となっている。図6を参照して、イベント処理システムのシーケンス制御を説明する。なお、図6のシーケンスは、基本的に図4と同じなので、要点のみ説明する。図6のステップ136において、図5のイベントDB207Aのシーケンスキーが同じイベントID001002について、イベント制御部202は、先に受け付けたイベントID001のみ取り込む。ステップ152において、イベント制御部202は、イベントDB207を更新して、イベントID001のイベントステータス403を終了、イベントID002のイベントステータス403を実行とする。そして、イベント制御部202は、イベントID002を取り込む。これらの処理により、イベント制御部202は、同一イベントキーの処理を同時実行させない。また、業務APサーバ300がデータベース図示せずの更新が必要な場合、イベント制御層でレコード単位にシーケンス制御されており、デッドロックおよび更新順序不正は発生しない。すなわち、業務APサーバは300、処理順序を意識せずに実行可能である。図7を参照して、イベント処理システムのエラー制御を説明する。図7のステップ161からステップ177までとステップ188からステップ191は、図4のステップ101からステップ117までとステップ123からステップ126までと同一なので説明を省略する。ステップ178において、業務APサーバ300Cは、処理結果NGの処理結果を業務APインタフェース203Cに送信する。業務APインタフェース203Cは、イベント制御部202に処理結果NGの処理結果を送信するS179。イベント制御部202は、エラー制御を実行するS181。イベント制御部202は、業務APインタフェース203Cにリトライ処理要求を送信するS182。業務APインタフェース203Cは、業務APサーバ300Cにリトライ処理要求を送信するS183。業務APサーバ300Cは、業務APインタフェース203Cに処理結果OKの処理結果を送信するS184。業務APインタフェース203Cは、イベント制御部202に処理結果OKの処理結果を送信するS186。イベント制御部202は、イベントDB207のステータスを更新するS187。なお、ここではエラー制御としてリトライを説明したが、業務APサーバ300C-1が、処理結果NGの処理結果を業務APインタフェース203Cに送信したとき、業務APサーバ300C-2にリカバー処理要求を送信するのが、リカバーである。図8を参照して、図9のイベント取り込み時点でのイベントDB207の状態を説明する。図8において、イベントDB207Bは、イベントID001~003のシーケンスキーは、互いに異なる。したがって、連続的に読み込み可能である。このため、イベントステータスは、いずれも実行である。また、イベントID001~003のイベント種別は、いずれもAである。したがって、イベントAの輻輳を防止するために、イベント処理システムは、分散並列処理を実行する。図9を参照して、イベント処理システムの分散並列処理を説明する。なお、図9のステップ201~ステップ204、ステップ229~ステップ232は、図4のステップ101~ステップ104、ステップ123~ステップ126と同一なので、説明を省略する。また、業務アプリケーション層は、3台の業務APサーバ300Aから構成されている点が、これまでのシーケンス図と異なる。図9において、イベント制御部202は、図8のイベントDB207BのイベントID001002003を順次取り込むS206。イベント制御部202は、シナリオ制御して、分散並列処理を決定するS207。イベント制御部202は、業務APインタフェース203Aに処理要求を送信するS208。この処理要求には、業務APサーバ300A-1の情報が含まれている。業務APインタフェース203Aは、業務APサーバ300A-1に処理要求を送信するS209。イベント制御部202は、シナリオを参照するS211。イベント制御部202は、業務APインタフェース203Aに処理要求を送信するS212。この処理要求には、業務APサーバ300A-2の情報が含まれている。業務APインタフェース203Aは、業務APサーバ300A-2に処理要求を送信するS213。イベント制御部202は、シナリオを参照するS214。イベント制御部202は、業務APインタフェース203Aに処理要求を送信するS216。この処理要求には、業務APサーバ300A-3の情報が含まれている。業務APインタフェース203Aは、業務APサーバ300A-3に処理要求を送信するS217。業務APサーバ300A-1は、業務APインタフェース203Aに処理結果を送信するS218。業務APインタフェース203Aは、イベント制御部202に処理結果を送信するS219。イベント制御部202は、イベントDB207のステータスを更新するS221。業務APサーバ300A-2は、業務APインタフェース203Aに処理結果を送信するS222。業務APインタフェース203Aは、イベント制御部202に処理結果を送信するS223。イベント制御部202は、イベントDB207のステータスを更新するS224。業務APサーバ300A-3は、業務APインタフェース203Aに処理結果を送信するS226。業務APインタフェース203Aは、イベント制御部202に処理結果を送信するS227。イベント制御部202は、イベントDB207のステータスを更新するS228。本実施例によれば、イベント制御層を設けたことにより、イベント制御と業務アプリケーションの役割を明確化し、業務アプリケーションでは制御ロジックを排除し、開発の単純化を実現できる。よって、各業務アプリケーションは、入力されてきたイベントに対し必要なビジネスロジックを実施していく。業務アプリケーションからのデータベース更新においても、イベント制御層は、レコード単位に制御し、デッドロックまたは更新順序不正は、発生しない仕組みとなる。また、システム全体をイベント制御と業務アプリケーションの疎結合による集合体として実現しており、レコード単位の単純なビジネスロジックを並列実行し、入力イベントの分散並列処理が可能である。ここで、レコード単位の制御は、同一キーを持つ処理を、順序通り実行するシーケンス制御である。この結果、業務アプリケーション開発者は、処理のイベント順番を意識した排他制御から開放される。さらに、業務アプリケーションのサーバで障害が発生してもイベント制御層でリトライ制御を実施することで、業務アプリケーション開発者はリトライ機能を実装しなくてもよい。イベント制御層は、一定数以上のイベントが発生した場合に待機する流量制御を提供する。この結果、業務アプリケーション開発者は、流量などの条件を意識せず業務アプリケーションを実装できる。