FR3049082A1 - SYSTEM MIGRATION USING SELECTIVE ENVELOPE MANAGEMENT CONTEXT - Google Patents

Abstract

Methods, systems, and computer program products for migrating a system from an existing platform to a replacement platform. Inbound data is provided to the existing platform and the replacement platform during a dual migration phase and the documents in the existing database and those in the replacement database are updated independently on the basis of those. In response to updating a document in the replacement database, an image of the document is captured in an envelope to maintain a historical record of the document. During the dual execution phase, documents can be migrated from the existing database to the replacement database and can be captured as images in envelopes in the replacement database. The images of the migrated documents can be compared with the images of the original documents to validate the replacement platform. The migrated documents can be cleaned up and the original documents can be filtered or merged with the migrated documents based on the comparison. The migrated documents or the original documents can then be selected as the master document.

Description

SYSTEM MIGRATION USING SELECTIVE ENVELOPE MANAGEMENT

CONTEXT

The invention generally relates to computers and computer software and in particular methods, systems, and computer program products for migrating the operations of a system from a software platform to a computer. another.

[0002] Data processing systems typically include a computer on which one or more software applications operate that exchange data files with other data processing systems. To perform their intended functions, software applications often store and extract data files from one or more databases. Software applications can rely on these data files to properly process queries received from other data processing systems. Databases can therefore provide a type of searchable memory that allows the data processing system to process requests and generate responses based on the results of the previously obtained data processing.

In time, the software applications, as well as the computers that house them, may become obsolete and need to be replaced. Since obsolete software often still provides critical functions for system users, any substantial disruption of existing application operations can have serious consequences for the system user. Thus, the migration of operations from a data processing system from an existing software platform to a new software platform entails a certain degree of risk for the system user if the migration takes place not without incident.

[0004] Although system migration may be unavoidable for most systems, system migration may present particular risks for revenue accounting systems due to the need for assured continuity of financial processing during and after the migration. Business continuity during system migration can affect, for example, the processing of financial accounts, conflict management, partnership management, and outbound data provisioning. System migration may require validation of data processing, internally generated data files, and migrated data files in the new system. With conventional systems, the success of migrating existing data and process files to a replacement platform can only be truly appreciated after failover, when completeness and accuracy reports become available. To solve the problems caused by the migration, the validation of new system processes using tracking audits that compare the migrated data with the existing data may be necessary for a substantial period of time after the failover. These shortcomings in existing methods for migrating data from processing systems can increase the risk of system downtime and faulty processing of data files.

[0005] Thus, there is a need for improved computer systems, methods, and computer program products for migrating processing system data from a software platform to another platform to reduce the risks associated with system migration. SUMMARY [0006] In one embodiment of the invention, a data processing system including an existing platform and a replacement platform is provided. The system includes one or more processors and a memory coupled to the processors. The memory stores an encoded program which, when executed by at least one of the processors, causes the system to receive incoming data from each of the existing platforms and the replacement platform, the incoming data being relative to a first document in the existing database. The encoded program also causes the system to update the first document in the existing database based on the incoming data, generate a second document in a replacement database based on the incoming data, and capture an image. the second document in an envelope, in the replacement database.

In another embodiment of the invention, a method for migrating the data processing system from an existing platform to a replacement platform is provided. The method includes receiving incoming data, updating the first document in the existing database based on the incoming data, generating a second document in the replacement database based on the incoming data, and capturing the image of the second document in the envelope, in the replacement database.

In another embodiment of the invention, a computer program product is provided which includes a computer-readable non-transitory storage medium comprising an encoded program. The encoded program is configured to, when executed by one or more processors, cause the processors to receive the incoming data, update the first document in the existing database based on the incoming data, generate the second document in the replacement database according to the incoming data, and capture the image of the second document in an envelope in the replacement database.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying and illustrating drawings of various embodiments of the invention, with the general description of the invention above and the detailed description of the embodiments provided below, serve to explain the embodiments of the invention. the invention.

[0010] FIG. 1 is a schematic view of an exemplary operating environment including a plurality of data processing systems in communication via a network.

FIG. 2 is a schematic view of an exemplary data processing system of FIG. 1.

FIG. 3 is a schematic view of a block diagram illustrating an existing platform is a replacement platform that may be housed by one or more of the data processing systems of FIG. 1.

FIG. 4 is a diagrammatic view of a block diagram illustrating a logical relationship between a document and a plurality of envelopes that can be stored in a database of the replacement platform of FIG. 3.

FIG. 5 is a schematic view illustrating an exemplary structure of the document of FIG. 4.

FIG. 6 is a schematic view illustrating hierarchical tree structures for the document of FIG. 5 for each of the databases: the existing database and a replacement database.

FIG. 7 is a schematic view illustrating a table of discrepancies that can be stored in a validation database.

FIG. 8 is a schematic view of a user interface that can be used to display the data stored in the divergence table of FIG. 7.

[0018] FIG. 9 is a schematic view of the process flow for migration of a data processing system from an existing platform to a replacement platform of FIG. 3.

DETAILED DESCRIPTION

Embodiments of the invention may be implemented by a data processing system, such as the Global Distribution System (GDS). The data processing system can provide processing functions and database functions that facilitate internal connections between one or more third party vendor systems, carrier systems, billing and settlement plan systems, systems, and systems. revenue accounting, or any other data processing system associated with the contribution of travel products. In the context of air travel, the data processing system may allow travelers to book and confirm air tickets and other travel products through indirect sales channels. These indirect sales channels may include online travel agencies or other companies that sell tickets for services provided by different companies (for example, a carrier). Indirect sellers may receive a payment from travelers for confirmed tickets and compensate the carrier for the cost of the service provided from the payment received, or alternatively they may ask the traveler to make a payment directly to the carrier.

Embodiments of the invention may include a migration manager for setting up a phased data migration strategy for migrating data processing systems from an existing database including an application. existing and an existing database, to a replacement platform that includes an existing application and an existing database. The migration manager can provide adaptive storage, manipulation, and reporting for multiple envelopes for each document being migrated from the existing platform to the replacement platform. The migration manager can receive data extracted by the existing application from documents in the existing database, while the existing platform is running with actual system data. The migration manager can use this data to create a migration envelope in the replacement database. At the same time, the replacement application can generate original envelopes separately in the replacement database by working with the actual system data in shadow mode. The migration envelope can fall between corresponding original envelopes, and the migration manager can use the original envelopes to compare, generate reports, clean migrated documents, or merge migrated documents with documents. 'origin. During this parallel operation period, or "dual operation", the migration manager can perform an automated comparison of the data to detect differences between the data in the existing database and those in the replacement database based on the database. multiple envelopes to evaluate data mapping and aggregation.

The migration manager can enable a flexible and phase-based data migration strategy through selective envelope management in the replacement platform. The double operation of the existing platform and the replacement platform, and the selective management of the envelope in the replacement platform, can allow the cleaning and validation of data on the fly, as well as the production postmigration reports during the migration period. An assessment following the migration process may include generating data streams based on user-selected data in the replacement system (for example, migrated envelopes, or the latest available original envelopes) to validate process or automatically populate test environments.

[0022] Referring now to FIG. 1, an exemplary operating environment according to one embodiment of the invention may include a global distribution system (GDS) 12, one or more indirect sellers systems, such as a travel agency 14, one or more travel product provider systems such as a carrier system 16, a billing and settlement system (Billing and Only Plan, or BSP) 18, a system of the company Tariff Editing (TariffFPublishing Company, or TPC) 20, and a revenue accounting system 22. Each of them: the GDS 12, the travel agency system 14, the carrier system 16, the system BSP 18, the TPC system 20, and the revenue accounting system 22, may communicate via a network 24. The network 24 may include one or more private and / or public networks (e.g. allow the escape nge of data.

The GDS 12 may be configured to facilitate communication between the carrier system 16 and the travel agency system 14 by allowing travel agents, transmitting carriers, or other indirect sellers to confirm reservations on one or more carrier systems. By this, the GDS 12 can maintain links to each carrier system 16 via the network 24. These links may allow the GDS 12 to route the reservation requests from the gateway. the travel agency system 14 and / or the carrier system 16 from the transmitting carrier to the corresponding fact carrier system 16. The travel agency system 14 and the carrier system 16 can thus confirm flights with multiple airlines. through a single GDS 12 connection. The GDS 12 can store Passenger Name Records (PNR) generated by the carrier system 16, as well as data that defines the rate context parameters and ticket prices associated with confirmed bookings in one or more searchable databases. This data may allow a PNR that includes a complete set of flight data for a route that includes flight segments on multiple airlines to be retained by GDS 12.

The carrier system 16 may include a computer reservation system (or CRS) and / or a billing system for the respective airlines that allows the GDS 12 and / or the travel agency system 14 to book. and pay for airline tickets. The carrier system 16 may also interact with other carrier systems 16, directly or through the GDS 12, to allow a transmitting carrier to sell tickets for seating provided by the actual carrier. The actual carrier may then charge the issuing carrier for the services provided. Billing between companies acting as indirect vendor and companies acting as a supplier of travel products may be provided by BSP 18.

The BSP system 18 may be configured to receive data from the ticket office of the travel agency or carrier issuer that declares the sale of the ticket in the name of the carrier de facto. In the United States, Airline Reporting Corporation (ARC) normally provides this service. In any case, the BSP can serve as an external provider for the Business Process Outsourcer (BPO) and serves as a clearing house and settlement for accounts between travel agencies, issuing carriers, done and any other company involved in the transaction. The de facto carrier can thus collect a payment through the BSP for providing a seating position.

The TPC system 20 can be managed by a tariff publishing company such as Airline Tariff Publishing Company (ATPCO) or the International Aeronautical Telecommunications Company (SITA). The TPC system 20 may provide tariff data for multiple carriers at the GDS 12, the travel agency system 14, the carrier system 16, the BSP system 18, the revenue accounting system 22, or any other system that needs tariff data. Tariff data may include rules that must be met in order for the corresponding tariff to be applied and that can be updated regularly by the corresponding travel suppliers.

The revenue accounting system 22 can manage the control, use, and accounting of electronic tickets, miscellaneous billing orders (Miscellaneous Charges Orders, or MCOs), various electronic documents (Electronic Miscellaneous Documents, or EMDs), and other electronic documents associated with the sale and use of travel products. The revenue accounting system 22 can validate transactions and correct billing errors, for example by recovering under-collected amounts. The revenue accounting system 22 may also be configured to detect fraud and to deliver the passenger segment and revenue related data to the back-office systems of the travel providers. Although illustrated as a separate system, the revenue accounting system 22 may also be included in one or more of the GDS 12 systems, the travel agency system 14, the carrier system 16, the BSP system 18, TPC 20 system, or it can be provided by those.

[0028] Referring now to FIG. 2, the GDS 12, the travel agency system 14, the carrier system 16, the BSP system 18, the TPC system 20, and the revenue recognition system 22 of the operating environment 10 can be implemented on one or several devices or computerized systems, such as the exemplary computer 30. The computer 30 may include a processor 32, a memory 34, a mass memory device 36, an input / output (I / O) interface 38, and a Human Computer Interface (HMI) 40. Computer 30 may also be operably coupled to one or more external resources 42 via network 24 or I / O interface 38. External resources may include, non-exhaustively, servers, databases, mass storage devices, peripheral devices, cloud network services, or any other appropriate computer resource that can be used with the computer. r 30.

The processor 32 may include one or more selected devices: microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, programmable gate networks, programmable logic devices, state-defined machines, logic circuits, analog circuits, digital circuits, or any other device for manipulating signals (analog or digital) based on operating instructions stored in the memory 34. The memory 34 may include a single device or a plurality of memory devices, including, but not limited to, read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or t other device capable of storing information. The mass storage device 36 may include data storage devices such as a hard disk, an optical disk, a tape drive, a volatile or nonvolatile solid state circuit, or any other device capable of store the information.

The processor 32 can operate under the control of an operating system 44 that resides in the memory 34. The operating system 44 can manage the computer resources so that the computer coded program, integrated form one or more application software, such as the application 46 which resides in the memory 34, can receive the instructions executed by the processor 32. In another embodiment of the invention, the processor 32 can execute the application 46 directly, and in this case the operating system 44 may be omitted. One or more data structures 48 may also reside in the memory 34 and may be used by the processor 32, the operating system 44, or the application 46 for storing or manipulating data.

The I / O interface 38 can provide a machine interface that couples the processor 32 in a functional manner with other devices and systems, such as the network 24 or the external resource 42. The application server 46 can thus collaborating with the network 24 or with the external resource 42 by communicating via the I / O interface 38 to provide the various elements, functions, applications, processes, modules making up the embodiments of the invention. The application 46 may also include an encoded program that is executed by one or more external resources 42, or otherwise relies on the functions or signals provided by other system or network components external to the computer 30. Indeed, in view of the almost infinite configurations of possible hardware and software, those skilled in the art will understand that the embodiments of the invention may include applications located externally to the computer 30, distributed to multiple computers or other external resources 42, or provided by computer resources (hardware and software) that are provided by a service such as a cloud computing service, via the network 24.

The HMI40 can be operatively coupled to the processor 32 of the computer 30, in a known manner, to allow a user to interact directly with the computer 30. The HMI 40 may include a video display or a unit a character display, a touch screen, a speaker and any other visual and audio indicator capable of communicating data to the user. HMI 40 may also include devices and controls such as alphanumeric keypad, pointing device, keyboards, pushbuttons, control buttons, microphones, etc. capable of accepting commands or inputs from the user and transmit them to the processor 32.

A database 50 may reside on the mass memory device 36, and may be used to collect and organize the data used by the various systems and modules described herein. The database 50 may include data and accommodate the associated data structures that store and organize the data. In particular, the database 50 can be arranged with any organization or database structure, including, but not limited to, a relational database, a hierarchical database, a networked database, an object-oriented database, or combinations of these.

A database management system, in the form of a software application executing instructions on the processor 32, can be used to access the information or the data stored in the records of the database 50, in response to a query. The query can be dynamically determined and executed by the operating system 44, other applications 46, one or more modules, or any other appropriate system element. Although embodiments of the invention, described herein, use in some cases a hierarchical relational database, network, object-oriented, or other appropriate database management model terminology, they are not limited to any particular type of database.

[0035] Referring now to FIG. 3, a migration manager 52 can facilitate the migration of a system from an existing platform 54 to a replacement platform 56. For this purpose, the migration manager 52 can manage the communications and the transfer. between the network 24 and the replacement platform 56. The existing platform 54 may include an existing application 58 and an existing database 60 comprising an existing system that is being replaced or upgraded. The replacement platform 56 may include a replacement application 62 and a replacement database 64 that include a replacement system that replaces or provides an upgrade to the existing system. The migration manager 52, the existing platform 54, and the replacement platform 56 may reside within a single system or may reside on two or more physically or logically separated systems.

The migration manager 52 may include an envelope management module 66 which analyzes the envelopes in the replacement database 64 and a validation database 68 which stores the detected differences between the original envelopes and envelopes migrated to replacement databases 64. Although the existing platform 54 and the replacement platform 56 are described below in the context of the migration of a revenue accounting system 22, Embodiments of the invention are not limited. Thus, the existing platform 54 and the replacement platform 56 could represent platforms for any data processing system being migrated, and the embodiments of the invention are not limited to migration. of a particular type of data processing system.

In the context of the migration of the revenue accounting system 22 from the existing platform 54 to the replacement platform 56, the existing platform 54 can receive incoming data through an existing data stream. 70, and the replacement platform 56 can receive the same incoming data through an incoming data replacement stream 72. The received data may include messages or files transmitted from one or more GDSs 12, travel agency systems 14, conveyor systems 16, BSP systems 18, TPC systems 20, any other system in communication with the existing platform 54 or the replacement platform 56 through the network 24.

Received data may include operational data, such as intercompany (interline) magnetic data transfer (Hand-Off Tape, or HOT) tapes used to transmit IATA BSP transactions: travel agency-airline and airline - Travel agency, Carrier Accounting Tape (or CAT) tapes used to report ARC transactions: travel agency-airline and airline-travel agency, records of control numbers Transaction Control Number, or TCN, Industry Sales Record (or ISR) and Tariff Data.

Each of the platforms, the existing platform 54 and the replacement platform 56 can process the received data using the existing application 58 or the replacement application 62 respectively, and update the records. in the existing corresponding database 60, or the corresponding replacement database 64. The existing platform 54 can output data through the existing outgoing data stream 74, and the replacement database 56 can outputting data via the outgoing data replacement stream 76. The outgoing data may be in the form of responses to messages or received files.

[0039] Referring now to FIG. 4, a document 84 is illustrated in relation to a plurality of envelopes 86 - 88. The documents may be stored in the existing database 60 and the replacement database 64, and may be the most basic type of data that is migrated from the existing database 60 to the replacement database 64. Each document can include one or more coupons and a unique identifier that allows the documents to be uniquely identified. The documents may include data files that can be migrated from the existing database 60 to the replacement database 64 independently, although one document may relate to another document.

The replacement database 64 may follow the documents using the envelopes 86-88. Each envelope 86-88 may include an image of the document 84 generated at a specific point in time. The history of document 84 can be preserved by generating a new envelope or adding an image to an existing envelope each time document 84 is modified. The most recently generated envelope (for example, envelope 88) may include the most recent image of the document and may thus contain the most up-to-date data. In contrast, the initial envelope generated (e.g., envelope 86) may include the first available image of the document (e.g., the image of the document at the time the document was first generated or migrated) and may contain the most recent data available for this document.

The envelope management module 66 may be configured to compare original envelopes with migrated envelopes of a document in the replacement database 64. The envelope management may include the selection of envelopes for the processing of the received data and the comparison of the envelopes for validation by the system. A given envelope can represent the data migrated from the existing database 60 (i.e., a migrated envelope), the data originally generated by the replacement application 62 (that is, a migrated envelope). that is, an original envelope) or a combination of migrated data and generated original data (i.e., a merged envelope). By giving visibility to the current and historical differences between the original envelopes, the migrated envelopes, and the merged envelopes in the replacement database 64, the envelope management module 66 can facilitate decisions about the migration to From an existing platform 54 to a replacement platform 56. For example, the envelope management module 66 can provide audit trail comparisons between migrated documents, original documents and documents including merged data. in the replacement database 64.

The envelope management module 66 can provide flexible management of the master data by selectively mapping the selected envelope data in the replacement database 64 to a single operation document which is transmitted by the user. Intermediate outgoing data replacement flow 76. Envelope management module 66 can provide data control through a historical migration mode that migrates data from existing database 60 to generate labeled envelopes. historical envelopes, but label the most recent envelope generated by the replacement application 62 as the master envelope.

The envelope management module 66 may also clean the documents in the replacement database 64. The cleaning of the documents may include the detection and correction of corrupted or erroneous data elements in the documents. For this purpose, the envelope management module 106 can identify in the existing database 60, the missing or erroneous data elements, during the migration of the documents to the replacement database 64. identification of erroneous or corrupt data elements may be based on comparisons with corresponding envelopes in the existing database 60. The envelope management module 66 may then replace or modify the corrupted data elements by merging the values. from selected envelopes.

The envelope management module 66 can also provide reports and comparisons by tagging, and by selecting specific envelopes for reports and retransmission.

The data files managed by the system being migrated (for example, the revenue accounting system 22) may comprise documents (for example, electronic tickets), each document comprising one or more coupons and each of them. 'between them representing a segment of a route defined by the document. In particular, the revenue accounting system 22 can support real-time data acquisitions and updates of documents and coupons from different sources, for example, an electronic ticket server, a server of various electronic documents. , a departure control system, etc. Each new event that results in a change in the document can trigger the creation and storage of a specific envelope that contains the original data, plus data updated due to the event. Thus, the most recent envelope of a given document may represent the most recent image of the document.

Envelopes may be labeled as belonging to a specific type, for example, master, dependent, historical, raw migrated, merged migrated, or any other relevant type defined in the replacement platform 56. Default the envelope management module 66 may be configured to access the most recent envelope for any received process call that uses or updates a document or coupon, regardless of any tags that may be present. However, the tags may provide a mechanism for the envelope management module 66 to access a specific envelope based on a tag. For example, the envelope management module 66 may be configured to access an envelope that is labeled as a master envelope even if there is a newer envelope for the document in question. The envelope management module 66 may also use envelopes that provide an audit trail document.

The existing database 60 and the replacement database 64 may have different document structures which may prevent the validation of reference data by using direct comparisons between documents in the existing database 60 (c that is, existing documents) and the documents in the replacement database 64 (ie, replacement documents). For example, each database can use a different business object model, a different data storage structure, a different export data layout (for example, comma-separated values against fixed lengths), and / or a different order for transactions and repetitive items (for example, coupons, taxes and forms of payment). Existing documents and replacement documents may also display data differences caused by rounded values or report formats.

In order to remedy the difficulties encountered during validation, caused by differences in database structure, the migration manager 52 can be configured to analyze documents in a number of "extracted files", each of them containing a specific type of data. Files extracted from corresponding documents from the existing database 60 and from the replacement database 64 can be compared generally directly. In one embodiment of the invention, each document can be divided into three different extracted files: one for the documents, another for the coupons and the last for the fees and taxes (Fees-Fees-Charges, or TFCs).

The migration manager 52 can begin the process of analyzing an existing document exported from the existing database 60 by identifying the comparable elements in the document. The migration manager 52 can then describe the contents of the existing document using a predefined syntax to identify a grammatical structure of the document. The migration manager 52 can then perform a functional mapping between the elements identified in the existing document and corresponding fields of the replacement document in the replacement database 64 according to the corresponding elements in the predefined syntax. The migration manager 52 may then populate the fields of the replacement document with the data exported from the existing document based on the mapping.

In one embodiment of the invention, the grammar-based analysis can be performed by the migration manager 52 while the reference data is retrieved from the existing database 60 and is used to populate them. Documents in the replacement database 64. The execution time of the analysis performed by the migration manager 52 may allow the existing platform 54 and the replacement platform 56 to operate in parallel without modification. software to accommodate differences in document format. The execution time of the analysis can also allow the same functional data of an outgoing flow to be compared in two different document formats, for example, the standard format of the data exchange center between companies (Interline Data Exchange Center, or IDEC) Integrated Settlement Format (IDEC), IDEC and IS-XML, etc.

The document analysis based on the grammar can enable the migration manager 52 to ignore specific fields in a document, or differences in the values of particular fields that are below a predetermined threshold for example, values less than a fixed amount or a percentage of the value of the items being compared. In either case, the migration manager 52 may perform post-process filtering to remove known differences between the existing document and the replacement document. The discrepancies between the mapped elements can be stored in the validation database 68 to facilitate calculation of the user's key performance indicators that can rely on comparison processes or specific fields.

The generation of extracted files in the existing database 60 and in the replacement database 64 can allow the validation of database data in the raw state before the processing of the corresponding documents by the existing application. 58 or the replacement application 62. Extracted files can also provide flexibility by enabling data validation independent of platform data formats and database structures. Extracted files can also improve tracking through the use of KPIs that enable users to set objective failover criteria based on the data quality of the replacement platform.

[0052] Referring now to FIG. 5, an exemplary document 90 comprising two coupons 92 and 94 is illustrated in the form of a grammar file. The grammar file may include a plurality of data fields, each of which contains a data element. In an illustrated exemplary embodiment, each coupon 92 and 94 includes a character type element 96, a nine character date element 98, a 13 character ticket number element 100, a six character PNR element 102 , a three-character currency element 104, an eight-character tariff element 106, and elements representing three tax groups, 108, 110,112, each of which has a two-character code (for example, YQ, FR). , <null>) and an amount of eight characters (for example, 00000.00; 00009.50; 00010.00; 00020.00).

[0053] Referring now to FIG. 6, the coupon 92 is illustrated by two hierarchical tree structures 114 and 116 which can represent the coupon 92 in its storage form in the existing and replacement databases 60 and 64 respectively. Each tree structure 114 and 116 may comprise a plurality of linked nodes that map elements into a corresponding grammar file of coupon 92. Exemplary tree structures 114 and 116 each include a document node 118 and 120, a node node 122, and 124, a currency node 126 and 128, a date node 130 and 132, a ticket number node 134 and 136, a document type node 138 and 140, are three tax group nodes 142 - 144,146 - 148 each being the parent of a respective node of amounts 150 - 152, 154 - 156 and a node of codes 158 - 160, 162 - 164.

The document node 118-120 may contain data identifying the coupon 92, the amount node 122-124 may contain data defining the amount of the tariff, the currency node 126-128 may contain data identifying the currency. in which the amounts are denominated, the date node 130 - 132 may contain data defining a relevant date for the coupon 92 (for example, the date of the flight), the amount nodes of the tax groups 142 -144, 146 - 148 may contain data defining a tax or charge amount and the code nodes 150 - 152,154 - 156 may contain data defining a code that identifies the type of tax or charge. The mapping of the data elements included in the coupon 92 into a hierarchical tree structure can unify the representation of the underlying data, thus facilitating comparisons between a document having different grammatical formats in the existing database 60 and in the database. replacement data 64.

The nodes of the tree structures 114 and 116 can be sorted to solve problems caused by the random positioning of the data elements in the grammar files in the existing database 60 and in the replacement database 64. The comparison of the tree structure 116 generated from the coupon 92 stored in the replacement database 64 with the tree structure 114 generated from the corresponding coupon 92 stored in the existing database 60 can be used to quickly identify incorrect values and missing or additional nodes.

The migration manager 52 can store the results of the comparisons between documents in the validation database 68. For example, in the case of exemplary tree structures 114 and 116 illustrated in FIG. 6, the validation database 68 may store a table of divergences 170 as shown in FIG. 7. The divergence table 170 may include a plurality of columns 172-176, a header row 178, and one or more rows of data 180-182. The intersection of each column 172-176 and each rank 180-182 can define a data field that contains the information relating to a detected discrepancy between an existing document and a replacement document. The header rank 178 may include headers that identify the type of information located in each corresponding column of the data ranks 180 - 182. For example, as shown in FIG. 7, the header rank 178 includes headers for the data element type, the data element category, the identity of the document containing the data element in question, the value of the data element. data item in the existing document and the value of the data item in the replacement document.

In the exemplary case presented, three divergences have been detected between the coupon represented by the tree structures 114 and 116. As shown in rank 180, the amount of the tariff indicated in the node 122 of the tree structure 114 differs. the amount of the tariff indicated in the node 124 of the tree structure 116. The ranks 181 and 182 each illustrate a code divergence identifying the fees invoiced for the coupon 92.

The data in the divergence table 170 can be used to provide key performance indicators to the system users involved with the migration from the existing platform 54 to the replacement platform 56. These performance indicators keys can be provided to users for example by a web page. Referring now to FIG. 8, an exemplary user interface 190 for displaying key performance indicators may include text fields 192 - 195 for displaying information and graphics 198-201, based on text to display graphical information. such as a plot of key performance indicators over time. The user interface 190 may be provided by a web page configured to allow users to refine according to the file format, to obtain statistics on all or a portion of the validation process, to browse the pages of the file. errors of a specific process, refine by data type, view statistics by category or data element, browse errors and generate reports in various formats (such as portable document format (PDF ) using a table of key performance indicators.

[0059] Referring now to FIG. 9, an exemplary migration 210 from an existing platform 54 to a replacement platform 56 may be implemented in phases. The migration 210 may begin with an initial setup phase 212. The initial setup phase 212 may include linking a network 24 to each of the data feeds, the existing stream 70, and the stream of data. replacement 72, and to load reference data into the replacement platform 56. Baseline data may include, for example, private carrier's quota share agreements.

In some cases, the existing database 60 and one or more of the data sources provided to the incoming power replacement stream 72 may reside in the same system as the replacement database 64. This may occur for example, when a carrier's production accounting system is housed in the GDS 12 and is upgraded from the existing platform 54 to the replacement platform 56. In this case, the data reference database for populating the replacement database 64 can be acquired from an electronic ticket server and a server of various electronic documents when these servers are also housed on the GDS 12.

Conventional methods of system migration from an existing platform to a replacement platform typically solve problems involving reference data and data links at the end of the migration period. In contrast, the embodiments of the present invention can solve these problems at the beginning of the migration to allow for dual processing and validation of migration steps occurring later. This may allow validation of the process of acquiring the completeness of benchmark data and the accuracy of the replacement platform, in phases, using automated document comparisons. In particular, the documents originally generated by the replacement platform 56 can be compared to corresponding documents generated by the existing platform 54 during the ongoing double operations on the existing platform 54 and on the platform. replacement form 56.

Once the existing platform 54 and the replacement platform 56 have been connected to the data streams and the replacement database 64 is populated with the reference data, the migration of 210 may proceed. A dual acquisition phase 214. During the dual acquisition phase 214, the input data may be provided to both the existing data stream 70 and the replacement data stream 72 so that the incoming data provided together to the existing platform 54 and the replacement platform 56. The existing platform 54 and the replacement platform 56 can each process the incoming data and update their corresponding database, the existing database 60 and the replacement database 64.

The migration manager 52 can validate the documents generated by the replacement platform 56 by comparing them with the documents generated by the existing platform 54. For example, the migration manager 52 can compare the values of the elements of the document data as described above for Figs. 6 and 7. On the basis of specific data extracts provided by the existing platform 54, the documents can be segregated according to the occurrence of the problem over time, for example the month during which the document was generated. . To compare the issued documents, the migration manager 52 can apply the same analysis and mapping techniques described above to address the differences between the business object models and the existing platform data file formats. replacement 54 and 56.

The cleansing of specific data can be applied to corrupted documents when the platform 54 is unable to provide mandatory data to the replacement platform 56. In this case, the migration manager 52 can either fix missing data elements on default values, either compute a new value based on other data fields, or merge the data from a corresponding data field into the most recent envelope of the database replacement 64 for the document in question.

The type of envelope generated in the replacement database 64 from the migrated documents may also depend on the type of migration. Envelopes can be labeled, for example, as: master, slave, history, migrated raw data, or migrated and merged data envelopes. When the most recent envelope for the document in the replacement database 64 is tagged as history, the envelope management module 66 can identify the most recent envelope in the replacement database 64 whose timing precedes that of the migrated envelope. The envelope management module 66 can then generate a copy of the envelope identified as being, according to its time stamp, the most recent copied envelope for the document. Reinsertion of a previously generated envelope, whose timestamp is earlier than that of a migrated envelope, can be used when the migrated data is not to be used as master data by the following operational processes, but is retained in the replacement database 64 for historical purposes.

During the dual operations phase 216, the existing platform 54 and the replacement platform 56 may operate in parallel while the migration manager 52 continues to validate the data in the replacement database 64. This validation may include the comparison of documents in the replacement database 64 with documents in the existing database 60 and with previous versions of document captured in corresponding envelopes in the replacement database 64. In one mode alternative embodiment of the invention, the migration manager 52 can validate each document in the replacement database 64 only once by comparing the document with the corresponding document in the existing database 60 when the document is imported into the replacement database 64.

The migration manager may also generate reports that provide an indication of the accuracy and completeness of the migration. One way to determine accuracy is based on accounting reports. For example, an accounting report can add the monetary values of unused coupons and used coupons for documents in the existing database 60 and the replacement database 64. The proximity of the values of these sums can then provide indication of the degree of accuracy of the data that has been migrated from the existing platform 54 to the replacement platform 56.

The completeness of the migration can then be determined on the basis of the number of migrated documents compared to the number of documents received. Missing documents can be classified according to whether they are missing "normally" or missing "abnormally". A document normally missing may be a document received from the existing database 60 that was rejected by the migration manager 52 because the format or quality of the data in the document was insufficient. For example, a document may be rejected if mandatory fields are missing and cleaning is not possible. The abnormally missing document in the replacement database 64 may include missing documents while one or more of the migrated envelopes for the missing document are present. A document may be classified as abnormally missing if the document was provided by the existing database 60, but is missing from the replacement database 64. The abnormally missing documents can be detected by drawing, from the existing database, a list of migrated documents that do not have a corresponding envelope in the replacement database 64. This list can be used to ensure the accuracy of the failover by identifying documents not accounted for by the platform. existing 54 that are either missing or corrupt.

The validation of the replacement platform 56 during the double operation phase 216 can also be performed on the basis of the data received from external sources, for example, the outgoing billing files received by a de facto carrier by the In this type of validation, the data files in the outgoing data replacement stream 76 may be compared to data files in the outgoing data stream 74 that respond to the data stream. the same external interrogation. The use of real-time data during the dual operation phase 216 can allow both the documents in the replacement database 64 and the operation of the replacement application 62 to be validated, confirming that the flat Alternate Form 56 works well with migrated data and external applications.

The outgoing billing documents (that is to say, the documents transmitted a carrier transmitter for flights performed by the carrier whose system is being migrated) can be validated by comparing the documents generated by the platform alternative form 56 with the documents generated by the existing platform 54. The migration manager 52 can thus enable the validation of invoicing processes between companies using the same data as those used by the existing platform 54, by for example, the most recent envelope in the existing database 60.

Incoming billing documents (that is, the rejection memos transmitted to a de facto carrier for flights sold to the carrier whose system is being migrated) can be validated by comparing the value Advance billing for the flight, calculated by the existing platform 54 and by the replacement platform 56. The validation may be based on reports generated by each platform which contain the anticipated billing value, the amount of rejection, and the causes of the divergence.

The accounting system processes, for example, accounting logic and granularity, may be different between the existing platform 54 and the replacement platform 56. The validation of the document comparison accounting processes may be different between the existing platform 54 and the replacement platform 56. require a comparison framework that includes mapping between data fields in each document, mapping between current and future accounts, and mapping from one to one, one to many, many to one, and many to many fields. data. In some cases data fields can be aggregated without filtering values by summing all data field values, for example, by summing monetary values for multiple transactions associated with a single ticket. In other cases, the data fields can be aggregated without filtering by selecting one of the existing or replacement documents to provide the value to the aggregated document, for example, the date field with the most recent value.

Once the replacement platform 56 has been fully validated, the migration process may advance to failover 218, and at this point the outgoing process of the replacement platform 56 may become the master process. When a document is present in the replacement database 64, but is missing or corrupted in the existing database 60, the carrier can cancel the accumulation at the beginning of the first month after the final pass to the plate. If the accounting has not been carried out on the existing platform 54, the migration manager 52 can re-trigger an accounting of all the events relating to a missing document, for example, the sale of a ticket and all the events that affected the coupons in the document before the switchover.

When a document is missing or corrupted both in the existing database 60 and in the replacement database 64, the carrier can cancel any accumulation for the document in question at the beginning of the first month following the switchover. . A resolution task in the replacement platform 56 may be retained for resolution of a problem after the switchover. When the task has completed the resolution, the pre-change events can be recreated on the replacement platform 56 and can be taken into account.

In some cases, an external system may require data for the validation test. For example, carriers may require large volumes of actual production data to perform validation tests on their systems. The test may also require that documents and coupons be in a specific state for example, a document that is not yet confirmed, a document that has not yet been billed, etc. To provide this data, the migration manager 52 can select envelopes and generate documents based on those that have the required level of completeness. The migration manager 52 can thus replicate production data and provide the replicated data to the system under test. For this purpose, the migration manager 52 may include a user interface configured to allow the selection of a specific document or a list of documents (for example, all documents referenced HOT or IS-IDEC in a given file). The user interface can also allow the user to define a step in the lifecycle of the selected document that will be exported, for example before the document is transmitted as invoice between companies.

Embodiments of the invention may allow the data to be migrated from the existing platform 54 to the replacement platform 56 while retaining the original acquired data available from the platform. alternate form 56. Reports can be generated and the data migration can be validated. Compared with conventional methods of migrating from an existing platform to a replacement platform, the migration manager 52 allows phased migration over a period of time, or a migration period. The migration manager 52 can thus provide continuous and trouble-free validation in a production environment.

A dual operation framework can enable system migration in high volume environments using the actual system traffic, providing the same data traffic to both the existing platform 54 and the platform. alternate form 56. The replacement platform 56 may perform parallel processing of the data traffic, and generate an outgoing data replacement stream 76 based on migrated or originally generated database records. The availability of real-time data streams, both from the existing platform 54 and from the replacement platform 56, can allow for flexible comparisons and facilitate the generation of KPIs.

The migration manager 52 may allow the migration of improved and secure data for example, by providing an audit trail by comparing envelopes of newly generated documents and migrated or merged documents. The migration manager 52 may also allow the cleaning of document data by merging the values between envelopes and correcting the tasks of the replacement platform by the migration of data from the existing platform 54. migration 52 can also provide master data management features. These features may include a historical migration mode that migrates data from the existing database 60 to the replacement database 64 to provide a historical record of the document and that reclassifies the data of the replacement platform as last master event.

[0079] A pre-transfer data appropriation and correction characteristic can repair the tasks of the replacement platform by using migrated data. If the corresponding document of the replacement platform does not include migrated data from the existing database 60 (for example, the document has been generated by the replacement application 62), the migration manager 52 may designate the replacement platform 56 as the mistress. The migration manager 52 can also facilitate the report and comparison of envelopes by tagging and selecting specific envelopes for report generation and / or re-export.

By allowing the existing platform 54 and the replacement platform 56 to operate in parallel and to produce equivalent data that can be compared and / or merged if needed, the migration manager 52 can provide benefits that are not available with conventional system migration methods. A dual operation may also allow the migration manager 52 to store multiple images of the same coupon data to provide a complete audit trail of the existing platform against the replacement platform data.

In general, the subprograms executed to implement the embodiments of the invention, whether they are implemented as part of an operating system or a specific application, a component 'a program, object, module or sequence of instructions, or even a subset thereof, may be referred to herein as "computer code program" or simply "encoded program" ". An encoded program typically includes computer-readable instructions that reside at various times in various memory and storage devices in a computer and, when decrypted and executed by one or more processors in a computer, cause the computer to performing operations necessary to perform operations and / or elements specific to the implementation of various aspects of the embodiments of the invention. The instructions of a computer-readable program for carrying out the operations of the embodiments of the invention may be, for example, the assembly language, or either a source code or an object code written in combination with one or several programming languages.

Various coded programs described herein may be identified according to the application in which they are implemented in the specific embodiments of the invention. However, it will be noted that any nomenclature of a particular program that follows, is used solely for convenience; thus the invention can not be limited to a single use in any specific application identified and / or implied by said nomenclature. Moreover, in view of the generally infinite number of ways in which computer programs can be organized according to under programs, procedures, methods, modules, objects, and so on, as well as the various ways of affecting features a program among various layers of software that are resident in a typical computer (for example, operating systems, libraries, program application interfaces (APIs), applications, applets, etc.), it will be appreciated that the embodiments of the invention are not limited to the specific organization and assignment of program functionality described herein.

The coded program implemented in any application / module described herein may be distributed individually or collectively as a program product in a variety of forms. In particular, the encoded program may be distributed using a computer-readable storage medium having computer-readable program instructions per se allowing a processor to perform aspects of the embodiments of the invention.

Machine-readable storage media, which are intrinsically non-transient, may include volatile and non-volatile, removable and non-removable tangible media, implemented in any information storage method or technology, such as program instructions. machine-readable, data structures, program modules, or other data. Computer readable storage media may also include RAMs, ROMs, EPROMs (read-only, programmable and erasable memory), flash memory, or any solid storage media technology, CD-ROM (portable compact disc with a read-only memory), or any other optical storage, magnetic recording tapes, magnetic disk storage, or any other medium that can be used to store the desired information and capable of being deciphered by a computer. A computer-readable storage medium can not be interpreted as "transient signals" per se (for example, radio waves or any other electromagnetic wave propagating through a transmission medium such as a waveguide, or electrical signals transmitted by cable). The computer-readable program instructions may be downloaded to a computer, another type of programmable data-processing apparatus, or to any other machine-readable storage medium device, or to an external computer or to an external storage device by a network.

Computer-readable program program instructions, stored in a computer readable medium, other types of programmable data processing apparatus, or other devices for operating in a particular manner, such as Instructions stored on a computer-readable medium produce an article of manufacture comprising instructions that implement the functions, actions, and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams. The computer program instructions may be provided to one or more processors of a general purpose computer, to a dedicated computer, or to another programmable data processing apparatus for producing a machine, for example, instructions that, when performed using the one or more processors, perform a series of calculations to implement the functions, actions, and / or operations specified in the flow charts, block diagrams, and / or block diagrams.

In certain other embodiments, the functions, actions, and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams may be reordered, serially processed, and / or processed. same time in accordance with the embodiments of the invention. In addition, any flow chart, block diagram, and / or block diagram may include more or fewer blocks than those illustrated while remaining consistent with the embodiments of the invention.

Claims (7)

1. A method for migrating a data processing system from an existing platform to a replacement platform comprising: receiving incoming data by each of the existing platforms and by the replacement platform, the incoming data being relative to a first document in an existing database; updating, by the existing platform, of the first document in the existing database according to the incoming data; generating, by the replacement platform, a second document in a replacement database based on the incoming data; and capturing by the replacement platform, a first image of the second document in a first envelope in the replacement database. The method of claim 1 further comprising: migrating the first document from the existing database to the replacement database; and capturing, by the replacement platform, a second image of the first document in a second envelope in the replacement database. 3. The method of claim 2 further comprising: labeling at least the first envelope as the master envelope. 4. An organized data processing system for migrating from an existing platform to a replacement platform, the data processing system being configured to: receive incoming data by each of the platforms, the existing platform and the replacement platform, the incoming data relating to a first document in an existing database; update the first document in the existing database based on the incoming data; generating a second document in a replacement database based on the incoming data; and capturing a first image of the second document in a first envelope in the replacement database. The data processing system of claim 4 further being configured to: migrate the first document from a first database to the replacement database; and capturing a second image of the first document in a second envelope in the replacement database. The data processing system according to claim 4 or claim 5 being further configured to implement the method of claim 3. A computer program comprising program code instructions for performing the steps of the method according to claims 1 to 3 when said program is run on a computer.