JP3632845B2 - File exchange device - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data exchange system via a network, and more particularly to a transfer apparatus and an exchange system in an EDI system.
[0002]
[Prior art]
In recent years, electronic transactions using computer networks have become active. As an example of this electronic commerce, electronic data interchange (EDI) has become widespread. By using this EDI, it is possible to send and receive data such as orders and orders with business partners. Also, Web-EDI is known as an advanced type of EDI. In this Web-EDI, by using a Web server and a Web browser, ordering / ordering data created in the HTML format is transmitted / received to / from a business partner via the Internet.
[0003]
In these systems, EDI is used for data exchange between specific companies, while Web-EDI is used for data exchange with an unspecified partner, so-called segregation of systems has been made.
[0004]
By the way, when exchanging data, it is necessary to negotiate a data format in advance to ensure mutual compatibility. In conventional EDI, this arrangement was made in three stages. First, as the domestic regulations, the exchange procedure, exchange structure, style, and character code used were defined. Next, as a contract for each trading industry, the type, content and meaning of data to be exchanged were defined as standard messages. Other matters related to operations and transactions were determined among participating companies.
[0005]
[Problems to be solved by the invention]
In the case of conventional EDI, in addition to the above standard specifications, in addition to the standard specifications described above, company-specific content was added, and there were many cases where the standard specifications were not observed. Furthermore, there have been many cases in which a system for exchanging accompanying information generated during a commercial transaction is constructed by a system different from EDI. For this reason, it was necessary to make the company's system compatible with the original specifications adopted by the business partners. In particular, when the number of new business partners is increased or the contents of transactions are partially changed, there is an adverse effect of increasing development costs and operating costs due to the need to change the system and its operation. Furthermore, in order to develop an individual system for each business partner, a considerable development period is required, and there is a problem that it is not possible to respond in a timely manner to the participation of new business partners and changes in the trade law formula.
[0006]
On the other hand, Web-EDI has the advantage of being able to participate in Web-EDI by preparing a program to be used by the client on the server side, as long as an environment capable of connecting to the Internet is prepared for the business partner serving as the client. . However, when there are multiple servers and multiple Web-EDIs, the screen style, input method, and operation method are different for each of them, resulting in confusion such as input mistakes and interpretation of business transactions. As a result, there was a risk of causing trouble in commerce.
[0007]
In addition, companies that adopt Web-EDI must make system changes and operational changes on the server side, as well as conventional EDI, when the transaction content and transaction environment are changed. There is a harmful effect of being overgrown.
[0008]
Furthermore, EDI using the Internet as a communication line has a security problem because the Internet is a system that is also used by general users. For example, there is a risk of damage caused by eavesdropping, falsification, and impersonation of exchange information. is there.
[0009]
In the data exchange system described above, legal reachability is adopted for the establishment of commercial transactions. Therefore, the time when the transaction message arrives at the other party is interpreted as the transaction establishment time. Therefore, the determination of the message transaction time has a very important meaning, and it is necessary to sufficiently ensure communication reliability. In conventional EDI, reliability was ensured by an exchange procedure. On the other hand, Web-EDI has a problem that since it uses the Internet, the reliability of communication is low, and confirmation of the establishment of a commercial transaction cannot be sufficiently guaranteed. In particular, in a commercial transaction with an unspecified business partner that employs open EDI, a content collation method and a confirmation result exchange method cannot be determined in advance because of its openness. In such a system, there is a tendency to adopt the method of re-sending the same data and checking it visually, but experts have pointed out that sending the same contents multiple times is a double transaction between companies. There is no solution.
[0010]
Therefore, an object of the present invention is to provide a data exchange system that can easily cope with the original specification of a supplier.
[0014]
[Means for Solving the Problems]
In the present invention, it was created in the first information system in order to solve the above problem.FileTo the second information system connected to the networkFileIn the exchange device, a plurality of pieces created in the first information systemInternal fileA first storage device for storing a plurality of the plurality of the storage devices stored in the first storage deviceFrom internal fileIn the intermediate file or the second information systemCreate a send / receive file to sendin order toCompany code, file name, and edit categoryA second storage device that stores a registry that describes a plurality of the plurality of the storage devices stored in the first storage deviceInternal fileSequentially readInternal fileBut,Describe the destinationDetermining means for determining whether the file format does not have message guide information or a folder format having the message guide information; andInternal fileIs determined to be in the file format,Internal fileIdentifying the registry according to the destination information contained in theInternal fileIs determined to be in the folder format, theInternal fileIn the message guide informationTo the address listedTherefore, the registry is identified and included in each identified registryCompany code and file nameFollowCreate the intermediate file from the internal fileStorage means for storing in an intermediate area, reading the intermediate file from the intermediate area, and reading the intermediate file to the second information systemCreate a send / receive file to sendTo the file name of the intermediate fileThereforeThe registryspecificAndIdentifiedThe registryThe edit category described in,A plurality of the intermediate files having the same destinationIf you are instructing to consolidateIntermediate filePut togetherSend / receive fileCreateSend / receive fileCreating means and said createdSend / receive fileTransmitting means for transmitting to the second information system;
It is characterized by providing.
[0015]
The storage means is determined to be the file format.Internal fileIf the message contains multiple internal messages with different destinations,Internal fileMay be included for each destination.
[0029]
DETAILED DESCRIPTION OF THE INVENTION
[First Embodiment]
In the present embodiment, an integrated information exchange system is provided between the own system and the supplier system to absorb differences between the two systems. Since the difference in the system differs for each business partner, a conversion rule and an exchange rule are prepared for each business partner. In addition, in order to cope with the addition of a new business partner or the system change of an existing business partner, it is possible to cope with it relatively easily only by correcting this conversion rule or exchange rule.
[0030]
FIG. 1 shows the system configuration of this embodiment. A plurality of user terminals 101 are connected to the business system 100 via an in-house LAN 102 in an intranet 150 of a certain company. The user terminal 101 executes transfer software such as Web browser software, mail software, and FTP, and transmits / receives files to / from the business system 100 and the integrated information exchange system 103 via the software. In addition, file servers 104 to 106 exist in the intranet 150. These file servers are used for file storage by the user terminal 101, the business system 100, and the integrated information exchange system 103. Instead of providing a file server, a hard disk built in the integrated information exchange system 103 or the like may be used. The integrated information exchange system 103 is connected to a supplier system via an arbitrary communication network 110. In the present embodiment, among the parties involved in the transaction, the side that transmits the data may be referred to as a sender, and the other party of the transaction, that is, the data receiver may be referred to as the destination (130 or 140). Note that the relay destination 120 may be arbitrarily provided between the transmission source and the transmission destination 130.
[0031]
FIG. 2 shows a computer configuration of the business system 100, the user terminal 101, the integrated information exchange system 103, the relay destination 120, and the destinations 130 and 140.
[0032]
The CPU 200 executes various programs stored in a hard disk drive (HDD) 206. A RAM 201 is a random access memory and is used to execute a program. A ROM 202 is a read-only memory, and stores a BIOS of the computer. The display 203 is a display device. The communication IF 205 is a communication device such as a network card or a modem for connecting to a LAN or the Internet. The input device 207 is configured with a keyboard or the like.
[0033]
Now, an example of executing EDI processing using a transmission / reception registry and an exchange destination registry based on the above-described configuration will be described. That is, the transmission / reception registry and the exchange destination registry are a set of information on data conversion rules and data exchange rules that are necessary for continuous transactions. More specifically, the transmission / reception registry stores control information necessary for file editing processing between the business system 100 and the integrated information exchange system. For example, when a business is continuously performed, a file created by the business system 100 is often transmitted to a business partner. In such a case, the file created by the business system 100 must be changed to a format that can be processed by the integrated information exchange system 103. Therefore, when the format is changed, data serving as a reference for the change processing is stored in the transmission / reception registry. On the other hand, the exchange destination registry stores control information necessary for editing a file for each exchange destination (relay destination, delivery destination, etc.). For example, if a file is created with reference to the transmission / reception registry, then a file conversion process that matches the specifications of the trading partner is required. Therefore, data serving as a reference for file conversion processing for each trading partner is stored in the exchange destination registry.
[0034]
These two types of registries include an element name and a value corresponding to the element name, and are described based on XML. Since it is based on XML, the description order of the elements is not important, and elements can be freely selected and combined. In other words, since it is rich in expandability, it is possible to easily deal with the addition of business partners and changes in business partner systems. For example, when the number of exchanges and destinations increases, or when switching between conventional EDI and Web-EDI according to the destination system, it is possible to cope with the problem by simply adding or changing the registry information. Furthermore, future expansion of usage can be handled by adding elements. Thus, the system of the connection part for exchanging data can be flexibly processed based on the transmission / reception registry exchange destination registry.
[0035]
FIG. 3 shows the configuration of the transmission / reception registry. The transmission / reception registry includes element names 301 to 306 and corresponding values. The transmission / reception section 301 indicates whether the registry is used for transmission or the registry used for reception. The internal file name 302 is the name of the file to be processed in the processing waiting area. The exchange destination code 303 is a company code indicating the exchange destination of the internal file, and is used to collate with the company code of the supplier registered in the exchange destination registry. The exchange classification 304 indicates that the transmission destination of the message included in the processing target file is VAN, mixed or single. The division division 305 indicates whether division by destination is necessary before transmission or division of the transmission source is necessary after reception. The creation category 305 indicates whether or not a message having the same destination is added to the internal file or added to the internal file and written to the intermediate area.
[0036]
FIG. 4 shows the configuration of the exchange destination registry. The replacement destination registry includes element names 401 to 404 and corresponding values. The company code 401 stores the exchange company code as a value. The name of the person in charge serving as the window of the exchange destination company is stored as a value in the name of the person in charge of the exchange destination. In the exchange destination e-mail 403, the e-mail address of the person in charge of exchange is stored as a value. The detail unit 404 stores element names 411 to 418. In the internal file name 411, the name of the processing target file stored in the intermediate area is stored as a value. In the transmission / reception file name 412, a file name for external exchange is stored as a value. External processing (VAN company or the like) determines processing at the time of relay based on this file name. The exchange method 413 stores as a value whether to transmit via VAN or directly to the other party. In the exchange procedure 414, a protocol name to be used is stored as a value. In the exchange method 415, a conversion method for a file to be exchanged or a message to be exchanged is stored as a value. In the edit section 416, whether or not a plurality of files having the same exchange destination are combined into one is stored as a value. In the transmission / reception directory 417, the name of a directory for registering the processing result is stored as a value. The integrated delivery destination 418 stores a company code of the exchange destination when the exchange files are collectively sent to another exchange destination (VAN or the like) as a value.
[0037]
In this embodiment, when only a file is transferred, processing is performed with reference to the transmission / reception registry and the exchange destination registry based on the file name.
[0038]
FIG. 5 shows an outline of processing in the intranet. The internal file created by the business system 100 or the user terminal 101 is first stored in the process waiting area 104 of the file server. The integrated information exchange system 103 reads an internal file at an arbitrary timing, and creates an intermediate file based on the transmission / reception registry. The created intermediate file is stored in the intermediate area 105 of the file server. The integrated information exchange system 103 reads the intermediate file at an arbitrary timing, creates a transmission file based on the exchange destination directory, and stores it in the transmission waiting area 107 of the file server. Finally, the integrated information exchange system 103 reads the transmission file from the transmission waiting area at an arbitrary timing and transmits it to the transmission destination.
[0039]
FIG. 6 shows a flowchart when processing the internal file stored in the processing waiting area. It is assumed that the sending / receiving registry and the exchange destination registry are created in advance by the EDI administrator.
[0040]
The integrated information exchange system 103 reads an internal file at an arbitrary timing (S10). This timing may be periodic or may be based on a user instruction.
FIG. 7 shows the stored contents of the processing waiting area 104. A processing waiting area 104 on the file server stores a file named gyomu10 and a folder named fldr20. The internal file gyomu10 is created by the business processing system, and at least one message is included in one file. The destination information is added to the head of each message. Each message is separated by a separator, and as shown in FIG. 7, messages with different destinations may be mixed.
[0041]
fldr20 is a folder format internal file. The fldr 20 includes message guide information, main information to be transmitted to the business partner, and a plurality of related information. The folder format internal file is created by the user terminal 101. The message guide information includes information having the same contents as the transmission / reception registry, and further describes the contents of processing to be executed at the business partner. Details will be described later. The message guide information can be distinguished from other files by giving a unique file name. For example, a naming rule for the file name (or the first n characters of the file name) may be determined in advance.
[0042]
The integrated information exchange system 103 determines whether the read file is in a file format or a folder format depending on whether or not the message guide information is included in the read file (S15).
[0043]
Next, the integrated information exchange system 103 reads the transmission / reception registry from the file server 106 (S30). More specifically, the integrated information exchange system extracts the file name (internal file name N) when the content extracted from the processing waiting area is not in the folder format, and the value of the element “internal file name” of the transmission / reception registry Is searched for a transmission / reception registry that matches the internal file name N. FIG. 8 shows an example of data in the transmission / reception registry. According to this example, a transmission / reception registry including “value 11” having the name “gyoumu1” of the file to be processed as an element is selected.
[0044]
Next, the values of “exchange category” and “division category” described in “value 11” of the selected transmission / reception registry are referred to. According to the example of FIG. 8, they are “mixed” and “divided”, respectively. In this case, the integrated information exchange system 103 determines that a plurality of messages are included in the internal file to be processed, and the message A process of dividing into units is executed (S40). In the example of FIG. 8, the messages 1 to 4 are divided into four for the internal file gyomu10.
[0045]
Next, for the message obtained in S40, the destination information added to the head of the message is extracted (S50). For example, the destination of the message 1 shown in FIG. 7 is “F1”.
Next, the exchange destination registry corresponding to the delivery destination extracted in S50 is searched (S60). FIG. 9 shows a specific example of the exchange destination registry. For example, a search is made for a match between the “company code” in the exchange destination registry and the destination. In the example of FIG. 9, the “value 21” that is the destination “F1” of the message 1 in the internal file gyomu10 is the exchange destination registry to be obtained.
[0046]
Next, an intermediate fill name is created based on the value of “company code” in the exchange destination registry and the value of “internal file name” in the detail section. For example, “company code + internal file name”. Further, an intermediate file is written with the created file name (S70). In addition, when the value of the “creation category” of the transmission / reception registry read in S30 is “append”, if a file with the same name already exists in the intermediate area, it is added, and if it does not exist, it is newly created. . In the example of FIG. 8, the message 4 is added after the message 1 of the internal file gyomu10 and is written in the intermediate area 105 as the intermediate file name “F1 + gyoumu10”. In addition, the message 3 is added after the message 2 of the internal file gyomu10, and written in the middle area 105 as the middle file name “G1 + gyoumu10”.
[0047]
The processes from S50 to S70 are performed for all messages (S80), and the processes from S10 to S80 are performed for all the files (S90).
[0048]
Next, the integrated information exchanging system creates a transmission / reception file for the intermediate file stored in the intermediate area 105 with time designation or periodically, and stores it in the transmission waiting area 107 of the file server. FIG. 10 shows a flowchart for processing the file in the intermediate area 105.
[0049]
First, the integrated information exchange system 103 reads the intermediate file (or intermediate folder, the same applies hereinafter) written in S70 from the intermediate area 105 (S210).
[0050]
Next, the exchange destination registry is searched based on the file name of the read intermediate file (S220). The file name of the intermediate file is “company code + internal file name” as described above. Therefore, character processing is performed from this file name using + as a delimiter to obtain a company code and an internal file name, and the value of the element “company code” in the exchange destination registry and the value of the element “internal file name” in the detail part are Search for a destination registry that matches the one obtained.
[0051]
Next, with respect to the exchange destination registry extracted by the search in S210, it is determined whether or not the value of the “edit category” in the detail section is “summary” (S225). As a result of the determination, if the summary is specified, the intermediate file having the same destination is edited into one (S230). It is determined whether there is another intermediate file that needs to be summarized (S235). If there is, an intermediate file to be summarized is read from the intermediate area 105 (S240). Thereafter, the processing is continued until all the summarization processing is completed.
[0052]
A specific example of the summary process will be described below. The summary processing differs depending on the element value, and the following processing is performed.
[0053]
(1) When the value of “exchange method” in the detail section of the exchange destination registry is “direct” and the value of “edit category” is “summary”
The value of the element name “transmission / reception directory” and the value of the element name “transmission / reception file name” are obtained and stored. In the case of the intermediate file “G1 + gyoumu10”, the value “d002” of the element name “transmission / reception directory” and the value “snd20” of the element name “transmission / reception file name” are obtained from the “value 22” of the exchange destination registry in FIG. . If there is an unprocessed intermediate file corresponding to the intermediate area if there is an unprocessed intermediate file that matches the value stored by referring to other details of the same exchange registry, this is also read and collected. All the contents of the read intermediate file are added and stored together, and the process proceeds to the next step.
[0054]
(2) The value of “Exchange method” in the details section of the exchange destination registry is “VAN”, and the value of “Edit category” is “Summary”" soIf there is:
The value of the element name “transmission / reception directory” and the value of the element name “transmission / reception file name” are obtained and stored. Based on the value of the element name “company code” of the exchange destination registry (referred to as company code K), another exchange destination registry is searched. If the company code K is registered as the value of the “integrated destination” in other exchange destination registries (referred to as exchange destination registry R), it can be understood that the delivery destinations are mixed and sent via VAN. A summary process performed by the integrated information exchange system in this case will be described with reference to FIG. Since “F1” is included in the value of the element name “integrated destination” of the exchange destination registry “value 23”, it is understood that the destination is a batch delivery in which the destinations are mixed via the VAN. It also knows that the value of the element name “company code” is “VAN1” and the value of the element name “transmission / reception file name” is “van10”. Next, by referring to the exchange destination registry “value 21” whose element name “company code” is “F1”, find the detail section 1 in which the element name “transmission / reception file name” has the same value “van10”. It can be seen that the intermediate file “F1 + gyoumu10” needs to be collected for VAN transmission from the value “gyoumu10” of the element name “internal file name” of the detail section 1. If the intermediate file "F1 + gyoumu10" is unprocessed, it is read and collected. Refer to the element name “transmission / reception file name” in the other detail part of the exchange destination registry “value 21”, and if there is any “van10” having the same value of “transmission / reception file name”, the corresponding intermediate file is Read and collect. This is repeated until there is no intermediate file to be collected with the same send / receive file name "van10". If another element is registered as the value of the element name “integrated destination” in the detail part of the exchange destination registry R, the same processing is repeated for this. When this processing is completed, all the contents of the read intermediate file to be collected are added and stored together, and the process proceeds to the next step.
[0055]
Next, it is determined whether or not the conversion method is specified in the value of the “conversion method” in the details of the exchange destination registry for the information of the intermediate file (or the file created by the summary process) stored in the previous step. (S245). If a conversion method is specified, the conversion process is performed using the specified conversion processing method.(S250). In the example of FIG. 9, the “transmission / reception file name” values in the exchange destination registry are “van10” and “send20”, and are converted into standard messages using the CII syntax. For information corresponding to “mail100”, the contents of the main information “tmp20” are converted into XML.
[0056]
Finally, the transmission / reception file subjected to the above processing is written in the transmission waiting area 107 (S260). Specifically, first, the file name of the writing file is created as the file name “company code + transmission / reception file name” from the value of “company code” and the value of “transmission / reception file name”. Subsequently, the directory in which the file is to be written is extracted from the value of the “delivery directory” in the exchange destination registry, and the file is written with the created file name. When writing, it is confirmed whether or not the same file name already exists, and if it exists, it is added to the existing file. If it does not exist, create a new file. In the example of FIG. 9, a file named “VAN1 + van10” is stored in the “V001” directory. Further, a file named “G2 + send20” is stored in the directory “002”. Further, a folder named “F1 + mail100” is stored in the directory “m010”.
The send / receive file in the send waiting area is edited with reference to the exchange destination registry regularly or at regular intervals, and sent to the outside for data exchange.
[0057]
According to the present invention, when the number of new destinations increases, information relating to the new destinations need only be registered in the exchange destination registry. In addition, when the transaction method is partially changed, necessary modifications may be made to the details of the sending / receiving registry and / or the exchange destination registry. It may be replaced with a new registry.
[0058]
Further, when the system is switched to the conventional EDI, Web-EDI, or mail EDI, it can be dealt with only by adding or changing the registry information. Since these two types of registries are described with element names and values based on XML, it is possible to select and combine elements regardless of the order.
[0059]
Moreover, future expansion can be easily handled by adding elements. As described above, the system of the connection part for exchanging data can flexibly perform processing based on the transmission / reception registry and the exchange destination registry. Since there is no need to make system changes or operational changes, it can be handled in a timely and less expensive manner.
[0060]
[Second Embodiment]
In the present embodiment, a case will be described in which data to be sent to a destination is transmitted in a folder format. In the folder format, a file describing contents to be transmitted to a destination and message guide information are stored in one folder, and this folder is sent to a destination. The message guide information is created by the user or the integrated information exchange system 103.
[0061]
FIG. 11 shows the structure of the message guide information. FIG. 12 shows a specific data example of the message guide information. The message guide information is also composed of an element name and a value corresponding to the element name as in the previous registry, and can be described on an XML basis. The subject 1001 stores the title of the sent contents as a value. The main information file name 1002 stores the file name of the main information describing the contents of the transaction as a value. The sending type 1003 stores the type of information to be traded as a value. The message level 1004 stores a message handling level as a value. The destination 1005 stores the company code of the business partner as a value. This value is checked against the company code of the customer registered in the exchange registry. The destination name 1006 stores the official name of the business partner as a value. The partner person in charge name 1007 stores the name of the person in charge of the business partner as a value. The partner person in charge e-mail 1008 stores the email address of the person in charge of the customer as a value. The sender 1009 stores the company code that is the sender as a value. The creator 1010 stores the message creator and issuer as values. The creator e-mail 1011 stores the email address of the message creator or issuer as a value. The creation date 1012 stores the creation date and issue date of the file as values. The verification data 1013 stores data necessary for falsification detection as a value. This value stores the result of hash calculation. The action request 1014 stores the request content as a value when requesting the supplier to execute an arbitrary process. The action result 1015 executes a process requested by the business partner based on the action request, and stores the execution result as a value. The related information file name 1016 stores the file name of related information sent along with the main information as a value.
[0062]
In the process waiting area 104 shown in FIG. 7, a folder fldr20 is stored as a process target file. Referring to the flowchart of FIG. 6 again, it is determined whether the message guide information is included in the information read from the processing waiting area (S15). For example, if it does not have message guide information, it is determined as a file format, and if it has message guide information, it is determined as a folder format.Ru. That is, this determination is processing for determining whether the processing target is a file format or a folder format. Therefore, any other process may be used as long as it can be determined.
[0063]
Next, the integrated information exchange system 103 reads the message guide information included in the folder and obtains the value of the element name that will be required in the subsequent steps (S20). In the example of FIGS. 7 and 12, from the message guide information of msgd20 included in the folder fldr20, the value “F1” of the element “delivery destination” of “value 31” and the value “tmp20” of the element “main information file name” To extract. The above-described processing after S60 is executed based on the transmission / reception directory, but in this embodiment, the processing is executed with a value extracted from the message guide information. For example, in S60, the exchange destination registry is searched based on the delivery destination extracted in S20. Based on the destination “F1” of the folder fldr20, “value 21” is extracted as the exchange destination registry to be obtained. In S70, the folder fldr20 is written as the folder name “F1 + tmp20” in the intermediate area in the same state as that in the processing waiting area. The following processing is performed in the same manner as in the file format.
[0064]
When creating message information, prepare a template that is intended to be shared by everyone, and execute a creation assistant program that can be created interactively on the user terminal 101 according to the user's purpose of use. do it. Alternatively, it may be created by starting a web browser on the user terminal 101 to access the integrated information exchange system 103 and executing a creation auxiliary program for the integrated information exchange system 103 via the CGI. In the latter case, message information is created by displaying a plurality of candidates for each element and marking a radio box.
[0065]
[Third Embodiment]
In the present embodiment, as another method of using the message guide information, for example, an example of setting a message transfer route or requesting an action at a destination is disclosed. By the way, in EDI, it is essential to set the VAN relay route and express the final destination. If message guide information is adopted as this expression, the contents sent can be protected from eavesdropping and tampering at the relay destination.
[0066]
FIG. 13 shows an outline of the present embodiment. In this embodiment, information necessary for relay processing at the relay destination is stored in the message information section, and encryption is performed by an encryption method negotiated with the first relay destination. On the other hand, the texts and accompanying materials such as order data stored in a file different from the message guide information are encrypted by an encryption method decided with a trading partner who is the final destination of these materials. At the relay destination, only the disclosure part (public part) is decrypted to extract the message guide information, and the next relay destination and the encryption method negotiated with the next relay destination are specified and encryption is performed. Finally, everything is decrypted at the final destination. As described above, in this embodiment, information necessary for relay is set as a disclosure unit, and information related to a transaction is divided as a non-disclosure unit (non-disclosure unit) and separately encrypted. There is no eavesdropping or tampering.
[0067]
Next, the process flowchart of the present embodiment shown in FIG. 14 will be described. In the integrated information exchange system 103 of the sender, the message guide information created in the user terminal 101 is read (S1401). The final destination is specified from the read message guide information (S1402), and the encryption method negotiated with the final destination is specified from the encryption table stored in the file server 106 (S1403). Using the specified encryption method, the non-disclosure part is encrypted. A hash operation is performed on the encrypted non-disclosure part (S1405), and the operation result is stored as the value of the collation data 1013 of the message guide information (S1406). Next, the first relay destination is specified with reference to the message guide information (S1407). By referring to the encryption table again, the encryption method negotiated with the specified relay destination is specified. The disclosure unit is encrypted with the specified encryption method (S1409). The disclosure part and the non-disclosure part are included in a folder or enclosed in a mail and transmitted to the first relay destination (S1410).
[0068]
The first relay destination 120 receives this (S1411), decrypts the disclosure unit (S1412), and extracts the message guide information. A hash operation is performed on the non-disclosure part (S1413), and it is determined whether the value of the data collation part included in the message guide information matches the operation result (S1414). If they do not match, it means that the non-disclosure part has been tampered with or damaged, and it is reported that tampering has been detected (S1415). If they match, since no alteration has been made, the next relay destination is specified from the message guide information to be transferred to the next relay destination (S1416). The encryption method corresponding to the specified next relay destination is specified from the encryption table (S1417), and the disclosure unit is encrypted again with the specified encryption method (S1418). The disclosure part and the non-disclosure part are enclosed in a folder or enclosed in an e-mail, and transmitted to the next relay destination (the final destination when relaying is completed) (S1419).
[0069]
The destination 130 receives this (S1420), decrypts the disclosure unit (S1421), and extracts the message guide information. The sender is specified from the message guide information (S1422), the encryption method corresponding to the specified sender is specified (S1423), the non-disclosure part is decrypted with the specified encryption method (S1424), and The process ends (S1425).
[0070]
Note that the processing performed by the sender integrated information exchange system may be performed by the user terminal. In that case, the processing is as follows.
[0071]
1) Encrypt the text and accompanying materials using the encryption method and encryption key agreed with the final destination. If necessary, a hash calculation is performed on the text or the accompanying material, and a hash calculation result is added as the value of the element name “collation data” of the message guide information, which is used for confirmation of data alteration.
[0072]
2) Encrypt this text and accompanying material and message guide information using the encryption method and encryption key negotiated with the first relay destination and send it to the first relay destination. 3) At the relay destination, the decryption process is performed with the key based on the encryption decided with the issuer. Since the message guide information is disclosed, the value is referred to and the relay destination to be the next route is known. If necessary, a hash calculation of the delivery contents is executed and compared with the value of the element name “collation data” of the message guide information to check whether the data is valid. Encrypt the text and accompanying materials and the message guide information using the encryption method and encryption key negotiated with the relay destination of the next route, and send it to the relay destination of the next route .
Thereafter, this is repeated for each relay destination.
[0073]
4) At the final destination, the content sent from the relayer to the final destination is decrypted using a decryption key based on the encryption method of the relayer. If necessary, a hash calculation of the delivery contents is executed and compared with the value of the element name “collation data” of the message guide information to check whether the data is valid. Next, the body text and accompanying materials are decrypted using a decryption key according to an agreement encryption method with the issuer.
[0074]
In this way, route setting and encryption are performed using the message guide information, that is, by using the disclosure part and the non-disclosure part together, the reliability of commercial transaction data and wiretapping on the Internet are performed at the application level. , Tampering, impersonation, etc. can be dealt with. It should be noted that this information disclosure / non-disclosure mechanism can also be applied to specific departments within a company, and can be applied to, for example, exchange of confidential information such as personnel information.
[0075]
[Fourth Embodiment]
In the present embodiment, the message guide information is used to cause the destination to execute a predetermined process.
[0076]
For example, in a commercial transaction, it may be assumed that the transaction has been completed by delivery of a predetermined electronic document. In such a case, the transmission principle is considered as when the electronic document is transmitted, and when the counterparty actually receives the electronic document, that is, when the electronic document reaches the other party, it is regarded as the service. There is an attainment principle. If the transmission principle is adopted, if the transmission time is recorded in the transmission source system, it can be considered that the transaction has been concluded at the transmission time, and if the transmission time is attached to the other party together with the electronic document, the other party also performs the transaction. Can be confirmed. On the other hand, in the case of reaching principle, the reception time is recorded by the system on the destination side, the transaction is considered to have been concluded at the reception time, and if the sender is informed of it, the sender also confirms the establishment time of the transaction. it can. Thus, in the case of reaching principle, it is necessary to confirm receipt of the transmitted document, that is, some means for confirming that the transaction document has been delivered to the other party.
[0077]
Therefore, in this embodiment, it is possible to request an action that is desired to be performed at the destination, such as confirmation of delivery as described above. Specifically, the request is mounted on the message guide information and is sent to the destination. Send. At the destination, the requested processing (action) is executed based on the request described in the content of the guide information. This execution may be performed automatically as described above, or may be executed by a manual operation by a person in charge who displays an action request on the display of the person in charge. Thereby, for example, there is an advantage that the above-described confirmation can be easily performed in Web-EDI.
[0078]
FIG. 15 shows the concept of an action request using message guide information. Moreover, the flowchart of a process is shown in FIG. Currently, it is generally interpreted that the establishment of a commercial transaction by EDI is established by the arrival of data at a destination. Conventional EDI tends to omit acknowledgments under mutual agreement, provided that a reliable exchange procedure is employed. However, since Web-EDI uses the Internet, transfer reliability is low, and confirmation of the establishment of a commercial transaction cannot be guaranteed. In the present embodiment, for example, a delivery confirmation mechanism in Web-EDI is realized by the following method.
[0079]
In the example of FIG. 15, the message guide information includes the content requested for the delivery confirmation process to the destination.
[0080]
In the company b as the sender, the user terminal 101 starts a program for setting an action request in the message guide information (S1601). When the program is activated, whether the content confirmation request or the delivery confirmation request is displayed is displayed on the display device of the user terminal, and can be set interactively (S1602, S1603). Here, the content confirmation is a process of detecting falsification of the electronic document and returning the result to the sender. For the detection, collation can be used by using the hash operation described above. In the example of FIG. 15, it is set that execution of both content confirmation and delivery confirmation is necessary (YES). When the setting by the user ends, the setting program ends (S1604).
[0081]
Thereafter, transmission processing is performed according to the flow of FIG. For example, a hash calculation is performed on the main information file EDI01 (EDI data) (S1405), and the result (hash value) is stored as the value of “collation data” of the message guide information (S1406). In the system of the sending company “b company”, the main information file EDI01 (EDI data) and the message guide information are transmitted to the system of the sending destination “a company” (S1410).
[0082]
The system of the destination “company a” acquires the value of “action request” from the received message guide information (S1611), and determines whether content confirmation processing is requested based on the value (S1612). If requested, that is, if YES, a hash operation is performed on the EDI data (S1613), and the operation result is compared with the value of “verification data” in the message guide information (hash value at the sender) (S1614). The collation result is stored as the value of the element name “action result” of the message guide information (S1615). If company b, which is the sending source, registers and discloses the hash calculation program and collation program on the Web so that company a can download them, processing can be performed without creating a program at the destination. . It is determined whether delivery confirmation is required for the message guide information (S1616). If the delivery confirmation is YES, only the message guide information is transmitted to the sender b company (S1617).
[0083]
Based on the returned message guide information, the system of the sending company b collates with the sending history, manages the matching result as history information, and sends the matching result to the person in charge as a result of the matching. To do. Note that the system may be configured to retransmit if the result of the verification does not match. Further, history information may be displayed on a user terminal or the like so that the user can confirm delivery.
[0084]
By using message guide information in this way, it is possible to mutually specify operation requests and execution processes at the destination of the message, so that the type and content of exchanged messages can be changed without creating a program at the destination. Corresponding processing can be performed at the destination. Further, since the delivery result is added and returned to the message guide information at the time of sending, collation at the sending source is facilitated.
【The invention's effect】
According to the present invention, for example, the number of new destinations is increased, the manner of exchange with destinations is changed, the exchange method is changed such as regular exchange or exchange every time, the existing EDI procedure or the exchange of the Internet is changed. Even when the means is changed, it is possible to cope with these changes only by correcting the values of the exchange destination registry and transmission / reception registry or message guide information elements in the system. This eliminates the need for system development and makes it possible to respond to these changes in a timely and easy manner.
[0089]
Also in Web-EDI, since processing at the destination can be specified, the reliability of the establishment of a commercial transaction such as delivery confirmation can be ensured, and safe electronic commerce with an unspecified number of people is possible.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of a system configuration in the present embodiment.
FIG. 2 is a block diagram showing a schematic configuration of an integrated information exchange system and the like in the present embodiment.
FIG. 3 is a diagram showing the contents of a transmission / reception registry in the present embodiment.
FIG. 4 is a diagram showing the contents of an exchange destination registry in the present embodiment.
FIG. 5 is a diagram conceptually representing a processing flow in the present embodiment.
FIG. 6 is a processing flowchart of an internal file in the present embodiment.
FIG. 7 is a diagram showing an example of a processing target file in a processing waiting area in the present embodiment.
FIG. 8 is a diagram illustrating an example of storing data in a transmission / reception registry according to the present embodiment.
FIG. 9 is a diagram illustrating an example of storing data in an exchange destination registry in the present embodiment.
FIG. 10 is a processing flowchart of an intermediate file in the present embodiment.
FIG. 11 is a diagram showing the content of message guide information in the present embodiment.
FIG. 12 is a diagram showing an example of storing data in message guide information in the present embodiment.
FIG. 13 is a diagram conceptually representing the flow of encryption processing in the present embodiment.
FIG. 14 is a flowchart of data exchange in the present embodiment.
FIG. 15 is a diagram conceptually representing a flow of action request processing in the present embodiment.
FIG. 16 is a flowchart of action request processing in the present embodiment.
[Explanation of symbols]
100 ... business system
101 ... User terminal
102 ... LAN
103. Integrated information exchange system
104 ... File server processing waiting area
105 ... Intermediate area of the file server
106: File server send / receive registry and exchange destination registry
110 ... EDI network or the Internet
120: Relay destination server
130 ... Destination system
140 ... Other destination system
150 ... The entire system of the sender

Claims (2)

In file exchange apparatus for transmitting to a second information system connected to the file created in the first information system network,
A first storage device for storing a plurality of internal files created in the first information system;
Registry describing a company code, a file name, and an edit category for creating an intermediate file or a transmission / reception file to be transmitted to the second information system from the plurality of internal files stored in the first storage device A second storage device for storing
Sequentially reading a plurality of the internal file stored in the first storage device, it reads the internal file, or a file format without a message guide information describing the destination or the message guide information, Determining means for determining whether the folder format has
Wherein when the internal file by determining means is determined to be the file format specifies the registry according to destination information contained in the internal file. On the other hand, when the internal file is in the folder format filename the specified internal file of the message guide therefore the registry destination described in the information, in accordance with the company code and the file names are contained in the registry specified respectively in the case where it is determined Storage means for creating the intermediate file from the internal file and storing it in the intermediate area,
The reading from the intermediate area of the intermediate file, when creating a transmission and reception file for transmission from the read intermediate file in the second information system to identify the file name thus the registry of the intermediate file, the specific When the edit category described in the registry indicates that the plurality of intermediate files having the same destination are to be combined into one, the plurality of intermediate files are combined into a single transmission / reception. and send and receive file creation means for creating a file,
A file exchange apparatus comprising: a transmission unit configured to transmit the created transmission / reception file to the second information system. The storage means includes
If there are destination different plurality of internal message to the said internal file that is determined to be a file format, claims characterized in that it comprises a dividing means for dividing the internal file for each said transmission with the destination Item 2. The file exchange device according to Item 1.

Images