Template Mapping System for Data Translation

This invention relates generally to electronic data interchange ("EDI") and, more particularly, to a template mapping system for dynamic and flexible dataset translation between different computer systems and data stores.

Electronic data interchange (EDI) is the electronic exchange of business documents, such as purchase orders and invoices. EDI is widely used to facilitate business processes. For instance, documents can be sent and received immediately, and mailing costs are reduced. In addition, there is less paperwork, and improved accuracy as the result of avoiding manual data entry.

Conventional EDI is accomplished over existing communication lines between trading partners' computers. The transfer can be direct if the computers are linked directly, or asynchronously if the connection is a transient one. However, direct networks are difficult to maintain with larger numbers of trading partners. More commonly, a third-party "value-added network" (VAN) is used. VANs maintain an electronic mailbox for each trading partner that can be accessed by each other partner.

In order to ensure both the sender and recipient format data in a common mutually agreed way EDI takes place pursuant to a variety of established EDI standards. Examples of such standards (and their 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, a United Nations 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).

Regardless of the particular standard, all are designed around an electronic representation of a paper business document. A unique identifier code is assigned for each type of business document. For example, in the ANSI X12 standard an invoice is referred to as document number X12.2, with a transaction set identification code of 810.

The basic unit of information on the electronic document is the "data element." For the invoice, each item being invoiced would be represented by a data element. Data elements can be grouped into compound data elements, and data elements and/or compound data elements may be grouped into data segments. Data segments can be grouped into loops; and loops and/or data segments form the business document.

The standards define 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. For each electronic document, a field definition table exists. For each data segment, the field definition table includes a key field identifier string to indicate the data elements to be included in the 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. Similarly, field definition tables include data element identifier strings to describe individual data elements. Element identifier strings 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.

In general, trading partners seldom employ the same database programs and computers, and accessing and storage formats differ significantly. A structured query language (ANSI SQL) has evolved to unify the accessing method. SQL provides a standard method of data accessing independent of specific database storage formats, but this does not address structure and data differences. SQL provides a useful mechanism to illustrate the functionality of the invention and a common point of reference and understanding. FIG. 14 is a high level schematic of the steps involved in SQL processing. SQL begins with a human operator 1 or automated process creating a script of SQL instructions 2 intended to retrieve or store information in database 7. The script is executed by a conventional SQL interpreter engine 3, which in turn initiates a series of database access requests 4. The database system 5 receives and processes the requests and physically accesses the data 6 from database 7. The data is fed back to the SQL interpreter engine 3 which builds a response 8 to the SQL instructions. The resultant output is properly formatted in SQL format 10 or is input to an application 9, depending on the intended usage. It is presumed for purposes of the present patent application that the reader is familiar with the ANSI SQL programming standards and language, and its several popular commercial implementations. To help illustrate these mechanisms, FIG. 15 is a chart showing the SQL language syntax components (at top), as well as an example of a simple SQL language script for inserting data into a table.

Accessing of data via SQL methods does not address remote transfers of data from one computer to another. More is needed before the data becomes useful in this context. The data must be translated from the format of one computer system to the other so that the latter can process it accurately. Originally, translation software was developed to support a variety of private system formats. The private systems were employed by larger companies and were custom written to allow them to exchange electronic documents with selected trading partners.

Eventually, more general translation programs were developed such as TDCC (used in the transportation industry) and UCS (used in the grocery industry). These programs adapted a more flexible approach to translating documents from a variety of different systems into recognizable form. Such translators operate by extracting fixed data files from the original dataset. They manipulate the data twice, once to extract the necessary incoming data, and once to create the outgoing information and place it in the recipient data system. In extracting the inbound data, the translators converted the variable length data elements and segments in the dataset to a fixed length format that could be processed by traditional batch applications. Of course, there was no flexibility to manipulate data, rearrange data, or make up for errors in the placement of data. Often data structure clashes would occur between the data formats (a structure clash occurs when the way that the information has been distributed within the local system does not match the way it is earmarked for eventual use. These programs also required highly specific transmission standards limiting the formats by which datasets are transmitted. Most often, the sender and receiver were required to contract in advance for a tailored software program that would be dedicated to mapping between their two types of datasets. For instance, typical modern computer systems use a combination of SQL, xBase, and Btree based database storage systems. To exchange data between these systems used to require using various flatfile formats. There are four types commonly used, flatfile records, a comma delimited file, EDI formats, and SQL syntax statements (the latter incurs a very high overhead in terms of message size, and so is usually restricted to local transfers and backing up of data only). In any of the four cases, each time a new sender or receiver was added to the client list, a new translation program would need to be added to the arsenal. Of course, this becomes expensive.

Previous attempts at improving the translation process have resulted in solutions that are still cumbersome, use inefficient computer programming language syntax and structures, and still require programming staff to implement. For instance, U.S. Pat. No. 5,202,977 discloses a language based EDI translation system that receives data, executes a script to translate the data, and then transmits the data. The translation is accomplished by a script which creates two separate trees, or linked lists of storage nodes (see column 22, lines 18-26). The script populates one tree with the input data. Then, a series of assignment statements are executed to populate the second tree with the desired output data and according to the desired output format. For the reasons explained above, the fixed scripts can be cumbersome, especially for complex looping datasets. Moreover, there is no flexibility to accommodate a new data structure. In the current state of the art, existing translation systems will abort when they encounter unfamiliar data conditions. Therefore, if a new trading partner comes along a new script must be custom written prior to EDI.

It would be greatly advantageous to streamline the translation system, and to reduce it to a flexible and efficient form capable of handling diverse datasets and incongruities in the data without custom programming support, and with built-in ability to handle unfamiliar conditions.

Accordingly, it is an object of the invention to provide an improved method and architecture for mapping data between fixed structure datasets defined by different computer formats.

It is another object to provide a data translation architecture and method which employs a simple intuitive mapping template which operates from an embedded knowledge of the structure rules for the data being exchanged.

It is a further object to provide a template mapping system which allows the details of the data manipulation required for translation to be expressed and prepared by a layperson, and without the requirement that they define the entire message structure in every detail. Said layperson will manually express and prepare said mapping templates and store them to control and define the template processing required.

It is another object to provide a template mapping system in which the mapping templates themselves can be transmitted along with the datasets to facilitate dynamic conversion between data formats.

It is still another object to facilitate EDI data exchange without the need for convoluted computer language syntax.

It is a further object to allow single step (in memory) implementations that allow direct conversions between database and EDI formats.

It is still another object to allow a user to take an EDI message structure and create either a flatfile record format, a comma delimited format, or explicit dynamic SQL statements with embedded data.

It is a still further object to construct a system that lends itself to implementation with a graphical user interface (GUI) for an intuitive spreadsheet-like metaphor for the end-user. In a spreadsheet cells and functions are used to manipulate mathematical data, whereas it is envisioned that a similar type mechanism in which cells point to data elements and functions will remove the need for complex programming.

These and other objects are accomplished by a template mapping system for translating data between a first data structure and a second data structure.

The system is especially suited for electronic data interchange (EDI) between a first computer system operating with data structured according to its particular protocol, and a second computer system operating with data structured according to a second protocol. The EDI is accomplished with a mapping template incorporating commands for extracting a dataset from the first computer system (formatted in the first protocol), and for restructuring the information according to the second protocol of the second dataset. The system architecture also includes a communication line between the computer systems over which the EDI transactions take place.

The method of using the above-described architecture includes the steps of loading a mapping template that incorporates one or more table field layouts that collectively describe the first data structure and second data structure. The mapping template also includes mapping template rules that define how data is mapped between the two structures. The mapping template is applied by loading a dataset formatted according to the first data structure. Then by identifying and tagging key data elements in said first data structure, and by storing the tagged key data elements in a structureless format. The mapping template is then applied to the structureless data to map the tagged key data elements from the structureless format into the second data structure. Finally, the mapped data is assembled into the second data structure.

FIG. 1 is a block diagram of the inbound mapping system of the present invention which allows data to be freely received from a host computer and reformatted for use in a host computer system.

FIG. 2 is a block diagram of the outbound mapping system of the present invention which allows data to be freely reformatted for transmission and use in a remote computer system. Like components and devices explained above with regard to FIG. 1 are similarly designated.

FIG. 3 shows an exemplary table field layout for a manifest history and manifest summary dataset which describes the names and maximum sizes of the various fields (in bytes) for each table.

FIG. 4A is an example mapping template for an inbound dataset including a manifest history and a manifest summary.

FIG. 4B is a continuation of FIG. 4A.

FIG. 5 is a flow chart of the three basic types of EDI message structure.

FIG. 6 shows an EDI message example of structure rules for a simple one to many relationship.

FIG. 7 shows an example of structure rules for an EDI message with implied looping.

FIG. 8A is an example mapping template for the EDI message dataset of FIG. 7.

FIG. 8B is a continuation of FIG. 8A.

FIG. 9 shows an example of an EDI message with complex looping.

FIG. 10 is an example mapping template for the complex looping inbound dataset of FIG. 9.

FIG. 11 is an example SQL output for the manifest history and summary of FIG. 2 mapped according to the mapping template of FIG. 10.

FIG. 12 shows an example flatfile output and field definition.

FIG. 13 is an example of the tagged inbound data assembled into a structureless format.

FIG. 14 is a high level schematic of the steps involved in conventional SQL processing.

FIG. 15 is a chart showing conventional SQL language syntax components (at top), as well as an example of a simple SQL language script for inserting data into a table.

FIG. 16 is an example template derived output structure showing the precise details on the format of the resulting output structure definitions.

FIG. 17 is an example mapping template for the simple inbound dataset of FIG. 6.

FIG. 18 is a top level overview of all components that make up the mapping template of the present invention (cross-referenced to more detailed figures).

The system described below provides a flexible and concise way of mapping between a computer dataset with positionally significant data, and an arbitrary new format required by the user of the method. The new format can include data re-structuring and formatting, or embedding data into dynamic database commands such as SQL or xBase data standards.

The system also allows this mapping to be performed despite only partial information regarding the structure of the original data. The system therefore is ideally suited for, but not restricted to, use in such applications as Electronic Data Interchange (EDI). The following description of the system will be in the context of EDI. However, it should be noted that the system can be used for other purposes, for example, in discontinuous processing associated with Email, forms, data collection systems, etc. The system also provides a mechanism to facilitate the melding of both current major EDI standards (e.g. ASC X12 and EDIFACT), and also combining SQL and EDI syntactical information together. Typical modern computer systems use a combination of SQL, xBase, and Btree based database storage systems. To exchange data between these systems entails using various flatfile formats. There are four types commonly used, flatfile records, a comma delimited file, EDI formats, and SQL syntax statements. (The latter incurs a very high overhead in terms of message size, and so is usually restricted to local transfers and backing up of data only).

The template mapping system of the present invention performs data translation of inbound datasets sent to the host computer from a remote computer system, as well as translation of outbound datasets to be sent from the host to a remote computer system. The invention allows the user to take an EDI message structure and create either a flatfile record format, a comma delimited format, or explicit dynamic SQL statements with embedded data. The latter is the preferred format since these can then be directly passed to the native database system for immediate transfer of the data required. (Other non-SQL database systems such as Btrieve or dBase syntax can be easily substituted). The other two forms are suitable for use with existing data import processes (typical in a mainframe system), while comma delimited formats are specific to xBase database systems import facilities. The invention can also be applied directly for object oriented style schema databases, where the TABLE and COLUMN items within a SQL based data storage can be directly equated to the CLASS and WITH items used in an object oriented data storage system.

To provide a familiar interface to the end-user the template mapping system can be implemented using a metaphor analogous to a spreadsheet, where the user describes the data storage tables, fields, and data elements in a simple and intuitive way. This can be viewed as similar to entering information and formulae into the cells in a spreadsheet. Associated with this is the use of @functions within the mapping template to provide processing decisions and calculation capabilities. (The use of the `@` symbol is merely a unique character delimiter to signal the beginning of a special function name to the mapping template parser). Each @function can optionally have parameters associated with it, or can return an assignment value, and each has a unique computational capability. For instance @IF() provides decision making, @D returns a date, @MAP() reformats a data item , @NEXTVAL retrieves the next value from a table, and so on. It is intended that implementers of the present invention will extend the available @functions to meet new and specialized needs within the domain of their own product environments.

The fault tolerant data translation of inbound datasets (inbound mapping) sent to the host computer from a remote computer system, and translation of outbound datasets (outbound mapping) to be sent from the host to a remote computer system will now be described.

1. Inbound Mapping

FIG. 1 illustrates the inbound mapping system of the present invention which allows data to be freely exchanged and reformatted between different computer systems. The flexible reformatting is accomplished by decomposing the data elements, tagging key ones, and then reconstructing an outbound dataset based on indexed and tagged key elements. This avoids the torturous prior art system of translating the data into flatfile format, offloading data into a flatfile database, and then translating again into the outbound dataset.

In FIG. 1, the inbound computer dataset 2 represents the incoming information from a remote sending computer's database that is to be received and processed by the host computer. The information may, for instance, include data from purchase orders, invoices and the like, arranged in a structured, application-processable form. The inbound dataset 2 is received directly over a standard communication line.

The inbound dataset 2 is processed by the template mapping system 10 of the present invention, and is thereby restructured and reformatted to be compatible with a receiving computer's database. The receiving computer may be the host computer (in which case the data can be directly downloaded into a computer database store 20 with the help of the existing database direct access software 20 provided by the database vendor), or alternatively, the receiving computer can be another remote computer (in this case, once reformatted in the host, the data can be output in the form of a computer output dataset 4 for transmission to the remote computer).

In order to properly translate the inbound dataset 2, the template mapping system 10 uses two other input components: the mapping template rules 45 and table field layouts 40.

The table field layouts 40 are typically supplied by the sending computer and are dynamically input to the template mapping system 10 for use in processing the input dataset. The table field layouts 40 describe the names and maximum sizes of the various fields (in bytes) for each table. FIG. 3 is a diagram showing the general components of a table field layout (at left) mapped to an actual exemplary table field layout (at right). The table field layout is for a manifest history and manifest summary dataset.

The table definition 150 comprises three components: 1) comments and notes 200 (optional); 2) a table description 300; and 3) field descriptions 400 which provide details of fields within that table. The table definition 150 can be repeated for as many tables as required.

The free-form comments and notes 200 are for documentation purposes. These are ignored by the mapping system.

The table description 300 includes a label identifying the item as a table (see example to right, column 1), a logical table name (column 2), and the coded table name (column 3). The physical table name relates back to the same name used in the mapping template. The logical table name allows a description of the table.

The field descriptions 400 include the field identifier (column 1), the field names (column 2), size (column 3), data format (column 4), and justification parameters (column 5) which may be needed by the mapping process to determine the physical format of the table.

Turning back to FIG. 1, the mapping template rules 45 govern the overall data translation process. These may include field-to-field assignments, and other data manipulations (examples of @ functions used to facilitate such other data exchanges are shown to the right hand side of the template). The mapping template rules form the operating core of the template mapping system 10. They can be provided as an integral part of the template mapping system 10, or they may be imported prior to the translation process. For example, to increase the flexibility of the template mapping system 10 the template mapping rules 45 may be transmitted by the remote sending computer as a precursor to the inbound dataset 2.

The table field layout 40 and mapping template rules 45 are used to build a mapping template, which is then applied to the incoming dataset in the mapping system 10.

FIGS. 4A and 4B are an example mapping template for an inbound dataset including a manifest history and a manifest summary. The template is subdivided into sections each directed to a different item to be translated.

Again, the mapping rules may be prefaced by a series of explanatory comments that generally explain what is to be mapped and how. In the example, the comment block at the head of the template identifies the EDI 856 as the message type, then gives some general examples of function and assignment operation usage within the template. The comments are designed to aid the human reader in interpreting the actions denoted in the subsequent template body and rules.

The mapping rules may be set forth in columns as shown. The illustrated columns include an "item" label to denote the particular item upon which the rules operate, and a "details" column setting forth the rule itself. The items are arranged in succession and include a table identifier that designates the type of table, an index number to uniquely designate the particular table, and key identifiers. The key identifiers denote fields within the data structure that indicate a change of record or level (see FIG. 5 and accompanying explanation). Such key fields can be further subdivided into natural keys within the data structure, and artificial keys that indicate repeated structure elements. For ANSI X12 EDI message standards these include natural keys, (usually found in the very first message segment), and keys within message control segments such as the HL, and LS/LE segments that are added to a message to specifically denote where data loops begin and end. In the message template the EDI.sub.-- KEY key field(s) are those elements within the message structure that indicate that a new record has occurred when its value changes. This allows the structure of the inbound message to be recursively identified, even if partial or incomplete table field layout 40 is provided. The HL.sub.-- KEY keys are specific to EDI messages which may contain HL segments, and these (when present) indicate the change of HL level, or record group, within the data structure. It should be noted that the order in which table definitions are added into the template itself can be used to determine the sequential significance of the actual mapped data output in a fault tolerant way. In other words, when performing the processing the natural order of the data occurrences within the data to be mapped will mean that the inner most key value changes will trigger first. This may be the desired result in the output sequencing. However, if not, the data must be cached on the basis of the table definition sequence. Therefore, instead of implementing the last part of a `write stored data values` operation immediately, these should be deferred by storing the resulting data based on the simple sequence of the table definitions (labelled as 1, 2, 3, etc.). Once mapping at this first pass is complete, a second pass is then necessary to process the actual data in the sequence 1, 2, 3, etc. This two level processing is only required where sequence is critical. Normally, this is not the case, and the extra complication can be avoided. The regular key ordering can be used to guarantee that referential integrity of one to many relationships within the data is not compromised by processing the `many` items before the `one` item.

The particular fields of the table are then set forth by label, and the field reassignments or operators immediately follow. Various types of assignments can be indicated. A simple example is shown by the `mnfst.sub.-- no` field, into which is assigned the value from the BSN02 EDI element. Another example is the `ts.sub.-- date` field which is assigned the value from the date function @DYYMMDD. The latter is a direct value not related to any incoming message element. A complex example is shown by the field rule for `generator.sub.-- id` which uses an @IF function and shows how a conditional assignment is implemented. In this case, the N101 EDI element is compared to the value `SF`. If it matches, then the value from N104 EDI element is assigned into the field `generator.sub.--id `. The "S" element used as prefixes indicates the rule applies to the HL "S" segment to be processed. Field `Reject.sub.-- flag` is assigned from the &&edi.sub.-- valid.sub.-- flag which is in a memory storage area which indicates the status of the translation process.

In addition to the two input components (the mapping template rules 45 and table field layouts 40), the template mapping system 10 uses a number of resident components that are maintained in the receiving computer system to help accomplish the dataset translation procedure. As shown in FIG. 1, these include data structure algorithm rules 50, dynamic SQL syntax rules 60, other database-specific syntax rules 70, and local exchange values 80.

The data structure process rules 50 consist of rules within the template mapping system that determine how specific data structure elements are handled by the mapping process. These known rules define how to handle the structures of the data, and how to recursively recognize and process the specific structures contained in it; this is intrinsically fault tolerant.

FIG. 5 is a flow chart of the three basic types of EDI message structure. These include simple structure (top) wherein each message includes a number of direct data elements.

FIG. 6 shows an EDI message example of structure rules for a simple one to many relationship (between the V1 segment and the R4/NV9 segment pairs). FIG. 17 is an example mapping template for a simple inbound dataset.

The EDI message may also include implied looping (see FIG. 5, middle). FIG. 7 shows an example of structure rules for an EDI message with implied looping. A data element representing a top level of detail may have multiple detail segments associated with it in loops, and each of these may also map to other data elements containing deeper levels of detail, and so on (compare to the simple looping in FIG. 6 notice the multiple N3 and N10 segments can occur multiple times in implied loops). FIG. 8A and 8B are an example mapping template for an implied looping dataset.

Finally, the EDI message may include complex looping (see FIG. 5, bottom). FIG. 9 shows an example of structure rules for an EDI message with complex looping. This is a hybrid of the previous two EDI message types. The previously discussed mapping template of FIGS. 4A and 4B are an example mapping template for an inbound dataset including complex looping (in FIGS. 4A and 4B are, HL segments provide complex looping structures, c.f., FIG. 9 where the VID/N10 segments provide an implied loop example).

Referring back to FIG. 1, the template mapping system 10 also uses dynamic SQL syntax rules 60. The American National Standards Institute maintains a standard language for accessing databases. This is called structured query language (SQL). Software programs may access SQL compliant databases by use of dynamic SQL statements embedded in the memory of the computer. Dynamic SQL allows real time accessing. The template mapping system 10 of the present invention can take advantage of widely available SQL integration tools kits such as those based on the industry wide ODBC (Open DataBase Connectivity) standard originally adopted by Microsoft and IBM. These make available a complete set of dynamic SQL statements and syntax rules 60. Alternately the template mapping system 10 could be optimized to work specifically with a select set of database types, such as the xBase standard, a widely used PC based standard, by building the structure rules that apply to accessing data within an xBase database. (xBase database standard defines the content of the header record within the database, and the data records and their field elements, and how to access the data, add, delete, and update records).

The template mapping system 10 also uses other database-specific syntax rules. These are miscellaneous syntax rules that are specific to particular database formats, such as dBase (Borland's database standard).

Finally, the template mapping system 10 employs local exchange values that are defined locally to equate to different external values. For example, the local exchange value K may be assigned to designate kilograms, whereas the external designation is KG.

Given the above-described inputs and infrastructure, the template mapping system 10 is capable of performing a robust, flexible translation of a fixed-structure inbound dataset into a different outbound dataset in the following manner.

2. The Method of Inbound Translation

The method of using the architecture described above includes two general steps: 1) decomposing the inbound data into discrete data elements and tagging the key elements; and 2) deducing the outbound structure of the data based on index key elements and assembling the final data product accordingly. The detailed steps for accomplishing this are explained below:

i. Open the inbound dataset (to be mapped), identify the type of document and verify that a mapping template exists for this type of document so that it can be processed.

ii. Load mapping template

The appropriate mapping template is loaded into memory and memory -storage locations are defined and reserved for the following information:

iii. Then for each record within the incoming dataset, read each one, one at a time, and do the following:

a. Load each data element into the data values store (data values), and tag it with its associated data tag, table and field address from the mapping template rules 45 described above.

b. Next determine if a control key value changed (by cross-referencing by element ID name into the key.sub.-- value store), or if an end of data set marker has been encountered. If so, determine which tables are affected by either event by checking the index elements (held in the key.sub.-- value store) against the control key value that changed (an end of data set marker triggers all tables for processing, a key change, only those tables for that key).

c. For each such table in step iii(b), build the complete output record in the following way:

1) check the index values in the incoming data structure (index columns) by doing the following:

2) populate the other data columns in the data structure by doing the following:

3) determine the write access mode to the physical data store:

4) write stored table data values by doing the following:

5) clear table values:

v. Continue processing the data set to be mapped, reading each record, until end of all data is detected. At this point, the inbound mapping process is completed.

vi.(optional) Error Correction

As a general principle of good programming practice error handling should be implemented within the template mapping process. This is currently done as a set of in memory stores that identify error conditions throughout each step of the processing, and then return these status indicators to the overall mapping template control logic to determine the required action. This flexibility is consistent with the philosophy of the template mapping method, in contrast to the current state of the art in which data translation aborts when seemingly critical end conditions are met.

3. Outbound Mapping

FIG. 2 illustrates the outbound mapping system of the present invention which allows data to be freely reformatted and sent to a different computer system. Like components and devices explained above with regard to FIGS. 1 and 3-17 are similarly designated.

In this case, the template mapping system 10 of the present invention must first access the relevant data from a host computer database store 28. This is accomplished by an accessing script 20 of dynamic SQL statements that is directly utilized during the mapping template process.

As before, the information may, for instance, include data from purchase orders, invoices and the like, arranged in a structured application-processable form, and not necessarily always a database.

The host data is processed by the template mapping system 10 of the present invention, and is thereby restructured and reformatted into an outbound dataset that will be compatible with the receiving computer and database. The processing performed by the template mapping system 10 is generally similar to that already described for the inbound process except that the mapping template is now used to both extract data from database tables, and also to deduce the required positionally significant data format to be constructed. Once reformatted, the data is output in the form of a computer output dataset 4 (i.e. EDI for transmission to another computer).

It is noteworthy that the template mapping system performs the data extraction from the host database store 28 based on the information given in the table definitions and mapping template. In contrast, prior art systems required custom programming to build a data extraction module.

In order to properly translate the host database store 28, the template mapping system 10 uses the same two input components: the mapping template rules 45 and table field layouts 40 as described above. In addition, the same resident components are maintained in the host computer system to accomplish the dataset translation procedure. The resident components include data structure algorithm rules 50, dynamic SQL syntax rules 60, other database-specific syntax rules 70, and local exchange values 80 (all as explained).

4. The Method of Outbound Translation

This method is conceptually the same as that already described for the inbound process except that the mapping template must now be used to both manipulate and extract data from database tables, and also to deduce the required positionally significant outbound data format to be constructed.

The method of using the architecture described above for outbound translation includes the following steps:

1. Loading mapping template

The mapping template is loaded into memory storage locations that are defined and reserved for the same information described with regard to the inbound data translation, but these now control the outbound translation. Whereas before the mapping template described the incoming data structure, it is now used to deduce the outbound data structure. (A number of new memory storage locations are also required for items specific to describing the outbound data structure, and these are detailed at the start of the processing logic description which follows this section).

2. Assembling and Formatting of outbound data

The format of the originating stored data may not necessarily match the outbound structure. In order to accommodate such structure clashes efficiently it is necessary to assemble the data items into a structureless format. This structureless format achieves two goals; firstly, it makes extract of the outbound data uncomplicated by allowing extraction in a way that is natural to the original data structure, and; second, it allows control of the final structure using the mapping template rather than it having to be pre-determined and built (as is the case with the current state of the art). The structureless format uses a record prefix to label each data item to be used in the final output (see FIG. 13 for example).

When the outbound data is stored in a SQL database the data extraction from the dataset 4 can be achieved using dynamic SQL statements directly from access software 20 to retrieve the data from the computer database store 28 (see FIG. 11, for instance). Such dynamic SQL statements can be deduced directly using the mapping template table definitions and key field definitions to determine the required database access data select statements. (In the current state of the art all such data accesses must be specifically programmed before hand). The present method uses the template mapping key fields to determine the sequence and order in which data is read. While the sequence in which tables are defined and key field definitions within the mapping template establish the referential relationships between tables. Once the data records have been retrieved from the database storage each data element is then specifically labelled with two tags. The first of these is the key value tag which is built by combining together the values from the table access keys (from the mapping template definition) into one fixed length contiguous string. The second item tag is the actual data element name within the outbound structure. On change of key value the record prefix is updated accordingly, and any referential table accesses are also performed (i.e. a referential lookup could be using `person id` to look up `surname` in a `people` table where surname is not available in the main table data items). Alternatively for non-SQL based systems records are directly extracted from data store 28 and the data is tagged in the same way but now the data must be output into an intermediary file and sorted on the key value tag. This sorting will insure that items required for the same output record structure are grouped together (because dynamic data access statements are not available, this data extraction will have to be pre-coded). Building the data in this structureless way means that the extraction process can be greatly simplified since it does not have to retrieve data and format it into the exact sequence of the outbound data structure (see example of FIG. 13).

3. Defining outbound dataset structure.

The outbound data structure is defined according to the following steps:

i. Select the first table definition from within the mapping template, select the data element tag names from the key definition section. These are the main identifier segments, ordered by key sequence that will make up the outbound message structure (i.e. refer to FIG. 4 tags BSN, HL, LIN). So for each of these key elements you will expect to need a matching segment in the outbound message structure format.

ii. Lookup like named tags within the mapping template field definitions to determine each complete set of elements for each of the key element items message structure segments. (i.e. refer to FIGS. 4A and 4B for the PID segment there will PID01, PID03 and PID04 elements).

iii. Lookup the remaining none key segment tags within the table template. These represent additional segments within this block. This completes identification of structure segments for the initial message structure, and group them relative to the key elements within the message template.

iv. Select the next table definition and compare the key field definitions. Ignore those tags already handled previously. Any remaining tags denote the loop structure for the next section of the message. Proceed as before to build segment definitions for these and then the remaining none key segment tags. Continue until all table definitions in the mapping template are included. Note: When performing this for existing ASC X12 EDI message structures you may get conflicting results. This is because some EDI message structures are not in compliance with structured data rules for relational data. Consequently segments in the ASC X12 standard can occur out of sequence. In these cases for strict message compliance you can simply add special local rules to accommodate these inconsistencies when generating the structure. (Another alternative is to simply substitute the default ASC X12 structure manually, instead of creating it dynamically). Refer to FIG. 16 for precise details on the format of the template derived output structure definitions.

4. Output data formatting

The structureless data store (as in FIG. 13), sorted by the record prefix key (created in step 2), is now used as input to the outbound record structure build process. Each record is read in turn, and the data tag name (also added at step 2) is used to locate the data item in the correct position in the matching outbound segment (split the record data into its three component pieces, the key prefix value, the data tag value, and the actual data value itself, refer to FIG. 13 for example of tagged data). Store the three components into the element.sub.-- data storage area. The outbound structure definition is thus built one outbound segment element at a time. If a control key.sub.-- value changes within the record prefix key, or if an end of data set marker has been encountered, then determine which segments are affected by either event by checking the index elements (from step 1) against the control key.sub.-- value that changed (an end of data set marker triggers all segments for processing, a key change, only those segments for that key).

The detailed step-by-step process for completing the output data formatting process (taken by the data mapping system 10 to manipulate the tagged data store information according to the layout specified by the required output structure in step 3) is as follows:

i. Build the outbound structure definitions and establish memory storage areas with the following attributes:

ii. Open the output tagged data already created, then for each record within the data proceed as follows:

a. split the record data into its three component pieces, the key prefix value, the data tag value, and the actual data value itself. (see FIG. 13 for example)

b. store the three components into the element.sub.-- data storage area

c. check the key value with the previous value, if it has changed then select the old key value and do the following:

(1) begin the primary level loop, until all structure segments at this loop level have been processed

(2) retrieve the current structure loop level from the level.sub.-- id store lookup and (3) save the first segment structure type for that loop level

d. now for all segments and stored data at that loop level do the following:

(1) begin the secondary level loop, until all details for these segments are completed lookup the next segment structure type, and the syntax details from segment structure stored details

(2) begin tertiary level loop, until all details for this segment are completed

e. now for all elements within that segment write the stored tagged data in the following way

(1) if pair indicator is "no", then lookup tagged data for that tagged write output to completed outbound dataset.

(2) if pair indicator is "yes", then loop writing all information for that segment BEFORE moving onto the next segment within the structure.

End tertiary level loop

f. repeat process for all structure segments at that loop level.

End secondary level loop

End primary level loop

c. Continue until all records have been processed from the tagged data set.

6. Error Correction

This whole last phase of the process also provides for self checking error reporting. This is done through comparing the data found in the element store (selected from the tagged data records) with the actual definition rules in the element and segment structure definitions. If a required element is blank or of invalid data length or type, then an error can be indicated accordingly.

Just as with inbound data processing, the template mapping system 10 is capable of performing a robust, flexible translation of a fixed-structure inbound dataset into a different outbound dataset.

FIG. 18 is a summary checklist of all of the above-described components that are incorporated in the mapping system 10 of the present invention. A brief explanation of each is given along with a reference to the figure(s) which portray the component in more detail.

Having now fully set forth a detailed example and certain modifications incorporating the concept underlying the present invention, various other modifications will obviously occur to those skilled in the art upon becoming familiar with said underlying concept. It is to be understood, therefore, that within the scope of the appended claims, the invention may be practiced otherwise than as specifically set forth herein.