สํารวจรูปแบบการรวม

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

รูปแบบแต่ละรูปแบบเน้นสถานการณ์ทางธุรกิจเฉพาะและข้อจํากัดทางเทคนิค:

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

รูปแบบทริกเกอร์ทันที

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

สถานการณ์ตัวอย่าง

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

เหตุผลในการรวมแทนที่จะเปลี่ยนเส้นทางผู้ใช้ไปยัง Oracle ประกอบด้วย:

• ประสบการณ์ของผู้ใช้ไม่ดี
• ข้อกังวลด้านความปลอดภัย
• ค่าใช้จ่ายสิทธิ์การใช้งาน

เนื่องจากต้นทุนที่มีประสิทธิภาพของการรวม Power Platform เหตุผลเหล่านี้อาจทำให้ควรมีการใช้งาน

การออกแบบโฟลว์

ใช้โฟลว์คลาวด์ทันทีที่ถูกกระตุ้นโดยการกดปุ่มในแอพ

ไดอะแกรมนี้แสดงรูปแบบทริกเกอร์ทันที ซึ่งการดําเนินการที่ผู้ใช้เริ่มต้นจะดึงข้อมูลจากระบบภายนอกและเขียนลงใน Dataverse:

โฟลว์ประกอบด้วยขั้นตอนเหล่านี้:

1. ร้องขอระเบียนจาก Oracle โดยใช้พารามิเตอร์ (เช่น ID ผลิตภัณฑ์) ที่แอปให้มา
2. ส่งกลับระเบียนจาก Oracle ไปยังแอป
3. เขียนระเบียนไปยัง Dataverse

จากนั้น ข้อมูลนี้จะปรากฏในอินเทอร์เฟซ Power Apps

ข้อควรพิจารณา:

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

รูปแบบการขับเคลื่อนเหตุการณ์

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

สถานการณ์ตัวอย่าง

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

ใช้ทริกเกอร์อัตโนมัติใน Power Automate เพื่อตอบสนองต่อเหตุการณ์เหล่านี้ โฟลว์จะรอรับการเปลี่ยนแปลงในระเบียน Dataverse และส่งการแจ้งเตือนเมื่อตรงตามเงื่อนไขที่กําหนด

แผนภาพนี้แสดงรูปแบบทริกเกอร์อัตโนมัติ ซึ่งการเปลี่ยนแปลงใน Dataverse จะเริ่มต้นการดําเนินการปลายทางโดยอัตโนมัติซึ่งอัปเดตลูกค้าด้วยข้อมูลกรณีที่เกี่ยวข้อง:

การกําหนดค่าทริกเกอร์

กําหนดค่าโฟลว์ดังนี้:

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

หลีกเลี่ยงการนำตรรกะนี้ไปใช้ในโฟลว์ด้วยการดำเนินการ If ใช้พารามิเตอร์ทริกเกอร์เพื่อลดการดําเนินการที่ไม่จําเป็นและปรับปรุงประสิทธิภาพการทํางาน

หลีกเลี่ยงข้อขัดแย้งเชิงตรรกะ

ประเมินตรรกะเหตุการณ์เพื่อป้องกันลักษณะการทํางานที่ไม่ได้ตั้งใจ:

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

ข้อควรพิจารณาเกี่ยวกับปริมาตรและความถี่

ทําความเข้าใจปริมาณที่คาดหวังของเหตุการณ์ที่ถูกกระตุ้น บริการการแจ้งเตือน (อีเมล SMS และอื่น ๆ) จํากัดจํานวนข้อความที่คุณสามารถส่งในกรอบเวลาที่กําหนด

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

รูปแบบการรวมข้อมูล

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

สถานการณ์ตัวอย่าง

บริษัทใช้ระบบดั้งเดิมสามระบบในการจัดการฟังก์ชันธุรกิจหลัก: SAP สําหรับคําสั่งซื้อและบัญชีลูกหนี้ Oracle สําหรับสินค้าคงคลังของผลิตภัณฑ์ และ IBM สําหรับการจัดการเนื้อหาที่เกี่ยวข้องกับลูกค้า องค์กรได้มอบหมายแอป Power Platform ใหม่เพื่อใช้ AI เพื่อคาดการณ์การดําเนินการที่ดีที่สุดถัดไปสําหรับลูกค้าแต่ละรายตามข้อมูลในอดีต แอปต้องรวบรวมข้อมูลที่เกี่ยวข้องจากทั้งสามระบบและสร้างแผนการขายสําหรับผู้จัดการฝ่ายขายเพื่อแนะนําการมีส่วนร่วม

วิธีการผสาน

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

ในกรณีการใช้งานนี้ ทริกเกอร์ที่กําหนดไว้จะรวมข้อมูลดังนี้:

• ร้องขอเฉพาะข้อมูลที่จําเป็นจากแต่ละระบบเท่านั้น
• ส่งกลับข้อมูลเป็นรูปแบบที่เข้ากันได้กับ Dataverse
• อัปโหลดข้อมูลลงในแบบจําลอง AI สําหรับการวิเคราะห์

ไดอะแกรมนี้แสดงรูปแบบการรวมข้อมูลแบบกําหนดเวลา ที่ซึ่งกระบวนการที่เกิดขึ้นซ้ําจะรวบรวมข้อมูลจากหลายระบบ และอัปโหลดชุดข้อมูลรวมลงใน Dataverse:

กําหนดค่าทริกเกอร์ตามกําหนดเวลา

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

• ตรวจสอบเวลาการดําเนินการของโฟลว์เพื่อหลีกเลี่ยงการทับซ้อนหรือความล่าช้า
• ใช้ระบบป้องกันเพื่อป้องกันประสิทธิภาพการทํางานลดลง
• ใช้ Application Insights หรือเครื่องมือที่คล้ายกันเพื่อให้แน่ใจว่าโฟลว์ทํางานอย่างต่อเนื่อง

การลดความเสี่ยง

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

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

รูปแบบการรวมเชิงบริการ

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

สถานการณ์สมมติตัวอย่างที่ได้รับการพิจารณาใหม่

ลองดําเนินการต่อด้วยสถานการณ์ตัวอย่างของเราที่องค์กรใช้ระบบหลายระบบเพื่อจัดการส่วนต่างๆ ของธุรกิจ SAP จัดการคําสั่งซื้อและบัญชีลูกหนี้ Oracle จัดการสินค้าคงคลังของผลิตภัณฑ์และ IBM จัดเก็บเอกสารทางการเงินภายใน Dataverse เรียกใช้แอปสําหรับการขาย การบริการลูกค้า และการจัดการผลิตภัณฑ์ SharePoint สนับสนุนการทํางานร่วมกันภายในและการจัดการฐานความรู้ ในขณะที่ Maersk APIs ทําให้กระบวนการโลจิสติกส์เป็นอัตโนมัติ

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

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

หลีกเลี่ยงโฟลว์แบบโมโนลิธิค

การสร้างโฟลว์ขนาดใหญ่หนึ่งโฟลว์เพื่อจัดการการรวมระบบทั้งหมดอาจไม่ได้เป็นไปได้ในทางปฏิบัติ ซึ่งแนะนําความท้าทายด้านประสิทธิภาพ ความปลอดภัย และการบํารุงรักษา แทน:

• สร้างโฟลว์แบบแยกส่วนสําหรับแต่ละทริกเกอร์และกระบวนการ
• ปรับโฟลว์ให้เหมาะสมสําหรับกรณีการใช้งานเฉพาะ
• ขยายขอบเขตการรวมเข้ากับส่วนประกอบที่สามารถจัดการได้

ปรับกระบวนการข้ามระบบให้เหมาะสม

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

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

ออกแบบกระบวนการทำงานที่:

• แบบแยกส่วนและบํารุงรักษาได้
• สามารถปรับขนาดได้ทั่วทั้งแผนกและระบบ
• ยืดหยุ่นต่อการเปลี่ยนแปลงในตรรกะทางธุรกิจและลักษณะการทํางานของระบบ

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

รูปแบบการซิงโครไนซ์ข้อมูล

ใช้การซิงโครไนซ์ข้อมูลเมื่อระบบเหมือนกันจัดเก็บข้อมูลในฐานข้อมูลแยกต่างหาก แม้ว่าการจัดเก็บข้อมูลเดียวกันสองครั้งอาจดูไม่มีประสิทธิภาพ แต่รูปแบบนี้สนับสนุนความต้องการทางธุรกิจเฉพาะ เช่น ประสิทธิภาพและการปฏิบัติตามกฎระเบียบ

• ประสิทธิภาพ: การเข้าถึงข้อมูลภายในเครื่องช่วยปรับปรุงการตอบสนอง โดยเฉพาะอย่างยิ่งในอุตสาหกรรมที่ไวต่อเวลาแฝง
• การปฏิบัติตามกฎระเบียบ: ข้อบังคับทางกฎหมายอาจจําเป็นต้องมีข้อมูลที่จะจัดเก็บไว้ภายในพรมแดนของชาติ องค์กรมักจะปรับใช้อินสแตนซ์ภายในเครื่องด้วยกระบวนการซิงโครไนซ์เพื่อให้เป็นไปตามข้อกําหนดเหล่านี้

สถานการณ์ตัวอย่าง

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

เพื่อสนับสนุนการดําเนินงานขาย บริษัทต้องการซิงโครไนซ์ข้อมูลที่ไม่เหมาะสม เช่น รายละเอียดการติดต่อ คําสั่งซื้อ และการจัดส่งในทุกอินสแตนซ์ ข้อมูลทางการแพทย์ไม่รวมอยู่ในการซิงโครไนซ์

วิธีการผสาน

ใช้โฟลว์อัตโนมัติบนคลาวด์ที่เริ่มทำงานเมื่อมีการอัปเดตในระเบียนบัญชี กําหนดค่าตัวกรองเป็น:

• ตรวจสอบเฉพาะเขตข้อมูลที่อนุญาต
• ป้องกันการซิงโครไนซ์ของข้อมูลที่ถูกจํากัด

วิธีการนี้ส่งผลให้มีการรวมที่ขับเคลื่อนด้วยเหตุการณ์ที่กําหนดเป้าหมายซึ่งสนับสนุนการปฏิบัติตามกฎระเบียบและประสิทธิภาพในการดําเนินงาน

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

เวลาตอบสนองที่คาดหวัง

ตั้งค่าความคาดหวังจริงสําหรับความเร็วในการซิงโครไนซ์ Power Automate เป็นแบบอะซิงโครนัสและไม่รับประกันประสิทธิภาพการทํางานแบบเรียลไทม์ หากผู้ใช้ทางธุรกิจคาดหวังความพร้อมใช้งานของข้อมูลทันที ให้ชี้แจงข้อจํากัดในช่วงต้นของกระบวนการออกแบบ

• ประเมินว่า Power Automate ตรงกับความต้องการด้านประสิทธิภาพหรือไม่
• หลีกเลี่ยงวิศวกรรมมากเกินไปสําหรับการเข้าถึงแบบเรียลไทม์เว้นแต่จะได้รับการพิสูจน์ตามข้อกําหนดทางธุรกิจ

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

นอกเหนือจากโฟลว์ระบบคลาวด์

เมื่อเลือกเครื่องมือการรวมให้เริ่มต้นด้วย Power Automate เป็นตัวเลือกเริ่มต้น ซึ่งให้ประสิทธิภาพด้านต้นทุนที่ไม่ตรงกันสําหรับทั้งการพัฒนาและการบํารุงรักษา

Power Automate เป็นเครื่องมือการรวมที่ต้องการสําหรับหลายสถานการณ์เนื่องจากมี:

• ส่งมอบการพัฒนาที่รวดเร็วด้วยตัวเชื่อมต่อที่มีรหัสต่ํา
• ลดค่าใช้จ่ายในการบํารุงรักษาในระยะยาว
• รองรับทริกเกอร์และระบบต่าง ๆ ที่หลากหลาย
• รองรับได้ดีสำหรับกรณีธุรกิจส่วนใหญ่

รหัสที่กําหนดเอง ฟังก์ชัน Azure Data Factory หรือ Service Bus อาจให้การควบคุมหรือประสิทธิภาพที่ดีขึ้น แก่คุณ แต่จะเพิ่มความซับซ้อนและต้นทุน ใช้ตัวเลือกเหล่านี้เฉพาะเมื่อ Power Automate ไม่ตรงกับความต้องการทางธุรกิจหรือทางเทคนิคของคุณ

สถานการณ์ตัวอย่าง

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

อย่างไรก็ตามในกรณีนี้วิธีการแบบไฮบริดคือคําตอบ:

• Power Automate เพื่อจัดการคอลเลกชันข้อมูลด้วยตัวเชื่อมต่อที่มีอยู่ภายใน
• การคํานวณที่ซับซ้อนที่ห่อหุ้มไว้ในรหัสแบบกําหนดเองที่เรียกใช้เป็น Azure Function ซึ่งสามารถปรับมาตราส่วนได้อย่างอิสระหรือในตัวเชื่อมต่อแบบกําหนดเอง

วิธีการแบบไฮบริดนี้ปรับสมดุลประสิทธิภาพ ความสามารถในการปรับขนาด และต้นทุน

กลยุทธ์การรวม

อย่าเลือกเครื่องมือโดยไม่พิจารณาบริบทหรือส่วนประกอบอื่น ให้รวมจุดแข็งของพวกเขาแทน. เช่น:

• ใช้ Power Automate สําหรับการเรียงและการเชื่อมต่อกับระบบ
• ใช้ฟังก์ชัน Azure สําหรับงานที่มีการคํานวณมาก
• ใช้ตัวเชื่อมต่อแบบกําหนดเองเพื่อขยายฟังก์ชันการทํางานเมื่อจําเป็น

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