US 5,202,977 AGrant
EDI Translation System Using Plurality of Communication Processes and De-Enveloping Procedure Corresponding to Transmitted Communication Process
Issue Date:1993-04-13
•18 Claims
•30 Drawing Sheets
Abstract
A language-based electronic data interchange ("EDI") translation system provides the capability to receive data in a first format from a source, execute a script to translate the data into a second format, and transmit the data in the second format to a destination. The system employs a data tree structure to enable flexible translation between EDI documents and application documents with differing data structures.
Metadata
Assignee
- Premenos Corp.
Inventors
- Emmanuel K. Pasetes, Jr.
- Lew Jenkins
Application Information
Application Number:US 5520800
Filing Date:1990-07-13
Priority Date:1990-07-13
Art Unit:232
Classifications
IPC:
G06F 1521G06F 1524
Field of Search:
364345401;408;200 MS File;900 MS File500
Patent Drawings (30 sheets)
Description
Background of the Invention
This invention relates generally to Electronic Data Interchange ("EDI") systems and more particularly to a novel EDI translation system.
EDI can be defined as the paperless, computer application to computer application, inter- and intra-organizational exchange of business documents, such as purchase orders and invoices, in a structured, application-processable form. An EDI document can be sent directly to a business partner's computer over a communication line. EDI provides many benefits, including: a) speed--documents are sent and received almost immediately; b) accuracy--documents are received as they were transmitted, eliminating manual rekeying of data and attendant errors; c) cost reduction--rapid document turnaround allows more accurate planning of inventory levels and reduces inventory reorder time; d) increased productivity--employees are freed from paperwork and available for other tasks; e) simplified broadcast communications to multiple trading partners (such as sending a request for proposal); f) directness of communication--data is routed directly from the person placing an order to the data processing system of the receiving organization; and g) data integration--data in documents can be integrated directly with existing business information and data processing systems.
EDI involves three essential components: a) EDI standards; b) communications means; and c) an EDI translation system. EDI standards can be divided into formatting standards, dictionary standards, and communications enveloping standards. Formatting standards govern: a) what documents can be communicated; b) what information is to be included; and c) how the information is to be sequenced and presented.
Dictionary standards specify the meaning of the various elements being combined by the formatting standard. Communications enveloping standards define how to group documents together into larger units. Communications enveloping saves on addressing by grouping a number of messages meant for the same destination from a specific source. The communications enveloping standard can also provide password security not present in paper forms of communication. Any of the standards can be proprietary standards (limited to one organization and its trading partners) or common EDI standards (adopted by industry-wide or cross-industry users).
EDI standard documents from and to which trading partner data is converted have detailed definitions in the pertinent EDI standard. EDI standards are maintained by various standards maintenance organizations. Examples of such standards (and maintenance organizations) are the ANSI X12 standard (developed by the American National Standards Institute's Accredited Standards Committee's X12 group), the UN-EDIFACT standard (Electronic Data Interchange for Administration, Commerce, and Transport, an international standard based on ANSI X12 and the Trade Data Interchange standards used in Europe), the Uniform Communications Standards ("UCS"), and TDCC (developed by the Transportation Data Coordinating Committee). The standards are not invariant --they continue to evolve to meet the changing needs of information transfer.
Standards may have different terminology. There are however, similarities in the meaning associated with the terms. Whether termed a transaction set (ANSI X12), a standard message (EDIFACT), or a document (UCS), there is an electronic representation of a paper business document. A unique identifier code is assigned in the standard for each type of business document. As an example, in the ANSI X12 standard an invoice is referred to as X12 document number X12.2, with a transaction set identification code of 810.
EDI standards are developed using a set of abstractions: a) there is a unit of data called a data element; b) data elements can be grouped into compound data elements; c) data elements and/or compound data elements are grouped into data segments; d) data segments can be grouped into loops; and e) loops and/or data segments are grouped into a business document.
The abstraction is based on an analogy to a paper document. Paper documents can be considered to have three distinct areas: the heading area, the detail area, and the summary area. In many cases the detail area consists of repeating groups of data elements. For example, in an invoice, the elements are the items being invoiced and are usually printed as lines in a columnar list. In the terminology used in the standards, these repeating groups are loops. Grouping data elements into loops proves unwieldy because of the number of data elements that must be considered. The standards therefore group data elements into data segments and compound data elements.
Transaction set standards specify whether data segments are mandatory, optional, or conditional and indicate whether, how many times, and in what order a particular data segment can be repeated. The transaction set standard does not specify the content of individual data segments. Instead, a segment directory identifies the specific data elements to be included in each data segment. The segment directory is composed of a series of data segment diagrams, each of which identifies the data elements to be included in a data segment, the sequence of the elements, whether each element is mandatory, optional, or conditional, and the form of each element in terms of the number of characters and whether the characters are numeric or alphabetic.
Data segment diagrams include the following components. The data segment identifier identifies the data segment being specified. The data element separator is a user-selected character that precedes each constituent data element and serves as a position marker. The data segment terminator is a user-selected character used to signify the end of the data element. Element diagrams describe individual data elements.
Depending on the standard, element diagrams can define an element's name, a reference designator, a data dictionary reference number specifying the location in a data dictionary where information on the data element can be found, a requirement designator (either mandatory, optional, or conditional), a type (such as numeric, decimal, or alphanumeric), and a length (minimum and maximum number of characters). A data element dictionary gives the content and meaning for each data element.
EDI standard documents are electronically packaged or "enveloped" for transmittal between trading partners. Enveloping can be at several levels. The first, or innermost, level of enveloping separates one document from another. This is accomplished by attaching transaction set headers and transaction set trailers to each transaction set, or document.
At a second level of enveloping, documents can be packaged together into groups known as functional groups. An example of a functional group is a purchase order and an invoice, which are often sent together in both the paper and EDI worlds. Each functional group is packaged with a functional group header at its beginning and a functional group trailer at its end. This second level of enveloping is an optional level in most standards.
At a third level of enveloping, all functional groups to be sent to a single trading partner can be packaged together. This enveloping consists of an interchange control header and an interchange control trailer bounding either the packaged functional groups and/or the document.
The second component of EDI is communications means. EDI standard documents are transmitted electronically between trading partners' computers. The transmittal can be directly between trading partners, via a direct private network in which the computers are linked directly. Direct networks become difficult to maintain with larger numbers of trading partners. The alternative is to use a third-party, or value-added network (VAN). A VAN maintains an electronic mailbox for each trading partner that can be accessed by each other partner (with appropriate security restrictions).
The standard does not specify a communications standard except to the extent to which it describes the enveloping standard and the way in which transmissions can be acknowledged. There are de-facto standards such as IBM 2780/3780 BSC protocols used as file transfer protocols. Virtually every EDI VAN supports these protocols because of their pervasive use.
The third component of EDI is the EDI translation system, which performs at least the functions of data communication and document translation. Document translation is the most significant function in this component, and is implemented through an EDI translation software.
In practice, participants in EDI select and agree to use a proper subset of the document standard. Such agreements among trading partners are too numerous to be included in an EDI translation software. The EDI translation therefore needs to provide a way for the user to express how to process or generate the EDI document in compliance with the agreement.
One example of the need for compliance with a trading partner agreement is when one trading partner is to automatically post an EDI document to a processing system. A purchase order received from a customer could be booked automatically through the recipient's order entry system. Since the agreement and the interface requirements to the order entry system are not defined in the EDI translation software, the user of the EDI translation software must specify how to perform the translation.
The EDI translation software must provide three functions in conjunction with giving the user a means of expression for performing the translation. First, the software must provide mechanisms to navigate and manipulate EDI documents. Second, the software must be able to produce the records that are to be interfaced with the order entry system. Third, the system must provide the user with means to express (using these primitives) a complete procedure for transforming an EDI document into something that is compatible with the user's interfacing requirements.
In some cases a user may find it advantageous to automatically print an EDI document on paper in a format that is familiar to the user. For example, it may be helpful to print an invoice because the accounts payable system is implemented manually. As in the discussion above, the translation software does not include a definition of the format in which the user expects the output. The user must therefore specify this information.
The development of prior EDI formatting or translation software can be traced through three generations--translation software of the invention represents the fourth generation. The first generation of software was developed in the late 1970s and early 1980s to support a variety of private formats. The private formats were developed by large corporations to allow them to exchange business documents with their trading partners. The formats did not conform to any industry standards. The software used in these systems resembled subsystems of existing general business applications.
These first generation systems typically involved the exchange of private-format data files and associated data processing programs. Trading partners typically communicated directly with each other over private networks. Examples of first generation systems include General Motors' and Ford's automotive "release" systems and retail industry order processing systems, such as those used by Sears, J.C. Penney, and K Mart.
The second generation was characterized by the introduction of variable length, hierarchical document standards such as TDCC (used in the transportation industry) and UCS (used in the grocery industry), which created a need for a more generalized approach to translating those standards into computer-processable business forms.
Translators of this generation typically employed fixed data files transferred to an intermediate process that translated the document into a form usable by host applications. The translator's primary task was to convert the records in the data files from variable length format to a fixed length format that could be processed by traditional batch applications. These translators were known colloquially as "asterisk strippers" because they had no capability to manipulate data between records or to change the placement of data within records.
A major shortcoming of these second generation translators was that a large amount of additional intermediate processing was required, typically involving programming tasks to integrate the EDI document into an application system. Networks and major trading partners tended to overlook this problem in their efforts to expand trading partner relationships. The dissatisfaction of end users with the high software maintenance demands of this post-translation processing requirement led to the development of the third generation of software.
The third, or current, generation of translation software attempts to provide higher levels of transform capability so that an EDI document can be put into a form closer to the input required by the user's integrated application software. These translators provide for table-driven systems and "dynamic mapping."
The translation software uses a table structure to perform the translation. The tables consist of the standard data dictionary and syntax rules for the data segments and elements of a given EDI transaction set. The software selects the appropriate table to perform the translation for a specified EDI transaction set to be generated.
Dynamic mapping allows the user to identify the relationship of elements within a segment to fields in an application input document and vice versa. Instead of fixing record lengths, the systems allow the user to put data elements into different data files in any location. Rather than being limited to a single fixed length file in a transaction set, the user can select data from multiple files, in any order within the file, and present the data to the translator.
The ACS Network Systems EDI 4XX product, available from ACS Network Systems of Concord, Calif., is typical of third generation software products. The data communication component of ACS 4XX provides the means to generate and maintain a communication line directly with a trading partner or to a third party data network and the means to control the process of sending and receiving documents to and from trading partners. The translation component of ACS 4XX translates incoming standard business documents from an EDI Standard format to a format usable by applications programs and reverses the process for outgoing data.
These third generation systems suffer from several problems. First, the dynamic links between fields in application databases and data elements in EDI documents are unconditional--the field mapping or linking is construed to be constant in any given application. The systems are therefore unable to represent the conditional expressions that appear as "notes" in almost all standards. For example, a segment definition may have a conditional note that specifies that either the second data element must be present or both the third and fourth elements must be present. Although some translators have attempted to comply with these notes through the actual translator software code, this technique has proven inadequate and difficult to maintain as standards and documents evolve. Further, the standards definitions employed by these systems have relied on a data base schema of the standards definition. This is a relatively inflexible approach that does not readily accomodate the continual evolution of the standards.
Second, these systems assume that EDI input will require non-EDI, or application, output. This prevents the systems from acting as true translators, capable of communicating any type of input and any type of output. Similarly, the communication components of such systems assume that their only interfaces would be with EDI-capable networks. This precludes straight file transfer capability between computers, and prevents the systems from acting in a terminal emulation mode to interface with other computers. Further, the communications interface does not provide the structure for unattended operation; the systems cannot act as passive communications systems for receiving calls from outside systems. There is also no method for allowing an outside application to send the system data for translation into EDI format.
Third, there can be structure or sequence clash between the EDI document and the application transaction's structure requirement. The previous generation systems provide a tool for specifying transformation of data through the use of a mapping program. The mapping program includes assumptions about the correspondence of structure and sequence between source data and target data. The tool therefore cannot be used to translate data with a structure or sequence clash between the source data and target data.
EDI documents are defined using a specification that prescribes a sequence and structure to the document. When the application transaction's structure and sequence differs from the corresponding EDI document specification, the user is required to develop a set of programs that deal with the structural or sequence difference to achieve a seamless interface to the application.
For example, a retail store may send to a manufacturer purchase orders with store distribution specifications attributed to each line item. If the manufacturer requires separate paperwork for each shipping location, the grouping of data as expressed by the EDI document clashes with the manufacturer interface requirement. The clash is caused by the different structure assumed when producing the EDI document (which specifies how to distribute the order for a specific item to multiple shipping locations) and the structure assumed by the order entry system (which assumes that an order document contains items for a specific shipping location).
Third generation systems do not attempt to address this problem. The general approach is to produce a file that contains the necessary data in a rigid, hierarchical structure and to force the user to develop a set of programs using whatever programming language and utilities are available to change the structure. Some of these programs can become very complicated.
Fourth, third generation translators generally have limited pattern matching capability. This reduces the scope of acceptable types of input. The pattern matching of application transaction files is very limited. Records are identified using a strictly specified value in a specific position in the record. Therefore, unless the application transaction file created from the computer application contains these very specific value(s) (i.e, H01, H02, D01, D02, etc.), an interface program must be developed to supply data to the translator.
Fifth, the current systems have strict one-to-one correspondence between source and target documents. The systems therefore cannot receive a document, such as a shipping notice, and generate multiple transactions, such as a receiving notice, an inspection notice, and an invoice notice.
Sixth, prior systems have limited capacity for evaluating performance errors. For example, a user who creates a mapping specification with a table driven or dynamic mapping scheme may find during operation that some of the data elements are output incorrectly--the value of a data element for one document may turn up in another document. It can be difficult for the user to find the source of the error because the systems provide no debugging mechanism for finding the problem. While a debugger capability could theoretically be added, it would be onerous to implement because the structure of the systems (being non-language based) is not susceptible to a debugging facility.
Finally, the third generation translators limit operations to simple assignment semantics. There is no provision for performing arithmetic operations on source data elements to produce a target data element. Performing logical operations or string manipulation are usually not provided.
Summary of the Invention
The invention overcomes the problems with the prior generation systems with an EDI translation method that receives data from a source in one format, executes a script to translate the data into a second format, and transmits the data in another format to a destination. The system has the ability to transform input data from, and into, virtually any format and to produce more than one output for each input document. The system employs a tree data structure and a script of translation instructions to overcome the hierarchical data structure limitations imposed by the prior generation systems.
The system can pattern-recognize records that are not explicitly differentiated. It provides flexibility in using virtually any communication system to communicate EDI as well as non-EDI documents. The system employs a model that assumes that both input and output are to be communicated and is therefore not constrained for use with a particular processor, but can instead act as a true communication front end.
The system addresses the difficulty that prior systems had in expressing syntax notes associated with segments in relational terms. This is done by expressing the notes using language construction of logical operators on data elements. For example, the semantic expression "(-or 2 (-and 3 4))" means "either the second element or both the third and fourth elements must be present."
The system addresses the inability of prior systems to handle structure clash between an EDI document and an application's data structure requirement by providing data and control structures. The control structures include such basic structures as executing a series of commands while some predicate condition exists.
The system supports data structures such as multi-dimensional arrays and an EDI tree data structure. The EDI tree data structure represents an instance of an EDI document. The tree provides random access operation on the document allowing the user to specify the sequence in which access to the EDI document is to be made. The system further provides a set of access primitives. These two tools allow the user, for example, to read a document and process it repeatedly, once for each of several shipping locations.
The system facilitates support for relational level notation in EDI document definitions that specify hierarchical nesting, such as EDIFACT standard documents. It supports implicit as well as explicit notation in EDI document definitions. The tree access notation enables the EDI programmer to reference EDI data elements so that a language can support it as one of its data types. Without such a notation, support for EDI in a programming language would be difficult. Nesting and repetition of segments is discussed in ISO Publication 9735, pp. 6-9 (1988).
The system also overcomes the limited ability of prior systems to pattern match data by providing a pattern matching capability that can read a fairly large set of patterns that follow an LL(1) grammar (for a description of LL(1) grammar, see Aho, Sethi, & Ullman; Compilers: Principle, Techniques and Tools, pp. .sctn. 4.4 (Addison Westley 1986). The user can formulate a filemap definition and record definitions to express the expected pattern. The system also allows the user to generate as many target documents as required from a single source document.
The system also overcomes the failure of the prior systems to provide a debugging capability. Since the system is language based, a conventional debugging facility can be readily provided.
Finally, the system has a broader range of operations performed than the prior systems and provides expressions such as those involving logical and arithmetic operators and string manipulation. Data transformation is enabled by use of an assignment statement. The assignment statement accepts an expression on the right hand side as in:
This statement specifies that a is computed from b plus c. The elements a, b, and c could be elements from the source or target, although a is likely to be an element of the target and b and c are likely to be elements of the source. In this example, a "+" operation is used in the right hand side expression. The system supports many such operations including "substring" to extract a portion of a string. These operations are termed language "primitives". The set of language primitives depends on the nature of the problem. However, by employing a programming language implementation, the invention allows a user to combine these basic operations into complex expressions. This expressiveness allows the user to specify more complex transformations.
The system is organized into four component work centers: a) Communications Interface (having a communication session as its input work unit); b) De-enveloping (having an interchange as its input work unit); c) Translation (having a document as its input work unit); and d) Enveloping (having an enveloping request as its input work unit).
The communications interface work center uses a script to schedule a communication session and describe how to break up the contents of the communication into units of de-enveloping work.
The de-enveloping work center divides a communication interchange into its component documents. It also performs a routing function, routing documents to the required destination.
The translation work center manipulates an incoming document into the format that is expected by another system. It can convert EDI data to a format that can be printed or used by application programs and can convert a file created by an application program to a standard EDI format. It is implemented as an interpreter or compiler that understands translation primitives and can be used with a script to perform transformations on many kinds of data. In the illustrated embodiment, each of these work centers are implemented using a novel EDI programming language, referred to herein as the e-language.
Brief Description of the Drawings
FIG. 1 is a block diagram of data flow through the EDI translation system.
FIG. 2 is a block diagram of a hardware implementation of the invention.
FIG. 3 is a sample communication script.
FIG. 4 is a sample EDI de-enveloping script.
FIGS. 5A, 5B, 5C, 5D and 5E are a sample application de-enveloping script.
FIG. 6 is a graphic representation of the organizational structure in which files are stored before enveloping.
FIG. 7 shows sample application data input for a translation operation.
FIG. 8 shows sample EDI output corresponding to the input of FIG. 7 as produced by the script shown in FIG. 13.
FIG. 9 is a document definition for an X12 810 invoice implemented in the e-language.
FIG. 10 shows two sample segment definitions implemented in the e-language.
FIG. 11 shows two sample element definitions implemented in the e-language.
FIG. 12 shows three sample data type definitions implemented in the e-language.
FIGS. 13A, 13B and 13C show a sample translation script for translating an application document to an EDI document.
FIGS. 14A, 14B, 14C, 14D and 14E show a sample translation script for translating an EDI document to an application document.
Detailed Description
The system is organized into four component work centers: a) Communications Interface; b) De-enveloping; c) Translation; and d) Enveloping. The flow of data through the system is illustrated in FIG. 1. Data flows into the system through communications interface 1. It then flows to the de-enveloper 2, to the translator 3, and to the enveloper 4. From the enveloper, the data flows back to the communications interface and thence out of the system.
In the illustrated embodiment, a data item flowing through the system can be considered conceptually as a package with a packing slip. As the data item is processed by each component of the system, some information is read from the packing slip, and additional information is written to the slip. The information that appears on the slip determines how the package will be processed. The system uses a "routing form" as an abstract representation of the packing slip. A routing form follows a data item through the system, and a component can both read from and write to the routing form. The behavior of a component may depend upon information that is read from the routing form.
The routing form provides for the following information: a) interchange sender; b) interchange receiver; c) functional group sender; d) functional group receiver; e) node (the network or application used); f) facility (the communication protocol); g) content type (EDI, application, or text); h) document type (transaction set identifier); i) translation script; j) functional group; k) error message; and l) functional acknowledgement flag. The information is placed in the routing form in the following order: a) in the communications interface--the node, facility, and content type; and b) in the de-enveloper--document type, senders, receivers, functional group, functional acknowledgement flag, and translation script. Error messages are written to the routing form by whichever module detects the error.
The EDI translation system can operate on a variety of hardware. In the illustrated embodiment, the system operates on a microcomputer having a 20 MHz Intel 80386 processor, 4-8 MB of RAM, one or more serial ports, a 100 MB fixed disk drive, a 2400 Baud modem with V.22 VIS/MSP protocol, and having a UNIX operating system. The system may also be operated on a local area network, with different machines implementing different functions of the system. For example, one machine can serve as the communications interface while another provides file storage.
As shown in FIG. 2, the system operates on microcomputer 10, which is connected to one or more EDI networks 20 and a host 30. The connection 40 between the system and the host is a synchronous connection such as a Bell 208A modem or another line driver. EDI data is transmitted to and from trading partners via the EDI networks, while application data is transmitted to and from applications operating on the host. All data transmission between the system and either the host or the EDI networks is routed through the communications interface work center, shown at 50.
In an alternate embodiment, the host on which the applications are operated and the microcomputer on which the EDI system operates are combined, so that applications are operated on the same machine as the system.
In the illustrated embodiment, each of the EDI system work centers is implemented in the e-language. Of course, the work centers could be implemented in other languages, such as Lisp or C++, although with greater difficulty. The e-language uses arithmetic, boolean, functional, and control structures similar to those in BASIC, Pascal, and COBOL. In addition, the e-language contains functions and data structures unique to EDI processing. These specialized functions include facilities for converting an EDI document to an EDI data tree and for performing the reverse operation. The e-language also contains commands to determine the status of various parts of the EDI system, and to perform low-level operations on these parts. These functions, and other aspects of the e-language, are described in the "e" Programmer's Reference Manual, attached as an Appendix hereto and being a part of the disclosure of this application.
The e-language allows the user to perform pattern-matching operations. For example, the e-language can be used to describe the format of an application file and to select the portions of the file to be used. This allows the production of a customized EDI document from an application file.
The e-language is structured in the manner described in the attached Appendix. The syntax of the e-language borrows some of the command names and clauses from BASIC and COBOL and general syntax structures from Pascal.
The system employs the concept of a data stream. A stream is a source of input or a destination of output. An input/output function generally takes a stream as one of its arguments. When a program is executed, a default input stream and a default output stream are created. Stream objects are bound to one or the other stream. Other streams can be opened during a program execution that can be bound to variables used in other run-time calls for input/output purposes.
Communications Interface
The communications interface has two parts: a) a scheduler; and b) a set of facilities drivers. The scheduler is a program that references a user-created table to determine when to communicate with sources of information (such as a trading partner or an application). The actual communication is done through a facility driver. All of the mechanics of transferring files via a given communication protocol are packaged in the facility driver, and are accessible to the user through a communication script. The script, which can be written in the e-language, specifies the procedures to be used to create a de-enveloping work unit.
The communications interface work center defines the concept of a logical connection to the outside world as a node. The logical implementation of the connection is a communications facility. Two kinds of nodes are defined: a) an EDI connection (or EDI network); and a non-EDI connection (or application). Thus, in FIG. 2, EDI network 20 and an application running on host 30 are each nodes. The node name is used to symbolize the network or application, binding the name to the specific communication facility that is used to execute the communication. In the illustrated embodiment, the system assumes that communication facilities exist in the form of hardware and software. These facilities are not part of the system; the system interfaces to the facilities through facility drivers, which are part of the system. The interface consists of a driver and a script. A driver is a program capable of communicating with the specific communication facility. This driver supports a set of primitives that is supported by the e-language. Communications packages usually have either a programming interface or a user interface. The driver must be interfaced to whichever interface the specific communication package has. A script is a program capable of configuring the communication package. This gives the system the ability to set up and use the proper script.
The different facilities to which the system could interface are numerous. It is therefore economical to have interfaces for common facilities such as Unix Mail, Unix File System, and Remote Job Entry. The operations provided by the interface depend on the capabilities of the facility, but as a minimum include send and receive primitives.
A facility client is capable of both sending and receiving files. The EDI translation system can be connected to a network node using a Binary Synchronous Remote Job Entry facility. The facility may be implemented by software such as the AT&T Synchronous Gateway. The gateway uses an account name to manage communication. When establishing communication with the network node in conjunction with the gateway, the network node is mapped to an account name, thus integrating the gateway communication software with the EDI system. A similar correspondence can be established between an application node and the gateway account. Other facility clients can include Unix Mail, X-MODEM, and the file system in the operating system.
Each node can also be assigned a schedule specifying the times when activity with the node is expected to occur. The schedules are derived from configuration specifications that users provide. The configuration specifications are configuration texts, rather than e-language scripts. Each schedule specifies the time and an associated script that is expected to be executed. The script, which, in the illustrated embodiment, is implemented in the e-language, contains details of how the communication is to be performed.
A sample communication script for a Unix Mail interface is shown in FIG. 3. The script embodies four primitives. The first, shown at 8110, is Envelope, which request that envelopes be made for data that is ready to be transmitted through the Unix Mail. The ATTMAIL parameter, 8120, identifies the network. The enveloped data is returned as a data stream. The second primitive is SendUnixMail, shown at 8210, which sends the enveloped mail messages in the stream out through the Unix Mail facility. Next, ReadUnixMail, shown at 8310, picks up from ATTMAIL any mail message, and develops a list of mail messages. Finally, MakeMail Interchange, shown at 8410, converts a mail message into an interchange.
This example illustrates the use of interface primitives that were developed as part of a Unix Mail driver. The example uses the Unix Mail facility to send and receive messages through the ATTMAIL network. If the pertinent parameter (such as 8120) were changed, the script could equally well use any other network. Scripts for simply reading mail without sending mail, or sending mail without reading mail, could also be developed and scheduled to execute at different times.
The scheduler is driven by a scheduler table, in which the rows are nodes and columns are facilities. Each cell in the table can contain a schedule instruction. The schedule instruction can specify that a communication should occur at a fixed interval or at a fixed time.
A facility is an interface with specific communication resources provided in the host machine. The facility includes information about how to use the communication resource. Because each facility is programmable, and therefore variable, a command must be issued to specify the communication script that the facility client should execute. The script is specified in the scheduler table.
Data received from a communication session is sent to the de-enveloper as a unit of work. The unit of work is assigned a script name, which identifies the de-enveloping procedure that will be used to divide the contents of the communication session.
The system also provides the structure for unattended operation, acting as a passive communications system for outside systems to call and to send it data for translation into EDI. The structure, based on the driver and configuration described above, allows the system to take advantage of existing communications packages. One of the standard facilities provided with the system is a file system communication facility. The facility consists of a listener that polls specified directories for files and a depositor that places enveloped data into a target file or separate files into a target directory. Files with specific names or files found in a specific directory are picked up by the system. The file name or the source directory determines the type of data and the requirements for de-enveloping.
The user can therefore use the file system communications facility in conjunction with any communication system that places incoming data into a specific directory to simulate incoming support. The user can also develop a program to transmit data deposited in a particular directory or file to the communication program.
These capabilities provide the tools for running unattended for communications initiated by another party. The system provides a scheduling mechanism for each network interface and application interface to allow the automatic scheduling of communications initiated by the system. The scheduling is done using a facility like timer services provided by some operating systems, such as the "cron" facility of the Unix operating system, which provides for the execution of specified commands according to a time schedule.
De-Enveloping Work Center
When incoming data contains multiple documents in one unit of work, the de-enveloping work center of the EDI system must break the work into single documents. The de-enveloper has three purposes: a) to strip off the enveloping layer and divide a communication interchange into its component documents; b) to identify the sender, receiver, and transaction type; and c) based on that information, determine the type of transformation needed and the destination of the transformed document, saving the enveloping information as attributes of each document. The process is script driven. The content type and the de-enveloper script are determined by the communications process; the identity of the interface is known at the time the communications process located the data. If the data was located by a network interface, the content type is EDI and the EDI de-enveloper script is invoked for that network interface. If data from an application interface was located, the content type is application transaction and the application transaction de-enveloper script is invoked.
Script selection is performed through a table, the table having nodes as rows and the type of data as columns (being either EDI data, applications data, or text). In the case of EDI data, the de-enveloper work unit (an interchange) is de-enveloped into its component functional groups and then into transaction sets. Each individual transaction set is then considered a separate translation work unit. In the case of an application file, the report is divided into individual invoices. Each individual invoice is then considered a separate translation work unit. The system has the capability to handle text files, but performs no de-enveloping, translation, or enveloping on them.
The de-enveloping process is also script driven. Different scripts, and methods, are used depending on whether the data is EDI or non-EDI. The system gives the user the capability of defining each script to meet the user's particular requirements.
For an EDI input, the de-enveloping script uses the following general procedure. First, the start of the file is marked. Then, for each found interchange, the following steps are taken. First, data from the last mark to a position just prior to the interchange envelope is returned as a de-enveloper unit of work, considered an application transaction with the same name as the network interface. Second, the interchange envelope is read and an attribute list consisting of interchange values is populated. Third, for each functional group envelope found within the interchange envelope, the following steps are taken. First, the functional envelope is read and additional attributes are populated. Second, for each document envelope found within the functional group envelope, the following steps are taken. First, the document envelope is read and document attributes are populated. Second, a mark is set. Third, a translation unit of work is created using data from the mark to the end of the document. Fourth, additional document attributes are populated from the end of the document. When no additional documents envelopes are found, additional functional group attributes are populated from the end of the functional group. When no additional functional groups are found, a mark is set. The entire process above is repeated until no more interchange envelopes are found.
A sample de-enveloping script for EDI data is shown in FIG. 4. The primitive OpenInterchange, shown at 9120, specifies the types of interchange envelopes expected to be present in the data (ISA interchange envelope types in the example). The variable "cursor," shown at 9110, is used to point to the current position in the input/output stream. The primitive "Deenvelope," shown at 9210, extracts a document from a found envelope. The example script extracts documents from all envelopes that it finds.
The de-enveloper reads just enough of the interchange file to extract a transaction and then sends the data obtained to another work center for further routing through the system. In general, data is passed from one work center to another using queues. A configuration file is used by all the work centers to determine what work centers are available to the system.
The de-enveloper tracks the interchange and functional group information as it processes the interchange. Users can access the information through the element reference notation, as described below.
In the case of an application transaction, the de-enveloping process is different. The user must specify how the data is to be divided into individual transactions because the patterns that specify the boundaries between documents are not known. The user employs the pattern matching capability of a function termed SPLIT to split off the individual transactions. The pattern matcher is implemented in the e-language using a technique similar to the recursive descent LL(1) parsing technique, with backtracking to support optional constructions. The pattern matcher uses a specification termed a filemap to describe the structure of a file and a record specification to describe the structure of each type of record found in the filemap.
The filemap describes the order of records found in the incoming file. The record definition describes the structure of each record type. The language borrows from COBOL picture clauses for specifying the data type of each data element. The structure of the mapfile is shown below:
Using a filemap specification, a system user can specify both structure and sequence with minimum ambiguity.
The e-language includes three primitives used in dividing application documents from an application communication. The primitive used to split off documents is SPLIT <stream, filemap>, which reads the file and processes it using the filemap. Additional primitives MARK.sub.-- END, DO.sub.-- SPLIT and ROUTE.sub.-- TO.sub.-- xxx are used to do perform functions similar to those provided in the EDI de-enveloping procedure. These primitives are to be used in the actions associated with records matched by the filemap specification. MARK.sub.-- END marks a possible end of a document. DO.sub.-- SPLIT splits out the document identified with the beginning and end marks and places a new begin mark immediately following the previous end mark.
Application documents are separated by selective use of these primitives in the filemap. For example, a communication file may contain a set of invoice reports. These reports are printed a page at a time, but may be printed in multiple pages. The filemap specifies how to pattern recognize each page and to extract from each page the trading partner's identifier. A begin mark is set at the beginning of the first page and an end mark set at the end of each page. If more than one sequential page includes the same invoice identifier, the SPLIT continues to pattern match until it reaches a page for which the invoice identifier is different, then resets the end mark to be at the end of the last page of the group of pages with the same invoice identifier. The DO.sub.-- SPLIT primitive is then used to divide out the invoice between the begin and end marks. A sample de-enveloping script for application data is shown in FIGS. 5A to 5E.
The script first identifies the filemap specification, "invoice" to be used, as shown at 10110. The "record [name]" commands, as at 10120, indicate that certain commands are to be executed when the named record is found in the input data stream. The "printf" commands shown, as at 10121, print out specified information for diagnostic purposes. As shown at 10300 in FIG. 5B, each time a record "total3" is found (10310), an end mark is set (10320). As shown at 10400, the script then splits the record with the DO.sub.-- SPLIT command (10410). The script then determines at 10420 the receiver, using the data element "custnum" shown at 10121 in record "terms" at 10120. Then, in line 10430, the script resets the start marker. In the following steps, as at 10440, the format for each record to be read is defined.
At 10520 in FIG. 5E, the script directs that each invoice be split, keeping a list of items in the variable "vfl," using the filemap "invoice" and the data from the standard input stream "stdin." Finally, at 10600, for each item in the list "vfl", the item is routed to the translation work center (10640).
As noted in the preceding script, the de-enveloping work center also routes documents to the required destination. The routing function is controlled by a routing table. For an EDI document the following document elements determine how to process the document: a) sender, found from the interchange or functional group envelope; b) receiver, from the same source; and c) document type, which is from the document envelope. Sender and receiver may be known by different names from different sources. The system resolves the different aliases into a specific enterprise using an alias table. For an application transaction, the following data elements determine how to process the transaction: a) sender, derived from application interface profiles or from document scanning; b) receiver, from the same source; c) the application transaction, which comes from the document.
The user specifies how to process translation units of work by entering in the routing table the following information: a) script to be used in the translation; b) the destination network or an application transaction; and c) sender and receiver. This information is found in the routing slip for the work unit.
Translation Work Center
The translation work center manipulates an incoming document into the format that is expected by another system. It can convert EDI data to a format that can be printed and/or used by applications and can convert a file created by an application to a standard EDI format. Unlike existing systems, there is complete flexibility in the ability to translate. It can convert from one EDI format to another or from one application format to another. In the illustrated embodiment, it is implemented as an interpreter that understands primitives of the e-language and is used with a script written in the e-language to perform transformations on many kinds of data. Although shown as implemented as an interpreter, implementation through use of a compiler is also possible.
The translation work center is explained in the context of a sample conversion. A sample input document, an invoice, will be converted from the application format shown in FIG. 7 to an EDI format, which is an EDI 810 document, as shown in FIG. 8. A document definition is created in the e-language that describes the structure of the document and a corresponding bare tree is constructed. Data is read from the input document and mapped onto the bare tree. The data is then mapped from the populated tree into the EDI 810 document format.
The EDI system manages an EDI data stream with an EDI reader and an EDI writer. The purpose of the EDI reader is to develop an EDI data tree from an EDI document expression. The e-language provides the capability to make a bare tree corresponding to a particular document and for creating an EDI tree from a virtual file whose body is a document.
Trees are one type of data variable used in the e-language. In turn, data variables are one type of e-language In turn, data variables are one type of e-language program element. The elements of a program written in the e-language are described below.
Lexical Elements--The e-language recognizes a character set that includes alphabetic characters, numerical characters, and special characters. Identifiers are names given to variables, functions, subroutines, patterns (records), and filemaps in the program. Constants can be string or numeric constants. Reserved words are words with special meanings in the e-language that cannot be used for program names or identifiers.
Variables--A variable is a name used to refer to objects in the system. The object may be a single element or multiple elements. The three variable types available in the e-language are arrays, records, and trees. Arrays are collections of data values whose individual members are accessed via a numeric index. A record is a compound data structure containing multiple values, or fields, of various types.
As described in more detail below, trees are composed of nodes, with an uppermost node called a root node (or root). Branches below a node are called the node's children or branches. The lowermost or outermost nodes (those with no children) are called leaf nodes or leaves.
The e-language provides the capability to make a bare tree appropriate for a particular document and to create an EDI tree from a virtual file whose body is an document. In both cases a pointer to the root of the tree is created; by assigning pointers, any node of the tree can be referenced.
Expressions/Operators--Expressions are constructs having a well-defined value in the context in which they appear. The simplest expressions in the e-language are identifiers, string constants, function calls, array references, and tree (or node) references. Operators are characters that designate mathematical or relational operations.
Statements--Statements are instructions to the computer to perform some sequence of operations. The types of statements available in the e-language include: a) assignment statements; b) conditional statements; c) iterative statements; d) IF statements; e) FOR statements; f) WHILE statements; and g) subroutine calls.
Functions--Functions are collections of instructions that return a value. Functions include multi-valued functions that return more than one value, subroutine definitions, and filemap definitions. Filemaps are function-like objects that perform pattern-matching on files. A filemap accepts as input a list of records and/or other filemaps, and matches items in the current virtual file with the given records or filemaps. Fields in a record that is successfully matched are bound to the items in the input file they match. The program can then access the values of the fields elsewhere.
Trees are information structures particularly well suited to the structure of documents. By representing documents as trees, the contents of the documents can be accessed in an expressive and convenient form. The tree is like a file buffer, with a definite structure, and in the e-language, a variable can be assigned to the tree.
Every node in an EDI tree can be classified as one of the following types. An area consists of a non-empty sequence of segment blocks and loop blocks. It can be considered as the root of an arbitrary subtree. Its subnodes are segment blocks and loop blocks. A segment block represents a block of repeated segments with identical segment identifiers. Its subnodes are segment bodies. A segment body represents a single segment within a segment block. Its subnodes are the elements of the segment. A loop block corresponds to one or more iterations of a loop. An iteration of a loop is the sequence of segment blocks for the segments marked as a loop in a standard document. The subnodes of loop blocks are loop bodies, analogous to segment blocks and segment bodies. A loop body is an iteration of a loop; its subnodes are segment blocks. An element has the same meaning for an EDI tree as it has for an EDI standard--it is the smallest logical portion of a segment. Some EDI standards also employs the concept of composite data elements, which have similar semantics and implementation to segments.
Any node in an EDI tree can be referenced by specifying its path. Symbols used in defining EDI documents are used to develop the path specification. Three operators are used: separator, selector, and arrow operators. Separator operators separate nodes in the tree, while selector operators select a loop body, segment body, or element in that node. An arrow operator points to an NTE segment or a subtree of a hierarchical level loop. An NTE segment is designated in the X12 standard as a floating segment, one that can appear anywhere within a document. Hierarchical levels, used in some EDI documents, show the relationships among different levels of detail in a shipment, such as pallets on a truck, part numbers on the pallet, cartons of a particular part number, etc. Such a notation is necessary because an NTE is considered an appendage to any segment body and an HL subtree is considered an appendix of an HL loop.
An EDI tree is constructed based on a document definition. A document definition for an X12 810 invoice transaction set, implemented in the e-language, is shown in FIG. 9. The definition is divided into a heading area 1100, a detail area 1200, and a summary area 1300. The heading area includes segments, such as segment ST, shown at 1101, and loops, such as loop.sub.-- n1, shown at 1110. The document definition gives the "grammar" of an invoice document as agreed to by the X12 committee.
Segments and elements can also be defined as text files in the e-language. Two sample segment definitions are shown in FIG. 10, expressed in Lisp. These segment definitions are for the CUR segment (shown at 2100) and for the N1 segment (shown at 2200). Each segment definition identifies the name of the segment, such as N1 shown at 2205, and the title, such as "NAME," shown at 2210. It specifies a list of document definitions in which the segment is used, as shown at 2220. This line indicates that the N1 segment is used in the 81O document definition (indicated at 2225).
The segment definition next defines a syntax. The syntax definition is used to evaluate a particular segment expression to determine whether it complies with the standard. This addresses the shortcoming of prior generation translators in inadequately handling the conditional notes in segment definitions. For example, segment N1 may have a conditional note that either the second data element must exist or both the third and fourth data elements must exist. This note is implemented in the syntax shown for segment N1, shown at 2230. The conditional is expressed in the statement "((-or 2 (-and 3 4)))," where the numbers refer to the data elements.
Next, the segment definition specifies a list of elements, as shown at 2240 for the N1 segment. Each element is indicated as being either mandatory (M), optional (0), or conditional (C). This ties into the syntax. For example, since the syntax provided that either the second data element or the fourth and fifth data elements must exist, these data elements (element numbers 93, 66, and 67) are indicated as conditional. Element 98 is mandatory.
The position of an element in a segment is used in the e-language to refer to the data element. In this element reference notation, the path specified by "tree HEADING LOOP.sub.-- N1[3]N1[2]" refers to the second element in the N1 segment, which means that element number 93 is being referenced.
Finally, the segment definition specifies the type and version of the EDI standard being used. As shown at 2250, the N1 segment definition is based on version 0.0 of the X12 standard.
The elements themselves can also be defined. Two sample data element definitions (also in Lisp) are shown in FIG. 11 --element 93 is defined at 3100 and element 98 is defined at 3200. This definition allows the EDI system to verify whether the format of an input data element conforms to the data definition. The element definition includes the name of the element (e.g., 93, as shown at 3111), the data type (e.g., alpha-numeric, or AN, as shown at 3112), the minimum (3113) and maximum (3114) length, and the title (e.g., NAME, as shown in 3115). Next, the definition specifies the segments in which the element is used, as shown at 3120. Finally, the type and version of the EDI standard is specified in 3130.
As shown in the element definition for data element 98, a list of possible values, shown at 3220, can be included that is used to validate the data element values.
The e-language can be used to describe the document, segment, and element sets that make up EDI standards such as X12. New document, segment, or element types can be defined, or existing definitions can be modified. The e-language allows the user to express the description in a way resembling the descriptions given in the EDI X12 and TDCC Standards books. Each element definition includes a specified data type, such as the "AN" or alphanumeric data type specified for data element 93 at 3112 in FIG. 11. These data types are not hard coded in the e-language, but rather their format is defined by a regular expression, which is a notation well known in the art. Four sample data type definitions are shown in FIG. 12. The definition for a numeric data type with floating decimal is shown at 4100, the definition for a floating point decimal data type is shown at 4200, the definition for an alphanumeric data type is shown at 4300, and the definition for the different classes of data types found in a data element definition, and the verification generator associated with the class, is shown at 4400. For example, data types specified as "n2" will match the definition [nN][-9] at 4410, so that a pattern will be generated based on the X12-n-verification-generator. The verification generator accounts for the minimum and maximum lengths and scaling factors in developing the pattern. The generated pattern is later used to verify that data read from an EDI document matches the pattern.
These regular expressions are evaluated when the data element is read or assigned to a tree. This means that new data types defined by EDI standard-setting organizations can be incorporated into the system with little difficulty. Further, a sufficiently sophisticated user could introduce new data types.
An EDI tree can be constructed based on the document definition using one of two e-language primitives, READ EDI (or EDITOTREE) and MAKEDOC. Both primitives are based on the document definition as specified by its document identifier (such as 810), by the standard (such as X12), and by the version of the standard (such as version 2.2). The EDI system uses a hunt sequence associated with the version to resolve the appropriate segment and element definitions. This is a technique that reduces the amount of space required to store various versions of the standards. It is a defaulting scheme used so that standard specifications that remain unchanged from version to version are stored only once.
The READ EDI primitive reads a data stream according to a specified standard and document definition, constructs an EDI data tree structure, and populates the tree from the data stream so that it can be accessed using the EDI tree path notation. The MAKEDOC primitive prepares an empty EDI data tree structure based on a specified standard and document definition. As explained below, this empty tree can later be filled with assignment statements in a filemap structure. MAKEDOC creates the minimum bare tree corresponding to the specified document definition. However, additional nodes or intermediate branches may be needed to contain the data. When an assignment statement is executed, if the required intermediate branch or node does not yet exist in the tree, it is created by the assignment. Another primitive, WRITE EDI (or TREETOEDI) writes data that has been structured in an EDI data tree structure to an output stream in an EDI document format.
These primitives are implemented in the dynamic creation of data structures as specified by the standards. The document tree contains areas, which contain loop blocks or segment blocks, loop blocks in turn contain loop bodies or segment blocks, segment blocks contain segment bodies, and segment bodies contain data elements. To allow an NTE segment to float, any segment body can be given an NTE property. The user can refer to and manipulate the contents of the tree by using the flexible notation referred to above. A tree can have multiple occurrences of loops or segments. In traversing a tree, the specific occurrence required must be referred to. For example, in the 810 document definition shown in FIG. 9, there is a LOOP.sub.-- N1 1110 defined in the HEADING area 1100 that can occur between 1 and 200 times. Inside the loop is an optional segment N2, shown at 1111, that can occur up to two times. To refer to the second occurrence of the N2 segment in the third occurrence of LOOP.sub.-- N1, the tree path specification would be "tree HEADING LOOP.sub.-- [3] N2[2]."
These primitives can be used to take data from an input stream in either EDI or application format and put data into an output stream in either format. In the sample translation illustrated below, application input data is converted to EDI output data.
The translation of the sample invoice document shown in FIG. 7 to the EDI 810 format shown in FIG. 8 is implemented with a translation script. The EDI translation script used with these two documents is shown in FIGS. 13A to 13C.
This script illustrates the structure of an e-language program. A program written in the e-language consists of a series of program statements stored in a file with a structure similar to a Pascal program. The program can begin with array declarations, which can be one-dimensional or multi-dimensional. None are defined in this example. Next is the definitions section, in which functions, subroutines, records, and filemaps are defined. The function "the.sub.-- date" is defined at 5110 in FIG. 13A, a filemap is defined at 5200 in FIGS. 13A and 13B, and several records are defined at 5300 in FIGS. 13B and 13C, with an individual record shown at 5310. The executable commands and statements follow, bounded by a BEGIN statement and an END statement, as shown at 5400 in FIG. 13C.
The FILEMAP statement, shown at 5200, maps the input data stream to a set of record assignments. These record assignments are listed in nested loops 5210 and 5211. Each record assignment assigns variables to tree path specifications. For example, in the "person" record assignment 5212, variable "p.sub.-- name" is assigned to the tree path "tree HEADING LOO.sub.-- P N1[1] PER[1][2]."
Following the filemap definition is a set of record definitions, shown at 5220. These definitions pattern match the data from the input file and assign them to the variables that have been assigned to tree paths in the record definition statements. In the command section 5400, a bare tree is created using the MAKEDOC function in line 5410, which specifies that the tree is to be an X12 810 invoice, using version 2.2 of X12. The bare tree is then populated from the standard input stream, STDIN, with the pattern-matched data in line 5420 using the MAPFILE function. Finally, in line 5430, data from the tree is output in EDI X12 format using the TREETOEDI function, using an "*" as an element separator, a " n" as a segment separator, and an "@" as a subelement separator.
The operation of this script is illustrated with the sample input shown in FIG. 7 and the sample EDI output shown in FIG. 8. In record definition 5310, a search is conducted for the string "MAIL" by 5311 and 5312. This is found in the input document at 6110. Having found MAIL, the blanks following MAIL are skipped by line 5313. Then, the following fourteen characters of data, which in this case will include "Perry Lawrence," are read and assigned to the variable p.sub.-- name in line 5314.
Line 5315 then searches for "GROUN." Then, the month ("NOV," read by line 5321), day ("27," read by line 5323), and year ("1989," read by line 5325) are read and assigned to the variables "mon," "day," and "year." These are concatenated by the function "the-date" defined at 5100 in FIG. 13, which in turn was assigned to the variable "inv.sub.-- date" in line 5313. Variable "inv.sub.-- date" in turn is mapped to tree HEADING BIG[1][1]in line 5314 (i.e., the first element in the first occurrence of the BIG segment).
Although the ST (transaction set header) and SE (transaction set trailer) segments (shown at 1101 and 1321, respectively, in the document definition shown in FIG. 9) are mandatory because they envelope the document, they are not put into the EDI output document at this point in the process because they are not yet determined. Enveloping segments typically contain control information, which cannot be resolved until the translation step is completed. For example, the SE segment includes the number of segments in the document, which is not known until the document is finished.
As shown at 7111 in FIG. 8, the data is then output as "NOV271989" following the BIG segment identification. Similarly, line 5327 of FIG. 13 reads in the inventory number, 101903, assigning it to the variable "inv.sub.-- num," which in turn is mapped by line 5315 to tree HEADING BIG[1][2], from which it is output at 7112. This process is followed to read the remainder of the required information from the input document and map it to the tree and thence to the output document.
The inverse of the above operation can also be performed. An EDI document can be converted into data records in a format readable by an application. In such a translation, a tree corresponding to the EDI invoice is created and populated using the READ EDI primitive. A series of assignment statements are used to assign data from the tree to fields in data records. When a data record is completed, it is output to the application by the PUTREC command. A sample of a script for translating an EDI document into an application document is shown in FIGS. 14A to 14E.
In the commands in FIGS. 14A to 14C, such as "record header" at 13110, the fields for each record of data required by the application are defined with picture statements. At 13200 in FlG. 14C, the READ EDI primitive is used to read the document "podoc" (purchase order document) and create a tree structure populated with the data from the EDI document in the input data stream. The script next includes a series of assignment statements, as at 13310, in which data from nodes of the tree are assigned to the fields. When the fields in a record are filled, the record is output to the output stream with the PUTREC command, as at 13400. This process continues for each of the records.
A translation from one EDI format to another EDI format can be performed as follows. First, READ EDI is used to create and populate a first tree corresponding to the input document. MAKEDOC is used to create a bare second tree corresponding to the desired output document. A series of assignment statements are then used to populate the bare second tree with data from the first tree. WRITE EDI then creates an EDI document from the populated second tree.
Similarly, the system can translate a document from a first application format to a second application format. An intermediate tree structure may not be used in this case. The document is first pattern recognized. The pattern recognized data is then assigned to the appropriate records for the second document format, and the records output to the second application using PUTREC. A tree may also be used to represent application transactions.
Enveloping Work Center
Outbound EDI documents are created by the translator process. These documents are usually created as a result of processing an inbound application transaction. Although the outbound document contains a complete address, the facility used for communicating the document may not be ready. There is therefore a need to hold these documents until the communication facility is ready. The process of grouping EDI documents into a "package" that is to be sent through an EDI communication facility is termed "enveloping."
As described above, the EDI enveloping scheme employs the concept of an interchange, which is a unit of communication from a given sender to a specific receiver comprising a package of mail containing multiple functional groups. A functional group is a grouping of EDI documents that correspond to a theoretical organizational function, such as the purchasing department. Each document is a single business document expressed in EDI.
The system uses a hierarchical file structure to store the EDI documents that are ready to be communicated. The structure closely follows the EDI enveloping scheme. The hierarchy runs from communication facility as the highest level, to network interface, receiver, sender, functional group, and document. This hierarchical structure is also used to store application transactions. Outbound application transactions are stored in a similar hierarchy, with communication facility at the top, followed by application interface and application transaction.
Thus, a file produced by the translator and its accompanying routing form is moved into a depository where the enveloper can find the file when required. The translator uses the node, file type (EDI, non-EDI, or text) network or application interface, and other information on the routing form to determine where a file should be placed. It also consults a table that indicates what sort of interchange is used for a given trading partner, functional group, and node. This file structure, corresponding to the hierarchy described above, is shown graphically in FIG. 6. TP denotes a trading partner, INT interchange method, and FG functional group. In the illustrated embodiment, the file is physically located on the fixed disk of the microcomputer on which the system is operated.
When the communication facility is ready, it makes a request to the enveloper specifying the communication facility and either the application interface or the network interface. A network interface is an interface to an EDI transfer or user agent. This means that the packages communicated through this interface must follow the EDI packaging scheme described above. An application interface is an application transfer or user agent. This means that the packages communicated through this interface pertains to a more simplified packaging. The procedure is to concatenate all transactions and present them for transmission. Optionally, the transactions may also be surrounded by job control language to create a job stream to be transmitted to a host.
When it receives a request from a facility client, the enveloper takes files from the directories into which they were placed by the depositor. The enveloper locates the appropriate directory based on the identity of the node and facility being served and the type of file content. Files within a given functional group directory are wrapped in a functional group envelope, which is in turn wrapped in an interchange envelope. Values for data elements in the functional group and interchange envelopes are obtained or generated. When the interchange is complete, it is sent to the facility client in the communications interface.
For application data files output by the translation work center, the enveloper first batches together the documents into a single set for use by the pertinent application. In the illustrated embodiment, the enveloper packages the data for the host (attaching job control language, for example) and transmits the packaged data through the communications interface to the job entry system of the host. In an alternate embodiment where the application and the EDI translation system operate on the same machine, the documents are grouped into a single file and placed in a file location agreed to by the application and EDI system, and the application is then triggered to execute the file.
Text files are sent directly to the facility client without processing. Sender and receiver data are embedded in application files. This makes the information available to the receiver and to the user's enveloping script. ##SPC1##
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
What is claimed is:
1. A computer implemented method for translating electronic data in a computer system in a computer system from a first format to a second format, comprising the steps of: (a) determining which one of a plurality of communication protocols to utilize to receive data as a function of a communication process used to transmit the data to the computer system; (b) receiving input data as a unit of work in a first format, the data comprises a plurality of data components; (c) assigning a script name to the unit of work to identify a de-enveloping procedure that will be used to separate the plurality of data components of the received data into individual data components, the de-enveloping procedure identified being dependent on the communication process used to transmit the data to the computer system; (d) dividing the received data into individual data components by executing the identified de-enveloping procedure; (e) translating the individual data components from the first format into a second format which is chosen to be compatible with a desired destination for the data; and (f) arranging the individual data components into a package so that the package is available for transmission at any time by the computer system to the desired destination.
2. The method of claim 1 wherein said translating step comprises the steps of: a. executing a first script to identify, classify, organize, route, and determine the translation requirements of said plurality of data components in said first format; and b. executing a second script to transform said plurality of data components in said first format to said second format.
3. The method of claim 2 wherein said scripts are executed by an interpreter.
4. The method of claim 2 wherein said scripts are executed by a compiler.
5. The method of claim 2 wherein said transforming step comprises the steps of: a. constructing a data tree structure having a plurality of branches and a plurality of nodes to represent a document or transaction; b. mapping one of said plurality of data components in said first format onto said data tree structure; c. mapping data in said data tree structure into said plurality of data components in said second format.
6. The method of claim 5 wherein said data tree structure is defined by specifications of an electronic data interchange document standard.
7. The method of claim 6 wherein said specifications comprise segment definitions and element definitions and wherein said step of constructing a data tree structure comprises the steps of: a. identifying a specification; b. defining a plurality of nodes, said nodes corresponding to said segment and element definitions; and c. developing a path specification for accessing said nodes.
8. The method of claim 7 wherein said step of identifying a specification comprises the steps of: a. identifying a specification identifier number; b. identifying an EDI standard; c. identifying an EDI standard version number; and d. using a hunt sequence associated with said version to resolve said segment and element definitions.
9. The method of claim 7 wherein said element definitions have associated data types, said data types being defined by a regular expression, said regular expression being computed when said element definition is read.
10. The method of claim 5 wherein said step of mapping to said data tree comprises the steps of: a. defining a plurality of data records, each of said records having one or more fields; b. parsing said one of said plurality of data components; c. matching data in said one of said plurality of data components to said fields in said record definitions; and d. binding said fields to said matching data.
11. The method of claim 5 wherein said step of mapping from said tree structure comprises the steps of: a. determining the identity of delimiters to be used to delimit said data; b. traversing said data tree in a depth first order; and c. formatting each of said nodes and placing said delimiters.
12. The method of claim 1 wherein said individual data components in said second format are maintained in a depository until they are transmitted to said destination.
13. The method of claim 1 wherein said script is defined in a programming language, said programming language incorporating a group of translating instructions corresponding to several translating steps in the flow of translating, including a pattern matching procedure for extracting data from a data stream, a data tree structure creation procedure, and a mapping procedure for mapping extracted data to a tree structure and mapping a data tree structure to an output stream.
14. The method of claim 13 wherein said programming language uses a relational model to represent data to facilitate processing by structured query language commands.
15. The method of claim 13 wherein said programming language is executed through an interpreter.
16. The method of claim 1 wherein said unit of work is divided into pages, said data components comprise application data components, and said dividing step comprises the steps of: a. marking a beginning of a data component; b. parsing through said unit of work; c. pattern matching data in said pages and extracting an identifier from each of said pages; d. marking an end of a data component when said identifier changes; and e. dividing out as a data component the data between said marked beginning and end.
17. A system for translating electronic data from a first format to a second format, comprising: a network; and a computer coupled to the network for receiving data transmitted from the network, said computer including: a communication interface including a driver to accept data in a first format as a unit of work, the data comprises a plurality of data components, and a script which determines a communication protocol to utilize to accept the data as a function of a communication process used to transmit the data to the communication interface, a de-enveloper coupled to the communications interface, said de-enveloper includes means for receiving the data from the communication interface, means for assigning a script name to the unit of work to identify a de-enveloping procedure that will be used to separate the received data into individual data components, the identified de-enveloping procedure being dependent on the communication process used to transmit the data to the communication interface, and means for dividing the received data into individual data components by executing the identified de-enveloping procedure, a translator coupled to the de-enveloper, said translator manipulates the individual data components from the first format into a second format which is chosen to be compatible with a desired destination for the data, and an enveloper coupled to the translator and the communication interface, said enveloper groups the translated individual data components into a package so that the package is available for transmission at any time by the communication interface to the desired destination.
18. The system according to claim 17 wherein said means for assigning a script name, further includes: means for dividing the received data into individual data components; means for identifying sender, receiver and transaction type; and means for determining the type of transformation needed and destination of the transformed individual data components.