System and method for legacy-based access to non-legacy data

Abstract

Abstract A method for legacy-based access to non-legacy data includes: receiving, at an intermediation server, a non-legacy data object containing non-legacy content; generating a legacy data ob ject containing the non-legacy content, for storage in a repository; storing, in association with the legacy data object, a non-legacy distribution channel indicator; adjusting a legacy pro cessing mechanism at the repository according to the non-legacy distribution channel indica tor; receiving from a client subsystem, via a legacy interface, a request for the non-legacy content; and in response to the request, retrieving and sending the legacy data object contain ing the non-legacy content, via the legacy interface. 2020277254 27 Nov 2020 4 / 6 20 20 27 72 54 2 7 N ov 2 02 0 116 2020277254 27 Nov 2020 400 112 124 Intermediation Server 212 404 400 Record ID: ZYXWVU 408 Name: Alice Smith Segment 1: LH 001 412 400 128 FIG. 4

Description

System And Method For Legacy-Based Access To Non- Legacy Data Field

[0001] The specification relates generally to computing systems, and specifically to a sys- tem and method for enabling legacy-based access to non-legacy data in such systems. Background

[0002] Computing systems may store and process data generated via a plurality of channels, e.g. employing distinct (and not necessarily compatible) communication protocols, messaging sequences, and the like. Such systems can include numerous distinct sub- systems, some of which may be able to manipulate data (e.g. initiate processing oper- ations, retrieve data for display and the like) only according to a subset of the above channels. Data generated via other channels may remain inaccessible to such subsys- tems. Summary

[0003] An aspect of the specification provides a method for legacy-based access to non-leg- acy data, the method comprising: receiving, at an intermediation server, a non-legacy data object containing non-legacy content; generating a legacy data object containing the non-legacy content, for storage in a repository; storing, in association with the legacy data object, a non-legacy distribution channel indicator; adjusting a legacy processing mechanism at the repository according to the non-legacy distribution channel indicator; receiving from a client subsystem, via a legacy interface, a request for the non-legacy content; and in response to the request, retrieving and sending the legacy data object containing the non-legacy content, via the legacy interface.

[0004] Storing the non-legacy distribution channel indicator can include storing the non-leg- acy distribution channel indicator in a field of the legacy data object.

[0005] Adjusting the legacy processing mechanism can include: determining whether the legacy data object is associated with the non-legacy distribution channel indicator; when the determination is affirmative, selecting an alternative processing mechanism distinct from the legacy processing mechanism,

[0006] Adjusting the legacy processing mechanism can include: determining whether the legacy data object is associated with the non-legacy distribution channel indicator; when the determination is affirmative, suppressing the legacy processing mechanism.

[0007] The method can further comprise: when the determination is negative, initiating the legacy processing mechanism,

[0008] The legacy processing mechanism can be a publication mechanism configured to transmit at least a portion of a legacy data object to a further subsystem.

[0009] Sending the legacy data object can include sending the non-legacy distribution chan- nel indicator. Sending the legacy data object can include omitting the non-legacy distribution chan- nel indicator. Adjusting the legacy processing mechanism according to the non-legacy distribution channel indicator can include applying a non-legacy access restriction to the legacy database. Another aspect of the specification provides an intermediation server for legacy- based access to non-legacy data, the intermediation server comprising: a memory storing a repository; a communications interface; and a processor connected with the communications interface and the memory, the processor configured to: receive, via the communications interface, a non-legacy data object containing non-legacy con- tent; generate a legacy data object containing the non-legacy content; store, in associ- ation with the legacy data object, a non-legacy distribution channel indicator; adjust a legacy processing mechanism at the repository according to the non-legacy distribu- tion channel indicator; receive from a client subsystem, via a legacy interface, a re- quest for the non-legacy content; and in response to the request, retrieve and send the legacy data object containing the non-legacy content, via the legacy interface. The processor can be configured, in order to store the non-legacy distribution chan- nel indicator, to store the non-legacy distribution channel indicator in a field of the legacy data object in the repository. The processor can be configured, in order to adjust the legacy processing mecha- nism, to: determine whether the legacy data object is associated with the non-legacy distribution channel indicator; when the determination is affirmative, select an alter- native processing mechanism distinct from the legacy processing mechanism. The processor can be configured, in order to adjust the legacy processing mecha- nism, to: determine whether the legacy data object is associated with the non-legacy distribution channel indicator; when the determination is affirmative, suppress the legacy processing mechanism. The processor can be further configured to: when the determination is negative, initi- ate the legacy processing mechanism, The legacy processing mechanism can be a publication mechanism configured to transmit at least a portion of a legacy data object to a further subsystem. The processor can be configured to send the non-legacy distribution channel indica- tor with the legacy data object. The processor can be configured to omit the non-legacy distribution channel indica- tor when sending the legacy data object. The processor can be configured, in order to adjust the legacy processing mechanism according to the non-legacy distribution channel indicator, to apply a non-legacy ac- cess restriction to the legacy database.

[0021] A further aspect of the specification provides a computer program product compris- ing program code instructions stored on a computer readable medium comprising: computer readable program means for receiving, via a communications interface, a non-legacy data object containing non-legacy content; computer readable program means for generating a legacy data object containing the non-legacy content; com- puter readable program means for storing, in association with the legacy data object, a non-legacy distribution channel indicator; computer readable program means for adjusting a legacy processing mechanism at the repository according to the non-leg- acy distribution channel indicator; computer readable program means for receiving from a client subsystem, via a legacy interface, a request for the non-legacy content; and computer readable program means for, in response to the request, retrieving and sending the legacy data object containing the non-legacy content, via the legacy in- terface, when said program runs on an intermediation server. Brief Descriptions of the Drawings

[0022] Embodiments are described with reference to the following figures, in which:

[0023] FIG. 1 is a diagram illustrating a system for enabling legacy-based access to non-leg- acy data;

[0024] FIG. 2 is a diagram illustrating certain internal components of the intermediation server of FIG. 1;

[0025] FIG. 3 is a flowchart of a method for enabling legacy-based access to non-legacy data;

[0026] FIG. 4 is a diagram illustrating a performance of blocks 305, 310 and 315 of the method of FIG. 3;

[0027] FIG. 5 is a diagram illustrating a performance of blocks 305, 310, 320 and 315 of the method of FIG. 3; and

[0028] FIG. 6 illustrates an example performance of blocks 345, 325, 330, 335 and 350 of the method of FIG. 3. Detailed Description

[0029] FIG. 1 depicts a system 100 for integrating enabling legacy-based access to non-leg- acy data. Within the system 100, various computing subsystems interact to generate and process data relating to any of a wide variety of activities. In the examples dis- cussed below, the subsystems of the system 100 interact to generate and process data relating to the delivery of items to customers. The items, in the examples, below, are travel-related products and services, such as flight tickets, hotel reservations, vehicle rental reservations, and the like. A wide variety of other activities can be enabled by the exchange of data between the subsystems shown of the system 100, and the spe- cific nature of the data processed within the system 100 is not particularly limited.

[0030] In the illustrated example, the system 100 includes at least one client subsystem 104, of which two examples 104-1 and 104-2 are shown in FIG. 1 (referred to collectively as the client subsystems 104 and generically as a client subsystem 104). Each client subsystem 104 is operated by a client entity that may also be referred to as a seller. The seller can be, for example, a travel agency. The client subsystems 104 generate requests, e.g. on behalf of customers, for travel items. The requests specify various attributes of the travel items, such as origin and destination locations, times and dates of travel, and the like. Responses to requests from the client subsystems 104 are gen- erated by, or on behalf of, entities that provide the items, referred to herein as provid- ers. Therefore, in the present example the providers are entities such as airlines, hotel operators or the like that deliver the items to the customer, or to other such entities for eventual delivery to the customer, following purchase of the items (such purchase being effected, for example, via a client subsystem 104). Each provider entity operates a provider subsystem 108; two example provider sub- systems 108-1 and 108-2 are shown in FIG. 1. Each of the client subsystems 104 and the provider subsystems 108 are implemented as at least one computing device with input and output assemblies and communications devices for exchanging data via a network 112. The network 112 can include any suitable combination of local-area and wide-area networks, including the Internet. Although two client subsystems 104 and two provider subsystems 108 are shown in FIG. 1, the system 100 can include a greater or smaller number of client subsystems 104 and provider subsystems 108 in other examples. The generation of responses to requests from the client subsystems 104 can take vari- ous forms. In the illustrated example, the provider subsystem 108-1 is assumed to generate responses to such requests locally, although as will be seen below, the re- quests are not transmitted directly from the client subsystem 104 to the provider sub- system 108-1. That is, the provider subsystem 108-1 includes an offer generation module (e.g. computer readable instructions and corresponding execution hardware, along with various stored data for use in generating responses) that enables the pro- vider subsystem 108-1 to generate response data based on the attributes specified in the request originated by a client subsystem 104. The response data may also be re- ferred to as “offer data”, and defines one or more items that match or partially match the requested attributes. Other provider subsystems 108, such as the provider subsystem 108-2 in the present example, may not generate responses to requests from the client subsystem 104. In- stead, such responses may be generated by a distribution subsystem 116. The pro- vider subsystem 108-2 may, for example, publish data defining the items offered by the provider entity that operates the provider subsystem 108-2 to a publication sub- system 120. The publication subsystem 120 may be operated by a third party (i.e. distinct from the above-mentioned provider entities), and may receive published item data such as flight schedules, fares and the like, from one or more provider subsys- tems 108. The distribution subsystem 116, in turn, may retrieve data from the publi- cation system 120 for use in generating responses to requests from the client subsys- tems 104 on behalf of the provider subsystem 108-2, The distinct response generation mechanisms mentioned above may be implemented using different sets of communication protocols, data exchange standards, and the like. The collection of communication protocols, standardized data formats and the like that define how response data is generated for a client request may be referred to as the distribution channel according to which that request is handled. As will be apparent to those skilled in the art, in the context of travel items, an exam- ple distribution channel is New Distribution Capability (NDC). The NDC standard defines an eXtensible Markup Language (XML) based data format, as well as mes- sage syntax, API calls and the like, for messages exchanged between client subsys- tems 104 and provider subsystems 108. In the present example, the provider subsys- tem 108-1, which generates response data locally, is assumed to employ the NDC channel. The NDC channel is also referred to herein as a non-legacy distribution channel, and content (i.e. data defining items) obtained via the NDC channel is re- ferred to as non-legacy content. That is, the non-legacy content is obtained via NDC messaging. Another example distribution channel in the context of travel items is a Global Dis- tribution System (GDS) channel. Components of the system 100 that implement the GDS channel, such as the distribution subsystem 116 and the provider subsystem 108-2 in the illustrated example, employ message syntax, sequencing and the like that is distinct from that used under NDC. For example, the GDS channel may em- ploy message syntax, sequence and the like as specified by the Electronic Data Inter- change For Administration, Commerce and Transport (EDIFACT) standard. The GDS channel is also referred to herein as a legacy distribution channel, and content (i.e. data defining items) obtained via the GDS channel is referred to as legacy con- tent. That is, the legacy content is obtained via GDS messaging. In other words, response data (i.e. the above-mentioned content) can be generated within the system 100 using two or more distinct generation mechanisms, or distribu- tion channels. Certain client subsystems 104 may be configured to obtain response data only via one channel (and not the other). Further, the client subsystems 104 may include internal components that are only compatible with one distribution channel. For example, the client subsystem 104-1 may be configured to obtain response data via either channel, but includes an accounting engine 122 that is only compatible with data obtained via the GDS channel (i.e. with legacy content). A wide variety of such internal components may be included in each client subsystem 104, and at least some of those internal components may have been deployed with legacy content compatibility only. Client subsystems 104 may be configured to obtain both legacy and non-legacy con- tent, such as a first flight for a given customer obtained via the GDS channel and a second flight for that customer obtained via the NDC channel. To enable client sub- systems 104 to view and manipulate both legacy and non-legacy content together, some systems implement a shared data storage and handling mechanism, with a shared set of formatting standards, API calls, and the like. However, such systems do not address the limited compatibility of components such as the engine 122: the shared storage and handling mechanisms differ from legacy mechanisms, and the en- gine 122 is therefore unable to use such shared mechanisms without potentially costly modifications. The system 100 is therefore configured to enable components such as the engine 122 to access non-legacy data (as well as legacy data) using legacy access mechanisms. The functionality discussed herein enables the engine 122 and other legacy-compati- ble components to continue functioning with fewer or no technical modifications to implement non-legacy compatibility. To that end, the system 100 includes an intermediation server 124 (also referred to herein simply as the server 124) connected with the network 112. Requests generated by the client subsystems 104 are transmitted via the network 112 to the intermedia- tion server 124. The intermediation server 124 receives requests from the client sub- systems 104, and passes such requests to the provider subsystems 108 and / or the dis- tribution subsystem 116. The intermediation server 124 also receives responses from the provider subsystems 108 and / or distribution subsystem 116, for return to the cli- ent subsystem 104. The responses mentioned above (i.e. the content) are stored in a repository 128 at the server 124. In particular, as will be discussed in greater detail below, content ob- tained via either distribution channel is stored in the repository 128 in legacy data ob- jects. The storage of content obtained via both legacy and non-legacy distribution channels in legacy data objects enables components such as the engine 122 to re- trieve and process non-legacy data with little or no modifications. In addition, the server 124 is configured to apply various forms of legacy processing mechanisms to data in the repository 128. However, as noted above the repository 128 can also contain non-legacy content for which the legacy processing mechanisms may not be suitable. Although non-legacy content is stored in the repository 128 in legacy data objects, interactions with external entities such as the provider subsystem 108-1 to update the non-legacy content is still performed according to the non-legacy (e.g. NDC) distribution channel. The server 124 is therefore also configured to track which content in the repository 128 is non-legacy content (i.e. originated through the non-legacy distribution channel), The server 124 can also, based on such tracking, adjust legacy processing mechanisms for non-legacy content, Before further discussion of the functionality of the various components of the sys- tem 100, certain internal components of the intermediation server 124 will be de- scribed in connection with FIG. 2. Turning to FIG. 2, the intermediation server 124 includes at least one processor 200, such as a central processing unit (CPU) or the like. The processor 200 is intercon- nected with a memory 204, implemented as a suitable non-transitory computer-read- able medium (e.g. a suitable combination of non-volatile and volatile memory sub- systems including any one or more of Random Access Memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, magnetic computer storage, and the like). The processor 200 and the memory 204 are generally comprised of one or more integrated circuits (ICs). The processor 200 is also interconnected with a communication interface 208, which enables the server 124 to communicate with the other computing devices of the sys- tem 100 via the network 112. The communication interface 208 therefore includes any necessary components (e.g. network interface controllers (NICs), radio units, and the like) to communicate via the network 112. The specific components of the com- munication interface 208 are selected based on the nature of the network 112. The server 124 can also include input and output devices connected to the processor 200, such as keyboards, mice, displays, and the like (not shown). The components of the server 124 mentioned above can be deployed in a single en- closure, or in a distributed format. In some examples, therefore, the server 124 in- cludes a plurality of processors, either sharing the memory 204 and communication interface 208, or each having distinct associated memories and communication inter- faces. The memory 204 stores the repository 128, as well as computer-readable instructions executable by the processor 200 to implement various functionality. The computer- readable instructions may also be referred to as applications, and in the illustrated ex- ample the memory 204 stores a content handling application 212 (also referred to herein simply as the application 212). In the description below, the processor 200, and more generally the server 124, are said to perform, or to be configured to per- form, those actions. It will be understood that they are so configured via the execu- tion (by the processor 200) of the instructions of the applications stored in memory 204, including the application 212. Execution of the application 212 by the processor 200 configures the server 124 to obtain data via either of the above-mentioned distribution channels, and to store the data in the repository 128, Execution of the application 212 also configures the server 124 to adjust legacy processing mechanisms performed on records in the re- pository 128, based on the distribution channel by which the records were obtained. An example of a processing mechanism is the handling of a record in the repository 128 in response to a request for the record from a client subsystem 104. Certain other example processing mechanisms will also be discussed below. Turning now to FIG. 3, certain aspects of the operation of the system 100 will be de- scribed in greater detail. Specifically, FIG. 3 illustrates a method 300 of providing access to non-legacy data using legacy-based access mechanisms. The performance of the method 300 will be discussed in conjunction with its performance within the system 100, and specifically by the intermediation server 124 via execution of the in- tegration application 212. At block 305, the server 124 receives content for storage in the repository 128. The receipt of content can be preceded by a variety of other actions that are outside the scope of the present discussion. In brief, the server 124 can receive a request for con- tent (e.g. a request for data defining purchasable travel items) from a client subsys- tem 104. The server 124 can then relay the request to the relevant entity in the system 100, such as the provider subsystem 108-1 and the distribution subsystem 116. The server 124 can then receive at least one response from the entity or entities to which the request was relayed, for processing at block 305. At block 310 the server 124 determines whether the content received at block 305 is non-legacy content. That is, the server 124 determines whether the content from block 305 was obtained according to the legacy distribution channel (e.g. by interact- ing with the distribution subsystem 116) or according to the non-legacy distribution channel (e.g. by interacting with the provider subsystem 108-1). The determination at block 310 can be based on the entity or entities from which the server 124 received the content, the message syntax, API calls or the like used to receive the content, and the like. For example, the server 124 can store configuration settings indicating the content type for each provider subsystem 108. When the determination at block 310 is negative, indicating that the content received at block 305 is legacy content (e.g. obtained via the GDS distribution channel in the present example), the server 124 proceeds to block 315. At block 315 the content re- ceived at block 305 is stored in the repository 128. In the case of legacy content, stor- age at block 315 need not involve any modification of the content, because the rec- ords of the repository 128 are formatted according to the legacy distribution channel. Turning to FIG. 4, an example performance of blocks 305, 310 and 315 is shown. In particular, the distribution subsystem 116 is shown transmitting content in the form of a legacy data object 400 to the server 124 via the network 112. The legacy data object 400 can be, for example, a record containing data acquired through the EDIFACT process, as noted earlier. At block 310, the determination is negative, and thus at block 315 the server 124 stores the legacy data object 400 in the repository 128. The contents of the data object 400 are shown within the dashed box indicating pro- cessing via execution of the application 212. In the illustrated example, the data ob- ject 400 includes a record identifier field 404, a name field 408, and an item defini- tion field 412. A wide variety of additional fields can be included in the data object 400. As will be apparent to those skilled in the art, the data object 400 is a simplified example of a Passenger Name Record (PNR) as employed in GDS-based distribution channels. In addition, the data object 400 can be stored in the repository 128 in the form in which the data object 400 was received from the distribution subsystem 116. Referring again to FIG. 3, following the performance of block 315 the server 124 can return to block 305 to receive additional content, as indicated by the dashed line from block 315 to block 305. More generally, the performance of blocks 305-315 (and of block 320, discussed below) can be repeated both before the remainder of the method 300 is performed, and during the performance of the remainder of the method 300. That is, blocks 305-320 indicate how the server 124 receives and processes content for storage in the repository 128, while the remaining blocks of the method 300 indi- cate how content already stored in the repository 128 may be processed. Receipt of content for storage and processing of stored content can be decoupled from one an- other. When the determination at block 310 is affirmative, indicating that the content re- ceived at block 305 is non-legacy content (e.g. obtained via the NDC channel in the present example), the server 124 proceeds to block 320 before block 315. At block 320, the server 124 generates a legacy data object that contains the content received at block 305. In other words, block 320 involves a translation of non-legacy content into a legacy format for storage in the repository 128. The server 124 also, at block 320, generates a distribution channel indicator associated with the legacy data object containing non-legacy content. Turning to FIG. 5, an example performance of blocks 305, 310, 320 and 315 is illus- trated. The example actions shown in FIG. 5 are assumed to take place after the per- formance of blocks 305-315 discussed above in connection with FIG. 4, and the data object 400 is therefore shown in the repository 128, In the example illustrated in FIG. 5, at block 305 the server 124 receives a non-leg- acy data object 500 from the provider subsystem 116-1. The data object 500 can in- clude data acquired via a message formatted according to the NDC standard, such as an NDC Order message containing data defining one or more items booked on behalf of a customer. As shown in FIG. 5, the data object 500 includes a record identifier field 504, a passenger name field 508, and at least one item field. In the present ex- ample, two item fields 512 and 516 are shown, each containing data defining a flight. The non-legacy data object 500 can also include various other fields, defining vari- ous other products or services and related information. For example, the data object 500 can be an NDC Orderltem object including data such as an OrderItem identifier and the like, which may not have direct analogues in legacy data objects. Following an affirmative determination at block 310, the server 124 proceeds to block 320 to generate a legacy data object 518 from the non-legacy content in the data record 500. In particular, the application 212 can include mapping rules or the like that specify fields of a legacy data object that correspond to fields of a non-leg- acy data object. An example mapping is illustrated in FIG. 5 by dashed lines between the fields 504-516 of the data object 500 and corresponding fields of the legacy data object 518. In particular, the record identifier field 504 corresponds to a record iden- tifier field 520. Similarly, the passenger name field corresponds to a name field 524. The item fields 512 and 516 are combined into a single segment field 528 (which may also be referred to as an air segment for GDS content). That is, the server 124 can be configured to retrieve data from any item fields 512, 516, etc. in the non-leg- acy data object 500, and insert that data into subfields or any other suitable data structure in a single segment field 528. In other examples, the translation of a non- legacy data object to a legacy data object need not include the merging of fields as illustrated in FIG. 5. Instead, in other examples one or more fields of the non-legacy data record 500 may be split into multiple corresponding fields in the legacy data record 518. As will now be apparent, the fields 520-528 are structurally aligned with the fields 404-412 shown in FIG. 4. That is, with an exception noted below, the content of the non-legacy data object 500 is translated, via block 320, into a format suitable for storage as a legacy data object. The above-mentioned exception includes the genera- tion and storage of a distribution channel indicator corresponding to the legacy data object 518. In some implementations, additional exceptions include storage of links between fields of the data objects 500 and 518 generated during the translation pro- cess. Such links can be stored in the legacy data object 518 itself, or in a separate re- pository. The distribution channel indicator, which in the illustrated example is the string “NDC”, indicates that the content in the legacy data object 518 was obtained via a non-legacy mechanism such as the NDC distribution channel. The indicator can be stored in a distribution channel indicator field 532 of the data object 518. Of note, the legacy data object 400 does not include such an indicator. More gener- ally, data objects containing legacy content need not be associated with such an indi- cator, although in other embodiments, all data objects in the repository 128 can in- clude distribution channel indicators (e.g. “NDC” for non-legacy content and “GDS” for legacy content), In other examples, the distribution channel indicator can be stored independently of the data object 518, such as in a distinct index identifying which records in the repos- itory 128 are associated with a non-legacy distribution channel. Following generation of the legacy data object 518 and the distribution channel indi- cator, the legacy data object 518 is stored in the repository 128 at block 315. Return- ing to FIG. 3, the server is then configured, at block 325, to determine whether to ini- tiate any of a variety of processing mechanisms with respect to one or more of the data objects stored in the repository 128. The determination at block 325 can be based on various factors, and numerous exam- ples of processing mechanisms may be initiated in response to such determinations. Examples of processing mechanisms include a data feed, which may also be referred to as a publication mechanism. For example, following the creation of a data object in the repository 128, or the application of an update to a data object in the repository 128, the server 124 can be configured to initiate a publication mechanism to inform other entities in the system 100 (e.g. one or more of the provider subsystems 108) of the changes made to the data record. Such a publication mechanism may also be ini- tiated periodically, and the determination at block 325 can therefore include a deter- mination of whether a predetermined period of time since a previous publication has elapsed. Another example of a processing mechanism is retrieving a data object from the re- pository 128 and providing the data object to another component of the system 100 (e.g. a client subsystem 104) in response to a request from that component. This ex- ample in particular will be discussed in greater detail further below. Other examples of processing mechanisms that can be initiated at block 325 include processing requests to modify or delete data objects in the repository 128, indexing processes performed on the repository 128, and the like. At block 325, therefore, the server 124 can assess any of a variety of conditions to determine whether to initiate at least one processing mechanism. If the determination at block 325 is negative, the server 124 returns to block 305 to await further content. The server 124 can also repeat the performance of block 325. As noted above, the performance of blocks 305-320 and that of blocks 325 onwards need not be coupled. That is, the conditions that lead to an affirmative determination at block 325 need not be associated directly with the most recently received data object. When the determination at block 325 is affirmative for a given data object, the server 124 proceeds to block 330. At block 330 the server 124 determines whether the data object is associated with a non-legacy distribution channel indicator. In the present example, the server 124 determines at block 330 whether the data object includes a distribution channel indicator field 532, as illustrated in FIG. 5. In other words, at block 330 the server 124 determines whether the data object for which a processing mechanism was initiated at block 325 contains legacy content or non-legacy content. When the determination at block 330 is affirmative, indicating that the data object (although a legacy data object structurally, as discussed in connection with block 320) contains non-legacy data, the server proceeds to block 332. At block 332, the server 124 determines whether an adjustment is needed to at least one legacy pro- cessing mechanism triggered at block 325. The server 124 can store indicators of leg- acy processing mechanisms that may be applied without adjustment to data objects, regardless of the type of content stored therein. If the processing mechanism trig- gered at block 325 does not appear in the above indicators, the determination at block 332 is affirmative, and the server 124 proceeds to block 335. At block 335 the server 124 adjusts the processing mechanism initiated at block 325 according to the distribution channel indicator. That is, the server 124 selects an ad- justed processing mechanism, which may differ (but is not required to differ) from the processing mechanism initiated at block 325. When the determination at block 332 is negative, indicating that no adjustment is necessary, the server 124 instead proceeds to block 340, discussed below. Some processing mechanisms, such as the above-mentioned publication or feed mechanism, may not be appropriate for non-legacy content, but are nevertheless trig- gered at block 325 in response to an update to the repository 128, because such pro- cesses may be automatically triggered in response to any update to legacy data ob- jects. Adjustment can therefore include suppression of the processing mechanism ini- tiated at block 325, such that the adjusted mechanism selected at block 335 is simply a null process (i.e. an absence of further processing). In other cases, the selected ad- justed processing mechanism may be analogous to the processing mechanism initi- ated at block 325, but may differ in at least one particularity. Adjustments to processing mechanisms may be reflected in adjustment configuration data stored at the server 124, e.g. in the instructions of the application 212. For exam- ple, the adjustment configuration data can map legacy processing mechanisms to ad- justed processing mechanisms. Table 1 illustrates example adjustment configuration data. As seen in Table 1, a provider feed processing function (i.e. the above-mentioned publication function) is mapped to no non-legacy function, Therefore, when the pro- vider feed legacy processing mechanism is initiated at block 325, at block 335 the se- lected adjustment to that processing mechanism is to suppress the legacy processing mechanism, and performance of the method 300 simply terminates. Table 1 also illustrates a view security processing function, employed to determine whether to grant a request (e.g. by a client subsystem 104 or component thereof) to retrieve a data object from the repository 128 for display. The example adjustment configuration data of Table 1 indicates that at block 335 the same processing function is employed (i.e. no adjustment is made, and the determination at block 332 for the “View Security” mechanism would be negative). In other examples, however, as in the third row of Table 1, different security policies may be applied, e.g. in the case of a request to modify a data record. For example, modifying a price of an item in leg- acy content may be permitted, but such a modification may not be permitted for non- legacy content. When the determination at block 330 is negative, indicating that the data object for which a processing mechanism was initiated at block 325 contains legacy content, the server 124 proceeds to block 340, and continues with the application of the leg- acy processing mechanism. Thus, for example, in the case of the publication function mentioned above, at block 340 the server 124 simply proceeds with the publication function for legacy content (whereas for non-legacy content the publication function is suppressed at block 335). As noted earlier, request handling is a specific case of a processing mechanism initi- ated at block 325. For example, the affirmative determination at block 325 can result from the receipt of a request for content at block 345. The request received at block 345 may include a record identifier, and initiates the performance of at least one pro- cessing mechanism, such as a view security mechanism to determine whether to grant access to the data object. At block 330 the server 124 determines whether the requested data object contains legacy or non-legacy data, and proceeds to block 335 or 340 according to the distribution channel indicator. A response is generated and transmitted to the request at block 350 based on the selected processing mechanism (whether adjusted at block 3335, or unadjusted at block 340). Turning to FIG. 6, an example performance of blocks 345, 325, 330, 335 and 350 is illustrated. In particular, the engine 122 of the client subsystem 104 sends a request 600 to the server 124 for the data object “ABCDEF” (i.e. the data object 518 shown in FIG. 5). Of particular note, the request is received at the server 124 via a legacy interface. As mentioned earlier, the engine 122 may be configured only to implement the GDS standard, rather than the NDC standard. Therefore, the request 600 (and in- deed, any requests for data objects generated by the engine 122) employs message syntax, sequencing and the like that is defined by the GDS distribution channel. Having received the request 600 at block 345, the server 124 initiates a view security process (i.e. an affirmative determination at block 325) and proceeds to block 330. At block 330, the determination is affirmative, because the data object 518 includes the distribution channel indicator field 532, indicating that the data object 518 contains non-legacy content with which the engine 122 is not compatible (in the absence of the functionality discussed herein). The server 124 therefore proceeds to block 335 and selects an adjusted processing mechanism according to the adjustment configura- tion data. In the present example, Table 1 indicates that no adjustment is required for retrieval and display of a data object. In other embodiments, however, Table 1 may indicate that a different set of security policies are to be applied for viewing of non- legacy content. At block 350, the data object 518 is returned, via the legacy interface (i.e. employing GDS syntax and message sequencing in this example), to the engine 122. In some examples, the distribution channel indicator field 532 can be omitted, and the re- sponse therefore contains a modified version 518’ of the data object 518. In other ex- amples, however, the entire data object 518 is transmitted at block 350. The adjust- ment configuration data itself can include configuration parameters indicating, for example, whether the field 532 is to be included when returning the data object 518 to the engine 122. Those skilled in the art will appreciate that in some embodiments, the functionality of the application 212 may be implemented using pre-programmed hardware or firm- ware elements (e.g., application specific integrated circuits (ASICs), electrically eras- able programmable read-only memories (EEPROMs), etc.), or other related compo- nents. It is to be understood that, if any prior art publication is referred to herein, such refe- rence does not constitute an admission that the publication forms a part of the com- mon general knowledge in the art, in Australia or any other country. In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implica- tion, the word “comprise” or variations such as “comprises” or “comprising” is used in an inclusive sense, i.e. to specify the presence of the stated features but not to pre- clude the presence or addition of further features in various embodiments of the in- vention.

Claims

1. A method for legacy-based access to non-legacy data, the method comprising:storing, in a repository, a plurality of legacy data objects each containing legacy content;receiving, at an intermediation server, a further data object for storage in the repository;determining, at the intermediation server, that the further data object is a non-legacy data object containing non-legacy content;in response to the determining:(i) generating a further legacy data object containing the non-legacy content,(ii) storing the further legacy data object in the repository with the plurality of legacy data objects, and(iii) storing, in association with the further legacy data object, a non-legacy distribution channel indicator;(iv) in response to storing the further legacy data object and the non-legacy distribution channel indicator, suppressing a legacy processing mechanism according to adjustment configuration data stored at the intermediation server;receiving from a client subsystem, via a legacy interface, a request for the non-legacy content; andin response to the request:(i) selecting a processing mechanism corresponding to the request,(ii) selecting, based on the adjustment configuration data, an adjustment to the processing mechanism, and(iii) according to the adjustment, retrieving and sending the further legacy data object containing the non-legacy content, via the legacy interface.

2. The method of claim 1, wherein storing the non-legacy distribution channel indicator includes storing the non-legacy distribution channel indicator in a field of the further legacy data object.

3. The method of claim 1 or claim 2, wherein selecting the adjustment includes:determining whether the legacy data object is associated with the non-legacy distribution channel indicator;2020277254   15 Jul 2026when the determination is affirmative, selecting an alternative processing mechanism distinct from the legacy processing mechanism.

4. The method of claim 3, further comprising: when the determination is negative, initiating the legacy processing mechanism.

5. The method of any one of the preceding claims, wherein the non-legacy content is obtained via New Distribution Capability (NDC) messaging, and wherein the legacy data object is obtained via Global Distribution System (GDS) messaging.

6. The method of claim 4, wherein the legacy processing mechanism is a publication mechanism configured to transmit at least a portion of a legacy data object to a further subsystem.

7. The method of any one of claims 1 to 6, wherein sending the further legacy data object includes sending the non-legacy distribution channel indicator.

8. The method of any one of claims 1 to 6, wherein sending the legacy data object includes omitting the non-legacy distribution channel indicator.

9. The method of any one of claims 1 to 8, wherein the adjustment to the legacy processing mechanism includes applying a non-legacy access restriction to a legacy database.

10. An intermediation server, comprising:a memory storing a repository containing a plurality of legacy data objects each containing legacy content;a communications interface; anda processor connected with the communications interface and the memory, the processor configured to:receive, via the communications interface, a further data object for storage in the repository;2020277254   15 Jul 2026determine, at the intermediation server, that the further data object is a non-legacy data object containing non-legacy content;in response to the determination:(i) generate a further legacy data object containing the non-legacy content;(ii) store the further legacy data object in the repository with the plurality of legacy data objects, and(iii). store, in association with the further legacy data object, a non-legacy distribution channel indicator;(iv) in response to storing the further legacy object and distribution channel indicator, suppress a legacy processing mechanism according to adjustment configuration data stored in the memory:receive from a client subsystem, via a legacy interface, a request for the non-legacy content; andin response to the request:(i) select a processing mechanism corresponding to the request,(ii) select, based on adjustment configuration data, an adjustment to the processing mechanism, and(iii) according to the adjustment, retrieve and send the further legacy data object containing the non-legacy content, via the legacy interface.

11. The intermediation server of claim 10, wherein the processor is configured, in order to store the non-legacy distribution channel indicator, to store the non-legacy distribution channel indicator in a field of the further legacy data object in the repository.

12. The intermediation server of claim 10 or claim 11, wherein the processor is configured, in order to select the adjustment, to:determine whether the legacy data object is associated with the non-legacy distribution channel indicator;when the determination is affirmative, select an alternative processing mechanism distinct from the legacy processing mechanism.

13. The intermediation server of claim 12, wherein the processor is further configured to: when the determination is negative, initiate the legacy processing mechanism.2020277254   15 Jul 202614. The intermediation server of claim 10, wherein the non-legacy content is obtained via New Distribution Capability (NDC) messaging, and wherein the legacy data object is obtained via Global Distribution System (GDS) messaging.

15. The intermediation server of claim 13, wherein the legacy processing mechanism is a publication mechanism configured to transmit at least a portion of a legacy data object to a further subsystem.

16. The intermediation server of any one of claims 10 to 15, wherein the processor is configured to send the non-legacy distribution channel indicator with the further legacy data object.

17. The intermediation server of any one of claims 10 to 15, wherein the processor is configured to omit the non-legacy distribution channel indicator when sending the further legacy data object.

18. The intermediation server of any one of claims 10 to 17, wherein the processor is configured, in order to adjust the legacy processing mechanism, to apply a non-legacy access restriction to a legacy database.

19. A computer program product comprising program code instructions stored on a computer readable medium executable by a processor of an intermediation server to:store, in a repository, a plurality of legacy data objects each containing legacy content;receive, via a communications interface, a further data object for storage in the repository;determine, at the intermediation server, that the further data object is a non-legacy data object containing non-legacy content;in response to the determination:(i) generate a further legacy data object containing the non-legacy content,(ii) storing the further legacy data object in the repository with the plurality of legacy data objects, and(iii) store, in association with the further legacy data object, a non-legacy distribution channel indicator;2020277254   15 Jul 2026(iv) in response to storing the further legacy data object and the non-legacy distribution channel indicator, suppress a legacy processing mechanism according to adjustment configuration data stored at the intermediation server;receive from a client subsystem, via a legacy interface, a request for the non-legacy content; andin response to the request:(i) select a processing mechanism corresponding to the request,(ii) select, based on the adjustment configuration data, an adjustment to the processing mechanism, and(iii) according to the adjustment, retrieve and send the further legacy data object containing the non-legacy content, via the legacy interface.

Images