(57)【要約】【課題】  大量な電文処理が必要となるリアルタイム処理において、一括処理によるスケジューリングコストの削減と、テーブルドリブンによる動的スケジューリングを可能とする。【解決手段】  大量の入力電文を電文固有の処理順序に従い複数の業務ＡＰで処理を行うシステムにおいて、電文入力を契機として複数の電文を規則に従い取りまとめて該当業務ＡＰにて一括処理を行い、業務処理順序をテーブルで管理することで次に処理を行う業務ＡＰの特定（テーブルドリブン）を行う。【選択図】          図１
2006350474.tif 000002
【特許請求の範囲】
【請求項１】
電文を業務単位に振り分け、前記振り分けられた電文をまとめて電文集合とし、前記電文集合を該当する業務毎に一括して処理する処理装置と、
前記処理装置に前記電文を送信する電文送信装置と、
前記処理装置から前記電文集合を受信する電文受信装置と
を備え、
前記処理装置は、前記電文の処理順序に従い、該当する業務での処理が完了した電文について次に処理を行う業務が残っている場合、前記処理が完了した電文をまとめて新たな電文集合とし、前記新たな電文集合を前記次に処理を行う業務にて一括して処理し、前記電文に必要な全ての業務で処理が完了した場合、前記電文を前記電文受信装置に送信する
リアルタイム処理システム。
【請求項２】
請求項１に記載のリアルタイム処理システムにおいて、
前記処理装置は、前記電文を一定数蓄積した時点でとりまとめを終了する
リアルタイム処理システム。
【請求項３】
請求項１又は２に記載のリアルタイム処理システムにおいて、
前記処理装置は、前記電文のとりまとめを開始してから一定時間が経過した時点でとりまとめを終了する
リアルタイム処理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載のリアルタイム処理システムにおいて、
前記処理装置は、
前記電文が最後に処理を行った業務に基づいて、次に処理を行う業務を解決するための情報を保持する宛先管理テーブルを備える
リアルタイム処理システム。
【請求項５】
請求項４に記載のリアルタイム処理システムにおいて、
前記電文は、
入力データを格納する格納部と、
前記次に処理を行う業務を記録するための制御部と
を有し、
前記処理装置は、前記次に処理を行う業務を前記宛先管理テーブルより特定し、前記電文の前記制御部に格納する
リアルタイム処理システム。
【請求項６】
請求項１乃至５のいずれか一項に記載のリアルタイム処理システムにおいて、
前記処理装置は、前記処理順序を動的に変更する
リアルタイム処理システム。
【請求項７】
電文に対して、処理すべき業務の順序を管理し、前記電文の処理順序検索依頼を受けて前記電文が処理すべき業務の情報を返し、外部からの処理順序変更依頼をもとに該当する前記電文の処理順序を変更する宛先管理部と、
前記宛先管理部に対し前記電文の処理順序検索依頼を行い、前記処理順序検索の検索結果の処理すべき業務の情報をもとに業務単位に前記電文を振り分ける宛先決定部と、
業務単位に振り分けられた前記電文を取りまとめ、宛先業務毎に貯められた前記電文数又は取りまとめ開始からの経過時間を監視して一括処理単位となる電文集合を作成する電文集合管理部と、
前記電文集合管理部で作成された前記電文集合を該当業務毎に一括処理を行う一括実行部と
を具備する
処理装置。
【請求項８】
請求項７に記載の処理装置において、
電文送信装置から送信される前記電文を受信する電文受信部と、
前記一括処理を行った後、全ての業務処理が完了した処理済電文の集合を一括して次の宛先となる電文受信装置に送信する電文送信部と
を更に具備する
処理装置。
【請求項９】
請求項８に記載の処理装置において、
前記宛先管理部は、前記電文毎に該当する電文が最後に処理を行った業務に関する情報をもとに、次に処理を行う業務を解決するための情報を保持する宛先管理テーブルを含む
処理装置。
【請求項１０】
請求項９に記載の処理装置において、
前記宛先決定部は、前記電文が前記次に処理を行う業務を前記宛先管理テーブルより特定し、前記電文の制御部に宛先業務名を格納し、前記特定した業務の情報をもとに宛先業務単位に振り分けて電文集合バッファに格納する
処理装置。
【請求項１１】
請求項１０に記載の処理装置において、
前記電文集合管理部は、前記電文集合バッファ毎に電文数や電文集合の作成開始からの経過時間を監視し、一括処理の単位となる電文集合を作成する
処理装置。
【請求項１２】
請求項１１に記載の処理装置において、
前記電文集合管理部は、電文数や経過時間が規定値を超えた場合は、それまでに格納されている電文を電文集合として処理先となる業務に一括処理依頼を行い、全ての業務処理を終えた場合は、処理済電文の一括送信依頼を行う
処理装置。
【請求項１３】
請求項１２に記載の処理装置において、
各業務は、処理した電文を再び前記宛先決定部宛に送付する
処理装置。
【請求項１４】
請求項１３に記載の処理装置において、
前記電文送信部は、前記電文集合管理部からの一括送信依頼を受けて、前記電文受信装置である電文受信用のクライアントに対して前記電文集合の送付を行う
処理装置。
【請求項１５】
（ａ）クライアントから電文を受信するステップと、
（ｂ）前記電文の受信を契機に、前記電文の宛先となる業務の特定依頼を行うステップと、
（ｃ）前記業務の特定依頼を受けて、宛先管理テーブルを参照することで前記電文の宛先を特定し、前記業務毎振り分けて電文集合バッファに格納するステップと、
（ｄ）前記業務毎に規定条件を満たすまでの間、前記電文を取りまとめて電文集合を作成するステップと、
（ｅ）前記電文集合の作成が完了した場合、前記業務での一括処理依頼を行うステップと
を具備する
リアルタイム処理方式。
【請求項１６】
請求項１５に記載のリアルタイム処理方式において、
前記（ｄ）ステップは、
（ｄ１）前記規定条件として、電文数が一定数になるまで取りまとめを行うステップを具備する
リアルタイム処理方式。
【請求項１７】
請求項１６に記載のリアルタイム処理方式において、
前記（ｄ）ステップは、
（ｄ２）作成中である前記電文集合の最初の電文が到着してからの経過時間を監視し、前記電文数が一定数以下の場合でも規定時間が経過した時点でとりまとめを終えるステップを更に具備する
リアルタイム処理方式。
【請求項１８】
請求項１５乃至１７のいずれか一項に記載のリアルタイム処理方式において、
（ｆ）前記一括処理依頼を受けた後、前記電文集合の一括処理を行うステップを更に具備する
リアルタイム処理方式。
【請求項１９】
請求項１８に記載のリアルタイム処理方式において、
（ｇ）前記業務での処理が完了した電文に対し、次に処理する業務の特定を行うステップを更に具備する
リアルタイム処理方式。
【請求項２０】
請求項１９に記載のリアルタイム処理方式において、
前記（ｇ）ステップは、
（ｇ１）前記次に処理する業務を前記宛先管理テーブルより特定するステップを具備する
リアルタイム処理方式。
【請求項２１】
請求項１９又は２０に記載のリアルタイム処理方式において、
（ｈ）前記次に処理する業務が残っている場合、再び処理先業務単位に振り分け、前記電文集合バッファに格納するステップを更に具備する
リアルタイム処理方式。
【請求項２２】
請求項２１に記載のリアルタイム処理方式において、
処理すべき全ての業務での処理が完了するまでの間、前記（ａ）ステップから前記（ｈ）ステップまでの処理を繰り返す
リアルタイム処理方式。
【請求項２３】
請求項２２に記載のリアルタイム処理方式において、
（ｉ）次の宛先となる業務がない場合、前記電文を、処理済電文用の電文集合バッファに格納し、前記電文数や経過時間が規定値となった場合は一括して送信依頼を行うステップを具備する
リアルタイム処理方式。
【請求項２４】
請求項２３に記載のリアルタイム処理方式において、
（ｊ）前記送信依頼を受けた場合、前記電文を前記クライアントに対して送信するステップを具備する
リアルタイム処理方式。
【請求項２５】
請求項１５乃至２４のいずれか一項に記載のリアルタイム処理方式において、
（ｋ）前記宛先管理テーブルの内容を変更することで動的に業務順序の変更を行うステップを更に具備する
リアルタイム処理方式。
【請求項２６】
請求項１５乃至２５のいずれか一項に記載のリアルタイム処理方式を、コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大量データを即時処理するためのリアルタイム処理システム、処理装置、リアルタイム処理方式、及びプログラムに関する。
【背景技術】
【０００２】
従来のスケジュール方式には、ＯＬＴＰ（Ｏｎ−Ｌｉｎｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ）方式とバッチ方式があった。
【０００３】
ＯＬＴＰ方式は、電文受信を契機にイベントドリブンで処理を行うためリアルタイム処理に向いた方式ではあるが、通常は電文１件を処理単位としているため電文あたりのオーバヘッドが大きくなるといるデメリットがあった。特に１電文を処理する間に複数の電文が到着し、処理待ち電文が貯まってしまうような、大量の電文を処理する必要のあるシステムにおいては、本方式の適用は困難であった。
【０００４】
一方、バッチ方式は、数時間程度の規定時間（短くとも１時間程度）の間隔でそれまでに処理要求のあった電文を一括処理する。このため、電文あたりのスケジュールにかかるオーバヘッドは小さくなるものの、電文到着から処理開始までの時間が長いためリアルタイム処理には向かない方式であった。
【０００５】
関連する技術として、特開２００４−１０２４３６号公報にアプリケーションプログラム処理装置、アプリケーションプログラム実行方法、及びアプリケーションプログラム生成方法、並びにコンピュータ・プログラムが開示されている。
この従来技術では、予め定められた処理シーケンスに従った処理を実行するアプリケーションプログラム処理装置が、以下の構成を有することを特徴とする。
（１）所定単位の処理プログラムを保持したプログラム部品を格納したプログラム部品格納部。
（２）トランザクションデータ項目と、該トランザクションデータを適用した処理を実行するプログラム部品の識別子（ＩＤ）とを対応付けたプロセス定義テーブル。
（３）前記プロセス定義テーブルに設定されたプログラム部品識別子（ＩＤ）に対応するプログラム部品を前記プログラム部品格納部から取得し、取得したプログラム部品を適用した処理を実行する制御部。
【０００６】
特開昭６３−０９４３６０号公報にトランザクション処理方式が開示されている。
このトランザクション処理方式は、トランザクションがアプリケーションプログラムの起動要因となっているデータコミュニケーションマネジメントシステムにおいて、以下の手段を備えている。
（１）前記トランザクションが一括処理を行うかどうか判定する手段。
（２）一括処理を行う前記トランザクションを取得し、１つのキューに蓄える手段。
（３）１回の同期点処理要求で複数トランザクションの同期点を一括取得する手段。
（４）前記複数トランザクションの送信メッセージを一括して出力する手段。
また、このトランザクション処理方式は、前記アプリケーションプログラムに処理を要求する前記トランザクションが発生した時、前記トランザクションが一括処理を行うＴ欄ザ区ションであるかどうか判定する。一括処理を行うトランザクションであれば前記キューに蓄える。前記キューに蓄えられた前記複数トランザクションは１度の前記アプリケーションプログラム起動で処理される。前記アプリケーションプログラムの処理終了時に１度同期点取得要求を出すことにより前記一括同期点取得が前記複数トランザクション同期点を取得し、前記複数トランザクションの前記送信メッセージを一括して出力する。
【０００７】
特開平０３−１０５５４４号公報にトランザクション受信処理方式及びオンライントランザクション処理方式が開示されている。
この従来技術では、端末装置から逐次送信されるトランザクションを受信して、該トランザクションを処理するオンライントランザクション処理システムが、以下の手段を備えたことを特徴とする。
（１）受信したトランザクションをスタックするスタック手段。
（２）予め定めた条件が満たされたか否かを判定する条件判定手段。
（３）前記条件が満たされたと判定された時、スタックされているトランザクションを一括して処理するトランザクション処理手段。
【０００８】
【特許文献１】特開２００４−１０２４３６号公報
【特許文献２】特開昭６３−０９４３６０号公報
【特許文献３】特開平０３−１０５５４４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
特開昭６３−０９４３６０号公報、又は特開平０３−１０５５４４号公報に開示されている既存の技術は、処理装置内に閉じた一括処理のみ想定されているため、１電文が複数の処理装置間を行き来するようなシステムへの適用が考慮されていない。
また、特開２００４−１０２４３６号公報に開示されている既存の技術は、プロセス定義テーブルに従い処理順序を解決することにより、部品追加（削除）等に伴う処理シーケンスの変更のみ考慮している。
本発明の目的は、一括処理によるスケジューリングコストの削減と、テーブルドリブンによる動的スケジューリングを可能とするリアルタイム処理システム、処理装置、リアルタイム処理方式、及びプログラムを提供することである。
【課題を解決するための手段】
【００１０】
以下に、［発明を実施するための最良の形態］で使用される番号を括弧付きで用いて、課題を解決するための手段を説明する。これらの番号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために付加されたものである。但し、それらの番号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。
【００１１】
本発明のリアルタイム処理システムは、電文を業務単位に振り分け、前記振り分けられた電文をまとめて電文集合とし、前記電文集合を該当する業務毎に一括して処理する処理装置（１００）と、前記処理装置（１００）に前記電文を送信する電文送信装置（２００）と、前記処理装置（１００）から前記電文集合を受信する電文受信装置（３００）とを備える。
前記処理装置（１００）は、前記電文毎の処理順序に従い、該当する業務での処理が完了した電文について次に処理を行う業務が残っている場合、前記処理が完了した電文をまとめて新たな電文集合とし、前記次に処理を行う業務にて一括して処理し、前記電文に必要な全ての業務で処理が完了した場合、前記電文を前記電文受信装置（３００）に送信する。
【００１２】
前記処理装置（１００）は、前記電文を一定数蓄積した時点でとりまとめを終了する。
【００１３】
前記処理装置（１００）は、前記電文のとりまとめを開始してから一定時間が経過した時点でとりまとめを終了する。
【００１４】
前記処理装置（１００）は、前記電文が最後に処理を行った業務に基づいて、次に処理を行う業務を解決するための情報を保持する宛先管理テーブル（１０７）を備える。
【００１５】
前記電文は、入力データを格納する格納部と、前記次に処理を行う業務を記録するための制御部とを有し、前記処理装置（１００）は、前記次に処理を行う業務を前記宛先管理テーブル（１０７）より特定し、前記電文の前記制御部に格納する。
【００１６】
前記処理装置（１００）は、前記処理順序を動的に変更する。
【００１７】
本発明の処理装置（１００）は、電文に対して、処理すべき業務の順序を管理し、前記電文の処理順序検索依頼を受けて前記電文が処理すべき業務の情報を返し、外部からの処理順序変更依頼をもとに該当する前記電文の処理順序を変更する宛先管理部（１０２）と、前記宛先管理部（１０２）に対し前記電文の処理順序検索依頼を行い、前記処理順序検索の検索結果の処理すべき業務の情報をもとに業務単位に前記電文を振り分ける宛先決定部（１０３）と、業務単位に振り分けられた前記電文を取りまとめ、宛先業務毎に貯められた前記電文数又は取りまとめ開始からの経過時間を監視して一括処理単位となる電文集合を作成する電文集合管理部（１０４）と、前記電文集合管理部（１０４）で作成された前記電文集合を該当業務毎に一括処理を行う一括実行部（１０５）と
を具備する。
【００１８】
本発明の処理装置（１００）は、電文送信装置（２００）から送信される前記電文を受信する電文受信部（１０１）と、
前記一括処理を行った後、全ての業務処理が完了した処理済電文の集合を一括して次の宛先となる電文受信装置（３００）に送信する電文送信部（１０６）と
を更に具備する。
【００１９】
前記宛先管理部（１０２）は、前記電文毎に該当する電文が最後に処理を行った業務に関する情報をもとに、次に処理を行う業務を解決するための情報を保持する宛先管理テーブル（１０７）を含む。
【００２０】
前記宛先決定部（１０３）は、前記電文が前記次に処理を行う業務を前記宛先管理テーブル（１０７）より特定し、前記電文の制御部に宛先業務名を格納し、前記特定した業務の情報をもとに宛先業務単位に振り分けて電文集合バッファに格納する。
【００２１】
前記電文集合管理部（１０４）は、前記電文集合バッファ毎に電文数や電文集合の作成開始からの経過時間を監視し、一括処理の単位となる電文集合を作成する。
【００２２】
前記電文集合管理部（１０４）は、電文数や経過時間が規定値を超えた場合は、それまでに格納されている電文を電文集合として処理先となる業務に一括処理依頼を行い、全ての業務処理を終えた場合は、処理済電文の一括送信依頼を行う。
【００２３】
各業務は、処理した電文を再び前記宛先決定部（１０３）宛に送付する。
【００２４】
前記電文送信部（１０６）は、前記電文集合管理部（１０４）からの一括送信依頼を受けて、前記電文受信装置（３００）である電文受信用のクライアントに対して前記電文集合の送付を行う。
【００２５】
本発明のリアルタイム処理方式は、（ａ）クライアントから電文を受信するステップと、（ｂ）前記電文の受信を契機に、前記電文の宛先となる業務の特定依頼を行うステップと、（ｃ）前記業務の特定依頼を受けて、宛先管理テーブル（１０７）を参照することで前記電文の宛先を特定し、前記業務毎振り分けて電文集合バッファに格納するステップと、（ｄ）前記業務毎に規定条件を満たすまでの間、前記電文を取りまとめて電文集合を作成するステップと、（ｅ）前記電文集合の作成が完了した場合、前記業務での一括処理依頼を行うステップとを具備する。
【００２６】
前記（ｄ）ステップは、（ｄ１）前記規定条件として、電文数が一定数になるまで取りまとめを行うステップを具備する。
【００２７】
前記（ｄ）ステップは、（ｄ２）作成中である前記電文集合の最初の電文が到着してからの経過時間を監視し、前記電文数が一定数以下の場合でも規定時間が経過した時点でとりまとめを終えるステップを更に具備する。
【００２８】
本発明のリアルタイム処理方式は、（ｆ）前記一括処理依頼を受けた後、前記電文集合の一括処理を行うステップを更に具備する。
【００２９】
本発明のリアルタイム処理方式は、（ｇ）前記業務での処理が完了した電文に対し、次に処理する業務の特定を行うステップを更に具備する。
【００３０】
本発明のリアルタイム処理方式は、前記（ｇ）ステップは、（ｇ１）前記次に処理する業務を前記宛先管理テーブル（１０７）より特定するステップを具備する。
【００３１】
本発明のリアルタイム処理方式は、（ｈ）前記次に処理する業務が残っている場合、再び処理先業務単位に振り分け、前記電文集合バッファに格納するステップを更に具備する。
【００３２】
本発明のリアルタイム処理方式は、処理すべき全ての業務での処理が完了するまでの間、前記（ａ）ステップから前記（ｈ）ステップまでの処理を繰り返す。
【００３３】
本発明のリアルタイム処理方式は、（ｉ）次の宛先となる業務がない場合、前記電文を、処理済電文用の電文集合バッファに格納し、前記電文数や経過時間が規定値となった場合は一括して送信依頼を行うステップを具備する。
【００３４】
本発明のリアルタイム処理方式は、（ｊ）前記送信依頼を受けた場合、前記電文を前記クライアントに対して送信するステップを具備する。
【００３５】
本発明のリアルタイム処理方式は、（ｋ）前記宛先管理テーブル（１０７）の内容を変更することで動的に業務順序の変更を行うステップを更に具備する。
【００３６】
本発明のプログラムは、上記のいずれかのリアルタイム処理方式を、コンピュータに実行させる。
【発明の効果】
【００３７】
第１の効果は、同一業務ＡＰ（アプリケーション）宛の電文を複数個取りまとめて電文集合とし、宛先業務ＡＰで一括処して処理を行うため、一般的なＯＬＴＰ方式のような電文１件単位で処理を行う方式と比較して、電文あたりのスケジューリングコストが少なくなるという点である。
第２の効果は、電文を取りまとめて電文集合を生成する際の規則として、電文数のほかに電文集合作成時間などを設定するため、一般的なバッチ処理方式のような処理開始間隔が長い方式と異なり、電文処理時間（電文到着から処理完了までの時間）の要件を満たす範囲内での即時処理が可能となる点である。
第３の効果は、業務変更などにより業務ＡＰの処理順序が変更となった場合に、宛先テーブルを更新することで対応が可能となる点である。既存のバッチ処理方式の場合、業務変更などにより業務の処理順序が変更となった場合は、そのつどスケジュールの再定義等の変更が必要になるのに対し、本方式ではテーブルを変更するだけで容易に動的スケジュールが可能となる。
【発明を実施するための最良の形態】
【００３８】
以下に本発明の第１実施形態について添付図面を参照して説明する。
図１を参照すると、本発明のリアルタイム処理システムは、処理装置１００、電文送信装置２００、電文受信装置３００を有している。
処理装置１００は、電文受信部１０１、宛先管理部１０２、宛先決定部１０３、電文集合管理部１０４、一括実行部１０５、電文送信部１０６を備える。
電文送信装置２００は、処理装置１００宛に電文を送信する。
電文受信装置３００は、処理装置１００から電文を受信する。
【００３９】
なお、電文は、処理装置１００への入力データである。但し、本発明のリアルタイム処理システムでは、１つの電文に対して複数の処理装置にて処理が行われることを想定している。このため、例えば、処理装置Ａで処理された電文が処理装置Ｂでも処理されるように決められていた場合、本電文は、処理装置Ａの入力データであり、処理装置Ａの出力データでもある。
【００４０】
電文受信部１０１は、電文送信装置２００から送信される電文を受信する機能を有する。
【００４１】
宛先管理部１０２は、各電文について、処理すべき業務の順序を管理する機能と、電文の処理順序検索依頼を受けて該当電文が処理すべき業務の情報を返す機能と、外部からの処理順序変更依頼をもとに該当電文の処理順序を変更する機能を有する。
宛先管理部１０２の例として、データベースが挙げられる。また、他にも、処理装置上のメモリを用いる場合が考えられる。
【００４２】
宛先決定部１０３は、宛先管理部１０２に対し電文の処理順序検索依頼を行う機能と、検索結果の処理すべき業務の情報をもとに業務単位に電文を振り分ける機能を有する。
【００４３】
電文集合管理部１０４は、業務単位に振り分けられた電文を取りまとめる機能と、宛先業務毎に貯められた電文数や取りまとめ開始からの経過時間などを監視して一括処理単位となる電文集合を作成する機能を有する。
【００４４】
一括実行部１０５は、電文集合管理部１０４で作成された電文集合を該当業務毎に一括処理を行う機能を有する。
【００４５】
電文送信部１０６は、全ての業務処理が完了した処理済電文の集合を一括して次の宛先となる電文受信装置３００に送信する機能を有する。
【００４６】
以上の構成により、処理装置１００は、一括処理と即時処理、動的スケジュールを実現する。
【００４７】
以下に本発明の処理の概要について説明する。
電文は、電文送信装置２００から処理装置１００の電文受信部１０１宛に送付される。電文受信部１０１は、電文受信を契機に受信電文の処理業務特定依頼を宛先決定部１０３に対して行う。
【００４８】
処理業務の特定は、宛先決定部１０３が宛先管理部１０２を参照することで実現する。宛先業務の特定後は、対象業務毎に振り分けて電文集合管理部１０４宛に電文を送付する。振り分けられた電文は、電文集合管理部１０４にて業務毎にまとめられる。
【００４９】
電文集合管理部１０４は、個々の業務単位に、貯められた電文数や、最初の電文到着からの経過時間、到着電文の優先度などを監視し、これらが規定値となった場合や高優先度の電文が到着した場合などにそれまでまとめられた電文を電文集合として一括処理要求を行う。
【００５０】
一括実行部１０５は、一括実行要求のあった電文集合を該当する業務にて一括処理を行う。
【００５１】
業務処理を完了した電文は、次に処理すべき業務の特定を行うために宛先決定部１０３宛に再送される。宛先決定部１０３では、先と同様に宛先管理部１０２を参照し、次の処理業務の特定と業務毎の振分を行う。以降は以上の処理を業務が完了するまで繰り返す。
【００５２】
なお、宛先を決定する際に、電文によっては、全ての業務処理が完了しているケースもあるが、このような電文についても「処理済電文」として振分の対象とする。処理済電文として振り分けられた電文に関しても、電文集合管理部１０４で電文集合を生成するが、生成後は電文送信要求を電文送信部１０６に対して行う。
【００５３】
電文送信部１０６は、該当する電文集合を一括して電文受信装置３００宛に送信する。
【００５４】
本発明では、複数の入力電文をまとめて処理単位（電文集合）とし各業務で処理することで、電文１件当たりの処理スケジューリングにかかるオーバヘッドを削減することが可能となる。このため、ＯＬＴＰ方式のような電文を１件ずつ処理する方式と比べ１電文あたりのスケジューリングコストが小さくなるというメリットがある。なお、本機能は、処理済電文の一括送信にも使用することで、電文受信装置３００といった外部装置への電文転送にかかるオーバヘッドの削減も可能となる。
【００５５】
また、一括処理単位となる電文集合を作成する際に、電文数や、取りまとめ開始からの経過時間などを監視し、電文毎の処理時間要件に合わせて電文集合の作成規則を決定することができる。このため、一般的なバッチ処理のような一定時間（少なくとも１時間程度）で処理を行う方式とは異なり、処理時間要件に合わせた即時処理が可能となる。
【００５６】
また、本発明では電文の処理順序を宛先テーブルで管理し、業務ＡＰ（アプリケーション）への振分前毎に処理順序の特定を行うため、業務の処理順序変更が必要となった場合は、該当テーブルの宛先業務の内容を更新することで対応可能となる。このため、バッチ処理方式のようにスケジュールが固定された方式と比べ、動的にスケジュールを変更できるというメリットがある。
【００５７】
本発明の実施例について以下に詳述する。
図２を参照すると、本実施例は処理装置１００とクライアント１０〜１３を用いる。処理装置１００とクライアント１０〜１３はネットワーク５００により接続されている。クライアント１０〜１２は電文の送信を行い、クライアント１３は処理済電文の受信を行う。
なお、クライアント１０〜１３は、処理装置１００に電文を送信する時は図１の電文送信装置２００に該当し、処理装置１００から電文を受信する時は図１の電文受信装置３００に該当する。
【００５８】
クライアント１０、１１、１２はネットワーク５００を介して電文を処理装置１００へ送信する機能を備えている。またクライアント１３は処理済電文を、同ネットワークを介して受信する機能を備えている。
【００５９】
処理装置１００は、電文受信部１０１、宛先決定部１０３、電文集合管理部１０４、一括実行部１０５、電文送信部１０６、宛先管理テーブル１０７、受信電文記憶部１０８を備える処理管理機構１１０と業務処理を行う業務ＡＰ１〜３により構成されている。
なお、宛先管理テーブル１０７は、図１に示す宛先管理部１０２に含まれる。この場合、性能を考慮し、処理装置上のメモリに宛先管理テーブル１０７を格納して管理するようにしても良い。また、受信電文記憶部１０８は、電文受信部１０１又は宛先決定部１０３に含まれていても良い。
【００６０】
業務ＡＰは業務単位に分割されており、１つの電文は規定の順番で業務ＡＰにて処理を行う。また、本実施例では処理対象の業務ＡＰと処理順序は電文毎に異なるケースも想定しているため、電文によっては処理不要な業務ＡＰが存在しても構わない。図３を参照すると、電文Ａ、Ｂ、Ｃのいずれも最初は業務ＡＰ１を行う。電文Ａは業務ＡＰ１の後に業務ＡＰ２、業務ＡＰ３の順に実行を行うが、電文Ｂは業務ＡＰ１のあとは業務ＡＰ３で完了する。また、電文Ｃは３種類の業務を全て行うが業務ＡＰ１の後の処理順序が電文Ａと異なり業務ＡＰ３、業務ＡＰ２の順となる。
【００６１】
電文には、入力データを格納するデータ部のほかに次に処理を行う業務ＡＰを記録するための制御部から構成される。処理装置１００への電文入力後や各業務ＡＰの処理終了後に宛先決定部１０３が次に処理を行う業務ＡＰを宛先管理テーブル１０７より特定し、宛先業務ＡＰを電文の制御部に格納する。図４を参照すると、電文Ｂは業務ＡＰ１、業務ＡＰ３の順で処理を行う。電文入力直後は宛先決定部１０３により制御部には宛先である「業務ＡＰ１」の情報が格納される。業務ＡＰ１の処理完了後に宛先決定部１０３は、制御部を次の宛先である「業務ＡＰ３」に更新する。更に業務ＡＰ３の処理完了後に宛先決定部１０３は、次の宛先を特定するために宛先管理テーブル１０７を参照するが、該当する宛先がないため制御部に「−」を格納する。
【００６２】
以下に処理管理機構の各部の機能を示す。
電文受信部１０１は、クライアントからの電文受信を契機に、該当電文の宛先業務の特定依頼を行う機能を持つ。なお、処理対象となった電文は、受信電文記憶部１０８に格納される。
【００６３】
宛先管理テーブル１０７は主記憶装置上に配置されており、電文毎に該当電文が最後に処理を行った業務ＡＰ情報より、次に処理を行う業務ＡＰを解決するための情報を保持する。
【００６４】
宛先決定部１０３は、各電文が次に処理を行う業務ＡＰを宛先管理テーブル１０７より特定し電文の制御部に宛先業務ＡＰ名を格納する機能と、特定した情報をもとに宛先業務ＡＰ単位に振り分けて電文集合バッファに格納する機能を持つ。
【００６５】
電文集合管理部１０４は、電文集合バッファ毎に電文数や電文集合の作成開始からの経過時間を監視し、一括処理の単位となる電文集合を作成する。電文数や経過時間が規定値を超えた場合は、それまでに格納されている電文を電文集合として処理先となる業務ＡＰに一括処理依頼を行う。但し、全ての業務処理を終えた処理済電文は、一括送信依頼を行う。
【００６６】
各業務ＡＰは処理した電文を再び宛先決定部１０３宛に送付する。
【００６７】
電文送信部１０６は、電文集合管理部１０４からの一括送信依頼を受けて、電文受信用のクライアント１３に対して該当電文集合の送付を行う。
【００６８】
次に、本実施例における動作について説明する。図５は、本実施例における動作を示すフローチャートである。
【００６９】
（１）ステップＳ１０１
クライアント１０、１１、１２からネットワーク５００を介して出力される電文は、処理装置１００の処理管理機構１１０に送付される。処理管理機構１１０の電文受信部１０１は、クライアントからの電文受信を契機に該当電文を受信電文記憶部１０８に格納し該当電文の宛先となる業務ＡＰの特定依頼を行う。
【００７０】
（２）ステップＳ１０２
宛先決定部１０３は、宛先業務ＡＰの特定依頼を受けて宛先管理テーブル１０７を参照することで該当電文の宛先を特定し、業務毎振り分けて電文集合バッファに格納する。
【００７１】
（３）ステップＳ１０３
電文集合管理部１０４は、宛先業務ＡＰ毎に規定条件を満たすまでの間、電文を取りまとめて電文集合を作成する。ここで条件としては、より多くの電文を一括処理可能とするように電文数が一定数になるまで取りまとめを行うことが望ましい。また、電文数のほかに、作成中である電文集合の最初の電文が到着してからの経過時間を監視し電文数が一定数以下の場合でも規定時間が経過した時点でとりまとめを終える規則も併用することが望ましい。これにより、一括処理によるスケジュールコストの削減と、１電文あたりの処理時間要件に柔軟に対応可能な即時処理が可能となる。電文集合の作成が完了した場合は、宛先業務ＡＰでの一括処理依頼を一括実行部１０５に対して行う。
【００７２】
（４）ステップＳ１０４
一括処理依頼を受けた一括実行部１０５は、該当電文集合の一括処理を行う。業務ＡＰでの処理が完了した電文は、再び宛先決定部１０３に送られ次に処理する業務ＡＰの特定を行う。
【００７３】
（５）ステップＳ１０５
電文を受信した宛先決定部１０３は、個々の電文の次の宛先業務ＡＰを宛先テーブルより特定する。ここで次に処理するべき業務が残っている場合は、電文集合管理部１０４により再び処理先業務ＡＰ単位に振り分けられ、電文集合バッファに格納される。
【００７４】
（６）ステップＳ１０６
以降は、処理すべき全ての業務ＡＰでの処理が完了するまでの間、上記の流れを繰り返す。
【００７５】
（７）ステップＳ１０７
宛先決定部１０３において、該当電文に必要な全ての業務で処理が完了した場合（次の宛先となる業務ＡＰがない場合）、本電文は、電文集合管理部１０４が有する処理済電文用の電文集合バッファに格納する。これらの電文も、電文集合管理部１０４にてとりまとめが行われ、電文数や経過時間が規定値となった場合は一括して電文送信部１０６に送信依頼を行う。
【００７６】
（８）ステップＳ１０８
送信要求を受けた電文送信部１０６は、該当電文をクライアント１３に対して送信を行う。
【００７７】
業務ＡＰの処理順序が変更となった場合の動作について説明する。
電文の処理順序は宛先管理テーブル１０７にて管理を行い、各業務ＡＰでの処理が終わった後に本テーブルを参照することで宛先業務ＡＰを特定する。新規業務の追加や既存業務の廃止などが発生した場合は、業務ＡＰの処理順序の変更が伴うことが想定される。このような場合は、宛先テーブルの内容を変更することで動的に業務順序の変更を行う。
【００７８】
本発明は、処理装置への入力を電文集合として管理する。本電文集合を、処理先となる業務ＡＰ単位に振り分けて一定量（期間）蓄えて一括処理を行う。各業務ＡＰの処理を行った電文は、電文毎に次の処理先（宛先）となる業務ＡＰ（又は処理装置）を宛先管理手段により解決し再び電文集合として取りまとめて、後続処理装置宛てに一括送付する。ここで、一括送付された電文集合もまた、宛先となる処理装置（業務ＡＰ）にて一括処理が行われる。これにより、複数の業務ＡＰを搭載する複数台の処理装置から構成され、電文毎に複数の処理装置間を行き来して処理が完結するような大規模システムに対しても本発明を適用してスループットの高いリアルタイム処理の実現が可能となる。
【００７９】
また、本発明では、業務ＡＰの処理順序の動的変更に加えて、各電文の処理順序（宛先）を特定し電文集合を作成する。これにより、電文集合をもとにした一括処理／送信によるリアルタイム処理のスループット向上が可能となる。
【００８０】
以上のように、本発明によるリアルタイム処理方式は、大量の入力電文を電文固有の処理順序に従い複数の業務ＡＰで処理を行うシステムにおいて、電文入力を契機として複数の電文を規則に従い取りまとめて該当業務ＡＰにて一括処理を行い、業務処理順序をテーブルで管理することで次に処理を行う業務ＡＰの特定（テーブルドリブン）を行う。これにより、大量な電文処理が必要となるリアルタイム処理において、一括処理によるスケジューリングコストの削減と、テーブルドリブンによる動的スケジューリングを可能とする。また、一括処理を行う電文の取りまとめ単位を、「電文数が一定数になるまで」や、「取りまとめ開始からの経過時間」などの条件をもとに設定することで処理実行時間の要件に柔軟に対応可能なリアルタイム処理が可能となる。
【図面の簡単な説明】
【００８１】
【図１】図１は、本発明のリアルタイム処理システムの構成を示すブロック図である。
【図２】図２は、本発明の実施例の構成を示すブロック図である。
【図３】図３は、電文毎の業務ＡＰの処理順序を示す図である。
【図４】図４は、業務ＡＰの処理順序と電文に格納される情報の関係を示す図である。
【図５】図５は、本実施例の動作を示すフローチャートである。
【符号の説明】
【００８２】
１〜３    業務ＡＰ
１０〜１３    クライアント
１００    処理装置
１０１    電文受信部
１０２    宛先管理部
１０３    宛先決定部
１０４    電文集合管理部
１０５    一括実行部
１０６    電文送信部
１０７    宛先管理テーブル
１０８    受信電文記憶部
１１０    処理管理機構
２００    電文送信装置
３００    電文受信装置
５００    ネットワーク
【図１】
2006350474.tif 000003
【図２】
2006350474.tif 000004
【図３】
2006350474.tif 000005
【図４】
2006350474.tif 000006
【図５】
2006350474.tif 000007