Abstract:
Methods, systems, apparatus and computer-readable media are disclosed for generating extract files. A first example method is disclosed for generating an extract file. The method includes receiving a data request and analyzing the data request to identify at least one record of at least one file containing data associated with the data request. The method also includes extracting the identified records and formatting the identified records according to a comma separated value format. The method further includes outputting an extract file containing the formatted records. Other methods, apparatus, systems and computer readable media are disclosed for generating extract files.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims priority to and incorporates by reference the entirety of U.S. provisional application entitled “Method and Apparatus for Formatting CSV-Formatted Extract File,” Ser. No. 60/487,062, filed Jul. 11, 2003. 
    
    
     TECHNICAL FIELD 
     The described methods and apparatus are generally related to information processing environments in which data is extracted, formatted and exported. More specifically, the described methods and apparatus are related to formatting source data into a non-proprietary file format. 
     BACKGROUND 
     Software systems commonly make use of application-specific data formats. Such data formats, being somewhat unique to the individual software system, are not necessarily recognized by third-party applications. In some cases, the data formats may be proprietary to a particular software application making such data formats difficult to access by other software systems. 
     When the user of such a software system has the need to import data from the software system into third-party applications or to otherwise access the software system&#39;s data, considerable development time and expense may be expended to derive the source data format. For example, an end-user of the above described software system may wish to generate customized reports based on data used by the software system. Without prior knowledge of the source software system&#39;s data format a significant amount of development time may be expended to derive this foreign data format. 
     Some software systems enable the importing and exporting of widely accepted file formats, such as the Comma Separated Value (“CSV”) format, for example. Data formatted in CSV uses a separator character, usually a comma, to separate each field in the record. A double separator represents blank or unfilled fields. The field contents can be surrounded by quotes or double quotes, in case the value contains a comma or embedded blanks. Unfortunately, certain proprietary software systems do not enable users to export to such widely accepted formats. 
     Consequently, there is a need for methods and apparatus that address the shortcomings of prior art software applications that fail to enable data to be exported in a widely recognized file format. A need exists for methods and apparatus to access data in an application specific file format and generate an export file in a widely recognized, non-proprietary file format. 
     SUMMARY 
     The following presents a simplified summary of methods, apparatus, systems, and computer readable media associated with generating an extract file in accordance with the present application. This summary is not an extensive overview and is not intended to identify key or critical elements of the methods, apparatus, systems, and/or media or to delineate the scope of the methods, apparatus, systems, and media. It conceptually identifies the methods, apparatus, systems, and media in a simplified form as a prelude to the more detailed description that is presented later. 
     In accordance with one aspect of the present application, an example method is disclosed for generating an extract file. The method includes receiving a data request and analyzing the data request to identify at least one record of at least one file containing data associated with the data request. The method also includes extracting the identified records, and formatting the identified records according to a comma separated value format. The method further includes outputting an extract file containing the formatted records. 
     In accordance with a second aspect of the present application, an example apparatus is disclosed for generating an extract file. The apparatus includes a processor and a memory in communication with the processor. The memory stores a program to control the operation of the processor. The processor is operative with the program in the memory to receive a data request. The processor is also operative with the program in the memory to analyze the data request to identify at least one record of at least one file containing data associated with the data request. The processor is further operative with the program in the memory to extract the identified records and format the identified records according to a comma separated value format. The processor is still further operative with the program in the memory to output an extract file containing the formatted records. 
     In accordance with a third aspect of the present application, an example computer-readable storage medium is disclosed. The medium is encoded with processing instructions for generating an extract file. 
     Certain illustrative aspects of the methods, apparatus, systems and computer-readable media are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the methods, apparatus, systems, and media may be employed and thus the examples are intended to include such aspects and equivalents. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a more complete understanding of the present methods and systems, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein: 
         FIG. 1  is a block diagram illustrating an example processing environment in which data is exported and imported between compatible software applications; 
         FIG. 2  is a block diagram illustrating an example processing environment in which data exported from a first software application may not be compatible with a second software application; 
         FIG. 3A  is a block diagram illustrating a first example processing environment in which data is exported from a first software application in accordance with the present application; 
         FIG. 3B  is a block diagram illustrating a second example processing environment in which data is exported from a first software application in accordance with the present application; and 
         FIG. 4  is an example methodology for generating a CSV formatted extract file. 
     
    
    
     DETAILED DESCRIPTION 
     Example methods and systems are now described with reference to the drawings, where like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to facilitate thoroughly understanding the methods and systems. It may be evident, however, that the methods and systems can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to simplify the description. 
     Referring to  FIG. 1 , a schematic block diagram illustrates an example information processing environment  100  in which data may be exported from a first software application  105  and imported into a second software application  115  which is compatible with the first application  105 . The transfer of data is accomplished via an extract file  110  having a proprietary format which is generated by the first application  105 . Environment  100  illustrates a common relationship between compatible applications. 
     Referring to  FIG. 2 , a schematic block diagram illustrates a second example information processing environment  200  in which extract file  110  exported from software application  105  is incompatible with a second software application  260 . As illustrated, a user  205  or application  210  may request application  105  to generate extract file  110 . Application  105  generates the extract file  110  based on an example store of application data  240 . The example store of application data includes application data files  215 ,  220  and  230 . 
     As shown, the extract file  110  generated by application  105  may is not compatible with application  260  which is incapable of determining the proprietary format of the extract file  110 , but which is capable of importing files having non-proprietary file formats such as CSV formatted file  250 , for example. 
     Referring now to  FIG. 3A , a schematic block diagram illustrates another example processing environment  300  in which data is transferred between two otherwise incompatible software applications  105  and  260 . As illustrated, a user  205  or application  210  may request extract utility  305  to generate the non-proprietary extract file  250 . If extract utility is authorized to access and determine the proprietary format of the data of data store  240 , extract utility  305  may access the store of data  240  to generate the extract file  250 . 
     Alternatively, extract utility  305  may not have the authorization to access, or may be unable to determine the proprietary format of, the application data  215 ,  220  and/or  230 . In that case, extract utility  305  may request application  105  to provide the data to be extracted from the store of application data  240 . The request from extract utility  305  may be an API call or may employ another request technique known to one of ordinary skill in the art. 
     In either case, the extract utility  305  generates extract file  250  which may be imported by application  260 . The extract file  250  created by extract utility  305  enables data to be passed between two otherwise incompatible applications  105  and  260 . 
     Referring now to  FIG. 3B , a schematic block diagram illustrates another example processing environment  350  in which data is transferred between two otherwise incompatible software applications  105  and  260 . As illustrated, a user  205  or application  210  may request extract utility  305  to generate the non-proprietary extract file  250 . As illustrated, extract utility  305  transmits to application  105  a request to export data to a proprietary extract file  110 . In response, application  105  exports the requested data to proprietary extract file  110 . The extract file may be a proprietary extract file that is incompatible with other non-proprietary applications. 
     Extract utility  305  accesses the proprietary extract file  110 , determines the proprietary format of the file, and generates the non-proprietary extract file  250  based on the contents of file  110 . The extract file  250  created by extract utility  305  enables data to be passed between two otherwise incompatible applications  105  and  260 . 
       FIG. 4  is a flowchart illustrating an example method  300  for generating an extract file in a non-proprietary format. At block  405 , a request for data is received. The request represents a request for a non-proprietary extract file to be generated. The data request is analyzed at block  410  and files and records are identified containing the requested data. At block  415 , the data is extracted form the identified records of the identified files. 
     As should be clear from the description of  FIGS. 3A and 3B  above, blocks  405 - 415  may be accomplished in a number of alternative ways. For example, an extract utility, such as extract utility  305 , having access to data store  240 , may be solely responsible for performing blocks  405 - 415 . Alternatively, extract utility  305  may request a proprietary application, such as application  105 , to perform blocks  410  and/or  415 . In such an alternate embodiment, block  415  may include transmitting the requested data from the application  105  to the extract utility  305 , or it may include application  105  generating a proprietary extract file which may be interpreted by extract utility  305 . 
     At block  420 , the identified data is formatted into a non-proprietary format, such as CSV format. An extract file containing the formatted records is output at block  425 . 
     The present application describes a software utility (“CSV Utility”) for extracting data from a source software system, re-formatting the data into a non-proprietary format, such as CSV-format, and making the formatted extract file available to end-users. Following delivery of the CSV-formatted extract file, end-users may immediately import the file into commercially available third-party tools configured to accept CSV-formatted files. Alternatively, an end-user who wished to import data from a source software application into a custom-developed software application may do so with reduced development effort due to the familiar structure of the non-proprietary CSV file format versus the possibly unknown structure of the source system data format. 
     In one embodiment, the CSV Utility described in the present application is used to extract data from a source software system developed by Computer Associates International, Inc. (“CA”), the assignee of the present application. This source software application, entitled AllFusion Endevor Change Manager 4.0 (“Endevor”) is a software tool that automates the management of the software development process—from initial design through distribution. Data used by Endevor includes data stored in Master Control Files (“MCF”) and Package files, which are formatted based on a CA specification. In this embodiment of the present application, the source system&#39;s unique data format, the above described MCF and Package file record layouts, are extracted by a CSV utility, reformatted into a commonly used and easily integrated data format, and made accessible to users. 
     This described embodiment performs the task of reading the CA-specific data records and rendering them in the widely recognized format of CSV. Following the CSV utility&#39;s processing, an end-user can easily import this CSV-formatted data into a variety of commercially available software tools such as MICROSOFT® EXCEL and MICROSOFT® ACCESS, each of which is manufactured and marketed by MICROSOFT CORPORATION, or any other programs that support the CSV file type. Once imported, the data can be used for a wide variety of purposes, including the generation of custom-designed reports. 
     The CSV Utility may run as a stand-alone program on a user&#39;s computing system. In the above described embodiment of the CSV utility, where the CA AllFusion Endevor Change Manager is the source application, the CSV utility processes the steps described with reference to  FIG. 3A  to obtain source application data formatted in CSV. Specifically, a user formats a data request in the Source Coding Language (“SCL”) syntax and submits the request as input to the CSV utility. SLC is the language Endevor uses to process batch requests. 
     The CSV utility analyzes the contents of the SCL statements and determines the CSV output. The CSV Utility calls Endevor API functions to obtain the requested data, which resides in Endevor MCF and Package Files. The data from the API responses are blocked into the CSV format and returned to the API where the data is written to the CSV formatted extract file. 
     What has been described above includes several examples. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, apparatus, methods, and computer readable media associated with generating an extract file. However, one of ordinary skill in the art may recognize that further combinations and permutations are possible. Accordingly, this application is intended to embrace such alterations, modifications, and variations that fall within the scope of the appended claims. Furthermore, to the extent that the term “includes” is employed in the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim.