(57)【要約】【課題】通信事業者のＯＳＳ／ＢＳＳ基盤では、大量の処理（イベント）が集中するため、複数のサーバ群によるシステム構成となる。このようなサーバ群で同時にイベントを実行する場合に、サーバ群全体でのイベントの制御が必要になる。【解決手段】複数のイベント制御サーバ２００からなるイベント制御層と、複数の業務サーバ３００とからなる業務アプリケーション層と、からなるイベント処理システムにおいて、イベント制御サーバ２００は、イベント発生源インタフェースと、イベント制御部と、複数の業務サーバインタフェースとから構成され、イベント制御部は、受信したイベント内容に基づいて、業務サーバ３００へのアクセスの排他制御と流量制御とを考慮したシナリオを作成し、このシナリオに基づいて、業務サーバ３００にアクセスするようにイベント制御サーバ２００を制御する。【選択図】図１
2012155441.tif 000002
【特許請求の範囲】
【請求項１】
複数のイベント制御サーバからなるイベント制御層と、複数の業務サーバとからなる業務アプリケーション層と、からなるイベント処理システムにおいて、
前記イベント制御サーバは、イベント発生源インタフェースと、イベント制御部と、複数の業務サーバインタフェースとから構成され、
前記イベント制御部は、受信したイベント内容に基づいて、前記業務サーバへのアクセスの排他制御と流量制御とを考慮したシナリオを作成し、このシナリオに基づいて、前記業務サーバにアクセスするように前記イベント制御サーバを制御することを特徴とするイベント処理システム。
【請求項２】
請求項１に記載のイベント処理システムであって、
前記業務サーバから、エラー応答を受信したとき、前記イベント制御部は、リトライまたはリカバーを選択して前記エラー応答を送信した業務サーバまたは他の業務サーバにアクセスするように前記イベント制御サーバを制御することを特徴とするイベント処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベント処理システムに係り、特に通信事業者がサービスを提供するための顧客管理や料金請求、物流、代理店等のＯＳＳ／ＢＳＳ（Operations Support System/Business Support System）基盤において、処理要求イベントの制御ロジックと業務アプリケーションをシンプルかつ効率的に実現するイベント処理システムに関する。
【背景技術】
【０００２】
特許文献１は、受信手段と、要求手段と、転送手段とからなるイベント制御装置を開示している。受信手段は、クライアントを指定する指定情報を含むイベントの通知要求を受信する。要求手段は、受信した指定情報に基づいて、サーバの中から指定情報によって特定されるクライアントに対してサービスを提供している振り分け先のサーバの通知を負荷分散装置に要求する。転送手段は、要求手段による要求に応じて通知された振り分け先のサーバのみに、イベントの通知要求を転送する。
【０００３】
従来のイベント処理システムでは、イベント発生源のサーバまたは端末機からの処理要求イベントは、業務アプリケーションが実装されたサーバで受信し、業務アプリケーションが実装されたサーバでイベントの制御を行なうと共に業務処理を実行していた。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２９４７３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
通信事業者のＯＳＳ／ＢＳＳ基盤（イベント処理システム）では、大量の処理（イベント）が集中する。このため、イベント処理システムは、多数のサーバ群によるシステム構成となる。このようなサーバ群で同時にイベントを実行する場合、サーバ群全体でのイベントの制御が必要になってくる。このため、業務アプリケーションに制御ロジックの組み込みが必要になり、開発が複雑化している。そこで、メンテナンス性・運用性を担保し、業務アプリケーション開発の単純化を実現するアーキテクチャを検討する必要がある。
【課題を解決するための手段】
【０００６】
イベントの制御と業務アプリケーション開発を明確に分離したシステムアーキテクチャとし、業務処理実装の単純化・効率化する仕組みとする。各種入力チャネルからＯＳＳ／ＢＳＳ基盤に対する入力データを、業務アプリケーションが直接インタフェースせずに、入力チャネルと業務アプリケーションの間に、イベント制御層を設ける。ここで、各種入力チャネルとは、オンライン申込、外部システム等である。
【０００７】
イベント制御層では、業務アプリケーションと入力チャネルとの仲介連携を行ない、各イベントの制御を行なう。ここで、イベントとは、具体的には入力されたデータである。
【０００８】
イベントの各種インタフェースやステータス管理、シーケンス制御、流量制御、複数業務アプリケーションへのロードバランス、エラー制御等の非機能要件（非業務処理要件）は、全てイベント制御層で行なう。ここで、エラー制御とは、具体的にはリトライ、リカバリである。
【０００９】
上述した課題は、複数のイベント制御サーバからなるイベント制御層と、複数の業務サーバとからなる業務アプリケーション層と、からなるイベント処理システムにおいて、イベント制御サーバは、イベント発生源インタフェースと、イベント制御部と、複数の業務サーバインタフェースとから構成され、イベント制御部は、受信したイベント内容に基づいて、業務サーバへのアクセスの排他制御と流量制御とを考慮したシナリオを作成し、このシナリオに基づいて、業務サーバにアクセスするようにイベント制御サーバを制御するイベント処理システムにより、解決できる。
【発明の効果】
【００１０】
イベント制御層を設けたことにより、イベント制御と業務アプリケーションの役割を明確化し、業務アプリケーションでは制御ロジックを排除し、開発の単純化を実現できる。
【図面の簡単な説明】
【００１１】
【図１】イベント処理システムのブロック図である。
【図２】イベント制御サーバのブロック図である。
【図３】イベントデータベースおよびイベントデータデータベースのレコードである。
【図４】イベント処理システムの基本処理シーケンスを説明するシーケンス図である。
【図５】イベント制御テーブル（その１）を説明する図である。
【図６】イベント処理システムのシーケンス制御を説明するシーケンス図である。
【図７】イベント処理システムのエラー制御を説明するシーケンス図である。
【図８】イベント制御テーブル（その２）を説明する図である。
【図９】イベント処理システムのロードバランス／流量制御を説明するシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施の形態について、実施例を用い図面を参照しながら、詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。
【００１３】
図１を参照して、イベント処理システム５００を説明する。図１において、イベント処理システム５００は、通信回線１０９を介して入力チャネルと相互接続されたイベント制御層と、通信回線１１０を介して、イベント制御層と接続された業務アプリケーション（ＡＰ）層とで構成されている。
【００１４】
入力チャネルは、複数のイベント発生源１００で構成されている。イベント発生源１００からのデータは、具体的には、オンライン申込Ｗｅｂ、他システムからのデータである。イベント発生源１００は、それらデータの送信元であるサーバまたは端末機である。イベント制御層は、複数のイベント制御サーバ２００で構成されている。イベント制御サーバ２００は、入力イベントの制御ロジックが実装されたサーバである。業務アプリケーション層は、複数の業務ＡＰサーバ３００で構成されている。異なる業務ＡＰを実行する業務ＡＰサーバ３００は、業務ＡＰサーバ３００Ａ〜３００Ｄと区別する。同一の業務ＡＰを実行する業務ＡＰサーバ３００Ａは、業務ＡＰサーバ３００Ａ−１〜３００Ａ−２と区別する。業務ＡＰサーバ３００は、業務アプリケーションが実装されたサーバである。
【００１５】
図１において、各サーバ１００、２００、３００は、数台しか示されていないが、勿論、実際にはこれ以上のサーバ構成でも良い。本実施例のイベント処理システムでは、業務アプリケーションが直接イベント発生源からのデータを受信せず、イベント発生源と業務アプリケーションの間に、イベント制御サーバ（イベント制御層）を設ける。
【００１６】
図２を参照して、イベント制御層を構成するイベント制御サーバ２００の構成を説明する。図２において、イベント制御サーバ２００は、イベント発生源インタフェース２０１、イベント制御部２０２、４台の業務ＡＰインタフェース２０３から構成される。イベント制御サーバ２００は、イベントＤＢ２０７、イベントデータＤＢ２０８と接続されている。
【００１７】
イベント発生源インタフェース２０１は、イベント発生源からの処理要求イベントと結果通知を送受信する。イベント制御部２０２は、シーケンス制御、流量制御、複数業務アプリケーションへのロードバランス、エラー制御を実行する。業務ＡＰインタフェース２０３は、業務アプリケーションへの業務処理命令と処理結果を送受信する。業務ＡＰインタフェース２０３は、業務ＡＰを実行する業務ＡＰサーバ３００に対応して、業務ＡＰインタフェース２０３Ａ〜２０３と区別する。イベントＤＢ２０７は、受信した処理要求イベントの制御情報を格納する。イベントデータＤＢ２０８は、受信した処理要求イベントのデータを格納する。
【００１８】
図３を参照して、イベントデータベースおよびイベントデータデータベースのレコードを説明する。ここで、図３（ａ)は、イベントＤＢのレコードを説明する図である。また、図３（ｂ）は、イベントデータＤＭのレコードを説明する図である。
【００１９】
図３（ａ）において、イベントＤＢのレコード４００は、イベント種別４０１、イベントＩＤ４０２、イベントステータス４０３、シーケンスキー４０４、イベント受付時刻４０５から構成されている。一方、図３（ｂ）において、イベントデータＤＢのレコード４１０は、イベントＩＤ４１１、イベントデータ４１２から構成されている。
【００２０】
図３（ａ）において、イベント種別４０１は、必要な業務処理・シナリオを特定し、イベント制御機能が処理要求する業務アプリケーションを選択する。また、イベント種別４０１は、エラー時の制御も決定する。イベントＩＤ４０２、４１１は、イベントの実データ４１２を特定する。イベントステータス４０３は、イベントのステータス・結果を管理する。シーケンスキー４０４は、デッドロック・更新順序不正を発生させないために、同一キーを持つ処理を順序通りシーケンス制御させる。イベント受付時刻４０５は、文字通りイベント制御サーバ２００の受付時刻である。
【００２１】
図４を参照して、イベント制御層を適用したイベント処理システムのシーケンスを説明する。図４において、イベント発生源１００は、イベント発生源インタフェース２０１にイベント発生を通知する（Ｓ１０１）。イベント発生源インタフェース２０１は、イベントＤＢ２０７に受け付けたイベントの管理情報を記録する（Ｓ１０２）。イベント発生源インタフェース２０１は、イベントデータＤＢ２０８に受け付けたイベントの実データを記録する（Ｓ１０３）。ここで、イベント発生源インタフェース２０１は、管理情報と実データとを、イベントＩＤで紐付する。イベント発生源インタフェース２０１は、イベント発生源１００にイベント応答を送信する（Ｓ１０４）。
【００２２】
イベント制御部２０２は、イベント発生源インタフェース２０１が受け付けたイベントを受け付けた順にイベントＤＢ２０７から取り込み、イベントの実データをイベントデータＤＢ２０８から取り込む（Ｓ１０６）。イベント制御部２０２は、取り込んだイベントのイベント種別に基づいてシナリオを作成する（Ｓ１０７）。ここで、シナリオは、１つの業務アプリケーションだけを実行するシナリオと、複数の業務アプリケーションを実行する必要があるシナリオがある。複数ある場合は、実行順序が決められている。
【００２３】
イベント制御部２０２は、業務ＡＰインタフェース２０３Ａに処理要求を送信する（Ｓ１０８）。ここで、処理要求には、実データ（イベントデータＤＢ２０８の内容）が含まれている。業務ＡＰインタフェース２０３Ａは、業務ＡＰサーバ３００Ａとのインタフェース機能を有し、業務ＡＰサーバ３００Ａに処理要求を送信する（Ｓ１０９）。業務ＡＰサーバ３００Ａは、業務アプリケーションプログラムを実行し（図示省略：以下同様）、業務ＡＰインタフェース２０３Ａに処理結果を送信する（Ｓ１１１）。業務ＡＰインタフェース２０３Ａは、イベント制御部２０２に処理結果を送信する（Ｓ１１２）。イベント制御部２０２は、イベントＤＢ２０７のイベントのステータスを更新する（Ｓ１１３）。イベント制御部２０２は、シナリオを確認する（Ｓ１１４）。ここでは、２件目の業務アプリケーションの実行があるので、イベント制御部２０２は、業務ＡＰインタフェース２０３Ｃに処理要求を送信する（Ｓ１１６）。業務ＡＰインタフェース２０３Ｃは、業務ＡＰサーバ３００Ｃに処理要求を送信する（Ｓ１１７）。業務ＡＰサーバ３００Ｃは、業務ＡＰインタフェース２０３Ｃに処理結果を送信する（Ｓ１１８）。業務ＡＰインタフェース２０３Ｃは、イベント制御部２０２に処理結果を送信する（Ｓ１１９）。イベント制御部２０２は、イベントＤＢ２０７のステータスを更新する（Ｓ１２１）。
【００２４】
イベント発生源１００は、イベント発生源インタフェース２０１に結果照会を送信する（Ｓ１２３）。イベント発生源インタフェース２０１は、イベントＤＢ２０７からイベントの処理結果を取得する（Ｓ１２４）。イベント発生源インタフェース２０１は、イベント発生源１００に結果通知を送信する（Ｓ１２６）。
【００２５】
図５を参照して、図６のイベント取り込み時点でのイベントＤＢ２０７の状態を説明する。図５において、イベントＤＢ２０７ＡのイベントＩＤ「００１」、「００２」のシーケンスキー４０４は共に「５０」である。同じ、シーケンスキーを持つレコードは、シーケンス制御が必要であることを表す。したがって、イベントＩＤの大きい「００２」は、イベントステータス４０３が「実行待ち」となっている。これに対して、イベントＩＤの小さい「００２」と、シーケンスキーが異なるイベントＩＤ「００３」は、イベントステータス４０３が「実行」となっている。
【００２６】
図６を参照して、イベント処理システムのシーケンス制御を説明する。なお、図６のシーケンスは、基本的に図４と同じなので、要点のみ説明する。図６のステップ１３６において、図５のイベントＤＢ２０７Ａのシーケンスキーが同じイベントＩＤ「００１」「００２」について、イベント制御部２０２は、先に受け付けたイベントＩＤ「００１」のみ取り込む。
【００２７】
ステップ１５２において、イベント制御部２０２は、イベントＤＢ２０７を更新して、イベントＩＤ「００１」のイベントステータス４０３を「終了」、イベントＩＤ「００２」のイベントステータス４０３を「実行」とする。そして、イベント制御部２０２は、イベントＩＤ「００２」を取り込む。
【００２８】
これらの処理により、イベント制御部２０２は、同一イベントキーの処理を同時実行させない。また、業務ＡＰサーバ３００がデータベース（図示せず）の更新が必要な場合、イベント制御層でレコード単位にシーケンス制御されており、デッドロックおよび更新順序不正は発生しない。すなわち、業務ＡＰサーバは３００、処理順序を意識せずに実行可能である。
【００２９】
図７を参照して、イベント処理システムのエラー制御を説明する。図７のステップ１６１からステップ１７７までとステップ１８８からステップ１９１は、図４のステップ１０１からステップ１１７までとステップ１２３からステップ１２６までと同一なので説明を省略する。
【００３０】
ステップ１７８において、業務ＡＰサーバ３００Ｃは、処理結果ＮＧの処理結果を業務ＡＰインタフェース２０３Ｃに送信する。業務ＡＰインタフェース２０３Ｃは、イベント制御部２０２に処理結果ＮＧの処理結果を送信する（Ｓ１７９）。イベント制御部２０２は、エラー制御を実行する（Ｓ１８１）。イベント制御部２０２は、業務ＡＰインタフェース２０３Ｃにリトライ処理要求を送信する（Ｓ１８２）。業務ＡＰインタフェース２０３Ｃは、業務ＡＰサーバ３００Ｃにリトライ処理要求を送信する（Ｓ１８３）。業務ＡＰサーバ３００Ｃは、業務ＡＰインタフェース２０３Ｃに処理結果ＯＫの処理結果を送信する（Ｓ１８４）。業務ＡＰインタフェース２０３Ｃは、イベント制御部２０２に処理結果ＯＫの処理結果を送信する（Ｓ１８６）。イベント制御部２０２は、イベントＤＢ２０７のステータスを更新する（Ｓ１８７）。
【００３１】
なお、ここではエラー制御としてリトライを説明したが、業務ＡＰサーバ３００Ｃ−１が、処理結果ＮＧの処理結果を業務ＡＰインタフェース２０３Ｃに送信したとき、業務ＡＰサーバ３００Ｃ−２にリカバー処理要求を送信するのが、リカバーである。
【００３２】
図８を参照して、図９のイベント取り込み時点でのイベントＤＢ２０７の状態を説明する。図８において、イベントＤＢ２０７Ｂは、イベントＩＤ「００１」〜「００３」のシーケンスキーは、互いに異なる。したがって、連続的に読み込み可能である。このため、イベントステータスは、いずれも「実行」である。
【００３３】
また、イベントＩＤ「００１」〜「００３」のイベント種別は、いずれも「Ａ」である。したがって、イベント「Ａ」の輻輳を防止するために、イベント処理システムは、分散並列処理を実行する。
【００３４】
図９を参照して、イベント処理システムの分散並列処理を説明する。なお、図９のステップ２０１〜ステップ２０４、ステップ２２９〜ステップ２３２は、図４のステップ１０１〜ステップ１０４、ステップ１２３〜ステップ１２６と同一なので、説明を省略する。また、業務アプリケーション層は、３台の業務ＡＰサーバ３００Ａから構成されている点が、これまでのシーケンス図と異なる。
【００３５】
図９において、イベント制御部２０２は、図８のイベントＤＢ２０７ＢのイベントＩＤ「００１」「００２」「００３」を順次取り込む（Ｓ２０６）。イベント制御部２０２は、シナリオ制御して、分散並列処理を決定する（Ｓ２０７）。イベント制御部２０２は、業務ＡＰインタフェース２０３Ａに処理要求を送信する（Ｓ２０８）。この処理要求には、業務ＡＰサーバ３００Ａ−１の情報が含まれている。業務ＡＰインタフェース２０３Ａは、業務ＡＰサーバ３００Ａ−１に処理要求を送信する（Ｓ２０９）。イベント制御部２０２は、シナリオを参照する（Ｓ２１１）。イベント制御部２０２は、業務ＡＰインタフェース２０３Ａに処理要求を送信する（Ｓ２１２）。この処理要求には、業務ＡＰサーバ３００Ａ−２の情報が含まれている。業務ＡＰインタフェース２０３Ａは、業務ＡＰサーバ３００Ａ−２に処理要求を送信する（Ｓ２１３）。イベント制御部２０２は、シナリオを参照する（Ｓ２１４）。イベント制御部２０２は、業務ＡＰインタフェース２０３Ａに処理要求を送信する（Ｓ２１６）。この処理要求には、業務ＡＰサーバ３００Ａ−３の情報が含まれている。業務ＡＰインタフェース２０３Ａは、業務ＡＰサーバ３００Ａ−３に処理要求を送信する（Ｓ２１７）。
【００３６】
業務ＡＰサーバ３００Ａ−１は、業務ＡＰインタフェース２０３Ａに処理結果を送信する（Ｓ２１８）。業務ＡＰインタフェース２０３Ａは、イベント制御部２０２に処理結果を送信する（Ｓ２１９）。イベント制御部２０２は、イベントＤＢ２０７のステータスを更新する（Ｓ２２１）。業務ＡＰサーバ３００Ａ−２は、業務ＡＰインタフェース２０３Ａに処理結果を送信する（Ｓ２２２）。業務ＡＰインタフェース２０３Ａは、イベント制御部２０２に処理結果を送信する（Ｓ２２３）。イベント制御部２０２は、イベントＤＢ２０７のステータスを更新する（Ｓ２２４）。業務ＡＰサーバ３００Ａ−３は、業務ＡＰインタフェース２０３Ａに処理結果を送信する（Ｓ２２６）。業務ＡＰインタフェース２０３Ａは、イベント制御部２０２に処理結果を送信する（Ｓ２２７）。イベント制御部２０２は、イベントＤＢ２０７のステータスを更新する（Ｓ２２８）。
【００３７】
本実施例によれば、イベント制御層を設けたことにより、イベント制御と業務アプリケーションの役割を明確化し、業務アプリケーションでは制御ロジックを排除し、開発の単純化を実現できる。
【００３８】
よって、各業務アプリケーションは、入力されてきたイベントに対し必要なビジネスロジックを実施していく。業務アプリケーションからのデータベース更新においても、イベント制御層は、レコード単位に制御し、デッドロックまたは更新順序不正は、発生しない仕組みとなる。また、システム全体をイベント制御と業務アプリケーションの疎結合による集合体として実現しており、レコード単位の単純なビジネスロジックを並列実行し、入力イベントの分散並列処理が可能である。ここで、レコード単位の制御は、同一キーを持つ処理を、順序通り実行するシーケンス制御である。この結果、業務アプリケーション開発者は、処理のイベント順番を意識した排他制御から開放される。
【００３９】
さらに、業務アプリケーションのサーバで障害が発生してもイベント制御層でリトライ制御を実施することで、業務アプリケーション開発者はリトライ機能を実装しなくてもよい。イベント制御層は、一定数以上のイベントが発生した場合に待機する流量制御を提供する。この結果、業務アプリケーション開発者は、流量などの条件を意識せず業務アプリケーションを実装できる。
【符号の説明】
【００４０】
１００…イベント発生源（サーバまたは端末機）、１０９…通信回線、１１０…通信回線、２００…イベント制御サーバ、２０１…イベント発生源インタフェース、２０２…イベント制御部、２０３…業務アプリケーションインタフェース、２０７…イベントデータベース、２０８…イベントデータＤＢ、３００…業務アプリケーションサーバ、５００…イベント処理システム。
【図１】
2012155441.tif 000003
【図２】
2012155441.tif 000004
【図３】
2012155441.tif 000005
【図４】
2012155441.tif 000006
【図５】
2012155441.tif 000007
【図６】
2012155441.tif 000008
【図７】
2012155441.tif 000009
【図８】
2012155441.tif 000010
【図９】
2012155441.tif 000011