Κανονικοποίηση της κατάστασης παρακολούθησης μεταφορέων: Πώς να αντιστοιχίσετε τα συμβάντα μεταφορέων σε ένα ενιαίο μοντέλο καταστάσεων

Η κανονικοποίηση της κατάστασης παρακολούθησης αποστολών σημαίνει τη μετάφραση των ειδικών για κάθε μεταφορέα κωδικών και μηνυμάτων σάρωσης σε ένα συνεπές μοντέλο αποστολής, διατηρώντας παράλληλα τα αρχικά αποδεικτικά στοιχεία. Για την αξιόπιστη υλοποίησή της, αντιστοιχίστε κάθε συμβάν σε μια κανονική κατάσταση και αιτία και, στη συνέχεια, υπολογίστε την τρέχουσα κατάσταση της αποστολής χρησιμοποιώντας τον χρόνο των συμβάντων, το πλαίσιο της αποστολής και σαφείς κανόνες μετάβασης. Μην θεωρείτε αυτόματα ότι το πιο πρόσφατο μήνυμα που ελήφθη αποτελεί την τρέχουσα κατάσταση της αποστολής.

Αυτός ο οδηγός απευθύνεται σε προγραμματιστές, ομάδες λειτουργίας logistics και υπεύθυνους προϊόντων που ενσωματώνουν την παρακολούθηση σε ένα σύστημα διαχείρισης παραγγελιών, έναν πίνακα υποστήριξης ή μια ροή εργασίας ειδοποιήσεων πελατών. Το παρακάτω μοντέλο αποτελεί προτεινόμενο μοτίβο υλοποίησης και όχι επίσημο πρότυπο μεταφορέα ή αναπαραγωγή της ταξινομίας κατάστασης οποιουδήποτε παρόχου παρακολούθησης.

Διαχωρίστε το συμβάν του μεταφορέα από την κατάσταση της αποστολής

Ένα συμβάν παρακολούθησης περιγράφει κάτι που αναφέρθηκε σχετικά με μια αποστολή: δημιουργήθηκε μια ετικέτα, ένα δέμα έφτασε σε μια εγκατάσταση ή μια απόπειρα παράδοσης απέτυχε. Η κατάσταση μιας αποστολής είναι η ερμηνεία της εφαρμογής σας για τα σχετικά αποδεικτικά στοιχεία σε μια συγκεκριμένη χρονική στιγμή. Αυτές οι έννοιες πρέπει να αποθηκεύονται ξεχωριστά.

Για παράδειγμα, ένα δέμα μπορεί να έχει ένα συμβάν αποτυχημένης απόπειρας παράδοσης και στη συνέχεια ένα συμβάν άφιξης σε εγκατάσταση. Η άφιξη αποτελεί χρήσιμο λειτουργικό ιστορικό, αλλά δεν σημαίνει απαραίτητα ότι η συνθήκη της αποτυχημένης απόπειρας έχει επιλυθεί. Αντίστροφα, μια καθυστερημένη σάρωση που φτάνει μετά από επιβεβαίωση παράδοσης δεν πρέπει να επαναφέρει αυτόματα το δέμα σε μεταφορά.

Μια πρακτική αρχιτεκτονική έχει τρία επίπεδα:

1. Ακατέργαστα αποδεικτικά στοιχεία: το αρχικό φορτίο δεδομένων του μεταφορέα ή του παρόχου, συμπεριλαμβανομένων κωδικών, κειμένου, χρονικών σημάνσεων και αναγνωριστικών.
2. Κανονικοποιημένα συμβάντα: η ερμηνεία σας για κάθε μεμονωμένο συμβάν χρησιμοποιώντας έναν κανόνα αντιστοίχισης με έκδοση.
3. Τρέχουσα προβολή αποστολής: η κατάσταση που επιλέγεται από το ιστορικό συμβάντων, μαζί με τυχόν ενεργές συνθήκες και ενέργειες πελατών.

Αυτός ο διαχωρισμός σάς επιτρέπει να διορθώνετε τις αντιστοιχίσεις και να αναδημιουργείτε τις καταστάσεις αποστολών χωρίς να απορρίπτετε την αρχική καταγραφή.

Ορίστε ένα συμπαγές μοντέλο κατάστασης με ξεχωριστές συνθήκες

Ένα μόνο πεδίο κατάστασης γίνεται δύσκολο στη συντήρηση όταν πρέπει να αναπαριστά ταυτόχρονα τη φυσική μετακίνηση, την επεξεργασία τελωνείου, τα προβλήματα παράδοσης και τις επιστροφές. Χρησιμοποιήστε ένα μικρό μοντέλο κύκλου ζωής και, στη συνέχεια, επισυνάψτε πιο συγκεκριμένες συνθήκες και αιτίες.

Διατηρήστε συνθήκες όπως CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE ή DELAY_REPORTED εκτός του κύριου πεδίου κύκλου ζωής. Μια αποστολή μπορεί να παραμένει IN_TRANSIT ενώ ένα πρόβλημα διεύθυνσης απαιτεί προσοχή. Μην χαρακτηρίζετε τη συνήθη τελωνειακή επεξεργασία ως εξαίρεση, εκτός εάν η πηγή αναφέρει κράτηση, πρόβλημα ή απαιτούμενη ενέργεια.

Αναπαριστάτε ξεχωριστά την κατεύθυνση με ένα πεδίο όπως το journey_type. Μια επιστροφή μπορεί να έχει τις δικές της καταστάσεις μεταφοράς και παράδοσης. Έτσι αποφεύγεται η ερμηνεία της παράδοσης πίσω στον αποστολέα ως επιτυχούς παράδοσης στον αγοραστή.

Δημιουργήστε την καταγραφή συμβάντος πριν γράψετε κανόνες αντιστοίχισης

Η κανονικοποιημένη καταγραφή πρέπει να περιέχει αρκετό πλαίσιο ώστε να εξηγεί την αντιστοίχιση και να αναπαράγει το αποτέλεσμα. Ένα χρήσιμο αρχικό σχήμα περιλαμβάνει:

• Ταυτότητα: εσωτερικό αναγνωριστικό αποστολής, αναγνωριστικό μεταφορέα, αριθμό παρακολούθησης, πηγή και σκέλος αποστολής.
• Αρχικά αποδεικτικά στοιχεία: ακατέργαστο κωδικό συμβάντος, ακατέργαστη περιγραφή, αναγνωριστικό συμβάντος πηγής όταν παρέχεται και αναφορά στο αρχικό φορτίο δεδομένων.
• Χρονισμός: χρόνος εμφάνισης του συμβάντος, πληροφορίες ζώνης ώρας, χρόνος λήψης και ακρίβεια χρονικής σήμανσης.
• Ερμηνεία: κανονική κατάσταση, συνθήκη, κωδικός αιτίας, τύπος διαδρομής και απαίτηση ενέργειας.
• Ιχνηλασιμότητα: αναγνωριστικό κανόνα αντιστοίχισης, έκδοση αντιστοίχισης και κατηγορία βεβαιότητας.

Διατηρήστε ξεχωριστό τον χρόνο εμφάνισης του συμβάντος από τον χρόνο λήψης της ενημέρωσης από το σύστημά σας. Ένα webhook που λαμβάνεται το απόγευμα μπορεί να περιγράφει σάρωση από το πρωί. Μια απόκριση polling μπορεί επίσης να περιέχει πολλά ιστορικά συμβάντα αντί για ένα νέο συμβάν.

Χρησιμοποιήστε τεκμηριωμένη μορφή χρονικής σήμανσης όπως το RFC 3339 όταν είναι γνωστά η ώρα και η μετατόπιση. Εάν η πηγή παρέχει τοπική ώρα χωρίς αξιόπιστη μετατόπιση, διατηρήστε αυτόν τον περιορισμό αντί να προσθέσετε ψευδή ένδειξη UTC. Αποθηκεύστε τα συμβάντα που περιέχουν μόνο ημερομηνία ως αποδεικτικά στοιχεία μόνο ημερομηνίας, αντί να επινοήσετε ακριβή ώρα σάρωσης.

Αποθηκεύστε τα ακατέργαστα φορτία δεδομένων υπό κατάλληλους ελέγχους πρόσβασης και κανόνες διατήρησης. Ενδέχεται να περιέχουν στοιχεία παραλήπτη ή άλλες πληροφορίες που δεν ανήκουν σε έναν πίνακα αναλυτικών δεδομένων με ευρεία πρόσβαση.

Αντιστοιχίστε πρώτα τους κωδικούς του μεταφορέα και χρησιμοποιήστε το κείμενο με προσοχή

Ξεκινήστε με κανόνες που περιορίζονται σε συγκεκριμένη πηγή και μεταφορέα. Ένας κωδικός όπως 01 δεν έχει αξιόπιστη σημασία εκτός του τεκμηριωμένου πλαισίου του. Όταν μια πηγή διακρίνει υπηρεσίες, περιοχές ή σκέλη, συμπεριλάβετε αυτές τις διαστάσεις όταν επηρεάζουν την ερμηνεία.

Χρησιμοποιήστε την ακόλουθη σειρά αντιστοίχισης ως προεπιλογή υλοποίησης:

1. Αντιστοιχίστε έναν τεκμηριωμένο δομημένο κωδικό συμβάντος και τυχόν απαιτούμενους προσδιοριστές.
2. Χρησιμοποιήστε μια τεκμηριωμένη κατάσταση ή υποκατάσταση της πηγής όταν περιγράφει με σαφήνεια το συμβάν που επεξεργάζεται.
3. Εφαρμόστε στενά περιορισμένους κανόνες κειμένου για γνωστά μηνύματα που δεν διαθέτουν επαρκή δομημένα πεδία.
4. Αφήστε τα ανεπίλυτα συμβάντα χωρίς αντιστοίχιση και στείλτε τις επαναλαμβανόμενες περιπτώσεις για έλεγχο.

Πρώτα καθορίστε εάν το πεδίο κατάστασης ενός παρόχου περιγράφει ένα μεμονωμένο συμβάν ή την τρέχουσα σύνοψη της αποστολής. Η αντιγραφή μιας σύνοψης σε επίπεδο αποστολής σε κάθε ιστορικό συμβάν μπορεί να κάνει παλαιότερες σαρώσεις να φαίνονται ως επιβεβαιώσεις παράδοσης.

Αποφύγετε καθολικούς κανόνες λέξεων-κλειδιών όπως «περιέχει delivered». Η φράση «not delivered» θα ταίριαζε επίσης, όπως και ένα μήνυμα που περιγράφει παράδοση σε συνεργάτη logistics. Οι κανόνες κειμένου χρειάζονται χειρισμό άρνησης, γλωσσικό πλαίσιο και εξαιρέσεις. Η μηχανική μετάφραση μπορεί να βοηθήσει έναν αξιολογητή να κατανοήσει ένα μήνυμα, αλλά η μεταφρασμένη διατύπωση δεν πρέπει να γίνεται σιωπηρά ο authoritative ορισμός του συμβάντος.

Ενδεικτικές αντιστοιχίσεις και τα όριά τους

Τα παρακάτω παραδείγματα χρησιμοποιούν επινοημένα μηνύματα για να επιδείξουν τον σχεδιασμό κανόνων. Δεν αποτελούν επαληθευμένους κωδικούς μεταφορέων ή ακριβή μηνύματα συγκεκριμένου μεταφορέα.

• «Shipment details submitted»: αντιστοιχίστε σε PRE_TRANSIT όταν ο ορισμός της πηγής υποδεικνύει μόνο ηλεκτρονικές πληροφορίες.
• «Accepted at origin facility»: αντιστοιχίστε σε IN_TRANSIT όταν το συμβάν επιβεβαιώνει τη φυσική παραλαβή.
• «Recipient unavailable; attempt unsuccessful»: καταγράψτε DELIVERY_ATTEMPT_FAILED και αξιολογήστε τον κύκλο ζωής από τα περιβάλλοντα αποδεικτικά στοιχεία. Μην συμπεραίνετε ότι είναι διαθέσιμη η παραλαβή.
• «Available for collection»: αντιστοιχίστε σε READY_FOR_PICKUP όταν η πηγή επιβεβαιώνει την ετοιμότητα παραλαβής από τον παραλήπτη.
• «Transferred to delivery partner»: καταγράψτε την παράδοση σε συνεργάτη και διατηρήστε την κατάλληλη κατάσταση μεταφοράς, αντί να χαρακτηρίσετε την παράδοση στον παραλήπτη ως ολοκληρωμένη.

Κάθε κανόνας πρέπει να έχει σύντομη αιτιολόγηση και υπεύθυνο. Όταν ένας ειδικός λειτουργίας αμφισβητεί μια αντιστοίχιση, η ομάδα πρέπει να μπορεί να εντοπίσει τον ακριβή κανόνα αντί να ανακατασκευάζει μια ετικέτα που εμφανίζεται στον πελάτη.

Υπολογίστε την τρέχουσα κατάσταση με έναν ντετερμινιστικό reducer

Ο reducer είναι η συνάρτηση που αξιολογεί τα κανονικοποιημένα συμβάντα και παράγει την τρέχουσα προβολή της αποστολής. Πρέπει να επιστρέφει το ίδιο αποτέλεσμα για τα ίδια αποδεικτικά στοιχεία και την ίδια έκδοση κανόνων, ανεξάρτητα από το πόσες φορές επαναλαμβάνεται η είσοδος.

Καταργήστε τα διπλότυπα χωρίς να διαγράφετε σημαντικές σαρώσεις

Προτιμήστε ένα σταθερό αναγνωριστικό συμβάντος πηγής, όταν υπάρχει. Διαφορετικά, δημιουργήστε ένα κλειδί κατάργησης διπλοτύπων από διαθέσιμα χαρακτηριστικά όπως ταυτότητα αποστολής, μεταφορέας, κωδικός, χρόνος εμφάνισης και τοποθεσία. Λάβετε υπόψη την ακρίβεια χρονικής σήμανσης και τη συμπεριφορά της πηγής. Δύο σαρώσεις με πανομοιότυπες περιγραφές δεν είναι απαραίτητα διπλότυπες, ειδικά εάν το δέμα επισκέπτεται ξανά μια εγκατάσταση.

Ταξινομήστε τα συμβάντα χωρίς να υποθέτετε τέλεια ρολόγια

Χρησιμοποιήστε αξιόπιστους χρόνους εμφάνισης και τεκμηριωμένες πληροφορίες ακολουθίας όπου είναι διαθέσιμες. Ο χρόνος λήψης μπορεί να βοηθήσει στην επίλυση ισοβαθμιών, αλλά δεν πρέπει συνήθως να υπερισχύει ενός παλαιότερου χρόνου εμφάνισης. Εάν οι χρονικές σημάνσεις συγκρούονται ή δεν μπορούν να συγκριθούν αξιόπιστα, διατηρήστε την ασάφεια αντί να κατασκευάσετε βεβαιότητα.

Επικυρώστε τις μεταβάσεις αντί να εκχωρείτε καθολική σειρά

Μια απλή αριθμητική σειρά καταστάσεων δεν μπορεί να αναπαραστήσει κάθε διαδρομή αποστολής. Ένα δέμα μπορεί να μεταβεί από «προς παράδοση» ξανά σε μεταφορά μετά από ανεπιτυχή απόπειρα. Η διαθεσιμότητα παραλαβής μπορεί να λήξει. Μια ρητή διόρθωση μπορεί να ακυρώσει μια επιβεβαίωση παράδοσης.

Ορίστε τις επιτρεπόμενες μεταβάσεις και τα αποδεικτικά στοιχεία που απαιτεί καθεμία. Αντιμετωπίστε την delivered ως προστατευμένη από συνήθεις παλαιότερες σαρώσεις, αλλά επιτρέψτε μια τεκμηριωμένη διόρθωση ή μια εξουσιοδοτημένη λειτουργική παράκαμψη. Καταγράψτε την αιτία και την πηγή κάθε παράκαμψης.

Παρακολουθήστε ανεξάρτητα τις ενεργές συνθήκες

Μια μεταγενέστερη σάρωση μετακίνησης μπορεί να δείχνει πρόοδο χωρίς να αποδεικνύει ότι έχει επιλυθεί ένα πρόβλημα πληρωμής ή διεύθυνσης. Ορίστε κανόνες εκκαθάρισης ανά συνθήκη: ρητή επίλυση, συμβάν που οδηγεί λογικά σε επίλυση ή εξουσιοδοτημένη χειροκίνητη ενέργεια. Μην εκκαθαρίζετε κάθε συνθήκη απλώς επειδή έφτασε ένα άλλο συμβάν.

Διακρίνετε επίσης την καθυστέρηση που αναφέρει ο μεταφορέας από τη δική σας ειδοποίηση αδράνειας. Η απουσία νέων σαρώσεων αποτελεί παρατήρηση σχετικά με την επικαιρότητα των δεδομένων και όχι απόδειξη ότι το δέμα χάθηκε.

Χειριστείτε τις παραδόσεις μεταξύ μεταφορέων και τις επιστροφές ως συνδεδεμένες διαδρομές

Η διασυνοριακή παρακολούθηση μπορεί να περιλαμβάνει πολλούς μεταφορείς και αναγνωριστικά. Διατηρήστε μια εσωτερική ταυτότητα αποστολής και συνδέστε τις ειδικές για κάθε μεταφορέα αναφορές παρακολούθησης με τα σχετικά σκέλη. Συνδέστε τις αναφορές χρησιμοποιώντας σχέσεις που παρέχονται από την πηγή ή επαληθευμένα λειτουργικά δεδομένα, όχι απλώς παρόμοιους προορισμούς ή κοντινές χρονικές σημάνσεις.

Ένα συμβάν παράδοσης σε επίπεδο σκέλους πρέπει να ερμηνεύεται μέσα στο πλαίσιό του. Η παράδοση σε εγκατάσταση συγκέντρωσης ή δίκτυο συνεργάτη μπορεί να ολοκληρώνει αυτό το σκέλος χωρίς να ολοκληρώνει την παράδοση στον αγοραστή. Η προβολή της αποστολής σας πρέπει να γνωρίζει ποιον προορισμό αντιπροσωπεύει το συμβάν.

Ομοίως, διαχωρίστε τα «αίτημα επιστροφής», «έναρξη μετακίνησης επιστροφής» και «επιστροφή στον αποστολέα». Αυτά περιγράφουν διαφορετικά ορόσημα. Ένα αίτημα επιστροφής δεν αποδεικνύει ότι το δέμα μετακινείται πράγματι προς τα πίσω και η επιβεβαίωση παράδοσης μιας αντίστροφης διαδρομής πρέπει να προσδιορίζει τον προορισμό επιστροφής.

Χρησιμοποιήστε ένα tracking API χωρίς να παραχωρείτε τους επιχειρηματικούς σας κανόνες

Μια ενοποίηση πολλών μεταφορέων μπορεί να παρέχει ένα κοινό σημείο εισαγωγής, αλλά μια κοινή μορφή απόκρισης δεν εξαλείφει την ανάγκη για σαφές εσωτερικό συμβόλαιο. Κατά την αξιολόγηση του 17TRACK Tracking API, χρησιμοποιήστε την official documentation για να ελέγξετε τη σημασία των πεδίων και των διεπαφών που σχετίζονται με την υλοποίησή σας. Μην υποθέτετε ότι οι προτεινόμενες καταστάσεις αυτού του οδηγού ταιριάζουν με την εγγενή ταξινομία του.

Πριν συνδέσετε οποιοδήποτε API με ειδοποιήσεις πελατών ή λειτουργικό αυτοματισμό, καθορίστε:

• Ποια πεδία περιγράφουν μεμονωμένα συμβάντα και ποια περιγράφουν την τρέχουσα σύνοψη της αποστολής.
• Ποιες αρχικές λεπτομέρειες του μεταφορέα εκτίθενται και μπορούν να διατηρηθούν.
• Πώς αναπαρίστανται οι χρονικές σημάνσεις, οι ελλείπουσες τιμές, οι διορθώσεις και οι επαναλαμβανόμενες ενημερώσεις.
• Πώς μπορούν να διακριθούν οι διαδρομές επιστροφής και η παράδοση σε ενδιάμεσους συνεργάτες.
• Πώς θα ανταποκρίνεται η ενοποίησή σας σε άγνωστους κωδικούς ή μελλοντικές αλλαγές σχήματος.

Διατηρήστε έναν λεπτό adapter μεταξύ της εξωτερικής απόκρισης και του κανονικού μοντέλου σας. Έτσι το υπόλοιπο της εφαρμογής σας μπορεί να χρησιμοποιεί ένα ενιαίο συμβόλαιο κατάστασης παρακολούθησης χωρίς να εξαρτάται από κάθε όνομα πεδίου ανάντη. Αντιμετωπίστε τους κανόνες ειδοποιήσεων ως άλλο επίπεδο: ένα νέο κανονικοποιημένο συμβάν δεν πρέπει να ενεργοποιεί αυτόματα μήνυμα προς τον πελάτη.

Ελέγξτε τα ιστορικά συμβάντων και όχι μόνο τις μεμονωμένες αντιστοιχίσεις

Μια αντιστοίχιση μπορεί να είναι σωστή μεμονωμένα και παρ’ όλα αυτά να παράγει λάθος κατάσταση αποστολής. Ελέγξτε πλήρη ιστορικά, συμπεριλαμβανομένων ενημερώσεων που παραδόθηκαν με διαφορετική σειρά από τους χρόνους εμφάνισής τους.

• Καθυστερημένο ιστορικό: η επιβεβαίωση παράδοσης φτάνει πριν από μια παλαιότερη σάρωση μεταφοράς. Η αποστολή παραμένει delivered.
• Επαναλαμβανόμενη εισαγωγή: το ίδιο συμβάν επεξεργάζεται ξανά. Δεν αποστέλλεται διπλή ειδοποίηση πελάτη.
• Αποτυχημένη απόπειρα: μια ανεπιτυχής απόπειρα ακολουθεί την κατάσταση προς παράδοση. Η προβολή δεν υπόσχεται πλέον ενεργή διαδρομή παράδοσης χωρίς υποστηρικτικά αποδεικτικά στοιχεία.
• Ετοιμότητα παραλαβής: ένα δέμα φτάνει σε εγκατάσταση παραλαβής πριν επιβεβαιωθεί η διαθεσιμότητα. Δεν εκδίδεται πρόωρη οδηγία παραλαβής.
• Άγνωστο συμβάν: εμφανίζεται νέος κωδικός. Η ακατέργαστη καταγραφή διατηρείται και μια προηγουμένως καθιερωμένη κατάσταση αποστολής δεν αντικαθίσταται αυτόματα με unknown.
• Μετακίνηση επιστροφής: μια αντίστροφη διαδρομή ολοκληρώνεται στον αποστολέα. Η αρχική παράδοση στον αγοραστή δεν χαρακτηρίζεται επιτυχής.
• Διόρθωση: μια ρητή διόρθωση της πηγής αλλάζει το αποτέλεσμα μέσω ελέγξιμης μετάβασης.

Παρακολουθήστε τα μη αντιστοιχισμένα συμβάντα, τη χρήση εφεδρικής αντιστοίχισης κειμένου, τις μη έγκυρες μεταβάσεις και τις προσπάθειες διπλών ειδοποιήσεων ανά μεταφορέα και πηγή. Διακρίνετε την πληρότητα αντιστοίχισης από την ορθότητά της: η αναγνώριση κάθε κωδικού δεν είναι χρήσιμη εάν η ερμηνεία του είναι λανθασμένη.

Πριν αναπτύξετε μια αλλαγή αντιστοίχισης, επαναλάβετε αντιπροσωπευτικά ιστορικά και συγκρίνετε τις παλιές και νέες προβολές. Ελέγξτε τις διαφορές που επηρεάζουν την επιβεβαίωση παράδοσης, τις οδηγίες παραλαβής, την ολοκλήρωση επιστροφής ή την ενέργεια του πελάτη. Εκδώστε τους κανόνες με εκδόσεις, ώστε ένας εκπρόσωπος υποστήριξης να μπορεί να εξηγήσει γιατί το σύστημα παρήγαγε ένα συγκεκριμένο αποτέλεσμα.

Συχνές ερωτήσεις

Πρέπει κάθε συμβάν παρακολούθησης να έχει ακριβώς μία κατάσταση;

Κάθε συμβάν μπορεί να έχει μία κύρια κανονικοποιημένη ερμηνεία, αλλά μπορεί επίσης να χρειάζεται συνθήκη, αιτία και πλαίσιο διαδρομής. Η επιβολή όλης της σημασίας σε μία επίπεδη λίστα καταστάσεων καθιστά το μοντέλο δυσκολότερο στη χρήση και τη συντήρηση.

Πρέπει ένα άγνωστο συμβάν να αντικαθιστά την τρέχουσα κατάσταση της αποστολής;

Συνήθως όχι. Διατηρήστε την αντιστοίχιση του συμβάντος ως ανεπίλυτη, διατηρώντας παράλληλα την τελευταία υποστηριζόμενη κατάσταση αποστολής. Εμφανίστε ξεχωριστά την επικαιρότητα των δεδομένων, ώστε οι χρήστες να μην εκλαμβάνουν μια παλιά επιβεβαιωμένη κατάσταση ως πρόσφατη ενημέρωση.

Μπορεί μια παραδοθείσα αποστολή να επιστρέψει σε μεταφορά;

Μια παλαιότερη σάρωση μεταφοράς δεν πρέπει να προκαλεί αυτή την αλλαγή. Μια επαληθευμένη διόρθωση μπορεί να τη δικαιολογεί, ενώ μια νεοαποκτηθείσα διαδρομή επιστροφής θα πρέπει κανονικά να αναπαρίσταται ξεχωριστά. Η μετάβαση χρειάζεται σαφή αιτία και όχι απλώς μεταγενέστερη χρονική σήμανση λήψης.

Πώς πρέπει να αναπαρίστανται οι ελλείπουσες ενημερώσεις παρακολούθησης;

Χρησιμοποιήστε έναν εσωτερικό δείκτη επικαιρότητας ή ειδοποίηση αδράνειας. Διατηρήστε τον ξεχωριστά από την καθυστέρηση, την απώλεια ή τις καταστάσεις εξαίρεσης που αναφέρει ο μεταφορέας. Κάθε κατώφλι κλιμάκωσης πρέπει να αντικατοπτρίζει τις δεσμεύσεις εξυπηρέτησης και την επιχειρησιακή πολιτική σας, όχι μια καθολική υπόθεση.

Ποιος πρέπει να εγκρίνει τις αλλαγές αντιστοίχισης;

Η μηχανική πρέπει να έχει την ευθύνη της υλοποίησης και των δοκιμών επανάληψης· η λειτουργία logistics πρέπει να επικυρώνει τη σημασία της αποστολής· και ο υπεύθυνος εμπειρίας πελάτη πρέπει να εγκρίνει τις συνέπειες των μηνυμάτων. Ορίστε έναν κατονομασμένο υπεύθυνο λήψης αποφάσεων, ώστε τα αμφίσημα συμβάντα να μην παραμένουν επ’ αόριστον ανεπίλυτα.

Πηγές

• RFC 3339: Date and Time on the Internet: Timestamps — αναφορά για την αναπαράσταση χρονικών σημάνσεων και αριθμητικών μετατοπίσεων.
• 17TRACK Tracking API — επίσημο σημείο εισόδου για την ενοποίηση με το tracking API που συζητείται παραπάνω.
• 17TRACK API documentation — αναφορά υλοποίησης για τον έλεγχο του συμβολαίου του παρόχου· το κανονικό μοντέλο και τα παραδείγματα αντιστοίχισης σε αυτό το άρθρο αποτελούν προτεινόμενα μοτίβα σχεδιασμού και όχι ορισμούς ειδικούς για τον πάροχο.