Integration patterns που πρέπει να ξέρει κάθε ομάδα

Τα προβλήματα integration μοιάζουν διαφορετικά εξωτερικά: ένα e-shop που πρέπει να μιλήσει με το ERP, ένα σύστημα αποθήκης που χρειάζεται ενημερώσεις αποθέματος, ένας συνεργάτης που στέλνει τιμολόγια. Από κάτω, αποτελούνται από λίγα επαναλαμβανόμενα patterns. Οι ομάδες που τα ξέρουν παίρνουν καλύτερες αποφάσεις πιο γρήγορα, και μπορούν να τις εξηγήσουν η μία στην άλλη και στους vendors.

Ο οδηγός αυτός καλύπτει τα patterns που χρησιμοποιούμε συχνότερα, σε τι είναι καλό το καθένα, τα λάθη που βλέπουμε και πώς ελέγχετε αν ένα εργαλείο τα υποστηρίζει σωστά. Δεν είναι κατάλογος με κάθε pattern που έχει ποτέ πάρει όνομα. Είναι η σύντομη λίστα που καλύπτει τα περισσότερα επιχειρηματικά integrations.

Τοπολογία: point-to-point ή hub

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

Ένα hub (ή επίπεδο integration) βάζει ένα στοιχείο στη μέση. Κάθε σύστημα συνδέεται στο hub, και το hub δρομολογεί και μετασχηματίζει. Ένα νέο σύστημα σημαίνει μία νέα σύνδεση, όχι πέντε.

Το point-to-point είναι ακόμη μια χαρά για δύο συστήματα που θα μείνουν δύο. Μόλις εμφανιστεί τρίτο ή τέταρτο, ένα hub σχεδόν πάντα αποσβένεται. Σημειώστε ότι το «hub» περιγράφει το λογικό σχήμα, όχι έναν server: οι σύγχρονες πλατφόρμες integration και οι event brokers είναι κατανεμημένοι, αλλά παίζουν τον ρόλο του hub.

Χρονισμός: σύγχρονο ή ασύγχρονο

Αυτή είναι η απόφαση με τη μεγαλύτερη επίδραση στην αξιοπιστία.

Σύγχρονο (sync): αυτός που καλεί στέλνει ένα αίτημα και περιμένει την απάντηση. Εύκολο στην κατανόηση, και απαραίτητο όταν δεν μπορεί να συνεχίσει χωρίς το αποτέλεσμα (για παράδειγμα «υπάρχει απόθεμα;» στο checkout). Το μειονέκτημα είναι η σύζευξη: αν το σύστημα που απαντά είναι αργό ή εκτός λειτουργίας, το ίδιο γίνεται και αυτός που καλεί.
Ασύγχρονο (async): αυτός που καλεί παραδίδει το μήνυμα και συνεχίζει. Η δουλειά γίνεται αργότερα, συνήθως μέσω μιας ουράς. Τα αργά συστήματα, τα παράθυρα συντήρησης και οι αιχμές απορροφώνται από την ουρά. Το μειονέκτημα είναι ότι δεν υπάρχει άμεσο αποτέλεσμα, οπότε χρειάζεστε τρόπο να αναφέρετε την κατάσταση ή τις αποτυχίες αργότερα.

Ένας καλός κανόνας: σύγχρονες κλήσεις για ερωτήσεις που θέλουν απάντηση τώρα, και ασύγχρονα μηνύματα για εντολές και γεγονότα που μπορούν να επεξεργαστούν λίγα δευτερόλεπτα ή λεπτά αργότερα. Συγκρίνουμε τα δύο στην πράξη στο Sync ή async integration στο Boomi.

Τρόποι αλληλεπίδρασης

Request-reply

Ένα σύστημα ρωτά, το άλλο απαντά. Συνήθως σύγχρονα (μια κλήση REST), αλλά γίνεται και ασύγχρονα, με την απάντηση να στέλνεται σε μια ουρά απαντήσεων και να αντιστοιχίζεται με ένα correlation ID. Το request-reply είναι το σωστό μοντέλο για αναζητήσεις, επικυρώσεις και ό,τι περιμένει ο χρήστης.

Fire-and-forget

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

Publish/subscribe

Ένα σύστημα ανακοινώνει ότι κάτι συνέβη («η παραγγελία 58213 πληρώθηκε») σε ένα topic, και οσοιδήποτε subscribers αντιδρούν: το ERP εκδίδει τιμολόγιο, η αποθήκη ετοιμάζει τη συλλογή, το CRM ενημερώνει το ιστορικό του πελάτη. Ο publisher δεν ξέρει και δεν τον νοιάζει ποιος ακούει. Νέοι καταναλωτές προστίθενται χωρίς να αγγίξετε τον publisher. Το pub/sub είναι ο πυρήνας της event-driven αρχιτεκτονικής, που καλύπτουμε στον οδηγό για event-driven integration.

Όγκος: batch ή πραγματικός χρόνος

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

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

Πολλές ροές καταλήγουν κάπου στη μέση: micro-batches ανά λίγα λεπτά, ή πραγματικός χρόνος για τις σημαντικές αλλαγές και ένα νυχτερινό batch που συμφωνεί όλα τα υπόλοιπα. Διαλέξτε ρωτώντας πόσο «μπαγιάτικα» μπορούν να είναι τα δεδομένα πριν δημιουργήσουν πρόβλημα, όχι επιλέγοντας «real-time επειδή ακούγεται καλύτερα».

Δεδομένα: το canonical model

Όταν πολλά συστήματα ανταλλάσσουν τα ίδια επιχειρηματικά αντικείμενα (πελάτες, παραγγελίες, προϊόντα), κάθε ζευγάρι συστημάτων μπορεί να έχει το δικό του mapping, ή κάθε σύστημα να κάνει mapping από και προς μία κοινή μορφή, το canonical data model. Με canonical model, ένα νέο σύστημα σημαίνει δύο mappings (προς και από το canonical), όχι ένα για κάθε άλλο σύστημα.

Το αντίτιμο είναι η προσπάθεια σχεδιασμού και η διακυβέρνηση: κάποιος πρέπει να «έχει» το canonical model και να μην το αφήσει να γίνει «η ένωση όλων των πεδίων όλων των συστημάτων». Δουλεύει καλύτερα για λίγα βασικά αντικείμενα που μοιράζονται πολλές ροές. Φτιάχνουμε ένα στο Canonical data model στο Boomi.

Αξιοπιστία: idempotency

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

Το idempotency είναι αυτό που κάνει ασφαλή τα retries, τις επαναλήψεις και την παράδοση «τουλάχιστον μία φορά». Κάθε δημιουργία σε ένα integration πρέπει να έχει απάντηση στο «τι γίνεται αν τρέξει δύο φορές;». Ένα παράδειγμα θα βρείτε στο Συγχρονισμός παραγγελιών από το e-shop στο ERP με το Boomi.

Συνηθισμένα λάθη

Σύγχρονες αλυσίδες. Το e-shop καλεί το integration, που καλεί το ERP, που καλεί το σύστημα αποθήκης, ενώ ο πελάτης περιμένει. Ο πιο αργός κρίκος ορίζει τον χρόνο απόκρισης, και κάθε αποτυχία σπάει όλη την αλυσίδα.
Real-time για τα πάντα. Οι ροές πραγματικού χρόνου είναι πιο δύσκολες στην παρακολούθηση και την ανάκαμψη. Χρησιμοποιήστε τες εκεί όπου η καθυστέρηση έχει πραγματικά σημασία.
Pub/sub χωρίς υπεύθυνο. Topics όπου ο καθένας δημοσιεύει οτιδήποτε, χωρίς συμφωνημένη μορφή μηνυμάτων, γίνονται ένα νέο είδος «μακαρονάδας».
Canonical model που θέλει να είναι τα πάντα. Αν έχει 300 πεδία και κάθε ομάδα προσθέτει κι άλλα, παύει να είναι κοινή γλώσσα.
Υπόθεση ότι η παράδοση γίνεται ακριβώς μία φορά. Τα περισσότερα συστήματα μηνυμάτων παραδίδουν τουλάχιστον μία φορά. Σχεδιάστε τους καταναλωτές ώστε να είναι idempotent.
Χωρίς correlation IDs. Χωρίς ένα ID που ταξιδεύει με το μήνυμα από σύστημα σε σύστημα, η ανίχνευση ενός προβλήματος σημαίνει σύγκριση timestamps με το χέρι.

Πώς να συγκρίνετε εργαλεία

Όταν αξιολογείτε μια πλατφόρμα, ελέγξτε πώς υποστηρίζει τα patterns που χρειάζεστε, όχι μόνο τη λίστα connectors:

Sync και async: μπορεί να εκθέσει APIs και επίσης να διαβάζει και να γράφει μηνύματα σε ουρές ή topics, εγγενώς;
Εγγυήσεις παράδοσης: τι εγγυήσεις δίνουν οι ουρές ή τα event streams της, και πώς χειρίζεται τα μηνύματα που αποτυγχάνουν (dead-letter queues, replay);
Κατάσταση: μπορεί μια ροή να κρατά ένα watermark ή να ελέγχει προηγούμενες εκτελέσεις, για σταδιακές φορτώσεις και idempotency;
Επαναχρησιμοποίηση: μπορούν να μοιράζονται mappings, profiles και υπο-ροές, ώστε ένα canonical model να συντηρείται μία φορά;
Batch και πραγματικός χρόνος: χειρίζεται καλά και μεγάλες προγραμματισμένες φορτώσεις και μεμονωμένα μηνύματα χαμηλής καθυστέρησης;
Παρατηρησιμότητα: μπορείτε να ακολουθήσετε ένα επιχειρηματικό έγγραφο, με το ID του, σε όλες τις ροές από τις οποίες πέρασε;

Τα εργαλεία της αγοράς

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

Apache Camel. Open-source framework σε Java που υλοποιεί τα κλασικά enterprise integration patterns ως δομικά στοιχεία, με μεγάλο σύνολο components. Δυνατή επιλογή για ομάδες developers που θέλουν τα patterns σε κώδικα και μπορούν να λειτουργούν τις δικές τους υπηρεσίες.
Apache Kafka. Κατανεμημένη πλατφόρμα event streaming, ευρέως διαδεδομένη για pub/sub, event sourcing και ροές δεδομένων μεγάλου όγκου, διαθέσιμη ως open source και ως managed υπηρεσία από αρκετούς vendors. Είναι ραχοκοκαλιά για events και όχι πλήρες εργαλείο integration, οπότε το mapping και η συνδεσιμότητα έρχονται συνήθως από άλλα στοιχεία.
Azure Integration Services. Οικογένεια υπηρεσιών Azure (Logic Apps, Service Bus, Event Grid, API Management, Functions) που μαζί καλύπτουν ροές εργασιών, μηνύματα, events και APIs. Ταιριάζει σε οργανισμούς που ήδη χρησιμοποιούν Azure και δεν τους πειράζει να συνδυάζουν πολλές υπηρεσίες.
Boomi. Πλατφόρμα integration low-code όπου τα processes υποστηρίζουν request-reply APIs, προγραμματισμένα batch και event-driven ροές, ενώ το Boomi Event Streams προσθέτει pub/sub μηνύματα. Τα profiles, τα maps και τα sub-processes μοιράζονται ανάμεσα σε processes, κάτι που βολεύει για ένα canonical model. Ταιριάζει καλύτερα όταν θέλετε αυτά τα patterns διαθέσιμα σε μία οπτική πλατφόρμα χωρίς να συναρμολογείτε ξεχωριστές υπηρεσίες.
MuleSoft Anypoint. Πλατφόρμα integration και APIs με προσέγγιση API-led, με δυνατότητες μηνυμάτων και πλούσια εργαλεία για developers. Δημοφιλής σε μεγάλες επιχειρήσεις με αφοσιωμένες ομάδες integration.

Οι περισσότερες πραγματικές αρχιτεκτονικές συνδυάζουν περισσότερα από ένα: μια πλατφόρμα integration για συνδεσιμότητα και mapping, έναν event broker για ροές μεγάλου όγκου και ένα gateway για τα APIs. Τα patterns είναι αυτά που κρατούν αυτόν τον συνδυασμό συνεκτικό.

Επόμενα βήματα

Δύο πρακτικά άρθρα εφαρμόζουν τα patterns αυτού του οδηγού στο Boomi:

Sync ή async integration στο Boomi: πότε περιμένετε την απάντηση, και πώς δέχεστε ένα αίτημα αμέσως και το επεξεργάζεστε στο παρασκήνιο.
Canonical data model στο Boomi: κοινά profiles και maps από την πηγή στο canonical και από εκεί στον προορισμό.