Έναρξη

Δρομέας συλλογής για το blockchain logistics

Δρομέας συλλογής για το blockchain logistics

Η ενσωμάτωση των API συνοδεύεται από δοκιμές ενσωμάτωσης σε εργαλεία όπως το Postman ή το SoapUI. Οι προγραμματιστές ελέγχουν έτσι βήμα προς βήμα τη λειτουργικότητα του API και διασφαλίζουν ότι η ανταλλαγή δεδομένων μεταξύ των συστημάτων είναι σωστή από άποψη περιεχομένου και τεχνολογίας. Οι καταστάσεις σφάλματος μπορούν να προκληθούν μεμονωμένα και να αναχαιτιστούν πριν από τη χρήση του API, χωρίς μια μαζική ροή δεδομένων να επισκιάζει την εικόνα των κρίσιμων σημείων. Καθώς στα σύγχρονα εταιρικά περιβάλλοντα συνήθως εμπλέκονται πολλά συστήματα στην ανταλλαγή δεδομένων, πρέπει επίσης να εκτελούνται σε τακτική βάση διάφορα ερωτήματα που σχετίζονται με το περιεχόμενο. Η απουσία σφαλμάτων μπορεί στη συνέχεια να αξιολογηθεί μόνο ως αποτέλεσμα μιας ροής δεδομένων από άκρο σε άκρο. Η αυτοματοποίηση αυτού του κύκλου αίτησης-απάντησης πολλαπλών σταδίων θα περιγραφεί με τη βοήθεια του Postman Collection Runner χρησιμοποιώντας ως παράδειγμα την πλατφόρμα εφοδιαστικής TradeLens.

 

TradeLens εγκαινιάστηκε από τη μεγαλύτερη ναυτιλιακή εταιρεία στον κόσμο Maersk και βασίζεται στο τεχνολογία blockchain της IBM. Το βασικό του καθήκον είναι η ασφαλής και αξιόπιστη καταγραφή όλων των λογιστικών γεγονότων μεταξύ του αρχικού αποστολέα και του τελικού παραλήπτη ως μέρος της παγκόσμιας αλυσίδας μεταφορών. Αυτό δίνει τη δυνατότητα σε όλους τους συμμετέχοντες σε αυτή την αλυσίδα μπλοκ να χρησιμοποιούν αξιόπιστα και απαραβίαστα δεδομένα στη δική τους διαχείριση της αλυσίδας εφοδιασμού, προκειμένου να διασφαλίσουν μια αποτελεσματική ροή εμπορευμάτων. Η παρακολούθηση και ο εντοπισμός γίνεται παιχνιδάκι. Απλή, επεκτάσιμη και ασφαλής εφαρμογή με τη χρήση Workato έχει ήδη περιγραφεί λεπτομερώς σε άλλο άρθρο (βλ. σχόλιο). Σε αυτό το σημείο, θα θέλαμε να ρίξουμε μια πιο προσεκτική ματιά στο εξίσου σημαντικό προηγούμενο βήμα της αυτοματοποίησης των δοκιμών πριν από τη θέση σε λειτουργία. Εξασφαλίζει ότι έχουμε κατανοήσει το API και τη χρήση του και ότι η αυτοματοποίηση στην παραγωγή μπορεί να είναι επιτυχής.

 

 

 

Πηγή:

Η ανάπτυξη API περιλαμβάνει πάντα ουσιαστική τεκμηρίωση, η οποία συνήθως αποτελείται από έναν οδηγό εφαρμογής που μοιάζει με ιστολόγιο και μια τεχνική περιγραφή- η τελευταία δημιουργείται τακτικά με τη χρήση του εργαλείου Swagger (τώρα OpenAPI). Στην περίπτωση του TradeLens, και τα δύο αυτά πράγματα έχουν γίνει εξαιρετικά καλά: Λεπτομερής, περιεκτική, κατανοητή, τεχνικά ώριμη. Το υλοποίηση των επιμέρους βημάτων στο Postman δίνεται κατευθείαν στον ολοκληρωτή API, οπότε δεν χρειάζεται να πούμε περισσότερα γι' αυτό εδώ. Θέλουμε να περάσουμε κατευθείαν στην αυτοματοποίηση με τη βοήθεια των δρομέων συλλογής.

Ένας δρομέας συλλογής είναι μια ακολουθία μεμονωμένων ερωτημάτων που συνδυάζονται σε μια αλυσίδα χάρη στο σενάριο προ-ερωτήματος και το σενάριο δοκιμής. Ένα ερώτημα μπορεί να χρησιμοποιήσει το αποτέλεσμα ενός προηγούμενου ερωτήματος και να το επεξεργαστεί περαιτέρω προκειμένου να το συγκρίνει με μια αναμενόμενη τιμή. Εάν η πραγματική τιμή αντιστοιχεί στην αναμενόμενη τιμή, εμφανίζεται ένα πράσινο σύμβολο, διαφορετικά ένα κόκκινο. Τα ερωτήματα είναι ως επί το πλείστον ερωτήματα REST, το περιεχόμενο που ανταλλάσσεται ως επί το πλείστον δεδομένα JSON. Αυτό ισχύει και για το TradeLens. Στο συγκεκριμένο παράδειγμα, έχουμε επιλέξει ένα συμβάν TradeLens στο οποίο ένας σιδηροδρομικός μεταφορέας αναφέρει τη φόρτωση ενός εμπορευματοκιβωτίου στην αλυσίδα μπλοκ. Αυτό απαιτεί τρία επιμέρους βήματα: (1) εξουσιοδότηση στο IBM Cloud, (2) εξουσιοδότηση στο TradeLens και (3) μετάδοση του περιεχομένου του συμβάντος στο TradeLens.

 

Πηγή:

 

Στο πρώτο βήμα, το IBM Cloud παρέχει ένα Token πρόσβασης και ανανέωσης σε αντάλλαγμα για ένα έγκυρο κλειδί API που δημιουργήθηκε κατά την εισαγωγή στο TradeLens. Αυτό το κουπόνι πρόσβασης και ανανέωσης χρησιμοποιείται για να ζητηθεί ένα κουπόνι ανταλλαγής από το TradeLens Solution Manager, το οποίο τελικά χρησιμοποιείται για την αναφορά του συγκεκριμένου συμβάντος στην πλατφόρμα TradeLens. Η δημιουργία token σε δύο στάδια επιτρέπει στον εκδότη του συμβάντος, στην περίπτωσή μας την εταιρεία σιδηροδρομικών μεταφορών, να εκχωρήσει την εξουσιοδότηση χρήσης του TradeLens API στο δικό του όνομα στη διαχείριση χρηστών του IBM Cloud(Identity and Access Management, εν συντομία IAM). Εάν το Token πρόσβασης και ανανέωσης είναι έγκυρο, το TradeLens χορηγεί ένα Exchange Token για την αποστολή των συμβάντων (που ονομάζεται επίσης Bearer Token ή Onboarding Token). Αυτός ο διαχωρισμός της ευθύνης για τον έλεγχο ταυτότητας από την ευθύνη της υπηρεσίας ακολουθεί το σύγχρονο πρότυπο OAuth 2.0, το οποίο αποσκοπεί στην αποφυγή της συνεχούς ανταλλαγής και της περιττής αποθήκευσης κωδικών πρόσβασης μεταξύ των υπηρεσιών. Προκειμένου το TradeLens να αποδεχτεί τη διαχείριση χρήστη του IBM Cloud ως παράδειγμα εξουσιοδότησης, η διαχείριση χρήστη του IBM Cloud έγινε γνωστή στο TradeLens κατά την επιβίβαση, ώστε το TradeLens να μπορεί να αξιολογήσει την εγκυρότητα του κουπονιού πρόσβασης και ανανέωσης. Οι ενδιαφερόμενοι μπορούν να βρουν μια κατανοητή εισαγωγή στον τρόπο λειτουργίας του OAuth 2.0 και σε περαιτέρω μηχανισμούς ελέγχου ταυτότητας στο ακόλουθο βίντεο.

 

 

Εάν ο πελάτης έχει λάβει ένα κουπόνι ανταλλαγής, το εισάγει ως πεδίο "Authentication", πριν από τη λέξη "Bearer", στην αίτηση POST του συμβάντος: Η αίτηση POST παρέχει έτσι στο TradeLens έναν έγκυρο κωδικό πρόσβασης για την αποστολή του συμβάντος. Στο ακόλουθο στιγμιότυπο οθόνης, η διεύθυνση URL στην οποία αποστέλλεται το αίτημα POST έχει αφαιρεθεί από μια μεταβλητή, ώστε να μπορεί εύκολα να παραμετροποιηθεί από ένα σενάριο.

 

 

 

Αυτά για τη βασική διαδικασία. Τώρα στην αυτοματοποίηση και την επικύρωση εντός του Postman Collection Runner.

 

Μόλις ο πελάτης Postman στείλει το πρώτο αίτημα POST στο IBM Cloud IAM με το κουπόνι API στο σώμα του μηνύματος, το κουπόνι πρόσβασης και ανανέωσης του IBM Cloud IAM θα πρέπει να εγγραφεί από τη σχετική απάντηση σε μια μεταβλητή συλλογής. Αυτό πρόκειται να χρησιμοποιηθεί στο επόμενο βήμα, τον έλεγχο ταυτότητας με το TradeLens. Οι μεταβλητές συλλογής έχουν πεδίο εφαρμογής μια συλλογή, η οποία δεν είναι τίποτε άλλο από διάφορες αιτήσεις που έχουν συγκεντρωθεί σε μια συλλογή (παρόμοια με έναν φάκελο). Επομένως, μπορούν να μοιράζονται τις μεταβλητές αυτές, δηλαδή να έχουν πρόσβαση και να τις αλλάζουν, που έχουν οριστεί ως μεταβλητές συλλογής. Υπάρχουν επίσης τοπικές μεταβλητές, μεταβλητές περιβάλλοντος και παγκόσμιες μεταβλητές, τις οποίες θα συζητήσουμε αργότερα.

Το Postman προσφέρει τη δυνατότητα εκτέλεσης προγραμμάτων JavaScript πριν και μετά από μια αίτηση για αυτοματισμούς εντός συλλογών. Αυτό γίνεται εύκολα με τη δημιουργία ενός αντίστοιχου προγράμματος JavaScript στην καρτέλα "Pre-request Script" ή "Test Script". Το Postman παρέχει επίσης πολυάριθμες μεθόδους και ιδιότητες για την αλληλεπίδραση, οι οποίες περιέχονται στο αντικείμενο pm. Ας ρίξουμε μια πιο προσεκτική ματιά.

 

 

 

Στη γραμμή 3, δύο τοπικές μεταβλητές ορίζονται με τη λέξη-κλειδί let της JavaScript: Η μεταβλητή response καταγράφει την απάντηση της αίτησης POST που προηγείται αμέσως του σεναρίου δοκιμής σε μορφή JSON(pm.response.json())- αυτό δίνει στην απάντηση μια δομή που διευκολύνει την περαιτέρω επεξεργασία στο Postman. Αμέσως μετά, ορίζεται η μεταβλητή accessRefreshToken και της αποδίδεται αμέσως η προηγουμένως αποθηκευμένη μεταβλητή response ως συμβολοσειρά, κάτι που επιτυγχάνεται με τη μέθοδο stringify. Θα δούμε γιατί γίνεται αυτό σε λίγο.

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

Στη γραμμή 6, η απόκριση που μετατρέπεται σε συμβολοσειρά αποθηκεύεται ως μεταβλητή συλλογής- είναι επομένως διαθέσιμη και στις άλλες δύο αιτήσεις POST. Αυτό έχει σημασία μόνο για την αίτηση που ακολουθεί αμέσως μετά το βήμα 1, καθώς έχει πρόσβαση σε αυτή τη μεταβλητή συλλογής για να λάβει ένα κουπόνι ανταλλαγής (bearer token) από την TradeLens.

Τέλος, τρεις δοκιμές εκτελούνται στις γραμμές 9 έως 17: Εάν η απάντηση αντιπροσωπεύει ένα μήνυμα επιτυχίας (δηλ. κωδικό 200 σύμφωνα με το πρότυπο HTTP), περιέχει ένα τμήμα που ονομάζεται"access_token" και ένα που ονομάζεται"refresh_token". Εάν πληρούνται και οι τρεις προϋποθέσεις, αυτή η πρώτη αίτηση POST ήταν επιτυχής. Το Postman το επιβεβαιώνει με ένα πράσινο σύμβολο.

2. πιστοποίηση ταυτότητας προς το TradeLens Solution Manager

Αφού αποθηκευτεί το κουπόνι πρόσβασης και ανανέωσης σε μια μεταβλητή συλλογής, μπορεί να γίνει άμεση πρόσβαση σε αυτό στο δεύτερο αίτημα POST, εδώ στο σώμα του δεύτερου βήματος. Στο Postman, αυτό γίνεται με τη χρήση δύο αγκυλών με το όνομα της μεταβλητής ως αναγνωριστικό {{AccessRefreshToken}}.

Παρόμοια με το πρώτο βήμα, αποθηκεύουμε την απόκριση αυτής της δεύτερης αίτησης POST σε μια μεταβλητή συλλογής για περαιτέρω χρήση. Αυτή τη φορά πρόκειται για το διακριτικό ανταλλαγής, το οποίο το TradeLens αναφέρει ως"onboarding_token" στο έγγραφο JSON. Αποθηκεύεται και πάλι σε μια μεταβλητή συλλογής. Επιπλέον, το σενάριο δοκιμής ελέγχει αν πρόκειται και πάλι για θετική απάντηση HTTP 200 και αν η λέξη"onboarding_token" περιέχεται στο σώμα της απάντησης αυτή τη φορά. Εάν πληρούνται και τα δύο κριτήρια, η δοκιμή θεωρείται επιτυχής - πράσινο τικ.

3. διαβίβαση συμβάντος με υλικοτεχνικά δεδομένα στο TradeLens

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

Σε αντίθεση με τα δύο προηγούμενα βήματα, πρέπει να πραγματοποιηθούν τρία βήματα αυτοματισμού: Δεύτερον, το σώμα θα πρέπει να φορτώνεται δυναμικά από ένα αρχείο JSON, ώστε οι υπάλληλοι που δεν είναι εξοικειωμένοι με το Postman να μπορούν επίσης να προσθέτουν νέα δεδομένα δοκιμής σε μια δοκιμαστική εκτέλεση ή να στέλνουν δεδομένα δοκιμής στον ελεγκτή με τη μορφή εύκολων στη δημιουργία αρχείων JSON. Ας ξεκινήσουμε με το πρώτο μέτρο, τη μετάδοση του onboarding token ως πεδίο κεφαλίδας.

 

 

 

Στη γραμμή 2, δημιουργείται μια τοπική μεταβλητή με την ονομασία"bearerToken", στην οποία αποδίδεται η τιμή "Bearer " ακολουθούμενη από το περιεχόμενο, δηλαδή το onboarding token, της αντίστοιχης μεταβλητής συλλογής. Στη γραμμή 3, προσθέτουμε αυτή την τοπική μεταβλητή ως στοιχείο επικεφαλίδας "Authorisation" στην εκκρεμή αίτηση POST ή ενημερώνουμε την τιμή αυτού του στοιχείου επικεφαλίδας εάν υπάρχει ήδη. Η μέθοδος"upsert" από την ανάπτυξη βάσεων δεδομένων χρησιμοποιείται επίσης για το σκοπό αυτό στην επέκταση JavaScript του Postman. Επιπλέον, στις γραμμές 6 και 7 ανακτούμε την τρέχουσα ώρα που είναι συμβατή με το πρότυπο ISO 8601 στη ζώνη ώρας Ευρώπης/Βερολίνου από μια εξωτερική υπηρεσία ώρας προκειμένου να την αποθηκεύσουμε σε μια παγκόσμια μεταβλητή με όνομα"TimeStamp" σε μορφή ώρας (datetime). Αυτή η παγκόσμια μεταβλητή πρέπει να τροφοδοτηθεί στα δεδομένα μεταφοράς που πρόκειται να μεταδοθούν, καθώς το TradeLens θα ήθελε να γνωρίζει την ώρα μετάδοσης. Φυσικά, αντί για μια παγκόσμια μεταβλητή θα μπορούσε επίσης να χρησιμοποιηθεί μια μεταβλητή συλλογής ή περιβάλλοντος- αποφασίσαμε υπέρ μιας παγκόσμιας μεταβλητής για να δείξουμε τη χρήση της ως παράδειγμα. Τέλος, στη γραμμή 11, η μεταβλητή συλλογής"IterationData" πρέπει να συμπληρωθεί με όλα τα δεδομένα της δοκιμής - και πάλι ως συμβολοσειρά, όπως απαιτεί το Postman για το περιεχόμενο των μεταβλητών. Τα δεδομένα της δοκιμής προέρχονται από το προαναφερθέν ξεχωριστό έγγραφο JSON, το οποίο ο Δρομέας Συλλογής φορτώνει στο Postman. Αυτή η "παράπλευρη φόρτωση" των δεδομένων δοκιμών στο Postman είναι ένα πολύ ευπρόσδεκτο χαρακτηριστικό που διαχωρίζει τη δημιουργία αυτοματισμού από έναν μηχανικό αυτοματισμού δοκιμών από τη χρήση του αυτοματισμού δοκιμών ή την παροχή πραγματικών δεδομένων δοκιμών από έναν υπάλληλο του τμήματος.

Το σώμα του εκκρεμούς αιτήματος POST φαίνεται επίσης μη θεαματικό. Περιέχει μόνο τη μεταβλητή συλλογής"IterationData", η οποία με τη σειρά της περιέχει το υποδειγματικό σύνολο δεδομένων δοκιμής που παρουσιάζεται παρακάτω. Τα κόκκινα βέλη δείχνουν πού χρησιμοποιείται η μεταβλητή συλλογής που ορίζεται στο JavaScript και πού το Postman την αντικαθιστά με συγκεκριμένες τιμές στο παρασκήνιο. Για δοκιμαστικούς σκοπούς, ο χρόνος του συμβάντος μεταφοράς εξισώθηκε με αυτόν της μετάδοσης του συμβάντος- στον παραγωγικό αυτοματισμό, ο πρώτος χρόνος μεταφέρεται από το σύστημα διαχείρισης μεταφορών και δεν χρειάζεται να συμπληρωθεί.

 

 

 

 

 

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

Το τελευταίο βήμα σε αυτό το τρίτο αίτημα POST είναι ο έλεγχος της επιτυχίας της δημοσίευσης. Αυτό είναι εγγυημένο εάν ληφθεί από το TradeLens μια απάντηση HTTP 201 ή 202, η οποία περιέχει το κείμενο"Event submitted" στο σώμα. Αυτό μας φέρνει στο τέλος της αυτοματοποίησης των δοκιμών μας με το Postman. Εάν ξεκινήσετε το Collection Runner, όλα τα βήματα εκτελούνται για κάθε επανάληψη, δηλαδή για κάθε εγγραφή δεδομένων που διαβάζεται, και τα αποτελέσματα της δοκιμής εμφανίζονται σαφώς στο Postman με κόκκινα ή πράσινα εικονίδια. Η επιτυχία μπορεί επίσης να επαληθευτεί στη διεπαφή web του TradeLens. Εδώ μπορείτε να δείτε όλα τα συμβάντα στα οποία έχει πρόσβαση ο οργανισμός σας - συμπεριλαμβανομένων εκείνων που έχετε δημοσιεύσει εσείς οι ίδιοι. Ωστόσο, αυτό θα μας πήγαινε πολύ μακριά εδώ.

 

 

 

Το Postman είναι ένα θαυμάσιο εργαλείο για την κατανόηση των APIs και για την αρχική, βήμα προς βήμα υλοποίηση και αυτοματοποίηση δοκιμών. Μόλις ξεπεραστεί αυτό το πρώτο εμπόδιο, τίποτα δεν στέκεται εμπόδιο στην αυτοματοποίηση και την ενσωμάτωση στα συστήματα παραγωγής. Ωστόσο, σε αυτό το σημείο μπαίνουν στο παιχνίδι πιο ισχυρά εργαλεία όπως η πλατφόρμα ενσωμάτωσης και αυτοματοποίησης χαμηλού κώδικα που βασίζεται στο cloud, η Workato, η οποία είναι επίσης ιδανική για την αυτοματοποίηση δοκιμών των APIs. Για την αυτοματοποίηση δοκιμών με προσανατολισμό στην επιφάνεια και τη συνεχή παρακολούθηση της λειτουργίας, χρησιμοποιούμε στη συνέχεια εργαλεία RPA χωρίς κώδικα, όπως το Leapwork. Επιτρέπουν την αυτοματοποιημένη δοκιμή προγραμμάτων με διεπαφές χρήστη, όπως διαδικτυακές εφαρμογές, εφαρμογές Citrix ή ακόμη και εγκατεστημένα προγράμματα και εφαρμογές. Θα αφιερώσουμε ένα ξεχωριστό άρθρο σε αυτό το εξαιρετικά αποτελεσματικό εργαλείο και θα παρουσιάσουμε τα πλεονεκτήματά του χρησιμοποιώντας ένα συγκεκριμένο παράδειγμα.

 

Σχετικά με την Business Automatica GmbH:

Το Business Automatica μειώνει το κόστος των διαδικασιών με την αυτοματοποίηση των χειροκίνητων δραστηριοτήτων, αυξάνει την ποιότητα της ανταλλαγής δεδομένων σε πολύπλοκες αρχιτεκτονικές συστημάτων και συνδέει τα συστήματα που βρίσκονται σε τοπικό επίπεδο με σύγχρονες αρχιτεκτονικές cloud και SaaS.