Μετάφραση κωδικών ανάμεσα σε συστήματα με τα Cross Reference Tables του Boomi

Κάθε σύστημα έχει τους δικούς του κωδικούς για τα ίδια πράγματα. Το e-shop λέει έναν τρόπο πληρωμής card, το ERP τον λέει 07, και η μορφή της φορολογικής αρχής περιμένει άλλη τιμή. Η κεντρική αποθήκη στο ERP είναι η 01, στο σύστημα διαχείρισης αποθήκης είναι η ATH-MAIN. Η μετάφραση αυτών των κωδικών είναι μικρό κομμάτι κάθε integration, και από τους πιο συχνούς λόγους που χρειάζεται developer για κάτι που θα έπρεπε να είναι αλλαγή δύο λεπτών.

Σε αυτό το άρθρο εξηγούμε το pattern για τη μετάφραση κωδικών γενικά, και μετά το υλοποιούμε με τα Cross Reference Tables του Boomi.

Γιατί το hardcoding αποτυγχάνει

Ο γρήγορος δρόμος είναι να βάλετε τη μετάφραση μέσα στο mapping: ένα if, ένα μικρό lookup στο map, ένα script. Δουλεύει την πρώτη μέρα. Μετά:

• Η επιχείρηση προσθέτει μια τιμή. Ένας νέος τρόπος πληρωμής (ας πούμε, πάροχος άτοκων δόσεων) εμφανίζεται στο e-shop. Οι παραγγελίες με αυτόν αποτυγχάνουν ή, χειρότερα, φτάνουν στο ERP με κενό τρόπο πληρωμής.
• Η ίδια μετάφραση χρειάζεται σε δύο σημεία. Η ροή παραγγελιών και η ροή επιστροφών μεταφράζουν και οι δύο τρόπους πληρωμής, η καθεμία με το δικό της αντίγραφο. Το ένα ενημερώνεται, το άλλο όχι.
• Test και παραγωγή διαφέρουν. Το test ERP έχει αποθήκη 99 για δοκιμές· η παραγωγή όχι. Ένας hardcoded πίνακας δεν μπορεί να είναι σωστός και για τα δύο.
• Κανείς εκτός IT δεν βλέπει τους κανόνες. Ο λογιστής που ξέρει τις κατηγορίες ΦΠΑ δεν μπορεί να ελέγξει ένα script.

Το pattern: ένας κοινός, συντηρούμενος πίνακας κωδικών

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

Έννοια	E-shop	ERP	Φορολογική μορφή (myDATA)
Τρόπος πληρωμής	card	07	7
Τρόπος πληρωμής	cod	03	3
Τρόπος πληρωμής	bank	06	6

Μερικοί κανόνες κάνουν το pattern να δουλεύει:

• Ένας υπεύθυνος ανά πίνακα. Κάποιος από την επιχείρηση (λογιστήριο για ΦΠΑ, logistics για αποθήκες) είναι υπεύθυνος για το περιεχόμενο.
• Ρητός χειρισμός όταν λείπει τιμή. Ένα lookup που δεν βρίσκει τίποτα πρέπει να σταματά το έγγραφο με σαφές μήνυμα, όχι να περνά κενή τιμή παρακάτω.
• Τιμές ανά περιβάλλον. Test και παραγωγή μπορούν να έχουν διαφορετικές γραμμές, χωρίς αλλαγή στο integration.

Οι τιμές myDATA παραπάνω είναι μόνο παράδειγμα. Παίρνετε πάντα τους πραγματικούς κωδικούς από την τρέχουσα προδιαγραφή του συστήματος στο οποίο στέλνετε.

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

Στο Boomi, ο πίνακας είναι ένα Cross Reference Table component, και τα maps τον διαβάζουν με τη map function Cross Reference Lookup.

Βήμα 1: Δημιουργία του Cross Reference Table

1. Δημιουργήστε ένα νέο Cross Reference Table component, για παράδειγμα XREF Payment Methods.
2. Ορίστε τις στήλες, μία ανά σύστημα: Eshop, ERP, myDATA. Δώστε τους ονόματα συστημάτων, όχι κατευθύνσεις μιας ροής, γιατί άλλες ροές θα διαβάζουν τον ίδιο πίνακα σε άλλες κατευθύνσεις.
3. Προσθέστε τις γραμμές, μία για κάθε τρόπο πληρωμής.
4. Κάντε το ίδιο για τις άλλες έννοιες: XREF VAT Categories (κωδικός ΦΠΑ του ERP προς κατηγορία ΦΠΑ της φορολογικής μορφής) και XREF Warehouses (αποθήκη ERP προς κωδικό αποθήκης στο WMS).

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

Βήμα 2: Χρήση σε map

1. Ανοίξτε το map, για παράδειγμα το map παραγγελίας e-shop προς ERP από το Mapping παραγγελίας από JSON σε XML με maps και profiles στο Boomi.
2. Προσθέστε μια function Cross Reference Lookup (στην κατηγορία lookup των map functions).
3. Επιλέξτε τον πίνακα, ορίστε Eshop ως στήλη εισόδου και ERP ως στήλη εξόδου.
4. Συνδέστε το πεδίο πηγής payment στην είσοδο της function και την έξοδό της στο PaymentMethod του προορισμού.

Η ροή παραγγελιών χρησιμοποιεί Eshop → ERP. Η ροή τιμολογίων προς τη φορολογική αρχή μπορεί να χρησιμοποιεί ERP → myDATA από τον ίδιο πίνακα. Ένας πίνακας, πολλές κατευθύνσεις, καμία διπλή λογική.

Βήμα 3: Καθαρή αποτυχία όταν λείπει κωδικός

Όταν το lookup δεν βρει γραμμή, το πεδίο προορισμού μένει κενό. Μην το αφήσετε να φτάσει σιωπηλά στο ERP:

• Μετά το shape Map, προσθέστε ένα shape Decision (ή Business Rules αν έχετε αρκετούς ελέγχους) που ελέγχει αν το PaymentMethod είναι κενό.
• Στον κλάδο «κενό», σταματήστε το έγγραφο με ένα shape Exception και μήνυμα που αναφέρει την τιμή που λείπει, για παράδειγμα Unknown payment method 'klarna' in order WEB-58211.

Αυτό το μήνυμα λέει στον υπεύθυνο του πίνακα ακριβώς ποια γραμμή πρέπει να προσθέσει. Συνδυάστε το με τον κανονικό χειρισμό σφαλμάτων και τις ειδοποιήσεις σας· δείτε το Χειρισμός σφαλμάτων και retries στο Boomi.

Βήμα 4: Διαφορετικές τιμές ανά περιβάλλον

Οι γραμμές που καταχωρείτε στο component κάνουν deploy μαζί με το process. Αυτό είναι εντάξει για τιμές που είναι ίδιες παντού. Για τιμές που διαφέρουν ανάμεσα σε test και παραγωγή, όπως οι κωδικοί αποθηκών, χρησιμοποιήστε environment extensions: τα Cross Reference Tables μπορούν να οριστούν ως extensible, και τότε οι γραμμές τους αλλάζουν ανά περιβάλλον από το παράθυρο extensions του περιβάλλοντος, χωρίς αλλαγή ή νέο deploy του process.

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

• Αποφασίστε από την αρχή ποιοι πίνακες είναι extensible. Αν το αλλάξετε αργότερα, χρειάζεται νέο deploy.
• Περιορίστε ποιος αλλάζει extensions στην παραγωγή. Ένα λάθος mapping ΦΠΑ είναι πραγματικό οικονομικό λάθος.

Βήμα 5: Testing των οριακών περιπτώσεων

Στο Test mode, τρέξτε το process με δείγματα που καλύπτουν:

• κάθε γνωστό κωδικό (μία παραγγελία για κάθε τρόπο πληρωμής),
• έναν άγνωστο κωδικό, για να επιβεβαιώσετε τον κλάδο Exception,
• τα ακριβή κεφαλαία/πεζά και κενά που στέλνει το σύστημα πηγής (Card ή card, κενά στο τέλος), γιατί ένα lookup μπορεί να τα θεωρεί διαφορετικές τιμές.

Πότε να μη χρησιμοποιήσετε Cross Reference Table

• Μεγάλες ή συχνά μεταβαλλόμενες λίστες, όπως κωδικοί ειδών ή πελάτες, ανήκουν σε βάση δεδομένων, στο ίδιο το ERP ή σε master data hub, όχι σε στατικό πίνακα. Δείτε τη διαχείριση κύριων δεδομένων για αυτό το πρόβλημα.
• Μεταφράσεις με λογική, όπως «η κατηγορία ΦΠΑ εξαρτάται από χώρα και τύπο είδους», μπορεί να θέλουν Decision ή ένα μικρό σύνολο κανόνων αντί για απλό lookup. Κρατήστε τους κωδικούς στον πίνακα και τη λογική στο process.

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

• Τεκμηριώστε κάθε πίνακα: υπεύθυνος, σημασία κάθε στήλης, πού χρησιμοποιείται.
• Εξάγετε τακτικά το περιεχόμενο. Αντιμετωπίστε τους πίνακες ως ρυθμίσεις που ελέγχετε και επαναφέρετε.
• Προσθέτετε νέες τιμές πριν χρησιμοποιηθούν. Συμφωνήστε με την επιχείρηση ότι ένας νέος τρόπος πληρωμής ή μια νέα αποθήκη μπαίνει στον πίνακα πριν ενεργοποιηθεί στο σύστημα πηγής.
• Ελέγξτε τις τιμές παραγωγής. Αν κάνετε override τιμών στην παραγωγή, ελέγξτε τες μία φορά απέναντι στο πραγματικό σύστημα προορισμού, με μια ελεγχόμενη παραγγελία.

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

Η μετάφραση κωδικών είναι μικρή δουλειά που γίνεται μεγάλο πρόβλημα όταν είναι σκορπισμένη μέσα στα mappings. Κρατήστε τους κωδικούς σε έναν πίνακα ανά έννοια, με μία στήλη ανά σύστημα, υπεύθυνο και καθαρή αποτυχία όταν λείπει τιμή. Στο Boomi, τα Cross Reference Tables και η function Cross Reference Lookup δίνουν ακριβώς αυτό, με τιμές ανά περιβάλλον μέσω extensions. Για τη συνολική εικόνα, δείτε τον οδηγό για data mapping και μορφές δεδομένων.