Publish μία φορά, πολλοί consumers: pub/sub με το Boomi Event Streams

Μια νέα παραγγελία στο e-shop πρέπει να φτάσει σε τρία σημεία: στο σύστημα της αποθήκης, για να γίνει η συλλογή· στο ERP, για να εκδοθεί το τιμολόγιο· και στο CRM, για να βλέπουν οι πωλήσεις τι αγόρασε ο πελάτης. Σε αυτό το άρθρο εξηγούμε γιατί ο προφανής τρόπος γίνεται εύθραυστος, περιγράφουμε το pattern publish/subscribe που τον αντικαθιστά, και μετά το υλοποιούμε με το Boomi Event Streams και το Boomi Integration.

Το πρόβλημα με ένα process που καλεί όλους

Η πρώτη εκδοχή συνήθως μοιάζει έτσι:

e-shop ──► integration process ──► αποθήκη ──► ERP (τιμολόγιο) ──► CRM

Φτιάχνεται εύκολα και δουλεύει την πρώτη μέρα. Μετά έρχεται η πραγματικότητα:

• Ένα αργό σύστημα καθυστερεί όλα τα άλλα. Αν το CRM απαντά σε οκτώ δευτερόλεπτα, κάθε παραγγελία αργεί οκτώ δευτερόλεπτα.
• Μία αποτυχία σταματά τα πάντα. Αν το ERP κάνει το νυχτερινό backup, ούτε η αποθήκη παίρνει την παραγγελία, παρότι λειτουργεί κανονικά.
• Η μερική επιτυχία δύσκολα αναιρείται. Η αποθήκη πήρε την παραγγελία, η τιμολόγηση απέτυχε, το CRM δεν κλήθηκε ποτέ. Αν ξανατρέξετε όλο το process, γίνεται διπλή συλλογή.
• Κάθε νέος consumer σημαίνει αλλαγή στον producer. Η προσθήκη του προγράμματος επιβράβευσης σημαίνει αλλαγή και ξανά testing στο process από το οποίο εξαρτώνται όλοι.

Το pattern: publish μία φορά, ανεξάρτητα subscriptions

Με το publish/subscribe, το integration που παραλαμβάνει την παραγγελία κάνει ένα πράγμα: δημοσιεύει ένα event order.created σε ένα topic. Κάθε σύστημα που ενδιαφέρεται έχει το δικό του subscription στο topic και το δικό του consumer process.

                          ┌─► subscription: warehouse ──► process αποθήκης ──► WMS
e-shop ──► producer ──► topic: orders.created ──► subscription: invoicing ──► process τιμολόγησης ──► ERP
                          └─► subscription: crm ──► process CRM ──► CRM

Κάθε subscription παίρνει το δικό του αντίγραφο από κάθε event και κρατά τη δική του θέση. Αν το CRM είναι εκτός για μία ώρα, στο subscription του μαζεύεται backlog ενώ η αποθήκη και η τιμολόγηση συνεχίζουν. Όταν το CRM επιστρέψει, ο consumer του καλύπτει τη διαφορά. Η προσθήκη του προγράμματος επιβράβευσης αργότερα είναι ένα νέο subscription και ένα νέο process, χωρίς καμία αλλαγή στον producer.

Δύο κανόνες το κάνουν ασφαλές:

• Οι consumers πρέπει να είναι idempotent. Η παράδοση είναι at-least-once, οπότε το process τιμολόγησης πρέπει να αναγνωρίζει μια παραγγελία που έχει ήδη τιμολογήσει.
• Το event είναι γεγονός, όχι εντολή. Το order.created λέει τι συνέβη. Κάθε consumer αποφασίζει τι σημαίνει αυτό για το δικό του σύστημα.

Υλοποίηση με το Boomi Event Streams

Το Boomi Event Streams είναι ο managed event broker της πλατφόρμας Boomi, χτισμένος πάνω στο Apache Pulsar. Τα topics και τα subscriptions τα διαχειρίζεστε στην υπηρεσία Event Streams, και τα processes του Boomi Integration παράγουν και καταναλώνουν events μέσω του Boomi Event Streams connector. Οι ακριβείς ετικέτες στα μενού και οι επιλογές των operations μπορεί να αλλάζουν από έκδοση σε έκδοση, οπότε χρησιμοποιήστε τα παρακάτω βήματα ως οδηγό για τη σειρά της δουλειάς και ελέγξτε την τρέχουσα τεκμηρίωση για τα ονόματα των πεδίων.

Βήμα 1: Σχεδιάστε το event

Συμφωνήστε τη μορφή του event πριν φτιάξετε οτιδήποτε. Κρατήστε το μικρό αλλά αυτάρκες, με event ID για idempotency:

{
  "eventId": "7f1c2e9a-4b1d-4c55-9a51-2d1f0b7c9e10",
  "type": "order.created",
  "version": 1,
  "occurredAt": "2026-10-23T09:14:02Z",
  "orderId": "58213",
  "customerId": "C-1042",
  "currency": "EUR",
  "total": 184.50,
  "shipTo": { "city": "Θεσσαλονίκη", "postalCode": "54625" },
  "lines": [
    { "sku": "OL-500", "description": "Ελαιόλαδο 500 ml", "qty": 2, "unitPrice": 8.90 },
    { "sku": "HN-250", "description": "Θυμαρίσιο μέλι 250 g", "qty": 3, "unitPrice": 6.50 }
  ]
}

Φτιάξτε ένα JSON profile για αυτό στο Boomi. Producer και consumers θα χρησιμοποιούν όλοι το ίδιο profile, ώστε το συμβόλαιο να βρίσκεται σε ένα σημείο.

Βήμα 2: Δημιουργήστε το topic και τα subscriptions

1. Στο Event Streams, επιλέξτε το environment (π.χ. test) και δημιουργήστε ένα topic με όνομα orders.created.
2. Δημιουργήστε ένα subscription για κάθε σύστημα που καταναλώνει: warehouse, invoicing και crm. Δώστε τους το όνομα του consumer, όχι του process, ώστε να έχουν νόημα και όταν αλλάξει η δομή των processes.
3. Δημιουργήστε ένα access token για το environment με δικαίωμα produce και consume. Θα το χρησιμοποιήσετε στο connection του connector. Αντιμετωπίστε το ως μυστικό και αποθηκεύστε το μόνο στο connection component.

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

Βήμα 3: Φτιάξτε το producer process

1. Ξεκινήστε το process εκεί που φτάνει η παραγγελία. Αν το e-shop στέλνει webhook, χρησιμοποιήστε listener Web Services Server· αν κάνετε polling στο API του e-shop, ένα προγραμματισμένο process με τον connector του e-shop ή τον HTTP Client connector.
2. Με ένα Map shape μετατρέψτε την παραγγελία του e-shop στο profile order.created. Εδώ δημιουργείτε το eventId (ή χρησιμοποιείτε ένα σταθερό ID από την πηγή, που διευκολύνει τον εντοπισμό διπλοτύπων από retries).
3. Προσθέστε ένα Connector shape με τον Boomi Event Streams connector, ένα connection με το token σας και ένα operation με την ενέργεια Produce για το topic orders.created.
4. Αν η παραγγελία έχει φυσικό κλειδί, όπως ο αριθμός παραγγελίας, ορίστε το ως message key όπου το επιτρέπει το operation. Έτσι events με το ίδιο κλειδί μπορούν να κρατούν τη σειρά τους για όσους consumers τη χρειάζονται.

Ο producer είναι πλέον έτοιμος και δεν θα χρειαστεί αλλαγή όταν προστεθούν consumers.

Βήμα 4: Ένα consumer process ανά σύστημα

Κάθε consumer είναι ξεχωριστό process που ξεκινά με τον Event Streams connector σε λειτουργία listen:

1. Φτιάξτε ένα process του οποίου το Start shape χρησιμοποιεί τον Boomi Event Streams connector με operation listen (consume) στο topic orders.created και το subscription του συστήματος, π.χ. invoicing.
2. Ελέγξτε πρώτα για idempotency. Για την τιμολόγηση, αναζητήστε τον αριθμό web παραγγελίας στο ERP (ή σε έναν μικρό πίνακα με τα event IDs που έχουν επεξεργαστεί). Αν η παραγγελία υπάρχει ήδη, τερματίστε τη διαδρομή χωρίς ενέργεια.
3. Κάντε mapping του event σε ό,τι περιμένει ο προορισμός: παραστατικό πώλησης στο ERP, αίτημα συλλογής στην αποθήκη, δραστηριότητα ή παραγγελία στο CRM.
4. Καλέστε τον προορισμό με τον connector του.
5. Τυλίξτε την κλήση σε ένα Try/Catch shape, ώστε οι αποτυχίες να αντιμετωπίζονται συνειδητά. Τι κάνετε με τις αποτυχίες είναι το θέμα του άρθρου μας για τα dead-letter topics.

Επαναλάβετε για warehouse και crm. Τα τρία processes μοιράζονται το profile του event και τίποτε άλλο.

Βήμα 5: Deploy και δοκιμή

1. Κάντε deploy τον producer και τους τρεις consumers στο runtime του environment. Τα listener processes παίρνουν events μόνο όσο είναι deployed και οι listeners τους τρέχουν.
2. Στείλτε μία δοκιμαστική παραγγελία από το e-shop (ή κάντε post το δείγμα JSON στον producer).
3. Στο Event Streams, ελέγξτε το topic: ένα μήνυμα μέσα, και το backlog κάθε subscription να επιστρέφει στο μηδέν.
4. Στο Process Reporting θα πρέπει να δείτε μία εκτέλεση του producer και τρεις εκτελέσεις consumers.

Μετά δοκιμάστε τις ενδιαφέρουσες περιπτώσεις:

• Σταματήστε έναν consumer (π.χ. τον listener του CRM), στείλτε μερικές παραγγελίες και δείτε το backlog του subscription crm να μεγαλώνει ενώ αποθήκη και τιμολόγηση συνεχίζουν. Ξεκινήστε τον ξανά και δείτε τον να καλύπτει τη διαφορά.
• Στείλτε το ίδιο event δύο φορές και ελέγξτε ότι στο ERP υπάρχει μία παραγγελία πώλησης, όχι δύο.

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

• Ένα subscription ανά σύστημα, όχι ανά έκδοση process. Αν μετονομάσετε ένα subscription, το νέο ξεκινά άδειο και το παλιό συνεχίζει να μαζεύει events που κανείς δεν διαβάζει.
• Παρακολουθείτε τα backlogs. Ένα backlog που μεγαλώνει είναι το πρώτο σημάδι ότι ένας consumer έχει κολλήσει. Βάλτε ειδοποίηση.
• Ξεχωριστά environments. Χρησιμοποιήστε διαφορετικά environments και tokens του Event Streams για test και παραγωγή, ώστε μια δοκιμαστική παραγγελία να μη φτάσει ποτέ στην πραγματική αποθήκη.
• Εκδόσεις στο event. Προσθέτετε πεδία ελεύθερα· για αλλαγές που «σπάνε», δημοσιεύστε νέα έκδοση ή νέο topic και μεταφέρετε τους consumers έναν έναν. Ένα κοινό canonical model βοηθά (δείτε Canonical data model στο Boomi).
• Σχέδιο για poison messages πριν φτάσει το πρώτο.

Σύνοψη

Η δημοσίευση ενός event order.created και τα ανεξάρτητα subscriptions ανά σύστημα μετατρέπουν μια εύθραυστη αλυσίδα σε μικρά processes που αποτυγχάνουν και επανέρχονται το καθένα μόνο του. Στο Boomi, το Event Streams κρατά το topic και τα subscriptions, και κάθε consumer είναι ένα κανονικό integration process με τη δική του λογική. Για τις έννοιες πίσω από αυτό, και για το πότε τα events δεν είναι το σωστό εργαλείο, δείτε τον οδηγό μας Event-driven integration: τι είναι και πότε το χρειάζεστε.