(57)【特許請求の範囲】
【請求項１】
共通伝送媒体に接続された複数の処理装置により一連の処理を分散して行い、かつ、該一連の処理のそれぞれを実行するためのプログラムを上記複数の処理装置に分散して記憶させ、該プログラム同士が共通伝送媒体を介してメッセージデータの交換により処理を行なう分散処理システムにおいて、
前記メッセージデータは、内容コードと送信元アドレスと制御コードとデータ部を含み、
各処理装置の記憶装置が、メッセージデータと同一の構造をもつデータ格納テーブルを有し、
各処理装置が、データが外部からのメッセージか編集処理後のデータかを示す情報とデータの内容コードと元となるデータの情報とデータの格納型と前記データ格納テーブルのＩＤと格納型に付属した情報とをデータ毎に登録した格納方法登録テーブルと、データが外部または他処理からのメッセージか格納済みのデータ格納テーブルかを示す情報とデータの内容コードとデータがデータ格納テーブルである場合の検索条件とデータ項目の並びとをデータ毎に登録した編集方法登録テーブルと、データが外部からのメッセージか編集処理後のデータかを示す情報とデータの内容コードと送信元アドレスと制御コードと送信先とデータに関する条件とをデータ毎に登録した送信方法登録テーブルとを有し、
各処理装置が、受信したメッセージデータをその構造に基づいてデータ項目に分解し、対応する前記データ格納テーブルを検索し、前記受信したメッセージデータの内容コードと前記格納方法登録テーブルから格納型を判断し、前記格納型に従って前記受信したメッセージデータを前記データ格納テーブルに蓄積し、
各処理装置が、前記編集方法登録テーブルに従って出力すべきデータのデータ項目値を設定し、
各処理装置が、前記送信方法登録テーブルで指定された送信先へ送信することを特徴とするデータ格納方法。
【請求項２】
前記処理装置が、受信したメッセージデータに対応するデータ格納テーブルに対して、メッセージデータ中のデータ項目の値に従って、自処理装置内のデータ格納テーブルを検索し、該当するレコードを上書きすることを特徴とする請求項１記載のデータ格納方法。
【請求項３】
前記テーブル内に該当する領域がない場合、該レコードデータ用の領域を新たに確保して、受信したメッセージデータを格納することを特徴とする請求項２記載のデータ格納方法。
【請求項４】
前記処理装置が、受信した１つまたは複数のメッセージデータと、自処理装置内に格納されているデータを用いて新たなレコードデータを生成するステップと、生成されたデータの構造に対応するデータ格納テーブルにデータを格納するステップを有することを特徴とする請求項１乃至３のいずれかに記載のデータ格納方法。
【請求項５】
前記生成ステップ、および前記格納ステップの処理が、受信した１つまたは複数のメッセージデータを用い複数実行されることを特徴とする請求項４記載のデータ格納方法。
【請求項６】
前記処理装置が、受信したメッセージに含まれる情報または該メッセージに関して記憶されている情報を用いて、受信したメッセージデータ、または受信したメッセージデータと自処理装置内に格納されているデータを用いて生成された新たなレコードデータを格納するか判断するステップを有することを特徴とする請求項１乃至５のいずれかに記載のデータ格納方法。
【請求項７】
前記処理装置が、自処理装置の状態により、受信したメッセージデータ、または受信したメッセージデータと自処理装置内に格納されているデータを用いて生成された新たなレコードデータを格納するか判断するステップを有することを特徴とする請求項１乃至５のいずれかに記載のデータ格納方法。
【請求項８】
前記処理装置が、受信した１つまたは複数のメッセージデータと、自処理装置内に格納されているデータを用いて新たなレコードデータを生成するステップと、生成されたデータの構造に対応する識別子を付加して送信するステップを有することにより、問い合わせ元の装置または他の装置において、同一識別子を持つメッセージの受信と同一のインタフェースによって格納されているデータの受信を可能とすることを特徴とする請求項１記載のデータ格納方法。
【請求項９】
前記処理装置が、受信したメッセージに含まれる情報または該メッセージに関して記憶されている情報を用いて、受信したメッセージデータと自処理装置内に格納されているデータを用いて生成された新たなレコードデータを送信するか判断するステップを有することを特徴とする請求項８記載のデータ格納方法。
【請求項１０】
前記処理装置が、自処理装置の状態により、受信したメッセージデータ、または受信したメッセージデータと自処理装置内に格納されているデータを用いて生成された新たなレコードデータを送信するか判断するステップを有することを特徴とする請求項８記載のデータ格納方法。
【請求項１１】
前記処理装置においてデータを格納するテーブルの構造または、共通伝送媒体上を流れるメッセージデータの構造の定義を入力するインタフェースと、いずれかの定義を用いて他方の定義に用いることを可能とする定義プログラムを有することを特徴とする、請求項１乃至７のいずれかに記載のデータ格納方法。
【請求項１２】
各処理装置または各処理装置に格納されているプログラムが入出力するメッセージデータと、データ格納するテーブルとのデータ入出力の関係を、全ての処理装置にわたって表示するインタフェースを有するプログラムを有することを特徴とする請求項１乃至７のいずれかに記載のデータ格納方法。
【請求項１３】
データの格納処理と編集処理と送信処理の各処理を矢印でつなぐことにより処理の流れを定義し、内容コードを付した矢印によって処理間で渡されるデータを定義し、データの構造を定費するためのプログラムを有することを特徴とする請求項１に記載のデータ格納方法。
【請求項１４】
処理装置間のメッセージデータの入出力関係を表示することを特徴とする請求項１に記載のデータ格納方法。
【請求項１５】
プログラム間のメッセージデータの入出力関係を表示することを特徴とする請求項１に記載のデータ格納方法。
【請求項１６】
各処理装置は、受信したデータをバッファに保存しておき、自装置のプログラムの必要とするデータが揃った場合に、自装置のプログラムにデータを渡すことを特徴とする請求項１に記載のデータ格納方法。
【請求項１７】
共通伝送媒体に接続された複数の処理装置により一連の処理を分散して行い、かつ、該一連の処理のそれぞれを実行するためのプログラムを上記複数の処理装置に分散して記憶させ、該プログラム同士が共通伝送媒体を介してメッセージデータの交換により処理を行なう分散処理システムを構成する前記処理装置において、
前記メッセージデータは、内容コードと送信元アドレスと制御コードとデータ部を含み、
メッセージデータと同一の構造をもつデータ格納テーブルを有する記憶装置と、
データが外部からのメッセージか編集処理後のデータかを示す情報とデータの内容コードと元となるデータの情報とデータの格納型と前記データ格納テーブルのＩＤと格納型に付属した情報とをデータ毎に登録した格納方法登録テーブルと、
データが外部または他処理からのメッセージか格納済みのデータ格納テーブルかを示す情報とデータの内容コードとデータがデータ格納テーブルである場合の検索条件とデータ項目の並びとをデータ毎に登録した編集方法登録テーブルと、
データが外部からのメッセージか編集処理後のデータかを示す情報とデータの内容コードと送信元アドレスと制御コードと送信先とデータに関する条件とをデータ毎に登録した送信方法登録テーブルと、
受信したメッセージデータをその構造に基づいてデータ項目に分解し、対応する前記データ格納テーブルを検索し、前記受信したメッセージデータの内容コードと前記格納方法登録テーブルから格納型を判断し、前記格納型に従って前記受信したメッセージデータを前記データ格納テーブルに蓄積する手段と、
前記編集方法登録テーブルに従って出力すべきデータのデータ項目値を設定する手段と、
前記送信方法登録テーブルで指定された送信先へ送信する手段とを有することを特徴とする処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散処理システムにおいて各処理装置において発生したデータを該処理装置又は他の処理装置に保存しておき、必要に応じて保存されたデータを任意の装置が取得し、利用するようにされた分散処理システムにおけるデータの格納方法及びデータアクセス方法に関する。
【０００２】
【従来の技術】
従来、分散処理システムにおいてデータを格納する装置またはプログラムとしてはデータベースソフトウェアがあり、例えば、ネットワークコンピューティング1994年6月号，PP．9-23「ミドルウェアを使いこなす」に記載されるようなものが知られている。ここに挙げられているようなデータベースシステムでは、格納するデータとその構造をデータベース（DB）ごとに定義し、データの格納及びデータの検索、取得等もDBを指定して行われる。
【０００３】
【発明が解決しようとする課題】
従来のシステムでは、分散処理を行う処理装置やプログラム間でやりとりされるメッセージデータとDBは全く別に設計されるため、DB側のプログラムが、受信したメッセージデータを解析してDBの構造にあわせて格納する必要があった。さらに構造の定義も、メッセージ側とDB側で２重に行う必要があった。
【０００４】
DBのデータを利用するプログラムは、必要とするデータを格納しているDB中のデータと、伝送媒体に流されるメッセージデータ両方の構造やデータ内容を意識する必要がある。また、あるプログラムからDB中のデータを操作する場合は、相手先処理装置、DB、及びテーブルを指定する必要があった。このため、あるデータに関連した複数のデータ格納テーブルがある場合や、データ格納テーブルを多重化した場合は、DBのデータを操作するプログラムが全てのテーブルを指定してデータの格納や取得を行う必要があり、データ格納テーブルを拡張したり多重度を増したりするのにプログラムを変更する必要があったため、システムの柔軟性が低かった。
【０００５】
また、従来のDBはデータを格納しておくためのものであり、自律的なデータ取得や送信が行なえず、データの格納や送信は、全て、ある処理装置やプログラムから要求を発行して行なう必要があった。このため、DB中のデータを操作して、結果を他の処理装置に伝える必要がある場合は、DBのデータを操作したプログラムが他の処理装置に対して変更を伝える必要があり、プログラムの処理が煩雑になったり、システムの改造に伴いプログラム改造が必要になったりして、システムの柔軟性が低かった。さらにDBが自律的な判断を行わず、処理装置やプログラムからのデータ操作要求をそのまま実行するのみであるため、あるプログラムが誤ったデータ操作をしたために、その影響が他のプログラムに及んでしまうことも多く発生していた。
【０００６】
一方、各DBが自律的にデータを取得する方法として、例えば特開昭62-169242号公報に記載されている方法がある。これによると各DBは自律的にデータを取得したりすることは可能であるが、DBの構造については規定がなく、このためデータを発生するプログラムやデータを取得するプログラムからは、DBのデータ構造やメッセージのデータ構造について意識する必要があった。
【０００７】
このように、分散処理システムにおいてデータを格納するために、従来は、データ格納テーブルの構造をDB専用に定義する必要があった。
【０００８】
したがって、本発明の目的は、分散処理装置間やプログラム間でやりとりするメッセージデータの構造や名称を、DB中のデータ格納テーブルの名称や構造と透過にすることで、メッセージデータ及びDB中のデータを利用する処理装置やプログラムに対して、システム内で統一されたデータアクセス方法とデータ名称、データ構造を提供することにある。
【０００９】
また、本発明の他の目的は、DBに自律的な処理を行わせることで、送信元が意識してデータを書き込まなくとも、DBが自律的にデータを格納することを可能にすることにある。
【００１０】
さらに、本発明は、データの格納や送信といった処理を実行するかしないかを、DBが自律的に判断し、異常データの波及防止等を可能とすることを目的とするものである。
【００１１】
【課題を解決するための手段】
本発明のデータ格納方法及びアクセス方法は、処理装置間やプログラム間で送受信されるメッセージデータの名称や構造の定義情報と、DB内のデータ格納テーブルの名称や構造の定義情報を透過に利用可能なものとし、片方の定義が他方の定義として利用可能なものとすることを特徴とする。またこの情報の定義や、処理装置間及びプログラム間のメッセージ送受信の関係とデータ格納テーブルを介したデータの流れを、システム全体にわたって共通の定義プログラムを用いて定義したり、共通の参照プログラムを用いて参照したりする。
【００１２】
さらに、メッセージデータやDB中のデータを操作したり参照したりするプログラムに対して、メッセージデータとDB中の格納データを同一のインタフェースや同一のデータ名称、構造で操作したり、利用したりさせる。
【００１３】
さらに、本発明では、DB側に自律的なデータ操作やその判断機能をもたせることで、受信したメッセージデータを元にして関連する自内のデータ格納テーブルを書き換え、新しいメッセージデータを作成して送信し、また、これらの処理を実行するか判断したりさせることを特徴とする。
【００１４】
【発明の実施の形態】
以下に、本発明の実施の形態を詳細に説明する。
【００１５】
図１は、本発明を適用した分散処理システムの一例を示す構成図である。分散処理システムは、共通伝送媒体１０１を介して互いにデータの授受を行う処理装置１１１〜１１３と、ディスプレイやキーボードを有する端末１２１〜１２３から構成されている。処理装置１１１〜１１３には、端末１２１〜１２３が接続されている。ここで、端末１１１〜１１３は、ディスプレイやキーボード等のマンマシンインタフェースを持ち、このインタフェースを介して、処理装置上で実行されるプログラムの制御を行なったり、プログラムの出力を参照したりする機能を有している。また、処理装置１１１〜１１３は、メモリやディスク等のデータ記憶媒体を保持している。
【００１６】
処理装置１１１〜１１３は、伝送路上を流れるデータが自内のプログラムに必要なものであるかどうかを判定し、必要と判定したときこのデータを保存しておき、該プログラムの必要とするデータが揃った時点で、自装置内のプログラムにデータを渡す。本実施の形態におけるデータ格納方法を有するプログラム、及びデータアクセス方法を用いるプログラムも同様に必要となるデータが揃った時点でデータを受け取る。
【００１７】
図２(a)は、伝送路１０１上で送受信されるメッセージのフォーマットを示している。各メッセージは、データ２０４の他、データ２０４に付加された、メッセージデータの内容を示す内容コード（CC）２０２、送信元アドレス（SA）２０３、及び制御コード（CtlC）２０１を含んでいる。各処理装置１１１〜１１３は、これらの情報をもとにして各メッセージが自内のプログラムに必要なデータかを判断する。データ部２０４は、後述する定義プログラムによって構造が定義されており、各プログラムはCC２０２によってその構造を判断しデータを操作する。図２(b)は、データ部２０４の構造の一例である。本例では、データ部は製品ＩＤ２２１、管理番号２２２、測定値２２３等から構成される。２２４にもその他の構成データ項目が並ぶ。各処理装置やプログラムは、このデータ部に対して構造を定義し、この構造に従ってメッセージデータに値を設定してデータをやり取りする。
【００１８】
図３は、処理装置内プログラム構成の一例である。通信管理プログラム３１１が伝送媒体を介したメッセージデータの送受信を管理し、必要なデータが揃ったら、データ操作サブプログラムである蓄積処理サブプログラム３１３や編集処理サブプログラム３１４を起動する。サブプログラム３１３〜３１５は、データ管理プログラム３１２を経由してデータの格納を行ったり、他のサブプログラムとデータの受け渡しを行ったりする。データ管理プログラム３１２は、内部記憶装置内のデータ格納テーブル３２１や、外部記憶装置内のデータ格納テーブル３２２の名称や構造、アドレスやサイズ等を管理し、データのアクセスを行う。内部記憶装置はメモリ等で、外部記憶装置はディスク等である。
【００１９】
図４は、データが格納される格納装置内テーブル（以下テーブル）の構造例である。図４(a)は、メッセージ中のデータが格納されるデータ格納テーブルである。図２において説明したように、このテーブルの構造はCC, SA, CtlC等によって判断されるメッセージの構造に一致しており、各メッセージごとに作成されるものである。本例は、CCが“500”であるデータ格納テーブルの例であり、この構造はCCが“500”のメッセージにも適用されている。図４(b)は、図４(a)において説明したテーブルに格納されるメッセージのCC, SA, CtlC等のメッセージ情報および受信時刻等の情報を格納するテーブルである。ここに格納されるデータは、図４(a)に格納されるデータと紐付けされている。図４(a)、(b)のテーブルとも、後に説明する格納方式によって、固定的に確保することも動的に確保することもできる。またこのテーブルは、処理装置内の主記憶装置、補助記憶装置等任意の記憶装置に確保することができる。
【００２０】
次に、メッセージ格納処理の一例について説明する。
【００２１】
図５は、処理装置内の格納データ及び格納方法登録テーブルの一例である。入力データが外部からのメッセージか後述する編集処理後のものかを示す入力フィールド５１１と、入力データ又は編集処理後のデータのCCを格納するフィールド５１２、元となる受信メッセージの情報を格納するフィールド５１３、５１４、格納型を格納するフィールド５１５、テーブルＩＤ５１６、格納タイプに付属した情報を格納する付属項目５１７から構成されている。各入力データに関するこれらの項目が、レコード５２１〜５２４に格納されている。レコード５２１の例では、CCが“500”である外部からのメッセージを、送信元処理装置（SA）やメッセージの制御コード（CtlC）に関わらず蓄積型で格納するよう定義されている。レコード５２２の例は上書き型であり、付属項目５１７にあるように、製品ＩＤというデータ項目の値をキーとして格納するよう指定されている。本例では付属項目は１つのデータ項目であるが、これは複数個指定してもよいし、データを格納するか否かといった条件を指定しておくことも可能である。
【００２２】
図６は、蓄積処理の流れを示すフローチャートである。蓄積処理では、伝送媒体からのメッセージまたは他処理からのデータを受信し（ステップ６０１）、以降で説明する処理継続判定を行う（ステップ６０２）。その後、受信した外部または編集処理からのデータに対応する格納テーブルを検索し（ステップ６０３）、該データをその構造に基づいてデータ項目に分解して（ステップ６０４）、受信データのCCまたはIDと登録テーブルから格納型を判断する（ステップ６０５）。上書き型の場合は、図７にて説明する上書き処理を行い、蓄積型の場合はテーブルに新規にレコードを追加し（ステップ６０６）、該レコード中の、登録テーブルに指定されたフィールドにデータを格納する（ステップ６０７）。
【００２３】
図７は、上書き処理の流れを示すフローチャートである。受信したデータのCCと登録テーブルより上書き先レコードのキーとなるフィールドを取得し（ステップ７０１）、テーブルを検索することにより上書き先レコードを検索する（ステップ７０２）。次に、上書き先レコードが存在したかどうか判断し（ステップ７０３）、上書き先レコードが存在した場合は登録テーブルより上書き先のフィールドを取得し、該フィールドにデータを上書きする（ステップ７０４）。上書き先レコードが存在しなかった場合は、登録テーブルよりレコードが存在しなかった場合の処理を判断する（ステップ７０５）。廃棄処理が指定されていた場合は処理終了となり、追加処理が指定されていた場合は新規にレコードを追加し（ステップ７０６）、登録テーブルより上書き先のフィールドを取得し、該フィールドにデータを上書きする（ステップ７０４）。
【００２４】
図５〜図７において説明したデータ格納方法により、各処理装置内のプログラムが相手先や格納方法を指定せず送信したメッセージデータを格納することが可能である。
【００２５】
これまで説明した格納処理は、外部からのメッセージを直接格納することが可能であり、また、なんらかの編集処理の結果を格納することもできる。以下に編集処理の例を示す。
【００２６】
図８は、編集方法を登録するテーブルの一例である。図８(a)は、１つの編集処理につき複数の入力データ各々の条件と構造を示すテーブルである。各入力データごとに、入力元が外部または他処理からのメッセージか、格納済みのテーブルかを示す入力フィールド８１１、入力データのCC８１２、入力データがテーブルの場合にレコードの検索条件を示すフィールド８１３、データを構成する要素となるデータ項目の並び８１４〜８１７、が設定される。第１列８０１の例では、入力データがCC“600”のテーブルで、データ項目構成がID、規格、許容誤差、価格からなり、IDが“26”のレコードを検索するという設定である。本例では検索条件は定数を用いた式であるが、定数や入力データ中の値を用いて条件設定したり、数式以外でも文字列の一致やある文字列を含むかといった条件も加えることが可能である。また、データが格納された時刻を用いて一定範囲を検索したりすることも可能である。
【００２７】
図８(b)は、この編集処理による出力データを表すテーブルである。出力データのCC８２１、出力データを構成するデータ項目へのポインタ８２２〜８２５から構成される。８２２〜８２５は、該フィールドに設定される入力元データ項目を示す入力元テーブル中の項目のポインタが設定される。
【００２８】
図９は、編集処理の流れを示すフローチャートである。編集処理では、伝送媒体からのメッセージまたは他処理からのデータを受信し（ステップ９０１）、該編集モジュールが必要としているデータが全て揃ったか判断する（ステップ９０２）。ここで、処理装置が自内テーブルに格納しているデータ、すなわち入力元がテーブルとなっている入力データについては、既に揃っているものとみなす。データが揃っていない場合は、受信したデータをバッファに格納し（ステップ９０３）、次のデータ受信を待つ。データが揃っていた場合は、入力元テーブルより必要なデータを検索して揃え（ステップ９０４）、バッファからも入力データを取得して（ステップ９０５）、編集処理の登録テーブルに従って出力データのデータ項目値を設定する（ステップ９０６）。設定されたデータは、他の編集処理又は格納処理、後述する送信処理へ送信される（ステップ９０７）。
【００２９】
ここでは、データ項目の選択と配置についての編集処理を示したが、編集処理は本実施例のみに留まるものでなく、例えばユーザ作成の任意のデータ処理を行なうプログラムとすることも可能である。
【００３０】
次に、データを格納した処理装置からデータを送信する場合の例について説明する。
【００３１】
図１０は、送信処理方法の登録テーブルの一例である。入力データが外部からのメッセージか編集処理後のものかを示す入力フィールド１０１１と、入力データ又は編集処理後のデータのCCを格納するフィールド１０１２、受信メッセージ、または前処理の編集処理の元となった受信メッセージのＳＡ情報を格納するフィールド１０１３、このメッセージのＣｔｌＣを格納するフィールド１０１４、送信先を指定するフィールド１０１５、受信したデータに関する条件を格納するフィールド１０１６で構成される。これらの項目が各入力データに対してレコード１０２１〜１０２５に格納されている。例えば、レコード１０２１は、他編集モジュールからのCC“800”の入力データを、伝送媒体からの受信メッセージのSAやCtlC及びデータの内容に関わらず、相手先処理装置を特定せずに送信するよう指定されていることを示している。
【００３２】
図１１は、送信処理の流れを示すフローチャートである。送信処理では、伝送媒体からのメッセージまたは他処理からのデータを受信し（ステップ１１０１）、以降で説明する処理継続判定を行う（ステップ１１０２）。その後、データを登録テーブルに指定された処理装置を指定して送信する（ステップ１１０３）。送信されるメッセージは、入力データと同じ構造、同じ識別子を持って送信される。図１０の登録テーブル中レコード１０２１に対応する処理の例では、前処理となった編集処理より取得したデータに、CC“800”の識別子を付けられて送信される。
【００３３】
このようなデータ送信方法により、受信側のプログラムでは、他プログラムから送られるメッセージと、問い合わせメッセージ等の手段により他処理装置から取得した格納済みメッセージデータを同一のインタフェースで受信することが可能となる。
【００３４】
次に、これまで説明した編集処理、格納処理、送信処理を組み合わせて行われる処理装置内の処理の一例を、以下に説明する。
【００３５】
図１２は、複数処理連携のための定義テーブルである。図１２(a)は受信メッセージのCCに対してどの処理を起動するか示すCCと処理の対応を示すＣＣモジュールテーブルである。フィールド１２１１に受信メッセージのCC、該メッセージにより起動される処理のインデックスがフィールド１２１２に格納されている。ここで処理のインデックスは、図１２(b)に示す処理テーブル中のインデックスを意味する。各入力メッセージのCCに対応する起動処理が、レコード１２２１〜１２２３に格納されている。例えば、レコード１２２１は、CC“1000”に対し、インデックス“１”の処理を起動するよう登録されている。
【００３６】
図１２(b)は、各処理の情報を格納する処理テーブルである。インデックス１２５１は、各列の識別子である。各処理の情報は、処理名１２５２、処理種別１２５３、処理番号１２５４、各処理のパラメータ定義テーブルへのポインタ１２５５、入力データの構造を示すCCを格納するフィールド１２５６、出力データの構造を示すCCを格納するフィールド１２５７、該処理に続いて起動される処理のインデックス１２５８、１２５９で構成される。例えば、列１２６１は、処理名“a”の編集処理で、インデックス“２”、“３”で示される処理にCC“700”の構造をもつデータを渡すよう登録されている。インデックス“２”、“３”で示される処理は、インデックス“１”の処理後並行して実行される。インデックス“２”、“３”の処理を登録してある列１２６２、１２６３では、入力CCはともに“700”である必要がある。
【００３７】
図１３に、クライアント処理装置からのデータ問い合わせに対する応答処理の一例を示す。この応答処理は、受信した問い合わせデータに基づく編集処理１３０１と、生成された応答データを要求元に送信する処理１３０２からなる。編集処理１３０１では、まず、受信したメッセージが問い合わせメッセージかどうか判断する（ステップ１３１１）。問い合わせメッセージであった場合は、要求されているデータのCCを取得し（ステップ１３１２）、該CCのデータの検索条件を取得する（ステップ１３１３）。検索条件は、受信した問い合わせメッセージデータ中より取得したり、予め当該編集処理の用いるテーブルに登録しておくことができる。その後、該CCのデータ格納テーブルよりレコードデータを検索及び取得し（ステップ１３１４）、送信処理へと渡す。送信処理においては、編集処理より受け取ったデータを、ステップ１３１２で取得したCCを付加して要求元処理装置、すなわち問い合わせメッセージを送信した処理装置へ送信する。CCが“500”である場合の、送信処理の登録テーブルの例が、図１０に示すテーブル中のレコード１０２２である。本実施例では、フィールド１０１１〜１０１４によって、入力データは伝送媒体から受信したCC“500”の問い合わせメッセージであると判断され、データは問い合わせ元にのみ送信される。
【００３８】
図１４は、受信したデータを用いて新しいレコードデータを作成し、新しいデータを用いて自処理装置内データ格納テーブルを書き換え、この最新データを他処理装置へ送信する処理の例である。図１２(b)に示す処理テーブル中の、レコード１２２１〜１２２３にて示した連携処理の例である。この処理は、例えば、編集処理１４０１、格納処理１４０２、送信処理１４０３より構成される。編集処理１４０１では、受信したメッセージが問い合わせメッセージかどうか判断し（ステップ１４１１）、問い合わせメッセージでなかった場合は指定された方法でデータを編集して（ステップ１４１２）、後の格納処理１４０２及び送信処理１４０２へと生成したデータを渡す。格納処理１４０２では、取得したデータに対応するテーブルに該データを上書きし、送信処理１４０３では、取得したデータに対応するCCを付加してメッセージを送信する。
【００３９】
以上示した２例のように、複数の処理モジュールを連携させてデータの編集、格納、送信を行なうことが可能である。また、１回のメッセージ受信で、複数のデータ格納テーブル操作やメッセージ送信処理を実行することも可能である。
【００４０】
図１５は、データの格納、送信処理を継続するか否かを判断する処理の一例を示すフローチャートである。この処理は、格納処理においては図６のステップ６０２、送信処理においては図１１のステップ１１０２に対応する処理である。まず、取得したメッセージデータより、メッセージ送信元のアドレスや特定のデータ項目値等の、処理継続判断に必要な情報を抽出する（ステップ１５１１）。これを登録テーブル中の設定項目と比較し（ステップ１５１２）、条件を満たさない場合は“NG”を返す。条件を満たす場合、自処理装置内の状態を取得する（ステップ１５１３）。これは、CPUの負荷や記憶装置の使用量、データを格納するテーブルの占有状況、過去の何らかの処理により影響されたデータの信頼性等である。これらが条件を満たすか判断し（ステップ１５１４）、満たさない場合は“NG”、満たす場合は“Good”を返す。“Good”が返された場合は処理を継続し、“NG”が返された場合は処理を中止する。
【００４１】
図１６は、データ格納、編集、送信処理と、メッセージ構造を定義するプログラムのインタフェースの一例である。受信するメッセージデータがCC番号“640”の計画修正データ１６１１であり、該データを用いて編集処理１６２１、上書き処理１６２２、送信処理１６２３が順次実行されることで、データの格納と送信を行う処理の定義画面例を示している。各々の処理に渡されるデータは、矢印１６３１〜１６３３で示されており、これらにもその内容や構造に従ってCCが付けられている。本例では、矢印１６３１はCCが“640”であり、矢印１６３２、１６３３はCCが“700”である。画面右側のテーブルの図は、各処理が操作するデータ格納テーブルを示している。この例では、編集処理１６２１はCCが“730”のテーブル１６４１を、上書き処理１６２２はCCが“700”のテーブル１６４２を操作することを示している。このように、各処理を矢印でつなぐことで処理の流れを定義し、矢印によって処理間で渡されるデータを定義する。
【００４２】
図１７は、図１６の画面より開かれる詳細定義画面である。図１７(a)は、データ構造定義画面であり、図１６の入力データ表示１６１１、またはデータ表示矢印１６３１をマウスでクリックすることで表示される。この例ではCCが“640”のデータ構造を定義しており（フィールド１７１１）、構成するデータ項目が、順に、メーカ名１７１２で２０バイト文字列型（１７２１）、要求納期１７１３で１０バイト文字列型（１７２２）、製品コード１７１４で長整数型（１７２３）、本数１７１５で符号なし長整数型（１７２４）であることを示している。この定義は、入力メッセージのみに留まるものでなく、CCが“640”のデータ格納テーブルの定義として透過的に利用される。また図１６中のテーブル表示１６４１、１６４２をマウスでクリックしても、同様にCCが“730”の構造定義画面、CCが“700”の構造定義画面を表示し、各々の構造を定義可能である。ここで定義されたデータ構造は、それぞれCCが“730”のメッセージ、CCが“700”のメッセージに透過的に利用される。
【００４３】
図１７(b)は、データ編集処理の処理内容の定義画面の一例である。この画面は、例えば、図１６中の編集処理１６２１をマウスでクリックして表示される。入力データが、CC“640”１７３１とCC“730”１７３２であり、出力データがCC“700”１７３３である。線１７４１、１７４２は、CC“640”とCC“730”のメーカ名、およびCC“640”とCC“730”の製品コードが等しいレコードを検索して、入力データとして用いることを示している。矢印１７５１〜１７５５は、入力データ項目と出力データ項目の対応を示しており、例えば、矢印１７５１によってCC“640”のメーカ名が出力データCC“700”のメーカ名１７６１に設定されることを示している。フィールド１７６１〜１７６５は、出力データCC“700”を構成するデータ項目である。
【００４４】
図１８は、各処理装置間でメッセージデータが入出力される関係を表示するインタフェースの一例である。図１８(a)は、装置間のメッセージデータ入出力を表す装置間リンケージ図である。箱１８１１〜１８１３が各装置を表し、矢印１８３１〜１８３４がメッセージデータを表している。記憶装置１８２１を含んでいる装置１８１３は、データ格納処理を行っている装置である。矢印１８３１は、装置“１”から送られ、装置“３”に受信されるメッセージデータを、矢印１８３３は装置“３”から送られ、装置“２”に受信されるメッセージデータを、矢印１８３４は装置“２”から送られるメッセージデータをそれぞれ表している。矢印１８３２は、装置“２”が装置“３”から問い合わせによりデータを取得していることを表している。
【００４５】
図１８(b)は、プログラム間のメッセージデータ入出力、及びプログラムとデータ格納テーブルのデータ入出力関係を表している。箱１８５１〜１８５４がプログラムを表し、矢印１８６１〜１８６３がプログラム間で送受信されるメッセージデータを表している。１８７１、１８７２は、データ格納テーブルを表している。メッセージ１８６１を受信したプログラムc１８５３は、データ格納テーブル１８７１、１８７２にデータを格納する。受信データの編集とテーブルへの格納処理は、これまで説明したようにして行われる。プログラムd１８５４は、メッセージ１８６２を受信し、データ格納テーブル１８７１から取得したデータを用いてメッセージデータを作成し、該データを矢印１８６３で表されるように送信している。このような表示により、各プログラムとテーブルに格納されたデータの関係がわかりやすくなる。またプログラムdを表す箱１８５４をマウスでクリックして、図１６や図１７に示すの画面を表示することで、メッセージデータがどのように生成されたかを示し、データ生成関係をわかりやすく表示することも可能である。
【００４６】
【発明の効果】
処理装置間やプログラム間で送受信されるメッセージデータの名称や構造の定義と、DB内のデータ格納テーブルの名称や構造の定義を透過なものとすることで、メッセージ、テーブルといったシステム全体で共通化するデータ設計が、統合的に可能となる。プログラム間のデータの流れに加え、データ格納テーブルを含めたデータの流れや、データ生成の関係がシステム全体で表示可能で、システムの構成や挙動を把握しやすくなる。
【００４７】
また、各プログラムは、メッセージデータとDB中の格納データを同一のインタフェースや同一のデータ名称、構造で操作したり、利用したりさせることができるため、システム構造が簡単になり、プログラムの開発量が減少する。データのアクセスや操作も容易になる。
【００４８】
さらに、DB側が自律的なデータ操作やその判断機能を持つことで、受信したメッセージデータを元にして新レコードデータを作成したり、データ格納や送信を行ったりといった複数の処理を行える。このため各プログラムが全てのデータ操作を行ったりしなくてもよくなり、伝送路の負荷を下げられ、プログラムの開発量を下げられる。また、システムの改造やDBの拡縮、多重度の変更も、プログラムを書き換えずに行える。DB側の自律的な処理継続判断機能により、あるプログラムの送信した異常データの影響が、他のプログラムに波及しないようにできる。
【図面の簡単な説明】
【図１】本発明の一実施例における分散処理システムの構成を示すブロック図である。
【図２】共通伝送媒体を介して処理装置間で送受信されるメッセージデータの構成図と構成例の説明図である。
【図３】データ格納方法及びアクセス方法を実現する処理装置内のプログラム構成例説明図である。
【図４】データ格納テーブルの構造説明図である。
【図５】格納データを登録するテーブル例の説明図である。
【図６】データ蓄積処理を示すフローチャートである。
【図７】データ上書き処理を示すフローチャートである。
【図８】データ編集処理で用いるテーブルの構成例の説明図である。
【図９】データ編集処理を示すフローチャートである。
【図１０】送信処理で用いるテーブルの構成例の説明図である。
【図１１】データ送信処理を示すフローチャートである。
【図１２】データ格納処理やデータ編集処理、データ送信処理の組み合わせを登録するテーブルの構成説明図である。
【図１３】問い合わせ応答処理を実施する編集処理と送信処理の組み合わせ例を示すフローチャートである。
【図１４】データ格納及び送信処理を実施する編集処理及び上書き処理、送信処理の組み合わせ例を示すフローチャートである。
【図１５】自律的な処理継続判定処理を示すフローチャートである。
【図１６】データ格納方法及びアクセス方法を実現する処理構成の定義画面例の説明図である。
【図１７】データ構造及びデータ編集方法を定義する画面例の説明図である。
【図１８】装置又はプログラムと、データ格納装置又は格納テーブル間のデータフローを表示する保守プログラム画面例の説明図である。
【符号の説明】
111〜113：処理装置、121〜123：端末、101：共通伝送媒体、311：通信管理プログラム、312：データ管理プログラム、321：内部記憶装置、322：外部記憶装置、401〜403：データ格納テーブル、431〜433：メッセージ関連情報格納テーブル。
【図１】
0003887840.tif 000002
【図２】
0003887840.tif 000003
【図３】
0003887840.tif 000004
【図４】
0003887840.tif 000005
【図５】
0003887840.tif 000006
【図６】
0003887840.tif 000007
【図７】
0003887840.tif 000008
【図８】
0003887840.tif 000009
【図９】
0003887840.tif 000010
【図１０】
0003887840.tif 000011
【図１１】
0003887840.tif 000012
【図１２】
0003887840.tif 000013
【図１３】
0003887840.tif 000014
【図１４】
0003887840.tif 000015
【図１５】
0003887840.tif 000016
【図１６】
0003887840.tif 000017
【図１７】
0003887840.tif 000018
【図１８】
0003887840.tif 000019