Testing των Boomi processes κατά την ανάπτυξη

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

Γιατί το «τρέχω όλη την αλυσίδα και κοιτάζω» δεν δουλεύει

Είναι αργό. Κάθε δοκιμή θέλει πραγματική ενέργεια σε ένα σύστημα πηγής και έλεγχο σε ένα σύστημα προορισμού.
Δεν επαναλαμβάνεται. Η δεύτερη δοκιμαστική παραγγελία δεν είναι ποτέ ακριβώς ίδια με την πρώτη, και οι incremental ροές παίρνουν τα «νέα» δεδομένα μόνο μία φορά.
Κρύβει τη μέση. Βλέπετε την είσοδο και το αποτέλεσμα, όχι τι έκανε κάθε βήμα στα δεδομένα.
Ελέγχει μόνο το happy path. Κανείς δεν κλείνει το ERP για να δει τι γίνεται όταν είναι εκτός λειτουργίας.
Έχει παρενέργειες. Οι δοκιμαστικές παραγγελίες φτάνουν σε συστήματα που δεν θέλατε: στο ERP, στην courier, στο inbox του πελάτη.

Το pattern: σταθερή είσοδος, ορατά βήματα, σκόπιμα σφάλματα

Το καλό testing κατά την ανάπτυξη έχει τρία συστατικά:

Σταθερή, αποθηκευμένη είσοδος. Βάζετε ένα γνωστό έγγραφο στην αρχή της ροής αντί να το φέρνετε από ζωντανό σύστημα. Κρατάτε μια μικρή βιβλιοθήκη δειγμάτων: μια κανονική παραγγελία, μία με πολλές γραμμές, μία με ελληνικούς χαρακτήρες και μεγάλη διεύθυνση, μία μη έγκυρη.
Ορατότητα σε κάθε βήμα. Βλέπετε τα δεδομένα μετά από κάθε μετασχηματισμό, ώστε μια λάθος τιμή να εντοπίζεται στο βήμα που την παρήγαγε.
Σφάλματα που προκαλείτε σκόπιμα. Ελέγχετε τι γίνεται όταν αποτυγχάνει ένα lookup, όταν η επικύρωση απορρίπτει ένα έγγραφο και όταν το σύστημα προορισμού επιστρέφει σφάλμα.

Στην πράξη στο Boomi

Το Test mode του Boomi τρέχει ένα process από τον editor σε runtime που επιτρέπεται για δοκιμές, και κρατά τα έγγραφα που πέρασαν από κάθε shape για να τα δείτε. Μαζί με σταθερές εισόδους, καλύπτει και τα τρία συστατικά.

Βήμα 1: Test runtime

Το Test mode χρειάζεται runtime που επιτρέπεται να τρέχει δοκιμές: ένα τοπικό Atom σε μηχάνημα ή server ανάπτυξης, ή ένα test cloud runtime διαθέσιμο στον λογαριασμό σας. Χρησιμοποιήστε runtime σε test περιβάλλον, με connections που δείχνουν σε test instances των συστημάτων σας. Ποτέ μην τρέχετε Test mode σε runtime με connections προς την παραγωγή.

Έχετε υπόψη ότι το Test mode είναι σχεδιασμένο για ανάπτυξη: έχει όρια στον όγκο δεδομένων που επεξεργάζεται, οπότε χρησιμοποιήστε μικρά αντιπροσωπευτικά δείγματα και όχι ολόκληρα batches παραγωγής. Δείτε την τρέχουσα τεκμηρίωση για τα ακριβή όρια.

Βήμα 2: Σταθερά test data

Υπάρχουν δύο συνηθισμένοι τρόποι να ξεκινά ένα process με γνωστά δεδομένα αντί για ζωντανό connector.

Shape Message. Ορίστε το Start shape χωρίς δεδομένα και προσθέστε ένα shape Message με το δείγμα. Είναι η πιο γρήγορη επιλογή και κρατά το δείγμα μέσα στο process. Θυμηθείτε ότι το Message αντιμετωπίζει τις αγκύλες { } ως placeholders μεταβλητών, οπότε το JSON πρέπει να μπει μέσα σε μονά εισαγωγικά για να διαβαστεί αυτούσιο.

Αρχεία από τον δίσκο. Αν το test runtime είναι τοπικό Atom, μπορείτε να χρησιμοποιήσετε τον connector Disk για να διαβάσετε δείγματα από έναν φάκελο στο μηχάνημα, για παράδειγμα C:\boomi-test\orders\. Κάθε αρχείο γίνεται ένα έγγραφο, οπότε με πολλά δείγματα στον φάκελο ελέγχετε πολλές περιπτώσεις σε μία εκτέλεση. Έτσι τα δείγματα μένουν έξω από το process, εκεί που μπορούν να μπουν σε version control.

Ένας καθαρός τρόπος οργάνωσης είναι να χωρίσετε την πηγή από τη λογική:

Κύριο process:  [connector e-shop]  ──► Process Call: "Order logic" ──► [connector ERP]
Test process:   [Message / Disk]    ──► Process Call: "Order logic" ──► [Stop ή mock]

Η λογική (mapping, επικύρωση, lookups) ζει σε ένα subprocess που καλούν και το πραγματικό και το test process με το shape Process Call. Αναπτύσσετε και ελέγχετε τη λογική με σταθερά δεδομένα, και το πραγματικό process απλώς προσθέτει τους connectors γύρω της.

Βήμα 3: Εκτέλεση και έλεγχος κάθε shape

Ανοίξτε το process και πατήστε Test. Διαλέξτε το test runtime σας.
Παρακολουθήστε την εκτέλεση στον καμβά. Κάθε shape δείχνει πόσα έγγραφα μπήκαν και πόσα βγήκαν.
Επιλέξτε ένα shape για να δείτε τα έγγραφα που παρήγαγε. Ανοίξτε ένα έγγραφο για να δείτε το περιεχόμενο και τα document properties του.
Ακολουθήστε ένα έγγραφο σε όλη τη ροή. Όταν μια τιμή είναι λάθος, το πρώτο shape όπου εμφανίζεται λάθος είναι εκεί που βρίσκεται το bug.

Τυπικοί έλεγχοι: περιέχει η έξοδος του Map τα αναμενόμενα πεδία· επέστρεψε τιμή το lookup· έστειλε το Decision το έγγραφο στον κλάδο που περιμένατε· πόσα έγγραφα έφτασαν στο τέλος σε σχέση με όσα ξεκίνησαν.

Για να διαβάζεται πιο εύκολα η εκτέλεση, προσθέστε ένα shape Notify σε βασικά σημεία με σύντομο μήνυμα όπως Order {1} mapped, payment method {2}, με τιμές του εγγράφου ως παραμέτρους. Τα μηνύματα εμφανίζονται στο process log της δοκιμής.

Βήμα 4: Σκόπιμο testing των δρόμων σφάλματος

Το happy path συνήθως είναι εντάξει. Τα bugs βρίσκονται στους άλλους κλάδους. Φτιάξτε δείγματα που ενεργοποιούν τον καθένα:

Αποτυχία επικύρωσης. Παραγγελία χωρίς κωδικό πελάτη ή με αρνητική ποσότητα. Ελέγξτε ότι το έγγραφο σταματά και ότι το μήνυμα σφάλματος είναι χρήσιμο.
Άγνωστος κωδικός. Παραγγελία με τρόπο πληρωμής που δεν υπάρχει στον πίνακα lookup. Ελέγξτε ότι αποτυγχάνει καθαρά αντί να φτάσει στο ERP με κενό πεδίο.
Σφάλμα προορισμού. Κάντε την κλήση προς τον προορισμό να αποτύχει: στρέψτε το test connection σε endpoint που δεν υπάρχει, στείλτε μια σκόπιμα λάθος εγγραφή που θα απορρίψει το test ERP, ή αντικαταστήστε την κλήση με shape Exception σε ένα test αντίγραφο. Ελέγξτε ότι το shape Try/Catch το πιάνει και ότι ο χειρισμός σφαλμάτων (logging, ειδοποίηση, retry) λειτουργεί όπως σχεδιάστηκε.
Μερική αποτυχία. Στείλτε τρία έγγραφα όπου το ένα είναι μη έγκυρο. Ελέγξτε ότι τα δύο σωστά περνούν, αν αυτή είναι η επιθυμητή συμπεριφορά.

Για το πώς σχεδιάζεται ο ίδιος ο χειρισμός σφαλμάτων, δείτε το Χειρισμός σφαλμάτων και retries στο Boomi.

Βήμα 5: Κρατήστε τα δείγματα

Όταν ένα δείγμα φανεί χρήσιμο, κρατήστε το:

Αποθηκεύστε τα αρχεία-δείγματα σε κοινό σημείο ή σε version control, με όνομα που λέει την περίπτωση, για παράδειγμα order-greek-long-address.json ή order-unknown-payment.json.
Καταγράψτε το αναμενόμενο αποτέλεσμα για το καθένα, έστω πρόχειρα στην αρχή: «βγάζει 3 γραμμές, τρόπος πληρωμής 07».
Όταν αναφερθεί bug από την παραγωγή, κάντε το προβληματικό έγγραφο (ανωνυμοποιημένο) νέο δείγμα.

Αυτά τα δείγματα γίνονται αργότερα η είσοδος για αυτοματοποιημένα regression tests, όπως περιγράφουμε στο Regression testing των Boomi integrations πριν από το deploy.

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

Αφαιρέστε τις «συντομεύσεις» δοκιμών από το πραγματικό process. Shapes Message με δείγματα και κλάδοι μόνο για test ανήκουν σε test processes, όχι σε αυτό που κάνει deploy.
Ελέγξτε ότι τα connections είναι ανά περιβάλλον. Χρησιμοποιήστε environment extensions ώστε το ίδιο process να χρησιμοποιεί test endpoints στο test και endpoints παραγωγής στην παραγωγή.
Τρέξτε ένα ελεγχόμενο end-to-end test. Μετά το component testing, μία πραγματική παραγγελία μέσα από τα test instances επιβεβαιώνει connectors και διαπιστευτήρια.
Κάντε masking στα προσωπικά δεδομένα των δειγμάτων. Δείγματα από την παραγωγή δεν πρέπει να έχουν πραγματικά ονόματα, emails ή ΑΦΜ πελατών.

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

Το testing όσο φτιάχνετε είναι πιο γρήγορο και βρίσκει περισσότερα bugs όταν η είσοδος είναι σταθερή, κάθε βήμα είναι ορατό και τα σφάλματα προκαλούνται σκόπιμα. Στο Boomi, ένα shape Message ή ο connector Disk δίνει την είσοδο, ένα subprocess κρατά τη λογική ελέγξιμη, και το Test mode δείχνει τα έγγραφα σε κάθε shape. Για τη συνολική εικόνα, δείτε τον οδηγό για testing integrations.