Dossier aérien et émission
Travelport TripServices : session, réservation et émission
Une session de travail rassemble les éléments du dossier. Le résultat du commit dépend du flux exécuté : il faut identifier ce qui est réservé et ce qui est effectivement émis.
Sources consultées le · Méthode éditoriale de Performance Voyage
Quel rôle dans votre organisation ?
Demandez un parcours dont le résultat attendu est précisément décrit : réservation en attente d’émission ou billet émis. Gardez les références de session, de voyageurs, d’offre et de réservation dans leur périmètre. Une session préparée peut être complète sans que le commit ait été exécuté ; une référence de réservation ne suffit pas à prouver un billet utilisable.
Travelport TripServices figure dans la famille Air et NDC. Les prix, pays couverts, niveaux de service et droits du compte ne sont pas certifiés par ce dossier. Faites-les préciser dans une proposition datée.
Source officielle de l’entrée ↗ · Retrouver la fiche du répertoire
Ce que les sources documentent
Travelport : Flights Booking Guide
Le flux minimal de réservation crée un workbench, ajoute un voyageur et une offre, puis le commit. Selon le workbench, le commit peut réserver, émettre ou mettre à jour un dossier.
Consulter la source 1 ↗La suite propose nos contrôles de sélection : elle ne décrit pas des tests exécutés sur un compte fournisseur. Une documentation peut évoluer ; relisez la version applicable avant de développer ou de signer.
Quatre ensembles de données à rapprocher
| Ensemble | À collecter | Contrôle proposé |
|---|---|---|
| Session | Workbench et étape courante | Savoir si le dossier est préparé ou enregistré. |
| Voyageurs | Identifiants et données requises | Rapprocher chaque personne des segments et services. |
| Offre | Référence et conditions retenues | Éviter un assemblage provenant de recherches différentes. |
| Résultat | Réservation, billets et états observés | Prouver séparément réservation et émission. |
Conservez identifiant, source, date et résultat dans le registre de comparaison. Travaillez avec des données anonymisées et les accès de test autorisés.
Un scénario à faire rejouer pendant le pilote
Dans le périmètre de test autorisé, faites produire une réservation puis montrez le résultat d’émission prévu par votre montage. Demandez un cas avec réponse de commit perdue et la procédure pour retrouver le dossier. Ajoutez une modification d’un seul voyageur ou service si cette opération est ouverte sur le contenu concerné.
Les étapes préparatoires et les effets du commit sont lisibles dans la preuve. Le support distingue session, réservation et titre émis ; un retour ambigu déclenche une consultation d’état ou une escalade.
Préparez les mêmes exemples pour les autres acteurs de la catégorie Air et NDC. Comparez les responsabilités et les preuves sur votre tâche, avec la grille d’évaluation et le coût complet.
Erreurs à éviter dans la comparaison
- Présenter une session ouverte comme un billet.
- Supposer des fonctions d’après-vente identiques pour tout contenu.
- Répéter un commit sans contrôler le résultat de la première demande.
Marquez un point non démontré comme « à confirmer ». Il reste distinct d’un échec observé et d’une fonction annoncée. Une décision fiable peut retenir un périmètre plus restreint si les responsabilités et la reprise sont maîtrisées.
Questions fréquentes
Le commit émet-il toujours un billet ?
Non. Le guide décrit plusieurs effets selon le workbench et le flux. Définissez le résultat attendu et vérifiez les objets retournés.
Quel cas doit être testé en plus du parcours normal ?
Une réponse manquante après une opération qui peut avoir créé ou modifié le dossier, puis la procédure pour retrouver son état.
GDS et NDC ont-ils le même après-vente ?
Faites confirmer les capacités ouvertes pour le contenu et le compte. La présence dans une recherche ne valide pas toutes les opérations.