พัฒนาแอปพลิเคชันการมีหลายรูปแบบที่ปรับขนาดได้ด้วยการฝัง Power BI

บทความนี้อธิบายวิธีพัฒนาแอปพลิเคชันที่พร้อมใช้งานหลายรายการที่ฝังเนื้อหา Power BI ในขณะที่บรรลุระดับสูงสุดของความสามารถในการปรับขนาด ประสิทธิภาพ การทํางาน และการรักษาความปลอดภัย ด้วยการออกแบบและการใช้แอปพลิเคชันด้วย โปรไฟล์บริการหลัก คุณสามารถสร้างและจัดการโซลูชันการใช้งานที่หลากหลายซึ่งประกอบด้วยผู้เช่าลูกค้าหลายหมื่นรายที่สามารถส่งรายงานให้กับผู้ชมที่มีผู้ใช้มากกว่า 100,000 ราย

โปรไฟล์ บริการหลักเป็นคุณลักษณะที่ทําให้คุณสามารถจัดการเนื้อหาขององค์กรใน Power BI ได้ง่ายขึ้นและใช้ความจุของคุณได้อย่างมีประสิทธิภาพมากขึ้น อย่างไรก็ตาม การใช้โปรไฟล์บริการหลักสามารถเพิ่มความซับซ้อนในการออกแบบแอปพลิเคชันของคุณได้ ดังนั้น คุณควรใช้เฉพาะเมื่อมีความจําเป็นในการบรรลุขนาดที่มีนัยสําคัญเท่านั้น เราขอแนะนําให้ใช้โปรไฟล์บริการหลักเมื่อคุณมีพื้นที่ทํางานจํานวนมากและผู้ใช้แอปพลิเคชันมากกว่า 1,000 ราย

หมายเหตุ

ค่าของการใช้โปรไฟล์บริการหลักจะเพิ่มขึ้นตามที่คุณต้องการเพื่อปรับมาตราส่วนที่เพิ่มขึ้น รวมถึงความต้องการของคุณในการบรรลุการแยกความปลอดภัยและการแยกผู้เช่าในระดับสูงสุด

คุณสามารถทําการฝัง Power BI ได้โดยใช้สถานการณ์การฝังที่แตกต่างกันสองสถานการณ์: ฝังสําหรับองค์กรของคุณ และ ฝังสําหรับลูกค้าของคุณ

สถานการณ์การฝังตัวสําหรับองค์กรของคุณจะนําไปใช้เมื่อผู้ชมแอปพลิเคชันประกอบด้วยผู้ใช้ภายใน ผู้ใช้ภายในมีบัญชีองค์กรและต้องรับรองความถูกต้องด้วยรหัส Microsoft Entra (ก่อนหน้านี้เรียกว่า Azure Active Directory) ในสถานการณ์นี้ 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 นอกจากนี้ยังรองรับระบบอัตโนมัติและการปรับมาตราส่วนที่ดีขึ้นและมีค่าใช้จ่ายในการจัดการน้อยลง อย่างไรก็ตาม จําเป็นต้องใช้สิทธิ์ผู้ดูแลระบบ Power BI ในการตั้งค่าและจัดการ

ด้วยการใช้โครงร่างสําคัญของบริการ คุณสามารถหลีกเลี่ยงปัญหาทั่วไปที่เกี่ยวข้องกับบัญชีผู้ใช้หลัก เช่น ข้อผิดพลาดในการรับรองความถูกต้องในสภาพแวดล้อมที่ผู้ใช้จําเป็นต้องลงชื่อเข้าใช้ โดยใช้การรับรองความถูกต้องแบบหลายปัจจัย (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 สําหรับบริการหลักทั้งสองรายอนุญาตให้เมตาดาต้าสําหรับ ACLs เพิ่มขึ้นเป็นจุดที่จะลดประสิทธิภาพการทํางานในระดับหนึ่ง

นี่คือข้อสังเกตที่สําคัญ: จํานวนของพื้นที่ทํางานที่สร้างขึ้นโดยโครงร่างสําคัญของบริการมีผลกระทบโดยตรงต่อประสิทธิภาพการทํางานและการปรับขนาด โครงร่างสําคัญของบริการที่เป็นสมาชิกของพื้นที่ทํางาน 100 จะดําเนินการเรียกใช้ REST API ได้เร็วกว่าบริการหลักที่เป็นสมาชิกของพื้นที่ทํางาน 1,000 ในทํานองเดียวกัน บริการหลักที่เป็นสมาชิกของพื้นที่ทํางานเพียง 10 แห่งจะดําเนินการเรียกใช้ REST API ได้เร็วกว่าบริการหลักที่เป็นสมาชิกของพื้นที่ทํางาน 100 แห่ง

สำคัญ

จากมุมมองของประสิทธิภาพและความสามารถในการปรับขนาด จํานวนพื้นที่ทํางานที่เหมาะสมซึ่งโครงร่างสําคัญของบริการเป็นสมาชิก

จัดการการแยกสําหรับแบบจําลองความหมายและข้อมูลประจําตัวของแหล่งข้อมูล

สิ่งสําคัญอีกประการหนึ่งเมื่อออกแบบแอปพลิเคชันการใช้งานหลายรายการคือการแยกผู้เช่าลูกค้า เป็นสิ่งสําคัญที่ผู้ใช้จากผู้เช่าลูกค้าหนึ่งไม่เห็นข้อมูลของผู้เช่าลูกค้ารายอื่น ดังนั้น คุณต้องเข้าใจวิธีการจัดการความเป็นเจ้าของแบบจําลองความหมายและข้อมูลประจําตัวของแหล่งข้อมูล

ความเป็นเจ้าของแบบจําลองความหมาย

แบบจําลองความหมาย Power BI แต่ละตัวจะเป็นเจ้าของเดียว ซึ่งสามารถเป็นบัญชีผู้ใช้หรือโครงร่างสําคัญของบริการ คุณต้องมีความเป็นเจ้าของแบบจําลองความหมายในการตั้งค่าการรีเฟรชตามกําหนดการและตั้งค่าพารามิเตอร์แบบจําลองความหมาย

เคล็ดลับ

ในบริการของ Power BI คุณสามารถกําหนดว่าใครคือเจ้าของแบบจําลองความหมายโดยการเปิดการตั้งค่าแบบจําลองความหมาย

ถ้าจําเป็น คุณสามารถโอนการเป็นเจ้าของแบบจําลองความหมายไปยังบัญชีผู้ใช้หรือบริการหลักอื่นได้ คุณสามารถทําได้ในบริการของ Power BI หรือโดยใช้การดําเนินการ REST API TakeOver เมื่อคุณนําเข้าไฟล์ Power BI Desktop เพื่อสร้างแบบจําลองความหมายใหม่โดยใช้โครงร่างสําคัญของบริการ โครงร่างสําคัญของบริการจะถูกตั้งค่าเป็นเจ้าของแบบจําลองความหมายโดยอัตโนมัติ

ข้อมูลประจำตัวของแหล่งข้อมูล

หากต้องการเชื่อมต่อแบบจําลองความหมายกับแหล่งข้อมูลพื้นฐาน เจ้าของแบบจําลองความหมายต้องตั้งค่าข้อมูลประจําตัวของแหล่งข้อมูล ข้อมูลประจําตัวของแหล่งข้อมูลถูกเข้ารหัสและแคชโดย 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 ID ไม่ทราบอะไรเกี่ยวกับโปรไฟล์บริการหลัก เนื่องจากโปรไฟล์บริการหลักถูกสร้างขึ้นโดย Power BI และมีอยู่ในระบบย่อยบริการของ Power BI ที่ควบคุมความปลอดภัยและการรับรองความถูกต้องของ Power BI เท่านั้น

ข้อเท็จจริงที่ว่าโปรไฟล์บริการหลักไม่ทราบสําหรับ Microsoft Entra ID มีทั้งข้อดีและข้อเสีย ประโยชน์หลักคือ แอปพลิเคชันฝังตัวสําหรับสถานการณ์ลูกค้า ของคุณไม่จําเป็นต้องมีสิทธิ์พิเศษของ Microsoft Entra เพื่อสร้างโปรไฟล์บริการหลัก นอกจากนี้ยังหมายความว่าแอปพลิเคชันสามารถสร้างและจัดการชุดของข้อมูลประจําตัวภายในเครื่องที่แยกต่างหากจาก Microsoft Entra

อย่างไรก็ตามก็มีข้อเสียเช่นกัน เนื่องจากไม่พบโปรไฟล์บริการหลักใน Microsoft Entra คุณจะไม่สามารถเพิ่มโปรไฟล์บริการหลักไปยังกลุ่ม Microsoft Entra เพื่ออนุญาตให้เข้าถึงพื้นที่ทํางานโดยนัยได้ นอกจากนี้ แหล่งข้อมูลภายนอก เช่น ฐานข้อมูล Azure SQL หรือ 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 ที่แสดงโปรไฟล์ เมื่อคุณพัฒนาแอปพลิเคชันที่ใช้โปรไฟล์บริการหลัก เราขอแนะนําให้คุณจัดเก็บชื่อที่แสดงโปรไฟล์และค่า ID ไว้ในฐานข้อมูลแบบกําหนดเอง ด้วยวิธีนี้ การเรียกใช้รหัสของแอปพลิเคชันของคุณจะตรงไปตรงมา

ถ้าคุณกําลังเขียนโปรแกรมด้วย 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 คุณสมบัติของแต่ละโปรไฟล์บริการหลัก

ถ้าคุณกําลังเขียนโปรแกรมด้วย Power BI .NET SDK คุณสามารถใช้ เมธอด Profiles.GetProfiles ได้

ดําเนินการเรียกใช้ REST API โดยใช้โปรไฟล์บริการหลัก

มีสองข้อกําหนดสําหรับการเรียกใช้ REST API โดยใช้โปรไฟล์บริการหลัก:

• คุณต้องผ่านโทเค็นการเข้าถึงสําหรับบริการหลักในส่วนหัวการรับรองความถูกต้อง
• คุณต้องใส่ส่วนหัวที่ ชื่อ X-PowerBI-profile-id ด้วยค่าของ ID โปรไฟล์ของบริการหลัก

หากคุณกําลังใช้ Power BI .NET SDK คุณสามารถตั้งค่า ส่วนหัวของรหัสโปรไฟล์ X-PowerBI ได้อย่างชัดเจนโดยการส่งผ่านใน 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 ออบเจ็กต์ คุณสามารถเตรียมใช้งานออบเจ็กต์ได้โดยการส่งผ่านใน ID ของโปรไฟล์ไปยังคอนสตรักเตอร์

// 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 เมธอด โดยการส่งผ่านใน ID ของโปรไฟล์ ด้วยวิธีนี้ คุณสามารถสร้างพื้นที่ทํางานโดยใช้ข้อมูลประจําตัวของโปรไฟล์บริการหลัก

// 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
• คำถาม ลองถามชุมชน Power BI
• คำ แนะ นำ สนับสนุนแนวคิดในการปรับปรุง Power BI