Διαχείριση σφαλμάτων και retries στο Boomi

Κάθε integration αποτυγχάνει κάποια στιγμή. Το ERP κάνει restart για μια αναβάθμιση, ένα cloud API επιστρέφει 503 για ένα λεπτό, ένας πελάτης γράφει τον ΑΦΜ με ένα κενό στη μέση. Η διαφορά ανάμεσα σε ένα αξιόπιστο και ένα εύθραυστο integration δεν είναι αν συμβαίνουν σφάλματα, αλλά τι κάνει η ροή μετά. Σε αυτό το άρθρο περιγράφουμε έναν απλό σχεδιασμό διαχείρισης σφαλμάτων που δουλεύει για τις περισσότερες επιχειρηματικές ροές, και τον φτιάχνουμε στο Boomi.

Γιατί το «γράψ’ το στο log και προχώρα» αποτυγχάνει

Η προεπιλεγμένη συμπεριφορά πολλών integrations είναι ένα από δύο άκρα:

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

Ούτε τα «τυφλά» retries βοηθούν. Αν ξαναδοκιμάσετε εκατό φορές έναν κωδικό προϊόντος που λείπει, το προϊόν δεν θα δημιουργηθεί, και αν ξαναδοκιμάσετε αμέσως ένα timeout, ενώ το ERP κάνει restart, απλώς προσθέτετε φορτίο.

Το pattern: κατάταξη, retry, παρκάρισμα, ειδοποίηση

1. Κατατάξτε το σφάλμα

Τα σφάλματα χωρίζονται σε δύο ομάδες, που θέλουν αντίθετη αντιμετώπιση:

Τύπος	Παραδείγματα	Τι κάνετε
Προσωρινό	timeout, connection refused, HTTP `429`, `502`, `503`, `504`, κλειδωμένη εγγραφή	retry αργότερα
Μόνιμο	HTTP `400`, `404`, `422`, σφάλμα επικύρωσης, άγνωστος κωδικός προϊόντος, ΑΦΜ που λείπει	όχι retry, σε άνθρωπο

Τα σφάλματα ταυτοποίησης (401, 403) είναι ειδική περίπτωση: το retry δεν βοηθά, αλλά η αιτία είναι συνήθως θέμα ρυθμίσεων (ένας κωδικός ή ένα token που έληξε) που επηρεάζει κάθε document, οπότε αξίζουν άμεση ειδοποίηση.

2. Retry στα προσωρινά σφάλματα με backoff

Ξαναδοκιμάστε μερικές φορές με αυξανόμενες παύσεις, για παράδειγμα μετά από 10 δευτερόλεπτα, 1 λεπτό και 5 λεπτά. Αυτό λέγεται backoff. Δίνει στο άλλο σύστημα χρόνο να συνέλθει και δεν το «σφυροκοπά». Τα retries είναι ασφαλή μόνο αν η ενέργεια είναι idempotent, ώστε μια δημιουργία που ξανατρέχει να μη φτιάχνει διπλότυπο (δείτε Συγχρονισμός παραγγελιών από το e-shop στο ERP με το Boomi).

3. Παρκάρετε ό,τι δεν διορθώνεται αυτόματα

Τα documents που αποτυγχάνουν μόνιμα, ή αποτυγχάνουν ακόμη μετά από όλα τα retries, πηγαίνουν σε μια ουρά ελέγχου (συχνά λέγεται dead-letter queue). Κρατά τα αρχικά δεδομένα, το μήνυμα σφάλματος και την ώρα, ώστε κάποιος να διορθώσει την αιτία και να τα ξαναστείλει. Το κρίσιμο είναι ότι ένα «παρκαρισμένο» document δεν σταματά τα υπόλοιπα.

4. Ειδοποιήστε τους σωστούς ανθρώπους, μία φορά

Στείλτε μια ειδοποίηση που λέει τι απέτυχε, γιατί και τι πρέπει να γίνει, στην ομάδα που μπορεί να το λύσει. Ομαδοποιήστε: ένα email «12 παραγγελίες απέτυχαν: άγνωστος κωδικός προϊόντος» είναι χρήσιμο, 12 ξεχωριστά emails είναι spam που όλοι μαθαίνουν να αγνοούν.

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

Θα «τυλίξουμε» το βήμα «δημιουργία παραγγελίας στο ERP» του προηγούμενου άρθρου με αυτόν τον σχεδιασμό. Τα δομικά στοιχεία είναι το shape Try/Catch, ένα Decision για τον τύπο του σφάλματος, ένα sub-process για την ουρά ελέγχου και οι ειδοποιήσεις της ίδιας της πλατφόρμας.

Βήμα 1: Βάλτε το επικίνδυνο βήμα σε Try/Catch

Τοποθετήστε ένα shape Try/Catch πριν τον connector του ERP. Ό,τι βρίσκεται στο μονοπάτι Try προστατεύεται.
Ορίστε το failure trigger ώστε να πιάνει σφάλματα σε επίπεδο document, για να «πιάνεται» μόνη της μια παραγγελία που αποτυγχάνει ενώ οι υπόλοιπες συνεχίζουν.
Το Try/Catch έχει ρύθμιση retry count. Όταν είναι πάνω από μηδέν, τα documents που απέτυχαν ξανατρέχουν στο μονοπάτι Try πριν φτάσουν στο Catch, με αυξανόμενη καθυστέρηση ανάμεσα στις προσπάθειες. Έτσι έχετε ένα βασικό backoff χωρίς επιπλέον σχεδιασμό. Ελέγξτε την τρέχουσα τεκμηρίωση για τον μέγιστο αριθμό retries και τις καθυστερήσεις στην έκδοσή σας.

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

Βήμα 2: Κάντε ορατά τα σφάλματα των connectors

Από προεπιλογή, πολλοί connectors θεωρούν μια απάντηση HTTP με σφάλμα ως αποτυχημένο document, που είναι αυτό που θέλετε εδώ. Σε connectors όπου υπάρχει επιλογή, φροντίστε τα σφάλματα να «σηκώνονται» αντί να επιστρέφονται ως κανονική απάντηση, αλλιώς το Try/Catch δεν έχει τίποτα να πιάσει. Όταν χρειάζεστε τον κωδικό κατάστασης στη λογική σας, διαβάστε τον από τα document properties της απάντησης του connector (τα ακριβή ονόματα διαφέρουν ανά connector).

Βήμα 3: Κατάταξη στο μονοπάτι Catch

Στο μονοπάτι Catch, το μήνυμα σφάλματος είναι διαθέσιμο στο process (το Try/Catch το ορίζει ως document property). Προσθέστε ένα shape Decision ή Route που το εξετάζει:

Μηνύματα που ταιριάζουν σε timeouts, σφάλματα σύνδεσης ή κωδικούς όπως 503 πηγαίνουν στον κλάδο των προσωρινών.
Όλα τα υπόλοιπα πηγαίνουν στον κλάδο των μόνιμων.

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

Βήμα 4: Φτιάξτε την ουρά ελέγχου

Δημιουργήστε ένα μικρό sub-process, που καλείται με shape Process Call και από τους δύο κλάδους όταν εξαντληθούν τα retries. Πρέπει να:

Αποθηκεύει το αρχικό document μαζί με το σφάλμα, το όνομα του process και την αναφορά της παραγγελίας (για παράδειγμα ESHOP-58213). Ο προορισμός μπορεί να είναι ένας πίνακας σε βάση, ένας κοινόχρηστος φάκελος, μια Atom Queue ή ένα topic σε event stream. Διαλέξτε αυτό που η ομάδα σας θα κοιτάζει στην πράξη.
Σημειώνει την εγγραφή ως NEW, ώστε ένα process επαναποστολής (ή ένας άνθρωπος) να την πάρει αργότερα και να την αλλάξει σε RESUBMITTED ή CLOSED.

Το Process Reporting του Boomi επιτρέπει επίσης να δείτε τα documents που απέτυχαν και, για κάποιους τύπους process, να τα ξανατρέξετε. Αυτό είναι χρήσιμο για όσους λειτουργούν την πλατφόρμα, αλλά μια ξεχωριστή ουρά ελέγχου δίνει στους χρήστες της επιχείρησης μια λίστα με την οποία δουλεύουν χωρίς πρόσβαση στην πλατφόρμα.

Βήμα 5: Ειδοποιήσεις

Έχετε δύο επίπεδα:

Μέσα στο process: ένα shape Notify στον κλάδο των μόνιμων σφαλμάτων γράφει ένα μήνυμα με σαφές κείμενο (για παράδειγμα «Παραγγελία ESHOP-58213: ο κωδικός SKU-771 δεν βρέθηκε στο ERP»). Οι ειδοποιήσεις αυτές μπορούν να περάσουν στις ειδοποιήσεις και στις συνδρομές email της πλατφόρμας.
Σε επίπεδο πλατφόρμας: ρυθμίστε ειδοποιήσεις email ή συνδρομές σε events για σφάλματα process και προβλήματα runtime (για παράδειγμα ένα runtime που βγαίνει offline), ώστε να μαθαίνετε και για αποτυχίες που δεν φτάνουν ποτέ στο Catch σας.

Αν θέλετε ένα process να τελειώνει ως αποτυχημένο αφού «παρκάρει» τα documents, ώστε να φαίνεται καθαρά στην παρακολούθηση, βάλτε ένα shape Exception στο τέλος του κλάδου των μόνιμων σφαλμάτων.

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

Χαλάστε πράγματα επίτηδες. Βάλτε λάθος port στη σύνδεση του ERP, στείλτε μια παραγγελία με άγνωστο κωδικό προϊόντος και ελέγξτε ότι κάθε περίπτωση καταλήγει στον σωστό κλάδο, με χρήσιμο μήνυμα.
Ελέγξτε το retry για διπλότυπα. Προσομοιώστε ένα timeout αφού το ERP έχει δημιουργήσει την παραγγελία και βεβαιωθείτε ότι το retry δεν δημιουργεί δεύτερη.
Ορίστε υπεύθυνο. Αποφασίστε ποιος κοιτάζει την ουρά ελέγχου και πόσο συχνά. Μια ουρά χωρίς υπεύθυνο είναι απλώς μια πιο αργή εκδοχή του «log και συνέχεια».
Μετράτε. Καταγράφετε τα retries και τα παρκαρισμένα documents ανά εβδομάδα. Μια απότομη αύξηση συνήθως σημαίνει ότι κάτι άλλαξε σε κάποιο από τα συστήματα.

Για παρακολούθηση και ειδοποιήσεις σε όλα τα processes σας, δείτε το Παρακολούθηση και ειδοποιήσεις για integrations στο Boomi.

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

Κατατάξτε τα σφάλματα, κάντε retry με backoff μόνο στα προσωρινά, παρκάρετε τα υπόλοιπα εκεί όπου ένας άνθρωπος μπορεί να τα διορθώσει και να τα ξαναστείλει, και ειδοποιήστε μία φορά με μήνυμα που οδηγεί σε ενέργεια. Στο Boomi, το shape Try/Catch δίνει τη λογική retry και catch, ένα Decision κάνει την κατάταξη και ένα μικρό sub-process δίνει την ουρά ελέγχου. Για την ευρύτερη εικόνα, δείτε τον οδηγό μας Ολοκλήρωση εφαρμογών: ERP, CRM και e-shop χωρίς «μακαρονάδα».