JPH08115373A - Information system in distributed system - Google Patents

Information system in distributed system

Info

Publication number
JPH08115373A
JPH08115373A JP24908194A JP24908194A JPH08115373A JP H08115373 A JPH08115373 A JP H08115373A JP 24908194 A JP24908194 A JP 24908194A JP 24908194 A JP24908194 A JP 24908194A JP H08115373 A JPH08115373 A JP H08115373A
Authority
JP
Japan
Prior art keywords
notification
transaction
queue
notification means
customer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP24908194A
Other languages
Japanese (ja)
Inventor
Kazuyuki Ikeda
一幸 池田
Atsushi Nitta
淳 新田
Mitsunobu Tasaka
光伸 田坂
Takatoshi Shimoyama
高寿 下山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP24908194A priority Critical patent/JPH08115373A/en
Publication of JPH08115373A publication Critical patent/JPH08115373A/en
Pending legal-status Critical Current

Links

Landscapes

  • Multi Processors (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

PURPOSE: To make an efficient communication by associating informing means with each other for a client having accounts of plural branches when an informing means are provided for every group of branches in a transaction detail storage file and informing processes are made parallel. CONSTITUTION: Transaction details which are obtained from other systems are stored in the order of account numbers by using a transaction detail storage mean 10. An information queue inserting means 20 generates information queues for every client by referring to the storage contents in the order of the account numbers. A transaction informing means 30 takes out one transaction information from the head unless the queue is empty, and inquires of other informing means by using a transaction information acknowledgement request means 40. Then, a transaction information associating means 50 receives the inquiry, transfers transaction contents stored in the transaction detail storage means 10 to the transaction information acknowledgement request means 40 on condition that the client is expected to be informed, and deletes them from the information queue. When the transaction information acknowledgement request means 40 receives the transaction contents of other informing means, the transaction informing means 30 informs the client of them together with the transaction contents that the means itself holds.

Description

【発明の詳細な説明】Detailed Description of the Invention

【０００１】[0001]

【産業上の利用分野】本発明は、金融機関における取引
内容を取引先へ通知する方法および装置に係り、例えば
ファックスを通して給与振込み状況を通知する勘定系の
サブシステム並びにそれに好適な通知方式に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method and an apparatus for notifying a customer of transaction details in a financial institution, and more particularly to an accounting subsystem for notifying a payroll transfer status by fax and a notification method suitable for the subsystem.

【０００２】[0002]

【従来の技術】本発明に関連する公知例として、日立製
作所のアプリケーションプログラムプロダクト「ＥＢ−
２１システム（外部接続システム）」が挙げられる。こ
のシステムは、取引明細蓄積ファイルを店群ごとに別ボ
リュームとし、通知キューを取引先の地区ごとに別とし
て、１つのＣＰＵが一括管理している。2. Description of the Related Art As a publicly known example related to the present invention, an application program product "EB-" manufactured by Hitachi, Ltd.
21 system (external connection system) ”. In this system, a transaction detail accumulation file is set as a separate volume for each store group, and a notification queue is set separately for each customer's district, and one CPU collectively manages the notification queue.

【０００３】[0003]

【発明が解決しようとする課題】前記公知例に対して、
取引明細蓄積ファイルのボリュームごとに別ＣＰＵを割
り当てることにより通知能力を向上することを考える。
このとき、取引先をＣＰＵにくくりつける、つまり各取
引先に対して通知するＣＰＵを１つ予め決めておく方法
がある。並列システムを構築する際、各ＣＰＵの構成要
素をできるだけ同一にするという観点からすると、前記
の方法は各ＣＰＵ別に取引先情報という要素が入り込む
分、好ましくない。そこで、取引先をＣＰＵにくくりつ
けない方法を考えると、以下の問題がある。DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention
Consider improving the notification capability by allocating a different CPU for each volume of the transaction statement accumulation file.
At this time, there is a method in which a customer is liable to a CPU, that is, one CPU to be notified to each customer is predetermined. From the viewpoint of making the constituent elements of each CPU as identical as possible when constructing a parallel system, the above-mentioned method is not preferable because the customer information element is incorporated for each CPU. Therefore, considering a method in which the customer is not attached to the CPU, there are the following problems.

【０００４】各ＣＰＵが全取引先に対する通知キューを
独自に管理するため、複数の店群に口座を所有する取引
先に対しては各ＣＰＵがばらばらに通知を行うことにな
り、通知をする側の通信効率が悪いと同時に、受け取る
取引先も労力の浪費、および紙などの資源の浪費という
点で迷惑する。Since each CPU independently manages the notification queue for all customers, each CPU separately notifies the customers who have accounts in a plurality of stores, and the notification side. At the same time as the communication efficiency is poor, the receiving customer also is annoyed by the waste of labor and the waste of resources such as paper.

【０００５】各ＣＰＵが連携することにより各取引先に
対して必ず一括通知する場合、連携によるオーバーヘッ
ドのため、緊急を要する通知が遅延する恐れがある。When the respective CPUs cooperate with each other to make a batch notification to each customer, the overhead due to the cooperation may delay an urgent notification.

【０００６】特定の店群に対する通知処理が集中した場
合、それに対応するＣＰＵに負荷が集中し、並列化によ
る処理能力の向上ができない。When the notification processing for a specific store group is concentrated, the load is concentrated on the CPU corresponding to the notification processing, and the processing capacity cannot be improved by parallelization.

【０００７】[0007]

【課題を解決するための手段】図１を用いて示す。本計
算機システムは、口座番号ごとに取引明細を蓄積する取
引明細蓄積手段１０、上記口座番号を所有する取引先に
対応するキューを挿入する通知キュー挿入手段２０、上
記キューを取り出して取引内容を取引先へ送信する取引
通知手段３０、取引先の通知承認要求メッセージを他通
知手段へ送信する取引通知承認要求手段４０、他通知手
段からの通知承認要求メッセージを受信して該当する取
引先の取引内容をまとめる取引通知連携手段５０とから
なる。The means for solving the problems will be described with reference to FIG. The computer system includes a transaction statement accumulating unit 10 for accumulating transaction details for each account number, a notification queue inserting unit 20 for inserting a queue corresponding to a customer who owns the account number, and a transaction content by taking out the queue. Transaction notification means 30 to be transmitted to the destination, transaction notification approval request means 40 to transmit the notification approval request message of the supplier to other notification means, and a notification approval request message from the other notification means to receive the transaction content of the corresponding supplier. And transaction notification cooperation means 50.

【０００８】図２を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２０
および取引通知手段３０に加えて、一括管理サーバーか
ら各通知手段へキューを振り分けるキュー振り分け手段
６０とからなる。This will be shown with reference to FIG. This computer system is
Transaction detail storage means 10 and notification queue insertion means 20 described above
In addition to the transaction notifying means 30, a queue allocating means 60 for allocating the queue from the collective management server to each notifying means.

【０００９】図３を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、取引通知承認要求手段４０、お
よび取引通知連携手段５０に加えて、取引先の契約内容
に従い他通知手段と連携するか否かを決定する契約者管
理手段７０とからなる。This will be shown with reference to FIG. This computer system is
Transaction detail storage means 10 and notification queue insertion means 2 described above
0, transaction notification means 30, transaction notification approval request means 40, and transaction notification cooperation means 50, and contractor management means 70 for determining whether or not to cooperate with other notification means according to the contract contents of the supplier. .

【００１０】図４を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、取引通知承認要求手段４０、取
引通知連携手段５０、および契約者管理手段７０に加え
て、全通知手段の通知キュー情報を保持しておく負荷平
滑手段８０とからなる。This will be shown with reference to FIG. This computer system is
Transaction detail storage means 10 and notification queue insertion means 2 described above
0, transaction notification means 30, transaction notification approval request means 40, transaction notification cooperation means 50, and contractor management means 70, as well as load smoothing means 80 for holding the notification queue information of all notification means.

【００１１】図５を用いて示す。本計算機システムは、
上記の取引明細蓄積手段１０、通知キュー挿入手段２
０、取引通知手段３０、およびキュー振り分け手段６０
に加えて、全通知手段の通知キュー情報を保持しておく
一括管理サーバー内の負荷平滑手段９０、および各通知
手段が自分の保有する通知キュー情報を管理する負荷平
滑手段１００とからなる。This will be shown with reference to FIG. This computer system is
Transaction detail storage means 10 and notification queue insertion means 2 described above
0, transaction notification means 30, and queue distribution means 60
In addition to the above, the load smoothing means 90 in the collective management server holds the notification queue information of all the notification means, and the load smoothing means 100 manages the notification queue information held by each notification means.

【００１２】[0012]

【作用】図６のフローチャートを用いて示す。まず取引
明細蓄積手段１０を用いて他システムから取得した取引
明細を口座番号順に蓄積しておく（ステップ１００
０）。通知キュー挿入手段２０は前記口座番号順の蓄積
内容を参照して取引先ごとに通知キューを作成する（ス
テップ２０００）。取引通知手段３０は前記通知キュー
が空でなければ（ステップ３０００）、先頭から１つ取
り出し（ステップ３５００）、取引先へ通知する（ステ
ップ８０００）前に、他の通知手段に前記取引先の通知
キューが存在するか否かを調べるため、取引通知承認要
求手段４０を用いて他の通知手段へ問い合わせる（ステ
ップ４０００）。すると他の通知手段における取引通知
連携手段５０がそれを受取り（ステップ５０００）、前
記取引先に対する通知の予定があれば（ステップ６００
０）、取引明細蓄積手段１０によって格納された取引内
容を前記取引通知承認要求手段４０へ転送し（ステップ
６５００）、通知キューから削除する（ステップ６７０
０）。取引通知承認要求手段４０が他の通知手段の取引
内容を受信すると（ステップ７０００）、取引通知手段
３０は、自分が保持する取引内容と合わせて、取引先へ
一括通知する（ステップ８０００）。The operation will be described with reference to the flowchart of FIG. First, the transaction details obtained from another system are accumulated in order of account numbers using the transaction detail accumulation means 10 (step 100).
0). The notification queue inserting means 20 creates a notification queue for each customer by referring to the stored contents in the order of the account numbers (step 2000). If the notification queue 30 is not empty (step 3000), the transaction notification means 30 takes out one from the beginning (step 3500) and notifies other notification means of the supplier before notifying the supplier (step 8000). In order to check whether or not the queue exists, the transaction notification approval requesting means 40 is used to make an inquiry to another notifying means (step 4000). Then, the transaction notification cooperation means 50 in the other notification means receives it (step 5000), and if there is a notification schedule to the supplier (step 600).
0), transfer the transaction contents stored by the transaction details accumulating means 10 to the transaction notification approval requesting means 40 (step 6500), and delete them from the notification queue (step 670).
0). When the transaction notification approval requesting means 40 receives the transaction contents of other notifying means (step 7000), the transaction notifying means 30 collectively notifies the trading partners together with the transaction contents held by itself (step 8000).

【００１３】図７のフローチャートを用いて示す。まず
一括管理サーバー内の取引明細蓄積手段１０を用いて他
システムから取得した取引明細を口座番号順に蓄積して
おく（ステップ１００）。一括管理サーバー内の通知キ
ュー挿入手段２０は前記口座番号順の蓄積内容を参照し
て取引先ごとに通知キューを作成する（ステップ２０
０）。キュー振り分け手段６０は前記通知キューが空で
なければ（ステップ３００）、先頭から１つずつ取り出
し（ステップ３５０）、通知手段の中から１つを選び
（ステップ４００）、前記選択された通知手段へ取引内
容を送信する（ステップ５００）。取引内容を受信した
通知手段は、取引明細蓄積手段１０を用いてその内容を
口座番号ごとに蓄積し（ステップ１０００）、さらに通
知キュー挿入手段２０を用いて取引先ごとに通知キュー
を作成する（ステップ２０００）。取引通知手段３０は
前記通知キューが空でなければ（ステップ３０００）先
頭から１つ取り出し（ステップ３５００）、取引先ごと
に一括して通知する（ステップ８０００）。This will be described with reference to the flowchart of FIG. First, the transaction details accumulating means 10 in the collective management server are used to accumulate the transaction details acquired from another system in the order of account numbers (step 100). The notification queue inserting means 20 in the collective management server creates a notification queue for each customer by referring to the stored contents in the order of the account numbers (step 20).
0). If the notification queue is not empty (step 300), the queue allocating means 60 takes out one by one from the beginning (step 350), selects one from the notification means (step 400), and sends it to the selected notification means. The transaction details are transmitted (step 500). The notification means that has received the transaction content stores the content for each account number using the transaction statement storage means 10 (step 1000), and creates a notification queue for each customer using the notification queue insertion means 20 ( Step 2000). If the notification queue 30 is not empty (step 3000), the transaction notification means 30 takes out one from the beginning (step 3500) and collectively notifies each transaction partner (step 8000).

【００１４】図８のフローチャートを用いて示す。取引
明細蓄積手段１０を用いて他システムから取得した取引
明細を口座番号順に蓄積しておき（ステップ１００
０）、通知キュー挿入手段２０を用いて前記口座番号順
の蓄積内容を参照して取引先ごとに通知キューを作成し
（ステップ２０００）、取引通知手段３０を用いて前記
通知キューが空でなければ（ステップ３０００）、先頭
から１つ取り出す（ステップ３５００）までは請求項１
における作用と同様。ここで、契約者管理手段７０を用
いて前記取引先に対する契約状況を参照し、取引発生後
即時に通知するという契約者でなければ（ステップ３７
００）、前記請求項１における作用と同様の操作を行
う。すなわち、他の通知手段に前記取引先の通知キュー
が存在するか否かを調べるため、取引通知承認要求手段
４０を用いて他の通知手段へ問い合わせ（ステップ４０
００）、他の通知手段における取引通知連携手段５０が
それを受取り（ステップ５０００）、前記取引先に対す
る通知の予定があれば（ステップ６０００）、取引明細
蓄積手段１０によって格納された取引内容を前記取引通
知承認要求手段４０へ転送し（ステップ６５００）、通
知キューから削除し（ステップ６７００）、取引通知承
認要求手段４０が他の通知手段の取引内容を受信すると
（ステップ７０００）、取引通知手段３０は、自分が保
持する取引内容と合わせて、取引先へ一括通知する（ス
テップ８０００）。一方、取引発生後即時に通知すると
いう契約者であったときには（ステップ３７００）、他
の通知手段と連携すること無く即座に取引先へ通知する
（ステップ８０００）。This will be described with reference to the flowchart of FIG. Transaction details acquired from another system using the transaction detail storage means 10 are accumulated in the order of account numbers (step 100).
0), the notification queue inserting means 20 is used to create a notification queue for each supplier by referring to the stored contents in the order of the account numbers (step 2000), and the transaction notification means 30 must be used to empty the notification queue. If (step 3000), one is taken out from the top (step 3500).
Similar to the action in. Here, the contractor management means 70 is used to refer to the contract status for the customer and the contractor is not notified immediately after the transaction occurs (step 37).
00), the same operation as the operation in claim 1 is performed. That is, in order to check whether or not the notification queue of the supplier exists in the other notification means, the transaction notification approval request means 40 is used to make an inquiry to the other notification means (step 40).
00), the transaction notification cooperation means 50 in the other notification means receives it (step 5000), and if there is a notification to the supplier (step 6000), the transaction content stored by the transaction statement accumulating means 10 is described above. When the transaction notification approval request means 40 transfers the transaction notification approval request means 40 (step 6500) and deletes it from the notification queue (step 6700) and the transaction notification approval request means 40 receives the transaction content of another notification means (step 7000), the transaction notification means 30. Together with the transaction contents held by itself, collectively notifies the trading partners (step 8000). On the other hand, when the contractor is to notify immediately after the occurrence of the transaction (step 3700), the customer is immediately notified without cooperation with other notifying means (step 8000).

【００１５】図９のフローチャートを用いて示す。まず
取引明細蓄積手段１０を用いて他システムから取得した
取引明細を口座番号順に蓄積しておく（ステップ１００
０）。通知キュー挿入手段２０は前記口座番号順の蓄積
内容を参照して取引先ごとに通知キューを作成するが
（ステップ２０００）、ここでさらに負荷平滑手段８０
を用いて通知キュー情報も生成、あるいは更新しておく
（ステップ２５００）。取引通知手段３０は前記通知キ
ューが空でなければ（ステップ３０００）、先頭から１
つ取り出し（ステップ３５００）、契約者管理手段７０
を用いて前記取引先に対する契約状況を参照し、取引発
生後即時に通知するという契約者でなければ（ステップ
３７００）、他の通知手段に前記取引先の通知キューが
存在するか否かを調べるため、取引通知承認要求手段４
０を用いて他の通知手段へ問い合わせる（ステップ４０
００）。ここでさらに、負荷平滑手段８０を用いて前記
通知キュー情報も送信しておく（ステップ４５００）。
他の通知手段における取引通知連携手段５０がそれを受
取り（ステップ５０００）、前記取引先に対する通知の
予定があれば（ステップ６０００）、取引明細蓄積手段
１０によって格納された取引内容を前記取引通知承認要
求手段４０へ転送するが（ステップ６５００）、ここで
負荷平滑手段８０により自分の保持する通知キュー情報
を考慮し、先に受信した情報と比較し、自分の負荷が高
いと判断したときは（ステップ６６００）、通知キュー
の一部とそれに対応する取引内容も転送し（６６５
０）、通知キューから削除する（ステップ６７００）。
取引通知承認要求手段４０が他の通知手段の取引内容を
受信すると（ステップ７０００）、取引通知手段３０
は、自分が保持する取引内容と合わせて、取引先へ一括
通知する（ステップ８０００）と同時に、受信した通知
キューとそれに対応する取引内容を取引明細蓄積手段１
０を用いて蓄積する（ステップ８５００）。一方、取引
発生後即時に通知するという契約者であったときには
（ステップ３７００）、他の通知手段と連携すること無
く即座に取引先へ通知する（ステップ８０００）。This will be described with reference to the flowchart of FIG. First, the transaction details obtained from another system are accumulated in order of account numbers using the transaction detail accumulation means 10 (step 100).
0). The notification queue inserting means 20 creates a notification queue for each customer by referring to the stored contents in the order of the account numbers (step 2000), and here the load smoothing means 80 is further added.
Is used to generate or update the notification queue information (step 2500). If the notification queue is not empty (step 3000), the transaction notification means 30 returns 1 from the beginning.
One (step 3500), contractor management means 70
Is used to refer to the contract status for the supplier, and if the contractor does not notify immediately after the occurrence of the transaction (step 3700), it is checked whether or not the notification queue of the supplier exists in other notification means. Therefore, transaction notification approval requesting means 4
Use 0 to query other notification means (step 40
00). Here, the notification queue information is also transmitted using the load smoothing means 80 (step 4500).
If the transaction notification cooperation means 50 in the other notification means receives it (step 5000) and there is a notification to the supplier (step 6000), the transaction content stored by the transaction statement accumulating means 10 is approved by the transaction notification. Although it is transferred to the requesting means 40 (step 6500), when the load smoothing means 80 considers the notification queue information held by itself and compares it with the previously received information, when it is judged that the own load is high ( In step 6600, a part of the notification queue and the corresponding transaction content are also transferred (665).
0), delete from the notification queue (step 6700).
When the transaction notification approval requesting means 40 receives the transaction content of another notifying means (step 7000), the transaction notifying means 30.
In addition to the transaction contents that it holds, it collectively notifies the trading partners (step 8000), and at the same time, the received notification queue and the corresponding transaction contents are stored in the transaction statement storage means 1.
Accumulate using 0 (step 8500). On the other hand, when the contractor is to notify immediately after the occurrence of the transaction (step 3700), the customer is immediately notified without cooperation with other notifying means (step 8000).

【００１６】図１０のフローチャートを用いて示す。ま
ず一括管理サーバー内の取引明細蓄積手段１０を用いて
他システムから取得した取引明細を口座番号順に蓄積し
ておく（ステップ１００）。一括管理サーバー内の通知
キュー挿入手段２０は前記口座番号順の蓄積内容を参照
して取引先ごとに通知キューを作成する（ステップ２０
０）。キュー振り分け手段６０は前記通知キューが空で
なければ（ステップ３００）、先頭から１つずつ取り出
し（ステップ３５０）、通知手段の中から１つを選び
（ステップ４００）、前記通知手段へ取引内容を送信す
る（ステップ５００）。取引内容を受信した通知手段
は、取引明細蓄積手段１０を用いてその内容を口座番号
ごとに蓄積し（ステップ１０００）、さらに通知キュー
挿入手段２０を用いて取引先ごとに通知キューを作成す
る（ステップ２０００）。ここで、負荷平滑手段１００
を用いて自分が保持する通知キュー情報を生成、あるい
は更新し（ステップ２３００）、さらに一括管理サーバ
ーへ前記情報を送信しておく（２６００）。前記情報を
受信したキュー振り分け手段６０は、負荷平滑手段９０
を用いて前記通知手段の通知キュー情報を更新し（ステ
ップ６００）、次回の選択（ステップ４００）における
判断材料とする。通知手段内の取引通知手段３０は前記
通知キューが空でなければ（ステップ３０００）、先頭
から１つ取り出し（ステップ３５００）、取引先ごとに
一括して通知し（ステップ８０００）、負荷平滑手段１
００を用いて通知キュー情報を更新する（ステップ９０
００）。This will be described with reference to the flowchart of FIG. First, the transaction details accumulating means 10 in the collective management server are used to accumulate the transaction details acquired from another system in the order of account numbers (step 100). The notification queue inserting means 20 in the collective management server creates a notification queue for each customer by referring to the stored contents in the order of the account numbers (step 20).
0). If the notification queue is not empty (step 300), the queue distribution means 60 takes out one by one from the beginning (step 350), selects one from the notification means (step 400), and sends the transaction contents to the notification means. It is transmitted (step 500). The notification means that has received the transaction content stores the content for each account number using the transaction statement storage means 10 (step 1000), and creates a notification queue for each customer using the notification queue insertion means 20 ( Step 2000). Here, the load smoothing means 100
Generate or update the notification queue information held by itself (step 2300), and further transmit the information to the collective management server (2600). Upon receiving the information, the queue distribution unit 60 receives the load smoothing unit 90.
Is used to update the notification queue information of the notification means (step 600), which is used as a basis for judgment in the next selection (step 400). If the notification queue is not empty (step 3000), the transaction notification means 30 in the notification means takes out one from the beginning (step 3500), and notifies the trading partners collectively (step 8000).
00 to update the notification queue information (step 90)
00).

【００１７】[0017]

【実施例】図６および図１１を用いて示す。図１１は本
発明の１実施例を示すプロセス構成、およびファイル構
成である。勘定系システムから取引通知ＣＰＵへ口座番
号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
取引通知プロセス３１は上記通知キューが空でなければ
（ステップ３０００）、先頭からキューを取り出し（ス
テップ３５００）、図１４に示す通知管理テーブル３２
を通知中と更新した後、他ＣＰＵの取引通知連携プロセ
ス５１へ上記取引先に対する取引通知承認要求メッセー
ジを送信する（ステップ４０００）。すると、他ＣＰＵ
の取引通知連携プロセス５１がそれを受取り（ステップ
５０００）、前記取引先に対する通知の予定があるか否
かを各自の通知キューによってチェックする。予定があ
るときは（ステップ６０００）、さらに通知管理テーブ
ル３２によって通知中か否かをチェックする。通知中で
ないときは、上記取引通知プロセス３１へ該当する取引
先の取引内容とともに取引通知承認メッセージとして送
信し（ステップ６５００）、通知キューを取り出して通
知管理テーブル３２を通知済と更新する（ステップ６７
００）。一方、通知中であるときは、上記取引通知プロ
セス３１に取引通知拒否メッセージを送信する。全ＣＰ
Ｕの取引通知連携プロセス５１から取引承認メッセージ
を受信した取引通知プロセス３１は（ステップ７００
０）、前記受信した取引内容と合わせて取引先へ一括通
知し（ステップ８０００）、通知管理テーブル３２を通
知済と更新する。取引通知拒否メッセージを１つでも受
け取った取引通知プロセス３１は、取引通知承認メッセ
ージを送信したＣＰＵ分の取引内容のみを一括通知し
（ステップ８０００）、通知管理テーブル３２を通知済
と更新する。以上の処理を繰り返し、通知キューが空に
なったところで、取引通知プロセス３１は一定時間休眠
する。休眠からさめた取引通知プロセス３１は、同様の
処理を行う。EXAMPLE An example will be described with reference to FIGS. 6 and 11. FIG. 11 shows a process configuration and a file configuration showing an embodiment of the present invention. When the transaction details 11 describing the account number and the transaction details are sent from the accounting system to the transaction notification CPU, the transaction details accumulation process 12 receives the transaction details and stores the transaction details in the form of the transaction details number and transaction details for each account number. Store in file 13 (step 1000).
Further, the customer corresponding to the above account number is obtained from the customer ID conversion table 14 shown in FIG. 12 and inserted into the notification queue of the corresponding district (step 2000). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement storage file 13.
If the notification queue is not empty (step 3000), the transaction notification process 31 takes out the queue from the beginning (step 3500), and the notification management table 32 shown in FIG.
Is updated to "notifying", a transaction notification approval request message to the transaction partner is transmitted to the transaction notification cooperation process 51 of another CPU (step 4000). Then, other CPU
The transaction notification cooperation process 51 of (1) receives it (step 5000), and checks whether or not there is a schedule for notification to the supplier by its notification queue. When there is a schedule (step 6000), it is further checked by the notification management table 32 whether or not notification is in progress. When the notification is not in progress, it is transmitted as a transaction notification approval message to the transaction notification process 31 together with the transaction details of the corresponding supplier (step 6500), the notification queue is taken out, and the notification management table 32 is updated as notified (step 67).
00). On the other hand, when notification is in progress, a transaction notification refusal message is transmitted to the transaction notification process 31. All CP
The transaction notification process 31 that received the transaction approval message from the U transaction notification cooperation process 51 (step 700
0), together with the received transaction contents, collectively notifies the trading partners (step 8000) and updates the notification management table 32 as notified. The transaction notification process 31, which has received at least one transaction notification refusal message, collectively notifies only the transaction content of the CPU that has transmitted the transaction notification approval message (step 8000), and updates the notification management table 32 as notified. When the notification queue becomes empty by repeating the above processing, the transaction notification process 31 sleeps for a certain period of time. The transaction notification process 31 awakened from dormancy performs similar processing.

【００１８】図７および図１５を用いて示す。図１５は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから一括管理サーバーＣＰ
Ｕへ口座番号および取引内容を記述した取引明細１１が
送られると、それを取引明細蓄積プロセス１２が受取
り、口座番号ごとに取引明細数および取引内容という形
式で取引明細蓄積ファイル１３へ格納する（ステップ１
００）。さらに、図１２に示す顧客ＩＤ変換テーブル１
４により上記口座番号に対応する取引先を求め、該当す
る地区の通知キューへ挿入する（ステップ２００）。上
記キューには図１３に示す通り、取引先および取引明細
蓄積ファイル１３上の格納位置という情報が保持されて
いる。キュー振り分けプロセス６１は上記通知キューが
空でなければ（ステップ３００）、先頭からキューを１
つ取り出し（ステップ３５０）、取引通知ＣＰＵ１〜ｍ
の中から１つを選択し（ステップ４００）、前記選択さ
れたＣＰＵ内の取引明細蓄積プロセス１２へ、前記通知
キューとそれに対応する取引内容を送信する（ステップ
５００）。一括管理サーバーＣＰＵから取引通知ＣＰＵ
へ口座番号および取引内容を記述した取引明細１１が送
られると、それを取引明細蓄積プロセス１２が受取り、
口座番号ごとに取引明細数および取引内容という形式で
取引明細一時蓄積ファイル１５へ格納する（ステップ１
０００）。さらに、図１２に示す顧客ＩＤ変換テーブル
１４により上記口座番号に対応する取引先を求め、該当
する地区の通知キューへ挿入する（ステップ２００
０）。上記キューには図１３に示す通り、取引先および
取引明細一時蓄積ファイル１５上の格納位置という情報
が保持されている。取引通知プロセス３１は上記通知キ
ューが空でなければ（ステップ３０００）、先頭からキ
ューを取り出し（ステップ３５００）、取引先へ通知す
る（ステップ８０００）。この場合、一括管理ＣＰＵが
各取引先に対する取引内容をまとめているので、取引通
知ＣＰＵ同志の連携は必要ない。This will be described with reference to FIGS. 7 and 15. FIG. 15 shows a process configuration and a file configuration showing an embodiment of the present invention. Accounting system to central management server CP
When the transaction statement 11 describing the account number and transaction content is sent to U, the transaction statement storage process 12 receives it and stores it in the transaction statement storage file 13 in the format of the transaction statement number and transaction content for each account number ( Step 1
00). Furthermore, the customer ID conversion table 1 shown in FIG.
The customer corresponding to the above account number is obtained by 4 and is inserted into the notification queue of the corresponding district (step 200). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement storage file 13. If the notification queue is not empty (step 300), the queue distribution process 61 sets the queue to 1 from the beginning.
One (step 350), transaction notification CPU 1 to m
One of the above is selected (step 400), and the notification queue and the corresponding transaction content are transmitted to the transaction detail accumulation process 12 in the selected CPU (step 500). Central management server CPU to transaction notification CPU
When the transaction details 11 describing the account number and transaction content are sent to the transaction details storage process 12,
Store in the transaction detail temporary storage file 15 in the form of the number of transaction details and transaction details for each account number (step 1
000). Further, the customer ID conversion table 14 shown in FIG. 12 is used to find the customer corresponding to the above account number and insert it into the notification queue of the corresponding district (step 200).
0). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement temporary storage file 15. If the notification queue is not empty (step 3000), the transaction notification process 31 takes out the queue from the beginning (step 3500) and notifies the customer (step 8000). In this case, since the collective management CPU summarizes the transaction contents for each customer, the transaction notification CPUs need not cooperate with each other.

【００１９】図８および図１６を用いて示す。図１６は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから取引通知ＣＰＵへ口座
番号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
取引通知プロセス３１は上記通知キューが空でなければ
（ステップ３０００）、先頭からキューを取り出す（ス
テップ３５００）。ここで、図１７に示す契約管理テー
ブル７１を参照し、前記キューに対応する取引先に対す
る契約が取引発生後即時に通知という契約であれば（ス
テップ３７００）、取引先へ通知する（ステップ８００
０）。上記以外の契約であれば、図１４に示す通知管理
テーブル３２を通知中と更新した後、他ＣＰＵの取引通
知連携プロセス５１へ上記取引先に対する取引通知承認
要求メッセージを送信する（ステップ４０００）。する
と、他ＣＰＵの取引通知連携プロセス５１がそれを受取
り（ステップ５０００）、前記取引先に対する通知の予
定があるか否かを各自の通知キューによってチェックす
る。予定があるときは（ステップ６０００）、さらに通
知管理テーブル３２によって通知中か否かをチェックす
る。通知中でないときは、上記取引通知プロセス３１へ
該当する取引先の取引内容とともに取引通知承認メッセ
ージとして送信し（ステップ６５００）、通知キューを
取り出して通知管理テーブル３２を通知済と更新する
（ステップ６７００）。一方、通知中であるときは、上
記取引通知プロセス３１に取引通知拒否メッセージを送
信する。全ＣＰＵの取引通知連携プロセス５１から取引
承認メッセージを受信した取引通知プロセス３１は（ス
テップ７０００）、前記受信した取引内容と合わせて取
引先へ一括通知し（ステップ８０００）、通知管理テー
ブルを通知済と更新する。取引通知拒否メッセージを１
つでも受け取った取引通知プロセス３１は、取引通知承
認メッセージを送信したＣＰＵ分の取引内容のみを一括
通知し（ステップ８０００）、通知管理テーブル３２を
通知済と更新する。以上の処理を繰り返し、通知キュー
が空になったところで、取引通知プロセス３１は一定時
間休眠する。休眠からさめた取引通知プロセス３１は、
同様の処理を行う。This will be described with reference to FIGS. 8 and 16. FIG. 16 shows a process configuration and a file configuration showing an embodiment of the present invention. When the transaction details 11 describing the account number and the transaction details are sent from the accounting system to the transaction notification CPU, the transaction details accumulation process 12 receives the transaction details and stores the transaction details in the form of the transaction details number and transaction details for each account number. Store in file 13 (step 1000).
Further, the customer corresponding to the above account number is obtained from the customer ID conversion table 14 shown in FIG. 12 and inserted into the notification queue of the corresponding district (step 2000). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement storage file 13.
If the notification queue is not empty (step 3000), the transaction notification process 31 takes out the queue from the beginning (step 3500). Here, referring to the contract management table 71 shown in FIG. 17, if the contract corresponding to the customer corresponding to the queue is a notification immediately after a transaction occurs (step 3700), the customer is notified (step 800).
0). If the contract is other than the above, the notification management table 32 shown in FIG. 14 is updated to "notifying", and then a transaction notification approval request message to the transaction partner is transmitted to the transaction notification cooperation process 51 of another CPU (step 4000). Then, the transaction notification cooperation process 51 of the other CPU receives it (step 5000), and checks whether or not there is a notification schedule for the customer with its notification queue. When there is a schedule (step 6000), it is further checked by the notification management table 32 whether or not notification is in progress. When the notification is not in progress, it is sent to the transaction notification process 31 as a transaction notification approval message together with the transaction contents of the corresponding supplier (step 6500), the notification queue is taken out, and the notification management table 32 is updated as notified (step 6700). ). On the other hand, when notification is in progress, a transaction notification refusal message is transmitted to the transaction notification process 31. The transaction notification process 31 that has received the transaction approval message from the transaction notification cooperation process 51 of all the CPUs (step 7000) collectively notifies the business partners together with the received transaction content (step 8000) and has notified the notification management table. And update. Transaction notification rejection message 1
The transaction notification process 31 that has received at least one notification collectively notifies only the transaction content of the CPU that has transmitted the transaction notification approval message (step 8000), and updates the notification management table 32 as notified. When the notification queue becomes empty by repeating the above processing, the transaction notification process 31 sleeps for a certain period of time. The transaction notification process 31 awakened from sleep
Perform similar processing.

【００２０】図９および図１８を用いて示す。図１８は
本発明の１実施例を示すプロセス構成、およびファイル
構成である。勘定系システムから取引通知ＣＰＵへ口座
番号および取引内容を記述した取引明細１１が送られる
と、それを取引明細蓄積プロセス１２が受取り、口座番
号ごとに取引明細数および取引内容という形式で取引明
細蓄積ファイル１３へ格納する（ステップ１０００）。
さらに、図１２に示す顧客ＩＤ変換テーブル１４により
上記口座番号に対応する取引先を求め、該当する地区の
通知キューへ挿入する（ステップ２０００）。上記キュ
ーには図１３に示す通り、取引先および取引明細蓄積フ
ァイル１３上の格納位置という情報が保持されている。
また、このとき自ＣＰＵが保有する通知キュー数をメモ
リ上にセットしておく。取引通知プロセス３１は上記通
知キューが空でなければ（ステップ３０００）、先頭か
らキューを取り出す（ステップ３５００）。ここで、図
１７に示す契約管理テーブル７１を参照し、前記キュー
に対応する取引先に対する契約が取引発生後即時に通知
という契約であれば（ステップ３７００）、取引先へ通
知する（ステップ８０００）。上記以外の契約であれ
ば、図１４に示す通知管理テーブル３２を通知中と更新
した後、他ＣＰＵの取引通知連携プロセス５１へ上記取
引先に対する取引通知承認要求メッセージを送信し（ス
テップ４０００）、さらに前記メモリ上にセットしてい
た通知キュー数を送信する（ステップ４５００）。する
と、他ＣＰＵの取引通知連携プロセス５１がそれを受取
り（ステップ５０００）、前記取引先に対する通知の予
定があるか否かを各自の通知キューによってチェックす
る。予定があるときは（ステップ６０００）、さらに通
知管理テーブル３２によって通知中か否かをチェックす
る。通知中でないときは、上記取引通知プロセス３１へ
該当する取引先の取引内容とともに取引通知承認メッセ
ージとして取引通知プロセスへ送信した後（ステップ６
５００）、前記受信した通知キュー数と自ＣＰＵ内のメ
モリ上にセットしてある通知キュー数を比較し、自ＣＰ
Ｕ内の通知キュー数が多ければ（ステップ６６００）、
その差のｎ分の１の通知キューとそれに対応する取引内
容を、取引明細蓄積プロセス１２へ送信する（ステップ
６６５０）。ただし、ｎは並列数（ここでは取引通知Ｃ
ＰＵ数）のことである。そして、前記通知キューを取り
出して通知管理テーブルを通知済と更新し、通知キュー
数もその分減らしておく（ステップ６７００）。一方、
通知中であるときは、上記取引通知プロセス３１に取引
通知拒否メッセージを送信する。全ＣＰＵの取引通知連
携プロセス５１から取引承認メッセージを受信した取引
通知プロセス３１は（ステップ７０００）、前記受信し
た取引内容と合わせて取引先へ一括通知し、メモリ上の
通知キュー数を１減らし、通知管理テーブル３２を通知
済と更新する（ステップ８０００）。取引通知拒否メッ
セージを１つでも受け取った取引通知プロセス３１は、
取引通知承認メッセージを送信したＣＰＵ分の取引内容
のみを一括通知し（ステップ８０００）、通知管理テー
ブル３２を通知済と更新する。また、他ＣＰＵから送信
された通知キューとそれに対応する取引内容を受信した
取引明細蓄積プロセス１２は、口座番号ごとに取引明細
数および取引内容という形式で取引明細蓄積ファイル１
３へ格納し、通知キュー数をその分増やしておく（ステ
ップ８５００）。以上の処理を繰り返し、通知キューが
空になったところで、取引通知プロセス３１は一定時間
休眠する。休眠からさめた取引通知プロセス３１は、同
様の処理を行う。This will be described with reference to FIGS. 9 and 18. FIG. 18 shows a process configuration and a file configuration showing an embodiment of the present invention. When the transaction details 11 describing the account number and the transaction details are sent from the accounting system to the transaction notification CPU, the transaction details accumulation process 12 receives the transaction details and stores the transaction details in the form of the transaction details number and transaction details for each account number. Store in file 13 (step 1000).
Further, the customer corresponding to the above account number is obtained from the customer ID conversion table 14 shown in FIG. 12 and inserted into the notification queue of the corresponding district (step 2000). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement storage file 13.
At this time, the number of notification queues held by the own CPU is set in the memory. If the notification queue is not empty (step 3000), the transaction notification process 31 takes out the queue from the beginning (step 3500). Here, referring to the contract management table 71 shown in FIG. 17, if the contract corresponding to the customer corresponding to the queue is a notification immediately after a transaction occurs (step 3700), the customer is notified (step 8000). . If the contract is other than the above, the notification management table 32 shown in FIG. 14 is updated to "notifying", and then a transaction notification approval request message to the transaction partner is transmitted to the transaction notification cooperation process 51 of the other CPU (step 4000). Further, the number of notification queues set in the memory is transmitted (step 4500). Then, the transaction notification cooperation process 51 of the other CPU receives it (step 5000), and checks whether or not there is a notification schedule for the customer with its notification queue. When there is a schedule (step 6000), it is further checked by the notification management table 32 whether or not notification is in progress. If the notification is not in progress, after sending to the transaction notification process 31 as a transaction notification approval message together with the transaction details of the corresponding customer (step 6).
500), comparing the received number of notification queues with the number of notification queues set in the memory of the own CPU, and
If the number of notification queues in U is large (step 6600),
The notification queue of 1 / n of the difference and the corresponding transaction content are transmitted to the transaction details accumulation process 12 (step 6650). However, n is the parallel number (here, transaction notification C
The number of PUs). Then, the notification queue is taken out and the notification management table is updated as notified, and the number of notification queues is also reduced accordingly (step 6700). on the other hand,
When notification is in progress, a transaction notification refusal message is transmitted to the transaction notification process 31. The transaction notification process 31 that has received the transaction approval message from the transaction notification cooperation process 51 of all the CPUs (step 7000) collectively notifies the trading partners together with the received transaction contents, and reduces the number of notification queues on the memory by 1. The notification management table 32 is updated as notified (step 8000). The transaction notification process 31, which has received at least one transaction notification refusal message,
Only the transaction content for the CPU that has transmitted the transaction notification approval message is collectively notified (step 8000), and the notification management table 32 is updated as notified. Further, the transaction statement accumulating process 12 that has received the notification queue transmitted from another CPU and the transaction details corresponding to the notification queue stores the transaction statement accumulation file 1 in the form of the transaction statement number and transaction statement for each account number.
3, and the number of notification queues is increased by that amount (step 8500). When the notification queue becomes empty by repeating the above processing, the transaction notification process 31 sleeps for a certain period of time. The transaction notification process 31 awakened from dormancy performs similar processing.

【００２１】図１０および図１９を用いて示す。図１９
は本発明の１実施例を示すプロセス構成、およびファイ
ル構成である。勘定系システムから一括管理サーバーＣ
ＰＵへ口座番号および取引内容を記述した取引明細１１
が送られると、それを取引明細蓄積プロセス１２が受取
り、口座番号ごとに取引明細数および取引内容という形
式で取引明細蓄積ファイル１３へ格納する（ステップ１
００）。さらに、図１２に示す顧客ＩＤ変換テーブル１
４により上記口座番号に対応する取引先を求め、該当す
る地区の通知キューへ挿入する（ステップ２００）。上
記キューには図１３に示す通り、取引先および取引明細
蓄積ファイル１３上の格納位置という情報が保持されて
いる。キュー振り分けプロセス６１は上記通知キューが
空でなければ（ステップ３００）、先頭からキューを取
り出し（ステップ３５０）、取引通知ＣＰＵ１〜ｍの中
から１つを選択し（ステップ４００）、前記ＣＰＵ内の
取引明細蓄積プロセス１２へ、前記通知キューとそれに
対応する取引内容を送信する（ステップ５００）。一括
管理サーバーＣＰＵから取引通知ＣＰＵへ口座番号およ
び取引内容を記述した取引明細１１が送られると、それ
を取引明細蓄積プロセス１２が受取り、口座番号ごとに
取引明細数および取引内容という形式で取引明細一時蓄
積ファイル１５へ格納する（ステップ１０００）。さら
に、図１２に示す顧客ＩＤ変換テーブル１４により上記
口座番号に対応する取引先を求め、該当する地区の通知
キューへ挿入する（ステップ２０００）。上記キューに
は図１３に示す通り、取引先および取引明細一時蓄積フ
ァイル１５上の格納位置という情報が保持されている。
また、このとき通知キュー数をメモリ上にセットし、前
記キュー振り分けプロセス６１へ送信しておく（ステッ
プ２６００）。取引通知プロセス３１は上記通知キュー
が空でなければ（ステップ３０００）、先頭からキュー
を取り出し（ステップ３５００）、取引先へ通知した後
（ステップ８０００）、通知キュー数を１減らす（ステ
ップ９０００）。前記通知キュー数を受信したキュー振
り分けプロセス６１は、送信元ＣＰＵの通知キュー数を
メモリにセットしておく。以上の処理を通知キューが空
になるまで繰り返すが、全取引通知ＣＰＵから１つ選択
するとき（ステップ４００）、最も通知キュー数の多い
ＣＰＵを選択することにより、取引通知ＣＰＵ間の負荷
を平滑化できる。This will be described with reference to FIGS. 10 and 19. FIG.
Are a process configuration and a file configuration showing an embodiment of the present invention. Accounting system to centralized management server C
Transaction details 11 describing account number and transaction details on PU
Is sent to the transaction statement accumulation process 12 and stored in the transaction statement accumulation file 13 in the form of the transaction statement number and transaction content for each account number (step 1).
00). Furthermore, the customer ID conversion table 1 shown in FIG.
The customer corresponding to the above account number is obtained by 4 and is inserted into the notification queue of the corresponding district (step 200). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement storage file 13. If the notification queue is not empty (step 300), the queue distribution process 61 takes out the queue from the beginning (step 350), selects one of the transaction notification CPUs 1 to m (step 400), and stores it in the CPU. The notification queue and the corresponding transaction content are transmitted to the transaction details accumulation process 12 (step 500). When the transaction details 11 describing the account number and the transaction details are sent from the collective management server CPU to the transaction notification CPU, the transaction details accumulation process 12 receives the transaction details 11 and the transaction details in the form of the transaction details number and transaction details for each account number. It is stored in the temporary storage file 15 (step 1000). Further, the customer corresponding to the above account number is obtained from the customer ID conversion table 14 shown in FIG. 12 and inserted into the notification queue of the corresponding district (step 2000). As shown in FIG. 13, the queue holds information on the supplier and the storage position on the transaction statement temporary storage file 15.
At this time, the number of notification queues is set in the memory and sent to the queue distribution process 61 (step 2600). If the notification queue is not empty (step 3000), the transaction notification process 31 takes out the queue from the beginning (step 3500), notifies the customer (step 8000), and then reduces the number of notification queues by 1 (step 9000). Upon receiving the notification queue number, the queue distribution process 61 sets the notification CPU number of the transmission source CPU in the memory. The above process is repeated until the notification queue becomes empty. When selecting one from all transaction notification CPUs (step 400), the CPU with the largest number of notification queues is selected to smooth the load between transaction notification CPUs. Can be converted.

【００２２】[0022]

【発明の効果】口座番号ごとに取引明細を蓄積した取引
明細蓄積ファイルの店群という切り口で通知処理を並列
化したとき、複数の店群に口座をもつ取引先への通知が
少しずつ頻繁に行われることを防ぐことができ、効率的
な通信ができると同時に、通知を受け取る取引先の労力
や資源の浪費を防ぐことができる。[Effects of the Invention] When the notification processing is parallelized at the section of the store group of the transaction detail storage file in which the transaction details are stored for each account number, the notifications to the business partners who have accounts in a plurality of store groups are frequently and little by little. It is possible to prevent the communication from being performed and to perform efficient communication, and at the same time, prevent the labor and resources of the business partner receiving the notification from being wasted.

【００２３】請求項１および２の効果に加えて、取引先
の契約形態に応じた取引通知処理を行うことにより、緊
急を要する通知の遅延を防ぐことができる。In addition to the effects of claims 1 and 2, by performing the transaction notification processing according to the contract form of the supplier, it is possible to prevent the delay of the notification that requires an emergency.

【００２４】ＣＰＵ間の負荷を平滑化することにより、
特定店群に口座を持つ取引先に対する通知の遅延を防ぐ
ことが出来る。By smoothing the load between the CPUs,
It is possible to prevent delays in notifications to business partners who have accounts in specific stores.

【図面の簡単な説明】[Brief description of drawings]

【図１】計算機システム構成図である。FIG. 1 is a computer system configuration diagram.

【図２】計算機システム構成図である。FIG. 2 is a computer system configuration diagram.

【図３】計算機システム構成図である。FIG. 3 is a computer system configuration diagram.

【図４】計算機システム構成図である。FIG. 4 is a computer system configuration diagram.

【図５】計算機システム構成図である。FIG. 5 is a computer system configuration diagram.

【図６】作用を示すフローチャートである。FIG. 6 is a flowchart showing an operation.

【図７】作用を示すフローチャートである。FIG. 7 is a flowchart showing an operation.

【図８】作用を示すフローチャートである。FIG. 8 is a flowchart showing an operation.

【図９】作用を示すフローチャートである。FIG. 9 is a flowchart showing an operation.

【図１０】作用を示すフローチャートである。FIG. 10 is a flowchart showing an operation.

【図１１】１実施例を示すファイル構成およびプロセス
構成である。FIG. 11 is a file structure and a process structure showing an embodiment.

【図１２】顧客ＩＤ変換テーブルのフォーマットであ
る。FIG. 12 is a format of a customer ID conversion table.

【図１３】通知キューのフォーマットである。FIG. 13 is a format of a notification queue.

【図１４】通知管理テーブルのフォーマットである。FIG. 14 is a format of a notification management table.

【図１５】１実施例を示すファイル構成およびプロセス
構成である。FIG. 15 is a file structure and process structure showing an embodiment.

【図１６】１実施例を示すファイル構成およびプロセス
構成である。FIG. 16 is a file structure and process structure showing an embodiment.

【図１７】契約管理テーブルのフォーマットである。FIG. 17 is a format of a contract management table.

【図１８】１実施例を示すファイル構成およびプロセス
構成である。FIG. 18 is a file configuration and process configuration showing an embodiment.

【図１９】１実施例を示すファイル構成およびプロセス
構成である。FIG. 19 is a file structure and process structure showing an embodiment.

【符号の説明】[Explanation of symbols]

１０…取引明細蓄積手段、 １１…取引明細、
１２…取引明細蓄積プロセス、 １３…取引明細蓄
積ファイル、１４…顧客ＩＤ変換テーブル、 １５
…取引明細一時蓄積ファイル、２０…通知キュー挿入手
段、 ３０…取引通知手段、３１…取引通知プロ
セス、 ３２…通知管理テーブル、４０…取引
通知承認要求手段、 ５０…取引通知連携手段、５
１…取引通知連携プロセス、 ６０…キュー振り分
け手段、６１…キュー振り分けプロセス、 ７０…契
約者管理手段、７１…契約管理テーブル、 ８
０…負荷平滑手段、９０…負荷平滑手段、
１００…負荷平滑手段。10 ... Transaction details storage means, 11 ... Transaction details,
12 ... Transaction details accumulation process, 13 ... Transaction details accumulation file, 14 ... Customer ID conversion table, 15
... transaction detail temporary storage file, 20 ... notification queue insertion means, 30 ... transaction notification means, 31 ... transaction notification process, 32 ... notification management table, 40 ... transaction notification approval request means, 50 ... transaction notification cooperation means, 5
1 ... Transaction notification cooperation process, 60 ... Queue distribution means, 61 ... Queue distribution process, 70 ... Contractor management means, 71 ... Contract management table, 8
0 ... load smoothing means, 90 ... load smoothing means,
100 ... Load smoothing means.

───────────────────────────────────────────────────── フロントページの続き (72)発明者 下山 高寿 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報システム事業部内 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Takatoshi Shimoyama 12 Hitachi, Ltd. Information Systems Division, 890 Kashimada, Saiwai-ku, Kawasaki-shi, Kanagawa

Claims (5)

【特許請求の範囲】[Claims] 【請求項１】口座番号ごとに取引明細を蓄積した取引明
細蓄積ファイルと、その取引内容を一定時間間隔で取引
先ごとに通知する手段とからなる計算機システムにおい
て、取引明細蓄積ファイルの店群ごとに通知手段を設け
ることにより通知処理を並列化する際、複数の店群にま
たがって口座を所有する取引先に対しては、上記通知手
段同士が連携することにより、一括して通知することを
特徴とする分散システムにおける通知方式。1. A computer system comprising a transaction statement storage file in which transaction details are stored for each account number, and means for notifying the transaction details to each customer at fixed time intervals, for each store group of transaction statement storage files. When the notification processing is parallelized by providing the notification means in the above, it is possible to collectively notify the business partners who have an account across a plurality of stores by the cooperation of the notification means. Notification method for distributed systems. 【請求項２】口座番号ごとに取引明細を蓄積した取引明
細蓄積ファイルと、その取引内容を一定時間間隔で取引
先ごとに通知する手段とからなる計算機システムにおい
て、取引明細蓄積ファイルの店群ごとに通知手段を設け
ることにより通知処理を並列化する際、取引明細蓄積フ
ァイルおよび通知キューを一括管理するサーバーを設け
て通知手段への通知キューの振り分けを行うことによ
り、複数の店群にまたがって口座を所有する取引先に対
して一括通知することを特徴とする分散システムにおけ
る通知方式。2. A computer system comprising a transaction statement storage file in which transaction details are stored for each account number, and means for notifying the transaction details to each supplier at fixed time intervals, for each store group of transaction statement storage files. When the notification processing is parallelized by providing the notification means in the, the server that collectively manages the transaction statement accumulation file and the notification queue is provided, and the notification queue is distributed to the notification means, so that it is spread over a plurality of stores. A notification method in a distributed system characterized by making a collective notification to business partners who own an account. 【請求項３】請求項１記載の計算機システムにおいて、
取引発生後即時に通知するという契約をしている取引先
に対しては、前記通知手段間の連携を行わないことによ
り、通知に時間のかかることを防ぐことを特徴とする分
散システムにおける通知方式。3. The computer system according to claim 1,
A notification method in a distributed system characterized by preventing the notification from taking a long time by not coordinating the notification means with respect to a customer who has a contract to notify immediately after a transaction occurs. . 【請求項４】請求項３記載の計算機システムにおいて通
知手段同志が連携する際、相手方通知手段の保有する通
知キュー情報を取得しておき、相手方通知手段の負荷が
軽いと判断したときには通知キューとそれに対応する取
引内容を相手方通知手段へ移動することにより、通知手
段間の負荷を平滑化することを特徴とする分散システム
の通知方式。4. In the computer system according to claim 3, when the notification means cooperate with each other, the notification queue information held by the other party notification means is acquired, and when it is determined that the load of the other party notification means is light, the notification queue becomes the notification queue. A notification method for a distributed system, characterized in that the load between notification means is smoothed by moving the corresponding transaction content to the notification means of the other party. 【請求項５】請求項２記載の計算機システムにおいて一
括管理サーバーが通知手段へ通知キューを振り分ける
際、各通知手段の保有する通知キュー情報を取得してお
き、負荷が軽いと判断された通知手段へ優先的に通知キ
ューを振り分けることにより、通知手段間の負荷を平滑
化することを特徴とする分散システムの通知方式。5. In the computer system according to claim 2, when the batch management server distributes the notification queue to the notification means, the notification queue information held by each notification means is acquired in advance, and the notification means is determined to have a light load. A notification method for a distributed system, characterized in that the load between notification means is smoothed by preferentially allocating notification queues.
JP24908194A 1994-10-14 1994-10-14 Information system in distributed system Pending JPH08115373A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP24908194A JPH08115373A (en) 1994-10-14 1994-10-14 Information system in distributed system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP24908194A JPH08115373A (en) 1994-10-14 1994-10-14 Information system in distributed system

Publications (1)

Publication Number Publication Date
JPH08115373A true JPH08115373A (en) 1996-05-07

Family

ID=17187723

Family Applications (1)

Application Number Title Priority Date Filing Date
JP24908194A Pending JPH08115373A (en) 1994-10-14 1994-10-14 Information system in distributed system

Country Status (1)

Country Link
JP (1) JPH08115373A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1049579A (en) * 1996-07-31 1998-02-20 Mitsubishi Electric Corp Vacarious work execution system
JP2011527057A (en) * 2008-07-04 2011-10-20 アリババ グループ ホールディング リミテッド Buffered bookkeeping

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1049579A (en) * 1996-07-31 1998-02-20 Mitsubishi Electric Corp Vacarious work execution system
JP2011527057A (en) * 2008-07-04 2011-10-20 アリババ グループ ホールディング リミテッド Buffered bookkeeping

Similar Documents

Publication Publication Date Title
JP4294879B2 (en) Transaction processing system having service level control mechanism and program therefor
JP3818655B2 (en) Task scheduling method, system, and program product
US7895231B2 (en) Queuing model for a plurality of servers
CN102299959B (en) Load balance realizing method of database cluster system and device
US6336143B1 (en) Method and apparatus for multimedia data interchange with pacing capability in a distributed data processing system
EP0568002B1 (en) Distribution of communications connections over multiple service access points in a communications network
US7155438B2 (en) High availability for event forwarding
US8024744B2 (en) Method and system for off-loading user queries to a task manager
US10133797B1 (en) Distributed heterogeneous system for data warehouse management
CN109582447B (en) Computing resource allocation method, task processing method and device
US8954994B2 (en) System and method for message service with unit-of-order
CN102567086A (en) Task scheduling method, equipment and system
CN104079630A (en) Business server side load balancing method, client side, server side and system
CN104040485A (en) PAAS hierarchial scheduling and auto-scaling
CN104040486A (en) Decoupling PAAS resources, jobs, and scheduling
CN1606301A (en) A resource access shared scheduling and controlling method and apparatus
WO2008142705A2 (en) A method and system for load balancing in a distributed computer system
CN102025652B (en) Service bus and message processing method
CN109309646A (en) A kind of multi-media transcoding method and system
JPH08115373A (en) Information system in distributed system
CN113687962A (en) Request processing method, device, equipment and storage medium
JP6503035B1 (en) File processing support system, file processing support method and file processing support program
JP3907641B2 (en) Server system
CN112291320A (en) Distributed two-layer scheduling method and system for quantum computer cluster
JPH07282011A (en) Distributed transaction processing system