8 βέλτιστες πρακτικές ενσωμάτωσης του UPS Tracking API (και λάθη που πρέπει να αποφεύγετε)

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

Ο παρών οδηγός απευθύνεται σε προγραμματιστές, ομάδες λειτουργίας ηλεκτρονικού εμπορίου και υπεύθυνους προϊόντος που είναι υπεύθυνοι για την ορατότητα των παραγγελιών. Εστιάζει σε πρακτικές αποφάσεις που επηρεάζουν την ποιότητα των δεδομένων, την εμπειρία των πελατών, το λειτουργικό κόστος και την αποκατάσταση από περιστατικά.

Τι πρέπει να κάνει μια ενσωμάτωση API παρακολούθησης της UPS

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

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

1. Επιβεβαιώστε το προϊόν API και τις απαιτήσεις πρόσβασης πριν από την κωδικοποίηση

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

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

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

2. Ασφαλίστε τα διαπιστευτήρια και απομονώστε τα περιβάλλοντα

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

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

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

3. Επικυρώστε και κανονικοποιήστε τους αριθμούς παρακολούθησης

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

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

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

4. Δημιουργήστε εσωτερικό μοντέλο κατάστασης αντί να αντιγράφετε το κείμενο του μεταφορέα

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

Ένα απλό μοντέλο μπορεί να περιλαμβάνει label_created, in_transit, out_for_delivery, delivered, exception και unknown. Η ακριβής λίστα αποτελεί απόφαση προϊόντος και όχι εγγύηση της UPS. Διατηρείτε τον αρχικό κωδικό και την περιγραφή του μεταφορέα μαζί με την κανονικοποιημένη κατάσταση, ώστε το προσωπικό υποστήριξης να μπορεί να διερευνά αμφίσημες περιπτώσεις.

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

5. Αντιμετωπίστε την παρακολούθηση ως πρόβλημα δεδομένων που βασίζεται σε γεγονότα

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

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

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

6. Σχεδιάστε για επαναλήψεις, όρια ρυθμού και μερικές αποτυχίες

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

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

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

7. Διαχωρίστε την επικαιρότητα των δεδομένων από τα μηνύματα προς τους πελάτες

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

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

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

8. Δοκιμάστε λειτουργικές οριακές περιπτώσεις και όχι μόνο την επιτυχή διαδρομή

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

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

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

Συνηθισμένα λάθη στο API παρακολούθησης της UPS με μια ματιά

Λάθος	Λειτουργική συνέπεια	Καλύτερη πρακτική
Κωδικοποίηση διαπιστευτηρίων	Διαρροή διαπιστευτηρίων και δύσκολη ανανέωση	Χρησιμοποιήστε προστατευμένη ρύθμιση στην πλευρά του διακομιστή και διαχείριση μυστικών
Αντιμετώπιση της παρακολούθησης ως ενός αιτήματος	Παλιές ή ελλιπείς πληροφορίες για την αποστολή	Χρησιμοποιήστε ανανέωση με βάση την κατάσταση και διατήρηση γεγονότων
Ανάλυση μόνο του κειμένου εμφάνισης	Εύθραυστοι κανόνες όταν αλλάζει η διατύπωση	Αντιστοιχίστε τους τεκμηριωμένους κωδικούς και διατηρήστε τις αρχικές αποκρίσεις
Επανάληψη κάθε σφάλματος	Σπατάλη αιτημάτων και πιο αργή αποκατάσταση	Ταξινομήστε τα σφάλματα και εφαρμόστε περιορισμένη οπισθοδρόμηση
Δοκιμή μόνο περιπτώσεων επιτυχίας	Οι αποτυχίες παραγωγής μετατρέπονται σε περιστατικά που βλέπουν οι πελάτες	Δοκιμάστε κενές, καθυστερημένες, διπλές, μη έγκυρες καταστάσεις και καταστάσεις εξαίρεσης

Πότε ένα API παρακολούθησης πολλαπλών μεταφορέων μπορεί να είναι καταλληλότερο

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

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

Πρακτική λίστα ελέγχου πριν από την κυκλοφορία

1. Επιβεβαιώστε το τρέχον προϊόν API της UPS, τη διαδικασία πρόσβασης, τα περιβάλλοντα και τη μέθοδο ελέγχου ταυτότητας στην επίσημη τεκμηρίωση.
2. Καθορίστε το εσωτερικό μοντέλο αποστολής και γεγονότων πριν γράψετε τον αναλυτή απόκρισης.
3. Προστατεύστε τα διαπιστευτήρια και διατηρήστε τη ρύθμιση παραγωγής ξεχωριστή από τις δοκιμές.
4. Επικυρώνετε τα αναγνωριστικά διατηρώντας την αρχική τιμή που εισήγαγε ο πελάτης.
5. Υλοποιήστε περιορισμένες επαναλήψεις, προσωρινή αποθήκευση, αποδιπλοποίηση και ανανέωση με βάση την κατάσταση.
6. Γράψτε τα μηνύματα προς τους πελάτες ξεχωριστά από τα αρχικά δεδομένα γεγονότων του μεταφορέα.
7. Δοκιμάστε εξαιρέσεις, κενά αποτελέσματα, καθυστερημένες σαρώσεις, διπλά γεγονότα και αποτυχίες υπηρεσίας.
8. Παρακολουθείτε την επικαιρότητα και την ποιότητα ανάλυσης μετά την ανάπτυξη και, στη συνέχεια, επανεξετάζετε την ενσωμάτωση όταν αλλάζει η τεκμηρίωση του μεταφορέα.

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

Μπορώ να καλέσω το API παρακολούθησης της UPS απευθείας από έναν browser;

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

Γιατί ένας αριθμός παρακολούθησης επιστρέφει μερικές φορές κανένα χρήσιμο γεγονός;

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

Πρέπει κάθε ενημέρωση παρακολούθησης να ενεργοποιεί email;

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

Πώς πρέπει να διαχειρίζεται μια εφαρμογή μια άγνωστη κατάσταση της UPS;

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

Είναι μια απευθείας ενσωμάτωση με την UPS καλύτερη από ένα API πολλαπλών μεταφορέων;

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

Πηγές

• UPS Developer Portal — επίσημοι πόροι προγραμματιστών και τεκμηρίωση API.
• UPS Tracking — επίσημη υπηρεσία παρακολούθησης της UPS.
• 17TRACK API — επίσημες πληροφορίες προϊόντος για ενσωμάτωση API παρακολούθησης πολλαπλών μεταφορέων.
• 17TRACK API Documentation — επίσημη τεκμηρίωση API και αναφορά ενσωμάτωσης.