FR3021789A1 - - Google Patents
Download PDFInfo
- Publication number
- FR3021789A1 FR3021789A1 FR1554341A FR1554341A FR3021789A1 FR 3021789 A1 FR3021789 A1 FR 3021789A1 FR 1554341 A FR1554341 A FR 1554341A FR 1554341 A FR1554341 A FR 1554341A FR 3021789 A1 FR3021789 A1 FR 3021789A1
- Authority
- FR
- France
- Prior art keywords
- data
- standard
- data structure
- record
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 67
- 230000004044 response Effects 0.000 claims description 25
- 238000010926 purge Methods 0.000 claims description 9
- 238000007726 management method Methods 0.000 description 164
- 230000008569 process Effects 0.000 description 23
- 239000003795 chemical substances by application Substances 0.000 description 16
- 230000007246 mechanism Effects 0.000 description 16
- 238000010200 validation analysis Methods 0.000 description 14
- 238000013459 approach Methods 0.000 description 13
- 238000004891 communication Methods 0.000 description 13
- 238000013507 mapping Methods 0.000 description 13
- 230000009466 transformation Effects 0.000 description 12
- 238000006243 chemical reaction Methods 0.000 description 10
- 101100228853 Saccharolobus solfataricus (strain ATCC 35092 / DSM 1617 / JCM 11322 / P2) gds gene Proteins 0.000 description 9
- 238000004590 computer program Methods 0.000 description 9
- 230000004048 modification Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 9
- 230000008707 rearrangement Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000003068 static effect Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 239000012530 fluid Substances 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 102100029235 Histone-lysine N-methyltransferase NSD3 Human genes 0.000 description 4
- 101000634046 Homo sapiens Histone-lysine N-methyltransferase NSD3 Proteins 0.000 description 4
- 230000009471 action Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000013499 data model Methods 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 230000001427 coherent effect Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 235000012054 meals Nutrition 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013439 planning Methods 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 229960005486 vaccine Drugs 0.000 description 2
- 102100029239 Histone-lysine N-methyltransferase, H3 lysine-36 specific Human genes 0.000 description 1
- 101000634050 Homo sapiens Histone-lysine N-methyltransferase, H3 lysine-36 specific Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000004313 glare Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000002367 polarised neutron reflectometry Methods 0.000 description 1
- 229920000636 poly(norbornene) polymer Polymers 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000029305 taxis Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/14—Travel agencies
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Tourism & Hospitality (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Human Resources & Organizations (AREA)
- Physics & Mathematics (AREA)
- Economics (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Entrepreneurship & Innovation (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
L'invention concerne un procédé de gestion d'une structure de données d'enregistrement étendue (9) dans un système de gestion de contenu (100). La structure de données d'enregistrement comprend une structure de données d'enregistrement standard (90) pour le stockage d'enregistrements comprenant des éléments de données standard de types standard prédéfinis sous la forme de conteneurs de données standard et une structure de données d'enregistrement non-standard (91) pour le stockage d'enregistrements comprenant des éléments de données non-standard de types différents desdits types standards prédéfinis sous la forme de conteneurs de données non-standard. Chaque enregistrement dans la structure de données d'enregistrement étendue (9) comprend un identifiant d'enregistrement, les enregistrements correspondant à des éléments de données associés dans la structure de données d'enregistrement étendue (9) partageant un identifiant d'enregistrement commun, le procédé comprenant, pour chaque enregistrement créé dans la structure de données d'enregistrement étendue (9) pour un élément de données ayant un identifiant d'enregistrement donné, la création d'une entrée dans une structure de données auxiliaire (92). L'entrée partage l'identifiant d'enregistrement donné et comprend un conteneur de données auxiliaire, ledit conteneur de données auxiliaire comprenant un ensemble d'attributs associés aux conteneurs de données partageant le même identifiant d'enregistrement dans la structure de données d'enregistrement. Le procédé gère la structure de données d'enregistrement étendue (9) sur la base des données maintenues dans la structure de données auxiliaire (92).
Description
ARRIERE-PLAN
Procédé et système de gestion d’une structure de données d’enregistrement
ARRIERE-PLAN
La présente invention concerne de manière générale la gestion de données, et en particulier des procédés, systèmes et produits de programmes informatiques pour gérer une structure de données d’enregistrement dans un système de gestion de contenu.
Les systèmes de gestion de contenu peuvent offrir un accès à un contenu spécifique à un ou plusieurs clients (par exemple, des consommateurs finaux) connectés au système via des réseaux de communication dédiés.
Avec l'apparition d'un grand nombre de fournisseurs de distribution de contenu dans chaque secteur industriel, il existe un besoin pour chaque consommateur de pouvoir accéder à plusieurs fournisseurs de contenu via un unique système de gestion de contenu.
Par exemple, dans l'industrie du tourisme, des systèmes de gestion de voyages peuvent être utilisés pour distribuer du contenu obtenu auprès d'un ensemble de systèmes de fournisseurs de voyages (fournisseurs de contenu) vers une pluralité de systèmes d'agences de voyages (consommateurs de contenu). L'industrie du tourisme a connu une croissance considérable durant ces dernières décennies et, dans le même temps, les services proposés par l'industrie du tourisme ont considérablement changé, de sorte qu'une large variété de services est maintenant offerte aux consommateurs finaux, impliquant un contenu hétérogène. En outre, l'industrie du tourisme implique maintenant beaucoup d'acteurs entre les fournisseurs de voyages et les consommateurs finaux, avec une énorme quantité de données à gérer entre ces différents acteurs. Entre le fournisseur de voyages et l'utilisateur final, des intermédiaires voyagistes tels que des Systèmes de Distribution Globale (GDS, "Global Distribution Systems ") fournissent des Systèmes de Gestion de Voyages pour permettre aux agents voyagistes de récupérer des informations auprès de fournisseurs de voyages traditionnels (compagnies aériennes), ou de conduire des transactions entre des consommateurs finaux et des fournisseurs de voyages traditionnels.
Le modèle métier des agences de voyages qui se concentrait principalement sur la distribution exclusive de transports aériens évolue et des acteurs réalisent maintenant des marges plus importantes grâce à un contenu non aériens. Une très grande variété de services offerts par de nouveaux types de fournisseurs de voyages est ainsi proposée à destination.
La présente invention concerne de manière générale la gestion de données, et en particulier des procédés, systèmes et produits de programmes informatiques pour gérer une structure de données d’enregistrement dans un système de gestion de contenu.
Les systèmes de gestion de contenu peuvent offrir un accès à un contenu spécifique à un ou plusieurs clients (par exemple, des consommateurs finaux) connectés au système via des réseaux de communication dédiés.
Avec l'apparition d'un grand nombre de fournisseurs de distribution de contenu dans chaque secteur industriel, il existe un besoin pour chaque consommateur de pouvoir accéder à plusieurs fournisseurs de contenu via un unique système de gestion de contenu.
Par exemple, dans l'industrie du tourisme, des systèmes de gestion de voyages peuvent être utilisés pour distribuer du contenu obtenu auprès d'un ensemble de systèmes de fournisseurs de voyages (fournisseurs de contenu) vers une pluralité de systèmes d'agences de voyages (consommateurs de contenu). L'industrie du tourisme a connu une croissance considérable durant ces dernières décennies et, dans le même temps, les services proposés par l'industrie du tourisme ont considérablement changé, de sorte qu'une large variété de services est maintenant offerte aux consommateurs finaux, impliquant un contenu hétérogène. En outre, l'industrie du tourisme implique maintenant beaucoup d'acteurs entre les fournisseurs de voyages et les consommateurs finaux, avec une énorme quantité de données à gérer entre ces différents acteurs. Entre le fournisseur de voyages et l'utilisateur final, des intermédiaires voyagistes tels que des Systèmes de Distribution Globale (GDS, "Global Distribution Systems ") fournissent des Systèmes de Gestion de Voyages pour permettre aux agents voyagistes de récupérer des informations auprès de fournisseurs de voyages traditionnels (compagnies aériennes), ou de conduire des transactions entre des consommateurs finaux et des fournisseurs de voyages traditionnels.
Le modèle métier des agences de voyages qui se concentrait principalement sur la distribution exclusive de transports aériens évolue et des acteurs réalisent maintenant des marges plus importantes grâce à un contenu non aériens. Une très grande variété de services offerts par de nouveaux types de fournisseurs de voyages est ainsi proposée à destination. Avec l'attractivité de ces canaux de distribution alternatifs, les agences de voyages tendent à distribuer de plus en plus de contenu non GDS (par exemple, hôtels, locations de véhicules, etc.) en plus du contenu GDS habituel (par exemple, un contenu de voyage par avion ou par train).
Cependant, les systèmes de gestion de voyages classiques n'offrent pas de moyens appropriés pour fournir directement aux agences de voyages des informations relatives à du contenu non GDS.
Tel que représenté sur la Figure 1, un système de gestion de voyages 1 comprend généralement une structure de données d'enregistrement telle qu'une structure de données "Enregistrement du Nom du Passager" 900 pour stocker des enregistrements associés à du contenu GDS reçu directement de fournisseurs de contenu GDS 40. Chaque enregistrement (PNR) est identifié dans une base de données BD par un repère de dossier. Les repères de dossier PNR peuvent alors être utilisés pour accéder au contenu GDS et le distribuer à des dispositifs clients tels que des systèmes d'agents voyagistes ou de consommateurs finaux (60).
La structure de données PNR 900 contient un repère de dossier en association avec des données de voyages associées à un passager donné ou un groupe de passagers voyageant ensemble (le repère de dossier est également connu comme un numéro de confirmation, un numéro de réservation, un code de confirmation, une référence de réservation, etc.). Par exemple, lorsqu'une réservation est effectuée pour un passager ou un groupe de passagers, un PNR est créé dans la structure de données 900, ce PNR comprenant un repère de dossier et des données correspondant au contenu de la réservation (par exemple, données du vol telles que l'heure d'arrivée, l'heure de départ, etc.).
Actuellement, les systèmes de gestion de voyages ne peuvent pas recevoir directement du contenu non GDS en provenance de fournisseurs de voyages non GDS 50 en raison de contraintes de normalisation.
En effet, la manière dont un système de gestion de voyages échange avec un fournisseur de voyages standard (40) est soumis aux règles définies par l'Association Internationale des Transports Aériens (IATA, "International Air Transport Association"), dans les Procédures de Messages Interlignes de Réservations ATA/IATA - Passagers (AIRIMP, "ATA/IATA Réservations Interline Message Procedures - Passenger"). En particulier, les messages échangés entre un fournisseur de voyages standard 40 et le moteur de gestion de contenu de voyages 30 doivent satisfaire à un format d'échange de messages TT Y (format Télétype) défini par la norme IAT A et les PNR conventionnels 900 sont configurés pour ne traiter que du contenu reçu dans un tel format TTY.
Aucune norme industrielle n'est définie en tant que telle pour la topologie et le contenu d'un PNR 900. Cependant, chaque système de gestion de voyages (par exemple, un Système de Réservation par Ordinateur, (CRS, " Computer Réservation System ") définit ses propres normes propriétaires pour la topologie et le contenu du PNR, en tenant compte des limitations de l'AIRIMP et en particulier la nécessité d'établir aisément une correspondance entre données PNR et messages AIRIMP. Par conséquent, il existe de nombreuses similitudes en ce qui concerne les contenus et formats de données de PNR 900 tenus par différents systèmes de gestion de voyages. En particulier, chaque structure de données PNR 900 est telle que les données de voyages associées à un repère de dossier doivent satisfaire à un certain nombre de types prédéfinis qui correspondent au contenu GDS normalisé par l'IATA (données aériennes, données ferroviaires, etc.).
Par conséquent, seul du contenu GDS (par exemple, des données aériennes, ferroviaires) peut être enregistré dans la structure de données PNR 900 dans un format statique satisfaisant aux contraintes associées à la norme d'échange de messages IATA. Il n'est donc pas possible de créer d'enregistrement pour un contenu non GDS (location de véhicules, jet-ski, etc.).
Le document US2012259667 propose une solution pour le stockage de contenu non GDS dans le PNR 900 sous la forme de remarques, de segments divers ou fantômes. Cependant, une telle solution ne permet pas au système de gestion de voyages de stocker de manière dynamique et fluide du contenu non GDS reçu directement d'un fournisseur de voyages non-standard, d'une manière structurée, à l'avance, dans le PNR 900 parmi d'autres éléments non GDS.
Les systèmes de gestion de voyages conventionnels 1 ne traitent que du contenu provenant de fournisseurs de voyages GDS, tels que des fournisseurs de lignes aériennes. Un système de gestion de voyages conventionnel comprend un moteur de gestion de contenu de voyages 30 utilisant un nombre considérable d'applications, chaque application étant associée à un service de voyage spécifique (par exemple, réservation, boutique, prix, etc.). En réponse à une demande provenant d'un agent voyagiste donné Ai (70), le moteur de gestion de contenu de voyages 30 peut uniquement récupérer du contenu auprès de fournisseurs de voyages GDS 40, générer un enregistrement dans le PNR 900 et renvoyer une représentation de l'enregistrement PNR ainsi créé à l'agent voyagiste Ai.
Chaque agent voyagiste doit être connecté directement à un ensemble de fournisseurs de contenu non GDS 50 si l'agent voyagiste a besoin d'accéder à du contenu non GDS, tandis que le système de gestion de voyages 1 n'est connecté directement qu'à des fournisseurs de contenu GDS 40. D'autre part, chaque agent voyagiste est connecté directement à un ensemble spécifique de fournisseurs de voyages 50 pour obtenir du contenu de voyage non GDS (taxi, billets de spectacles, etc.). Le moteur de gestion de contenu de voyages 30 expose donc n plateformes de services de voyages (une plateforme 2.1, 2.2, .. ,2.i, 2.n pour chaque agent voyagiste Al à An), tout en ne traitant que du contenu de voyages standard (contenu GDS) provenant des fournisseurs de voyages standard 40.
Par conséquent, si un agent voyagiste Ai donné souhaite un contenu spécifique provenant d'un fournisseur de voyages non-standard 50 (par exemple, un billet de musée), ce contenu doit être implémenté personnellement par l'agent voyagiste Ai. Cette implémentation personnelle est particulièrement coûteuse et complexe pour les agents voyagistes.
En outre, dans des approches classiques, le système de gestion de voyages 100 stocke le contenu de PNR dans un format local (format de contenu PNR source). Cependant, le système de gestion de voyages peut avoir besoin d'échanger des données entre le PNR et d'autres systèmes externes (fournisseurs de voyages, agences de voyages) ayant leur propre format de données PNR (format de contenu PNR cible). Par conséquent, selon le système cible, une conversion du contenu PNR associé à un enregistrement PNR du système de gestion de voyages peut être effectuée vers le format de contenu PNR cible. Cette conversion implique actuellement un codage matériel et une recompilation, dans une approche coûteuse et statique. De manière similaire, dans un flux d'applications utilisant du contenu PNR à l'intérieur du système de gestion de voyages 100, chaque application interne du flux d'applications (applications chaînées) qui reçoit le contenu PNR doit convertir le contenu PNR en un format d'application afin de le manipuler. Chaque application de la chaîne doit donc décoder, valider et coder le contenu PNR pour pouvoir l'écrire ou le lire, ce qui nécessite des composants codés manuellement et s'avère coûteux.
Il existe donc un besoin concernant des systèmes, procédés et produits de programmes informatiques améliorés pour la gestion de contenu, permettant un échange de RESUME
Afin de résoudre ces problèmes ainsi que d'autres, il est mis à disposition un procédé de gestion de contenu tel que défini dans la revendication indépendante 1 présentée en annexe, et un système de gestion de contenu tel que défini dans la revendication indépendante 15 présentée en annexe. Des formes de réalisation préférées sont définies dans les revendications dépendantes.
Le procédé et le système selon les divers modes de réalisation de l'invention permettent ainsi une gestion centralisée de la structure de données d'enregistrement standard et de la structure de données d'enregistrement non-standard. Les informations conservées dans la structure de données de gestion centrale peuvent être utilisées pour traiter les deux zones de manière synchrone pour les données communes. Une telle structure de données de gestion centrale permet en outre de purger les structures de données d'enregistrement standard et non-standard ou de gérer les conflits d'accès aux structures de données d'enregistrement standard et non-standard comme si elles formaient une structure de données d'enregistrement unique.
D'autres avantages de la présente invention deviendront clairs pour l'homme du métier à l'examen des dessins et de la description détaillée. Il est bien entendu que tout avantage additionnel y sera incorporé.
BREVE DESCRIPTION DES DESSINS contenu dynamique et fluide.
RESUME
Afin de résoudre ces problèmes ainsi que d'autres, il est mis à disposition un procédé de gestion de contenu tel que défini dans la revendication indépendante 1 présentée en annexe, et un système de gestion de contenu tel que défini dans la revendication indépendante 15 présentée en annexe. Des formes de réalisation préférées sont définies dans les revendications dépendantes.
Le procédé et le système selon les divers modes de réalisation de l'invention permettent ainsi une gestion centralisée de la structure de données d'enregistrement standard et de la structure de données d'enregistrement non-standard. Les informations conservées dans la structure de données de gestion centrale peuvent être utilisées pour traiter les deux zones de manière synchrone pour les données communes. Une telle structure de données de gestion centrale permet en outre de purger les structures de données d'enregistrement standard et non-standard ou de gérer les conflits d'accès aux structures de données d'enregistrement standard et non-standard comme si elles formaient une structure de données d'enregistrement unique.
D'autres avantages de la présente invention deviendront clairs pour l'homme du métier à l'examen des dessins et de la description détaillée. Il est bien entendu que tout avantage additionnel y sera incorporé.
BREVE DESCRIPTION DES DESSINS
Les dessins joints, qui sont incorporés ici et qui constituent une partie de la présente demande, illustrent différentes formes de réalisation de l'invention et, en association avec la description générale de l'invention donnée ci-dessus et la description détaillée des formes de réalisation données ci-après, servent à expliquer les formes de réalisation de l'invention.
La Figure 1 est une vue schématique d'un système de gestion de contenu classique selon la technique antérieure ;
La Figure 2 est une vue schématique d'un système de gestion de contenu selon certaines formes de réalisation incluant une pluralité de systèmes informatiques connectés via un réseau ;
Les dessins joints, qui sont incorporés ici et qui constituent une partie de la présente demande, illustrent différentes formes de réalisation de l'invention et, en association avec la description générale de l'invention donnée ci-dessus et la description détaillée des formes de réalisation données ci-après, servent à expliquer les formes de réalisation de l'invention.
La Figure 1 est une vue schématique d'un système de gestion de contenu classique selon la technique antérieure ;
La Figure 2 est une vue schématique d'un système de gestion de contenu selon certaines formes de réalisation incluant une pluralité de systèmes informatiques connectés via un réseau ; La Figure 3 est une vue schématique d'un environnement de fonctionnement représentatif incluant un système de gestion de contenu ;
La Figure 4 est une vue schématique d'un système informatique représentatif des Figures 2 et 3 ;
La Figure 5 est un organigramme décrivant un processus qui peut être exécuté pour ajouter un nouveau contenu dans la structure de données d'enregistrement étendue ;
La Figure 6 est une vue schématique de la structure d'une application interne s'exécutant dans le système de gestion de contenu selon certaines formes de réalisation ;
La Figure 7 est une vue schématique décrivant le fonctionnement d'une application interne basée sur des objets techniques du type Modèle d'Objet Métier ;
La Figure 8 est une vue schématique du système de gestion de contenu décrivant des interactions représentatives entre des applications internes ;
La Figure 9 est une vue schématique d'un conteneur de données non-standard représentatif défini par un ensemble de valeurs de clés ;
La Figure 10 est une vue schématique de formats de sérialisation représentatifs ;
La Figure 11 est une vue schématique du conteneur de données non-standard représentatif de la Figure 9 avec des informations de type incluses dans le conteneur de données non-standard ;
La Figure 12 est une vue schématique du fichier de description de structure représentatif associé au conteneur de données non-standard de la Figure 12 ;
La Figure 13 est un organigramme d'un procédé qui peut être exécuté pour un accès de contenu par une application ;
La Figure 14 est une vue schématique d'une unité d'échange de contenu représentative ;
La Figure 15 est un organigramme d'un processus qui peut être exécuté pour transmettre du contenu à un dispositif client ;
La Figure 16 est une vue schématique d'une conversion XSLT d'un conteneur de données standard de type C ;
La Figure 17 est une vue schématique d'une conversion XSLT d'un conteneur de données non-standard du même type C que le conteneur de données standard de la Figure 16 ;
La Figure 18 est une vue schématique d'une conversion XSLT d'un conteneur de données standard du type D comprenant un ensemble d'attributs ;
La Figure 19 est une vue schématique d'une conversion XSLT d'un conteneur de données non-standard de type E ayant certains attributs identiques aux attributs du conteneur de données standard de la Figure 18 ;
La Figure 20 est un organigramme d'un processus qui peut être exécuté pour réarranger des éléments de données ; et
La Figure 21 est une vue schématique d'une structure de données d'enregistrement étendue, selon certaines formes de réalisation.
DESCRIPTION DETAILLEE
Les procédés, systèmes et produits de programmes informatiques selon des formes de réalisation de l'invention peuvent permettre une gestion dynamique de tout type de contenu (standard et non-standard) reçu en provenance de fournisseurs de contenu et d'un stockage centralisé d'enregistrements associés à ce contenu, quel que soit le type de contenu. Le système de gestion de contenu 100 peut être basé sur une architecture client/serveur permettant la réception de demandes de clients.
En référence à la Figure 2, il est mis à disposition un système de gestion de contenu 100 par l'intermédiaire duquel un certain nombre de clients utilisateurs 7 peut accéder directement, via une plateforme unique, à tout type de contenu fourni par un ensemble de systèmes de fournisseurs de contenu 4, 5. Le contenu traité par le système de gestion de contenu 100 peut être reçu de systèmes de fournisseurs de contenu standard 4 communiquant avec le système de gestion de contenu 100 en fonction d'un premier type de format d'échange de messages 14, tel qu'un format d'échange de messages standardisé prédéfini, ou de systèmes de fournisseurs de contenu non-standard 5 communiquant avec le système de gestion de contenu 100 selon un deuxième type de format d'échange de messages 15.
Le système de gestion de contenu 100 peut être connecté à un réseau de communication 13, lequel réseau de communication 13 peut comprendre l'Internet, un réseau local (LAN), un réseau étendu (WAN), un réseau voix/données cellulaires, une ou plusieurs
DESCRIPTION DETAILLEE
Les procédés, systèmes et produits de programmes informatiques selon des formes de réalisation de l'invention peuvent permettre une gestion dynamique de tout type de contenu (standard et non-standard) reçu en provenance de fournisseurs de contenu et d'un stockage centralisé d'enregistrements associés à ce contenu, quel que soit le type de contenu. Le système de gestion de contenu 100 peut être basé sur une architecture client/serveur permettant la réception de demandes de clients.
En référence à la Figure 2, il est mis à disposition un système de gestion de contenu 100 par l'intermédiaire duquel un certain nombre de clients utilisateurs 7 peut accéder directement, via une plateforme unique, à tout type de contenu fourni par un ensemble de systèmes de fournisseurs de contenu 4, 5. Le contenu traité par le système de gestion de contenu 100 peut être reçu de systèmes de fournisseurs de contenu standard 4 communiquant avec le système de gestion de contenu 100 en fonction d'un premier type de format d'échange de messages 14, tel qu'un format d'échange de messages standardisé prédéfini, ou de systèmes de fournisseurs de contenu non-standard 5 communiquant avec le système de gestion de contenu 100 selon un deuxième type de format d'échange de messages 15.
Le système de gestion de contenu 100 peut être connecté à un réseau de communication 13, lequel réseau de communication 13 peut comprendre l'Internet, un réseau local (LAN), un réseau étendu (WAN), un réseau voix/données cellulaires, une ou plusieurs connexions par bus haute vitesse, et/ou d'autres réseaux de communication de ce type.
Le système de gestion de contenu 100 peut être dédié à un ou plusieurs champs spécifiques (par exemple, le champ voyage). Un ou plusieurs dispositifs clients 7 peuvent être connectés chacun au réseau de communication 13, de telle sorte qu'un utilisateur puisse initialiser une session de demande de service auprès du système de gestion de voyages 100 et recevoir du contenu en provenance du système de gestion de voyages 100 en réponse à la demande de service.
Des formes de réalisation de l'invention peuvent être implémentées par un système informatique comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Le système informatique peut proposer des fonctions de traitement et de base de données pour une gestion de contenu.
Chaque dispositif client 7 peut être un dispositif informatique personnel, un ordinateur de type tablette, un terminal client mince, un smartphone et/ou d'autres dispositifs informatiques de ce type. Chaque dispositif client 7 peut héberger des navigateurs Web et/ou un logiciel d'application personnalisé (par exemple, un système client) et peut inclure une interface utilisateur cliente.
Chaque système de fournisseur de contenu 4 ou 5 peut être connecté au réseau de communication 13. Chaque système de fournisseur de contenu 4 ou 5 peut héberger un ou plusieurs sites Web et/ou avoir un service d'hébergement hébergeant un ou plusieurs sites Web.
Un utilisateur (à savoir, un voyageur) utilisant l'un des dispositifs clients 7 peut se connecter au système de gestion de contenu 100 à l'aide du dispositif client 7 pendant une session de demande de service associée à une application (accédée par exemple par connexion à un service Web). Le système de gestion de contenu 100 comprend un moteur de gestion de contenu 3 pour traiter la demande de service émanant du dispositif client 7.
Le moteur de gestion de contenu 3 peut échanger des messages avec les fournisseurs de voyages standard 4 en utilisant le format d'échange de messages TTY normalisé selon la norme IATA (premier format d'échange de messages 14).
Le moteur de gestion de contenu 3 peut en outre échanger des messages avec les fournisseurs non-standard 5 via une unité d'échange de données 11 (également appelée "unité d'accès au contenu" dans la présente description). L'unité d'échange de données 11 peut utiliser des messages définis selon un langage de description de données tel que le langage de balisage extensible (deuxième format d'échange de messages 15) pour communiquer avec les fournisseurs de contenu non-standard, par exemple en réponse à une recherche, une réservation, une demande de prix, une délivrance, une demande d'annulation émanant d'un client utilisateur 7 associé à une entité d'agent voyagiste (par exemple, un opérateur agent voyagiste ou un système d'agent voyagiste).
L'utilisateur peut soumettre la demande de service au système de gestion de contenu 100 en saisissant des informations au niveau du dispositif client 7 via une interface graphique utilisateur générée sur le dispositif client 7 par une application s'exécutant sur le système de gestion de contenu 100 (par exemple, sous la forme d'un service Web). Des informations reçues de l'utilisateur peuvent être accumulées jusqu'à ce que l'utilisateur soumette la demande de service au système de gestion de contenu 100 (par exemple, en exécutant une action de soumission).
En réponse à la demande utilisateur, le moteur de gestion de contenu 3 peut demander et obtenir du contenu auprès des systèmes de fournisseurs de contenu 4 et/ou 5 selon les formats d'échange de messages 14 et/ou 15 et stocker un enregistrement apparenté au contenu récupéré dans une structure de données d'enregistrement étendue 9. La stmcture de données d'enregistrement étendue 9 peut être stockée dans un contexte et sauvegardée dans une ou plusieurs bases de données 8 en réponse à une demande de sauvegarde, ou bien périodiquement. D'une autre manière, dans certaines formes de réalisation, la structure de données d'enregistrement étendue 9 peut être stockée directement dans une ou plusieurs bases de données 8.
La structure de données d'enregistrement étendue 9 comprend une structure de données d'enregistrement standard 90 pour stocker des enregistrements en association avec des données standard et une structure de données d'enregistrement non-standard 91 pour stocker des enregistrements en association avec des données non-standard.
Un enregistrement comprend un identifiant d'enregistrement (également appelé "repère de dossier") en association avec des éléments de données apparentés. L'identifiant d'enregistrement peut être d'un type quelconque ou d'un format quelconque, tel qu'un nombre.
La structure de données d'enregistrement standard 90 est statique car elle est uniquement adaptée pour stocker un enregistrement pour des types prédéfinis de contenu (appelé contenu "standard") ayant un ou plusieurs attributs parmi un ensemble prédéfini d'attributs. Tel qu'utilisé ici, le terme "standard" fait référence à un contenu standard ayant un format et/ou un type prédéfini correspondant au format et/ou aux types pris en charge par la structure de données d'enregistrement standard 90.
Un enregistrement peut être ajouté dans la structure de données d'enregistrement standard 90 pour un contenu reçu comprenant des éléments de données apparentés, si le contenu reçu comprend uniquement des éléments de données standard. L'enregistrement comprend un identifiant d'enregistrement en association avec les éléments de données.
D'une autre manière, un enregistrement peut être ajouté à la structure de données d'enregistrement non-standard 91 pour un contenu reçu comprenant des éléments de données apparentés, si le contenu reçu comprend uniquement des éléments de données non-standard. L'enregistrement comprend un identifiant d'enregistrement en association avec au moins un conteneur de données non-standard comprenant les éléments de données non-standard.
En outre, un enregistrement peut être ajouté à la structure de données d'enregistrement standard 90 et à la structure de données d'enregistrement non-standard 91 pour un contenu reçu comprenant des éléments de données apparentés, si le contenu reçu comprend des éléments de données non-standard et une structure de données d'enregistrement standard 90. Les deux enregistrements ajoutés pour le standard de contenu reçu dans la structure de données d'enregistrement 90 et dans la structure de données d'enregistrement non-standard 91 peuvent se voir attribuer tous les deux le même identifiant d'enregistrement (appelé ci-après "identifiant d'enregistrement commun"). L'identifiant d'enregistrement commun est partagé entre un ou plusieurs éléments de données standard (contenu standard) dans la structure de données d'enregistrement standard 90 et/ou un ou plusieurs conteneurs de données non-standard (comprenant des éléments de données non-standard) dans la structure de données d'enregistrement non-standard 91.
En utilisant un même identifiant d'enregistrement dans les deux structures de données d'enregistrement 90 et 91 pour identifier des éléments de données standard et nonstandard apparentés, le système de gestion de contenu 100 peut gérer les deux structures de données d'enregistrement de manière transparente comme si elles formaient une unique structure de données d'enregistrement.
Le moteur de gestion de contenu 3 peut enregistrer un certain nombre d'applications associées à différents services. Le moteur de gestion de contenu 3 peut exécuter une ou plusieurs applications en fonction de la demande de service reçue en provenance du dispositif client 7, qui peut déclencher une récupération de contenu auprès de systèmes de fournisseurs de contenu et le stockage des enregistrements apparentés à ce contenu reçu dans la structure de données étendue 9. Le moteur de gestion de contenu peut être en outre configuré pour renvoyer la réponse à la demande de service, en fonction des enregistrements stockés dans la structure de données d'enregistrement étendue 9, quel que soit le type de contenu, aux clients utilisateurs utilisant le contenu enregistré dans la structure de données d'enregistrement étendue 9. Pour retourner la réponse aux clients, le moteur de gestion de contenu 3 peut utiliser une unité d'échange de données 11 pour générer une représentation uniforme du contenu des dispositifs clients 7, quels que soient les types de contenu compris dans les enregistrements récupérés de la structure de données d'enregistrement étendue 9. Le moteur de gestion de contenu 3 joue donc le rôle d'un agrégateur d'applications pour fournir des services aux clients utilisateurs 7.
Dans une forme de réalisation préférée de l'invention, le système de gestion de contenu 100 peut être un Système de Gestion de Voyages. Le système de gestion de voyages 100 peut être mis en œuvre par un opérateur intermédiaire (par exemple, un Système de Distribution Globale (GDS) dans le domaine des voyages) pour permettre une gestion centralisée du contenu du voyage, implémentée par exemple par un GDS (acronyme pour "Global Distribution System " (Système de Distribution Globale)).
La Figure 3 présente un environnement de fonctionnement représentatif 10 d'un tel système de gestion de contenu 100 mis en œuvre dans un GDS 1. Dans cette forme de réalisation, le contenu standard fait référence au contenu GDS compatible avec les contraintes IATA (tel que des données aériennes, ferroviaires) fourni par des systèmes de fournisseurs de voyages standard 4, tandis que le contenu non-standard peut être un type quelconque de contenu non GDS qui ne satisfait pas aux contraintes IATA (par exemple, la location de véhicules) fourni par des systèmes de fournisseurs de voyages non-standard 5 ou réservé en dehors du système GDS. La structure de données d'enregistrement standard 90 peut être une structure de données PNR standard (également appelée ci-après "PNR standard", PNR étant l'acronyme de " Passenger Name Record" (Enregistrement du Nom du Passager)) qui est configurée pour stocker du contenu standard tandis que la structure de données d'enregistrement non-standard 91 (également appelée ci-après "PNR non-standard") 5 0 5 0 5 0 est configurée pour enregistrer de façon dynamique tout type de contenu non-standard sans qu'il soit nécessaire que les types et attributs du contenu non-standard soient prédéfinis par un codage matériel des mécanismes de mappage et de compilation des données. Le PNR standard 90 comporte généralement un ensemble complet de données pour un itinéraire de voyage, incluant des segments provenant de porteuses multiples, avec des structures de données prédéfinies (types, attributs, familles) et/ou d'autres services constituant le voyage, tels que les réservations d'un hôtel et d'un véhicule de location.
La structure de données d'enregistrement étendue 9 forme un Enregistrement de Voyage Etendu (également appelé ci-après "ETR" (" Extended Travel Record")), où chaque enregistrement de contenu peut être manipulé de manière fluide par le moteur de gestion de contenu 3 quel que soit le type de contenu associé à l'enregistrement.
Les dispositifs clients 7 peuvent être associés à une pluralité de systèmes d'agences de voyages 700 demandant des services via des interfaces clientes respectives 2. Plus particulièrement, le système de gestion de voyages 100 peut également accéder à différents types de dispositifs clients soumettant différents types de demandes selon une approche client/serveur, tels que des dispositifs de voyageurs 6 via des interfaces utilisateurs respectives 2 ou même des systèmes de fournisseurs de voyages 4 ou 5 (par exemple, pour l'échange de contenus stockés dans l'Enregistrement de Voyage Etendu 9).
Les systèmes de fournisseurs de voyages standard 4 peuvent inclure une pluralité de systèmes de compagnies ou systèmes de voyageurs. Les systèmes de fournisseurs de produits de voyages non-standard 5 peuvent inclure des systèmes de location de véhicule, des systèmes de réservation de musée, etc. Lorsqu'ils sont implémentés, les systèmes de compagnies peuvent inclure un Système de Réservation Informatique (CRS, "Computer Réservation System ") et/ou un système de facturation pour la ligne aérienne concernée, qui permet le GDS 1. Les systèmes d'agences de voyages 700 peuvent être configurés pour réserver et payer pour des billets de voyages et/ou des services additionnels offerts par des fournisseurs de voyages non-standard 5. Certains systèmes de fournisseurs de voyages standard 4 peuvent également interagir entre eux, soit directement soit via le GDS 1, pour permettre à une compagnie émettrice de vendre des billets pour des sièges fournis par une compagnie exploitante. La compagnie exploitante peut alors facturer la compagnie émettrice pour les services fournis.
Le GDS 1 peut être configuré pour faciliter la communication entre les fournisseurs 5 0 5 0 5 0 de voyages 4 et 5 et les systèmes d'agences de voyages 700 en permettant aux agents voyagistes, aux compagnies émettrices, ou à d'autres vendeurs indirects de rechercher des segments disponibles et d'effectuer des réservations sur un ou plusieurs systèmes de compagnies 4 et de rechercher et réserver des services additionnels (par exemple, location de véhicule, billets de musées, etc.) via le GDS 1.
Chaque système d'agence de voyages 70 peut inclure un serveur Web qui fournit un site Web accessible au public. Ce site Web peut être configuré pour offrir un accès à des fonctionnalités de planification de voyage, telles que la possibilité de rechercher des produits de voyage concordant avec une demande concernant un voyage. A cette fin, le système d'agence de voyages 70 peut fournir au voyageur un accès à des données provenant d'une ou plusieurs bases de données hébergées par le GDS 1, les fournisseurs de voyages 4 et 5, et le système d'agence de voyages 70. Dans une autre forme de réalisation de l'invention, le système d'agence de voyages 70 peut être un système propriétaire qui limite l'accès aux fournisseurs de services de voyages ou aux agents voyagistes, auquel cas un accès peut être fourni via un site Web privé ou une autre application.
Les voyageurs ou les agents voyagistes peuvent utiliser le système d'agence de voyages 70 pour générer et/ou rechercher des propositions de voyage qui satisfont à une demande concernant un voyage reçue du voyageur à l'aide d'une application spécifique relative aux voyages (par exemple, une application de planification de voyage).
Des dispositifs de voyageurs 6 peuvent être connectés directement au système de gestion des voyages 100 via un réseau publique ou privé 13 (par exemple, l'Internet). Le dispositif de voyageur 6 peut être un quelconque système informatique approprié configuré pour communiquer sur le réseau 13 avec le système de gestion de voyages 100. Par exemple, le dispositif de voyageur 6 peut comprendre un ordinateur de bureau, un ordinateur portable ou une tablette, un téléphone intelligent, ou tout autre dispositif informatique qui permet à un voyageur de rechercher et de réserver des services de voyages sur le réseau 20. Dans une forme de réalisation de l'invention, le dispositif de voyageur 6 peut inclure une application de navigateur Web qui communique avec une application de services Web hébergée par le moteur de gestion de contenu 3 du système de gestion de voyages 100 pour soumettre des demandes de voyages en fonction de l'application de services Web.
D'une autre manière, le dispositif de voyageur 6 peut inclure une application de navigateur Web qui communique avec une application de services Web hébergée par le 5 0 5 0 5 0 système d'agence de voyages 70. L'application de services Web peut, quant à elle, communiquer avec le système de gestion de voyages 100 pour soumettre les demandes de voyage en fonction de l'application de services de voyage.
Les demandes de voyages peuvent être soumises, par exemple, pour obtenir des données apparentées à des segments de voyages disponibles, pour générer des propositions de voyage qui satisfont à la demande de voyage et/ou pour réserver des services auxiliaires (par exemple, location de véhicule, réservation de jet-ski, réservation de billet de musée, etc.) correspondant au contenu non-standard fourni par des fournisseurs non-standard 5, en liaison avec un voyage fourni via le GDS 1 ou via un autre GDS.
En référence maintenant à la Figure 4, le GDS 1, le système de gestion de voyages 100, les systèmes de fournisseurs de voyages 4 et 5, les systèmes d'agences de voyages 70, les dispositifs de voyageurs 6 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, appelés collectivement ordinateur, tel que l'ordinateur 30. L'ordinateur 30 peut comporter un processeur 32, une mémoire 34, un dispositif de mémoire de stockage de masse 36, une interface d'entrée/sortie (I/O) 38 et une Interface Homme-Machine (IHM) 40. L'ordinateur 30 peut également être couplé de manière fonctionnelle à une ou plusieurs ressources externes 42 via le réseau 22 et/ou une interface I/O 38. Des ressources externes peuvent inclure, mais sans y être limitées, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau à base de nuage, ou toute autre ressource informatique appropriée qui peut être utilisée par l'ordinateur 30.
Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés parmi les microprocesseurs, les microcontrôleurs, les processeurs de signaux numériques, les microordinateurs, les unités centrales de traitement, les réseaux prédiffusés programmables par l'utilisateur, les dispositifs logiques programmables, les machines d'état, les circuits logiques, les circuits analogiques, les circuits numériques, ou d'autres dispositifs qui manipulent des signaux (analogiques ou numériques) en fonction d'instructions d'opérations qui sont stockées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif mémoire ou une pluralité de dispositifs mémoire incluant, mais sans y être limités, une mémoire morte (ROM), une mémoire vive (RAM), une mémoire volatile, une mémoire non volatile, une mémoire à accès aléatoire statique (SRAM), une mémoire à accès aléatoire dynamique (DRAM), une mémoire flash, une mémoire cache, ou tout autre dispositif 5 0 5 0 5 0 capable de stocker des informations. Le dispositif de mémoire de stockage de masse 36 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un lecteur de cassette, un dispositif à semi-conducteurs non volatile, ou tout autre dispositif capable de stocker des informations. Une base de données 44 peut résider sur le dispositif de mémoire de stockage de masse 36, et peut être utilisée pour collecter et organiser des données utilisées par les différents systèmes et modules décrits ici.
Le processeur 32 peut fonctionner sous la commande d'un système d'exploitation 46 qui réside dans la mémoire 34. Le système d'exploitation 46 peut gérer des ressources informatiques de telle sorte qu'un code de programme informatique intégré sous la forme d'une ou plusieurs applications logicielles, telles qu'une application 48 résidant dans la mémoire 34, peuvent avoir des instructions exécutées par le processeur 32. Dans une autre forme de réalisation, le processeur 32 peut exécuter l'application 48 directement, auquel cas le système de fonctionnement 46 peut être omis. Une ou plusieurs structures de données 50 peuvent également résider dans la mémoire 34, et peuvent être utilisées par le processeur 32, le système d'exploitation 46 et/ou l'application 48 pour le stockage ou la manipulation de données.
L'interface I/O 38 peut fournir une interface machine qui couple fonctionnellement le processeur 32 à d'autres dispositifs et systèmes, tels que le réseau 22 et/ou une ressource externe 42. L'application 48 peut ainsi travailler en coopération avec le réseau 22 et/ou une ressource externe 42 en communiquant via l'interface I/O 38 pour fournir les différentes particularités, fonctions, applications, processus et/ou modules comprenant des formes de réalisation de l'invention. L'application 48 peut également avoir un code programme qui est exécuté par une ou plusieurs ressources externes 42, ou autrement s'appuyer sur des fonctions et/ou signaux fournis par d'autres composants système ou réseau externes à l'ordinateur 30. En effet, étant donné la presque infinité de configurations matérielles et logicielles possibles, l'homme du métier comprendra que les formes de réalisation de l'invention peuvent inclure des applications qui sont situées à l'extérieur de l'ordinateur 30, distribuées sur plusieurs ordinateurs ou d'autres ressources externes 42, ou fournies par des ressources informatiques (matérielles ou logicielles), sous la forme d'un service sur le réseau 22, tel qu'un service informatique en nuage.
L'interface IHM 40 peut être couplée de manière fonctionnelle au processeur 32 de l'ordinateur 30 d'une manière connue, pour permettre à un utilisateur de l'ordinateur 30 5 0 5 0 5 0 d'interagir directement avec l'ordinateur 30. L'interface IHM 40 peut inclure des écrans vidéo et/ou alphanumériques, un écran tactile, un haut-parleur, et tout autre indicateur audio et visuel approprié capable de fournir des informations à l'utilisateur. L'interface IHM 40 peut également inclure des dispositifs de saisie et des commandes tels qu'un clavier alphanumérique, un dispositif de pointage, des pavés numériques, des boutons poussoirs, des boutons de commande, des microphones, etc., capables de recevoir des commandes et données d'entrée en provenance de l'utilisateur et de transmettre les entrées introduites dans le processeur 32.
La description suivante sera faite en référence au système de gestion de contenu 100 de la Figure 3, à titre d'exemple uniquement.
Différents agents de voyages connectés au système de gestion de contenu 100 via des systèmes d'agences de voyages 70 respectifs peuvent donc accéder directement, via une plateforme unique, à tout type de contenu fourni par un ensemble de systèmes de fournisseurs de voyages (4, 5), quel que soit le type de contenu (tel que du contenu de ligne aérienne standard, des taxis, des billets de spectacle, etc.). Le Système de Gestion de Voyages 100 offre donc la possibilité de stocker non seulement du contenu standard compatible avec la structure de données PNR standard 90, mais également tout nouveau type de contenu (à savoir, courses de taxi, billet de théâtre, concert, cadeaux, etc.) tout en rendant inutile que les agences de voyages réservent un tel contenu non-standard en dehors du système GDS par téléphone, ou par Internet, etc.
Grâce à l'ajout d'un PNR non-standard 91 au PNR standard 90, le système de gestion de voyages peut fournir de manière dynamique et fluide un nombre illimité de services de voyages aux systèmes d'agences de voyages 70.
L'Enregistrement de Voyage Etendu 9 forme donc une représentation de contenu structurée fournie par un quelconque système de fournisseur de voyages 4 ou 5 (il peut correspondre par exemple à un produit réservé en dehors du GDS), tandis que les enregistrements enregistrés dans l'ETR 9 peuvent être accédés et gérés comme si le PNR standard 90 et le PNR non-standard 91 formaient une unique structure de données d'enregistrement.
Un élément de données standard (par exemple, un produit) dans le PNR standard 90 est associé à un ensemble d'attributs qui peuvent être qualifiés comme étant optionnels Tableau 1
Déplacements Nuitées Repas Activités Services
Air Hôtel Restaurant Activités sportives Assurance
Ferry Appartement Bar & Club Boutiques Visa
Spectacles &
Croisière Camping Autre Cadeaux Evénements
Rail B&B Excursions Documentation
Equipement de
Autocar Autre Visites loisirs
Transports
Autre Services locaux urbains
Transfert Réunion
Taxi Vaccin
Voiture Autre
Vélo
Parking
0 ou obligatoires en fonction de la topologie et du format mis en œuvre dans le GDS 1 pour être compatible avec la norme IATA.
Les données enregistrées dans l'Enregistrement de Voyage Etendu 9 peuvent être classifiées en une pluralité de familles, chaque famille comprenant plusieurs types d'éléments de données comme, par exemple, les 5 familles représentées dans le Tableau 1. L'ETR 9 est adapté pour prendre en charge un nombre quelconque de nouveaux types et nouvelles familles d'éléments de données.
Tableau 1
Déplacements Nuitées Repas Activités Services
Air Hôtel Restaurant Activités sportives Assurance
Ferry Appartement Bar & Club Boutiques Visa
Spectacles &
Croisière Camping Autre Cadeaux Evénements
Rail B&B Excursions Documentation
Equipement de
Autocar Autre Visites loisirs
Transports
Autre Services locaux urbains
Transfert Réunion
Taxi Vaccin
Voiture Autre
Vélo
Parking
Le moteur de gestion de contenu 3 est configuré pour gérer du contenu hétérogène de l'ETR 9 qui peut comprendre :
- l'ajout de nouveaux éléments de données provenant de tout système de fournisseur de voyages 4 ou 5 dans l'enregistrement de voyage étendu 9, quel que soit le type de contenu, par exemple en réponse à des demandes émanant de systèmes d'agences de voyages 70;
Le moteur de gestion de contenu 3 est configuré pour gérer du contenu hétérogène de l'ETR 9 qui peut comprendre :
- l'ajout de nouveaux éléments de données provenant de tout système de fournisseur de voyages 4 ou 5 dans l'enregistrement de voyage étendu 9, quel que soit le type de contenu, par exemple en réponse à des demandes émanant de systèmes d'agences de voyages 70; - la modification d'éléments de données dans l'enregistrement de voyage étendu 9 (par exemple par changement de la date de début d'un produit "Musée" correspondant à une pré-réservation de deux entrées pour un Musée);
- l'effacement d'éléments de données de l'enregistrement de voyage étendu 9 (par exemple par suppression du Produit "Musée" de l'enregistrement de voyage étendu si un utilisateur a décidé de retirer ce produit de son voyage à New- York).
- la récupération d'éléments de données auprès de l'enregistrement de voyage étendu 9 (par exemple par récupération de tous les attributs structurés du produit "Musée" dans un enregistrement de voyage spécifique).
L'Enregistrement de Voyage Etendu (9) peut donc stocker du contenu non-standard et du contenu standard comme s'ils faisaient partie d'une unique structure de données d'enregistrement (PNR). Le moteur de gestion de contenu 3 gère le contenu hétérogène enregistré dans l'enregistrement de voyage étendu 9, d'une manière transparente pour les clients utilisateurs. L'enregistrement de voyage étendu 9 est en outre flexible et adapté à tout type de nouveau contenu (taxi, métro, bus, billetterie de musée, etc.), quels que soit les attributs associés au nouveau contenu.
Le PNR standard 90 est organisé selon la norme IATA. Lorsqu'un ensemble donné d'éléments de données est transmis par un système de fournisseur de voyages standard 4 au moteur de gestion de contenu 3 via un message selon le premier format d'échange de messages 14 dans un flux d'applications associé à un service donné (par exemple, un flux de gestion de réservation), les étapes suivantes peuvent être exécutées par le moteur de gestion de contenu 3 : i. les données peuvent être extraites par le moteur de gestion de contenu 3 à partir du message entrant transmis par le système de fournisseur de voyages standard 4, et ii. un enregistrement peut être ajouté dans le PNR standard 90, l'enregistrement comprenant un identifiant d'enregistrement en association avec les éléments de données correspondant aux données extraites par le moteur de gestion de contenu 3 (données de contenu).
Les données ainsi obtenues peuvent être utilisées pour construire un autre message à envoyer à une application suivante dans le flux d'applications.
Lorsque le flux d'applications met en jeu un ensemble d'applications internes 5 0 5 0 5 0 chaînées, l'étape i. peut être effectuée par une application interne donnée dans le flux d'applications, tandis que l'étape ii. peut être déclenchée par une autre application du flux.
Les données ajoutées dans le PNR standard 90 peuvent avoir uniquement un nombre limité d'attributs prédéfinis et doivent respecter un ou plusieurs types et formats prédéfinis (attributs normalisés);
Le PNR non-standard 91 n'est pas compatible avec les règles et les contraintes historiques de la norme (définition de contenu IATA, messages TTY, messages IATA). Cependant, le contenu non-standard peut faire partie de l'Enregistrement de Voyage Etendu 9 et être accédé de manière fluide et transparente par les applications exécutées par le moteur de gestion de contenu 3.
L'Enregistrement de Voyage Etendu 9 peut donc stocker tout type de contenu standard (par exemple, du contenu GDS tel que vol, hôtel, véhicule, croisière, assurance, ferry) et de contenu non-standard (tels que bus/taxi/restaurant/etc.) d'une manière structurée et dans un format universel.
Pour la gestion dynamique de tout type de contenu, le moteur de gestion de contenu 3 est configuré pour créer un conteneur de données non-standard en réponse à du contenu reçu comprenant des éléments de données non-standard transmis au système de gestion de voyages 100 par des systèmes de fournisseurs de contenu non-standard 5. Le conteneur de données non-standard peut s'adapter de manière dynamique au format de l'application interne du système de gestion de contenu qui reçoit l'élément de données en raison des propriétés d'auto-sérialisation du conteneur de données non-standard. Lorsque l'application interne réceptrice est une application d'un flux d'applications mettant en jeu un ensemble d'applications chaînées (applications internes), le conteneur de données non-standard peut s'adapter de manière dynamique au format de chaque application interne à laquelle il est transmis à l'aide des propriétés d'auto-sérialisation du conteneur de données non-standard.
Plus spécifiquement, lorsque le Système de Gestion de Voyages 100 se connecte à un nouveau fournisseur de voyages 5 fournissant un type de contenu non-standard, les éléments de données non-standard reçus du système de fournisseur de contenu non-standard 5 peuvent être stockés dans ce conteneur de données non-standard assigné au type de contenu non-standard. Un enregistrement peut ensuite être ajouté dans la structure de données d'enregistrement non-standard 91 par une application interne (par exemple dans un flux d'applications). L'enregistrement peut comprendre un identifiant d'enregistrement et le conteneur de données non-standard ayant le type de contenu non-standard. Le conteneur de données non-standard peut comprendre une liste d'attributs, chaque attribut étant représenté par une clé et une valeur. Chaque attribut peut lui-même comprendre une liste de sousattributs, qui sont chacun représentés par une clé et une valeur (de manière similaire pour les sous-attributs, etc.). Chaque clé d'attribut est associée à un nom et un type. Le conteneur de données non-standard est configuré pour s'auto-implémenter quelle(s) que soi(en)t la structure qu'il représente ou les données qu'ils contient : pour un accès en lecture seule ou un accès en lecture/écriture (par exemple, obtenir ou paramétrer) d'une quelconque valeur de tout attribut qui fait partie du conteneur de données non-standard, le conteneur de données non-standard permet un tel accès via un procédé ne dépendant ni du nom de la clé ni du type de la clé, sans qu'il soit nécessaire de mettre en œuvre des procédés d'obtention/paramétrage par codage matériel.
Le conteneur de données non-standard peut donc être utilisé pour créer un nouvel enregistrement dans le PNR non-standard 91, quel que soit le type de contenu. Cet enregistrement peut être accédé de manière transparente par le moteur de gestion de contenu 3, pour tout type d'actions de gestion de contenu, par exemple pour exécuter des applications de voyages, générer un affichage de résultat de demande de service sur les dispositifs clients 7, ou transmettre du contenu à des dispositifs externes (par exemple, des systèmes de fournisseurs de voyages ou des dispositifs de voyages).
En référence maintenant à la Figure 5, celle-ci présente un organigramme qui décrit un procédé pour la création d'un nouvel enregistrement dans l'Enregistrement de Voyage Etendu 9 en réponse à un contenu reçu en provenance d'un ou plusieurs systèmes de fournisseurs de voyages.
Au bloc 501, le moteur de gestion de contenu 3 peut recevoir du contenu en provenance d'un ou plusieurs fournisseurs de voyages 4, 5 par l'intermédiaire de formats d'échange de messages 14 et/ou 15, par exemple en réponse à une demande de service émanant d'un dispositif client 7, tel qu'un système d'agences de voyages.
Le contenu peut comprendre une pluralité d'éléments de données apparentés, par exemple des éléments de données relatifs à un même voyage, tels qu'un produit de type Vol (élément de données standard) et un produit de type Taxi (contenu non-standard) reçus de manière séquentielle. Les éléments de données associés à un contenu commun peuvent être reçus de manière séquentielle ou en parallèle. Les éléments de données peuvent comprendre des informations permettant d'identifier qu'ils font partie d'un même contenu commun.
Les éléments de données peuvent comprendre des éléments de données standard (par exemple, un produit de type Vol) et/ou des éléments de données non-standard (par exemple, un produit de type Taxi).
Les éléments de données standard (par exemple, du contenu GDS) peuvent être reçus selon le premier format d'échange de messages 14 tel que le format TTY.
Les éléments de données non-standard peuvent être reçus par l'unité d'échange de données 11 sous la forme d'un message défini selon un langage de description de balises tel que le langage XML selon le deuxième format d'échange de messages 15. La description suivante sera faite en référence au message XML (également appelé document ou fichier XML) pour un échange de données entre le système de gestion de voyages 100 et des systèmes externes. Le message d'échange de données peut comprendre un fichier de description de structure pour décrire la structure du message et les types et formats des données contenues dans le message. Par exemple, pour des messages d'échange de données du type XML, XML XSD, des schémas tels que des fichiers de description de structure peuvent être utilisés pour fournir une représentation de la structure des attributs du message XML.
Au bloc 502, pour chaque élément de données reçu pour le contenu commun, le moteur de gestion de contenu 3 peut extraire les éléments de données. L'extraction de contenu peut être effectuée par une application interne du moteur de gestion de contenu 3.
Si l'élément de données correspond à un contenu standard (par exemple, un produit de type Vol), le moteur de gestion de contenu 3 crée un enregistrement R dans le PNR standard (90) pour le contenu standard (par exemple, produit de type Vol) à l'aide d'un conteneur de données standard (également appelé ci-après "conteneur standard") au bloc 503 ayant le type d'élément de données (par exemple, le type Vol). Le conteneur de données standard peut être un conteneur statique configuré pour des types d'éléments de données prédéfinis (éléments de données standard). L'enregistrement R peut se voir assigner un identifiant d'enregistrement I et peut être associé au conteneur de données standard au bloc 505. L'enregistrement peut être sauvegardé dans un contexte temporaire et/ou dans au moins une base de données 8. Si l'élément de données correspond à un contenu non-standard (par exemple, un produite de type Taxi), le moteur de gestion de contenu 3 crée un enregistrement R dans le PNR non-standard (90) pour le contenu standard (par exemple, produit de type Vol) en utilisant le conteneur de données non-standard (également appelé ci-après "conteneur standard") au bloc 505. L'étape 505 peut être déclenchée par une application interne du flux d'applications. L'application interne déclenchant la création de l'enregistrement dans l'ETR peut être différente de l'application interne recevant l'élément de données non-standard de l'unité d'échange de données 11. Par exemple, une première application interne Al peut recevoir l'élément de données non-standard au format Fl de l'application Al, l'élément de données non-standard peut être transmis aux autres applications internes de la chaîne jusqu'à ce qu'il arrive à une application interne An au format Fn de l'application An, et finalement l'application An déclenche la création d'un enregistrement dans la structure de données d'enregistrement non-standard 91 (le conteneur de données non-standard ayant le format Fn). Le conteneur de données non-standard peut se voir assigner au type de l'élément de données (par exemple, type Taxi).
Le conteneur de données non- standard est adapté pour contenir tout type d'élément de données (élément de données non-standard). L'enregistrement R peut se voir assigner le même identifiant d'enregistrement I et peut être associé au conteneur de données nonstandard au bloc 506. L'enregistrement peut être stocké dans un contexte temporaire et/ou dans au moins une base de données.
Dans une forme de réalisation, le conteneur de données non-standard créé au bloc 506 peut en outre se voir assigner une étiquette au bloc 507. Cette étiquette peut être utilisée par le moteur de gestion de contenu 3 lors de l'accès à l'enregistrement R, par exemple pour identifier les éléments de données qui ne sont pas envoyés à des dispositifs clients 7.
Par conséquent, un identifiant d'enregistrement unique I peut être créé dans le PNR standard 90 et le PNR non-standard 91 pour tous les éléments de données standard et les éléments de données non-standard correspondant à un contenu commun (éléments de données apparentés). Cet identifiant d'enregistrement commun peut donc être partagé pour manipuler des enregistrements correspondant à des éléments de données hétérogènes, comme s'ils étaient tenus dans une unique structure de données d'enregistrement. Par exemple, l'identifiant d'enregistrement I peut être utilisé par le moteur de gestion de contenu 3 pour permettre à une application de lire/écrire des éléments de données nonstandard, quel que soit le type de données.
Dans un exemple simplifié, l'Enregistrement de Voyage Etendu 9 peut par exemple comprendre plusieurs enregistrements auxquels est assigné un identifiant d'enregistrement commun II, cet enregistrement ID1 étant associé en commun aux éléments de données suivants :
Elément de Données Standard DI de type 1 Elément de Données Standard D2 de type 2
- Elément de Données Standard D3 de type 3
Elément de Données Non-standard D4 de type 4 étiqueté Elément de Données Non-standard D5 de type 5
- Elément de Données Non-standard D6 de type 2 étiqueté.
Les enregistrements des éléments de données Dl, D2, D3 sont enregistrés dans la structure de données d'enregistrement standard 90 en association avec l'identifiant d'enregistrement ID1.
Les enregistrements pour les éléments de données D4, D5, D6 sont enregistrés dans la structure de données d'enregistrement standard 90 en association avec l'identifiant d'enregistrement ID1 (dans des conteneurs de données non-standard).
Le conteneur de données standard utilisé pour contenir des éléments de données standard est spécifiquement adapté pour contenir des éléments de données ayant un type prédéfini et paramétrer des attributs en fonction de la norme IAT A. Le conteneur de données standard est donc uniquement adapté aux formats de données et types de données normalisés.
Le conteneur de données non-standard peut être créé quels que soient le type, les attributs et le format des éléments de données non-standard. Chaque attribut peut lui-même comprendre un certain nombre de sous-attributs.
Le moteur de gestion de contenu 3 utilise par conséquent le conteneur de données non-standard pour créer de manière dynamique un nouveau type de contenu dans l'Enregistrement de Voyage Etendu (9), quel que soit le type de contenu.
Le conteneur de données non-standard peut être un conteneur de données polymorphe qui, à la différence d'un conteneur standard, n'est pas codé par codage matériel en le code pour un élément donné. En revanche, la forme qu'il prend peut être définie de manière dynamique.
Le conteneur de données non-standard peut également avoir des propriétés d'autosérialisation/désérialisation.
Dans certaines formes de réalisation, le conteneur de données non-standard peut être un objet technique représenté par un Modèle d'Objet Métier 21 de l'application interne qui le manipule, ce qui facilite l'intégration d'un nouveau contenu dans l'Enregistrement de Voyage Etendu 9.
La Figure 6 représente de manière schématique la structure d'une application interne du moteur de gestion de contenu 3 selon certaines formes de réalisation de l'invention, dans lesquelles le conteneur de données non-standard est un Modèle d'Objet Métier 21. L'application interne peut être une application autonome ou une application dans une chaîne d'applications (formant des applications apparentées).
L'application interne comprend :
- des interfaces structurées 2,
- un Modèle d'Objet Métier 21,
- une Couche Métier 22.
Les interfaces structurées 2 représentent la manière dont les applications communiquent entre elles. Les interfaces structurées peuvent transporter les données fonctionnelles que les applications peuvent traiter. Elles peuvent être mappées sur le modèle d'objet métier 21 qui est utilisé par la couche métier 22 pour effectuer des actions de validation et fonctionner. Une action de validation correspond à des vérifications fonctionnelles effectuées par la couche métier 22 sur les données en plus des vérifications grammaticales. Les éléments de données peuvent être insérés dans la structure de données d'enregistrement étendue 9 d'une manière structurée après validation.
Par conséquent, une modification des structures de données du PNR étendu 9 peut mettre en jeu une modification du Modèle d'Objet Métier 21 de l'application et une modification de ses interfaces structurées. En outre, pour tirer avantage des modifications de structure de données, les autres applications apparentées possibles peuvent également avoir besoin d'adapter leur Modèle d'Objet Métier 21, leurs interfaces structurées 2 et d'intégrer la nouvelle version du modèle de données dans les autres interfaces de modules. Les différentes formes de réalisation de l'invention permettent de limiter les coûts associés à une telle modification en utilisant le modèle de conteneur de données nonstandard.
Des applications de services de voyages fonctionnant dans le moteur de gestion de contenu 3 peuvent fonctionner selon le schéma de la Figure 7. Le BOM 21 représente le Modèle d'Objet Métier 21 utilisé pour représenter le modèle de données interne utilisé par l'application.
Le Service 210 représente un quelconque message structuré reçu par le système de gestion de voyages 100 (tel qu'un message XML ou Edifact) en provenance d'un dispositif client 7, un fournisseur de voyages non-standard 5 ou un dispositif de voyageur 6 qui peut être déclenché par l'application.
Le serveur de Contexte 211 représente le stockage Contextuel des données (également appelées "contexte") utilisées par l'application entre des interactions asynchrones avec d'autres applications.
Les données du contexte peuvent être sauvegardées dans la base de données 8 en réponse à une demande, périodiquement ou selon certaines conditions.
La Figure 8 illustre les interactions entre des applications chaînées Al à AN dans le moteur de gestion de contenu 3, en fonction de certaines formes de réalisation. Lorsque le système de gestion de voyages 100 est mis en œuvre selon une architecture distribuée, les applications internes chaînées Al à AN en charge des processus peuvent alors s'appeler mutuellement, ce qui peut entraîner plusieurs duplications de l'architecture 7 dans plusieurs serveurs d'application (30) (également appelés "serveurs principaux"), chaque serveur d'application 30 étant associé à une application chaînée respective Ai. A chaque étape de la chaîne de processus, dans des approches conventionnelles, les données qui sont transportées du premier serveur principal 30 pour l'application Al au dernier serveur 30 pour l'application An sont transformées, codées et décodées de différentes manières avant de passer d'un serveur 30 à un autre au milieu des processus. Chaque serveur principal 30 décode ensuite les éléments de données entrants et valide les données pour son processus dédié avant d'accéder aux éléments de données. Ensuite, les données sont codées pour être transmises à l'application suivante A,+1de la chaîne. En outre, le Modèle d'Objet Métier 21 peut être mis enjeu dans le processus de remplissage et de récupération d'informations dans ou depuis les interfaces structurées 2 et peut être utilisé pour écrire/lire des données. Dans des approches classiques, il faut des composants à codage manuel pour écrire/lire des données dans/depuis les interfaces structurées 2 et dans le référentiel d'enregistrement central. Par conséquent, un seul changement dans le modèle de données peut être coûteux. En outre, les éléments de données que les applications manipulent ont généralement beaucoup de contraintes fonctionnelles, de sorte que chaque application peut avoir besoin de s'assurer que les données manipulées soient dans un format approprié, compatible avec les contraintes de l'industrie (validation).
En conséquence, dans des approches classiques, à chaque fois qu'un élément de données doit être modifié dans ces applications chaînées, toutes les étapes du processus peuvent être impactées car chaque processus doit transmettre les nouvelles données au processus suivant et devra donc les décoder, les valider et les coder. De plus, lorsqu'un nouveau contenu doit être ajouté à une application existante, chaque processus doit en outre transmettre le nouveau contenu au processus suivant et chaque processus de la chaîne doit décoder, valider et coder le nouvel élément.
L'invention selon certaines formes de réalisation améliore la situation en utilisant la propriété d'auto-sérialisation du conteneur de données non-standard de type BOM.
En particulier, un conteneur de données non-standard peut être créé par une première application Al de la chaîne, en réponse à la réception d'éléments de données Dl, D2 et D3 en provenance de fournisseurs de contenu non-standard 5. Ce contenu nonstandard ne peut pas être stocké tel quel dans le PNR standard 90 car il ne comprend pas de types et attributs de données compatibles avec la structure standard du PNR 90. Le contenu non-standard peut prendre différentes formes et être associé à différents types et attributs.
La première application Al peut créer par exemple le conteneur non- standard pour chaque élément de données non-standard D au format Fl de la première application interne Al (par exemple, Tampons de Protocole). La première application Al fait ensuite passer le conteneur non-standard vers l'application suivante de la chaîne à l'aide d'un message Ml utilisant les propriétés d'auto-sérialisation/désérialisation du conteneur non-standard. Le message Ml peut être un grand objet binaire transportant des informations d'autosérialisation/désérialisation. La deuxième application A2 peut ensuite extraire le conteneur de données non-standard au format F2 de l'application interne A2. De manière similaire, la deuxième application peut transmettre le conteneur non-standard aux autres applications de la chaîne à l'aide de messages M2, M3, etc. transportant les informations d'autosérialisation/désérialisation jusqu'à ce qu'une application An déclenche la création d'un enregistrement dans l'ETR 9.
Par conséquent, grâce à l'utilisation d'un conteneur de données non-standard, aucun changement de données n'est requis pour l'ajout de nouvelles structures de données à l'ETR 9, la mise à jour de la structure de données ou la transmission d'un élément de données dans une chaîne d'applications internes. En outre, il n'est pas nécessaire de modifier des structures de données existantes. Les données contenues par le conteneur de données nonstandard peuvent être rendues disponibles sans qu'il soit nécessaire de les extraire et de les convertir d'un format en un autre. Les couches intermédiaires/codées manuellement peuvent donc être réduites.
Tel que décrit dans l'exemple de la Figure 9, un conteneur de données nonstandard 50 peut être défini par un ensemble de valeurs de clés qui décrivent un Modèle d'Objet Métier qui peut être manipulé par des applications. Chaque clé 51 définit un attribut du BOM et comprend une valeur associée 52 (également appelée "données" sur la Figure 9). Par exemple, le conteneur de données non-standard défini par la clé "ville" est associé à la valeur "Paris". Le conteneur de données peut comprendre des structures complexes et être associé à toute sorte de données. Par exemple, une ou plusieurs clés du conteneur de données peuvent en outre être associées à une référence 53 (appelée "REF" sur la Figure 9), pour associer un conteneur de données donné à un ensemble de conteneurs de données apparentés. Par exemple, le conteneur de données désigné par le couple clé/valeur "téléphone/+335551213" comprend une référence ("REF") aux conteneurs de données suivants: "mobile/+336123456" et "domicile/ +335551213".
Le conteneur de données non-standard 50 permet l'accès au moteur de gestion de contenu 3 en mode écriture pour l'un quelconque des éléments de données contenus dans le conteneur de données non-standard, sans qu'il soit nécessaire de développer un module d'accès pour permettre cet accès. Cela garantit la flexibilité et l'extensibilité.
En outre, un accès à l'élément de données contenu dans le conteneur de données non-standard peut être effectué par le moteur de gestion de contenu 3 à tout instant d'un traitement par une application à l'aide de demandes selon un langage d'interrogation approprié tel que Xpath. Le conteneur de données non-standard peut avoir une compatibilité descendante et montante en ce qui concerne la programmation. Du point de vue de la programmation, aucun changement de code n'est requis pour utiliser une nouvelle version des structures d'éléments de données associées au conteneur de données non-standard.
Le conteneur de données non-standard est configuré pour prendre en charge une sérialisation/désérialisation. En particulier, la sérialisation peut être exécutée au moment de la création et de la modification d'un ou plusieurs attributs du contenu non-standard pour coder le conteneur de données dans un format extensible et la désérialisation peut être effectuée à chaque fois qu'une application a besoin de lire au moins un attribut d'un contenu nonstandard.
En particulier, les clés et valeurs du conteneur de données non-standard peuvent être sérialisées à tout instant par traduction de l'état de l'objet technique (par exemple, BOM) représentant le conteneur de données non-standard en un format (par exemple, une représentation binaire) qui peut être stocké et reconstruit par un mécanisme de désérialisation pour restaurer le conteneur de données à son état d'origine. Le conteneur de données nonstandard peut donc être transformé en tout format cible, quelles que soient les données contenues dans le conteneur de données. Les mécanismes de sérialisation et désérialisation ne nécessitent pas un codage matériel. Des informations de sérialisation peuvent être intégrées dans une bibliothèque associée au Conteneur de Données. L'utilisation de ce BOM fournit donc nativement un mécanisme de sérialisation qui peut être pris en charge par toute sorte de structure définie par les clés du conteneur de données non-standard, sans nécessiter de codage spécifique. Dans certaines formes de réalisation représentatives, le format de représentation du conteneur de données non-standard utilisé pour traduire son état selon les mécanismes de sérialisation/désérialisation peut se fonder par exemple sur les formats XML, ASCII, JSON, Binaires, tel qu'illustré sur la Figure 10.
La validation des valeurs du conteneur de données non-standard peut n'être nécessaire qu'au moment de la création et de la modification de l'élément de données représenté par l'objet conteneur de données non-standard. Par conséquent, aucun processus de lecture n'est requis pour revalider les éléments de données associés aux clés.
A l'aide du conteneur de données non-standard, les informations relatives au type de contenu (par exemple, transport aérien, taxi, manifestation sportive, parking, transport urbain, etc.) peuvent être transportées dans le conteneur de données non-standard lui-même. Le type de conteneur de données non-standard peut être stocké sous la forme d'une clé directement dans le conteneur de données non-standard.
Dans certaines formes de réalisation, le mécanisme de validation à la création ou la modification d'un conteneur de données non-standard donné peut être basé sur le type fonctionnel stocké dans l'élément de données non stocké sous la forme d'une clé au lieu d'un type C++ sous la forme d'approches classiques.
Dans certaines formes de réalisation, chaque type de conteneur de données nonstandard peut être associé à un fichier de description de structure (par exemple, XSD) décrivant une structure d'attribut de l'élément de données (topologie d'attribut, dépendance d'attribut, et format d'attribut, etc.).
Le fichier de description de structure (par exemple, XSD) représente en outre l'interrelation entre les attributs et les éléments d'un conteneur de données non-standard représenté sous la forme d'un objet technique (par exemple, un objet XML). Dans un schéma XSD associé à un conteneur de données non-standard, les clés/valeurs différentes du conteneur de données non-standard et les contraintes auxiliaires qui lui sont appliquées peuvent être décrites à l'aide d'un ensemble d'étiquettes XML. Les fichiers de description de structure peuvent être utilisés à la création et la modification de conteneurs de données nonstandard. De plus, des contraintes auxiliaires peuvent être appliquées au conteneur de données non-standard à l'aide du fichier de description de structure (par exemple, XSD).
Le fichier de description de structure associé à chaque conteneur de données nonstandard peut être utilisé pour valider les attributs du conteneur de données non-standard à la création ou la modification du conteneur de données non-standard. Le mécanisme de validation peut comprendre la vérification du fait que l'élément de données non-standard représenté par le conteneur de données non-standard adhère à la description de l'élément de données dans lequel le contenu doit être placé. Dans certaines formes de réalisation, le mécanisme de validation peut être implémenté pour valider si les données stockées dans le conteneur de données non-standard correspond à un format cible à l'aide du fichier de description de structure associé au conteneur de données non-standard.
Le système de gestion de voyages 100 peut contenir un tableau pour le stockage du type de données du conteneur de données non-standard en correspondance avec le fichier de description de structure associé au conteneur de données non-standard. Le tableau peut être mis à jour au moment de l'exécution des processus.
Le moteur de gestion de contenu 3 peut être configuré pour ajouter de nouvelles données dans un conteneur de données non-standard, par mise à jour des fichiers de description de structure (par exemple, XSD) décrivant la structure du conteneur de données non-standard, comme par exemple de nouveaux attributs.
Le fichier de description de structure (par exemple, XSD) définissant un conteneur de données non-standard peut être modifié sans avoir à effectuer un codage matériel des changements et à recompiler le code. La modification d'un conteneur de données nonstandard est donc dynamique et apte à être mise à jour au moment de l'exécution.
La Figure 11 est une vue schématique des conteneurs de données non-standard représentatifs de la Figure 9, montrant leurs types respectifs : type Téléphone, type Adresse, type GPS. Le type d'information peut être stocké sous la forme d'un attribut dans le conteneur de données non-standard. Ces informations peuvent être utilisées pour récupérer le fichier de description de structure associé à un conteneur de données non-standard.
La Figure 12 illustre des fichiers de description XSD pour les exemples de conteneurs de données non-standard de la figure 11 qui ont des types différents ("Type Téléphone", "Type Adresse", "Type GPS").
Selon certaines formes de réalisation, le moteur de gestion de contenu 3 peut générer en outre un ensemble d'interfaces de services internes 2 dans la plateforme unique exposée par le Système de Gestion de Voyages 100 sur les dispositifs clients 7, quel que soit le type de contenu retourné à un dispositif client 7 et les applications entretenues par le moteur de gestion de contenu 3.
L'Enregistrement de Voyage Etendu 9 peut être utilisé par un nombre considérable d'applications. Par exemple, le moteur de gestion de contenu 3 peut comprendre un ensemble d'applications (par exemple, applications de voyages) pour délivrer différents types de services de voyages aux dispositifs clients 7 en fonction du contenu externe reçu de systèmes de fournisseurs de voyages standard 4 (par exemple, produits de ligne aérienne) et de tout autre système de fournisseur de voyages 5 (par exemple, des produits hors ligne aérienne), quel que soit le type de contenu. Ces services peuvent inclure par exemple les services Boutiques, Réservations, Etablissement de prix, Assurance, Remboursement. 5 0 5 0 5 0
Ces applications de services peuvent être exécutées en réponse à des demandes de services émanant de systèmes (par exemple, des systèmes d'agences de voyages 70) connectés au système de gestion de voyages 100 via un dispositif client 7, sans qu'il soit nécessaire d'adapter chaque application aux N types de données ajoutées à l'ETR 9 par codage matériel.
Les résultats peuvent être retournés via l'unité d'échange de données l i a l'aide de messages de réponse dans un format donné tel que des messages XML. Les interfaces de services internes 2 générées par le système de gestion de voyages (100) peuvent donc être du type XML.
Pour rendre inutile le recodage et la recompilation de chaque application pour prendre en charge un nombre quelconque de nouveaux types de conteneurs de données nonstandard, un élément générique ayant un type unique (type Elément Générique) peut être utilisé. L'élément générique est un méga-conteneur de données configuré pour contenir un conteneur de données non-standard d’un type quelconque. L'élément générique peut être vu par toutes les applications de services comme un conteneur d'un type unique (appelé ciaprès "type Elément Générique") tandis que l'élément générique peut contenir un nombre illimité N de types de données non-standard.
Chaque application peut donc instancier l'élément générique pour pouvoir manipuler les conteneurs non-standard d'une manière fluide, indépendamment du type de l'élément de données contenu dans le conteneur de données. Par conséquent, chaque application n'a pas besoin d'instancier autant de conteneurs de données non-standard que de nouveaux types de données.
En conséquence, l'ajout d'un nouveau type de contenu dans le PNR non-standard 91 n'impacte pas et ne nécessite pas l'adaptation aux applications traitées par le moteur de gestion de contenu 3 pour assurer une compatibilité descendante (par exemple, un codage matériel).
La Figure 13 est un organigramme décrivant l'accès aux enregistrements de l'ETR 9 ayant un identifiant d'enregistrement donné I par une application. Par exemple, l'identifiant d'enregistrement I peut comprendre :
- un élément de données standard SD1 de type Tl
- un élément de données standard SD2 de type T2 - un élément de données non-standard NSD3, contenu dans un conteneur de données non-standard, de type T3
- un élément de données non-standard NSD4, contenu dans un conteneur de données non-standard, de type T4.
Au bloc 600, les enregistrements associés à l'identifiant d'enregistrement I sont récupérés auprès de l'ETR 9. Les enregistrements peuvent être associés à des éléments de données standard (SD1, SD2) et des éléments de données non-standard NSD3, NSD4 (conteneurs de données non-standard) ayant des types respectifs Tl, T2, T3, T4.
Chaque élément de données SD1, SD2, NSD3 et NSD4 est ensuite traité séparément.
En particulier, pour chaque élément de données tel que par exemple le NSD3, si l'élément de données est un élément de données non-standard (bloc 601), l'élément de données non-standard de type T3 est transformé en un élément générique d'un Type Elément Générique contenant l'élément de données non-standard de type T3 au bloc 602. L'élément générique tel qu'un méga-conteneur de données peut contenir lui-même un conteneur de données non-standard ayant un type spécifique. L'élément générique peut être implémenté sous la forme d'un objet technique tel qu'un BOM, et peut être basé sur la même technologie que le conteneur de données non-standard.
Si l'élément de données est un élément de données standard (bloc 603) tel que par exemple SD1, l'élément de données standard de type Tl peut être converti en un conteneur de données non-standard du même type Tl au bloc 604.
Au bloc 602, l'élément de données non-standard ainsi obtenu est ensuite transformé en un élément générique d'un type Elément Générique unique contenant l'élément de données non-standard de type Tl correspondant à l'élément de données standard NSD1.
L'élément générique forme un état transitoire de l'élément de données non-standard, ce qui permet à l'application de manipuler les éléments de données standard et les éléments de données non-standard d'une manière fluide, quel que soit leur type. L'application peut donc manipuler les éléments de données de l'ETR 9 sans connaître explicitement le type du contenu non-standard comme s'ils avaient un type unique.
Au bloc 605, si l'exécution de l'application nécessite qu'un ou plusieurs éléments de données puissent être envoyés à l'interface du dispositif client 7 envoyant la demande de services, l'application peut inspecter l'élément générique pour accéder au type de l'élément de données.
Dans certaines formes de réalisation de l'invention, les éléments de données nonstandard peuvent être associés à des étiquettes respectives. Dans ces formes de réalisation, au bloc 601, seuls les éléments de données non-standard associés à des étiquettes respectives peuvent être sélectionnés par l'application et transformés dans un élément générique.
Par conséquent, l'élément générique abstrait le type des éléments de données nonstandard: au lieu de définir un nouveau type d'élément à chaque fois qu'un nouveau type de contenu doit être manipulé par les applications (nouveau contenu ajouté dans l'ETR 9), chaque application peut donc instancier un élément générique unique capable de prendre en charge de tous nouveaux types et attributs.
En référence de nouveau à la Figure 3, le système de gestion de voyages 100 peut être adapté pour échanger tout type de données (contenu standard et non-standard) avec tout type de dispositif client externe tel qu'un système d'agences de voyages 70, un système de fournisseur de voyages non-standard 5, et tout autre serveur principal à l'intérieur du même GDS via les interfaces internes 2.
Dans des approches conventionnelles, le système de gestion de voyages 100 peut échanger des données d'un PNR standard avec d'autres dispositifs clients cibles (par exemple, des systèmes de fournisseurs de voyages, des systèmes d'agences de voyages) ayant leur propre standard pour le format du contenu PNR (format de contenu PNR cible) par implémentation d'une conversion à codage matériel vers le format standard pris en charge par l'interface du dispositif client cible. Cela nécessite un mécanisme de codage au niveau du système de gestion de voyages 100 et des mécanismes de décodage/validation au niveau du dispositif cible. Au lieu de cela, chaque système de gestion de voyages peut avoir son propre standard pour le format du contenu PNR (format de contenu PNR source) et donc les interfaces des dispositifs cibles ne prennent en charge que ce format. Cette conversion (codage/décodage/validation) met actuellement en jeu un codage matériel et une recompilation, dans une approche coûteuse et statique.
L'unité d'échange de données 11 permet la réception ou la transmission d'un message d'échange de données à partir d'un dispositif client externe selon le deuxième format d'échange de données 15 pour échanger tout type de contenu. Dans une forme de réalisation préférée, le deuxième format d'échange de données 15 est un langage de description de balise
Dans certaines formes de réalisation de l'invention, les éléments de données nonstandard peuvent être associés à des étiquettes respectives. Dans ces formes de réalisation, au bloc 601, seuls les éléments de données non-standard associés à des étiquettes respectives peuvent être sélectionnés par l'application et transformés dans un élément générique.
Par conséquent, l'élément générique abstrait le type des éléments de données nonstandard: au lieu de définir un nouveau type d'élément à chaque fois qu'un nouveau type de contenu doit être manipulé par les applications (nouveau contenu ajouté dans l'ETR 9), chaque application peut donc instancier un élément générique unique capable de prendre en charge de tous nouveaux types et attributs.
En référence de nouveau à la Figure 3, le système de gestion de voyages 100 peut être adapté pour échanger tout type de données (contenu standard et non-standard) avec tout type de dispositif client externe tel qu'un système d'agences de voyages 70, un système de fournisseur de voyages non-standard 5, et tout autre serveur principal à l'intérieur du même GDS via les interfaces internes 2.
Dans des approches conventionnelles, le système de gestion de voyages 100 peut échanger des données d'un PNR standard avec d'autres dispositifs clients cibles (par exemple, des systèmes de fournisseurs de voyages, des systèmes d'agences de voyages) ayant leur propre standard pour le format du contenu PNR (format de contenu PNR cible) par implémentation d'une conversion à codage matériel vers le format standard pris en charge par l'interface du dispositif client cible. Cela nécessite un mécanisme de codage au niveau du système de gestion de voyages 100 et des mécanismes de décodage/validation au niveau du dispositif cible. Au lieu de cela, chaque système de gestion de voyages peut avoir son propre standard pour le format du contenu PNR (format de contenu PNR source) et donc les interfaces des dispositifs cibles ne prennent en charge que ce format. Cette conversion (codage/décodage/validation) met actuellement en jeu un codage matériel et une recompilation, dans une approche coûteuse et statique.
L'unité d'échange de données 11 permet la réception ou la transmission d'un message d'échange de données à partir d'un dispositif client externe selon le deuxième format d'échange de données 15 pour échanger tout type de contenu. Dans une forme de réalisation préférée, le deuxième format d'échange de données 15 est un langage de description de balise tel que XML. Chaque message d'échange de données correspondant à un élément de données non-standard comprend un fichier de description de structure définissant les attributs de l'élément de données (topologie et format des attributs), tels qu'un XSD pour des messages XML, et un ensemble de valeurs correspondant aux valeurs des attributs.
La Figure 14 représente plus en détail la structure de l'unité d'échange de données 11 selon certaines formes de réalisation.
L'unité d'échange de données 11 peut être utilisée pour échanger des éléments de données avec un dispositif client externe, tel qu'un fournisseur de voyages non-standard 5, un système d'agences de voyages ou un autre système non GDS. En particulier, l'unité d'échange de données 11 peut être utilisée pour :
- recevoir des éléments de données non-standard en provenance d’un dispositif client ; ou
- transmettre des éléments de données de l'ETR 9 à un dispositif client.
L'unité d'échange de données 11 peut comprendre un moteur de transformation de structure 111 tel qu'un moteur XSLT pour la transformation d'un fichier de description de structure tel qu'un XSD d'un fichier de description de structure source XSD1 en un fichier de description de structure cible XSD2 et un générateur de message d'échange de données 112 pour la transmission des données sous la forme d'un message défini selon un langage de description tel que XML. Le moteur XSLT peut utiliser des règles de mappage locales prédéfinies 113 (par exemple, feuilles de style XSLT) définissant des règles de transformation pour la transmission d'un fichier de description de structure source XSD1 en mode réception ou des règles de mappage client prédéfinies 117 (par exemple, feuilles de style XSLT) définissant des règles de transformation pour la transformation d'un fichier de description de structure source XSD1 en mode transmission.
Le système de gestion de voyages 100 peut enregistrer ou charger de manière dynamique au moment de l'exécution un ou plusieurs fichiers de description de structure locaux prédéfinis 115 associés à des types de contenu différents et correspondant à des fichiers de description de structure à appliquer localement par le système de gestion de voyages 100.
En mode réception, l'unité d'échange de données 11 peut recevoir un message d'échange de données entrant XML1 d'un dispositif client externe 7 compatible avec un fichier de description de structure source XSD1 défini par le dispositif client externe 7. Le message entrant XML1 contient un élément de données non-standard d'un type donné Ti.
A chaque fois qu'un tel message d'échange de données entrant XML1 est reçu par le système de gestion de voyages 100 comprenant un élément de données non-standard, le moteur de transformation 111 peut transformer le fichier de description de structure XSD1 du message entrant en un fichier de description de structure cible XSD2 à l'aide des règles de mappage locales 113 associées au type de l'élément de données contenu dans le message d'échange de données XML1. Le fichier de description de structure cible XSD2 est ensuite ajouté à l'ensemble de fichiers de description de structure locaux 115.
L'unité d'échange de données 11 peut en outre appliquer un mécanisme de validation au message entrant XML1 avant la transformation du fichier de description de structure source XSD1 en le fichier de description de structure cible XSD2 pour valider un certain nombre de conditions relatives aux attributs du fichier de description de structure XSD1 (par exemple présence d'attributs obligatoires).
Le conteneur de données non-standard du type Ti peut ensuite être généré par mappage des champs du message d'échange de données XML1 sur les primitives du conteneur de données non-standard. Le conteur de données non-standard est ensuite ajouté à l'ETR 9 en association avec le fichier de description de structure cible (XSD2) stocké en 115 pour le type Ti tel que décrit en relation avec la Figure 5. Toute mise à jour ou tout ajout de nouveau contenu dans l'ETR 9 peut être effectué au moment de l'exécution.
L'utilisation de l'unité d'échange de données 11 permet donc de convertir de manière dynamique tout message d'échange de données entrant reçu des systèmes de fournisseurs de contenu 4, 5 en plusieurs objets de contenu de données non-standard représentant les éléments à ajouter/modifier, sans nécessiter de changement de code.
En mode transmission (pointillés), le système de gestion de voyages 100 peut transmettre un quelconque élément de données de l'ETR dans l'interface cible d'un dispositif client externe 7 via l'unité d'échange de données.
En mode transmission, l'unité d'échange de données 11 reçoit en entrée un conteneur de données non-standard (contenant un élément de données non-standard ou un élément de données standard du type Ti préalablement converti en un conteneur de données nonstandard). Le conteneur de données non-standard de type Ti est associé à un fichier de description de structure (appelé fichier de description de structure source) comprenant une description des attributs (clé) du conteneur de données non-standard, de la topologie des attributs et du format d'attribut, tel qu'un fichier XSD (115). Un conteneur de données nonstandard est également associé à des valeurs de clé correspondant aux valeurs des attributs.
Si l'élément de données devant être transmis par le système de gestion de voyages 100 comprend un conteneur de données non-standard d'un type donné Ti provenant de l'ETR 9, le moteur de transformation 111 peut transformer le fichier de description de structure XSD3 associé au conteneur de données non-standard dans les fichiers de description de structure locaux 115 en un fichier de description de structure cible XSD4 à l'aide des règles de mappage client 117 associé au type de l'élément de données non-standard. Les règles de mappage client 117 définissent les règles de transformation vers le format de l'interface du dispositif client cible 7, par exemple pour afficher les interfaces graphiques utilisateur (GUI) du dispositif client cible 7.
Si l'élément de données à transmettre au dispositif client 7 est un élément de données standard (par exemple, éléments GDS) du type Ti, l'élément de données standard peut être préalablement converti en un conteneur de données non-standard du même type à l'aide du convertisseur de conteneur de données 12. L'élément de données standard peut ensuite être envoyé à l'unité d'échange de données 11 sous la forme d'un conteneur de données nonstandard pour la transmission du dispositif client cible 7.
La Figure 15 décrit un organigramme pour la transmission d'un élément de données de type Ti à l'interface cible d'un dispositif client 7 (Interface Graphique Utilisateur, GUI), selon certaines formes de réalisation.
Si l'élément de données est un élément de données standard (bloc 700), l'élément de données standard du type Ti peut être converti en un conteneur de données non-standard du même type Ti au bloc 701 (similaire au bloc 604 de la Figure 12). L'élément de données standard est ensuite traité au bloc 703 sous la forme d'un conteneur de données non-standard du type Ti, associé à un fichier de description de structure XSD1 et à des valeurs de clés Vi.
Si l'élément de données est un élément de données non-standard se présentant sous la forme d'un conteneur de données non-standard du type Ti (bloc 700) associé à un fichier de description de structure XSD1 et à des valeurs de clés Vi, l'élément de données non-standard 5
10
15
20
25
30 de type Ti est traité directement au bloc 703.
Au bloc 703, le fichier de description de structure source XSD1 associé au conteneur de données non-standard est récupéré.
Au bloc 704, le fichier de description de structure source XSD1 est converti en un fichier de description de structure cible XSD2 à l'aide du moteur de mappage 110 (par exemple, moteur XSLT) pour analyser le fichier de description de structure source XSD1 et convertir les champs analysés en un fichier de description de structure cible XSD2 à l'aide des règles de mappage 113 (par exemple, feuilles de style XSLT). Les règles de mappage 113 sont définies selon le format de l'interface cible du dispositif client 7.
Au bloc 705, le message XML contenant l'élément de données à transmettre au dispositif client est généré par ajout des valeurs Vi associées au conteneur de données nonstandard.
Au bloc 706, le message XML est envoyé à l'interface cible du dispositif client 7 via le réseau 13. L'interface cible peut être adaptée de manière dynamique et transparente en réponse à la réponse du message XML.
Les dispositifs clients externes 7 peuvent en outre extraire l'élément de données contenu dans le message XML et le stocker selon son propre standard sans avoir besoin d'appliquer un mécanisme de décodage et de validation complexe aux données, quel que soit le type des données et le format de l'interface cible.
Grâce à l'utilisation de conteneur de données non-standard associé à des fichiers de description de structure (XSD) et ayant la capacité de se sérialiser sous la forme d'un message d'échange de données en un quelconque format 15 (par exemple, XML), un nouveau type d'interfaces 2 peut donc être construit.
Dans une forme de réalisation, l'unité d'échange de données 11 peut être utilisée par le moteur de gestion de contenu 3 pour générer de manière dynamique une représentation cohérente de résultats de demande sur l’interface d'un dispositif client 7 (par exemple, système d'agences de voyages) quel que soit le type de contenu (contenu standard, nonstandard, mixte), avec aussi peu de logiciel à codage manuel que possible.
Les applications de services peuvent utiliser directement une structure de données homogène pour stocker les données dans les interfaces 2. Cela rend inutile l'échange entre les couches interfaces et les couches BOM d'encore un autre format de la structure de données. Cela permet en outre de réduire le surdébit entre les données stockées dans l'enregistrement de voyage étendu et la représentation des données dans les interfaces de services exposées aux dispositifs clients 7 (par exemple, systèmes d'agences de voyages) via une plateforme unique.
De manière spécifique, le procédé de la Figure 13 peut être appliqué pour générer une représentation de résultats en réponse à une demande de service émanant d'un dispositif client 7 (par exemple, système d'agence de voyages 70) et afficher cette représentation sur l'interface graphique utilisateur associée au service sur l'interface du dispositif client, tout en assurant que la représentation soit homogène quel que soit le type de contenu (contenu standard ou contenu non-standard).
Lorsqu'un identifiant d'enregistrement associé à un contenu non-standard et/ou un contenu standard est ajouté dans la Structure de Données d'Enregistrement Etendue 9, les applications de services sont adaptées pour générer une représentation d'enregistrement de manière dynamique et homogène, quel que soit le nouveau type.
L'application du moteur de gestion de contenu 3 correspondant à la demande de service peut accéder aux enregistrements correspondant au résultat obtenu auprès de l'ETR selon le procédé d'accès de la Figure 12 à l'aide de l'élément générique.
L'implémentation de l'accès aux conteneurs de données non-standard (50) sur la base de l'élément générique unique quel que soit le type de contenu à renvoyer au dispositif client 7 permet à chaque application de prendre en charge tout type de contenu provenant de systèmes de fournisseurs de contenu non-standard 5. Les applications dans le moteur de gestion de contenu 3 sont donc indépendantes du type de contenu.
Pour renvoyer les résultats à l’interface du système d'agence de voyages 70, l'application peut inspecter l'élément générique pour accéder au conteneur de données nonstandard (bloc 605 de la Figure 6). Le conteneur de données non-standard ainsi accédé peut donc être retourné selon le procédé de la Figure 14.
Le moteur de gestion de contenu 3 est donc adapté pour fournir une plateforme unique à tous les dispositifs clients 7 comprenant un ensemble d'interfaces par service (par exemple, service de voyage) représentant une réponse unique indépendamment du type de produits qui doit être manipulé (par exemple : produit de transport aérien GDS classique (vol) / location de véhicule GDS / taxi non GDS / restaurant non GDS...). Pour faciliter l'intégration d'un nouveau contenu dans une application, l'interface de services interne 2 associée à l'application peut avoir un ensemble d'attributs communs pour chaque famille de contenu. Cela permet à des nouveaux éléments d'une famille de contenu déjà existante de tirer avantage de toutes les fonctions d'affichage disponibles pour la famille.
De manière spécifique, la structure de données sous-jacente du Conteneur de Données non-standard (50) peut partager un format commun dans une catégorie d'élément spécifique. Par exemple, le fichier de description de format XSDi utilisé pour représenter un élément de données du type segment ligne aérienne peut être le même indépendamment du fait qu'il a été réservé via le système de gestion de voyages (100) ou via un autre système de réservation externe. Il peut donc également partager un ensemble de données communes avec des éléments d'une autre catégorie (par exemple, catégorie transport).
En particulier, le moteur de transformation 111 peut être défini de telle sorte que, pour un identifiant d'enregistrement donné II dans l'ETR 9 associé à un élément de données non-standard et à un élément de données standard, si l'élément de données non-standard et l'élément de données standard sont d'un même type général (par exemple, "hôtel"), une même représentation peut être générée pour les deux éléments de données au niveau de l'interface cible du dispositif client externe 7 (par exemple, système d'agence de voyages) par mappage du fichier de description de structure XSDI associé à l'élément de données non-standard et du fichier de description de structure XSD2 associé à l'élément de données standard sur un même fichier de description de structure du type commun compatible avec l'interface cible.
Par exemple, tel que décrit sur la Figure 16, un élément de données standard du type TYPE C est tout d'abord converti en un conteneur non-standard associé au même type TYPE C (bloc 701 de la Figure 7), puis une représentation (XSD2) est générée sur le dispositif client pour le TYPE C à l'aide du moteur de transformation 111 et des règles de mappage 117 définies pour le TYPE C au niveau du dispositif client (feuilles de style). Tel que représenté dans l'exemple de la Figure 17, une même représentation (XSD2) sera utilisée pour un conteneur non-standard du type TYPE C.
De plus, les règles de transformation 117 peuvent être définies de telle sorte que des attributs d'un même type de tout élément de données soient mappé sur une même sousreprésentation, quel que soit le type de contenu (non-standard ou standard), qui comprend les attributs (dans le fichier de description cible). Dans l'exemple décrit sur la Figure 18, un conteneur standard de type TYPE D comprenant un ensemble d'attributs Al, A2, A3, A4 (tel que défini dans le fichier de description de structure source XSD1) est tout d'abord converti en un conteneur non-standard associé au même type TYPE D (bloc 701 de la Figure 1), puis une représentation XSD2 (fichier de description de structure cible) est générée sur le dispositif client pour le TYPE D à l'aide du moteur de transformation 111, la représentation XSD2 comprenant des attributs de représentation {El, E2, E3, E4} correspondant aux attributs source {Al, A2, A3, A4}. Tel que représenté dans l'exemple de la Figure 19, une même représentation {E2, E3} peut être générée pour les attributs A2, A3 d'un conteneur non-standard d'un autre type TYPE C comprenant l'ensemble d'attributs {Cl, A2, A3, C4}, par application des mêmes règles de mappage 117 pour des attributs similaires d'un fichier de description de structure source XSD. Le moteur de mappage 11 générera une représentation XSD3 = {Fl, E2, E3, F4, F5} avec une même représentation E2 et E3 pour les attributs respectifs A2 et A3.
Le moteur de gestion de contenu 3 fournit donc une plateforme unique à tous les dispositifs clients 7 (associés par exemple à des systèmes d'agences de voyages) comprenant un ensemble d'interfaces par application, par l'intermédiaire desquelles une unique réponse peut être générée indépendamment du type de contenu qui doit être manipulé (par exemple, produit de type Vol GDS, location de véhicule GDS, taxi non GDS, restaurant non GDS, etc.).
Les applications de services peuvent donc utiliser directement une structure de données homogène pour stocker les données dans les interfaces. Cela rend inutile l'échange entre les couches interfaces et les couches BOM d'encore un autre format de la structure de données. Cela permet en outre de réduire le surdébit entre les données stockées dans l'Enregistrement de Voyage étendu 9 et la représentation des données dans les interfaces de services 2 exposées aux dispositifs clients 7 (par exemple, systèmes d'agences de voyages) via une plateforme unique.
Par conséquent, l'unité d'échange de données 11 permet de générer de manière dynamique une représentation cohérente des résultats quel que soit le type de contenu (contenu standard, non-standard, mixte), avec aussi peu de logiciel à codage manuel que possible.
En particulier, le message d'échange de données utilisé pour retourner les résultats au dispositif client 7 a un format proche des structures internes (par exemple, XML) et ce format est hérité des fichiers de description de structure (par exemple, XSD) utilisés pour définir les éléments eux-mêmes dans l'Elément générique.
Le système de gestion de voyages 100 fournit donc un ensemble d'interfaces par service de voyage représentant une réponse unique indépendamment du type de produits qui doit être manipulé (par exemple : produit de transport aérien GDS classique (vol) / location de véhicule GDS / taxi non GDS / restaurant non GDS...).
La Figure 20 décrit un organigramme d'un procédé de réagencement de contenu selon certaines formes de réalisation. Un contenu associé à un identifiant d'enregistrement commun dans l'ETR 9 comprend un ensemble d'éléments de données apparenté à un même voyage. Selon l'application nécessitant un identifiant d'enregistrement particulier dans l'ETR 9, l'application peut nécessiter que les éléments de données différents associés à un repère de dossier donné soient disposés (par exemple, ordonnés) selon des critères de réagencement prédéfinis (par ex. des critères de réordonnancement) lorsqu'ils sont accédés par l'application.
Le procédé de réagencement de contenu peut être implémenté pour réarranger les éléments de données selon des critères de réarrangement prédéfinis par l'application, par exemple selon un ordre chronologique, un critère de rangement, etc. Le procédé de réagencement peut fusionner les éléments de données standard et non-standard en un modèle de rangement abstrait basé sur un élément abstrait. L'élément abstrait peut être utilisé pour trier les éléments de données selon les critères de réagencement. L'application peut donc retourner un élément de données fusionné ordonné selon les contraintes d'interface cible. Il peut en résulter par exemple des documents d'itinéraire agrégés où des segments de PNR et des éléments étendus (contenu non-standard) peuvent être fusionnés dans une même vue.
En particulier, pour chaque élément de données, si l'élément de données est un élément de données non-standard (bloc 801), l'élément de données non-standard du type Ti est transformé en un élément abstrait d'un type unique contenant un sous-ensemble des attributs de l'élément de données non-standard du type Ti dans le bloc 802. Les attributs du conteneur de données non-standard sont filtrés selon des règles de filtrage générées par exemple en fonction des critères de réagencement (par exemple, ordre chronologique, les critères de filtrage sélectionneront des attributs de données). L'élément abstrait peut être implémenté sous la forme d'un objet technique tel qu'un BOM, et peut être basé sur la même technologie que le conteneur de données non-standard et/ou l'élément générique. Il convient d'observer que l'élément générique et l'élément abstrait permettent tous les deux une abstraction du type d'un élément de données.
Si l'élément de données est un élément de données standard (bloc 803) du type Ti, il peut être converti en un conteneur de données non-standard du même type Ti au bloc 804 (de manière similaire à l'étape 604 de la Figure 6).
Au bloc 805, les attributs de l'élément de données non-standard ainsi obtenu sont filtrés selon des critères de filtrage.
Au bloc 806, l'élément de données non-standard obtenu à l'étape 804 est transformé en un élément abstrait contenant l'ensemble filtré d'attributs de l'élément de données nonstandard de type Ti correspondant à l'élément de données standard de type Ti.
De manière similaire à l'élément générique, l'élément abstrait obtenu forme un état transitoire de l'élément de données non-standard, ce qui permet d'abstraire le type de conteneur de données. Cela permet en outre une manipulation globale des attributs d'éléments de données filtrés par l'application, quels que soient leurs types, par inspection du modèle abstrait et en particulier un agencement de ceux-ci en fonction des critères de réagencement.
Dans le champ Voyage, le PNR standard 90 peut être stocké dans une zone de stockage qui est partagée entre une pluralité de systèmes. Les éléments de données standard enregistrés dans le PNR standard 90 peuvent être de différents types et chaque élément peut avoir son propre format de sérialisation. Les éléments de données standard peuvent partager un même identifiant d'enregistrement si les éléments de données sont liés (par exemple, communs à un même passage ou un même itinéraire).
De manière similaire, un élément de données dans le PNR non-standard 91 peut partager un même identifiant d'enregistrement qu'un autre élément de données dans le PNR non-standard 91 ou le PNR standard si les éléments de données sont liés. Le PNR nonstandard 91 peut être stocké dans la même zone de stockage que le PNR standard. D'une autre manière, le PNR standard 90 et le PRN non-standard 91 peuvent être stockés dans des zones de stockage différentes. Les deux zones peuvent être générées par un mécanisme de gestion global afin de permettre une synchronisation de données communes. Le mécanisme de gestion global peut être implémenté pour lier la zone de stockage dédiée au PNR nonstandard 91 à l'autre zone de stockage dédiée au PNR standard 90 à chaque demande qui nécessite de manipuler l'enregistrement de voyage étendu 9 global.
Même si l'ETR 9 est divisé en deux structures de données d'enregistrement 90 et 91, l'ETR 9 peut être géré globalement en fonction des identifiants d'enregistrement communs identifiant des éléments de données apparentés, des données de conteneurs auxiliaires et/ou des informations de structure de données d'enregistrement.
Les données du conteneur de données auxiliaires peuvent comprendre des informations de commande concernant chaque conteneur de données (par exemple, date de création, date de dernière modification, etc.). Dans des approches classiques, de telles informations sont stockées directement dans chaque conteneur de données standard en association avec un identifiant d'enregistrement 0 et peuvent être accédées pour gérer le PNR standard (par exemple pour purger périodiquement le PNR standard). Cependant, cette approche ne permet pas une gestion optimisée des deux structures de données d'enregistrement 90 et 91.
La Figure 21 représente la structure de l'ETR 9 selon certaines formes de réalisation. Tel que représenté, pour optimiser la gestion globale des deux structures de données d'enregistrement 90 et 91, dans une certaine forme de réalisation, l'enregistrement de voyage étendu 9 peut en outre comprendre une structure de données auxiliaires 92 (également appelée "structure de données de gestion centrale" ou "zone de gestion centrale") pour l'enregistrement de données de conteneur auxiliaires apparentées à chaque conteneur de données créé dans l'ETR 9, telles que la date de création d'un conteneur de données, la date de dernière modification d'un conteneur de données, etc. Les informations enregistrées dans la structure de données auxiliaires 92 peuvent être utilisées pour gérer les deux zones d'une manière synchrone. Chaque entrée de la structure de données auxiliaires 92 peut partager les mêmes identifiants d'enregistrement sous la forme de conteneurs de données créés dans l'ETR 9. En outre, chaque enregistrement de la structure de données auxiliaires 92 peut être associé à un ensemble de données de conteneur auxiliaires apparentées aux conteneurs de données enregistrés dans l'ETR 9 (ayant le même identifiant d'enregistrement). La structure de données auxiliaires 92 peut être remplie d'informations de conteneur de données contenues dans la structure de données d'enregistrement standard 90 et la structure de données d'enregistrement non-standard 91.
Dans certaines formes de réalisation, chaque entrée de la structure de données auxiliaires 92 peut comprendre l'ensemble d'attributs auxiliaires apparentés aux conteneurs de données partageant le même identifiant d'enregistrement dans la structure de données d'enregistrement étendue (9). Chaque entrée peut comprendre un conteneur de données auxiliaire pour le stockage de l'ensemble de données de conteneur auxiliaires apparentées aux enregistrements de l'ETR 9 partageant le même identifiant d'enregistrement. L'ensemble de données de conteneur auxiliaires peut comprendre des attributs de commande représentant des informations de commande relatives aux enregistrements de l'ETR 9 partageant le même identifiant d'enregistrement, tels que la date précédente de purge de l'enregistrement.
Dans certaines formes de réalisation, les informations de conteneur de données relatives à tous les enregistrements d'une structure de données d'enregistrement donnée 90 ou 91 peuvent être enregistrées dans un enregistrement dédié (également appelé "enregistrement d'informations de conteneur") dans cette structure de données d'enregistrement (90 ou 91) et se voir assigner un identifiant d'enregistrement particulier (par exemple, identifiant d'enregistrement 0). L'enregistrement d'informations de conteneur de la structure de données d'enregistrement standard 90 et/ou l'enregistrement d'informations de conteneur de la structure de données d'enregistrement non-standard 91 peuvent être copiés dans la structure de données non auxiliaires 92 à des intervalles de temps différents, par exemple périodiquement ou en réponse à une demande ou, d'une autre manière, à chaque fois que l'ETR 9 est sauvegardé dans la ou les bases de données 8.
La structure de données auxiliaires 92 peut en outre enregistrer des informations de structure de données d'enregistrement relatives à la structure de données d'enregistrement standard et/ou à la structure de données d'enregistrement non-standard, telles que des informations de version identifiant la dernière version de la structure de données d'enregistrement standard 90 et de la structure de données d'enregistrement non-standard 91 dans les bases de données.
Le système de gestion de voyages 100 peut comprendre une unité de commande d'ETR 18 pour gérer l'ETR 9 en fonction des données comprises dans la structure de données auxiliaires 92 (informations de données de conteneur auxiliaires et/ou les informations de structure de données d'enregistrement standard 90 et/ou les informations de structure de données d'enregistrement non-standard 91).
Dans une forme de réalisation, l'unité de commande d'ETR 18 peut comprendre un module de purge 180 configuré pour purger périodiquement des enregistrements du PNR standard 90 et du PNR non-standard 91 de manière synchrone pour des données communes, à l'aide d'identifiants d'enregistrement communs, les données de conteneur auxiliaires étant enregistrées dans la structure de données auxiliaires 92 et/ou les informations de structure de données d'enregistrement.
Dans certaines formes de réalisation, l'unité de commande d'ETR 18 peut comprendre un gestionnaire d'accès 181 pour traiter simultanément un accès à un même identifiant d'enregistrement dans le PNR standard 90 et dans le PNR non-standard 91 en fonction des données enregistrées dans la structure de données auxiliaires 92. Dans cette forme de réalisation, la structure de données auxiliaires peut en outre enregistrer des informations de version identifiant la dernière version de la structure de données d'enregistrement standard 90 et de la structure de données d'enregistrement non-standard 91 dans les bases de données 8. Par exemple, à chaque fois que l'ETR 9 est sauvegardé dans la base de données à partir du contexte, les informations de version sont mises à jour dans la structure de données auxiliaires 92. Le gestionnaire d'accès 18 peut être configuré pour gérer l'accès à l'ETR 9 en fonction des informations de version enregistrées dans la structure de données auxiliaires 92.
Le code programme selon l'une quelconque des formes de réalisation de l'invention décrites ici peut être distribué sur une base individuelle ou collective sous la forme d'un produit de programme se présentant sous toute une variété de formes différentes. En particulier, le code programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports de communication. Les supports de stockage lisibles par ordinateur, qui sont par nature non transitoires, peuvent inclure des supports tangibles volatiles et non volatiles, et amovibles et non amovibles, implémentés selon une quelconque méthode ou technologie pour le stockage d'informations, telles que des instructions lisibles par ordinateur, des structures de données, des modules de programmes, ou d'autres données. Les supports de stockage lisibles par ordinateur peuvent inclure une RAM, une ROM, une mémoire morte programmable et effaçable (EPROM), une mémoire morte électriquement programmable et effaçable (EEPROM), une mémoire flash ou une autre technologie de mémoire à semi-conducteurs, une mémoire morte à disque compact portable (CD-ROM), ou un autre stockage optique, des cassettes magnétiques, une bande magnétique, un stockage par disque magnétique ou d'autres dispositifs de stockage magnétiques, ou tout autre support qui peut être utilisé pour stocker les informations souhaitées et qui peut être lu par un ordinateur. Les supports de communication peuvent mettre en œuvre des instructions lisibles par ordinateur, des structures de données, ou d'autres modules de programmes. A titre d'exemple, et sans limitation, des supports de communication peuvent inclure des supports Glaires tels qu'un réseau Glaire ou une connexion Glaire directe, et des supports sans G1 tels que des supports sans G1 acoustiques, RF, infrarouge et autres. Toutes combinaisons de ce qui précède sont également incluses dans le cadre de supports lisibles par ordinateur.
Les procédés décrits dans le présent document peuvent être implémentés par des instructions de programme informatique fournies au processeur d'un quelconque type d'ordinateur pour produire une machine ayant un processeur qui exécute les instructions pour implémenter les fonctions/actes spéciGés dans le présent document. Ces instructions de programme informatique peuvent également être stockées dans un support lisible par ordinateur qui peut diriger un ordinateur aGn qu'il fonctionne d'une manière particulière. A cette Gn, les instructions de programme informatique peuvent être chargées sur un ordinateur pour provoquer l'exécution d'une série d'étapes fonctionnelles et ainsi produire un procédé implémenté par ordinateur de telle sorte que les instructions exécutées fournissent des procédés pour l'implémentation des fonctions/actes spéciGés dans le présent document.
Bien que des formes de réalisation de l'invention aient été illustrées par une description de différents exemples, et bien que ces formes de réalisation aient été décrites d'une manière très détaillée, il n'est pas dans l'intention de la demanderesse de restreindre ou limiter d'une quelconque manière à ces détails le cadre des revendications jointes. Des avantages et modifications additionnels apparaîtront de manière évidente à l'homme du métier. L'invention, prise dans ses aspects les plus larges, n'est donc pas limitée aux détails spéciGques, aux procédés représentatifs, et aux exemples illustratifs présentés et décrits. En particulier, bien que l'élément abstrait ait été décrit pour le réagencement de contenu, il peut être utilisé d'une manière générale par les applications internes pour l'accès à un contenu pour différentes sortes d'opérations. Les règles de filtrage appliquées pour Gltrer les attributs d'un conteneur de données peuvent varier en fonction des opérations prévues.
Claims (9)
- REVENDICATIONS1. Procédé de gestion d'une structure de données d'enregistrement étendue (9) dans un système de gestion de contenu (100), ladite structure de données d’enregistrement comprenant une structure de données d’enregistrement standard (90) pour le stockage d’enregistrements comprenant des éléments de données standard prédéfinis de types standard sous la forme de conteneurs de données standard et une structure de données d’enregistrement non-standard (91) pour le stockage d'enregistrements comprenant des éléments de données non-standard de types différents desdits types standards prédéfinis sous la forme de conteneurs de données non-standard, chaque enregistrement dans ladite structure de données d'enregistrement étendue (9) comprenant un identifiant d'enregistrement, les enregistrements correspondant à des éléments de données associés dans la structure de données d'enregistrement étendue (9) partageant un identifiant d'enregistrement commun, le procédé comprenant, pour chaque enregistrement créé dans la structure de données d'enregistrement étendue (9) pour un élément de données ayant un identifiant d'enregistrement donné, la création d'une entrée dans une structure de données auxiliaire (92), ladite entrée partageant ledit identifiant d'enregistrement donné et comprenant un conteneur de données auxiliaire, ledit conteneur de données auxiliaire comprenant un ensemble d'attributs associés aux conteneurs de données partageant le même identifiant d'enregistrement dans la structure de données d'enregistrement, le procédé gérant ladite structure de données d'enregistrement étendue (9) sur la base des données maintenues dans la structure de données auxiliaire (92).
- 2. Procédé selon la revendication 1, comprenant la mise à jour de la structure de données auxiliaire (92) en réponse à la sauvegarde de la structure de données d'enregistrement étendue dans une base de données (8).
- 3. Procédé selon l'une quelconque des revendications précédentes, dans lequel la structure de données d'enregistrement étendue (9) est sauvegardée dans une base de données (8) à différents intervalles de temps, et le procédé comprenant l’étape consistant à purger périodiquement des enregistrements de la structure de données d'enregistrement étendue maintenue dans ladite base de données sur la base des attributs des conteneurs de données maintenus dans la structure de données d'enregistrement auxiliaire (92).
- 4. Procédé selon la revendication 3, dans lequel chaque conteneur de données auxiliaire partageant un identifiant d'enregistrement donné comprend des attributs de commande représentant des informations de commande associées à l'enregistrement de la structure de1. Procédé de gestion d'une structure de données d'enregistrement étendue (9) dans un système de gestion de contenu (100), ladite structure de données d’enregistrement comprenant une structure de données d’enregistrement standard (90) pour le stockage d’enregistrements comprenant des éléments de données standard prédéfinis de types standard sous la forme de conteneurs de données standard et une structure de données d’enregistrement non-standard (91) pour le stockage d'enregistrements comprenant des éléments de données non-standard de types différents desdits types standards prédéfinis sous la forme de conteneurs de données non-standard, chaque enregistrement dans ladite structure de données d'enregistrement étendue (9) comprenant un identifiant d'enregistrement, les enregistrements correspondant à des éléments de données associés dans la structure de données d'enregistrement étendue (9) partageant un identifiant d'enregistrement commun, le procédé comprenant, pour chaque enregistrement créé dans la structure de données d'enregistrement étendue (9) pour un élément de données ayant un identifiant d'enregistrement donné, la création d'une entrée dans une structure de données auxiliaire (92), ladite entrée partageant ledit identifiant d'enregistrement donné et comprenant un conteneur de données auxiliaire, ledit conteneur de données auxiliaire comprenant un ensemble d'attributs associés aux conteneurs de données partageant le même identifiant d'enregistrement dans la structure de données d'enregistrement, le procédé gérant ladite structure de données d'enregistrement étendue (9) sur la base des données maintenues dans la structure de données auxiliaire (92).2. Procédé selon la revendication 1, comprenant la mise à jour de la structure de données auxiliaire (92) en réponse à la sauvegarde de la structure de données d'enregistrement étendue dans une base de données (8).3. Procédé selon l'une quelconque des revendications précédentes, dans lequel la structure de données d'enregistrement étendue (9) est sauvegardée dans une base de données (8) à différents intervalles de temps, et le procédé comprenant l’étape consistant à purger périodiquement des enregistrements de la structure de données d'enregistrement étendue maintenue dans ladite base de données sur la base des attributs des conteneurs de données maintenus dans la structure de données d'enregistrement auxiliaire (92).4. Procédé selon la revendication 3, dans lequel chaque conteneur de données auxiliaire partageant un identifiant d'enregistrement donné comprend des attributs de commande représentant des informations de commande associées à l'enregistrement de la structure de 5 0 5 0 5 0 données d'enregistrement étendue (9) partageant le même identifiant d'enregistrement.
- 5. Procédé selon la revendication 4, dans lequel lesdits attributs de commande comprennent la date de purge d'un enregistrement dans la structure de données étendue (9) partageant le même identifiant d'enregistrement.
- 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite structure de données auxiliaire (92) comprend en outre des informations de structure de données d'enregistrement associées à la structure de données d'enregistrement standard et à la structure de données non-standard.
- 7. Procédé selon la revendication 6, dans lequel les informations de structure de données d'enregistrement comprennent des informations de version identifiant la dernière version de la structure de données d'enregistrement standard (9) et de la structure de données nonstandard dans ladite au moins une base de données.
- 8. Procédé selon la revendication 7, comprenant la gestion de l'accès à la structure de données d'enregistrement étendue sur la base desdites informations de version.
- 9. Système de gestion d'une structure de données d'enregistrement étendue (9) dans un système de gestion de contenu (100), ladite structure de données d'enregistrement comprenant une structure de données d'enregistrement standard (90) pour stocker des enregistrements comprenant des éléments de données standard de types standard prédéfinis sous la forme de conteneurs de données standard et une structure de données d'enregistrement non-standard (91) pour stocker des enregistrements comprenant des éléments de données non-standard ayant des types différents desdits types standard prédéfinis sous la forme de conteneurs de données non-standard, chaque enregistrement dans ladite structure de données d’enregistrement étendue (9) comprenant un identifiant d’enregistrement, les enregistrements correspondant à des éléments de données associés dans la structure de données d’enregistrement étendue (9) partageant un identifiant d’enregistrement commun, le système de gestion de la structure de données d’enregistrement étendue étant configuré pour créer une entrée dans une structure de données auxiliaire (92), pour chaque enregistrement créé dans la structure de données d'enregistrement étendue (9) pour un élément de données ayant un identifiant d'enregistrement donné, ladite entrée dans la structure de données auxiliaire (92) partageant ledit identifiant d'enregistrement donné et comprenant un conteneur de données auxiliaire, ledit conteneur de données auxiliaire comprenant un ensemble d'attributs associés aux conteneurs de données partageant le même identifiant d'enregistrement dans la structure de données d'enregistrement, le système étant en outre configuré pour gérer ladite structure de données d'enregistrement étendue (9) sur la base des données maintenues dans la structure de données auxiliaire (92).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/291,758 US9367563B2 (en) | 2014-05-30 | 2014-05-30 | Managing records in a travel management system |
| EP14305813.9A EP2950225B1 (fr) | 2014-05-30 | 2014-05-30 | Procédé et système permettant de gérer une structure de données d'enregistrement |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3021789A1 true FR3021789A1 (fr) | 2015-12-04 |
Family
ID=54544809
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1554341A Pending FR3021789A1 (fr) | 2014-05-30 | 2015-05-13 |
Country Status (4)
| Country | Link |
|---|---|
| JP (1) | JP6559469B2 (fr) |
| KR (1) | KR101695544B1 (fr) |
| CN (1) | CN105303287B (fr) |
| FR (1) | FR3021789A1 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3049366A1 (fr) * | 2016-03-24 | 2017-09-29 | Amadeus Sas | Systeme de traitement de transactions en ligne pour des transactions impliquant de multiples produits |
| US10402877B2 (en) | 2016-03-24 | 2019-09-03 | Amadeus S.A.S. | Online transaction processing system for multi-product transactions |
| US10803459B2 (en) | 2016-03-24 | 2020-10-13 | Amadeus S.A.S. | Online transaction processing system for multi-product transactions |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3586301B1 (fr) * | 2017-02-21 | 2024-05-29 | Amadeus S.A.S. | Gestion de données non standard dans un système de gestion de données |
| CN110166494A (zh) * | 2019-07-04 | 2019-08-23 | 四川长虹电器股份有限公司 | 一种远程监控系统中设备复合运行状态的记录方法 |
| CN111260477B (zh) * | 2019-12-02 | 2023-07-25 | 泰康保险集团股份有限公司 | 一种产品对象数据信息的写入、读取方法及处理系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070260495A1 (en) * | 2005-10-21 | 2007-11-08 | Scott Mace | Software Architecture and Database for Integrated Travel Itinerary and Related Reservation System Components |
| EP2509035A1 (fr) * | 2011-04-05 | 2012-10-10 | Amadeus S.A.S. | Procédé de réservation et système avec gestion PNR améliorée |
| US20120278334A1 (en) * | 2011-04-29 | 2012-11-01 | John Abjanic | Database System |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000148548A (ja) * | 1998-11-17 | 2000-05-30 | Nec Corp | 不要レコード削除装置 |
| CN1407453A (zh) * | 2001-08-29 | 2003-04-02 | 南宁美狐高科技有限公司 | 旅游线路数据对象的组织关联方法 |
| JP2005352634A (ja) * | 2004-06-09 | 2005-12-22 | Hidenori So | Ｘｍｌを用いた分散データ処理システム |
| US20070083380A1 (en) * | 2005-10-10 | 2007-04-12 | Yahoo! Inc. | Data container and set of metadata for association with a media item and composite media items |
| JP5483561B2 (ja) * | 2010-02-25 | 2014-05-07 | 楽天株式会社 | ストレージ装置、サーバ装置、ストレージシステム、データベース装置、データの提供方法、及び、プログラム |
-
2015
- 2015-05-13 FR FR1554341A patent/FR3021789A1/fr active Pending
- 2015-05-29 JP JP2015109768A patent/JP6559469B2/ja active Active
- 2015-05-29 KR KR1020150076600A patent/KR101695544B1/ko active IP Right Grant
- 2015-05-29 CN CN201510284799.6A patent/CN105303287B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070260495A1 (en) * | 2005-10-21 | 2007-11-08 | Scott Mace | Software Architecture and Database for Integrated Travel Itinerary and Related Reservation System Components |
| EP2509035A1 (fr) * | 2011-04-05 | 2012-10-10 | Amadeus S.A.S. | Procédé de réservation et système avec gestion PNR améliorée |
| US20120259667A1 (en) | 2011-04-05 | 2012-10-11 | Marc Pelissier | Reservation method and system with improved pnr handling |
| US20120278334A1 (en) * | 2011-04-29 | 2012-11-01 | John Abjanic | Database System |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3049366A1 (fr) * | 2016-03-24 | 2017-09-29 | Amadeus Sas | Systeme de traitement de transactions en ligne pour des transactions impliquant de multiples produits |
| US10402877B2 (en) | 2016-03-24 | 2019-09-03 | Amadeus S.A.S. | Online transaction processing system for multi-product transactions |
| US10803459B2 (en) | 2016-03-24 | 2020-10-13 | Amadeus S.A.S. | Online transaction processing system for multi-product transactions |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105303287B (zh) | 2018-04-10 |
| JP2016006642A (ja) | 2016-01-14 |
| JP6559469B2 (ja) | 2019-08-14 |
| KR101695544B1 (ko) | 2017-01-11 |
| CN105303287A (zh) | 2016-02-03 |
| KR20150138823A (ko) | 2015-12-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR3021788A1 (fr) | ||
| FR3021790A1 (fr) | ||
| US9367563B2 (en) | Managing records in a travel management system | |
| FR3021789A1 (fr) | ||
| KR101753451B1 (ko) | Pnr 취급이 개선된 예약 방법 및 시스템 | |
| Dunning et al. | Streaming architecture: new designs using Apache Kafka and MapR streams | |
| US11113637B2 (en) | Content exchange with a travel management system | |
| US10891279B2 (en) | Content management in a travel management system | |
| FR3021787A1 (fr) | ||
| US9619568B2 (en) | Content access in a travel management system | |
| EP2950246A1 (fr) | Procédé et système d'échange de contenu | |
| FR3062228A1 (fr) | Base de donnees agregative d'enregistrements contexte | |
| EP2950225B1 (fr) | Procédé et système permettant de gérer une structure de données d'enregistrement | |
| EP2950245A1 (fr) | Procédé et système d'accès de contenu | |
| EP2950244A1 (fr) | Système de gestion de contenu |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210917 |
|
| RX | Complete rejection |
Effective date: 20220720 |