Comité Technique et fonctionnel

Le 8 Décembre 2011

Interventions, PAC, notifications

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

Notifications XFTLes besoins des distributeurs

Axes possibles d'évolution selon les besoins distributeurs

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.

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

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é

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)

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

NotificationsLes réponses des fournisseurs

• 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

La problématique de Pierre et Vacances

Les solutions possibles

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>

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>

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

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>

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>

Les améliorations

•Bloc ajoutPour ajouter de nouveaux produitsPour 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>

Les améliorations

• Bloc mise à jourPour modifier le prix ou la disponibilité de produits existantsClé 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>

Les améliorations

•Bloc suppressionSupprimer 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>

Les améliorations

•Contenu des données prix dispoPlusieurs 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é

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é

NotificationsLes nouveaux principes de synchronisation

« Aviser un distributeur unique »

Aviser un distributeur unique : étape 1

Fournisseur

Distributeur

Le distributeur comprend que le fournisseur a envoyé une notification

Le fournisseur envoie une notification au distributeur

Vérification que l’information a été modifiée

On notifie une émission ou une création de dossier, de document …

Aviser un distributeur unique : étape 2

La distributeur récupère les données auprès du

fournisseur.

Distributeur

Fournisseur

Le distributeur récupère une donnée modifiée sous forme de transaction, de FTP …

Get_Bookingou

Get_DocumentFTP

F

La donnée peut être un fichier, unDocument, un statut …

… tout ce qui est relatif à la donnée modifiée

« La mise en œuvre du format » 

La mise en œuvre possible …

La génération du contenu est

testé via une interrogation

depuis le FTP

Fournisseur

Distributeur

Interrogation régulière des notifications sur le répertoire

Dépôt des nouvelles notifications dans 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

Répertoire FTP

Interrogation avec retour sans rien

Interrogation avec retour sans rien

Interrogation avec retour …et récupération des notifications

La mise en œuvre possible : étape 1

Le fournisseur génère le

contenu et avise le

distributeur

Fournisseur

Distributeur

Le distributeur comprend que le fournisseur a notifié quelque chose

Le fournisseur envoie une notification au distributeur

Récupartion transactionnelle de la notification

La mise en œuvre possible : étape 2

La distributeur récupère

les données auprès du

fournisseur

Distributeur

Fournisseur

Le distributeur récupère une donnée modifiée

Récupération de la donnée modifiée en

XFT

F

« Aviser plusieurs distributeurs »

Aviser plusieurs distributeurs

Le fournisseur génère le contenu et

avise plusieurs distributeurs

Fournisseur

Le fournisseur envoie les notifications à plusieurs distributeurs

Distributeur 1 Distributeur 2 Distributeur 3 Distribueur 4

Le fournisseur peut faire des envois multiples

Les distributeurs comprennent qu’une notificationa été envoyée

Aviser plusieurs distributeurs

Les distributeurs récupèrent ensuite

les données auprès du fournisseur

Fournisseur

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 

TransactionTransaction Transaction Transaction

F

Le PAC

De nouveaux

enjeux pour une

standardisation

De nouveaux enjeux pour une standardisation

La Pac USAGE

Producteur A

Producteur B

Producteur C

CacheProduit

Dis

trib

ute

urs

/ C

on

so

lida

teu

rsU

tili

sa

teu

r

fin

al

fou

rnis

seu

rs

Producteur…

XFT CatalogueXFT CatalogueXFT CatalogueXFT Catalogue

XFT Cache XFT Caches XFT Cache XFT Cache

La base de produits est alimentée par l’intermédiaire

d’exports de la part des fournisseurs, au format CETO…

XFT Promos XFT Promos XFT Promos

Les exports sont associés à des fichiers de

caches établis au standard XFT

La PAC Qui s’en sert ? La génération

• Les fournisseurs Asia Cabinet Chaubet Crystal TO Italowcost Donatello La France du Nord au

Sud Fram Kuoni Luxair Tour Marmara

Nouvelles frontières Pierre et Vacances Présence assistance

tourisme Siriona Thomas Cook Transat France Voyageurs du Monde

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

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

Le PAC les inconvénients

• Inconvénients La taille des fichiers L’aspect non ciblé de la

mise à jour (annule et remplace)

Déclinaisons du fichier (enrichissement non uniforme)

N’ empêche pas l’utilisation de robot pour requêter la disponibilité

Il ne couvre pas l’intégralité des besoins des distributeurs

Il taxe des systèmes fournisseurs

La PAC n’est pas adapté aux produits flexibles ni aux packages dynamiques

Le rafraichissement doit être plus régulier qu’avant compte tenu du fait que les tarifs et les disponibilités évoluent plus vite qu’avant

• 3/J 5/j le poids est une inconvénient

Le PAC Quelles évolutions possibles ?

• Aujourd’hui Un PAC et prix promo par catalogue

Producteur A

Producteur B

Producteur C

ProducteurD

XFT Catalogue

XFT Cache

XFT PromosXFT Catalogue

XFT Cache

XFT Promos

XFT Catalogue

XFT Cache

XFT Promos

XFT Catalogue

XFT Cache

XFT Promos

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

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

• 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

Les solutions possibles