Συγχρονισμός παραγγελιών από το e-shop στο ERP με το Boomi

Η μεταφορά των παραγγελιών του e-shop στο ERP είναι συνήθως το πρώτο integration που φτιάχνει μια εταιρεία, και αυτό που πονάει περισσότερο όταν στραβώσει. Μια παραγγελία που χάθηκε σημαίνει δυσαρεστημένο πελάτη. Μια διπλή παραγγελία σημαίνει διπλή τιμολόγηση, λάθος αποθέματα και ένα απόγευμα με πιστωτικά. Σε αυτό το άρθρο εξηγούμε τα δύο patterns που προλαμβάνουν και τα δύο προβλήματα, και μετά φτιάχνουμε τη ροή βήμα βήμα στο Boomi.

Γιατί η απλή λύση αποτυγχάνει

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

Χάνονται παραγγελίες. Η ροή έτρεξε αργότερα, ή απέτυχε μία φορά, ή το ρολόι του server ήταν λίγο εκτός. Όποια παραγγελία πέσει στο κενό ανάμεσα σε δύο παράθυρα δεν διαβάζεται ποτέ.
Διπλασιάζονται παραγγελίες. Η κλήση στο ERP έκανε timeout, αλλά το ERP στην πραγματικότητα δημιούργησε την παραγγελία. Η ροή ξαναδοκιμάζει και τη δημιουργεί ξανά. Ή δύο εκτελέσεις επικαλύπτονται και διαβάζουν και οι δύο την ίδια παραγγελία.
Χάνονται αλλαγές. Μια παραγγελία που πληρώθηκε στις 10:02 και ακυρώθηκε στις 10:15 διαβάζεται μία φορά και ποτέ ξανά.

Το pattern: watermark και idempotency

Δύο απλές ιδέες το λύνουν.

1. Σταδιακό polling με watermark

Αντί για «τα τελευταία 10 λεπτά», θυμηθείτε πού σταματήσατε. Μετά από κάθε επιτυχημένη εκτέλεση, αποθηκεύστε το μεγαλύτερο updated_at που επεξεργαστήκατε (το watermark). Η επόμενη εκτέλεση ζητά από το e-shop τις παραγγελίες που άλλαξαν μετά από το watermark. Αν μια εκτέλεση αποτύχει, το watermark δεν μετακινείται, οπότε η επόμενη συνεχίζει από το ίδιο σημείο. Τίποτα δεν πέφτει σε κενό.

Δύο λεπτομέρειες έχουν σημασία:

Πάρτε το watermark από τα δεδομένα (το τελευταίο updated_at που πράγματι επεξεργαστήκατε), όχι από το ρολόι του server του integration.
Χρησιμοποιήστε «μεγαλύτερο ή ίσο» και μια μικρή επικάλυψη (για παράδειγμα ένα λεπτό πίσω) αν τα timestamps του e-shop δεν έχουν μεγάλη ακρίβεια. Η επικάλυψη θα φέρει μερικές παραγγελίες δύο φορές, που δεν πειράζει, χάρη στη δεύτερη ιδέα.

2. Idempotent δημιουργία

Μια ενέργεια είναι idempotent αν το να γίνει δύο φορές έχει το ίδιο αποτέλεσμα με το να γίνει μία. Για τις παραγγελίες, αυτό σημαίνει ότι το ERP πρέπει να αναγνωρίζει μια παραγγελία που ήδη έχει. Ο συνηθισμένος τρόπος είναι να αποθηκεύετε τον αριθμό παραγγελίας του e-shop στην παραγγελία του ERP, για παράδειγμα σε ένα πεδίο «εξωτερική αναφορά», και να τον ελέγχετε πριν τη δημιουργία:

για κάθε παραγγελία μετά το watermark:
    αν το ERP έχει παραγγελία με externalRef = "ESHOP-58213":
        ενημέρωσέ την αν άλλαξε η κατάσταση, αλλιώς προσπέρασέ την
    αλλιώς:
        δημιούργησέ την με externalRef = "ESHOP-58213"
μετακίνησε το watermark στο τελευταίο updated_at που επεξεργάστηκες

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

Υλοποίηση στο Boomi

Το παράδειγμα χρησιμοποιεί ένα REST API τύπου WooCommerce στην πλευρά του e-shop και ένα ERP με REST ή SOAP API. Η ίδια δομή δουλεύει και για άλλα e-shops και ERP, αλλάζουν μόνο οι connectors.

Βήμα 1: Αποθήκευση του watermark

Το Boomi επιτρέπει σε ένα process να κρατά τιμές από εκτέλεση σε εκτέλεση με τα persisted process properties. Δημιουργήστε ένα dynamic process property, για παράδειγμα LAST_ORDER_UPDATED_AT, και ορίστε το ως persisted όταν του δίνετε τιμή σε ένα shape Set Properties. Η τιμή του διατηρείται από τη μία εκτέλεση στην επόμενη στο ίδιο runtime.

Για την πρώτη εκτέλεση, δώστε του μια λογική αρχική τιμή (για παράδειγμα την ημερομηνία έναρξης λειτουργίας), ώστε το process να μην προσπαθήσει να φέρει όλο το ιστορικό του e-shop.

Βήμα 2: Ανάγνωση των παραγγελιών που άλλαξαν

Ξεκινήστε το process με start shape τύπου No Data και ορίστε χρονοπρόγραμμα αργότερα στο deployment (για παράδειγμα κάθε πέντε λεπτά).
Προσθέστε ένα connector shape HTTP Client (ή τον ειδικό connector του e-shop, αν υπάρχει) με operation GET στο endpoint των παραγγελιών.
Περάστε το watermark ως query parameter, για παράδειγμα modified_after. Στο operation του HTTP Client μπορείτε να ορίσετε μεταβλητές αντικατάστασης στο resource path και να τις γεμίσετε από το process property.
Φροντίστε τη σελιδοποίηση. Τα περισσότερα APIs e-shop επιστρέφουν 50 ή 100 παραγγελίες ανά σελίδα. Επαναλάβετε μέχρι να έρθει άδεια σελίδα, ή χρησιμοποιήστε την υποστήριξη paging του connector, όπου υπάρχει.
Χωρίστε την απάντηση σε ένα document ανά παραγγελία (ένα shape Data Process με split βάσει profile είναι συνηθισμένος τρόπος), ώστε κάθε παραγγελία να πετυχαίνει ή να αποτυγχάνει μόνη της.

Βήμα 3: Mapping στην παραγγελία του ERP

Χρησιμοποιήστε ένα shape Map από το profile της παραγγελίας του e-shop στο profile της παραγγελίας του ERP. Τυπικές δουλειές εδώ:

Αντιστοιχίστε τον αριθμό παραγγελίας του e-shop στο πεδίο εξωτερικής αναφοράς του ERP, για παράδειγμα ESHOP-58213.
Μεταφράστε κωδικούς: τρόποι πληρωμής, τρόποι αποστολής και κατηγορίες ΦΠΑ. Ένα cross reference table κρατά αυτές τις λίστες σε ένα σημείο (δείτε Cross reference tables στο Boomi).
Βρείτε τον πελάτη: αναζητήστε τον πελάτη του ERP με email ή ΑΦΜ, ή στείλτε την παραγγελία σε ένα sub-process που δημιουργεί πρώτα τον πελάτη, για παράδειγμα C-1042.

Βήμα 4: Έλεγχος πριν τη δημιουργία

Πριν την κλήση δημιουργίας, ζητήστε από το ERP μια παραγγελία με την ίδια εξωτερική αναφορά. Μετά χρησιμοποιήστε ένα shape Decision:

Δεν βρέθηκε: δημιουργήστε την παραγγελία.
Βρέθηκε: συγκρίνετε την κατάσταση. Αν άλλαξε στο e-shop (για παράδειγμα σε ακυρωμένη), ενημερώστε την. Αλλιώς σταματήστε αθόρυβα, είναι μια αβλαβής επανάληψη.

Αν το ERP σας υποστηρίζει upsert ή unique constraint στην εξωτερική αναφορά, χρησιμοποιήστε το επιπλέον. Ο έλεγχος πριν τη δημιουργία μπορεί ακόμη να «συγκρουστεί» αν τρέχουν δύο εκτελέσεις ταυτόχρονα, οπότε φροντίστε και να μην επικαλύπτονται οι εκτελέσεις. Τα processes του Boomi έχουν μια επιλογή που ορίζει αν επιτρέπονται ταυτόχρονες εκτελέσεις. Κρατήστε την απενεργοποιημένη για αυτό το process (τα ακριβή ονόματα των επιλογών μπορεί να αλλάζουν από έκδοση σε έκδοση).

Βήμα 5: Μετακίνηση του watermark μόνο μετά την επιτυχία

Στο τέλος του επιτυχημένου μονοπατιού, δώστε στο LAST_ORDER_UPDATED_AT το μεγαλύτερο updated_at από τις παραγγελίες που επεξεργαστήκατε. Ένας απλός τρόπος είναι να κρατάτε το μέγιστο σε ένα dynamic process property καθώς περνούν τα documents, και να το κάνετε persist στο τελευταίο Set Properties.

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

Πριν βγείτε σε παραγωγή

Τρέξτε το δύο φορές επίτηδες. Γυρίστε το watermark μία ώρα πίσω και ξανατρέξτε το process. Τίποτα καινούργιο δεν πρέπει να εμφανιστεί στο ERP. Είναι το καλύτερο μεμονωμένο τεστ για το idempotency.
Δοκιμάστε τα κενά. Σταματήστε το χρονοπρόγραμμα για μία ώρα, βάλτε μερικές δοκιμαστικές παραγγελίες και ξεκινήστε το ξανά. Πρέπει να έρθουν όλες.
Παρακολουθήστε την πρώτη αιχμή. Ελέγξτε τους χρόνους εκτέλεσης στις πρώτες προσφορές ή καμπάνιες, και προσαρμόστε το χρονοπρόγραμμα και το μέγεθος σελίδας αν μια εκτέλεση διαρκεί περισσότερο από το διάστημα.
Καταγράψτε την εξωτερική αναφορά. Προσθέστε τον αριθμό παραγγελίας του e-shop στα logs ή στα tracked fields του process, ώστε να απαντάτε σε δευτερόλεπτα στο «έφτασε η παραγγελία 58213 στο ERP;».
Τεκμηριώστε το watermark. Γράψτε πού βρίσκεται και πώς γίνεται reset, για τη μέρα που κάποιος θα χρειαστεί να ξανασυγχρονίσει μια περίοδο.

Συνοψίζοντας

Το watermark εξασφαλίζει ότι δεν χάνεται τίποτα, και η idempotent δημιουργία ότι δεν διπλασιάζεται τίποτα. Μαζί μετατρέπουν τον συγχρονισμό παραγγελιών από ένα εύθραυστο χρονόμετρο σε ροή που μπορείτε να ξανατρέξετε όποτε θέλετε. Στο Boomi, τα persisted process properties κρατούν το watermark, και μια αναζήτηση μαζί με ένα shape Decision κάνουν τη δημιουργία idempotent. Για την ευρύτερη εικόνα, δείτε τον οδηγό μας Ολοκλήρωση εφαρμογών: ERP, CRM και e-shop χωρίς «μακαρονάδα», και συνεχίστε με το Διαχείριση σφαλμάτων και retries στο Boomi.