Στο παρασκήνιο του τείχους προστασίας προσωπικών δεδομένων

Άρθρο
08/01/2024

Σημείωμα

Προς το παρόν, τα επίπεδα προστασίας προσωπικών δεδομένων δεν είναι διαθέσιμα στις ροές δεδομένων Power Platform, αλλά η ομάδα προϊόντων εργάζεται για την ενεργοποίηση αυτής της λειτουργικότητας.

Εάν έχετε χρησιμοποιήσει το Power Query για οποιοδήποτε χρονικό διάστημα, πιθανότατα το έχετε βιώσει. Εκεί είστε, κάνοντας ερωτήματα μακριά, όταν ξαφνικά λαμβάνετε ένα σφάλμα που δεν μπορεί να διορθώσει καμία αναζήτηση στο διαδίκτυο, τροποποίηση ερωτημάτων ή χτύπημα πληκτρολογίου. Ένα σφάλμα όπως:

Formula.Firewall: Query 'Query1' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Ή ίσως:

Formula.Firewall: Query 'Query1' (step 'Source') is accessing data sources that have privacy levels which cannot be used together. Please rebuild this data combination.

Αυτά τα Formula.Firewall σφάλματα είναι αποτέλεσμα του τείχους προστασίας προσωπικών δεδομένων του Power Query (γνωστό και ως τείχος προστασίας), το οποίο μερικές φορές μπορεί να φαίνεται ότι υπάρχει αποκλειστικά και μόνο για να ματαιώσει τους αναλυτές δεδομένων σε όλο τον κόσμο. Ωστόσο, είτε το πιστεύετε είτε όχι, το τείχος προστασίας εξυπηρετεί έναν σημαντικό σκοπό. Σε αυτό το άρθρο, θα εμβαθύνουμε σε αυτό για να κατανοήσουμε καλύτερα τον τρόπο λειτουργίας του. Με μεγαλύτερη κατανόηση, ελπίζουμε ότι θα έχετε τη δυνατότητα να διαγνώσετε και να διορθώσετε λάθη τείχους προστασίας στο μέλλον.

Τι είναι?

Ο σκοπός του τείχους προστασίας προσωπικών δεδομένων είναι απλός: υπάρχει για να αποτρέπει την ακούσια διαρροή δεδομένων μεταξύ προελεύσεων από το Power Query.

Γιατί χρειάζεται αυτό; Θέλω να πω, μπορείτε σίγουρα να συντάξετε ορισμένα M που θα μεταβιβάσουν μια τιμή SQL σε μια τροφοδοσία OData. Ωστόσο, αυτό θα ήταν σκόπιμη διαρροή δεδομένων. Ο συντάκτης mashup θα ήξερε (ή τουλάχιστον θα έπρεπε) ότι το έκανε αυτό. Γιατί τότε χρειάζεται προστασία από ακούσια διαρροή δεδομένων;

Η απάντηση; Πτυσσόμενα.

Πτυσσόμενα?

Η αναδίπλωση είναι ένας όρος που αναφέρεται στη μετατροπή παραστάσεων στην M (όπως φίλτρα, μετονομασία, ενώσεις και ούτω καθεξής) σε λειτουργίες σε μια ανεπεξέργαστα προέλευση δεδομένων (όπως SQL, OData και ούτω καθεξής). Ένα τεράστιο μέρος της δύναμης του Power Query προέρχεται από το γεγονός ότι το PQ μπορεί να μετατρέψει τις λειτουργίες που εκτελεί ένας χρήστης μέσω του περιβάλλοντος εργασίας χρήστη του σε σύνθετες γλώσσες προέλευσης δεδομένων SQL ή άλλες γλώσσες προέλευσης δεδομένων παρασκηνίου, χωρίς ο χρήστης να χρειάζεται να γνωρίζει τις εν λόγω γλώσσες. Οι χρήστες επωφελούνται από τις επιδόσεις των εγγενών λειτουργιών προέλευσης δεδομένων, με την ευκολία χρήσης ενός περιβάλλοντος εργασίας χρήστη, όπου όλες οι προελεύσεις δεδομένων μπορούν να μετασχηματιστούν χρησιμοποιώντας ένα κοινό σύνολο εντολών.

Ως μέρος της αναδίπλωσης, το PQ ορισμένες φορές μπορεί να καθορίσει ότι ο πιο αποτελεσματικός τρόπος για την εκτέλεση ενός συγκεκριμένου συνδυασμού δεδομένων είναι να λάβετε δεδομένα από μια προέλευση και να τα μεταβιβάσετε σε μια άλλη. Για παράδειγμα, εάν συνενώνετε ένα μικρό αρχείο CSV σε έναν τεράστιο πίνακα SQL, πιθανώς δεν θέλετε το PQ να διαβάσει το αρχείο CSV, να διαβάσει ολόκληρο τον πίνακα SQL και, στη συνέχεια, να τα ενώσει στον τοπικό υπολογιστή σας. Πιθανώς θέλετε το PQ να συμπληρώσει τα δεδομένα CSV σε μια πρόταση SQL και να ζητήσει από τη βάση δεδομένων SQL να εκτελέσει την ένωση.

Με αυτόν τον τρόπο μπορεί να συμβεί ακούσια διαρροή δεδομένων.

Φανταστείτε εάν συμμετείχατε σε δεδομένα SQL που περιλάμβαναν αριθμούς κοινωνικής ασφάλισης υπαλλήλων με τα αποτελέσματα μιας εξωτερικής τροφοδοσίας OData και ανακαλύψατε ξαφνικά ότι οι Αριθμοί κοινωνικής ασφάλισης από το SQL αποστέλλονταν στην υπηρεσία OData. Κακά νέα, σωστά;

Αυτό είναι το είδος του σεναρίου που προορίζεται για να αποτρέψει το τείχος προστασίας.

Πώς λειτουργεί;

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

Λοιπόν, πώς επιτυγχάνει αυτή την αποστολή;

Το κάνει διαιρώντας τα ερωτήματα M σε κάτι που ονομάζεται διαμερίσματα και, στη συνέχεια, επιβάλλοντας τον ακόλουθο κανόνα:

Ένα διαμέρισμα μπορεί είτε να έχει πρόσβαση σε συμβατές προελεύσεις δεδομένων, είτε να αναφέρει άλλα διαμερίσματα, αλλά όχι και τα δύο.

Απλό... ακόμα πολύπλοκο. Τι είναι ένα διαμέρισμα; Τι κάνει δύο προελεύσεις δεδομένων "συμβατές"; Και γιατί θα πρέπει να ενδιαφέρεται το τείχος προστασίας εάν ένα διαμέρισμα θέλει πρόσβαση σε μια προέλευση δεδομένων και αναφορά σε ένα διαμέρισμα;

Ας το αναλύσουμε και ας δούμε τον παραπάνω κανόνα ένα κομμάτι τη φορά.

Τι είναι ένα διαμέρισμα;

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

Εάν δεν είστε εξοικειωμένοι με τα βήματα, μπορείτε να τα προβάλετε στη δεξιά πλευρά του παραθύρου πρόγραμμα επεξεργασίας Power Query αφού επιλέξετε ένα ερώτημα, στο τμήμα παραθύρου Εφαρμοσμένα βήματα. Τα βήματα παρακολουθούν όλα όσα έχετε κάνει για να μετασχηματίσετε τα δεδομένα σας στην τελική τους μορφή.

Διαμερίσματα που αναφέρονται σε άλλα διαμερίσματα

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

Όλα αυτά μπορεί να φαίνονται αρκετά αφηρημένα, επομένως ας δούμε ένα παράδειγμα.

Ας υποθέσουμε ότι έχετε ένα ερώτημα που ονομάζεται Employees, το οποίο αντλεί ορισμένα δεδομένα από μια βάση δεδομένων SQL. Ας υποθέσουμε ότι έχετε επίσης ένα άλλο ερώτημα (EmployeesReference), το οποίο απλώς αναφέρεται στους Υπαλλήλους.

shared Employees = let
    Source = Sql.Database(…),
    EmployeesTable = …
in
    EmployeesTable;

shared EmployeesReference = let
    Source = Employees
in
    Source;

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

shared Employees = let
    Source = Sql.Database(…),
    EmployeesTable = …
in
    EmployeesTable;

shared EmployeesReference = let
    Source = Value.Firewall("Section1/Employees")
in
    Source;

Παρατηρήστε ότι η απλή αναφορά στο ερώτημα Employees έχει αντικατασταθεί από μια κλήση στο Value.Firewall, η οποία παρέχεται με το πλήρες όνομα του ερωτήματος Employees.

Όταν αξιολογείται το EmployeesReference, η κλήση στο Value.Firewall("Section1/Employees") αναχαιτίζεται από το τείχος προστασίας, το οποίο έχει πλέον την ευκαιρία να ελέγξει εάν (και πώς) τα ζητούμενα δεδομένα ρέουν στο διαμέρισμα EmployeesReference. Μπορεί να κάνει πολλά πράγματα: να αρνηθεί την αίτηση, να αποθηκεύει στο buffer τα ζητούμενα δεδομένα (το οποίο εμποδίζει τυχόν περαιτέρω αναδίπλωση στην αρχική προέλευση δεδομένων της) και ούτω καθεξής.

Αυτός είναι ο τρόπος με τον οποίο το τείχος προστασίας διατηρεί τον έλεγχο των δεδομένων που ρέουν μεταξύ των διαμερισμάτων.

Διαμερίσματα που έχουν απευθείας πρόσβαση σε προελεύσεις δεδομένων

Ας υποθέσουμε ότι ορίζετε ένα ερώτημα Query1 με ένα βήμα (σημειώστε ότι αυτό το ερώτημα ενός βήματος αντιστοιχεί σε ένα διαμέρισμα τείχους προστασίας) και ότι αυτό το μοναδικό βήμα έχει πρόσβαση σε δύο προελεύσεις δεδομένων: έναν πίνακα βάσης δεδομένων SQL και ένα αρχείο CSV. Πώς το αντιμετωπίζει αυτό το τείχος προστασίας, δεδομένου ότι δεν υπάρχει αναφορά διαμερίσματος και, επομένως, δεν απαιτείται Value.Firewall η αναχαίτιση του τείχους προστασίας; Ας εξετάσουμε τον κανόνα που αναφέρεται παραπάνω:

Ένα διαμέρισμα μπορεί είτε να έχει πρόσβαση σε συμβατές προελεύσεις δεδομένων, είτε να αναφέρει άλλα διαμερίσματα, αλλά όχι και τα δύο.

Για να επιτραπεί η εκτέλεση του ερωτήματος μίας-διαμερίσματος-αλλά-δύο-προελεύσεων δεδομένων, οι δύο προελεύσεις δεδομένων της πρέπει να είναι "συμβατές". Με άλλα λόγια, πρέπει να είναι εντάξει για την αμφίδρομη κοινή χρήση των δεδομένων μεταξύ τους. Αυτό σημαίνει ότι τα επίπεδα προστασίας προσωπικών δεδομένων και των δύο προελεύσεων πρέπει να είναι δημόσια ή και τα δύο εταιρικά, δεδομένου ότι αυτοί είναι οι μόνοι δύο συνδυασμοί που επιτρέπουν την κοινή χρήση και προς τις δύο κατευθύνσεις. Εάν και οι δύο προελεύσεις έχουν σήμανση Ιδιωτική ή κάποια έχει σήμανση Δημόσια και η μία έχει σήμανση Εταιρικό ή έχουν επισημανθεί χρησιμοποιώντας κάποιον άλλο συνδυασμό επιπέδων προστασίας προσωπικών δεδομένων, τότε δεν επιτρέπεται η αμφίδρομη κοινή χρήση και, επομένως, δεν είναι ασφαλές για αυτές να αξιολογηθούν και οι δύο στο ίδιο διαμέρισμα. Κάτι τέτοιο θα σήμαινε ότι μπορεί να προκύψει μη ασφαλής διαρροή δεδομένων (λόγω αναδίπλωσης) και το τείχος προστασίας δεν θα έχει τρόπο να το αποτρέψει.

Τι θα συμβεί εάν προσπαθήσετε να αποκτήσετε πρόσβαση σε μη συμβατές προελεύσεις δεδομένων στο ίδιο διαμέρισμα;

Formula.Firewall: Query 'Query1' (step 'Source') is accessing data sources that have privacy levels which cannot be used together. Please rebuild this data combination.

Ας ελπίσουμε ότι τώρα θα κατανοήσετε καλύτερα ένα από τα μηνύματα σφάλματος που παρατίθενται στην αρχή αυτού του άρθρου.

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

Γιατί να μην τα κάνω και τα δύο;

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

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

Επομένως, τι συμβαίνει εάν ένα διαμέρισμα προσπαθήσει να κάνει αναφορά σε άλλα διαμερίσματα και να αποκτήσει απευθείας πρόσβαση σε προελεύσεις δεδομένων;

Formula.Firewall: Query 'Query1' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Τώρα ελπίζουμε να κατανοήσετε καλύτερα το άλλο μήνυμα σφάλματος που αναφέρεται στην αρχή αυτού του άρθρου.

Διαμερίσματα σε βάθος

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

Επομένως, πώς ακριβώς διαμερώνονται τα ερωτήματα;

Αυτή η ενότητα είναι ίσως η πιο σημαντική για να κατανοήσετε γιατί βλέπετε σφάλματα τείχους προστασίας και να κατανοήσετε τον τρόπο επίλυσής τους (όπου είναι δυνατό).

Ακολουθεί μια σύνοψη υψηλού επιπέδου της λογικής διαμείσματος.

Αρχικός διαμερισμό
- Δημιουργεί ένα διαμέρισμα για κάθε βήμα σε κάθε ερώτημα
Στατική φάση
- Αυτή η φάση δεν εξαρτάται από τα αποτελέσματα της αξιολόγησης. Αντίθετα, βασίζεται στον τρόπο με τον οποίο δομούνται τα ερωτήματα.
  - Περικοπή παραμέτρων
    - Εκτελεί περικοπή διαμερισμάτων παραμέτρου-esque, δηλαδή, οποιουδήποτε που:
      - Δεν αναφέρεται σε άλλα διαμερίσματα
      - Δεν περιέχει κλήσεις συναρτήσεων
      - Δεν είναι κυκλικό (δηλαδή, δεν αναφέρεται στον εαυτό του)
    - Σημειώστε ότι η "κατάργηση" ενός διαμερίσματος το περιλαμβάνει αποτελεσματικά σε οποιαδήποτε άλλα διαμερίσματα αναφέρονται σε αυτό.
    - Η περικοπή διαμερισμάτων παραμέτρων επιτρέπει την εργασία αναφορών παραμέτρων που χρησιμοποιούνται στις κλήσεις συναρτήσεων προέλευσης δεδομένων (για παράδειγμα, Web.Contents(myUrl)) αντί για την εμφάνιση σφαλμάτων "το διαμέρισμα δεν μπορεί να αναφέρει προελεύσεις δεδομένων και άλλα βήματα".
  - Ομαδοποίηση (Στατική)
    - Τα διαμερίσματα συγχωνεύονται με σειρά εξαρτήσεων από κάτω προς τα επάνω. Στα συγχωνευμένα διαμερίσματα που προκύπτουν, τα παρακάτω θα είναι ξεχωριστά:
      - Διαμερίσματα σε διαφορετικά ερωτήματα
      - Διαμερίσματα που δεν αναφέρονται σε άλλα διαμερίσματα (και έτσι επιτρέπεται η πρόσβαση σε μια προέλευση δεδομένων)
      - Διαμερίσματα που αναφέρονται σε άλλα διαμερίσματα (και επομένως απαγορεύεται η πρόσβαση σε μια προέλευση δεδομένων)
Δυναμική φάση
- Αυτή η φάση εξαρτάται από τα αποτελέσματα της αξιολόγησης, συμπεριλαμβανομένων των πληροφοριών σχετικά με τις προελεύσεις δεδομένων στις οποία αποκτούν πρόσβαση διάφορα διαμερίσματα.
- Τακτοποίηση
  - Εκτελεί περικοπή διαμερισμάτων που πληρούν όλες τις ακόλουθες απαιτήσεις:
    - Δεν αποκτά πρόσβαση σε προελεύσεις δεδομένων
    - Δεν αναφέρεται σε διαμερίσματα που έχουν πρόσβαση σε προελεύσεις δεδομένων
    - Δεν είναι κυκλικό
- Ομαδοποίηση (Δυναμική)
  - Τώρα που έχουν περικοπεί περιττά διαμερίσματα, προσπαθήστε να δημιουργήσετε διαμερίσματα προέλευσης που είναι όσο το δυνατόν περισσότερα. Αυτό γίνεται με τη συγχώνευση των διαμερισμάτων χρησιμοποιώντας τους ίδιους κανόνες που περιγράφονται στη φάση στατικής ομαδοποίησης παραπάνω.

Τι σημαίνουν όλα αυτά;

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

Δείτε ένα δείγμα σεναρίου. Είναι μια αρκετά απλή συγχώνευση ενός αρχείου κειμένου (Επαφές) με μια βάση δεδομένων SQL (Υπάλληλοι), όπου ο διακομιστής SQL είναι μια παράμετρος (DbServer).

Τα τρία ερωτήματα

Ακολουθεί ο κωδικός M για τα τρία ερωτήματα που χρησιμοποιούνται σε αυτό το παράδειγμα.

shared DbServer = "MySqlServer" meta [IsParameterQuery=true, Type="Text", IsParameterQueryRequired=true];

shared Contacts = let

    Source = Csv.Document(File.Contents("C:\contacts.txt"),[Delimiter="   ", Columns=15, Encoding=1252, QuoteStyle=QuoteStyle.None]),

    #"Promoted Headers" = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),

    #"Changed Type" = Table.TransformColumnTypes(#"Promoted Headers",{{"ContactID", Int64.Type}, {"NameStyle", type logical}, {"Title", type text}, {"FirstName", type text}, {"MiddleName", type text}, {"LastName", type text}, {"Suffix", type text}, {"EmailAddress", type text}, {"EmailPromotion", Int64.Type}, {"Phone", type text}, {"PasswordHash", type text}, {"PasswordSalt", type text}, {"AdditionalContactInfo", type text}, {"rowguid", type text}, {"ModifiedDate", type datetime}})

in

    #"Changed Type";

shared Employees = let

    Source = Sql.Databases(DbServer),

    AdventureWorks = Source{[Name="AdventureWorks"]}[Data],

    HumanResources_Employee = AdventureWorks{[Schema="HumanResources",Item="Employee"]}[Data],

    #"Removed Columns" = Table.RemoveColumns(HumanResources_Employee,{"HumanResources.Employee(EmployeeID)", "HumanResources.Employee(ManagerID)", "HumanResources.EmployeeAddress", "HumanResources.EmployeeDepartmentHistory", "HumanResources.EmployeePayHistory", "HumanResources.JobCandidate", "Person.Contact", "Purchasing.PurchaseOrderHeader", "Sales.SalesPerson"}),

    #"Merged Queries" = Table.NestedJoin(#"Removed Columns",{"ContactID"},Contacts,{"ContactID"},"Contacts",JoinKind.LeftOuter),

    #"Expanded Contacts" = Table.ExpandTableColumn(#"Merged Queries", "Contacts", {"EmailAddress"}, {"EmailAddress"})

in

    #"Expanded Contacts";

Ακολουθεί μια προβολή υψηλότερου επιπέδου, που εμφανίζει τις εξαρτήσεις.

Παράθυρο διαλόγου εξαρτήσεων ερωτημάτων.

Ας χωρίσουμε

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

Αρχικά διαμερίσματα τείχους προστασίας.

Στη συνέχεια, κάνουμε περικοπή των διαμερισμάτων παραμέτρων. Επομένως, το DbServer περιλαμβάνεται σιωπηρά στο διαμέρισμα Προέλευση.

Περικομμένα διαμερίσματα τείχους προστασίας.

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

Δημοσιεύστε στατικά διαμερίσματα τείχους προστασίας.

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

Ας προσποιηθούμε

Για λόγους απεικόνισης, ωστόσο, ας δούμε τι θα συμβεί εάν το ερώτημα Επαφές, αντί να προέρχεται από ένα αρχείο κειμένου, κωδικοποιημένα στην M (ίσως μέσω του παραθύρου διαλόγου Εισαγωγή δεδομένων ).

Σε αυτήν την περίπτωση, το ερώτημα Επαφές δεν θα αποκτήσει πρόσβαση σε προελεύσεις δεδομένων. Έτσι, θα περικοπεί κατά τη διάρκεια του πρώτου μέρους της δυναμικής φάσης.

Διαμέρισμα τείχους προστασίας μετά από δυναμική περικοπή φάσης.

Έχοντας καταργήσει το διαμέρισμα Επαφές, τα δύο τελευταία βήματα των Υπαλλήλων δεν θα αναφέρονται πλέον σε διαμερίσματα, εκτός από αυτό που περιέχει τα πρώτα τρία βήματα των Υπαλλήλων. Έτσι, τα δύο διαμερίσματα θα ομαδοποιηθούν.

Το διαμέρισμα που προκύπτει θα μοιάζει κάπως έτσι.

Τελικά διαμερίσματα τείχους προστασίας.

Παράδειγμα: Διαβίβαση δεδομένων από μια προέλευση δεδομένων σε μια άλλη

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

Ας υποθέσουμε ότι θέλετε να αναζητήσετε ένα όνομα εταιρείας από την υπηρεσία OData Northwind και, στη συνέχεια, να χρησιμοποιήσετε το όνομα της εταιρείας για να εκτελέσετε μια αναζήτηση Bing.

Πρώτα, δημιουργείτε ένα ερώτημα Εταιρεία για να ανακτήσετε το όνομα της εταιρείας.

let
    Source = OData.Feed("https://services.odata.org/V4/Northwind/Northwind.svc/", null, [Implementation="2.0"]),
    Customers_table = Source{[Name="Customers",Signature="table"]}[Data],
    CHOPS = Customers_table{[CustomerID="CHOPS"]}[CompanyName]
in
    CHOPS

Στη συνέχεια, δημιουργείτε ένα ερώτημα αναζήτησης που αναφέρεται στην Εταιρεία και το διαβιβάζει στο Bing.

let
    Source = Text.FromBinary(Web.Contents("https://www.bing.com/search?q=" & Company))
in
    Source

Σε αυτό το σημείο θα έχετε προβλήματα. Η αξιολόγηση της αναζήτησης παράγει ένα σφάλμα τείχους προστασίας.

Formula.Firewall: Query 'Search' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Αυτό συμβαίνει επειδή το βήμα Προέλευση της αναζήτησης είναι η αναφορά σε μια προέλευση δεδομένων (bing.com) και η αναφορά σε ένα άλλο ερώτημα/διαμέρισμα (Εταιρεία). Παραβιάζει τον κανόνα που αναφέρθηκε παραπάνω ("ένα διαμέρισμα μπορεί να έχει πρόσβαση σε συμβατές προελεύσεις δεδομένων ή να αναφέρει άλλα διαμερίσματα, αλλά όχι και τα δύο").

Τι να κάνω; Μία επιλογή είναι η τελείως απενεργοποίηση του τείχους προστασίας (μέσω της επιλογής προστασίας προσωπικών δεδομένων με την ετικέτα Παράβλεψη των επιπέδων προστασίας προσωπικών δεδομένων και ενδεχόμενη βελτίωση των επιδόσεων). Τι γίνεται όμως εάν θέλετε να αφήσετε ενεργοποιημένο το τείχος προστασίας;

Για να επιλύσετε το σφάλμα χωρίς να απενεργοποιήσετε το τείχος προστασίας, μπορείτε να συνδυάσετε τα στοιχεία Εταιρεία και Αναζήτηση σε ένα μεμονωμένο ερώτημα, ως εξής:

let
    Source = OData.Feed("https://services.odata.org/V4/Northwind/Northwind.svc/", null, [Implementation="2.0"]),
    Customers_table = Source{[Name="Customers",Signature="table"]}[Data],
    CHOPS = Customers_table{[CustomerID="CHOPS"]}[CompanyName],
    Search = Text.FromBinary(Web.Contents("https://www.bing.com/search?q=" & CHOPS))
in
    Search

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

Αυτό είναι ένα περιτύλιγμα

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

Κοινή χρήση μέσω