Abstract:
An information processing system for processing Electronic Data Interchange (EDI) data is disclosed. Customer data is received in EDI format is converted into a database format by a set of PERL language scripts by selecting a particular PERL script or module that corresponds to the type of EDI data received. The converted data is stored in databases to be used by operations control systems such as a plant production control system.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention relates to electronic data processing and more particularly to Electronic Data Interchange (EDI) based information processing.  
       BACKGROUND OF THE INVENTION  
       [0002]     Computer networks having different architectures are found across various business data-processing environments. Some business networks use proprietary network protocols and data-storage formats that need to be converted into other forms if the data from such networks are to be used by other networks that cannot interpret proprietary formats. Although non-proprietary network protocols like the TCP/IP have emerged as an effective bridge between incompatible local networks, the formats in which data is stored and structured on a network remain non-homogenous and proprietary to a large extent. Hence, there arose a need for a common standardized data format for information exchange in business environments. The EDI family of data-formats is an attempt in this direction. EDI and its applications are considered next.  
         [0003]     EDI allows data to be stored and transmitted over networks in standardized formats that can be interpreted by the receiving computer system. The receiving computer must have a software application that can interpret and process the incoming EDI formatted data. Business data-processing is typically carried out using database systems, and in particular by relational database systems. Typically, a set of applications running on the receiving computer system is required to process data received from customers in multiple formats. However, such a set of applications is complex to maintain. Further, the whole production control software system becomes difficult to maintain when either a monolithic EDI-to-database conversion application is used or a set of diverse modules for EDI-to-database conversion are used.  
       SUMMARY OF THE INVENTION  
       [0004]     A method information processing where the received data is in EDI format is described. The received EDI formatted data is converted by a set of PERL scripts or modules into a database format, typically relational database format. The process of selecting a particular PERL script for a particular type of EDI data is automatic and does not require user-intervention. The PERL scripts and the EDI data-type that it can convert is stored in an indexed array which is typically a PERL hash. The converted data can be used for a variety of purposes. For example, a plant control system is described that is automatically controlled by the customers. The customers sends requirements in EDI format and the PERL scripts convert that EDI formatted data into databases, which is then used to schedule production and also increase production if required.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0005]     The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:  
         [0006]     FIG. 1  is a block-diagram of a plant management system that employs a PERL (Practical Extraction and Report Language) based EDI-to-database converter;  
         [0007]      FIG. 2A  is a PERL script snippet that shows splitting of a scalar storing a record;  
         [0008]      FIG. 2B  is a PERL script snippet that shows separation of a record into fields stored as array elements;  
         [0009]      FIG. 2C  is a PERL snippet that shows a subroutine call that is based on the type of data in the array; and  
         [0010]      FIG. 3  is a flow diagram of the data flow in the EDI data-processing system. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0011]     The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.  
         [0012]     Referring to  FIG. 1 , a plant management system  10  incorporating the present invention is shown. The plant management system  10  receives input from multiple customers. The customers send their on-going requirements to the producer/manufacturer as EDI data  12  that is received as an input by the system  10 . The EDI data  12  is converted into a database format by the PERL based EDI to database converter  14 . The converted data is analyzed at data type analyzer  16  as being either weekly data or daily data. The weekly data is stored in the weekly database  18 , while the daily data is stored in the daily database  20 . Those skilled in the art will appreciate that the converter  14  can be either a single PERL script or a set of distinct PERL modules or scripts.  
         [0013]     Data from both the databases, i.e., the weekly database  18  and the daily database  20 , are fed into the plant scheduling system  22 . The system  10  is designed to be flexible in accepting extra orders from the customers that are over and above the regular orders sent as the EDI data  12  as described above. The additional customer requirements  24  can be scheduled as either daily or weekly orders and are fed into the plan scheduling system  22  to be blended with the data sourced from the weekly database  18  and the daily database  20 . The plant scheduling system  22  then uses such blended data to determine if extra parts need to be produced in the next production schedule. Those skilled in the art will appreciate that though the above example uses plant scheduling for an exemplary parts manufacturing operation, the teachings of the present invention may be applied to any type of production or service activity that requires periodic inputs and produces corresponding output.  
         [0014]     The formats of the weekly database  18  and the daily database  20  can be relational type. However, other formats like hierarchical, object oriented, XML or a newer format can also be easily incorporated with the present invention by building an appropriate PERL script to convert the EDI data into a new database format and including the same within the hash of conversion processes described below. Those skilled in the art will appreciate that the particular database format used does not limit the invention, and the relational type is used in this description only as an example.  
         [0015]      FIG. 2A  is a PERL script snippet that shows snippet for a scalar that stores a record;  FIG. 2B  is a PERL script snippet that shows separation of a record into fields stored as array elements; and  FIG. 2C  is a PERL snippet that shows a subroutine call that is based on the type of data in the array. The EDI data  12  received from the customer can be formatted in a variety of ways. While the receiving computer of the system  10  will be able to handle only known data-types, it will not be necessary for the customer&#39;s sending computer to inform the system  10  each time about the details of the data-type being transmitted. The system  10  receives the EDI data  12  as variable length records using predefined delimiters. The structure of the EDI data  12  record is described next.  
         [0016]     The first field in each EDI data  12  record identifies the type of data contained in it. For example, the string “DATATYPE*data1*data2*data3 . . . ” represents the general structure of EDI data  12  record, in which the first field is the data-type indicator and subsequent data-fields are separated using the predetermined delimiter “*”. Those skilled in the art will recognize that the EDI data  12  record may have any type of data-record having fields separated with any form of delimiter (or delimiters), and that the above examples of data-fields and delimiters are merely illustrative in nature.  
         [0017]     The system  10  reads a delimited record from the received EDI data  12  and splits the individual fields into a character array as shown in code-snippet  32  ( FIG. 2A ). The split string in the “array” is stored as the DATATYPE indicator at element [0] and data-elements in the fields [1],[2] and so forth as shown in the snippet  34  ( FIG. 2B ). Calling of a sub-routine to process the data-fields depending upon the DATATYPE is described next.  
         [0018]     A subroutine-hash, i.e., a PERL character indexed array, of subroutines is pre-built to process each separate data-type by a corresponding subroutine. The sub-routine has will typically be composed of multiple key-value pairs, where the key being EDI data-type (format) to be processed and value being a pointer or a link to the corresponding PERL script that can process that particular EDI data-type. Referring to  FIG. 2C , the subroutine call is shown at snippet  36 , where the first parameter passed is the DATATYPE of the EDI data  12  record and other parameters are the field values. The particular sub-routine to be called is automatically selected based on the value/contents of the DATATYPE stored in the ‘array[0]’ location.  
         [0019]     The automatic selection of a particular subroutine through a subroutine hash eliminates the need to have lengthy code for calling a particular sub-routine, based on the data-type, and passing to the sub-routine any specific parameters. On the contrary, due to the use of a subroutine hash the subroutine call has a uniform format as shown in snippet  36 . Hence, this technique facilitates seamless and easy conversion of various EDI data  12  formats without any need for human intervention or lengthy and cumbersome coding to handle each EDI data-type with a separate section of code.  
         [0020]      FIG. 3  is a flow diagram of the data-flow in the EDI data-processing system  10 . An example of the operation of the whole system in the context of a production planning system for an automobile part manufacturer is described next. The daily EDI data  12  is received from customers, which in this example are truck parts as shown at step  38 . A particular PERL script is selected to convert the received daily EDI data  12  as shown at step  40  depending upon the type of the data as described above. The PERL DBASE::AccessX module at step  42  converts the EDI data  12  processed by the selected PERL script into a database record and stores it in the daily database  20  (see  FIG. 1 ). In a similar manner, weekly EDI data  12  is sourced at step  48 , converted by an automatically selected PERL script at step  50 , and converted into a weekly database  18  record format at step  54 .  
         [0021]     The integration of daily and weekly data is described next. The PERL DBASE:AccessX module at step  46  collects data from the daily database  20  and the weekly database  18  to create a production control database shown at step  58 . This particular module uses PERL scripts as shown at step  56  to create the production control database. The integration of the daily data is performed by filtering the daily database  20  and the weekly database  18 . In the context of  FIG. 1  the above operations are carried out by the plant scheduling system  22  that determines (decision step  26 ) if extra parts are to be manufactured (step  30 ) or not (step  28 ).  
         [0022]     The system  10  achieves the conversion of EDI data  12  into a database format that can be easily filtered and processed. One application of such EDI-to-database conversion as described above is to control a production planning system. However, those skilled in the art will recognize that a production planning system is just an illustrative application of the present invention, and this example not meant to be limiting in any manner. The present invention provides seamless conversion of EDI data into database formats without any need for human intervention. Further, PERL based scripting is applied to select a particular module for converting the specific type of EDI data received from the customers. Hence, EDI data from multiple customers in differing formats can be processed by the system without any separate code required to determine which particular converter needs to be selected.  
         [0023]     The description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. Such variations are not to be regarded as a departure from the spirit and scope of the invention.