Ανάπτυξη εφαρμογών πολλαπλών προσαυξήσεων με δυνατότητα κλιμάκωσης με την ενσωμάτωση Power BI

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

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

Σημείωμα

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

Μπορείτε να επιτύχετε ενσωμάτωση Power BI χρησιμοποιώντας δύο διαφορετικά σενάρια ενσωμάτωσης: Ενσωμάτωση για τον οργανισμό σας και Ενσωμάτωση για τον πελάτη σας.

Το σενάριο Ενσωμάτωση για τον οργανισμό σας ισχύει όταν το κοινό της εφαρμογής αποτελείται από εσωτερικούς χρήστες. Οι εσωτερικοί χρήστες έχουν εταιρικούς λογαριασμούς και πρέπει να κάνουν έλεγχο ταυτότητας με το Αναγνωριστικό Microsoft Entra. Σε αυτό το σενάριο, το Power BI είναι λογισμικό ως υπηρεσία (SaaS). Ορισμένες φορές αναφέρεται ως Τα δεδομένα ανήκουν στον χρήστη.

Το σενάριο Ενσωμάτωση για τον πελάτη σας ισχύει όταν το κοινό της εφαρμογής αποτελείται από εξωτερικούς χρήστες. Η εφαρμογή είναι υπεύθυνη για τον έλεγχο ταυτότητας χρηστών. Για πρόσβαση σε περιεχόμενο Power BI, η εφαρμογή βασίζεται στην ενσωμάτωση ταυτότητας (κύρια υπηρεσία Microsoft Entra ή κύριος λογαριασμός χρήστη) για τον έλεγχο ταυτότητας με το Microsoft Entra. Σε αυτό το σενάριο, το Power BI είναι πλατφόρμα ως υπηρεσία (PaaS). Ορισμένες φορές αναφέρεται ως Τα δεδομένα ανήκουν στην εφαρμογή.

Σημείωμα

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

Ανάπτυξη εφαρμογών πολλαπλών χρήσεων

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

Για να δημιουργήσετε μια λύση πολλαπλών μισθωτών με δυνατότητα κλιμάκωσης, πρέπει να μπορείτε να αυτοματοποιήσετε τη δημιουργία νέων μισθωτών πελατών. Η προμήθεια ενός νέου μισθωτή πελάτη συνήθως περιλαμβάνει τη σύνταξη κώδικα που χρησιμοποιεί το Power BI REST API για τη δημιουργία ενός νέου χώρου εργασίας Power BI, τη δημιουργία σημασιολογικών μοντέλων με την εισαγωγή αρχείων Power BI Desktop (.pbix), την ενημέρωση παραμέτρων προέλευσης δεδομένων, τον ορισμό διαπιστευτηρίων προέλευσης δεδομένων και τη ρύθμιση προγραμματισμένης ανανέωσης μοντέλου σημασιολογίας. Το παρακάτω διάγραμμα δείχνει πώς μπορείτε να προσθέσετε στοιχεία Power BI, όπως αναφορές και σημασιολογικά μοντέλα, σε χώρους εργασίας για να ρυθμίσετε μισθωτές πελατών.

Όταν αναπτύσσετε μια εφαρμογή που χρησιμοποιεί το σενάριο Ενσωμάτωση για τον πελάτη σας, μπορείτε να κάνετε κλήσεις Power BI REST API χρησιμοποιώντας μια ταυτότητα ενσωμάτωσης που είναι είτε ένας κύριος λογαριασμός χρήστη είτε μια κύρια υπηρεσία. Συνιστούμε τη χρήση μιας κύριας υπηρεσίας για εφαρμογές παραγωγής. Παρέχει την υψηλότερη ασφάλεια και για το λόγο αυτό είναι η προσέγγιση που συνιστάται από το Microsoft Entra. Επίσης, υποστηρίζει καλύτερη αυτοματοποίηση και κλιμάκωση και υπάρχουν λιγότερα έξοδα διαχείρισης. Ωστόσο, απαιτεί δικαιώματα διαχειριστή Fabric για να ρυθμίσετε και να διαχειριστείτε.

Με τη χρήση μιας κύριας υπηρεσίας, μπορείτε να αποφύγετε συνήθη προβλήματα που σχετίζονται με τους κύριους λογαριασμούς χρηστών, όπως τα σφάλματα ελέγχου ταυτότητας σε περιβάλλοντα όπου οι χρήστες απαιτείται να εισέλθουν χρησιμοποιώντας έλεγχο ταυτότητας πολλών παραγόντων (MFA). Η χρήση μιας κύριας υπηρεσίας είναι επίσης συνεπής με την ιδέα ότι το σενάριο Ενσωμάτωση για τον πελάτη σας βασίζεται στην ενσωμάτωση περιεχομένου Power BI χρησιμοποιώντας μια νοοτροπία PaaS σε αντίθεση με μια νοοτροπία SaaS.

Περιορισμός χώρου εργασίας 1.000

Όταν σχεδιάζετε ένα περιβάλλον πολλαπλών χρήσεων που υλοποιεί το σενάριο Ενσωμάτωση για τον πελάτη σας, φροντίστε να λάβετε υπόψη ότι δεν είναι δυνατή η εκχώρηση πρόσβασης στην ταυτότητα ενσωμάτωσης σε περισσότερους από 1.000 χώρους εργασίας. Η υπηρεσία Power BI επιβάλλει αυτόν τον περιορισμό για να εξασφαλίζεται καλή απόδοση κατά την πραγματοποίηση κλήσεων REST API. Ο λόγος για αυτόν τον περιορισμό σχετίζεται με τον τρόπο με τον οποίο το Power BI διατηρεί μετα-δεδομένα που σχετίζονται με την ασφάλεια για κάθε ταυτότητα.

Το Power BI χρησιμοποιεί μετα-δεδομένα για την παρακολούθηση των χώρων εργασίας και των στοιχείων χώρου εργασίας στα οποία μπορεί να έχει πρόσβαση μια ταυτότητα. Στην πραγματικότητα, το Power BI πρέπει να διατηρεί μια ξεχωριστή λίστα ελέγχου πρόσβασης (ACL) για κάθε ταυτότητα στο υποσύστημα εξουσιοδότησης. Όταν μια ταυτότητα πραγματοποιεί μια κλήση REST API για πρόσβαση σε έναν χώρο εργασίας, το Power BI πρέπει να εκτελέσει έναν έλεγχο ασφαλείας σε σχέση με την ACL της ταυτότητας για να εξασφαλίσει ότι είναι εξουσιοδοτημένη. Ο χρόνος που απαιτείται για να προσδιοριστεί εάν ο χώρος εργασίας προορισμού βρίσκεται εντός της ACL αυξάνεται εκθετικά καθώς αυξάνεται ο αριθμός των χώρων εργασίας.

Σημείωμα

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

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

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

Ακολουθεί η παρατήρηση κλειδιού: Ο αριθμός των χώρων εργασίας που δημιουργούνται από μια κύρια υπηρεσία έχει άμεσο αντίκτυπο στις επιδόσεις και την κλιμάκωση. Μια κύρια υπηρεσία που είναι μέλος 100 χώρων εργασίας θα εκτελεί κλήσεις REST API ταχύτερα από μια κύρια υπηρεσία που είναι μέλος 1.000 χώρων εργασίας. Παρομοίως, μια κύρια υπηρεσία που είναι μέλος μόνο 10 χώρων εργασίας θα εκτελεί κλήσεις REST API ταχύτερα από μια κύρια υπηρεσία που είναι μέλος 100 χώρων εργασίας.

Σημαντικό

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

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

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

Κυριότητα μοντέλου σημασιολογίας

Κάθε σημασιολογικό μοντέλο Power BI έχει έναν μοναδικό κάτοχο, ο οποίος μπορεί να είναι είτε ένας λογαριασμός χρήστη, είτε μια κύρια υπηρεσία. Η κατοχή μοντέλου σημασιολογίας απαιτείται για τη ρύθμιση προγραμματισμένης ανανέωσης και τον ορισμό παραμέτρων σημασιολογικού μοντέλου.

Φιλοδώρημα

Στην υπηρεσία Power BI, μπορείτε να προσδιορίσετε ποιος είναι ο κάτοχος μοντέλου σημασιολογίας, ανοίγοντας τις ρυθμίσεις μοντέλου σημασιολογίας.

Εάν είναι απαραίτητο, μπορείτε να μεταβιβάσετε την κυριότητα του μοντέλου σημασιολογίας σε άλλον λογαριασμό χρήστη ή κύρια υπηρεσία. Αυτό μπορείτε να το κάνετε στην υπηρεσία Power BI ή χρησιμοποιώντας τη λειτουργία REST API TakeOver . Όταν εισάγετε ένα αρχείο Power BI Desktop για να δημιουργήσετε ένα νέο μοντέλο σημασιολογίας χρησιμοποιώντας μια κύρια υπηρεσία, η κύρια υπηρεσία ορίζεται αυτόματα ως κάτοχος μοντέλου σημασιολογίας.

Διαπιστευτήρια προέλευσης δεδομένων

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

Συνιστούμε να εφαρμόζετε ένα κοινό μοτίβο σχεδίασης κατά την προμήθεια ενός νέου μισθωτή πελάτη. Μπορείτε να εκτελέσετε μια σειρά κλήσεων REST API χρησιμοποιώντας την ταυτότητα της κύριας υπηρεσίας:

1. Δημιουργήστε έναν νέο χώρο εργασίας.
2. Συσχετίστε τον νέο χώρο εργασίας με αποκλειστικούς εκχωρημένους πόρους.
3. Εισαγάγετε ένα αρχείο Power BI Desktop για να δημιουργήσετε ένα μοντέλο σημασιολογίας.
4. Ορίστε τα διαπιστευτήρια προέλευσης μοντέλου σημασιολογίας για αυτό το σημασιολογικό μοντέλο.

Με την ολοκλήρωση αυτών των κλήσεων REST API, η κύρια υπηρεσία θα είναι διαχειριστής του νέου χώρου εργασίας και κάτοχος του μοντέλου σημασιολογίας και των διαπιστευτηρίων προέλευσης δεδομένων.

Σημαντικό

Υπάρχει μια συνήθης εσφαλμένη αντίληψη ότι τα διαπιστευτήρια προέλευσης δεδομένων σημασιολογικού μοντέλου στοχεύουν σε επίπεδο χώρου εργασίας. Αυτό δεν είναι αλήθεια. Τα διαπιστευτήρια προέλευσης δεδομένων στοχεύουν την κύρια υπηρεσία (ή τον λογαριασμό χρήστη) και αυτή η εμβέλεια επεκτείνεται σε όλους τους χώρους εργασίας Power BI στον μισθωτή Microsoft Entra.

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

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

Στρατηγικές σχεδίασης πριν από τα προφίλ κύριας υπηρεσίας

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

• Μία κύρια υπηρεσία
• Συγκέντρωση κύριας υπηρεσίας
• Μία κύρια υπηρεσία ανά χώρο εργασίας

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

Η στρατηγική σχεδίασης μίας κύριας υπηρεσίας απαιτεί μια εφάπαξ δημιουργία μιας καταχώρησης εφαρμογής Microsoft Entra. Επομένως, περιλαμβάνει λιγότερα έξοδα διαχείρισης από τις άλλες δύο στρατηγικές σχεδίασης, καθώς δεν απαιτείται η δημιουργία περισσότερων καταχωρήσεων εφαρμογών Microsoft Entra. Αυτή η στρατηγική είναι επίσης η πιο απλή προς ρύθμιση, επειδή δεν απαιτεί σύνταξη επιπλέον κώδικα που εναλλάσσει το περιβάλλον κλήσης μεταξύ των αρχών υπηρεσίας κατά την πραγματοποίηση κλήσεων REST API. Ωστόσο, ένα πρόβλημα με αυτήν τη στρατηγική σχεδίασης είναι ότι δεν αλλάζει κλίμακα. Υποστηρίζει μόνο ένα περιβάλλον πολλαπλών χρήσεων που μπορεί να αναπτύξει έως 1.000 χώρους εργασίας. Επίσης, οι επιδόσεις είναι βέβαιο ότι θα υποβαθμιστούν καθώς εκχωρείται πρόσβαση στην κύρια υπηρεσία σε μεγαλύτερο αριθμό χώρων εργασίας. Υπάρχει επίσης ένα πρόβλημα με την απομόνωση μισθωτή πελάτη, επειδή η μοναδική κύρια υπηρεσία γίνεται κάτοχος κάθε μοντέλου σημασιολογίας και όλων των διαπιστευτηρίων δεδομένων σε όλους τους μισθωτές πελατών.

Η στρατηγική σχεδίασης συγκέντρωσης κύριας υπηρεσίας χρησιμοποιείται συνήθως για την αποφυγή του περιορισμού χώρου εργασίας 1.000. Επιτρέπει στην εφαρμογή να κλιμακώνεται σε οποιονδήποτε αριθμό χώρων εργασίας, προσθέτοντας τον σωστό αριθμό οντοτήτων υπηρεσίας στον χώρο συγκέντρωσης. Για παράδειγμα, μια ομάδα πέντε οντοτήτων υπηρεσίας επιτρέπει την κλιμάκωση έως 5.000 χώρων εργασίας. Ένα σύνολο 80 οντοτήτων υπηρεσίας επιτρέπει την κλιμάκωση έως 80.000 χώρων εργασίας και ούτω καθεξής. Ωστόσο, ενώ αυτή η στρατηγική μπορεί να κλιμακώνει σε μεγάλο αριθμό χώρων εργασίας, έχει πολλά μειονεκτήματα. Πρώτα, απαιτείται εγγραφή επιπλέον κώδικα και αποθήκευση μετα-δεδομένων για να επιτρέπεται η εναλλαγή περιβάλλοντος μεταξύ των οντοτήτων υπηρεσίας κατά την πραγματοποίηση κλήσεων REST API. Δεύτερον, απαιτεί περισσότερη προσπάθεια διαχείρισης, καθώς πρέπει να δημιουργείτε καταχωρήσεις εφαρμογών Microsoft Entra κάθε φορά που χρειάζεται να αυξήσετε τον αριθμό των οντοτήτων υπηρεσίας στον χώρο συγκέντρωσης.

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

Η μοναδική στρατηγική σχεδίασης κύριας υπηρεσίας ανά χώρο εργασίας περιλαμβάνει τη δημιουργία μιας κύριας υπηρεσίας για κάθε μισθωτή πελάτη. Από θεωρητική άποψη, αυτή η στρατηγική προσφέρει την καλύτερη λύση καθώς βελτιστοποιεί την απόδοση των κλήσεων REST API, παρέχοντας παράλληλα πραγματική απομόνωση για σημασιολογικά μοντέλα και διαπιστευτήρια προέλευσης δεδομένων σε επίπεδο χώρου εργασίας. Ωστόσο, αυτό που λειτουργεί καλύτερα στη θεωρία δεν λειτουργεί πάντα καλύτερα στην πράξη. Αυτό συμβαίνει επειδή η απαίτηση για τη δημιουργία μιας κύριας υπηρεσίας για κάθε μισθωτή πελάτη δεν είναι πρακτική για πολλούς οργανισμούς. Αυτό συμβαίνει επειδή ορισμένοι οργανισμοί έχουν επίσημες διαδικασίες έγκρισης ή περιλαμβάνουν υπερβολική γραφειοκρατία για τη δημιουργία καταχωρήσεων εφαρμογών Microsoft Entra. Αυτοί οι λόγοι μπορεί να καταστήσουν αδύνατη την εκχώρηση σε μια προσαρμοσμένη εφαρμογή της αρχής που χρειάζεται για τη δημιουργία καταχωρήσεων εφαρμογών Microsoft Entra κατ' απαίτηση και με τον αυτοματοποιημένο τρόπο που απαιτεί η λύση σας.

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

Προφίλ κύριας υπηρεσίας

Η δυνατότητα προφίλ κύριας υπηρεσίας έχει σχεδιαστεί για να διευκολύνει τη διαχείριση εταιρικού περιεχομένου στο Power BI και την πιο αποτελεσματική χρήση των εκχωρημένων πόρων σας. Συμβάλλουν στην αντιμετώπιση τριών συγκεκριμένων προκλήσεων που περιλαμβάνουν το χαμηλότερο ποσοστό προσπάθειας και επιβάρυνσης προγραμματιστών. Αυτές οι προκλήσεις περιλαμβάνουν:

• Κλιμάκωση σε μεγάλο αριθμό χώρων εργασίας.
• Βελτιστοποίηση επιδόσεων κλήσεων REST API.
• Απομόνωση σημασιολογικών μοντέλων και διαπιστευτηρίων προέλευσης δεδομένων σε επίπεδο μισθωτή πελάτη.

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

Τα προφίλ κύριας υπηρεσίας είναι τοπικοί λογαριασμοί που δημιουργούνται στο περιβάλλον του Power BI. Μια κύρια υπηρεσία μπορεί να χρησιμοποιήσει τη Profiles λειτουργία REST API για να δημιουργήσει νέα προφίλ κύριας υπηρεσίας. Μια κύρια υπηρεσία μπορεί να δημιουργήσει και να διαχειριστεί το δικό της σύνολο προφίλ κύριας υπηρεσίας για μια προσαρμοσμένη εφαρμογή, όπως φαίνεται στο παρακάτω διάγραμμα.

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

Τα προφίλ κύριας υπηρεσίας δεν είναι γνωστά στο Microsoft Entra

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

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

Ωστόσο, υπάρχουν και μειονεκτήματα. Επειδή τα προφίλ κύριας υπηρεσίας δεν είναι γνωστά στο Microsoft Entra, δεν μπορείτε να προσθέσετε ένα προφίλ κύριας υπηρεσίας σε μια ομάδα Microsoft Entra για να εκχωρήσετε έμμεσα πρόσβαση σε έναν χώρο εργασίας. Επίσης, οι εξωτερικές προελεύσεις δεδομένων, όπως μια βάση δεδομένων SQL Azure ή το Azure Synapse Analytics, δεν μπορούν να αναγνωρίσουν τα προφίλ κύριας υπηρεσίας ως ταυτότητα κατά τη σύνδεση σε μια βάση δεδομένων. Επομένως, η μοναδική στρατηγική σχεδίασης κύριας υπηρεσίας ανά χώρο εργασίας (δημιουργία μιας κύριας υπηρεσίας για κάθε μισθωτή πελάτη) μπορεί να είναι μια καλύτερη επιλογή όταν υπάρχει μια απαίτηση σύνδεσης σε αυτές τις προελεύσεις δεδομένων χρησιμοποιώντας μια ξεχωριστή κύρια υπηρεσία με μοναδικά διαπιστευτήρια ελέγχου ταυτότητας για κάθε μισθωτή πελάτη.

Τα προφίλ κύριας υπηρεσίας είναι κύριες ασφαλείας πρώτης κατηγορίας

Παρόλο που τα προφίλ κύριας υπηρεσίας δεν είναι γνωστά στο Microsoft Entra, το Power BI τα αναγνωρίζει ως κύριες ασφαλείας πρώτης κατηγορίας. Όπως ακριβώς με έναν λογαριασμό χρήστη ή μια κύρια υπηρεσία, μπορείτε να προσθέσετε προφίλ κύριας υπηρεσίας σε έναν ρόλο χώρου εργασίας (ως διαχειριστής ή μέλος). Μπορείτε επίσης να το μετατρέψετε σε κάτοχο μοντέλου σημασιολογίας και κάτοχο διαπιστευτηρίων προέλευσης δεδομένων. Για αυτούς τους λόγους, η δημιουργία ενός νέου προφίλ κύριας υπηρεσίας για κάθε νέο μισθωτή πελάτη αποτελεί βέλτιστη πρακτική.

Φιλοδώρημα

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

Εκτέλεση κλήσεων REST API ως προφίλ κύριας υπηρεσίας

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

1. Όταν ένα προφίλ κύριας υπηρεσίας δημιουργεί έναν νέο χώρο εργασίας, το Power BI προσθέτει αυτόματα αυτό το προφίλ ως διαχειριστή χώρου εργασίας.
2. Όταν ένα προφίλ κύριας υπηρεσίας εισάγει ένα αρχείο Power BI Desktop για να δημιουργήσει ένα μοντέλο σημασιολογίας, το Power BI ορίζει αυτό το προφίλ ως κάτοχο μοντέλου σημασιολογίας.
3. Όταν ένα προφίλ κύριας υπηρεσίας ορίζει διαπιστευτήρια προέλευσης δεδομένων, το Power BI ορίζει αυτό το προφίλ ως κάτοχο των διαπιστευτηρίων προέλευσης δεδομένων.

Είναι σημαντικό να κατανοήσετε ότι μια κύρια υπηρεσία έχει μια ταυτότητα στο Power BI που είναι ξεχωριστή και διακριτή από τις ταυτότητες των προφίλ της. Αυτό σας παρέχει επιλογές ως προγραμματιστής. Μπορείτε να εκτελέσετε κλήσεις REST API χρησιμοποιώντας την ταυτότητα ενός προφίλ κύριας υπηρεσίας. Εναλλακτικά, μπορείτε να εκτελέσετε κλήσεις REST API χωρίς προφίλ, το οποίο χρησιμοποιεί την ταυτότητα της γονικής κύριας υπηρεσίας.

Συνιστούμε να εκτελείτε κλήσεις REST API ως γονική κύρια υπηρεσία όταν δημιουργείτε, προβάλετε ή διαγράφετε προφίλ κύριας υπηρεσίας. Θα πρέπει να χρησιμοποιήσετε το προφίλ κύριας υπηρεσίας για την εκτέλεση όλων των άλλων κλήσεων REST API. Αυτές οι άλλες κλήσεις μπορούν να δημιουργήσουν χώρους εργασίας, να εισαγάγουν αρχεία Power BI Desktop, να ενημερώσουν παραμέτρους σημασιολογικών μοντέλων και να ορίσουν διαπιστευτήρια προέλευσης δεδομένων. Μπορούν επίσης να ανακτήσουν μετα-δεδομένα στοιχείων χώρου εργασίας και να δημιουργήσουν διακριτικά ενσωμάτωσης.

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

1. Δημιουργήστε έναν χώρο εργασίας.
2. Συσχετίστε τον χώρο εργασίας με ένα σύνολο εκχωρημένων πόρων.
3. Εισαγωγή αρχείου Power BI Desktop.
4. Ορίστε παραμέτρους σημασιολογικού μοντέλου.
5. Ορισμός διαπιστευτηρίων προέλευσης δεδομένων.
6. Ρυθμίστε προγραμματισμένη ανανέωση δεδομένων.

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

Φιλοδώρημα

Να θυμάστε: Κατά την πραγματοποίηση κλήσεων REST API, χρησιμοποιήστε την κύρια υπηρεσία για να δημιουργήσετε και να διαχειριστείτε προφίλ κύριας υπηρεσίας και χρησιμοποιήστε το προφίλ κύριας υπηρεσίας για να δημιουργήσετε, να ρυθμίσετε και να αποκτήσετε πρόσβαση σε περιεχόμενο Power BI.

Χρήση των λειτουργιών REST API προφίλ

Η ομάδα λειτουργιών REST API Προφίλ αποτελείται από λειτουργίες που δημιουργούν και διαχειρίζονται προφίλ κύριας υπηρεσίας:

• Create Profile
• Delete Profile
• Get Profile
• Get Profiles
• Update Profile

Δημιουργία προφίλ κύριας υπηρεσίας

Χρησιμοποιήστε τη λειτουργία Δημιουργία προφίλ REST API για να δημιουργήσετε ένα προφίλ κύριας υπηρεσίας. Πρέπει να ορίσετε την displayName ιδιότητα στο σώμα αίτησης για να καταχωρήσετε ένα εμφανιζόμενο όνομα για τον νέο μισθωτή. Η τιμή πρέπει να είναι μοναδική σε όλα τα προφίλ που ανήκουν στην κύρια υπηρεσία. Η κλήση θα αποτύχει εάν υπάρχει ήδη ένα άλλο προφίλ με αυτό το εμφανιζόμενο όνομα για την κύρια υπηρεσία.

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

Εάν προγραμματίζετε με το Power BI .NET SDK, μπορείτε να χρησιμοποιήσετε τη Profiles.CreateProfile μέθοδο , η οποία επιστρέφει ένα ServicePrincipalProfile αντικείμενο που αντιπροσωπεύει το νέο προφίλ. Διευκολύνει τον προσδιορισμό της τιμής ιδιότητας id .

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

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

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

Διαγραφή προφίλ κύριας υπηρεσίας

Χρησιμοποιήστε τη λειτουργία Διαγραφή προφίλ REST API για να διαγράψετε ένα προφίλ κύριας υπηρεσίας. Αυτή η λειτουργία μπορεί να κληθεί μόνο από τη γονική κύρια υπηρεσία.

Εάν προγραμματίζετε με το Power BI .NET SDK, μπορείτε να χρησιμοποιήσετε τη Profiles.DeleteProfile μέθοδο .

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

Χρησιμοποιήστε τη λειτουργία REST API Λήψη προφίλ για να ανακτήσετε μια λίστα των προφίλ κύριας υπηρεσίας που ανήκουν στην κύρια υπηρεσία κλήσης. Αυτή η λειτουργία επιστρέφει ένα ωφέλιμο φορτίο JSON που περιέχει τις id ιδιότητες και displayName κάθε προφίλ κύριας υπηρεσίας.

Εάν προγραμματίζετε με το .NET SDK του Power BI, μπορείτε να χρησιμοποιήσετε τη μέθοδο Profiles.GetProfiles .

Εκτέλεση κλήσεων REST API χρησιμοποιώντας ένα προφίλ κύριας υπηρεσίας

Υπάρχουν δύο απαιτήσεις για την πραγματοποίηση κλήσεων REST API χρησιμοποιώντας ένα προφίλ κύριας υπηρεσίας:

• Πρέπει να διαβιβάσετε το διακριτικό πρόσβασης για τη γονική κύρια υπηρεσία στην κεφαλίδα εξουσιοδότησης .
• Πρέπει να συμπεριλάβετε μια κεφαλίδα με την ονομασία X-PowerBI-profile-id με την τιμή του αναγνωριστικού του προφίλ κύριας υπηρεσίας.

Εάν χρησιμοποιείτε το Power BI .NET SDK, μπορείτε να ορίσετε την τιμή κεφαλίδας X-PowerBI-profile-id ρητά διαβιβάζοντας το αναγνωριστικό του προφίλ κύριας υπηρεσίας.

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

Όπως φαίνεται στο παραπάνω παράδειγμα, όταν προσθέσετε την κεφαλίδα X-PowerBI-profile-id στο PowerBIClient αντικείμενο, είναι εύκολο να καλέσετε μεθόδους, όπως Groups.GetGroups, ώστε να εκτελεστούν χρησιμοποιώντας το προφίλ κύριας υπηρεσίας.

Υπάρχει ένας πιο εύκολος τρόπος για να ορίσετε την κεφαλίδα X-PowerBI-profile-id για ένα PowerBIClient αντικείμενο. Μπορείτε να προετοιμάσετε το αντικείμενο διαβιβάζοντας το αναγνωριστικό του προφίλ στην κατασκευή.

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

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

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

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

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

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

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

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

Δείγμα προγραμματιστή

Σας προτείνουμε να κάνετε λήψη ενός δείγματος εφαρμογής με το όνομα AppOwnsDataMultiTenant.

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

Σχετικό περιεχόμενο

Για περισσότερες πληροφορίες σχετικά με αυτό το άρθρο, ανατρέξτε στους παρακάτω πόρους:

• Προφίλ κύριας υπηρεσίας για εφαρμογές πολλαπλών χρήσεων στο Power BI Embedded
• Μετεγκατάσταση εφαρμογών πολλών πελατών στο μοντέλο προφίλ κύριας υπηρεσίας
• Προφίλ ομάδας λειτουργίας Power BI REST API
• Δείγμα εφαρμογής AppOwnsDataMultiTenant
• Ερωτήσεις; δοκιμάστε να ρωτήσετε το Κοινότητας Fabric
• Προτάσεις? συνεισφέρετε ιδέες για τη βελτίωση του Fabric