WO2002007001A2 - System, method, and article of manufacture for propagating transactional processing facility based data to a variety of clients - Google Patents

System, method, and article of manufacture for propagating transactional processing facility based data to a variety of clients Download PDF

Info

Publication number
WO2002007001A2
WO2002007001A2 PCT/US2001/041375 US0141375W WO0207001A2 WO 2002007001 A2 WO2002007001 A2 WO 2002007001A2 US 0141375 W US0141375 W US 0141375W WO 0207001 A2 WO0207001 A2 WO 0207001A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
tpf
computer
relational database
server computer
Prior art date
Application number
PCT/US2001/041375
Other languages
French (fr)
Other versions
WO2002007001A3 (en
Inventor
William E. Foote
Scott A. Luttenberg
Farid M. Mehovic
R. Craig Murphy
Robin B. Tait
Paul R. Wright
Original Assignee
Sabre Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/617,509 external-priority patent/US6714945B1/en
Application filed by Sabre Inc. filed Critical Sabre Inc.
Priority to AU2001281323A priority Critical patent/AU2001281323A1/en
Priority to EP01959804A priority patent/EP1327200A2/en
Publication of WO2002007001A2 publication Critical patent/WO2002007001A2/en
Publication of WO2002007001A3 publication Critical patent/WO2002007001A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data

Definitions

  • the present invention relates to electronic data manipulation, and more particularly, to a system, method, and article of manufacture for propagating Transaction Processing Facility ("TPF") based data to a non-TPF based platform, such as a relational database, in a timely and effective manner, and for providing the propagated data to a variety of clients.
  • TPF Transaction Processing Facility
  • TPF Transaction Processing Facility
  • EBCIDIC Extended Binary-Coded Decimal Interchange Code
  • TPF based systems however, also have several disadvantages, including problems with development and low data management functionality.
  • the development of TPF and its applications is slow, costly, and tedious, primarily because portions of TPF and many of its applications are written in mainframe assembler language.
  • TPF based systems have low data management functionality. Specifically, current TPF based systems fail to respond adequately to application independence and critical data accessibility requirements of many industries that use the TPF based systems.
  • TPF based systems may only be accessed and utilized by applications managed through the limited purpose TPF control programs. For example, if a travel agent needs to obtain a list of passengers scheduled to fly to a particular airport, a TPF based application written for the particular purpose of obtaining that passenger list may be needed. Then, if the travel agent needs some other information, another TPF based application may be needed to execute that particular request. On the other hand, with a relational database, the travel agent may only need to change the query instead of needing different applications for different requests.
  • RDBMS relational database management system
  • SQL Structured Query Language
  • a TPF based system maintains huge volumes of real-time data, it is deficient in its ability to present this data in a timely and effective manner for use by non-TPF based applications, such as RDBMS based applications.
  • non-TPF based applications such as RDBMS based applications.
  • data can be either (1) copied into the non-TPF environment via a batch- processing scenario, or (2) retrieved from the TPF based system via on-line communication channels, such as screen-scraping.
  • Each option is deficient because if the non-TPF based application needs real-time data, option (1) becomes unfeasible due to processing delays and data accuracy impact that is associated with host processor and storage device overhead.
  • Option (2) also becomes equally unacceptable due to communications delay, for example, when the application requires reference to more than a single element of real-time data.
  • Option (2) bears the further significant detriment of requiring extensive modification to applications within the TPF based system to facilitate presentation of such data.
  • the present invention provides a data processing system for propagating transaction processing facility (TPF) data from a TPF based computer to a relational database associated with a server computer and making this data available to a variety of clients.
  • the system includes the TPF based computer and the server computer, which is coupled to the TPF based computer.
  • the server computer receives the TPF data propagated from the TPF based computer and generates a structured query language (SQL) statement reflecting the received TPF data.
  • SQL structured query language
  • the relational database that is associated with the server computer is updated by using the generated SQL statement.
  • the present invention also provides a data propagation method for propagating data from a TPF based computer to a relational database associated with a server computer.
  • the data is propagated from the TPF based computer to the server computer.
  • the server computer generates a SQL statement reflecting the propagated data.
  • the relational database corresponding to the server computer is updated with the use of the generated SQL statement.
  • the present invention provides a data processing system that assists with miscellaneous function management requests.
  • a data processing system includes a TPF based computer with TPF data; a server computer with a relational database, coupled to the TPF based computer, wherein the relational database includes a structured replica of the TPF data; and a client terminal for sending miscellaneous fimction management requests to the TPF based computer.
  • the TPF based computer sends the request to the server computer.
  • the server computer receives the miscellaneous function management request, generates a SQL statement reflecting the miscellaneous function management request, and sends the generated SQL statement to the relational database.
  • the present mvention provides a method that assists with miscellaneous function management requests.
  • a client terminal sends a miscellaneous function management request to a TPF based computer.
  • the TPF based computer sends the request to a server computer.
  • the server computer includes a relational database that has a structured replica of data stored on the TPF based computer.
  • the server computer generates a SQL statement reflecting the miscellaneous function management request and sends the SQL statement to the relational database.
  • the present invention also provides a computer-readable medium containing instructions for causing a computer to perform a method for propagating data.
  • the data is propagated from the TPF based computer to a server computer.
  • the server computer generates a SQL statement reflecting the propagated data.
  • the relational database associated with the server computer is updated with the use of the generated SQL statement.
  • the present invention provides a computer-readable medium containing instructions for causing a computer to perform a method for assisting with miscellaneous function management requests.
  • a client terminal sends a miscellaneous function management request to a TPF based computer.
  • the TPF based computer sends the request to the server computer.
  • the server computer includes a relational database that has a structured replica of data stored on the TPF based computer.
  • the server computer generates a SQL statement reflecting the miscellaneous function management request and sends the SQL statement to the relational database.
  • FIG. 1 is a diagram of an exemplary network environment in which features of the present invention may be implemented
  • FIG. 2 is an exemplary block diagram illustrating components of the TPF based system 400 that is shown in FIG. 1 ;
  • FIG. 3 is an exemplary block diagram illustrating components of the non-TPF based system 500 that is shown in FIG. 1 ;
  • FIG.4 is an exemplary flowchart illustrating the data propagation selection process 440 of the present invention.
  • FIG. 5 is an exemplary flowchart illustrating the function management process 510 of the present invention.
  • FIG. 6 is an exemplary block diagram illustrating the translation process 550 of the present invention.
  • FIG. 7 is an block diagram illustrating an exemplary implementation of the
  • the present invention provides a system, method, and article of manufacture to propagate TPF based data to a non-TPF based platform, such as a relational database, in a timely and effective manner.
  • a non-TPF based platform such as a relational database
  • the non-TPF based platform may have a replica of the data stored on a TPF-based system.
  • the data may be propagated asynchronously or synchronously, and in real-time or after set intervals.
  • a client for example, may be a computer that accesses the data directly from the relational database; a registered system that receives data, in real-time, as its being propagated from the TPF based system; an extraction and transformation client, such as a data warehouse or a data mart; or a non-SQL (Structured Query Language) client.
  • a non-SQL client such as a client that only has a command line interface, does not have the capability to generate SQL statements. Instead, such a non-SQL client can only generate either English language commands or other type of queries.
  • the system and method of the present invention enable even a non-SQL client to access data from the non-TPF based platform.
  • the present invention provides for miscellaneous function management, such as providing e-mail capabilities and database statistics.
  • a travel agent who is connected to a TPF based system may e-mail reservation data to a customer via the non-TPF based platform.
  • the present invention also relates to computer readable media that include program instruction or program code for performing various computer-implemented operations based on the methods and processes of the invention.
  • the media and program instructions may be those specially designed and constructed for the purposes of the invention, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • the media may take many forms including, but not limited to, non-volatile media, volatile media, and transmission media.
  • Nonvolatile media includes, for example, optical or magnetic disks.
  • Volatile media includes, for example, dynamic memory.
  • Transmission media includes, for example, coaxial cables, copper wire, and fiber optics. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infrared data communications.
  • Examples of program instructions include both machine code, such as produced by compiler, and files containing a high level code that can be executed by the computer using an interpreter.
  • FIG. 1 is a diagram of an exemplary network environment in which features of the present invention may be implemented.
  • the network environment includes client 300, TPF based system 400; and non-TPF based system 500, all of which are interconnected by network 600.
  • Network 600 may be a single or a combination of any type of computer network, such as the Internet, an Intranet, an Extranet, a Local Area Network
  • LAN Local Area Network
  • WAN Wide Area Network
  • Client 300 of FIG. 1 may include, but is not limited to, a workstation, a computer, a printer, a facsimile, a registered system, an extraction and transformation client, and a non-SQL client.
  • Client 300 may be used as an input, for example, to enter data into the TPF based system 400, or an output, for example, to retrieve data from the TPF or the non-TPF based system 500.
  • Client 300 may be directly connected to the non-TPF based system 500. These clients may either retrieve the data stored in the non-TPF based system 500 or may receive the data from the non-TPF based system 500. Moreover, these type of clients may include computers running non-TPF based applications, such as RDBMS applications. Non-TPF based applications may access data from the non-TPF based system 500.
  • Client 300 also may be a registered system that registers its data requirements and data formats with the non-TPF system 500. Data meeting the registered system's requirements may be made available via multiple delivery mechanisms. For example, the non-TPF system 500 may provide data meeting a registered system's criteria in real time to the registered system.
  • the client 300 may be an extraction and transformation client, which includes, but is not limited to, a data warehouse and a data mart.
  • a data warehouse may be a RDBMS based computer system, which is designed to store large amounts of data and perform complex queries against this stored data.
  • a data mart is very similar to a data warehouse, but only has a subset of the data for use with a specific purpose. For example, a data warehouse may store reservation data for airlines and hotels, whereas a data mart may store reservation data for airlines only.
  • a non-SQL client may be able to access data from the non-TPF based system 500.
  • a non-SQL client is one that does not have the capability to generate SQL statements.
  • An example of a non-SQL client is a user, such as a travel agent, who only has access to a command line interface.
  • the present invention may provide a travel agent with commands, which may be translated by the present invention into SQL statements and thus, may allow the travel agent to access the data from the non-TPF based system 500. Access may include querying the non-TPF based data.
  • client 300 may simultaneously access both the TPF based system 400 and the non-TPF based system 500.
  • the computer may interact with the TPF based system 400 using an emulator or a command line interface, whereas the computer may interact with the non-TPF based system 500 using RDBMS applications.
  • the TPF based system 400 of FIG. 1 may include a single or a series of mainframe computers, such as the IBM 9032. Moreover, as shown in FIG. 2, the computers in the TPF based system 400 may include operating system 410, TPF database 420, a plurality of TPF applications 430, and data propagation selection process 440. Although not shown, the computers may also include input devices, such as a keyboard; output devices, such as a monitor; memory; and a processor. These, other typical components, and the operation of a TPF based system 400 are known to those skilled in the art and are also within the scope of the present invention. For example, it is known that upon receiving an application program processing request, the TPF operating system 410 passes control to the appropriate TPF application 430 to process a user request.
  • the data propagation selection process 440 located in the TPF based system 400 may be used to satisfy several requests, including, but not limited to, updating the data, a request to access propagated data; a request to e-mail propagated data to the customer; and providing database statistics.
  • database statistics may include providing a travel agent with statistics, such as the number of customers who made airline reservations using the travel agent and the total number of airline customers who also made hotel reservations. With this information, the travel agent may, for example, realize that the agent needs a better marketing program to increase the number of customers that make both airline and hotel reservations.
  • the above requests may be classified into two categories: TPF data update requests and
  • miscellaneous function management requests may fall under either or both the categories. For example, updating and e-mail may fall under both, whereas access and providing database statistics falls under miscellaneous function management only. Updating may include, but is not limited to, creating, modifying, and deleting. Access includes querying the data.
  • TPF data update request The difference between the two categories, TPF data update request and miscellaneous function management request, is that with the TPF data update request, the entire data record is sent to the non-TPF based system 500, whereas, with the miscellaneous function management request, only part of the data record is sent to the non-TPF based system 500.
  • updating is classified under both categories because when creating a new data record, the whole record is sent to the non-TPF system 500, whereas when deleting a record, only a reference to the data record is sent to the non-TPF based system 500.
  • miscellaneous function management e-mail request is different from the TPF data update e-mail request in that the TPF data update e-mail request sends the entire data record for propagation and then, e-mails the data to the recipient.
  • the miscellaneous function management e-mail request is for use with retrieving and sending data that is stored in the non-TPF based system 500, and thus, only a reference to the data record is sent to the non-TPF based system 500. For example, if a travel agent wants to send data that contains information about a new reservation to a customer, the travel agent may use the TPF data update e-mail request.
  • the travel agent may use the miscellaneous function management e-mail request.
  • a reference to the data will be sent to the non-TPF based system 500, the data will be retrieved from the non-TPF based system 500, and then, sent to the customer via e-mail.
  • the miscellaneous function management access request may be used by a non- SQL client, such as a client that only has a command line interface and that needs to access the data stored in the non-TPF based system 500. Access includes querying the data stored in the non-TPF based system 500.
  • the data propagation selection process 440 is further explained in detail in the following description.
  • the non-TPF based system 500 shown in FIG. 1 also may include a single or a series of computers. Furthermore, as shown in FIG. 3, one or more of the computers in the non-TPF based system 500 may include a function management process 510, distribution process 520, extraction and transformation process 530, translation process 550, and a relational database 540.
  • the function management process 510 in conjunction with the data propagation selection process 440, assists in satisfying the TPF data update and miscellaneous function management requests.
  • the function management process 510 also provides the propagated data to the distribution process 520.
  • the distribution process 520 sends the data to any registered systems and assists in completing some of the miscellaneous function management requests, such as providing e-mail capability to a TPF user.
  • the extraction and transformation process 530 extracts, transforms, and then, sends the data to an extraction and transformation client, such as a data warehouse or a data mart.
  • the translation process 550 assists with accessing data from the relational database 540 upon a receiving a request from a non-SQL client.
  • the relational database 540 stores the propagated data.
  • the computers in the non-TPF system 500 may also include input devices, such as a keyboard; output devices, such as a monitor; memory, such as random access memory (RAM) and/or read only memory (ROM); and a processor.
  • input devices such as a keyboard
  • output devices such as a monitor
  • memory such as random access memory (RAM) and/or read only memory (ROM); and a processor.
  • RAM random access memory
  • ROM read only memory
  • FIGs.4 and 5 are exemplary flow charts of the steps involved in the data propagation selection process 440, the function management process 510, and the distribution process 520.
  • the data propagation selection process 440 that is resident on the TPF based system 400 is shown by the dotted rectangle in FIG. 4.
  • the data propagation selection process 440 comprises a series of steps that may occur in real time, for example, immediately after a TPF application updates the data, or after a set interval.
  • a request such as a TPF data update or a miscellaneous function management request, is generated in steps 805, 810, and 815.
  • the TPF based system 400 receives an application program processing request from a user.
  • a user such as a travel agent
  • the travel agent places such a request, using client 300, with the TPF based system 400.
  • the TPF based system 400 receives such a request.
  • the system 400 dispatches the application program processing request, for example, by finding the appropriate TPF application 430 to satisfy the user's request and passes
  • step 815 the application 430 performs routine processing.
  • the travel agent may make all appropriate updates to the reservation data.
  • the system determines whether a TPF data update or a miscellaneous function management request is indicated.
  • the system may examine the request using a predetermined criteria. For example, in the case of airlines, the criteria may be that only requests relating to the specified airlines are propagated. Alternatively, the criteria may be that all requests are propagated to the non-TPF based system 500.
  • step 820 or 825 it is determined that either a TPF data update request or a function management request is indicated, the request is sent to the function management process 510, as indicated by steps 830 and 845. If the request is a TPF data update request, the system sends the data to the function management process 510 that is resident on the non-TPF based system 500, as indicated by step 840. On the other hand, if the request is a miscellaneous function management request, the request is sent to the function management process 510, as indicated by step 845. However, as mentioned in the foregoing description, with the miscellaneous function management request, only a reference or part of the data record is sent instead of sending the entire data record.
  • the passing of the data or reference to the data invokes the function management process 510 and this process completes the TPF data update or the miscellaneous function management request, as indicated in step 835.
  • the function management process 510 completes both the TPF data update and the function management process 510 asynchronously, as shown by the dotted arrows in FIG. 4.
  • the requests may be processed synchronously, asynchronously, or in a combination of both. Such embodiments are also within the scope of the present invention. If the requests are processed asynchronously, the user does not need to wait for completion of the function management process 510, and instead may return and complete routine application program processing, as indicated by steps 840 and 850.
  • steps 820 or 825 If in steps 820 or 825, a TPF data update or a miscellaneous function management request is not indicated, the user completes routine application program processing, as indicated by step 850. Once the application program processing is complete, the control is returned to the operating system 410 in the TPF based system 500, as indicated by a step 855. For example, once the travel agent is done with updating the reservation data, the travel agent may log off from the system and thus, return control to the operating system 410.
  • a request for the function management process is received from the TPF based system 400. This request may be the result of step 835 of FIG. 4, for example.
  • the system determines whether the request is a TPF data update request or a miscellaneous function management request. If the request is a TPF data update request, the propagated data is parsed and transformed into an object containing a structured relational representation of the data, as indicated by a step 915. For example, the propagated data may be parsed into discrete attributes and converted into a CORBA (Common Object Request Broker Architecture) compliant data object.
  • CORBA Common Object Request Broker Architecture
  • the new reservation data may
  • the propagated data may be parsed and transformed into a data object containing a structured relational representation of the data in step 915.
  • the request is a miscellaneous function management request
  • the received request and reference to the data also are parsed in step 915. For example, if the travel agent deleted an existing reservation, the deletion request and the reference to the deleted reservation are sent to the function management process 510 by the data propagation selection process 440, and then, the deletion request and the reference to the deleted reservation are parsed in step 915.
  • SQL-DML Structured Query Language - Data Manipulation Language
  • SQL statements for insertion of such data into the relational database 540 are created in step 920.
  • SQL statements for deletion of the such data from the relation database 540 are created in step 920.
  • the SQL statements used for database updates may be generated, for example, as part of an offline build process.
  • the relational database schema and data cross reference spreadsheets may be inputs to this offline build process.
  • a data cross reference spreadsheet may include table names, column names, column data types, and column data source for the relational database 540.
  • the outputs of this offline build process may be embedded SQL statements that are stored within a runtime table structure that is accessed and modified dynamically at runtime to complete the SQL statement. For example, in step 920, the SQL statements may be accessed from the runtime table structure and then, the accessed SQL statements may be modified with the parsed data to complete the SQL statements, which may be then used to update the relational database 540.
  • step 925 the SQL statements reflecting the data propagation request or the miscellaneous function management request are sent to update or search the target relational database 540.
  • updating includes inserting the parsed and transformed data by using the SQL statements generated in step 920.
  • Searching includes searching the relational database using the SQL statements generated in step 920.
  • step 930 the system determines whether the update or search was successful. To determine whether the update or search was successful, the system may, for example, examine a return code sent by the relational database. If the update or search of the relational database 540 was successful, then, the system waits for another request, as indicated by step 945. However, as indicated in step 935, if the request was a miscellaneous function management request, a reply may be sent to the user before the system returns to the wait stage. For example, if a travel agent placed a miscellaneous function management access request, the result to the access request may be sent back to the travel agent via the TPF based system 400 in step 935 so that the result can be displayed to the travel agent.
  • Step 935 is optional as indicated by the dotted lines and only applies to the miscellaneous function management requests.
  • the request and the data may be optionally sent to the distribution process 520, which is explained in the following description.
  • a TPF data update or a miscellaneous function management request does not exist in step 910 and/or if the update or search of the relational database was not successful in step 930, an error may be generated, and the error and/or the data may be logged for investigation in step 950.
  • a reply error may be sent to the user in step 955.
  • the reply error may be sent to the user, such as a travel agent, via the TPF based system 500.
  • the error may inform the travel agent of the type of error generated and what the travel agent needs to do to correct the error. Then, the system returns to the wait stage, as indicated by a step 945.
  • the function management process 510 may be divided into different processes.
  • the function management process 510 may be divided into a retriever, a parser, and an inserter process.
  • the retriever process may by responsible for the management of the request. After receiving the request, the retriever process may send the request to the parser process, which may parse the request into discrete attributes and covert it into a CORBA compliant data object. Next, the retriever process may request the inserter process to generate a series of SQL statements for updating the relational database 540. Then, the retriever process may send the SQL statements to the relational database 540 for updating the database.
  • These and other modifications to the function management process 510 are known to those skilled in the art and are within the scope of the present invention.
  • the distribution process 520 may provide e-mail capabilities and may provide
  • a travel agent who wants to e- mail new reservation data or existing reservation data to a customer may use the distribution process to send an e-mail to the customer with this information. If the travel agent wants to send new reservation data, the travel agent, for example, may send an e-mail request as well as the propagated data to the function management process 510. After the function management process has updated the relational database 540 with the new reservation data, step 940 of the function management process passes the new reservation data and e-mail request to the distribution process 520, which in turn e-mails the reservation data to the customer. On the other hand, if the travel agent needs to send existing reservation data to a customer, the travel agent
  • the TPF based system 400 may send a miscellaneous function management e-mail request to the TPF based system 400.
  • the TPF based system 400 sends the request to the function management process 510, which in turn, retrieves the data in step 930 and sends the data to the distribution process 520.
  • the distribution process 520 sends this data to the customer in an e-mail.
  • the distribution process may also provide the propagated data to a client 300, such as a registered system, in real time.
  • Client 300 may register its data requirements and required data formats with the distribution process.
  • the distribution process receives data from the function management process 510, it checks the data and the list of client request to determine a match. If there is a match, the data may be made available to the client 300 via multiple delivery mechanisms. For example, the data may be sent using readily available communication protocols, such as CORBA' s HOP (Internet Inter-Object Request Broker Protocol).
  • CORBA' s HOP Internet Inter-Object Request Broker Protocol
  • the TPF based system 400 may send the data to the registered systems in real time, as it is being propagated from the TPF based system 400 or after a set interval.
  • the present invention also provides the ability to provide data to a client 300, such as an extraction and transformation client, for example, a data mart or a data warehouse.
  • the extraction and transformation process 530 provides the data to the extraction and transformation clients.
  • the extraction and transformation process 530 is a batch process that copies data from the relational database 540, transforms the data to meet the requirements of the extraction and transformation client, and places the data into a file for loading into the extraction and transformation client, such as a data warehouse or data mart.
  • conversion tables may be used to transform data attributes to meet the requirements.
  • the airport designation DFW for example, may be transformed to Dallas/Ft. Worth by the tables.
  • Other examples of transformation may include currency conversion and date formats.
  • the present invention also provides a translation process 550, which may be used by a non-SQL client.
  • a TPF based system 400 provides access to the TPF data, it provides minimal or no query ability.
  • any query ability provided by the TPF based system 400 may require new applications, which may not be readily available for use by the user.
  • a non-SQL client such as a computer with a command line interface, which is only connected to a TPF based system 400, may not be able to place a query requests against the TPF data stored in the TPF database 420.
  • the translation process 550 provides the ability of accessing, which includes querying, the propagated data that is stored in the relational database 540. Since the relational database 540 may have a relational replica of the database 420, the non-SQL client does not loose any data by querying the relational database 540 instead of the TPF database 420.
  • a non-SQL client may access the data stored in the relational database 540 via the translation process 550, data propagation selection process 510, and the function management process 510.
  • a non-SQL client may send an access request, which may include a query request, to the TPF based system 400, which in turn sends this request to the non-TPF based system 500.
  • the request may be in the form of traditional TPF based commands, English commands, or any other form.
  • the request is received by the data propagation selection process 440, which in turn, sends the request to the function management process 510. Both the data propagation selection process 440 and function management process 510 were described in the following description and thus, only the differences will be described now.
  • step 920 where the parsed query request is sent to the translation process 550, which is shown in FIG. 6.
  • the parsed request is received by the receiver 710 of the translation process 550.
  • the receiver process sends the parsed request to the translator 715, which converts the request into the SQL-DML statements.
  • the SQL-DML statements are sent to sender 720, which sends the request to the relational database 540.
  • the function management process 510 may be used to process the results. For example, once the database returns the results, these results may be sent to the non-SQL client, as indicated by step 935. Thus, with the present invention, even a non-SQL client may be able to query data stored in the relational database 540.
  • FIG. 7 illustrates an exemplary implementation of the location of the processes and use of the propagated data by a variety of clients.
  • the processes and applications may be stored on a single computer or distributed among several computers, for example, to provide load-balancing.
  • the function management process 510, distribution process 520, extraction and transformation process 530, translation process 550, and the relational database 540 may exist on three servers, the functional server, distribution server, and database server.
  • the function management process 510, distribution process 520, extraction and transformation process 530, the translation process 550, and the relational database 540 may exist on one server.
  • the database server may be part of a RDBMS and may operate in any open relational database environment, for example, DB2, Oracle, Ingres, Informix, or Sybase.
  • the operating system for the database and distribution servers may be Unix or an equivalent system.
  • the database and distribution servers may execute upon, for example, SMP (symmetric multi-processors) such as IBM's RISC System/600 Models J30 or R30, a MPP (massively parallel processors), such as IBM's SP 2.1, or Sun Solaris models such as Sun El 0000 Models.
  • SMP symmetric multi-processors
  • IBM's RISC System/600 Models J30 or R30 a MPP (massively parallel processors), such as IBM's SP 2.1, or Sun Solaris models such as Sun El 0000 Models.
  • the distribution server may utilize readily available communication protocols, such as CORBA' s HOP, for interfacing with clients.
  • CORBA' s HOP CORBA' s HOP
  • the components shown in FIG. 7 may be connected in single or a combination of any type of computer network, such as the Internet, an Intranet, an Extranet, a LAN, or a WAN.
  • servers may be connected in a LAN, which may be connected to the TPF based system 400 via network 600, such as a WAN, i.e., the network 600 may be a WAN.
  • the data stored in the relational database 540 may be used by a variety of clients.
  • the laptop computer, printer, and fax machine may use applications, such as RDBMS applications, to access the data directly from the relational database 540.
  • the data may be provided by the distribution process 520 to registered systems, such as a system running business applications.
  • the data may be e-mailed via the distribution process using the e- mail server, which may connected to the Internet.
  • the data may also be provided to a data ware house or a data mart, as shown in FIG. 7.
  • the personal computer which is connected to the TPF based system 400 and may be running emulation software, may access the data from either the TPF database 420 or the relational database 540, for example, with the assistance of the data propagation selection process, the function management process 510, and the translation process 550.

Abstract

A system, method, and article of manufacture for propagating data from a transaction processing facility (TPF) based computer to a relational database associated with a server computer and providing the propagated data to a variety of clients are presented. A TPF based computer includes TPF data, which is propagated to the server computer. The server computer is coupled to the TPF based computer. The server computer receives the propagated TPF data and generates a structured query language (SQL) statement reflecting the received TPF data. The relational database associated with the server computer is updated by using the generated SQL statement. The propagated data may be provided to a variety of clients.

Description

SYSTEM. METHOD. AND ARTICLE OF MANUFACTURE
FOR PROPAGATING TRANSACTIONAL PROCESSING FACILITY
BASED DATA AND FOR PROVIDING THE PROPAGATED DATA
TO A VARIETY OF CLIENTS
RELATED APPLICATIONS
The present application is a continuation-in-part of U.S. patent application no. 08/588,463, filed April 24, 1998, which is a continuation of U.S. patent application nos. 08/560,295 and 08/560,466, both filed on November 17, 1995 and now abandoned. The content of all the aforesaid applications is relied upon and is hereby incorporated by reference.
BACKGROUND OF THE INVENTION
A. Field of the Invention
The present invention relates to electronic data manipulation, and more particularly, to a system, method, and article of manufacture for propagating Transaction Processing Facility ("TPF") based data to a non-TPF based platform, such as a relational database, in a timely and effective manner, and for providing the propagated data to a variety of clients.
B. Description of the Related Art
Transaction Processing Facility ("TPF") is a term recognized throughout the data processing industry, and refers to an operating system that is used with mainframes. TPF is highly specialized, real-time, and used for processing transactions. A TPF based system maximizes hardware and software resources for processing real-time transactions efficiently. As a result of its real-time transaction processing capability, many industries, such as airline and banking, heavily rely on such a TPF based system. Moreover, the data stored on a TPF based system, for example, in EBCIDIC (Extended Binary-Coded Decimal Interchange Code) format, is very valuable because it represents real-time information, i.e., information that is maintained in as current a manner as possible.
TPF based systems, however, also have several disadvantages, including problems with development and low data management functionality. The development of TPF and its applications is slow, costly, and tedious, primarily because portions of TPF and many of its applications are written in mainframe assembler language.
In addition to the problems with development, current TPF based systems have low data management functionality. Specifically, current TPF based systems fail to respond adequately to application independence and critical data accessibility requirements of many industries that use the TPF based systems.
Unlike information governed by a relational database or a relational database management system (RDBMS), which supports Structured Query Language (SQL), data resident on current TPF based systems may only be accessed and utilized by applications managed through the limited purpose TPF control programs. For example, if a travel agent needs to obtain a list of passengers scheduled to fly to a particular airport, a TPF based application written for the particular purpose of obtaining that passenger list may be needed. Then, if the travel agent needs some other information, another TPF based application may be needed to execute that particular request. On the other hand, with a relational database, the travel agent may only need to change the query instead of needing different applications for different requests.
Moreover, although a TPF based system maintains huge volumes of real-time data, it is deficient in its ability to present this data in a timely and effective manner for use by non-TPF based applications, such as RDBMS based applications. For example, if a non-TPF based application requires data stored within a TPF based system, such data can be either (1) copied into the non-TPF environment via a batch- processing scenario, or (2) retrieved from the TPF based system via on-line communication channels, such as screen-scraping. Each option is deficient because if the non-TPF based application needs real-time data, option (1) becomes unfeasible due to processing delays and data accuracy impact that is associated with host processor and storage device overhead. Option (2) also becomes equally unacceptable due to communications delay, for example, when the application requires reference to more than a single element of real-time data. Option (2) bears the further significant detriment of requiring extensive modification to applications within the TPF based system to facilitate presentation of such data.
Accordingly, there is presently a need for a system, method, and article of manufacture that allows a variety of clients to have access to the TPF data in a timely and effective manner.
SUMMARY OF THE INVENTION
The present invention provides a data processing system for propagating transaction processing facility (TPF) data from a TPF based computer to a relational database associated with a server computer and making this data available to a variety of clients. The system includes the TPF based computer and the server computer, which is coupled to the TPF based computer. The server computer receives the TPF data propagated from the TPF based computer and generates a structured query language (SQL) statement reflecting the received TPF data. The relational database that is associated with the server computer is updated by using the generated SQL statement.
In addition to the system, the present invention also provides a data propagation method for propagating data from a TPF based computer to a relational database associated with a server computer. In this method, the data is propagated from the TPF based computer to the server computer. The server computer generates a SQL statement reflecting the propagated data. The relational database corresponding to the server computer is updated with the use of the generated SQL statement.
In another aspect, the present invention provides a data processing system that assists with miscellaneous function management requests. Such a system includes a TPF based computer with TPF data; a server computer with a relational database, coupled to the TPF based computer, wherein the relational database includes a structured replica of the TPF data; and a client terminal for sending miscellaneous fimction management requests to the TPF based computer. The TPF based computer sends the request to the server computer. The server computer receives the miscellaneous function management request, generates a SQL statement reflecting the miscellaneous function management request, and sends the generated SQL statement to the relational database. In still another aspect, the present mvention provides a method that assists with miscellaneous function management requests. In this method, a client terminal sends a miscellaneous function management request to a TPF based computer. The TPF based computer sends the request to a server computer. The server computer includes a relational database that has a structured replica of data stored on the TPF based computer. The server computer generates a SQL statement reflecting the miscellaneous function management request and sends the SQL statement to the relational database.
The present invention also provides a computer-readable medium containing instructions for causing a computer to perform a method for propagating data. In this method, the data is propagated from the TPF based computer to a server computer. The server computer generates a SQL statement reflecting the propagated data. The relational database associated with the server computer is updated with the use of the generated SQL statement.
In yet another aspect, the present invention provides a computer-readable medium containing instructions for causing a computer to perform a method for assisting with miscellaneous function management requests. In this method, a client terminal sends a miscellaneous function management request to a TPF based computer. The TPF based computer sends the request to the server computer. The server computer includes a relational database that has a structured replica of data stored on the TPF based computer. The server computer generates a SQL statement reflecting the miscellaneous function management request and sends the SQL statement to the relational database. BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings,
FIG. 1 is a diagram of an exemplary network environment in which features of the present invention may be implemented;
FIG. 2 is an exemplary block diagram illustrating components of the TPF based system 400 that is shown in FIG. 1 ;
FIG. 3 is an exemplary block diagram illustrating components of the non-TPF based system 500 that is shown in FIG. 1 ;
FIG.4 is an exemplary flowchart illustrating the data propagation selection process 440 of the present invention;
FIG. 5 is an exemplary flowchart illustrating the function management process 510 of the present invention;
FIG. 6 is an exemplary block diagram illustrating the translation process 550 of the present invention; and
FIG. 7 is an block diagram illustrating an exemplary implementation of the
present invention.
DETAILED DESCRIPTION
The following detailed description of the invention refers to the accompanying
drawings. While the description includes exemplary embodiments, other embodiments are possible, and changes may be made to the embodiments described without departing from the spirit and scope of the invention. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents.
The present invention provides a system, method, and article of manufacture to propagate TPF based data to a non-TPF based platform, such as a relational database, in a timely and effective manner. As a result, the non-TPF based platform may have a replica of the data stored on a TPF-based system. Moreover, the data may be propagated asynchronously or synchronously, and in real-time or after set intervals.
The present invention also provides the propagated data to a variety of clients. A client, for example, may be a computer that accesses the data directly from the relational database; a registered system that receives data, in real-time, as its being propagated from the TPF based system; an extraction and transformation client, such as a data warehouse or a data mart; or a non-SQL (Structured Query Language) client. A non-SQL client, such as a client that only has a command line interface, does not have the capability to generate SQL statements. Instead, such a non-SQL client can only generate either English language commands or other type of queries. However, the system and method of the present invention enable even a non-SQL client to access data from the non-TPF based platform. Moreover, the present invention provides for miscellaneous function management, such as providing e-mail capabilities and database statistics. For example, with the present invention, a travel agent who is connected to a TPF based system may e-mail reservation data to a customer via the non-TPF based platform.
The above-noted features, other aspects, and principles of the present invention may be implemented in various system or network environments to provide automated and computational tools to facilitate propagation of the TPF based data and to provide the propagated data to a variety of clients. Such environments and applications may be specially constructed for performing the various processes and operations of the invention or they may include a general purpose computer or computing platform selectively activated or reconfigured by program code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer or other apparatus, and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.
The present invention also relates to computer readable media that include program instruction or program code for performing various computer-implemented operations based on the methods and processes of the invention. The media and program instructions may be those specially designed and constructed for the purposes of the invention, or they may be of the kind well-known and available to those having skill in the computer software arts. The media may take many forms including, but not limited to, non-volatile media, volatile media, and transmission media. Nonvolatile media includes, for example, optical or magnetic disks. Volatile media includes, for example, dynamic memory. Transmission media includes, for example, coaxial cables, copper wire, and fiber optics. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infrared data communications. Examples of program instructions include both machine code, such as produced by compiler, and files containing a high level code that can be executed by the computer using an interpreter. SYSTEM ARCHITECTURE
FIG. 1 is a diagram of an exemplary network environment in which features of the present invention may be implemented. The network environment includes client 300, TPF based system 400; and non-TPF based system 500, all of which are interconnected by network 600. Network 600 may be a single or a combination of any type of computer network, such as the Internet, an Intranet, an Extranet, a Local Area
Network (LAN), or a Wide Area Network (WAN), for example. These as well as other network configurations are known to those skilled in the art and are also within the scope of the present invention.
Client 300
Client 300 of FIG. 1 may include, but is not limited to, a workstation, a computer, a printer, a facsimile, a registered system, an extraction and transformation client, and a non-SQL client. Client 300 may be used as an input, for example, to enter data into the TPF based system 400, or an output, for example, to retrieve data from the TPF or the non-TPF based system 500.
Client 300 may be directly connected to the non-TPF based system 500. These clients may either retrieve the data stored in the non-TPF based system 500 or may receive the data from the non-TPF based system 500. Moreover, these type of clients may include computers running non-TPF based applications, such as RDBMS applications. Non-TPF based applications may access data from the non-TPF based system 500.
Client 300 also may be a registered system that registers its data requirements and data formats with the non-TPF system 500. Data meeting the registered system's requirements may be made available via multiple delivery mechanisms. For example, the non-TPF system 500 may provide data meeting a registered system's criteria in real time to the registered system.
Moreover, the client 300 may be an extraction and transformation client, which includes, but is not limited to, a data warehouse and a data mart. A data warehouse may be a RDBMS based computer system, which is designed to store large amounts of data and perform complex queries against this stored data. A data mart is very similar to a data warehouse, but only has a subset of the data for use with a specific purpose. For example, a data warehouse may store reservation data for airlines and hotels, whereas a data mart may store reservation data for airlines only.
Furthermore, with the present invention, a non-SQL client may be able to access data from the non-TPF based system 500. A non-SQL client is one that does not have the capability to generate SQL statements. An example of a non-SQL client is a user, such as a travel agent, who only has access to a command line interface. In such cases, the present invention may provide a travel agent with commands, which may be translated by the present invention into SQL statements and thus, may allow the travel agent to access the data from the non-TPF based system 500. Access may include querying the non-TPF based data.
In addition, client 300 may simultaneously access both the TPF based system 400 and the non-TPF based system 500. For example, if the client 300 is a computer, the computer may interact with the TPF based system 400 using an emulator or a command line interface, whereas the computer may interact with the non-TPF based system 500 using RDBMS applications. These as well as other clients will known to those skilled in the art and are also within the scope of the present invention. TPF Based System 400
The TPF based system 400 of FIG. 1 may include a single or a series of mainframe computers, such as the IBM 9032. Moreover, as shown in FIG. 2, the computers in the TPF based system 400 may include operating system 410, TPF database 420, a plurality of TPF applications 430, and data propagation selection process 440. Although not shown, the computers may also include input devices, such as a keyboard; output devices, such as a monitor; memory; and a processor. These, other typical components, and the operation of a TPF based system 400 are known to those skilled in the art and are also within the scope of the present invention. For example, it is known that upon receiving an application program processing request, the TPF operating system 410 passes control to the appropriate TPF application 430 to process a user request.
The data propagation selection process 440 located in the TPF based system 400 may be used to satisfy several requests, including, but not limited to, updating the data, a request to access propagated data; a request to e-mail propagated data to the customer; and providing database statistics. For example, database statistics may include providing a travel agent with statistics, such as the number of customers who made airline reservations using the travel agent and the total number of airline customers who also made hotel reservations. With this information, the travel agent may, for example, realize that the agent needs a better marketing program to increase the number of customers that make both airline and hotel reservations. The above requests may be classified into two categories: TPF data update requests and
miscellaneous function management requests. The requests may fall under either or both the categories. For example, updating and e-mail may fall under both, whereas access and providing database statistics falls under miscellaneous function management only. Updating may include, but is not limited to, creating, modifying, and deleting. Access includes querying the data.
The difference between the two categories, TPF data update request and miscellaneous function management request, is that with the TPF data update request, the entire data record is sent to the non-TPF based system 500, whereas, with the miscellaneous function management request, only part of the data record is sent to the non-TPF based system 500. For example, updating is classified under both categories because when creating a new data record, the whole record is sent to the non-TPF system 500, whereas when deleting a record, only a reference to the data record is sent to the non-TPF based system 500.
Similarly, e-mail falls under both categories, but the miscellaneous function management e-mail request is different from the TPF data update e-mail request in that the TPF data update e-mail request sends the entire data record for propagation and then, e-mails the data to the recipient. On the other hand, the miscellaneous function management e-mail request is for use with retrieving and sending data that is stored in the non-TPF based system 500, and thus, only a reference to the data record is sent to the non-TPF based system 500. For example, if a travel agent wants to send data that contains information about a new reservation to a customer, the travel agent may use the TPF data update e-mail request. On the other hand, if the travel agent needs to send information about an already existing reservation to a customer, the travel agent may use the miscellaneous function management e-mail request. In the latter case, a reference to the data will be sent to the non-TPF based system 500, the data will be retrieved from the non-TPF based system 500, and then, sent to the customer via e-mail.
The miscellaneous function management access request may be used by a non- SQL client, such as a client that only has a command line interface and that needs to access the data stored in the non-TPF based system 500. Access includes querying the data stored in the non-TPF based system 500. The data propagation selection process 440 is further explained in detail in the following description.
Non-TPF Based System 500
The non-TPF based system 500 shown in FIG. 1 also may include a single or a series of computers. Furthermore, as shown in FIG. 3, one or more of the computers in the non-TPF based system 500 may include a function management process 510, distribution process 520, extraction and transformation process 530, translation process 550, and a relational database 540. The function management process 510, in conjunction with the data propagation selection process 440, assists in satisfying the TPF data update and miscellaneous function management requests. The function management process 510 also provides the propagated data to the distribution process 520. The distribution process 520 sends the data to any registered systems and assists in completing some of the miscellaneous function management requests, such as providing e-mail capability to a TPF user. The extraction and transformation process 530 extracts, transforms, and then, sends the data to an extraction and transformation client, such as a data warehouse or a data mart. The translation process 550 assists with accessing data from the relational database 540 upon a receiving a request from a non-SQL client. The relational database 540 stores the propagated data.
Although not shown, the computers in the non-TPF system 500 may also include input devices, such as a keyboard; output devices, such as a monitor; memory, such as random access memory (RAM) and/or read only memory (ROM); and a processor. These and other typical components are known to those skilled in the art and are also within the scope of the present invention.
DATA PROPAGATION SELECTION PROCESS
FIGs.4 and 5 are exemplary flow charts of the steps involved in the data propagation selection process 440, the function management process 510, and the distribution process 520. The data propagation selection process 440 that is resident on the TPF based system 400 is shown by the dotted rectangle in FIG. 4. The data propagation selection process 440 comprises a series of steps that may occur in real time, for example, immediately after a TPF application updates the data, or after a set interval. However, prior to the data propagation selection process 440, a request, such as a TPF data update or a miscellaneous function management request, is generated in steps 805, 810, and 815.
In a step 805, the TPF based system 400 receives an application program processing request from a user. For example, a user, such as a travel agent, may want to create or update an airline, car, or hotel reservation for a customer. Thus, the travel agent places such a request, using client 300, with the TPF based system 400. In step 805, the TPF based system 400 receives such a request. Next, in a step 810, the system 400 dispatches the application program processing request, for example, by finding the appropriate TPF application 430 to satisfy the user's request and passes
control to the application 430. Then, in a step 815, the application 430 performs routine processing. For example, in step 815, the travel agent may make all appropriate updates to the reservation data.
In steps 820 and 825, the system determines whether a TPF data update or a miscellaneous function management request is indicated. To determine whether a TPF data update request or function management request is indicated, the system may examine the request using a predetermined criteria. For example, in the case of airlines, the criteria may be that only requests relating to the specified airlines are propagated. Alternatively, the criteria may be that all requests are propagated to the non-TPF based system 500.
If in step 820 or 825, it is determined that either a TPF data update request or a function management request is indicated, the request is sent to the function management process 510, as indicated by steps 830 and 845. If the request is a TPF data update request, the system sends the data to the function management process 510 that is resident on the non-TPF based system 500, as indicated by step 840. On the other hand, if the request is a miscellaneous function management request, the request is sent to the function management process 510, as indicated by step 845. However, as mentioned in the foregoing description, with the miscellaneous function management request, only a reference or part of the data record is sent instead of sending the entire data record.
The passing of the data or reference to the data invokes the function management process 510 and this process completes the TPF data update or the miscellaneous function management request, as indicated in step 835. In one embodiment, the function management process 510 completes both the TPF data update and the function management process 510 asynchronously, as shown by the dotted arrows in FIG. 4. However, in other embodiments, the requests may be processed synchronously, asynchronously, or in a combination of both. Such embodiments are also within the scope of the present invention. If the requests are processed asynchronously, the user does not need to wait for completion of the function management process 510, and instead may return and complete routine application program processing, as indicated by steps 840 and 850.
If in steps 820 or 825, a TPF data update or a miscellaneous function management request is not indicated, the user completes routine application program processing, as indicated by step 850. Once the application program processing is complete, the control is returned to the operating system 410 in the TPF based system 500, as indicated by a step 855. For example, once the travel agent is done with updating the reservation data, the travel agent may log off from the system and thus, return control to the operating system 410.
FUNCTION MANAGEMENT PROCESS 510
The function management process 510 and distribution process 520 will be explained now with reference to FIG. 5. An exemplary flow chart of the function management process 510 is shown in FIG. 5. In a step 905, a request for the function management process is received from the TPF based system 400. This request may be the result of step 835 of FIG. 4, for example. Next, in step 910, the system determines whether the request is a TPF data update request or a miscellaneous function management request. If the request is a TPF data update request, the propagated data is parsed and transformed into an object containing a structured relational representation of the data, as indicated by a step 915. For example, the propagated data may be parsed into discrete attributes and converted into a CORBA (Common Object Request Broker Architecture) compliant data object. In the travel agent
example, if the travel agent created a new reservation, the new reservation data may
be first sent to the function management process 510 by the data propagation selection process 440, and then, the propagated data may be parsed and transformed into a data object containing a structured relational representation of the data in step 915. Alternatively, if the request is a miscellaneous function management request, the received request and reference to the data also are parsed in step 915. For example, if the travel agent deleted an existing reservation, the deletion request and the reference to the deleted reservation are sent to the function management process 510 by the data propagation selection process 440, and then, the deletion request and the reference to the deleted reservation are parsed in step 915.
After parsing, SQL-DML (Structured Query Language - Data Manipulation Language) statements are created in step 920. For example, in the case of a new reservation record, SQL statements for insertion of such data into the relational database 540 are created in step 920. On the other hand, in the case of deletion of a reservation record, SQL statements for deletion of the such data from the relation database 540 are created in step 920. The SQL statements used for database updates may be generated, for example, as part of an offline build process. The relational database schema and data cross reference spreadsheets may be inputs to this offline build process. Since a relational database stores data in the form of related tables, a data cross reference spreadsheet may include table names, column names, column data types, and column data source for the relational database 540. The outputs of this offline build process may be embedded SQL statements that are stored within a runtime table structure that is accessed and modified dynamically at runtime to complete the SQL statement. For example, in step 920, the SQL statements may be accessed from the runtime table structure and then, the accessed SQL statements may be modified with the parsed data to complete the SQL statements, which may be then used to update the relational database 540.
Then, in step 925, the SQL statements reflecting the data propagation request or the miscellaneous function management request are sent to update or search the target relational database 540. For example, updating includes inserting the parsed and transformed data by using the SQL statements generated in step 920. Searching includes searching the relational database using the SQL statements generated in step 920.
In step 930, the system determines whether the update or search was successful. To determine whether the update or search was successful, the system may, for example, examine a return code sent by the relational database. If the update or search of the relational database 540 was successful, then, the system waits for another request, as indicated by step 945. However, as indicated in step 935, if the request was a miscellaneous function management request, a reply may be sent to the user before the system returns to the wait stage. For example, if a travel agent placed a miscellaneous function management access request, the result to the access request may be sent back to the travel agent via the TPF based system 400 in step 935 so that the result can be displayed to the travel agent. Step 935 is optional as indicated by the dotted lines and only applies to the miscellaneous function management requests. Moreover, as indicated by a step 940, after the update or search of the relational database in step 925, the request and the data may be optionally sent to the distribution process 520, which is explained in the following description.
On the other hand, if a TPF data update or a miscellaneous function management request does not exist in step 910 and/or if the update or search of the relational database was not successful in step 930, an error may be generated, and the error and/or the data may be logged for investigation in step 950. Moreover, a reply error may be sent to the user in step 955. For example, the reply error may be sent to the user, such as a travel agent, via the TPF based system 500. The error may inform the travel agent of the type of error generated and what the travel agent needs to do to correct the error. Then, the system returns to the wait stage, as indicated by a step 945.
Although the function management process 510 was described as a single process in the foregoing description, the function management process 510 may be divided into different processes. For example, the function management process 510 may be divided into a retriever, a parser, and an inserter process. The retriever process may by responsible for the management of the request. After receiving the request, the retriever process may send the request to the parser process, which may parse the request into discrete attributes and covert it into a CORBA compliant data object. Next, the retriever process may request the inserter process to generate a series of SQL statements for updating the relational database 540. Then, the retriever process may send the SQL statements to the relational database 540 for updating the database. These and other modifications to the function management process 510 are known to those skilled in the art and are within the scope of the present invention.
DISTRIBUTION PROCESS 520
The distribution process 520 may provide e-mail capabilities and may provide
propagated data to registered systems. For example, a travel agent who wants to e- mail new reservation data or existing reservation data to a customer may use the distribution process to send an e-mail to the customer with this information. If the travel agent wants to send new reservation data, the travel agent, for example, may send an e-mail request as well as the propagated data to the function management process 510. After the function management process has updated the relational database 540 with the new reservation data, step 940 of the function management process passes the new reservation data and e-mail request to the distribution process 520, which in turn e-mails the reservation data to the customer. On the other hand, if the travel agent needs to send existing reservation data to a customer, the travel agent
may send a miscellaneous function management e-mail request to the TPF based system 400. The TPF based system 400 sends the request to the function management process 510, which in turn, retrieves the data in step 930 and sends the data to the distribution process 520. The distribution process 520 sends this data to the customer in an e-mail.
The distribution process may also provide the propagated data to a client 300, such as a registered system, in real time. Client 300 may register its data requirements and required data formats with the distribution process. When the distribution process receives data from the function management process 510, it checks the data and the list of client request to determine a match. If there is a match, the data may be made available to the client 300 via multiple delivery mechanisms. For example, the data may be sent using readily available communication protocols, such as CORBA' s HOP (Internet Inter-Object Request Broker Protocol). Moreover, the distribution process
may send the data to the registered systems in real time, as it is being propagated from the TPF based system 400 or after a set interval.
EXTRACTION AND TRANSFORMATION PROCESS 530
The present invention also provides the ability to provide data to a client 300, such as an extraction and transformation client, for example, a data mart or a data warehouse. The extraction and transformation process 530 provides the data to the extraction and transformation clients. The extraction and transformation process 530 is a batch process that copies data from the relational database 540, transforms the data to meet the requirements of the extraction and transformation client, and places the data into a file for loading into the extraction and transformation client, such as a data warehouse or data mart. For example, as part of the process 530, conversion tables may be used to transform data attributes to meet the requirements. The airport designation DFW, for example, may be transformed to Dallas/Ft. Worth by the tables. Other examples of transformation may include currency conversion and date formats.
TRANSLATION PROCESS 550
The present invention also provides a translation process 550, which may be used by a non-SQL client. Although a TPF based system 400 provides access to the TPF data, it provides minimal or no query ability. In addition, any query ability provided by the TPF based system 400 may require new applications, which may not be readily available for use by the user. Thus, a non-SQL client, such as a computer with a command line interface, which is only connected to a TPF based system 400, may not be able to place a query requests against the TPF data stored in the TPF database 420. The translation process 550, however, provides the ability of accessing, which includes querying, the propagated data that is stored in the relational database 540. Since the relational database 540 may have a relational replica of the database 420, the non-SQL client does not loose any data by querying the relational database 540 instead of the TPF database 420.
A non-SQL client may access the data stored in the relational database 540 via the translation process 550, data propagation selection process 510, and the function management process 510. A non-SQL client may send an access request, which may include a query request, to the TPF based system 400, which in turn sends this request to the non-TPF based system 500. For example, the request may be in the form of traditional TPF based commands, English commands, or any other form. The request is received by the data propagation selection process 440, which in turn, sends the request to the function management process 510. Both the data propagation selection process 440 and function management process 510 were described in the following description and thus, only the differences will be described now. The difference lies in step 920, where the parsed query request is sent to the translation process 550, which is shown in FIG. 6. The parsed request is received by the receiver 710 of the translation process 550. The receiver process sends the parsed request to the translator 715, which converts the request into the SQL-DML statements. Then, the SQL-DML statements are sent to sender 720, which sends the request to the relational database 540.
Once the request is sent to the relational database 540, the function management process 510 may be used to process the results. For example, once the database returns the results, these results may be sent to the non-SQL client, as indicated by step 935.. Thus, with the present invention, even a non-SQL client may be able to query data stored in the relational database 540.
EXEMPLARY IMPLEMENTATION
FIG. 7 illustrates an exemplary implementation of the location of the processes and use of the propagated data by a variety of clients. In both the TPF based system 400 and the non-TPF based system 500, the processes and applications may be stored on a single computer or distributed among several computers, for example, to provide load-balancing. As shown in FIG. 7, the function management process 510, distribution process 520, extraction and transformation process 530, translation process 550, and the relational database 540 may exist on three servers, the functional server, distribution server, and database server. In another embodiment, the function management process 510, distribution process 520, extraction and transformation process 530, the translation process 550, and the relational database 540 may exist on one server. These and other configurations are known to those skilled in the art and are also within the scope of the present invention.
Moreover, the operating environment for the various servers shown in FIG. 7 is known to those skilled in the art and is also within the scope of the present invention. For example, the database server may be part of a RDBMS and may operate in any open relational database environment, for example, DB2, Oracle, Ingres, Informix, or Sybase. The operating system for the database and distribution servers may be Unix or an equivalent system. The database and distribution servers may execute upon, for example, SMP (symmetric multi-processors) such as IBM's RISC System/600 Models J30 or R30, a MPP (massively parallel processors), such as IBM's SP 2.1, or Sun Solaris models such as Sun El 0000 Models. The distribution server may utilize readily available communication protocols, such as CORBA' s HOP, for interfacing with clients. Furthermore, as described in the foregoing description, the components shown in FIG. 7 may be connected in single or a combination of any type of computer network, such as the Internet, an Intranet, an Extranet, a LAN, or a WAN. For example, the database, functional, and distribution
servers may be connected in a LAN, which may be connected to the TPF based system 400 via network 600, such as a WAN, i.e., the network 600 may be a WAN. Moreover, as shown in FIG. 7, the data stored in the relational database 540 may be used by a variety of clients. For example, the laptop computer, printer, and fax machine may use applications, such as RDBMS applications, to access the data directly from the relational database 540. Moreover, the data may be provided by the distribution process 520 to registered systems, such as a system running business applications. Also, the data may be e-mailed via the distribution process using the e- mail server, which may connected to the Internet. The data may also be provided to a data ware house or a data mart, as shown in FIG. 7. Finally, the personal computer, which is connected to the TPF based system 400 and may be running emulation software, may access the data from either the TPF database 420 or the relational database 540, for example, with the assistance of the data propagation selection process, the function management process 510, and the translation process 550.
While the examples given in the foregoing description related to airlines and travel agents, the present invention is not limited to the airline industry. It will be apparent to those skilled in the art that various modifications and variations can be made in the system and method of the present invention and in construction of this invention without departing from the scope or spirit of the invention.
Moreover, other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as
exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

WHAT IS CLAIMED IS:
1. A data processing system comprising: a transaction processing facility (TPF) based computer including TPF data; a server computer, coupled to the TPF based computer, for receiving the TPF data propagated by the TPF based computer and for generating a structured query language (SQL) statement reflecting the received TPF data; and a relational database associated with the server computer, wherein the relational database is updated by using the generated SQL statement.
2. A data processing system according to claim 1, further comprising a first client terminal, coupled to the TPF based computer, for accessing the TPF data.
3. A data processing system according to claim 2, wherein the first client terminal inputs new data into the TPF based computer, retrieves the TPF data, changes the TPF data, and deletes the TPF data.
4. A data processing system according to claim 2, wherein the first client terminal accesses data from the relational database.
5. A data processing system according to claim 4, wherein the first
client terminal retrieves and queries the data stored in the relational database.
6. A data processing system according to claim 1, further comprising a second client terminal, coupled to the server computer, for accessing data stored in the relational database.
7. A data processing system according to claim 6, wherein the second client terminal accesses the data from the relational database independently of the TPF based computer.
8. A data processing system according to claim 7, wherein the second client terminal retrieves and queries the data stored in the relational database.
9. A data processing system according to claim 1, wherein the TPF based computer asynchronously propagates the TPF data to the server computer.
10. A data processing system according to claim 1 , wherein the server computer includes a distribution means for receiving the propagated TPF data from the server computer after update of the relational database.
11. A data processing system according to claim 10, wherein the distribution means sends the propagated TPF data in real time to a registered system.
12. A data processing system according to claim 10, wherein the distribution means e-mails the propagated data to a customer.
13. A data processing system according to claim 1, wherein the server
computer includes an extraction and transformation means for extracting the data stored in the relational database, transforming the extracted data, and sending of the transformed data to an extraction and transformation client.
14. A data processing system according to claim 13, wherein the extraction and transformation client is chosen from a data mart and a data warehouse.
15. A data propagation method, comprising the steps of: propagating data from a transaction processing facility (TPF) based computer to a server computer;
generating a structured query language (SQL) statement reflecting the propagated data by the server computer; and updating a relational database corresponding to the server computer by using the SQL statement.
16. The method according to claim 15, further comprising the step of accessing data from the TPF based computer using a first client terminal that is coupled to the TPF based computer.
17. The method according to claim 16, wherein the step of accessing data includes inputting new data into the TPF based computer, retrieving the TPF data, changing the TPF data, and deleting the TPF data.
18. The method according to claim 16, further comprising the step of
accessing data from the relational database using the first client terminal.
19. The method according to claim 18, wherein the step of accessing includes retrieving and querying the data stored in the relational database.
20. The method according to claim 15, further comprising the step of accessing data from the relational database with a second client terminal that is coupled to the server computer.
21. The method according to claim 20, wherein the step of accessing the data is done independently of the TPF based computer.
22. The method according to claim 21 , wherein the step of accessing data includes retrieving and querying the data stored in the relational database.
23. The method according to claim 15, wherein the step of propagating data is performed asynchronously.
24. The method according to claim 15, further comprising the step of receiving propagated data by a distribution means of the server computer after updating the relational database.
25. The method according to claim 24, further comprising the step of sending the propagated data by the distribution means in real time to a registered
system.
26. The method according to claim 24, further comprising the step of e- mailing the propagated data by the distribution means to a customer.
27. The method according to claim 15, further comprising the step of extracting the data from the relational database, transforming the extracted data, and sending the transformed data by an extraction and transformation means of the server computer to an extraction and transformation client.
28. The method according to claim 27, wherein the extraction and transformation client is chosen from a data mart and a data warehouse.
29. A data processing system comprising: a transaction processing facility (TPF) based computer including TPF data; a server computer including a relational database, coupled to the TPF based computer, the relational database including a structured replica of the TPF data; and a client terminal for sending a miscellaneous function management request to the TPF based computer; wherein the TPF based computer sends the miscellaneous fimction management request to the server computer, which generates a structured query language (SQL) statement reflecting the miscellaneous fimction management request, and sends the generated SQL statement to the relational database.
30. A data processing system according to claim 29, wherein data is retrieved from the relational database by using the generated SQL statement and sent to a customer via e-mail.
31. A miscellaneous function management method, comprising the steps of:
sending a miscellaneous function management request by a client terminal to a transaction processing facility (TPF) based computer; sending the miscellaneous function management request by the TPF based computer to a server computer, which includes a relational database that has a structured replica of data stored on the TPF based computer; and generating a structured query language (SQL) statement reflecting the miscellaneous function management request and sending the generated SQL statement by the server computer to the relational database.
32. The method according to claim 31, further comprising the step of retrieving data from the relational database by using the generated SQL statement and sending the retrieved data to a customer via e-mail.
33. A computer-readable medium containing instructions for causing a computer to perform a method for propagating data, comprising the steps of: propagating data from a transaction processing facility (TPF) based computer
to a server computer; generating a structured query language (SQL) statement reflecting the propagated data by the server computer; and updating a relational database associated with the server computer by using the SQL statement.
34. The computer-readable medium according to claim 33, further comprising the step of accessing data from the TPF based computer using a first client terminal that is coupled to the TPF based computer.
35. The computer-readable medium according to claim 34, wherein the step of accessing data includes inputting new data into the TPF based computer, retrieving the TPF data, changing the TPF data, and deleting the TPF data.
36. The computer-readable medium according to claim 34, further comprising the step of accessing data from the relational database using the first client terminal.
37. The computer-readable medium according to claim 36, wherein the step of accessing includes retrieving and querying the data stored in the relational database.
38. The computer-readable medium according to claim 33, further
comprising the step of accessing data from the relational database with a second client terminal that is coupled to the server computer.
39. The computer-readable medium according to claim 38, wherein the step of accessing the data is done independently of the TPF based computer.
40. The computer-readable medium according to claim 39, wherein the step of accessing data includes retrieving and querying the data stored in the relational database.
41. The computer-readable medium according to claim 33, wherein the step of propagating data is performed asynchronously.
42. The computer-readable medium according to claim 33, further comprising the step of receiving propagated data by a distribution means of the server computer after updating the relational database.
43. The computer-readable medium according to claim 42, further comprising the step of sending the propagated data by the distribution means in real time to a registered system.
44. The computer-readable medium according to claim 42, further comprising the step of e-mailing the propagated data by the distribution means to a customer.
45. The computer-readable medium according to claim 33, further
comprising the step of extracting the data from the relational database, transforming the extracted data, and sending the transformed data by an extraction and transformation means of the server computer to an extraction and transformation
client.
46. The computer-readable medium according to claim 45, wherein the extraction and transformation client is chosen from a data mart and a data warehouse.
47. A computer-readable medium containing instructions for causing a computer to perform a method for miscellaneous function management, comprising the steps of:
sending a miscellaneous function management request by a client terminal to a transaction processing facility (TPF) based computer; sending the miscellaneous fimction management request by the TPF based computer to a server computer, which includes a relational database that has a structured replica of data stored on the TPF based computer; and generating a structured query language (SQL) statement reflecting the miscellaneous fimction management request and sending the generated SQL statement by the server computer to the relational database.
48. The computer-readable medium according to claim 47, further comprising the step of retrieving data from the relational database by using the generated SQL statement and sending the retrieved data to a customer via e-mail.
PCT/US2001/041375 2000-07-17 2001-07-16 System, method, and article of manufacture for propagating transactional processing facility based data to a variety of clients WO2002007001A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2001281323A AU2001281323A1 (en) 2000-07-17 2001-07-16 System, method, and article of manufacture for propagating transactional processing facility based data and for providing the propagated data to a variety of clients
EP01959804A EP1327200A2 (en) 2000-07-17 2001-07-16 System, method and article of manufacture for propagating transactional processing facility based data to a variety of clients

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/617,509 US6714945B1 (en) 1995-11-17 2000-07-17 System, method, and article of manufacture for propagating transaction processing facility based data and for providing the propagated data to a variety of clients
US09/617,509 2000-07-17

Publications (2)

Publication Number Publication Date
WO2002007001A2 true WO2002007001A2 (en) 2002-01-24
WO2002007001A3 WO2002007001A3 (en) 2003-04-24

Family

ID=24473919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/041375 WO2002007001A2 (en) 2000-07-17 2001-07-16 System, method, and article of manufacture for propagating transactional processing facility based data to a variety of clients

Country Status (3)

Country Link
EP (1) EP1327200A2 (en)
AU (1) AU2001281323A1 (en)
WO (1) WO2002007001A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668744B2 (en) 2003-07-31 2010-02-23 The Boeing Company Method and system for conducting fleet operations

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997030404A1 (en) * 1996-01-18 1997-08-21 The Sabre Group, Inc. System for propagating airline tpf data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997030404A1 (en) * 1996-01-18 1997-08-21 The Sabre Group, Inc. System for propagating airline tpf data

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Oracle Data Mart Builder Getting Started" [Online] February 1999 (1999-02) , ORACLE CORPORATION , 500 ORACLE PARKWAY, REDWOOD CITY, CA 94065 XP002226580 Retrieved from the Internet: <URL: http://otn.oracle.com/doc/dms.25/pdf/dmbgs.pdf> [retrieved on 2002-11-01] page 1-1, line 8 - line 15 *
"Transaction Processing Facility General Information" [Online] September 1993 (1993-09) , IBM CORPORATION , POUGHKEEPSIE, NY 12601-5400, USA XP002226769 Retrieved from the Internet: <URL: http://www-3.ibm.com/software/ts/tpf/images/gtpgim00.pdf> [retrieved on 2003-01-10] the whole document *
BISBAL J ET AL: "An overview of legacy information system migration: A Brief Review of Problems, Solutions and Research" TRINITY COLLEGE DUBLIN COMPUTER SCIENCE DEPARTMENT TECHNICAL REPORTS, [Online] vol. 1999, no. 38, 1999, XP002226579 Dublin, Ireland Retrieved from the Internet: <URL:http://citeseer.nj.nec.com/398128.html> [retrieved on 2003-01-08] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668744B2 (en) 2003-07-31 2010-02-23 The Boeing Company Method and system for conducting fleet operations

Also Published As

Publication number Publication date
EP1327200A2 (en) 2003-07-16
WO2002007001A3 (en) 2003-04-24
AU2001281323A1 (en) 2002-01-30

Similar Documents

Publication Publication Date Title
US6714945B1 (en) System, method, and article of manufacture for propagating transaction processing facility based data and for providing the propagated data to a variety of clients
US6122642A (en) System for propagating, retrieving and using transaction processing facility airline computerized reservation system data on a relational database processing platform
US6256621B1 (en) Database management system and query operation therefor, including processing plural database operation requests based on key range of hash code
JP2538719B2 (en) How to access the server database
US7747610B2 (en) Database system and methodology for processing path based queries
US8943029B2 (en) On-line transaction processing (OLTP) compression and re-compression of database data
US6941310B2 (en) System and method for caching data for a mobile application
US5826258A (en) Method and apparatus for structuring the querying and interpretation of semistructured information
US7822710B1 (en) System and method for data collection
US6556988B2 (en) Database management apparatus and query operation therefor, including processing plural database operation requests based on key range of hash code
US20080162425A1 (en) Global anchor text processing
US20020078039A1 (en) Architecture for distributed relational data mining systems
EP2874077A2 (en) Stateless database cache
US10042889B2 (en) Pseudo columns for data retrieval
US7765196B2 (en) Method and apparatus for web cache using database triggers
US20090259643A1 (en) Normalizing query words in web search
US20050256897A1 (en) Providing the timing of the last committed change to a row in a database table
CN111309760A (en) Data retrieval method, system, device and storage medium
US6345271B1 (en) Method and apparatus for transforming queries
US7689542B2 (en) Dynamic return type generation in a database system
JP3808941B2 (en) Parallel database system communication frequency reduction method
US20040039755A1 (en) Metadata relationships
US20040254947A1 (en) Using a cache to provide cursor isolation
JP4189332B2 (en) Database management system, database management method, database registration request program, and database management program
CN111126073B (en) Semantic retrieval method and device

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 2001959804

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2001281323

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2001959804

Country of ref document: EP

ENP Entry into the national phase in:

Ref document number: 2003129166

Country of ref document: RU

Kind code of ref document: A

Format of ref document f/p: F

NENP Non-entry into the national phase in:

Ref country code: JP