JP2000250856A - Computer network and reporting method for transaction data - Google Patents

Abstract

PROBLEM TO BE SOLVED: To report transaction data in real time to a transaction module in a system on the reception side of a message without integrating a method for receiving the message in the system itself on the reception side of this message when transmitting the transaction data by transmitting the message from a system where a transaction occurs on a computer network. SOLUTION: In a reception side system 1, an inbound adapter 2 monitors the reception of a message in a reception queue 3 while utilizing a message broker application interface (MB-API) 4 and acquires a transaction type, an element type and transaction data from that message and after the format of these transaction data is transformed corresponding to that element type, these data are reported to transaction modules 5(1)-5(n) corresponding to that transaction type.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a computer network, and more particularly, to a computer network having a feature in notifying a transaction module in a system of transaction data. The present invention also relates to a method of notifying a transaction module to a transaction module in a system of a computer network.

[0002]

2. Description of the Related Art In a network architecture of a computer network, a communication protocol used when communication entities such as individual computers and terminals connected by communication lines (this communication entity is referred to as a system in this specification) communicate with each other. It is necessary to specify a protocol that is This protocol is basically defined by being hierarchized into an upper layer relating to communication processing between systems and a lower layer relating to data transfer on a communication line.

The upper layer and the lower layer each include a plurality of layers, and one of the upper layers is an application layer. The application layer plays a role of providing a service required for a plurality of systems in a computer network to process a series of tasks while communicating with each other, and one of the services is transaction processing.

[0004] Transaction processing involves data output and database maintenance required in response to the occurrence of a transaction (an event that changes the contents of a data file in data processing) in any system in a computer network. And so on.

In a conventional computer network, this transaction processing is performed, for example, by an application system (a system that executes application software) by using various types of E that are commercially available business applications.
RP (EnterpriseResource Pla)
(nning) package.

[0006] In this ERP package, a plurality of transaction modules corresponding to transaction types for identifying transactions are provided, and each transaction module performs transaction processing accompanying the occurrence of a transaction of the corresponding transaction type. .

When a transaction occurs in any system in a computer network, this transaction processing is performed not only in the system in which the transaction occurred but also in another system related to the transaction in the computer network. It must be made.

For this purpose, it is necessary to transmit transaction data (data used to change the contents of a data file in response to the occurrence of a transaction) from the system where the transaction has occurred to another system. . The other system needs to receive the transaction data and notify the transaction module corresponding to the transaction type.

FIG. 15 shows how transaction data is transmitted and received and a transaction module in the receiving system is notified in the conventional transaction processing using the ERP package. When the transaction occurs, the transmission-side application system (the application system in which the transaction occurred) 51 converts the transaction data of the transaction into a format that can be interfaced with the reception-side application system. A file 53, which is a set of transaction data, is created.

Then, at regular time intervals, the file 53 is transferred to the receiving application system 52 (a system to which transaction data is transmitted from the system 51 among other application systems in the computer network). .

Application system 52 on the receiving side
Receives the file 53 collectively at regular time intervals. Then, the file 53 is divided in units of transaction types, and distributed to corresponding transaction modules among a plurality of transaction modules 54 (1) to 54 (n) provided by the ERP package used in the system 52 ( Alternatively, the transaction data of each transaction type read from the file 53 is distributed to the corresponding transaction module.)
This notifies the corresponding transaction module of the transaction data.

[0012]

As described above, conventionally,
Transmission and reception of transaction data have been performed at once at predetermined time intervals in the form of file transfer. Therefore, every time an individual transaction occurs in the transmitting system, the transaction data of the transaction is not immediately received by the receiving system and notified to the corresponding transaction module in the system, and therefore, the receiving transaction module is not notified. Notification of transaction data to the transaction module in the system lacked real-time properties.

[0013] Further, instead of such a file transfer form, for example, every time a transaction occurs, a transaction type or an element type for identifying each element which is a constituent element of the transaction is transmitted from the transmission side system. Alternatively, a message including transaction data corresponding to each element type may be transmitted, and the receiving system may receive the message.

However, conventionally, in order to transmit and receive transaction data in real time by transmitting and receiving messages, the system itself requires, for example, M
It is necessary to incorporate a method of transmitting and receiving a message using an API (application interface) of the Q series or the like, which is complicated and complicates the system itself.

Conventionally, when a failure has occurred in the receiving system during the process of receiving and notifying such a message, it has not been possible to analyze or recover the failure.

Accordingly, an object of the present invention is to provide a method of receiving a message to a receiving system itself when a message including such transaction type, element type, and transaction data is transmitted from the transmitting system. Without incorporation, it is possible to notify the transaction module in the receiving system of transaction data in real time,
It is an object of the present invention to provide a computer network and a method of notifying transaction data that can analyze and recover from a failure in a receiving system in the process of receiving and notifying the message.

[0017]

SUMMARY OF THE INVENTION To solve this problem, the applicant assigns at least one system to receive transaction data in a computer network comprising a plurality of systems. As a system on the side, the message broker is used to monitor the reception of a message in the reception queue, obtain a transaction type from the message received in the reception queue, and, among a plurality of transaction modules in the system, We propose a transaction module corresponding to the transaction type that has an inbound adapter that notifies the transaction data obtained from the message.

In this computer network, in a system including the inbound adapter as a receiving system, the inbound adapter monitors the reception of a message in a reception queue using a message broker. When a message including the transaction type, the element type, and the transaction data as described above is transmitted from the transmitting system to the receiving system and received in the receiving queue, the inbound adapter uses the message.
The transaction type is immediately obtained from the message, and the transaction data corresponding to the transaction type is notified of the transaction data obtained from the message to the transaction module corresponding to the transaction type among the plurality of transaction modules in the receiving side system.

As a result, the transaction data is notified to the corresponding transaction module in the receiving system almost simultaneously with the transmission of the message from the transmitting system. Notification of transaction data is performed in real time.

As described above, according to this computer network, the message receiving method is absorbed by the message broker, so that the message receiving method is not incorporated in the receiving system itself as in the related art. Transaction data can be notified to the transaction module in the system in real time.

Here, the inbound adapter receives a message using a message broker. As is well known, a message broker is a subsystem for providing a message creation and transmission / reception function to an application system in a computer network, and for centrally managing transmission / reception of a message between application systems.

Since there are various types of commercially available middleware products for constructing a message broker, which provide a message receiving function, the message broker itself used in the computer network according to the present invention includes, for example, such a middleware product. It is possible to construct using. (For a description of the basics of a message broker, see, for example, Gartner Grou.
"JITS (Japan Inf
operation Technology Strat
egies) Research Note 』199
October 31, 1996, November 30, 1996, 19
It is published in the December 20, 1996 issue and the like. )

In the computer network according to the first aspect, for example, the inbound adapter acquires the element type and the transaction data from the message received by the reception queue as described in the second aspect, and executes the transaction. After format conversion of data according to its element type,
It is preferable that the notification is made to the transaction module corresponding to the transaction type of the message among the plurality of transaction modules.

According to a second aspect of the present invention, in the computer network, the inbound adapter may include a plurality of first modules corresponding to the transaction type and a plurality of first modules corresponding to the transaction type. Using a corresponding plurality of second modules and a message broker, monitor reception of a message in the reception queue, obtain a transaction type from the message received in the reception queue, and, among the plurality of first modules, A dispatcher for calling a module corresponding to the transaction type. The first module called from the dispatcher obtains the element type and the transaction data from the message received in the reception queue, and obtains a plurality of second data. Module Out of the plurality of transaction modules after the second module called from the first module converts the format of the transaction data according to the element type. It is preferable to notify the transaction module corresponding to the transaction type of the message.

In the computer network according to the second or third aspect, the inbound adapter (the second module in the third aspect) has, for example, the same element type as in the fourth aspect. It is more preferable to collectively convert a plurality of transaction data.

As a result, the format conversion of the transaction data included in the message transmitted from the transmitting side system is efficiently performed, and the notification of the transaction data to the transaction module is further speeded up. Become.

[0027] In the computer network according to any one of claims 1 to 4, the inbound adapter may include:
As an example, log information about a message received in a receiving queue is recorded as described in claim 5, and
It is preferable that the message sending system be notified of an error relating to the message.

More specifically, in the computer network according to any one of claims 1 to 4, when the transaction type obtained from the message received in the reception queue is indistinguishable, When at least one of the case where the content of the transaction data obtained from the message is incorrect, an error notification message is transmitted to the transmitting system, and the same information as the error notification message is logged. Is preferably recorded as
Further, in the computer network according to any one of claims 2 to 4 or 6, when the element type obtained from the message received in the reception queue is not identifiable as described in claim 7, the system on the transmission side is notified. It is preferable that an error notification message is transmitted, and that the same information as the error notification message is recorded as log information.

Thus, even if a failure occurs in the receiving system during the process of receiving and notifying a message, it is possible to analyze and recover the failure using the error notification message and the log information. become.

Next, in the computer network including a plurality of systems, the applicant notifies the transaction data receiving system of the transaction data to the transaction module in the system. A first step of using a message broker to monitor the reception of a message in a reception queue and obtaining a transaction type for identifying a transaction from the message received in the reception queue; Of the multiple transaction modules of the transaction module corresponding to the transaction type,
And a second step of notifying the transaction data obtained from the message.

In the transaction data notification method, the reception side system monitors the reception of a message in the reception queue using a message broker as a first step. Then, a message including the transaction type, the element type, and the transaction data as described above is transmitted from the transmitting system, and when the message is received in the receiving queue, the receiving system immediately performs the second step as a second step. A transaction type is acquired from the message, and transaction data acquired from the message is notified to a transaction module corresponding to the transaction type among a plurality of transaction modules in the receiving side system.

As a result, the transaction data is notified to the corresponding transaction module in the receiving system almost simultaneously with the transmission of the message from the transmitting system, so that the corresponding transaction module in the receiving system is sent to the corresponding transaction module. Notification of transaction data is performed in real time.

As described above, according to the transaction data notification method, the message receiving method is absorbed by the message broker, so that the message receiving method is not incorporated in the receiving system itself as in the related art. It is possible to notify the transaction module in the receiving system of the transaction data in real time.

Although a message broker is used in this transaction data notification method, the message broker itself can be constructed using a commercially available middleware product.

In the transaction data notifying method according to the eighth aspect, the second step is to acquire the element type and the transaction data from the message received by the reception queue as described in the ninth aspect. It is preferable that the format of the transaction data is converted in accordance with the element type, and then the transaction data is notified to the transaction module corresponding to the transaction type of the message among the plurality of transaction modules.

In the method of notifying transaction data according to claim 9, as an example, claim 1
As described in No. 0, it is more preferable that a plurality of transaction data having the same element type be collectively converted in the second step.

As a result, the format conversion of the transaction data included in the message transmitted from the transmission side system is also efficiently performed, so that the notification of the transaction data to the transaction module is further expedited. become.

Also, in the transaction data notifying method according to any one of claims 8 to 10, at least one of the first step and the second step is received in the reception queue as described in claim 11. It is preferable to record log information about the message that has been sent and notify a system on the transmitting side of the message of an error about the message.

More specifically, in the computer network according to claims 8 to 10, as in claim 12, in the first step, the transaction type obtained from the message received in the reception queue cannot be identified. In this case, it is preferable to transmit an error notification message to the transmission side system and record the same information as the error notification message as log information. In the computer network described in the item (2), in the second step, if the content of the transaction data obtained from the message received in the reception queue is incorrect and the element type obtained from the message is the same, If at least one of the cases is not possible, the sender It transmits an error notification message to Temu, and it is preferable to record the same information as the error notification message as log information.

Thus, even if a failure occurs in the receiving system during the process of receiving and notifying a message, the error can be analyzed and recovered using the error notification message and log information. Will be possible.

[0041]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An example in which the present invention is applied to a computer network in which a plurality of application systems using various applications are connected by communication lines will be described below.

FIG. 1 shows how a plurality of application systems included in a computer network to which the present invention is applied cooperate. This computer network includes a plurality of application systems 31 (1)
To provide message creation and transmission / reception functions to application systems 31 (1) to 31 (m).
(M) A message broker 32 for unified management of transmission and reception of messages between each other is constructed. Cooperation between the application systems 31 (1) to 31 (m) is performed by creating, transmitting, and receiving messages using the message broker 32. Specific functions of the message broker 32 will be described later.

Each application system 31 (1)-
31 (m) is the system that sends the message,
It can be any of the systems that receive the message. The present invention relates to the notification of transaction data to a transaction module in a system that receives a message. Therefore, in the following, each of the application systems 31 (1) to 31 (m) communicates with a system that receives a message. A description will be given of a case in which this is the case.

FIG. 2 shows each application system 31.
(1) to (m) show an example of the software configuration of the receiving side system. This receiving system 1
The system includes an inbound adapter 2, a reception queue 3, and an MB-API (message broker-application interface) 4, which is an interface for providing the inbound adapter 2 with a function of receiving a message. The MB-API 4 forms a part of the function of the message broker 32 in FIG.

The receiving system 1 uses a plurality of transaction modules 5 (1) corresponding to transaction types by using an ERP package.
5 (n) are provided, and each transaction module performs a transaction process associated with the occurrence of a transaction of the corresponding transaction type.

As shown in FIG. 2, the receiving side system 1
The transmission and reception of messages between the transmission side system 21 and the transmission side system 21 (the system which transmits transaction data to the reception side system 1 among the application systems 31 (1) to 31 (m) in FIG. 1) is managed by the message broker 22. You. This message broker 22 is also shown in FIG.
Of the message broker 32.

The message transmitted from the transmitting system 21 is received by the message broker 22 and
The data is transmitted to the reception queue 3 of the receiving system 1.

FIG. 3 shows an example of the structure of a message transmitted from the transmitting system 21. This message is
A message ID for uniquely identifying the message,
ID for identifying the type of transaction that occurred
(Called a transaction type) and a plurality of elements (called elements) constituting the transaction. Each element has an ID (called an element type) for identifying the type of the element,
And corresponding transaction data (called element data).

Note that this message is transmitted from the transmission side system 21 every time a transaction occurs, but each of the application systems 31 (1) to 31 (3) shown in FIG.
The configuration and processing of 1 (m) as the transmission side system 21 are out of the scope of the present invention, and thus description thereof is omitted. (A detailed example of the configuration and processing of the transmission-side system is described in “Computer Network and Transaction Data Transmission Method” filed on Feb. 25, 1999 by the present applicant.)

First, an outline of the processing of the inbound adapter 2 will be described. FIG. 4 shows the inbound adapter 2
This shows an outline of the processing of the MB-API.
The presence / absence of a message in the reception queue 3 is checked using the message reception function provided by the server 4 (step S1). Subsequently, it is determined whether a message has been received (step S2).

If it has not been received, the process returns to step S1, and the processes of steps S1 and S2 are repeated. In this way, the reception of the message in the reception queue 3 is constantly monitored. If a message has been received in the reception queue 3, the transaction type (see FIG. 3) of the message is acquired (step S3).

Subsequently, the element type and element data (see FIG. 3) of each element of the message are obtained (step S4). Then, after converting the format of the element data of each element according to the element type of the element, the transaction module 5 (1) to 5 (n) notifies the transaction module corresponding to the transaction type of the message (step). S5).

As a result, the element data (transaction data) in the corresponding transaction module in the receiving system 1 is notified to the corresponding transaction module in the receiving system 1 almost simultaneously with the transmission of the message from the transmitting system 21. Notification of transaction data to the transaction module is performed in real time.

As described above, the message receiving method is absorbed by the MB-API 4, so that the message receiving method is not incorporated in the receiving system 1 itself, and the transaction module 5 (1) in the receiving system 1 is used. ) To 5 (n) can be notified of transaction data in real time.

Next, the configuration of the inbound adapter 2 and details of its processing will be described. FIG. 5 shows an example of the configuration of the inbound adapter 2. The inbound adapter 2 includes a dispatcher 6 and a plurality of transaction processes 7 (1) to
7 (n) and each transaction processing 7 (1) to 7 (7)
(N) called from a plurality of element processes 8 (1) to 8 (k) (the value of k may be different for each transaction process).

Each transaction processing 7 (1) to 7
(N) is the transaction module 5 (1) in FIG.
-5 (n) is one-to-one for the corresponding transaction type
It corresponds to. Transaction processing 7 (1) to 7
Element processing 8 (1) to 8 called from (n)
(K) has a one-to-one correspondence with the element type (see FIG. 3) included in the message of the transaction type corresponding to the transaction processing.

The transaction processing 7 here
(1) to 7 (n) are not transaction processing as a generic term for processing such as data output and database maintenance required when a transaction occurs, but to transaction modules 5 (1) to 5 (n). Of the specific data for the notification of the element data.

FIGS. 6 to 9 show a detailed example of the processing of the inbound adapter 2 by each unit in FIG. In the inbound adapter 2, first, the processing of the dispatcher 6 is executed. FIG. 6 shows an example of the processing of the dispatcher 6. First, it is checked whether or not a message has been received in the reception queue 3 by using the message receiving function provided by the MB-API 4 (step S1).
1). Subsequently, it is determined whether a message has been received (step S12).

If it has not been received, the process returns to step S11, and the processes of steps S11 and S12 are repeated. In this way, the reception of the message in the reception queue 3 is constantly monitored. Then, if a message has been received in the reception queue 3, the transaction type (see FIG. 3) of the message is acquired (step S13).

Subsequently, it is determined whether or not the transaction type is identifiable (step S1).
4). If it is identifiable, a transaction process corresponding to the transaction type among the transaction processes 7 (1) to 7 (n) is called (step S15). Then, the processing of the dispatcher 6 ends.

On the other hand, if it is determined in step S14 that the message is not identifiable, a Notification message, which is an error notification message to the transmitting system 21 that has transmitted the message received in the reception queue 3, is created, and the Notification message Is returned to the transmitting side system 21 (step S16). Subsequently, the same information as that of the Notification message is recorded as log information in a log file (step S17). Then, the process returns to step S11 and repeats the steps from step S11.

FIG. 10 is a diagram showing the N created in step S16.
5 shows an example of an authentication message. No
The notification message itself includes a message ID for uniquely identifying the message, a transaction type, an element type, an element position indicating the element number in the message received by the reception queue 3, and an error message. It has a structure in which an error code indicating the content can be written. If the transaction type is indistinguishable, the message ID, the transaction type, and the Notific that has written the information in the error code among them.
ation message is created.

It is to be noted that the determination in step S14 is based on, for example, the transaction types Tx1, Tx2... Corresponding to the transaction modules 5 (1) to 5 (n) in FIG. Transaction processing 7 (1) to 7 (n) (in FIG. 11, Fun
c Tx1, Func Tx2...) are registered, and only the transaction types registered in the transaction type table can be identified.
Also, the transaction processing called in step S15 is confirmed by referring to the transaction type table.

FIG. 7 and FIG.
Examples of (1) to 7 (n) are shown. In the transaction process called from the dispatcher 6, first, as shown in FIG. 7, all information of the message received by the reception queue 3 is recorded as log information in a log file in a plain text format (step S21).

Subsequently, the element type and element data of one element of the message are obtained (step S22). Then, the content of the element data is checked (step S23), and it is determined whether or not the content is correct (step S24).

If the element is correct, it is determined whether or not the element is the first element that has obtained correct element data from the message (step S2).
5). Here, since it is the first element, it is determined to be yes and the process proceeds to step S33.

In step S33, the element is
It is determined whether or not this is the last element that has acquired the correct element data of the content from the message. If it is not the last element, the process returns to step S22. And for another element of the message,
Step S22 and subsequent steps are repeated.

On the other hand, if it is the last element, it is determined whether or not the element type of the element is identifiable (step S34). If it can be identified, the element processing corresponding to the element type among the element processings 8 (1) to 8 (k) is called (step S35). Then, the transaction processing ends.

When the process returns from step S33 to step S22, and reaches step S25 again, it is determined that the element is not the first element, and thus the process proceeds to step S26. In step S26, it is determined whether the element type of the current element (the element type obtained in step S22 this time) is the same as the element type of the previous element (element type of the element obtained in previous step S22). .

If they are not the same, the flow advances to step S27 in FIG. 8 to determine whether or not the element type of the previous element is identifiable. If it can be identified, the element processing corresponding to the element type among the element processings 8 (1) to 8 (k) is called (step S28). Subsequently, it is determined whether or not the current element is the last element obtained from the message (step S29).

If it is not the last element, the process returns to step S22 in FIG. Then, step S22 and subsequent steps are repeated for still another element of the message. On the other hand, if it is the last element, it is determined whether the element type of the current element is identifiable (step S30). If it can be identified, the element processing corresponding to the element type among the element processings 8 (1) to 8 (k) is called (step S31). Then, the transaction processing ends.

On the other hand, if it is determined in step S26 in FIG. 7 that the current element type is the same as the previous element type, the process proceeds to step S32.
Connect (append) the current element data to the previous element data. (If the previous element data is also appended to the previous element data in step S32, in step S32, the current element data is further appended to the plurality of element data.) Proceed to step S33.

If it is determined in step S24 in FIG. 7 that the content of the element data is not correct, the flow advances to step S36 in FIG. 8 to create a Notification message, and the Notification message is received by the reception queue 3. The message is sent back to the transmitting system 21 that sent the message. And the Not
The same information as the information message is recorded as log information in a log file (step S37), and FIG.
6 is restarted for the next message transmitted from the transmitting system 21 of FIG.

The case where it is determined in step S27 in FIG. 8 that the previous element type is not identifiable, the case where it is determined in step S30 in FIG. 8 that the current element type is not identifiable, Step S34 of 7
Then, even when it is determined that the element type cannot be identified, the processing of the dispatcher of FIG. 6 is restarted through steps S36 and S37.

FIG. 12 is a diagram showing the N created in step S36.
5 shows an example of an authentication message. In the case of an error relating to the element such as the content of the element data is not correct or the element type cannot be identified, the Notification in which information is written in the message ID, transaction type, element type, element position and error code.
A message is created.

The determination in step S34 in FIG. 7, and the determination in steps S27 and S30 in FIG. 8, for example, are included in the transaction type message corresponding to the transaction process called from the dispatcher process as shown in FIG. Element types Te1 and Te
2 and corresponding element processes 16 (1) to 16 (16)
(K) (FIG. 13 shows Func Te1 and Func Te
2) is referred to, and only the element types registered in this element type table can be identified.

The element processing 16 called in step S35 of FIG. 7 and steps S28 and S31 of FIG.
Confirmation of (1) to 16 (k) is also performed by referring to this element type table.

In this transaction processing, if the element types of the element data successively obtained from a plurality of elements of the message received by the reception queue 3 are the same, the element data is appended in step S32 in FIG. In this state, the element processing corresponding to the element type is called.

FIG. 14 shows an example of a message received by the reception queue 3 and a state where the element data of this message is appended in step S32 of FIG. The element data “1111111111111” and “22” obtained continuously from the first two elements
Since the element types of “222222222222” are the same (both are Te1), their element data is appended. Further, since the element types of the element data obtained successively from the fourth to sixth elements are the same (both are Te3), these element data are also appended.

In step S32 in FIG. 7, a code such as a line feed code is inserted between the individual element data to be appended as a separator for separating the individual element data. That is, when the transaction modules 5 (1) to 5 (n) in FIG. 1 are notified of the element data by the element processing described below, the transaction modules 5 (1) to 5 (n) discriminate the individual element data from the appended element data without error. It is to be able to do it.

FIG. 9 shows each of the element processes 8 (1) to 8 (8).
An example of (k) is shown. In the element processing called from the transaction processing, first, the format of the element data acquired in the transaction processing is converted according to the element type (step S4).
1). Subsequently, the format-converted element data is transferred to the transaction modules 5 (1) to 5
In (n), the transaction module corresponding to the transaction type of the message received by the reception queue 3 (the transaction type acquired in step S13 of the dispatcher process in FIG. 6) is notified (step S42).

When a plurality of element data having the same element type are appended by the transaction processing, in these steps S41 and S42, the format conversion and the notification to the transaction module are collectively performed on the element data. .

Subsequently, it is determined whether or not the notification to the transaction module has been successful (step S4).
3). If successful, the dispatcher process of FIG. 6 is restarted for the next message transmitted from the transmitting system 21 of FIG.

On the other hand, if the notification to the transaction module has not been successful yet, the notification to the transaction module is repeated every predetermined time until the predetermined number of times is reached. If the notification is not successful even if the notification is repeated a predetermined number of times, the entire process of the inbound adapter 2 is forcibly terminated.

As described in detail with reference to FIGS. 5 to 14 above, when the element types of the element data successively obtained from a plurality of elements of the message received by the reception queue 3 are the same, Are appended in the transaction processing, the element processing collectively converts the format of the element data and notifies the transaction module.

As a result, the format conversion of the element data included in the message transmitted from the transmission side system 21 is efficiently performed, and the notification of the element data to the transaction module is further expedited.

In the processing of the dispatcher 6, if the transaction type of the message received by the reception queue 3 cannot be identified, the Notificati
on message is returned to the transmitting side system 21 and the N
The same information as the authentication message is recorded as log information in a log file.

Transaction processing 7 (1) to 7 (n)
However, if all information of the message received by the reception queue 3 is recorded as log information, and the content of the element data obtained from the message received by the reception queue 3 is incorrect, or if the element type obtained from the message is incorrect. Notifyat if is not identifiable
The notification message is returned to the transmission side system 21, and the same information as the Notification message is recorded as log information in a log file.

Thus, even if a failure occurs in the receiving side system 1 in the process of receiving and notifying a message, it is possible to analyze and recover the failure using these Notification messages and log information. ing.

The MB-A which provides the dispatcher 6 with a function of receiving a message from the transmission side system 21
The PI 4 and the message broker 22 that manages the transmission and reception of messages between the receiving system 1 and the transmitting system 21 can be constructed using, for example, a commercially available middleware product for constructing a message broker.

FIG. 2 shows that the dispatcher 6 and the transaction processes 7 (1) to 7 (n) are Notify.
Although a message broker that provides a creation function and a transmission function of an event message is not shown, a message broker that provides such a creation function and a transmission function can also be constructed using a commercially available middleware product for constructing a message broker. It is. Alternatively, a message broker that provides such a function of receiving, creating, and transmitting messages may be developed without using a middleware product.

Further, in the above example, the present invention is applied to the computer network in which the transaction module is provided to the receiving system by using the ERP package. Needless to say, the present invention can be applied to a computer network having a transaction module in the side system.

In the above example, the present invention is applied to a computer network including only an application system as a communication entity, but the present invention is also applied to a computer network including a system not using an application as a communication entity. Of course you can. Further, the present invention is not limited to the above-described example, and it is needless to say that various other configurations can be adopted without departing from the gist of the present invention.

[0094]

As described above, according to the computer network of the first aspect of the present invention, a message including a transaction type, an element type, and transaction data is transmitted from a system in which a transaction has occurred. In this case, the effect is obtained that the transaction data can be notified in real time to the transaction module in the receiving-side system without incorporating the method of receiving the message into the message-receiving system itself.

In the computer network according to the second or third aspect, in the case of the fourth aspect, the format conversion of the transaction data contained in the message transmitted from the transmission side system is efficient. , The notification of the transaction data to the transaction module can be further speeded up.

Further, in the computer network according to any one of the first to fourth aspects, in the case of the fifth to seventh aspects, when a failure occurs in the receiving side system in the process of receiving and notifying a message. In addition, the effect that it is possible to analyze and recover from the failure using the error notification message and the log information is also obtained.

Next, according to the transaction data notification method of the present invention, a message including a transaction type, an element type, and transaction data is transmitted from a system in which a transaction has occurred. In this case, the effect is obtained that the transaction data can be notified in real time to the transaction module in the system on the message receiving side without incorporating the message receiving method into the system on the message receiving side itself.

In the transaction data notifying method according to the ninth aspect, in the case of the tenth aspect, the format conversion of the transaction data included in the message transmitted from the transmission side system is efficiently performed. In this case, the notification of the transaction data to the transaction module can be further speeded up.

Further, in the transaction data notifying method according to any one of claims 8 to 10, when the method according to any one of claims 11 to 13 is adopted, a failure occurs in the receiving side system in the process of receiving and notifying a message. Even in the case of occurrence, the effect of analyzing and recovering from the failure using the error notification message and the log information can be obtained.

[Brief description of the drawings]

FIG. 1 is a diagram showing a state of cooperation of a plurality of application systems in a computer network to which the present invention has been applied.

FIG. 2 is a diagram illustrating an example of a software configuration as a receiving system of the application system of FIG. 1;

FIG. 3 is a diagram illustrating an example of a structure of a message transmitted from the transmission side system in FIG. 2;

FIG. 4 is a flowchart showing an outline of processing of the inbound adapter of FIG. 2;

FIG. 5 is a diagram illustrating an example of a configuration of an inbound adapter in FIG. 2;

FIG. 6 is a flowchart illustrating an example of processing of the dispatcher of FIG. 5;

FIG. 7 is a flowchart illustrating an example of the transaction processing of FIG. 5;

FIG. 8 is a flowchart illustrating an example of the transaction processing of FIG. 5;

FIG. 9 is a flowchart illustrating an example of the element processing of FIG. 5;

FIG. 10 is a diagram showing an example of an error notification message to the transmission side system of FIG. 2;

FIG. 11 illustrates an example of a transaction type table.

12 is a diagram illustrating an example of an error notification message to the transmission side system in FIG. 2;

FIG. 13 is a diagram illustrating an example of an element type table.

FIG. 14 is a diagram illustrating an example of a message and a state where element data of the message is appended.

FIG. 15 is a diagram showing transmission / reception of transaction data and notification to a transaction module in a receiving-side system in the related art.

[Explanation of symbols]

1 receiver system, 2 inbound adapter,
3 reception queue, 4 MB-API, 5 (1) to 5
(N) transaction module, 6 dispatcher, 7 (1) to 7 (n) transaction processing, 8 (1) to 8 (k) element processing, 21
Sender system, 22, 32 Message broker, 31 (1) -31 (m) Application system

Claims (13)

[Claims] In a computer network including a plurality of systems, at least one system monitors reception of a message in a reception queue using a message broker as a system for receiving transaction data. Acquires a transaction type for identifying a transaction from the message received in step 1, and notifies the transaction module corresponding to the transaction type of the plurality of transaction modules in the system of the transaction data acquired from the message. A computer network comprising an inbound adapter. 2. The computer network according to claim 1, wherein the inbound adapter includes an element type for identifying an element that is a constituent element of a transaction from the message received in the reception queue, and the element type. A computer network for acquiring corresponding transaction data, converting the format of the transaction data according to the element type, and notifying a transaction module corresponding to the transaction type among the plurality of transaction modules. 3. The computer network according to claim 2, wherein the inbound adapter includes a plurality of first modules corresponding to the transaction type, a plurality of second modules corresponding to the element type, and a message broker. Monitoring the reception of a message in a reception queue, acquiring the transaction type from the message received in the reception queue, and calling a module corresponding to the transaction type among the plurality of first modules. And a module called from the dispatcher among the plurality of first modules acquires the element type and the transaction data from the message, and the plurality of second modules. A module corresponding to the element type is called, and a module called from the first module among the plurality of second modules converts the format of the transaction data according to the element type. A transaction module corresponding to the transaction type among the transaction modules. 4. The computer network according to claim 2, wherein a plurality of transaction data having the same element type are format-converted collectively. 5. The computer network according to claim 1, wherein the inbound adapter records log information on a message received in the reception queue, and transmits the log information to a system on the transmission side of the message. Sending a message notifying an error relating to the message. 6. The computer network according to claim 1, wherein the inbound adapter obtains a message received from the reception queue when the transaction type of the message is indistinguishable and from the message. In at least one of the case where the content of the transaction data is incorrect, and sends a message notifying the error to the system on the message sending side, and
A computer network, wherein the same information as a message notifying the error is recorded as log information. 7. The computer network according to claim 2, wherein the inbound adapter determines the type of the message received in the reception queue when the element type of the message cannot be identified. A computer network for transmitting a message notifying an error to a transmitting system and recording the same information as the message notifying the error as log information. 8. A method in which a system receiving transaction data in a computer network including a plurality of systems notifies the transaction module to a transaction module in the system, using a message broker to receive the transaction data in a reception queue. A first step of monitoring the reception of a message and acquiring a transaction type for identifying a transaction from the message received in the reception queue; and corresponding to the transaction type among a plurality of transaction modules in the system. A second step of notifying the transaction module of the transaction data acquired from the message. 9. The method of notifying transaction data according to claim 8, wherein in the second step, an element type and an element for identifying an element constituting the transaction from a message received in the reception queue. A transaction that acquires transaction data corresponding to a type, converts the format of the transaction data according to the element type, and notifies a transaction module corresponding to the transaction type among the plurality of transaction modules. Notification method of data. 10. The transaction data notification method according to claim 9, wherein in the second step, a plurality of transaction data having the same element type are collectively converted in format. Notification method. 11. The transaction data notification method according to claim 8, wherein at least one of the first step and the two steps is a log related to a message received by the reception queue. A method of notifying transaction data, comprising recording information and transmitting a message notifying an error relating to the message to a system on a transmitting side of the message. 12. The method of notifying transaction data according to claim 8, wherein in the first step, when the transaction type acquired from the message received in the reception queue is not identifiable. Transmitting a message notifying an error to a system on the transmitting side of the message, and recording the same information as the message notifying the error as log information. 13. The transaction data notification method according to claim 9, wherein in the second step, the content of the transaction data acquired from the message received in the reception queue is incorrect. And at least one of the case where the element type obtained from the message is unidentifiable, the system of the sender of the message,
A method for notifying transaction data, comprising transmitting a message notifying an error and recording the same information as the message notifying the error as log information.