Skip to main content
ΑρχικήΙστολόγιοΠώς να ενσωματώσετε ένα API παρακολούθησης αποστολών στο ηλεκτρονικό σας κατάστημα

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

17TRACK

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

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

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

Αποφασίστε τι πρέπει να επιτύχει η ενσωμάτωση

Ξεκινήστε από το επιχειρηματικό αποτέλεσμα και όχι από το endpoint του API. Τα περισσότερα καταστήματα θέλουν να μειώσουν τα αιτήματα «Πού είναι η παραγγελία μου;», να προσφέρουν στους αγοραστές σαφή εικόνα της παράδοσης και να βοηθούν τις λειτουργίες να εντοπίζουν καθυστερημένες αποστολές πριν παραπονεθεί ένας πελάτης. Αυτοί οι στόχοι απαιτούν διαφορετικά δεδομένα και ροές εργασίας.

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

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

Επιλέξτε τη σωστή αρχιτεκτονική ενσωμάτωσης

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

Η βασική ροή είναι η εξής:

  1. Μια πληρωμένη παραγγελία εκτελείται και λαμβάνει αριθμό παρακολούθησης και μεταφορέα.
  2. Το backend σας στέλνει τα στοιχεία της αποστολής στον πάροχο παρακολούθησης.
  3. Ο πάροχος επιστρέφει ένα αναγνωριστικό παρακολούθησης ή δεδομένα παρακολούθησης σύμφωνα με τον σχεδιασμό του API του.
  4. Το σύστημά σας αποθηκεύει την αναφορά του παρόχου και αντιστοιχίζει τα συμβάντα αποστολής σε εσωτερικές καταστάσεις.
  5. Μια προγραμματισμένη διαδικασία ενημέρωσης ή μια υποστηριζόμενη ειδοποίηση συμβάντος ανανεώνει την αποστολή.
  6. Το ηλεκτρονικό σας κατάστημα, η σελίδα παραγγελίας, τα εργαλεία υποστήριξης και η υπηρεσία ειδοποιήσεων διαβάζουν από τα δικά σας κανονικοποιημένα δεδομένα.

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

Επιβεβαιώστε την τεκμηρίωση του παρόχου πριν από την κωδικοποίηση

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

Δημιουργήστε μια σύντομη λίστα απαιτήσεων από την τεκμηρίωση:

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

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

Προετοιμάστε τα δεδομένα παραγγελίας και αποστολής

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

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

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

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

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

Κανονικοποιήστε τις καταστάσεις μεταφορέων για τους πελάτες

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

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

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

Δημιουργήστε τη ροή αιτημάτων από την πλευρά του διακομιστή

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

Μια ροή αιτημάτων ανεξάρτητη από πάροχο μπορεί να αναπαρασταθεί ως εξής:

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

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

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

Σχεδιάστε την εμπειρία παρακολούθησης του πελάτη

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

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

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

Χρησιμοποιήστε τις ειδοποιήσεις με προσοχή

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

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

Δοκιμάστε με πραγματικά σενάρια παράδοσης

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

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

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

Ασφάλεια, απόρρητο και συντήρηση

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

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

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

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

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

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

Μπορεί ένα API παρακολούθησης να εγγυηθεί πληροφορίες παράδοσης σε πραγματικό χρόνο;

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

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

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

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

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

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

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

Πηγές

Loading