หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
โซลูชันระดับองค์กรจําเป็นต้องส่งข้อความได้อย่างเชื่อถือได้เมื่อมีการเปลี่ยนแปลงข้อมูลที่เกิดขึ้นใน Dataverse สถาปัตยกรรมอ้างอิงนี้แสดงวิธีปรับใช้รูปแบบ Transactional Outbox กับ Dataverse เพื่อลดความเสี่ยงต่อการสูญหายของข้อความและช่วยทําให้ระบบที่รวมเข้าด้วยกันทํางานสอดคล้องกัน
Tip
บทความนี้แสดงตัวอย่างสถานการณ์และสถาปัตยกรรมตัวอย่างทั่วไปเพื่อแสดงให้เห็นวิธีการนําส่งเหตุการณ์ที่เชื่อถือได้จาก Dataverse ตัวอย่างสถาปัตยกรรมสามารถแก้ไขได้สำหรับสถานการณ์และอุตสาหกรรมต่างๆ มากมาย
แผนภาพสถาปัตยกรรม
เวิร์กโฟลว์
ขั้นตอนต่อไปนี้อธิบายเวิร์กโฟลว์ที่แสดงในไดอะแกรมสถาปัตยกรรมตัวอย่าง:
- การดําเนินการข้อมูลใน Dataverse เกิดขึ้น เช่น การสร้างหรือการอัปเดตระเบียนผู้ติดต่อ การดําเนินการนี้สร้างทรานแซคชันฐานข้อมูล
- ปลั๊กอินแบบซิงโครนัสของ Dataverse ทริกเกอร์ตอบสนองต่อเหตุการณ์นี้ และสร้างระเบียนในตารางกล่องขาออกภายใน Dataverse เป็นส่วนหนึ่งของธุรกรรมเดียวกัน
- ถ้าปลั๊กอินดําเนินการได้สําเร็จ ธุรกรรมจะคอมมิตทั้งระเบียนกล่องขาออกและการเปลี่ยนแปลงของระเบียนต้นฉบับ (เช่น Contact)
- ถ้าการดําเนินการปลั๊กอินล้มเหลว เหตุการณ์ข้อมูลเดิมจะย้อนกลับ และ Dataverse จะไม่บันทึกการแก้ไขระเบียนใดๆ
- ปลั๊กอินแบบอะซิงโครนัสจะทริกเกอร์เพื่อตอบสนองต่อการสร้างเรกคอร์ดในตารางกล่องขาออกใน Dataverse และเขียนข้อความไปยังคิวหรือหัวข้อ Azure Service Bus
- ตัวใช้ข้อความรอรับข้อความเพื่อประมวลผลและส่งไปยังระบบเป้าหมาย
ส่วนประกอบ
Dataverse เป็นระบบบันทึกข้อมูลธุรกรรมต้นทางของข้อมูลที่เป็นที่เกิดเหตุการณ์ข้อมูลและเป็นที่อยู่ของตารางกล่องขาออก ซึ่งจะส่งข้อความไปยังโบรกเกอร์ข้อความแบบอะซิงโครนัสโดยใช้ปลั๊กอิน
Azure Service Bus เป็นโบรกเกอร์องค์กรที่เชื่อถือได้ซึ่งรับข้อความจาก Dataverse สำหรับการประมวลผลจากระบบที่รับดำเนินการ
- คิว จะเหมาะสมเมื่อมีผู้รับข้อความรายเดียว
- ทอปิก เหมาะที่สุดเมื่อสมาชิกหลายรายอาจประมวลผลข้อความเดียวกัน หรือต้องการเกณฑ์การกรองเพื่อเลือกประมวลผลข้อความ
Azure Monitor คือโซลูชันการตรวจสอบที่ครอบคลุมสําหรับรวบรวม วิเคราะห์ และตอบสนองต่อการตรวจสอบข้อมูลจากโซลูชันระบบคลาวด์และในองค์กร ใช้เมตริกที่มีอยู่ภายในสําหรับ Azure Service Bus เพื่อตรวจสอบจํานวนของข้อความในคิวหรือทอปิก หรือคิวข้อความที่ไม่สามารถส่งได้
Azure Application Insights ใช้สําหรับการตรวจสอบประสิทธิภาพการทํางานของแอปพลิเคชัน และสามารถเปิดใช้งานสําหรับปลั๊กอิน Dataverse เพื่อส่งบันทึกการติดตามไปยังพื้นที่ทํางาน Application Insights
ตัวเลือกอื่น:
- Azure Logic Apps: ทางเลือกโลว์โค้ดที่ใช้ได้จริงเพื่อส่งข้อความจากตารางเอ้าท์บ็อกซ์ไปยังตัวกลางข้อความหากคุณต้องการการควบคุมที่แม่นยำยิ่งขึ้นเกี่ยวกับเวลาที่จะทริกเกอร์การออร์เคสเทรชันและการส่งข้อความ (ตัวอย่างเช่น ไมโครบัชชิง)
- ฟังก์ชัน Azure: เป็นทางเลือกแบบโค้ดเป็นหลักที่ให้คุณมีความยืดหยุ่นและปรับขนาดได้มากที่สุดเพื่อจัดการปริมาณงานที่สูงขึ้นและการลองใหม่เมื่อเกิดความล้มเหลวเป็นระยะ ๆ
รายละเอียดของสถานการณ์จำลอง
โซลูชันระดับองค์กรมักจําเป็นต้องแลกเปลี่ยนข้อมูลที่สําคัญกับระบบอื่น ๆ ผ่านข้อความ เพื่อให้แน่ใจว่ามีความสอดคล้องกันข้ามระบบ จัดการการดําเนินการข้อมูลและการส่งข้อความเป็นการดําเนินการแบบอะตอมเดียว อย่างไรก็ตาม ระบบธุรกรรมและโบรกเกอร์ข้อความส่วนใหญ่ไม่ค่อยรองรับธุรกรรมแบบกระจาย หรือทำให้เกิดการเชื่อมโยงกันอย่างแน่นหนาซึ่งคุณต้องการหลีกเลี่ยง หากไม่มีธุรกรรมแบบกระจาย ก็จะไม่มีการรับประกันความน่าเชื่อถือ เนื่องจากความล้มเหลวอาจเกิดขึ้นเมื่อส่งข้อความไปยังโบรกเกอร์หลังจากคอมมิตธุรกรรม
รูปแบบกล่องขาออกของธุรกรรมช่วยแก้ปัญหานี้โดยการสร้างข้อความในธุรกรรมฐานข้อมูลภายในเดียวกันกับที่อัปเดตข้อมูลธุรกิจ กระบวนการที่แยกต่างหากสามารถส่งข้อความจากตารางกล่องขาออกไปยัง message broker ความล้มเหลวของกระบวนการเป็นระยะไม่ใช่ปัญหา ตารางกล่องขาออกจัดเก็บข้อความเพื่อไม่ให้สูญหาย และกระบวนการจะลองใหม่อีกครั้งจนกว่าจะสําเร็จ
Dataverse เป็นแพลตฟอร์มข้อมูลแบบโลว์โค้ดที่มีความสามารถสูงและขยายได้ พร้อมที่เก็บข้อมูลธุรกรรมที่สามารถใช้รูปแบบนี้สำหรับสถานการณ์การผสานรวมขาออกที่สำคัญ
ข้อควรพิจารณา
ข้อควรพิจารณาเหล่านี้ใช้เสาหลักของ Power Platform Well-Architected ซึ่งเป็นชุดหลักการชี้นําเพื่อช่วยปรับปรุงคุณภาพของปริมาณงาน เรียนรู้เพิ่มเติมเกี่ยวกับ Microsoft Power Platform Well-Architected
ความน่าเชื่อถือ
รูปแบบนี้เพิ่มความน่าเชื่อถืออย่างมากรับประกันการส่งมอบอย่างน้อยหนึ่งครั้งและความสอดคล้องในที่สุดโดยรับรองความสอดคล้องของการทําธุรกรรม ด้วยการพึ่งพาตัวกลางข้อความ จะช่วยปกป้องระบบปลายทางจากการทำงานหนักเกินไปโดยการควบคุมการไหลของข้อมูลระหว่างระบบต้นทางและระบบเป้าหมาย และป้องกันปัญหาความพร้อมใช้งานของระบบปลายทาง
เมื่อจำเป็นต้องจัดลำดับข้อความ ให้เปิดใช้งานเซสชัน Azure Service Bus ในคิวหรือการสมัครรับข้อมูล ผู้ผลิตควรกำหนด SessionId ที่สอดคล้องกัน เช่น เรคคอร์ด Dataverse หรือรหัส aggregate ให้กับข้อความที่เกี่ยวข้องเพื่อให้ได้รับการประมวลผลตามลำดับภายในเซสชันนั้น ออกแบบคอนซูเมอร์สำหรับการประมวลผลแบบ idempotent เนื่องจากรูปแบบนี้รองรับการส่งแบบอย่างน้อยหนึ่งครั้ง และอาจมีข้อความซ้ำเกิดขึ้น เมื่อการตรวจหาเหตุการณ์ที่หายไปหรือผิดลำดับเป็นสิ่งสำคัญ ข้อความสามารถมีหมายเลขลำดับระดับแอปพลิเคชันได้ การรับประกันลำดับข้อความจะนําไปใช้ภายในเซสชันแทนที่จะเป็นส่วนกลาง และโซลูชันควรกําหนดว่าวิธีการลองใหม่และข้อความที่ถูกส่งไปยังคิว Dead Letter มีผลต่อการประมวลผลที่ตามมาสําหรับเซสชันนั้นอย่างไร
Security
เมื่อใช้บริการ Azure ทำให้ Dataverse สามารถรับรองความถูกต้องกับโบรกเกอร์ข้อความ (Azure Service Bus) ผ่านคุณลักษณะข้อมูลประจำตัวที่มีการจัดการของ Power Platform แนวทางนี้ขจัดความเสี่ยงในการจัดเก็บข้อมูลรับรองที่ละเอียดอ่อนและการหยุดทำงานที่เกิดขึ้นเมื่อมีการหมุนเวียนข้อมูลลับ
ประสิทธิภาพการทำงาน
การใช้ตัวกลางข้อความ เช่น Azure Service Bus ช่วยกระจายภาระงานเพื่อให้แน่ใจว่าแอปพลิเคชันปลายทางจะไม่รับภาระมากเกินไปในช่วงเวลาที่มีปริมาณงานสูง
พิจารณาใช้ฟังก์ชัน Azure แทนปลั๊กอิน Dataverse แบบอะซิงโครนัสเพื่อส่งข้อความไปยัง Azure Service Bus หากปริมาณงานมีจำนวนสูงมาก วิธีนี้ให้ความสามารถในการปรับขนาดและความยืดหยุ่นมากที่สุดในการประมวลผลเรกคอร์ดจำนวนมากเป็นชุดและจัดการข้อผิดพลาดชั่วคราว
ผู้สนับสนุน
Microsoft ดูแลบทความนี้ ผู้เขียนต่อไปนี้ได้เขียนบทความนี้
ผู้เขียนหลัก:
- Chris Piasecki, โซลูชันสถาปนิก