1. Comité Technique et fonctionnel
Le 8 Décembre 2011
Interventions, PAC, notifications

2. Plan
• Les notifications
 Ecotour  les besoins des distributeurs
 Pierre et Vacances  les besoins des fournisseurs
• Le PAC
 Usage
 Qui s’en sert ?
 Les avantages
 Les évolutions possibles
 Les solutions possibles
• Bilan
 L’avenir du PAC
L’avenir des notifications

3. Notifications XFT
Les besoins des distributeurs
Axes possibles d'évolution selon les besoins distributeurs

4. Constats sur la brochure
• Un devis est plus élevé que le prix annoncé
• Une date est complète à la cotation
  Client perdu
• La communication entre services
"production" cotés Distributeur et TO est
parfois difficile à cause des délais de 1 jour
entre les générations.
• Monter une opération spéciale sur une durée
courte est compliquée.

5. Constats sur le service client
• Système actuel de notifications
 les emails
• Inconvénients :
 Délais de traitement
 Travail manuel récurrent
 Erreurs possibles
 Compliqué si volume important
 Pas d'accusé réception

6. Notifications pour la brochure
• Sur les prix
 Date(s) complète(s)
 Une date passe de Stock -> request
 Modification du prix
 Nouvelles dates disponibles
• => Envoi d'un ensemble de prix avec
stock/request/full
• Sur le produit :
 Stopsale
 Nouveau produit disponible
 Descriptif CETO modifié

7. Gestion de dossier
• Emails échangés
 Hausse carburant
 Convocation
 Modification d'horaires
 Demande d'informations passeports
 Retard de vol
 Changement de statut (Request -> Confirm)
 Informations à destination du client (liste
des hôtels du circuit, etc., vol annulé, etc.)
 Régulations
 Nouvelle pièce comptable disponible : Avoir et facture
(A chaque modification tarifaire du dossier)

8. Notifications distributeur vers TO
• Produit reçu
• Produit disparu (plus de prix)
• Produit en ligne
• Produit hors ligne
• Fichier prix intégré
• Fichier ceto intégré
• Avis du client
 Informations marketing (mises en avant)
 Changement de position moteur de recherche par
destination et par prix

9. Notifications
Les réponses des fournisseurs

10. La problématique de Pierre et Vacances
• Plusieurs systèmes de réservation (3)
- Ancien système (BBOSS)
- Nouveau système (LEXO)
- Système Center Parcs
• Chaque système est maître des stocks et des prix
des produits qu’il vend
• Nos fichier de caches de disponibilités et de prix
regroupent des produits des 3 systèmes
  Cette complexité doit être transparente pour nos
partenaires

11. Les solutions possibles

12. L’implémentation en XFT
• Implémentation XFT
• Action :
<Action Code="Notification" Purpose="Send"/>
• Requester :
<Requester Code="PV" Channel="Intranet">
<Host Name="LEXO"/>
<Requester Channel="Internet" Code="PV">
<Country Code="GB"/>
</Requester>
</Requester>

13. L’implémentation XFT
• XFT implementation :
 l’emplacement du fichier
 le type de contenu
 les dates des produits
<Trip>
<Segments Name="PrixDispo" What="List">
<Description Role="URI" Type="File">
<Media Type="CSV">
<URL Channel="Intranet">http://…/cache.zip</URL>
</Media>
</Description>
<Segment xsi:type="SegmentProductType"/>
</Segments>
<Begin Value="2011-11-01"/>
<End Value="2012-10-31"/>
</Trip>

14. Les améliorations
• Améliorations
 Dissossier l’emmetteur de la notification
(Requester) du contexte du cache lui-
même (Requester/Requester)
 Notifications différentielles
- Gestion d’évènements en quasi temps réel
- Mises à jour ciblés

15. Les améliorations
• Requester
 L’emmetteur de la notification :
<Control>
<Requester Channel="Intranet" Code="PV">
<Host Name="LEXO"/>
</Requester>
</Control>
• Le destinataire des données
<Entities Name="PrixDispo">
…
<Rule Role="SellingConditions
<Requester Channel="Internet" Code="PV">
<Country Code="GB"/>
</Requester>
</Rule>
</Entities>

16. Les améliorations
•Notifications différentielles
 Utilisation de Tasks et de blocs
<Action Code="Notification" Purpose="Send">
<Tasks><Task …/></Tasks>
</Action>
•Ajout:
<Task Purpose="Add"><Entity Ref="_ID.ADD_"/></Task>
•Mise à jour :
<Task Purpose="Update"><Entity Ref="_ID.UPDATE_"/></Task>
•Suppression
<Task Purpose="Delete"><Entity Ref="_ID.DELETE_"/></Task>

17. Les améliorations
•Bloc ajout
Pour ajouter de nouveaux produits
Pour ajouter de nouvelles dates à un produit existant
<Entity ID="_ID.ADD_" Is="Product" Name="PrixDispo">
<Description Role="URI" Type="File">
<Media Type="CSV">
<URL Channel="Intranet“>![CDATA[http://xxx/cache.zip]]></URL>
</Media>
</Description>
<Begin>
<Between Begin="2012-12-01" End="2012-12-31"/>
</Begin>
</Entity>

18. Les améliorations
• Bloc mise à jour
Pour modifier le prix ou la disponibilité de produits existants
Clé d’identification : code, date, durée
<Entity ID="_ID. UPDATE_" Is="Product" Name="PrixDispo">
<Description Role="URI" Type="File">
<Media Type="CSV">
<URL Channel="Intranet“>![CDATA[http://xxx/cache.zip]]></URL>
</Media>
</Description>
<Begin>
<Between Begin="2012-12-01" End="2012-12-31"/>
</Begin>
</Entity>

19. Les améliorations
•Bloc suppression
Supprimer un ensemble de produits (par codes)
Supprimer un ensemble de dates (par intervalles)
Supprimer un ensemble de produits pour certaines dates
<Entity ID="_ID. DELETE_" Is="Product" Name="PrixDispo">
<Codes Role="Product">
<Code Value="_ProductCode_"/>
<Code Value="_ProductCode_"/>
<Code Value="_ProductCode_"/>
</Codes>
<Begin>
<Betweens>
<Between Begin="2012-01-01" End="2012-01-31"/>
<Between Begin="2012-03-01" End="2012-03-15"/>
</Betweens>
</Begin>
</Entity>

20. Les améliorations
•Contenu des données prix dispo
Plusieurs possibilités
- Csv distant (HTTP / FTP)
- Csv inclus
<Description Role="Body" Type="CSV">
<![CDATA[CSV Data present here]]>
</Description>
- PAC distant (HTTP / FTP)
- PAC inclus ?
- Zippé

21. Structure des messages
• Evénement générique "Dossier modifié".
 Le distributeur effectue alors une action "GetBooking“
  Non répudiation
• ou
 Convocation disponible
 Convocation modifiée
 Dossier annulé
 ...
• Avantages des messages spécifiques
 Possibilité de demander une confirmation au distributeur
• Inconvénient
 + Compliqué. Pas de rattrapage si un message est
manqué

22. Notifications
Les nouveaux principes de synchronisation

23. « Aviser un distributeur unique »

24. Aviser un distributeur unique : étape 1
On notifie une émission
ou une création de
dossier, de document …
Fournisseur
Le fournisseur
envoie une
notification au
distributeur Le distributeur
comprend que
le fournisseur
a envoyé une
notification
Distributeur
Vérification que l’information a été modifiée

25. Aviser un distributeur unique : étape 2
La distributeur récupère les données auprès du
La donnée peut être
fournisseur.
un fichier, un
F Document, un statut
…
Fournisseur
… tout ce qui est
relatif à
Get_Booking
la donnée modifiée
ou
FTP
Get_Document
Distributeur
Le distributeur récupère une donnée modifiée sous
forme de transaction, de FTP …

26. « La mise en œuvre du format »

27. La mise en œuvre possible …
La génération du contenu est
testé via une interrogation
depuis le FTP
Dépôt des nouvelles notifications dans le répertoire
Fournisseur
Interrogation Interrogation
avec retour avec retour
sans rien sans rien
Répertoire FTP
Interrogation
avec retour …et
récupération
des notifications
Distributeur
Interrogation régulière des
notifications sur le répertoire
Cela permet de vérifier que le fournisseur sait générer des notifications.
Cette phase est inutile s’il est impossible de consommer les Web services

28. La mise en œuvre possible : étape 1
Le fournisseur génère le
contenu et avise le
distributeur
Fournisseur
Le fournisseur
envoie une
notification au
distributeur Le distributeur
comprend
que le fournisseur
a notifié quelque
chose
Distributeur
Récupartion transactionnelle de la notification

29. La mise en œuvre possible : étape 2
La distributeur récupère
les données auprès du
fournisseur F
Fournisseur
Récupération de la
donnée modifiée en
XFT
Distributeur
Le distributeur récupère une donnée modifiée

30. « Aviser plusieurs distributeurs »

31. Aviser plusieurs distributeurs
Le fournisseur génère le contenu et
Le fournisseur envoie les
avise plusieurs distributeurs notifications à plusieurs
distributeurs
Fournisseur
Distributeur 1 Distributeur 2 Distributeur 3 Distribueur 4
Les distributeurs
comprennent qu’une
notificationa été envoyée
Le fournisseur peut faire des envois multiples

32. Aviser plusieurs distributeurs
Les distributeurs récupèrent ensuite
les données auprès du fournisseur
F
Fournisseur
Transaction Transaction Transaction Transaction
Distributeur 1 Distributeur 2 Distributeur 3 Distributeur 4
Les distributeurs récupèrent une info modifiée sous forme de transaction XFT ou de FTP

33. Le PAC
De
nouveaux
De nouveaux enjeux pour une
standardisation enjeux
pour une
standardis
ation

34. La Pac  USAGE
fournisseurs
Producteur Producteur Producteur Producteur
A B C …
XFT Catalogue XFT Catalogue XFT Catalogue XFT Catalogue
XFT Cache XFT Caches XFT Cache XFT Cache
XFT Promos XFT Promos XFT Promos
Distributeurs / Consolidateurs
La base de produits est
Cache Les exports sont
alimentée par l’intermédiaire
associés à des fichiers de
Produit d’exports de la part des
caches établis au standard XFT
fournisseurs, au format CETO…
Utilisateur
final

35. La PAC  Qui s’en sert ?  La génération
• Les fournisseurs  Nouvelles frontières
 Asia  Pierre et Vacances
 Cabinet Chaubet  Présence assistance
 Crystal TO Italowcost tourisme
 Donatello  Siriona
 La France du Nord au  Thomas Cook
Sud  Transat France
 Fram  Voyageurs du Monde
 Kuoni
 Luxair Tour
 Marmara

36. LA PAC  Qui s’en sert ?  L’utilisation
• Les distributeurs
 AS voyages,
 Atout France
 Carrefour Voyages
 Ctoutvert
 Leclerc Voyages
 Ecotour – RPC Voyages
 Prêt à Partir
 Selectour

37. PAC  Les avantages
• Les avantages
 Simplicité d’implémentation
 Possibilité d’optimisations
 Structure identique utilisée par tous
 Très utilisé
 Améliore les performances des distributeurs
• L’information est accessible au même endroit

38. Le PAC  les inconvénients
• Inconvénients  Il taxe des systèmes
 La taille des fichiers fournisseurs
 L’aspect non ciblé de  La PAC n’est pas adapté
la mise à jour (annule aux produits flexibles ni
et remplace) aux packages
 Déclinaisons du fichier dynamiques
(enrichissement non  Le rafraichissement doit
uniforme)
être plus régulier
 N’ empêche pas qu’avant compte tenu du
l’utilisation de robot
pour requêter la fait que les tarifs et les
disponibilité disponibilités évoluent
 Il ne couvre pas plus vite qu’avant
l’intégralité des • 3/J  5/j  le poids
besoins des est une inconvénient
distributeurs

39. Le PAC  Quelles évolutions possibles ?
• Aujourd’hui
 Un PAC et prix promo par catalogue
Producteur Producteur Producteur Producteur
A B C D
XFT Catalogue XFT Catalogue XFT Catalogue XFT Catalogue
XFT Promos XFT Promos XFT Promos XFT Promos
XFT Cache XFT Cache XFT Cache
XFT Cache

40. Le PAC  Quelles évolutions ?
 Qu’est -ce qu’on enlève ?
 Qu’est-ce qu’on rajoute ?
 Faut-il rajout er des nouvelles transactions afin de
mieux répondre aux besoins des distributeurs ?
 Faut il limiter la taille du PAC ?
 Faut-il créer une nouvelle structure pour les produits
?
 Faut-il créer un PAC/produit et non plus un
PAC/catalogue ?
• Ça signifierait qu’une fois le PAC mis à jour, des
notifications sur les modifications apportées au produit
pourraient être envoyées

41. Le PAC  Les évolutions possibles
• La standardisation du catalogue doit elle-
nous amener à standardiser le PAC ?
 Dans le PAC, le contenu est très technique.
Par conséquent, il existe une grande
cohérence de structure entre les différents
PAC
 3 déclinaisons sont possibles
• Même prix sur plage de date
• Même sur une période
• Prix et date seuls

42. Les solutions possibles
• Quelles solutions ?
 Chaque système :tient à jour son propre
“cache”
 Un module central est responsable de la
fusion des différents cache en un cache
unique “groupe”
 Mise à jour du cache central par notifications
XFT
 Mise à disposition des caches fusionnés aux
partenaires à heure fixe