Adding a hotel supplier is not adding a data source
Γράφει ο Panagiotis Athanasakopoulos · Παναγιώτης Αθανασακόπουλος
Architecture16 Οκτωβρίου 20263 min
Αυτή την εβδομάδα το TRVL, το online ταξιδιωτικό γραφείο που διευθύνω, συνδέθηκε με την τρίτη του πηγή ξενοδοχείων: την Emerging Travel Group. Μέσα σε μία νύχτα το site πέρασε από έναν κατάλογο χτισμένο κυρίως γύρω από την Ελλάδα σε 8.773 νέα καταλύματα, σε 111 χώρες και 1.511 πόλεις. Αυτή είναι η πρόταση για το δελτίο Τύπου. Η άλλη είναι η εξής: η εισαγωγή των ξενοδοχείων ήταν το πιο γρήγορο και το λιγότερο ενδιαφέρον κομμάτι της δουλειάς.
Το εύκολο λάθος είναι να δείτε έναν νέο προμηθευτή ως μια νέα πηγή δεδομένων. Αντιστοιχίζετε τα πεδία του στα δικά σας, γράφετε τα ξενοδοχεία στον ίδιο πίνακα, και το υπόλοιπο σύστημα συνεχίζει όπως πριν. Μοιάζει τελειωμένο. Δεν είναι. Ένας προμηθευτής ξενοδοχείων δεν σας πουλά δεδομένα. Σας πουλά υποσχέσεις: αυτό το δωμάτιο υπάρχει, σε αυτή την τιμή, αυτές τις ημερομηνίες, με αυτούς τους όρους ακύρωσης. Κάθε μία από αυτές τις υποσχέσεις μπορεί να αλλάξει από τη στιγμή που ο επισκέπτης τη διαβάζει ως τη στιγμή που πληρώνει.
Γι' αυτό η πρώτη απόφαση αφορούσε τη δομή. Κάθε σημείο του κώδικα που έλεγε «αν δεν είναι δικό μας, θα είναι του παλιού προμηθευτή» έγινε ρητή διακλάδωση για κάθε προμηθευτή. Ένα «αλλιώς» είναι μια εικασία για το μέλλον, και το μέλλον μόλις είχε φτάσει. Όπου δύο προμηθευτές πουλούν το ίδιο ξενοδοχείο, το κρατά αυτός που ήδη ξέρουμε. Μια διπλή καταχώριση με δύο τιμές είναι χειρότερη από οποιαδήποτε από τις δύο τιμές.
Η δεύτερη αφορούσε την ταχύτητα. Το API ενός προμηθευτή έχει όρια. Η κλήση που επιστρέφει πλήρη διαθεσιμότητα ανά δωμάτιο είναι η πιο αργή και η πιο περιορισμένη απ' όλες. Αν τη ζητά κάθε σελίδα ξενοδοχείου, το όριο εξαντλείται από την απλή περιήγηση, και ο επισκέπτης βλέπει «δεν υπάρχει διαθεσιμότητα» σε ένα ξενοδοχείο που έχει πολλή. Τώρα η σελίδα παίρνει την τιμή της από την κλήση αναζήτησης, που είναι γρήγορη και έχει άνετα όρια. Η ακριβή κλήση γίνεται μία φορά, όταν κάποιος ξεκινά πραγματικά να κάνει κράτηση.
Η τρίτη είναι η πιο σημαντική: η τιμή στη σελίδα είναι προσφορά, όχι συμβόλαιο. Από τη στιγμή που τη διαβάζει κανείς ως τη στιγμή που πληρώνει, ο προμηθευτής μπορεί να αλλάξει την τιμή του δωματίου. Αποφασίσαμε από πριν τι γίνεται σε αυτή την περίπτωση, ώστε να μη χρειαστεί να αυτοσχεδιάσει κανείς στο checkout. Αν η τιμή πέσει ή ανέβει έως τρία τοις εκατό, ο επισκέπτης πληρώνει αυτό που είδε. Αν ανέβει περισσότερο, βλέπει τη νέα τιμή πριν πληρώσει. Αν το δωμάτιο έχει φύγει, δεν γίνεται χρέωση. Κι αν μια αλλαγή φανεί μόνο μετά την πληρωμή, η επιστροφή χρημάτων γίνεται αυτόματα και ολόκληρη.
Μετά είναι οι τιμές που απλώς λείπουν. Η απουσία δεν είναι το ίδιο με την αποτυχία. Περίπου δύο χιλιάδες από τα νέα ξενοδοχεία δεν επέστρεψαν καμία τιμή, σε τέσσερα σετ ημερομηνιών με απόσταση μηνών μεταξύ τους. Το API απαντούσε σωστά κάθε φορά. Απλώς δεν είχε κάτι να πουλήσει. Ο πειρασμός είναι να το πείτε bug και να κρύψετε τα ξενοδοχεία, ή να το θεωρήσετε φυσιολογικό και να προχωρήσετε. Δεν κάναμε τίποτα από τα δύο. Το μετρήσαμε και στείλαμε τη λίστα στον προμηθευτή. Το τι θα βλέπουν οι επισκέπτες θα το αποφασίσουμε όταν μας απαντήσει.
Ένα μέρος της δουλειάς δεν φαίνεται, και αυτό είναι σκόπιμο. Ένας προμηθευτής έχει το δικό του σύστημα email. Ένας επισκέπτης που έκανε κράτηση σε εμάς δεν πρέπει ποτέ να λάβει μήνυμα από μια εταιρεία που δεν έχει ακούσει ποτέ, οπότε κάθε μήνυμα έρχεται από το TRVL. Τα mobile apps που είναι ήδη εγκατεστημένα στα κινητά δεν ήξεραν να χειριστούν τα νέα ξενοδοχεία. Έτσι ο server τα δείχνει μόνο στις εκδόσεις που δηλώνουν ότι μπορούν. Τίποτα από αυτά δεν φαίνεται σε ένα demo. Όλα φαίνονται την πρώτη φορά που λείπουν.
Πριν βγει οτιδήποτε live, όλη η διαδρομή δοκιμάστηκε με πραγματικές κρατήσεις σε ένα δοκιμαστικό κατάλυμα: αναζήτηση, έλεγχος τιμής, πληρωμή, επιβεβαίωση, ακύρωση, επιστροφή χρημάτων. Μέχρι να το ενεργοποιήσουμε, ένας έλεγχος στον κώδικα επέτρεπε κρατήσεις σε εκείνο το ένα ξενοδοχείο και πουθενά αλλού. Όταν δοκιμάζετε μια μηχανή κρατήσεων με ψεύτικα δεδομένα, αποδεικνύετε ότι ο κώδικάς σας συμφωνεί με τον εαυτό του. Όταν τη δοκιμάζετε με τον προμηθευτή, αποδεικνύετε ότι ο προμηθευτής συμφωνεί μαζί σας. Αυτή είναι η μόνη συμφωνία που θα προσέξει ποτέ ο επισκέπτης.
Αυτό σημαίνει στην πραγματικότητα να προσθέσετε έναν προμηθευτή. Όχι περισσότερες γραμμές σε έναν πίνακα, αλλά ένα δεύτερο σύνολο κανόνων για χρόνο, τιμή και εμπιστοσύνη, που πρέπει να ισχύει ακριβώς τη στιγμή που κινούνται χρήματα. Τα ξενοδοχεία είναι αυτό που βλέπει ο επισκέπτης. Οι κανόνες είναι αυτό που πραγματικά αγοράζει.
Common questions
- Τι περιλαμβάνει η σύνδεση με έναν προμηθευτή ξενοδοχείων, πέρα από την εισαγωγή των ξενοδοχείων;
- Τη διαχείριση των υποσχέσεων του προμηθευτή, όχι μόνο των δεδομένων του. Ελέγχετε ξανά τιμή και διαθεσιμότητα πριν από την πληρωμή. Αποφασίζετε από πριν τι γίνεται όταν αλλάξει κάποια από τις δύο. Σέβεστε τα όρια του API του προμηθευτή, ώστε η απλή περιήγηση να μην τα εξαντλεί. Και κρατάτε την επικοινωνία του προμηθευτή μακριά από τον επισκέπτη.
- Τι πρέπει να γίνεται αν η τιμή ενός ξενοδοχείου αλλάξει κατά το checkout;
- Ο κανόνας πρέπει να αποφασιστεί πριν από το λανσάρισμα, όχι στο checkout. Μια συνηθισμένη προσέγγιση: ένα μικρό περιθώριο μέσα στο οποίο ο επισκέπτης πληρώνει την τιμή που είδε, μια καθαρή ειδοποίηση με τη νέα τιμή όταν η αλλαγή το ξεπερνά, και καμία χρέωση, ή αυτόματη πλήρη επιστροφή χρημάτων, αν το δωμάτιο δεν είναι πια διαθέσιμο.
- Γιατί ένα ξενοδοχείο μπορεί να εμφανίζεται στον κατάλογο αλλά χωρίς διαθεσιμότητα;
- Γιατί η καταχώριση και η πώληση είναι ξεχωριστά πράγματα. Ένας προμηθευτής μπορεί να έχει το περιεχόμενο ενός καταλύματος χωρίς να έχει αυτή τη στιγμή τιμές να πουλήσει, οπότε το API απαντά σωστά, απλώς χωρίς τιμές. Αυτό είναι εμπορικό ζήτημα του προμηθευτή, όχι λάθος του λογισμικού. Αξίζει να το μετρήσετε πριν αποφασίσετε πώς θα δείχνετε αυτά τα ξενοδοχεία.