Canonical data model στο Boomi

Το πρώτο integration παραγγελιών κάνει mapping από το e-shop κατευθείαν στο ERP. Μετά έρχεται ένα marketplace και αποκτά το δικό του mapping προς το ERP. Μετά το σύστημα αποθήκης χρειάζεται κι αυτό παραγγελίες, οπότε προστίθενται mappings από το e-shop και το marketplace προς το WMS. Μετά αλλάζει το ERP, και καθένα από αυτά τα mappings πρέπει να ξαναγραφτεί. Σε αυτό το άρθρο εξηγούμε το canonical data model, το pattern που κρατά αυτή την κατάσταση υπό έλεγχο, και το φτιάχνουμε στο Boomi.

Γιατί τα απευθείας mappings δεν κλιμακώνονται

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

e-shop ──────► ERP          3 πηγές × 2 προορισμοί = 6 mappings
marketplace ─► ERP
B2B portal ──► ERP          και οι ίδιοι επιχειρηματικοί κανόνες
e-shop ──────► WMS          (κωδικοί ΦΠΑ, τρόποι πληρωμής, διευθύνσεις)
marketplace ─► WMS          αντιγραμμένοι σε καθένα από αυτά
B2B portal ──► WMS

Κάθε νέο σύστημα προσθέτει αρκετά mappings. Κάθε αλλαγή σε έναν επιχειρηματικό κανόνα πρέπει να γίνει σε πολλά σημεία, και αργά ή γρήγορα κάποιο ξεχνιέται.

Το pattern: mapping μία φορά σε ένα κοινό μοντέλο

Ένα canonical data model είναι ο δικός σας ορισμός, ανεξάρτητος από συστήματα, για ένα επιχειρηματικό αντικείμενο. Κάθε πηγή κάνει mapping προς αυτό, κάθε προορισμός από αυτό:

e-shop ──────┐                 ┌──► ERP
marketplace ─┼──► canonical ──┼──► WMS
B2B portal ──┘     παραγγελία  └──► (επόμενο σύστημα)

Τρεις πηγές και δύο προορισμοί θέλουν τώρα πέντε mappings αντί για έξι, και η διαφορά μεγαλώνει γρήγορα: με πέντε πηγές και τέσσερις προορισμούς είναι εννέα αντί για είκοσι. Το σημαντικότερο: ένας νέος προορισμός θέλει ένα νέο mapping, και η αλλαγή του ERP αγγίζει ένα mapping.

Κανόνες σχεδιασμού που το κρατούν χρήσιμο

Μοντελοποιήστε την επιχείρηση, όχι ένα σύστημα. Ονομάστε το customer.vatNumber, όχι AFM ή billing_vat. Χρησιμοποιήστε δικούς σας κωδικούς για πράγματα όπως οι τρόποι πληρωμής, και μεταφράστε τους κωδικούς των συστημάτων στις άκρες.
Ξεκινήστε μικρά. Βάλτε τα πεδία που χρειάζονται τουλάχιστον δύο ροές. Μια canonical παραγγελία με 25 καλά ορισμένα πεδία είναι πιο χρήσιμη από μία με 300 προαιρετικά.
Να είστε σαφείς στις μορφές. Ημερομηνίες σε ISO 8601, ποσά με δεκαδική τελεία και νόμισμα, κωδικοί χωρών σε ISO 3166. Αποφασίστε μία φορά και τεκμηριώστε το.
Βάλτε του εκδόσεις. Προσθέστε ελεύθερα προαιρετικά πεδία, αλλά αντιμετωπίστε τη διαγραφή ή μετονομασία πεδίου ως αλλαγή που «σπάει» τις ροές.
Δώστε του υπεύθυνο. Ένας άνθρωπος ή μία ομάδα εγκρίνει τις αλλαγές, αλλιώς γίνεται η ένωση των επιθυμιών όλων.

Ένα σύντομο παράδειγμα canonical παραγγελίας:

{
  "orderNumber": "ESHOP-58213",
  "source": "ESHOP",
  "orderDate": "2026-10-23T09:14:00+03:00",
  "customer": { "customerId": "C-1042", "name": "Papadopoulos SA", "vatNumber": "EL099999999", "email": "orders@example.gr" },
  "payment": { "method": "CARD", "status": "PAID" },
  "currency": "EUR",
  "lines": [
    { "sku": "SKU-771", "quantity": 2, "unitPrice": 24.90, "vatRate": 24 }
  ],
  "shipTo": { "street": "Ermou 10", "city": "Athens", "postalCode": "10563", "country": "GR" }
}

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

Στο Boomi, ένα canonical model φτιάχνεται από συνηθισμένα components, οργανωμένα ώστε να μοιράζονται: ένα profile για την canonical μορφή, maps προς και από αυτό, και sub-processes που «κρύβουν» κάθε σύστημα πίσω από το μοντέλο.

Βήμα 1: Δημιουργήστε το canonical profile

Δημιουργήστε έναν φάκελο για τα κοινά components, για παράδειγμα Canonical/Order, ώστε όλοι να ξέρουν πού βρίσκεται το μοντέλο.
Δημιουργήστε ένα JSON profile (ή XML profile, αν η ομάδα σας προτιμά XML) με όνομα όπως Canonical Order v1. Μπορείτε να κάνετε import το παραπάνω παράδειγμα για να παραχθεί η δομή, και μετά να ελέγξετε τους τύπους και να σημειώσετε τα υποχρεωτικά στοιχεία.
Προσθέστε μια σύντομη περιγραφή στο component, με σύνδεσμο στην τεκμηρίωση κάθε πεδίου.

Βήμα 2: Εισερχόμενα maps (πηγή προς canonical)

Για κάθε πηγή, δημιουργήστε ένα component Map από το profile της πηγής προς το canonical profile: E-shop Order to Canonical Order, Marketplace Order to Canonical Order κ.ο.κ. Εδώ γίνεται η μετάφραση που αφορά την κάθε πηγή: ονόματα πεδίων, μορφές ημερομηνιών και λίστες κωδικών όπως οι τρόποι πληρωμής.

Κρατήστε τη μετάφραση κωδικών σε cross reference tables αντί να είναι «καρφωμένη» σε κάθε map, ώστε το cod του e-shop και το CASH_ON_DELIVERY του marketplace να γίνονται και τα δύο COD σε ένα σημείο που συντηρείται. Δείτε Cross reference tables στο Boomi και, για τις τεχνικές mapping γενικότερα, Maps και profiles στο Boomi.

Βήμα 3: Εξερχόμενα maps (canonical προς προορισμό)

Για κάθε προορισμό, δημιουργήστε ένα map από το canonical profile: Canonical Order to ERP Sales Order, Canonical Order to WMS Shipment. Αυτά τα maps δεν ξέρουν τίποτα για το από πού ήρθε η παραγγελία. Το map του ERP μεταφράζει το COD στον κωδικό πληρωμής του ERP, το map του WMS αγνοεί εντελώς τις τιμές.

Βήμα 4: Τυλίξτε τους προορισμούς σε sub-processes

Δημιουργήστε ένα sub-process ανά προορισμό που δέχεται canonical παραγγελία: Deliver Order to ERP, Deliver Order to WMS. Το καθένα περιέχει το εξερχόμενο map, την κλήση του connector και τη δική του διαχείριση σφαλμάτων. Τα processes των πηγών τα καλούν με ένα shape Process Call (ή τα δρομολογούν με ένα shape Process Route, αν θέλετε να επιλέγεται ο προορισμός δυναμικά).

Ένα process πηγής γίνεται τότε σύντομο και ομοιόμορφο:

Ανάγνωση παραγγελιών e-shop ──► Map: e-shop → canonical ──► Process Call: Deliver Order to ERP
                                                        └─► Process Call: Deliver Order to WMS

Όταν αλλάξει το ERP, ξαναφτιάχνετε ένα sub-process. Όλες οι πηγές συνεχίζουν να δουλεύουν.

Βήμα 5: Έλεγχος στο όριο του canonical

Προσθέστε ένα βήμα επικύρωσης αμέσως μετά από κάθε εισερχόμενο map, για παράδειγμα ένα shape Business Rules ή ένα Decision στα υποχρεωτικά πεδία. Αν μια πηγή στείλει παραγγελία χωρίς ΑΦΜ για πελάτη B2B, απορρίπτεται στην άκρη με σαφές μήνυμα, αντί να αποτύχει αργότερα μέσα στην κλήση του ERP.

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

Γράψτε το λεξικό πεδίων. Μία γραμμή ανά πεδίο: σημασία, μορφή, παράδειγμα. Το profile μόνο του δεν εξηγεί την πρόθεση.
Ελέγξτε την επαναχρησιμοποίηση. Βεβαιωθείτε ότι τα processes χρησιμοποιούν το κοινό profile και τα κοινά maps, όχι αντίγραφα. Τα αντίγραφα αποκλίνουν.
Σχεδιάστε τις αλλαγές. Όταν χρειαστείτε Canonical Order v2, φτιάξτε το δίπλα στο v1 και μεταφέρετε τις ροές σταδιακά.
Μην περνάτε τα πάντα από αυτό. Μια μεμονωμένη ροή ανάμεσα σε δύο συστήματα που δεν χρησιμοποιεί κανείς άλλος μπορεί να κάνει απευθείας mapping. Το canonical model είναι για αντικείμενα που μοιράζονται πολλές ροές.

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

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

Ένα canonical model αντικαθιστά πολλά mappings ανά ζευγάρι συστημάτων με ένα mapping ανά σύστημα, και βάζει τους κοινούς επιχειρηματικούς κανόνες σε ένα σημείο. Στο Boomi φτιάχνεται από συνηθισμένα components: ένα κοινό profile, ένα εισερχόμενο map ανά πηγή, ένα εξερχόμενο map ανά προορισμό, και sub-processes που «κρύβουν» κάθε προορισμό. Για περισσότερα patterns σαν αυτό, δείτε το Integration patterns που πρέπει να ξέρει κάθε ομάδα.