การปรับปรุงแอปพลิเคชันให้ทันสมัยด้วย Power Platform

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

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

เคล็ดลับ

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

บทนำ

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

ความสามารถในการพัฒนาแบบ low-code ของ Microsoft Power Platform ทำให้สามารถสร้างและปรับใช้แอปพลิเคชันสมัยใหม่ได้รวดเร็วและคุ้มทุนมากขึ้นกว่าเดิม ผสานรวมระบบและแหล่งข้อมูลที่มีอยู่ของคุณได้อย่างง่ายดายเพื่อการแลกเปลี่ยนข้อมูลและการทำงานร่วมกันที่ราบรื่น เพิ่มปัญญาประดิษฐ์เพื่อปรับปรุงประสบการณ์ผู้ใช้ กระบวนการอัตโนมัติ และรับข้อมูลเชิงลึกอันมีค่าจากข้อมูลของคุณ ไม่ว่าคุณจะเป็นนักพัฒนาพลเมืองที่แก้ไขรายละเอียดเล็กๆ น้อยๆ หรือนักพัฒนามืออาชีพที่ทำงานเกี่ยวกับการปรับแต่งที่ซับซ้อน คุณสามารถขับเคลื่อนการเปลี่ยนแปลงทางดิจิทัลได้อย่างง่ายดาย รวดเร็วและมีค่าใช้จ่ายต่ำกว่าวิธีการแบบเดิม

ทำไมต้องเป็น Power Platform

เครื่องมือและเทคโนโลยีที่ครอบคลุมซึ่งทำให้ Power Platform ช่วยลดระยะเวลา ต้นทุน และข้อกำหนดในการพัฒนาของโครงการปรับปรุงให้ทันสมัยและการเปลี่ยนแปลงทางดิจิทัลได้อย่างมาก วิธีการแบบเขียนโค้ดน้อยช่วยลด—และยังสามารถขจัด—ความจำเป็นในการเขียนโค้ด วิทยาศาสตร์ข้อมูล และทรัพยากรวิศวกรรม AI ที่มีราคาแพง นักพัฒนาพลเมืองและนักพัฒนามืออาชีพต่างได้รับประโยชน์เหมือนกัน นักพัฒนาพลเมืองสามารถมีบทบาทอย่างชัดเจนในกระบวนการปรับปรุงให้ทันสมัย สร้างแอปพลิเคชันโดยตรงตามความเชี่ยวชาญเฉพาะด้าน และลดการพึ่งพาทีมไอที นักพัฒนามืออาชีพสามารถนำเสนอโซลูชันที่ซับซ้อนได้ในเวลาที่น้อยลง ทำให้พวกเขาสามารถเดินหน้าไปยังโครงการถัดไปได้เร็วขึ้น

ผลิตภัณฑ์และแนวคิดของ Power Platform

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

ตารางต่อไปนี้แสดงภาพรวมระดับสูงของแต่ละผลิตภัณฑ์ Power Platform

ผลิตภัณฑ์	Description
Power Apps	สร้างแอปพลิเคชันแบบกำหนดเองในพื้นที่พื้นที่ทำงานแบบลากและวางที่ใช้งานง่าย ด้วยตัวเชื่อมต่อมากกว่าหนึ่งพันรายการ แหล่งข้อมูลและบริการภายในและภายนอกอยู่ห่างออกไปเพียงไม่กี่คลิก แอปของคุณสามารถเรียกใช้เบราว์เซอร์ บนเดสก์ท็อป หรืออุปกรณ์เคลื่อนที่
Power Automate	สร้างเวิร์กโฟลว์เพื่อทำให้กระบวนการที่ซับซ้อนเป็นไปโดยอัตโนมัติ รวมแหล่งข้อมูลและบริการภายในและภายนอกโดยใช้ตัวเชื่อมต่อในตัวและแบบกำหนดเอง ใช้ระบบอัตโนมัติของกระบวนการดิจิทัล (DPA) เมื่อแอปพลิเคชันมี Application Programming Interface (API) ใช้กระบวนการทำงานอัตโนมัติโดยหุ่นยนต์ (RPA) เพื่อทำงานซ้ำๆ ที่ดำเนินการในเบราว์เซอร์หรือแอปเดสก์ท็อปโดยอัตโนมัติ ทริกเกอร์โฟลว์ให้ทำงานเมื่อมีเหตุการณ์เกิดขึ้นในระบบและบริการอื่นๆ หรือจัดกำหนดการให้ทำงานในเวลาที่กำหนด
Copilot Studio	การสร้างเอเจนต์การสนทนาโดยใช้อินเทอร์เฟซแบบกราฟิกที่ไม่ต้องเขียนโค้ด คุณสามารถปรับใช้เอเจนต์กับหลายช่องทาง รวมถึงเว็บไซต์ แอปสำหรับอุปกรณ์เคลื่อนที่ และแพลตฟอร์มการส่งข้อความ เช่น Microsoft Teams การเขียนโดยใช้ความช่วยเหลือของ AI สามารถเร่งการสร้างหัวข้อได้ คำตอบที่สร้างอัตโนมัติสามารถค้นหาและแสดงข้อมูลจากแหล่งที่มาต่างๆ ได้โดยไม่ต้องสร้างหัวข้อ
Power BI	ลากแผนภูมิ ตาราง และภาพอื่นๆ ไปยังพื้นที่ทำงานเพื่อสร้างรายงานที่ซับซ้อน ซึ่งเปิดเผยข้อมูลเชิงลึกที่ถูกล็อกอยู่ภายในข้อมูลของคุณได้อย่างง่ายดาย รวมแมชชีนเลิร์นนิงอัตโนมัติสำหรับการสร้างโมเดลเชิงคาดการณ์และการแสดงข้อมูลภาพของ AI ด้วยแผนผังการแยกส่วนสำหรับการดูรายละเอียดแนวลึกการวิเคราะห์สาเหตุหลักโดยละเอียด สำรวจข้อมูลของคุณโดยถามคำถามด้วยภาษาธรรมชาติในรูปแบบถาม &ตอบอย่างง่าย
Power Pages	สร้างเว็บไซต์ที่น่าสนใจและขับเคลื่อนด้วยข้อมูลได้อย่างรวดเร็วบนแพลตฟอร์ม Software as a Service (SaaS) แบบเขียนโค้ดน้อยที่ปลอดภัยระดับองค์กร ด้วยเทมเพลตที่หลากหลายและปรับแต่งได้และประสบการณ์แบบภาพที่ลื่นไหล การสร้าง การโฮสต์ และการจัดการเว็บไซต์ธุรกิจที่เชื่อมต่อกับภายนอกที่ทันสมัยจึงง่ายขึ้น

ตระกูลผลิตภัณฑ์ Power Platform อาศัยความสามารถและแนวคิดสนับสนุนบางประการ ตารางต่อไปนี้อธิบายสิ่งที่สำคัญที่สุดที่ต้องเข้าใจ

แนวคิด	Description
Power Fx	Power Fx เป็นภาษาที่เขียนโค้ดน้อย แบบโอเพ่นซอร์ส ที่ได้รับแรงบันดาลใจจากสูตร Excel กำหนดชนิดที่ชัดเจน เป็นแบบประกาศ และมีฟังก์ชันด้วยตรรกะที่จำเป็นและการจัดการสถานะทั้งหมดแสดงเป็นข้อความที่ผู้ใช้เข้าใจง่าย Power Fx ทำให้งานการเขียนโปรแกรมทั่วไปเป็นเรื่องง่ายสำหรับนักพัฒนาพลเมืองและนักพัฒนามืออาชีพ สนับสนุนการพัฒนาเต็มรูปแบบจากไม่มีโค้ดสำหรับผู้ที่ไม่เคยตั้งโปรแกรมมาก่อนจนถึง "โค้ดระดับสูง" สำหรับมืออาชีพที่ช่ำชอง ซึ่งทำให้ทีมต่างๆ สามารถทำงานร่วมกันและประหยัดเวลาและค่าใช้จ่าย
ตัวเชื่อมต่อ	ตัวเชื่อมต่อมีความสำคัญต่อการอนุญาตให้การเขียนโค้ดน้อยและการเขียนโค้ดแบบดั้งเดิมทำงานร่วมกันเพื่อส่งมอบแอปที่ทันสมัย ตัวเชื่อมต่อเป็น wrapper รอบ API ที่อนุญาตให้ Power Apps และ Power Automate ใช้แหล่งข้อมูลและบริการภายในและภายนอก มีตัวเชื่อมต่อที่สร้างไว้ล่วงหน้ามากกว่าหนึ่งพันรายการ และคุณสามารถสร้างตัวเชื่อมต่อของคุณเองสำหรับ RESTful API ใดก็ได้ ข้อกำหนดของตัวเชื่อมต่อประกอบด้วยข้อมูลเมตาที่จำเป็นเพื่อทำให้ API ทำงานง่ายสำหรับแอปที่เขียนโค้ดน้อย
Dataverse	Dataverse เป็นที่เก็บข้อมูลไฮบริดระดับคลาวด์ที่สร้างขึ้นจากบริการการจัดการข้อมูล Azure แต่เป็นมากกว่าฐานข้อมูล เป็นแพลตฟอร์มข้อมูลพื้นฐานสำหรับทั้ง Dynamics 365 และ Power Platform ด้วยตรรกะฝั่งเซิร์ฟเวอร์ในรูปแบบของเวิร์กโฟลว์และปลั๊กอินกฎธุรกิจและโฟลว์กระบวนการ รูปแบบการรักษาความปลอดภัยที่มีความซับซ้อนสูงและแพลตฟอร์มการพัฒนาที่ขยายได้พร้อมการสนับสนุนในตัวสำหรับแอปหลายภาษาและหลายสกุลเงิน แอปพลิเคชันสามารถสร้างได้อย่างรวดเร็วจากโมเดลข้อมูล ทำให้เป็นหนึ่งในวิธีที่เร็วที่สุดในการปรับใช้โซลูชันข้อมูลผ่านฟอร์ม
AI Builder	AI Builder ทำให้ง่ายต่อการใช้ปัญญาประดิษฐ์ใน Power Apps และ Power Automate เพื่อค้นหาข้อมูลเชิงลึกในข้อมูลของคุณ ทำให้กระบวนการเป็นอัตโนมัติและทำให้แอปของคุณมีประสิทธิภาพมากขึ้น ด้วย AI Builder คุณไม่จำเป็นต้องมีทักษะการเขียนโปรแกรมหรือวิทยาศาสตร์ข้อมูลเพื่อเข้าถึงความสามารถของ AI โมเดลที่สร้างไว้ล่วงหน้าและปรับแต่งได้นั้นพร้อมสำหรับสถานการณ์ทางธุรกิจทั่วไปหลายอย่าง และคุณสามารถสร้างโมเดลของคุณเองเพื่อตอบสนองความต้องการทางธุรกิจที่เฉพาะเจาะจงได้
Copilot	ความช่วยเหลือจาก Copilot AI ทำให้ผู้ใช้และนักพัฒนาพลเมืองหรือมืออาชีพ Power Platform มีประสิทธิภาพมากขึ้น ช่วยให้พวกเขาใช้เวลามากขึ้นในส่วนที่ดีที่สุดของงานและใช้เวลาน้อยลงกับงานปกติ อธิบายสถานการณ์ทางธุรกิจของคุณให้กับ Copilot ใน Power Automate สามารถเปลี่ยนคำอธิบายของคุณให้เป็นเวิร์กโฟลว์อัตโนมัติได้ บอก Copilot ใน Power Apps ถึงสิ่งที่คุณต้องการทำหรือข้อมูลที่คุณต้องการดูและสามารถสร้างแอปให้ได้ Copilot ตั้งค่าการเชื่อมต่อ สร้างและเติมข้อมูลในตาราง สร้างหน้าจอ และแม้แต่เสนอคำแนะนำเพื่อทำให้โฟลว์หรือแอปของคุณดีขึ้น แอปของคุณจะมีประสบการณ์การใช้งานที่ขับเคลื่อนด้วย Copilot ในตัวตั้งแต่หน้าจอแรก เพื่อให้ผู้ใช้ค้นพบข้อมูลเชิงลึกผ่านการสนทนา
สภาพแวดล้อมและโซลูชัน	สภาพแวดล้อมคือขอบเขตที่มีและทำให้ง่ายต่อการจัดการและรักษาความปลอดภัยทรัพยากร Power Platform นอกจากนี้ ยังใช้ในการจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) ซึ่งทำให้โซลูชันได้รับการพัฒนาและทดสอบในสภาพแวดล้อมแยกต่างหากก่อนที่จะปรับใช้กับสภาพแวดล้อมการทำงานจริง โซลูชันคือการปรับแต่งและส่วนขยายแบบแพ็คเกจของ Power Platform โซลูชันอาจรวมถึงแอป โฟลว์ ตาราง แผนภูมิ แดชบอร์ด ตัวเชื่อมต่อ และส่วนประกอบอื่นๆ ที่การปรับแต่งหรือส่วนขยายต้องการ โซลูชันสามารถพัฒนา ทดสอบ และปรับใช้กับการทำงานจริงในสภาพแวดล้อมแยกต่างหากโดยเป็นส่วนหนึ่งของนโยบาย ALM ขององค์กร คุณสามารถส่งออกโซลูชันเพื่อแชร์กับผู้ใช้หรือองค์กรอื่น และนำเข้าโซลูชันจากผู้อื่นได้ โซลูชันเป็นแบบมีการจัดการหรือไม่มีการจัดการ โซลูชันที่ไม่มีการจัดการใช้สำหรับการพัฒนาและการทดสอบ โซลูชันที่มีการจัดการใช้สำหรับการปรับใช้งานและการกระจายสำหรับการทำงานจริง

ประโยชน์หลักของ Power Platform สำหรับการทำให้แอปทันสมัย

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

• ลดต้นทุน องค์กรต่างๆ สามารถประหยัดเงินในการพัฒนาและบำรุงรักษาแอปได้ การศึกษาที่ได้รับมอบหมาย โดย Forrester Consulting พบว่าองค์กรที่ใช้ Power Platform สามารถเห็นต้นทุนการพัฒนาแอปพลิเคชันลดลง 45 เปอร์เซ็นต์และรับรู้ผลตอบแทนจากการลงทุน 140%

• ขยายกลุ่มทรัพยากรและขจัดปัญหาคอขวด นักพัฒนามืออาชีพ นักวิทยาศาสตร์ข้อมูล และวิศวกร AI ได้รับค่าตอบแทนสูงและเป็นที่ต้องการสูง องค์กรขนาดเล็กถึงขนาดกลางมักไม่มีความเชี่ยวชาญด้านการเขียนโค้ดภายในองค์กรระดับสูง และการว่าจ้างบริษัทภายนอกก็มีราคาแพง Power Platform แบบเขียนโค้ดน้อยเข้าถึงได้ง่ายขึ้นด้วยกลุ่มทรัพยากรที่ใหญ่ขึ้น ผู้เชี่ยวชาญเฉพาะด้านและพนักงานที่มีความเชี่ยวชาญด้านกระบวนการทางธุรกิจสามารถช่วยเร่งความพยายามในการปรับปรุงให้ทันสมัย แม้ว่าพวกเขาจะไม่เคยเขียนโค้ดเลยก็ตาม

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

• ลดหนี้ทางเทคนิค ค่าใช้จ่าย ทั้งทางการเงินและโอกาสที่สูญเสียไปในการอัปเกรดโซลูชันซอฟต์แวร์ที่ "รวดเร็วและไม่ถูกต้อง" และการบำรุงรักษาโครงสร้างพื้นฐานแบบเดิมนั้นสูง Power Platform ลดหนี้ทางเทคนิคนี้โดยทำให้ง่ายขึ้นและถูกกว่าสำหรับการสร้างโซลูชันในครั้งแรก ลดความซับซ้อนของการรวมข้อมูลและการกำกับดูแลด้วย Common Data Model และตัวเชื่อมต่อจัดหาแพลตฟอร์มส่วนกลางสำหรับการจัดการโซลูชัน และสนับสนุนการปรับปรุงอย่างต่อเนื่องด้วยการวิเคราะห์และ AI

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

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

• รวมแอปแบบดั้งเดิม แอปพลิเคชันรุ่นเก่ามักไม่มี API ความสามารถด้าน RPA ของ Power Platform สามารถทำให้แอปแบบคลาสสิกเป็นแบบอัตโนมัติและรวมไว้ในกระบวนการทางธุรกิจที่ทันสมัยของคุณ RPA ยังมีประโยชน์ในการปรับปรุงแอปขนาดใหญ่และซับซ้อนให้ทันสมัยขึ้นเรื่อยๆ

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

• เพิ่มประสิทธิภาพการทำงานของพนักงานในสถานที่ทำงานที่ทันสมัย Power Platform เป็นส่วนหนึ่งของสถานที่ทำงานสมัยใหม่ของ Microsoft แอปพลิเคชันที่ได้รับการปรับปรุงให้ทันสมัยบนแพลตฟอร์มสามารถใช้ประโยชน์จากความสามารถของ Microsoft 365 รวมถึงประสบการณ์บนมือถือที่น่าสนใจและการทำงานร่วมกันที่สะดวกและใช้งานง่าย AI ที่ล้ำสมัย เช่น Copilot, AI Builder และคุณลักษณะที่จะประกาศเร็วๆ นี้ทำให้ผู้ใช้และนักพัฒนามีประสิทธิภาพมากขึ้นด้วยความยุ่งยากน้อยลงและช่วงการเรียนรู้ที่สั้นลง

นวัตกรรมสำหรับบุคลากรหน้างาน

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

ด้วยความร่วมมือกับ Microsoft American Airlines ได้สร้าง ConnectMe ซึ่งเป็นแอป Microsoft Teams ที่สร้างขึ้นบน Power Apps และ Azure การใช้แอปบนอุปกรณ์เคลื่อนที่ ทีมหน้าหน้ามีข้อมูลการมาถึงการขึ้นเครื่องสัมภาระและประตูขึ้นเครื่องที่สำคัญเพียงปลายนิ้วสัมผัสในแบบเรียลไทม์ ปรับปรุงการปฏิบัติงานภาคพื้นดิน เร่งเวลาไปกลับของเครื่องบิน และทำให้การเดินทางเป็นประสบการณ์ที่น่าพึงพอใจยิ่งขึ้นสำหรับลูกค้า เรียนรู้เพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงของสายการบิน

การเพิ่มขีดความสามารถของ AI สำหรับผู้ปฏิบัติงานด้านความรู้

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

การเดินทางสู่การปรับปรุงแอปรุ่นเก่าให้ทันสมัยกำลังเพิ่มขึ้น

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

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

ตัวเลือกสำหรับการปรับปรุงแอปให้ทันสมัย

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

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

การสิ้นสุดอายุการใช้งาน

การย้าย

การปรับปรุงให้ทันสมัย

เลิกใช้

Replace

โฮสต์ใหม่

ปรับโครงสร้างของโค้ดใหม่

การแก้ไขสถาปัตยกรรม

สร้างใหม่

รายละเอียด

เอาแอปออก

แทนที่แอปด้วย SaaS หรือแอปอื่น

ปรับใช้ใหม่ตามที่เป็นอยู่กับระบบคลาวด์

ปรับโค้ดที่มีอยู่ให้เหมาะสม

เปลี่ยนโค้ดเป็นสถาปัตยกรรมแอปพลิเคชันใหม่หรือแบ่งเป็นไมโครเซอร์วิส

เขียนแอปใหม่ตั้งแต่เริ่มต้นด้วยขอบเขตและข้อกำหนดดั้งเดิม

โปรแกรมควบคุม

ไม่จำเป็นอีกต่อไป

ลดรายจ่าย

ลดรายจ่ายฝ่ายทุน

ใช้ประโยชน์จากเทคโนโลยีที่ใหม่กว่า

ลดรายจ่ายฝ่ายทุน

กู้คืนพื้นที่เก็บข้อมูล

ผลตอบแทนจากการลงทุนในระบบคลาวด์อย่างรวดเร็ว

การอัปเดตที่รวดเร็วและสั้นลง

โค้ดที่เคลื่อนย้ายได้เพิ่มเติม

ประสิทธิภาพของระบบคลาวด์ที่มากขึ้นในด้านทรัพยากร ความเร็ว ต้นทุน

เพิ่มประสิทธิภาพ

ลดหนี้ทางเทคนิค

ปรับปรุงความสามารถในการปรับขนาด ความน่าเชื่อถือ และการบำรุงรักษา

นำความสามารถใหม่ๆ ของระบบคลาวด์ไปใช้ได้ง่าย

ผสมผสานเทคโนโลยี

เร่งเวลาสร้างสรรค์สิ่งใหม่

เร่งการพัฒนา

ลดค่าใช้จ่ายในการปฏิบัติงาน

เทคโนโลยีของ Microsoft

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

คอนเทนเนอร์

Azure PaaS

Power Platform

Azure PaaS

ไมโครเซอร์วิสแบบไร้เซิร์ฟเวอร์

Power Platform

Azure PaaS

ไมโครเซอร์วิสแบบไร้เซิร์ฟเวอร์

ตารางต่อไปนี้แนะนำวิธีที่แนวทางแบบเขียนโค้ดน้อยสามารถนำไปใช้กับตัวเลือกการปรับปรุงแอปให้ทันสมัยแต่ละตัวเลือก

ตัวเลือก	Description
โฮสต์ใหม่	การโฮสต์ใหม่จะย้ายแอปตามที่เป็นอยู่จากสภาพแวดล้อมที่เก่าไปยังสภาพแวดล้อมที่ใหม่กว่า วิธีการแบบเขียนโค้ดน้อยใช้ไม่ได้โดยตรง แต่การโฮสต์ใหม่อาจเป็นขั้นตอนแรกก่อนที่จะใช้กลยุทธ์อื่นๆ ที่จะรวมโซลูชันแบบเขียนโค้ดน้อย
ปรับโครงสร้างของโค้ดใหม่หรือออกแบบใหม่	การปรับโครงสร้างใหม่จะปรับแต่งโค้ดเพื่อให้แอปได้รับประโยชน์สูงสุดจากสภาพแวดล้อมที่เน้นระบบคลาวด์เป็นหลัก การออกแบบใหม่จะปรับเปลี่ยนโค้ดอย่างมาก ซึ่งอาจรวมถึงการห่อหุ้มตรรกะที่มีอยู่โดยย้ายไปยัง API ที่สามารถแสดงกับโซลูชันแบบเขียนโค้ดน้อยผ่านตัวเชื่อมต่อ
แทนที่หรือสร้างใหม่	การแทนที่จะสลับแอปด้วยแอปอื่น การสร้างใหม่จะสร้างแอปขึ้นมาใหม่ตั้งแต่ต้น ตัวเลือกนี้มักเป็นที่แนวทางแบบเขียนโค้ดน้อยบรรลุผลลัพธ์ทางธุรกิจที่ดีที่สุด เริ่มต้นด้วยแอปพลิเคชันจาก Dynamics 365 หรือ Microsoft AppSource สามารถช่วยเริ่มต้นการปรับปรุงให้ทันสมัยได้อย่างรวดเร็ว เมื่อกรณีการใช้งานตรงกับความสามารถที่สร้างไว้ล่วงหน้า จากนั้นองค์กรสามารถใช้ส่วนประกอบ Power Platform เพื่อปรับแต่งแอปตามความต้องการเฉพาะของตน

แนวทางแบบเขียนโค้ดน้อยของ Power Platform มีศักยภาพที่จะนำเสนอมากกว่าเครื่องมือพัฒนาอื่น การทำให้การเขียนโค้ดน้อยเป็นส่วนหนึ่งของกลยุทธ์แอปสมัยใหม่ของคุณยังสามารถสร้างรากฐานสำหรับการเพิ่มขีดความสามารถให้กับผู้ที่ไม่ใช่นักพัฒนา เช่น ผู้เชี่ยวชาญเฉพาะด้าน เพื่อมีส่วนร่วมในความพยายามในการปรับปรุงให้ทันสมัยของคุณ องค์กรต่างๆ พบว่าการจัดตั้ง Center of Excellence (CoE) และการใช้ Power Platform และเครื่องมือต่างๆ เช่น CoE Starter Kit เพื่อสร้างแนวทางและการกำกับดูแลช่วยให้ผู้ใช้สร้างแอปและระบบอัตโนมัติที่เขียนโค้ดน้อยได้สำเร็จ และรับประกันว่าสินทรัพย์ เช่น API และส่วนประกอบสามารถนำกลับมาใช้ใหม่ได้ การเขียนโค้ดน้อยสามารถเร่งการพัฒนาแอปพลิเคชันและช่วยให้องค์กรดึงคุณค่าจากข้อมูลของตนได้เร็วขึ้น ไม่ว่าจะอยู่ที่ใดก็ตาม ในความเป็นจริง หลายองค์กรตัดสินใจที่จะรวมความคิดแบบเขียนโค้ดน้อยเข้ากับวัฒนธรรมของตน

คู่มือการเดินทางสู่ความทันสมัยของคุณ

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

1. การวางแผน คิดอย่างรอบคอบเกี่ยวกับเป้าหมายของคุณในการปรับปรุงแอปพลิเคชันรุ่นเก่าให้ทันสมัย และกำหนดกลยุทธ์ของคุณในการเข้าถึงเป้าหมายเหล่านั้น มีความเข้าใจที่ชัดเจนเกี่ยวกับปัญหาที่คุณต้องการให้ความทันสมัยแก้ไข นี่เป็นเวลาที่จะประเมินแอปและสภาพแวดล้อมของคุณโดยพิจารณาจากสิ่งที่ไม่ได้ผล สิ่งที่ใช้ได้ผล แต่สามารถปรับปรุงได้ และที่สำคัญที่สุดคือ คุณค่าใดที่เป็นผลมาจากการเปลี่ยนแปลงใดๆ ต่อธุรกิจหรือผู้ใช้ ประเมินโอกาสในการปรับปรุงให้ทันสมัยแต่ละครั้งเพื่อหาศักยภาพในการใช้ประโยชน์จากแนวทางแบบเขียนโค้ดน้อย จัดลำดับความสำคัญของโอกาสที่รวมโซลูชันแบบเขียนโค้ดน้อยเข้าด้วยกัน ใช้ Cloud Adoption Strategy Evaluator เพื่อสร้างกรณีธุรกิจสำหรับการปรับปรุงแอปพลิเคชันให้ทันสมัย

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

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

ประเมินโอกาสสำหรับโซลูชันที่เขียนโค้ดน้อย

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

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

ตัวอย่างเช่น หากคุณพิจารณาว่าแอปพลิเคชันไม่เหมาะสมเนื่องจาก Power Apps ไม่มีตัวควบคุมที่จำเป็น คุณสามารถใช้ Power Apps component framework (PCF) และโค้ดดั้งเดิมเพื่อสร้างตัวควบคุมแบบกำหนดเองได้ อีกตัวอย่างหนึ่งคือ แอปที่มีตรรกะที่ซับซ้อน คุณสามารถรวมศูนย์ตรรกะใน API ที่ Power Apps สามารถเข้าถึงได้โดยใช้ตัวเชื่อมต่อที่กำหนดเอง ในทั้งสองตัวอย่างเหล่านี้ ความสามารถในการขยาย Power Platform ทำให้แอปส่วนใหญ่สร้างขึ้นด้วยส่วนประกอบแบบเขียนโค้ดน้อยซึ่งเชื่อมช่องว่างกับโค้ดที่พัฒนาขึ้นแบบดั้งเดิม

NSure.com แพลตฟอร์มซื้อประกันออนไลน์ที่เป็นกรรมสิทธิ์ นำเสนอตัวอย่างในโลกจริง การเปิดตัวครั้งแรกของบริษัทอาศัยบริการ Angular, Xamarin และ Azure ที่พัฒนาขึ้นแบบดั้งเดิม ด้วยการเพิ่ม Power Platform และ Dynamics 365, NSure.com ได้สร้างโซลูชันรุ่นใหม่โดยใช้ทั้งเทคนิคการเขียนโค้ดแบบเขียนโค้ดน้อยและแบบดั้งเดิม ดังที่แผนภาพต่อไปนี้แสดง เรียนรู้เพิ่มเติมเกี่ยวกับการเดินทางของบริษัท

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

สถานการณ์ส่วนหน้าที่ไม่เหมาะกับแนวทางแบบเขียนโค้ดน้อย

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

สถานการณ์แบ็คเอนด์ที่ไม่เหมาะกับแนวทางแบบเขียนโค้ดน้อย

สถานการณ์	ความท้าทาย
ข้อมูลความเร็วสูง	มักจะได้รับการสนับสนุนการนำเข้าข้อมูลหลายล้านแถวซึ่งเป็นส่วนหนึ่งของการย้ายข้อมูลและเหตุการณ์ที่คล้ายกัน อย่างไรก็ตาม เวิร์กโหลดที่เกี่ยวข้องกับการประมวลผลข้อมูลหลายล้านแถวเป็นรายชั่วโมงหรือรายวันควรได้รับการประเมินเพิ่มเติม ตัวอย่างเช่น การรวบรวมข้อมูลปริมาณมากของการวัดและส่งข้อมูลทางไกลจากอินเทอร์เน็ตในทุกสิ่ง (IoT) ลงใน Dataverse ไม่สมเหตุสมผล สามารถใช้บริการระบบคลาวด์ Azure เพื่อรวบรวมและวิเคราะห์ข้อมูลและสัญญาณที่เกี่ยวข้องที่เพิ่มเข้ามาใน Dataverse เพื่อทริกเกอร์การดำเนินการในแอปพลิเคชันแทน แอปพลิเคชันที่เกี่ยวข้องกับการอัปเดตข้อมูล Dataverse จำนวนมากเป็นประจำอาจต้องการความช่วยเหลือจากโค้ดแบบเดิมเพื่อปรับขนาดการอัปเดต
เวิร์กโหลดเบื้องหลังที่มีตรรกะที่ซับซ้อน	เวิร์กโหลดเบื้องหลังที่เกี่ยวข้องกับตรรกะที่ซับซ้อนหรือการเรียก API ปริมาณมากอาจไม่เหมาะสำหรับโซลูชันแบบเขียนโค้ดน้อย ตรรกะสามารถรวมศูนย์ใน API ที่โซลูชันแบบเขียนโค้ดน้อยสามารถเรียกได้
API ที่ใช้โปรโตคอลที่ไม่ใช่ RESTful	ตัวเชื่อมต่อ Power Platform รองรับเฉพาะ REST API หากคุณต้องการเชื่อมต่อกับ API ลักษณะอื่น เช่น SOAP หรือ gRPC ให้ระบุ REST API ของคุณเองที่สื่อสารกับลักษณะที่เข้ากันไม่ได้

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

จัดลำดับความสำคัญของโอกาสในการเขียนโค้ดน้อย

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

การจัดลำดับความสำคัญควรพิจารณาปัจจัยต่อไปนี้:

• การเติบโตของการเขียนโค้ดน้อยขององค์กรของคุณ
• ความซับซ้อนของโอกาส
• ROI สำหรับองค์กร ผู้ใช้ และไอที
• ระยะเวลาส่งมอบ

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

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

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

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

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

จัดระเบียบและเพิ่มทักษะให้กับทีมของคุณ

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

ทีมของทรัพยากรแบบเขียนโค้ดน้อยที่ทำงานร่วมกับทรัพยากรโค้ดแบบดั้งเดิมเรียกว่า ทีมฟิวชัน ทีมฟิวชันออกแบบมาเพื่อส่งเสริมการทำงานร่วมกันโดยการฝึกอบรมทรัพยากรทั้งสองประเภทเกี่ยวกับการผสานรวมโซลูชันแบบเขียนโค้ดน้อยเข้ากับโค้ดแบบเดิม สถาปนิกโซลูชันกำหนดวิธีการออกแบบโซลูชันระหว่างการเขียนโค้ดน้อยและโค้ดแบบดั้งเดิม

แม้ว่าการเริ่มต้นมอบหมายงานทั้งหมดให้กับนักพัฒนาแบบดั้งเดิมจะเป็นเรื่องง่าย แต่ความพยายามในการปรับปรุงให้ทันสมัยแบบเขียนโค้ดน้อยเป็นโอกาสที่ดีในการขยายทีมโครงการ ผู้ใช้ทางธุรกิจจำนวนมากสร้างทรัพยากรแบบเขียนโค้ดน้อยที่ยอดเยี่ยม พวกเขาสามารถเร่งการทำงานของทีมได้เพราะพวกเขาเข้าใจปัญหาทางธุรกิจแล้ว พวกเขาเพียงแค่ต้องเรียนรู้วิธีทำงานแบบเขียนโค้ดน้อยที่ทีมทำ และทำความคุ้นเคยกับขั้นตอนการทดสอบและ ALM ซึ่งอาจหมายถึงการเรียนรู้วิธีสร้างแอปใน Power Apps หรือเวิร์กโฟลว์ใน Power Automate พวกเขาควรเข้าใจด้วยว่าผู้เขียนโค้ดแบบดั้งเดิมสามารถพัฒนาอะไรได้บ้างเพื่อให้ความพยายามแบบเขียนโค้ดน้อยง่ายขึ้น ซึ่งไม่ได้หมายความว่าพวกเขาจำเป็นต้องรู้วิธีเขียนโค้ดแบบดั้งเดิม

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

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

รวบรวมข้อกำหนด

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

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

หลีกเลี่ยงการทำงานกับวิธีการแบบเขียนโค้ดน้อย

องค์กรที่ยังใหม่กับการปรับปรุงแอปพลิเคชันให้ทันสมัยด้วยโซลูชันแบบเขียนโค้ดน้อย มักจะทำผิดพลาดในการพัฒนาแบบเขียนโค้ดน้อยในลักษณะเดียวกับที่พวกเขาพัฒนาโค้ดแบบเดิม ตัวอย่างเช่น องค์กรอาจใช้มาตรฐาน UX ที่เขียนขึ้นสำหรับแอป Angular กับการใช้งาน Power Apps ครั้งแรก ทีมโครงการจะใช้เวลาที่ไม่จำเป็นในการพยายามปฏิบัติตามมาตรฐานที่ออกแบบมาสำหรับความสามารถของเฟรมเวิร์กเชิงมุมและไม่ใช่ความต้องการทางธุรกิจ

ทีมที่เคยทำงานกับโค้ดแบบเดิมอาจพยายามลดการเขียนโค้ดน้อยให้เหลือน้อยที่สุด ตัวอย่างเช่น แทนที่จะใช้ตัวควบคุม Power Apps ทีมสามารถสร้างแอปพลิเคชันจากตัวควบคุมของ Power Apps component framework เพื่อหลีกเลี่ยงการเขียนโค้ดน้อยให้มากที่สุด วิธีที่ดีที่สุดสำหรับทีมคือใช้การเขียนโค้ดน้อยให้ได้มากที่สุดจนกว่าพวกเขาจะเจอกับอุปสรรคที่ไม่สามารถแก้ไขได้ ทีมที่เรียนรู้วิธีใช้ประโยชน์จากความสามารถของแพลตฟอร์มจะประสบความสำเร็จมากขึ้นในการบรรลุประโยชน์สูงสุดจากการเขียนโค้ดน้อย การเขียนโค้ดน้อยยังคงมีความสามารถมากขึ้นในการรับสิ่งที่เคยเป็นไปได้ด้วยโค้ดแบบเดิมเท่านั้น ความท้าทายทั่วไปในอดีตคือการติดค้างเนื่องจากแนวทางแบบเขียนโค้ดน้อยไม่สามารถทำซ้ำฟังก์ชันที่จำเป็นบางอย่างได้ Power Platform จัดการกับความท้าทายนี้ด้วยตัวเลือกความสามารถในการขยายที่อนุญาตให้แอปพลิเคชันแบบเขียนโค้ดน้อยส่วนใหญ่รวมส่วนประกอบพิเศษที่เขียนด้วยโค้ดแบบเดิมเมื่อจำเป็น

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

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

ทำความเข้าใจโครงสร้างต้นทุนของแนวทางแบบเขียนโค้ดน้อย

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

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

ผลิตภัณฑ์ Power Platform ทั้งหมดมีราคาตามปริมาณที่มักใช้กับความพยายามในการปรับปรุงแอปพลิเคชันให้ทันสมัย และต้องได้รับการประเมินสำหรับกลยุทธ์เฉพาะของแต่ละองค์กร

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

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

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

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

สำรวจภายใน Power Platform

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

ภายใน Dataverse

Dataverse ขับเคลื่อนโดยบริการ Azure ที่มีการจัดการเต็มรูปแบบมากกว่า 25 รายการ เช่น Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory และ Microsoft Purview ความสามารถในตัว ได้แก่ การรักษาความปลอดภัยที่ครอบคลุมการวิเคราะห์ที่มีประสิทธิภาพ AI ตรรกะทางธุรกิจขั้นสูงและการจัดการเหตุการณ์การสร้างโมเดลข้อมูล และการรวมเข้ากับ Dynamics 365, Microsoft 365, Azure และอื่น ๆ ความสามารถทั้งหมดเหล่านี้สร้างขึ้นบนเลเยอร์การจัดเก็บข้อมูลหลายภาษาของ Dataverse ซึ่งใช้ Azure SQL DB (สำหรับข้อมูลเชิงสัมพันธ์), Azure Cosmos DB (สำหรับ NoSQL), Azure Blob Storage (สำหรับไฟล์) และ Azure Data Lake Storage รุ่น 2 (สำหรับการวิเคราะห์ขนาดใหญ่และการเก็บข้อมูลระยะยาว) ใช้ได้สำหรับการใช้งานที่โปร่งใสในส่วนประกอบแบบเขียนโค้ดน้อยของ Power Platform และผ่าน Dataverse REST API

ความพร้อมใช้งานสูงและความต่อเนื่องทางธุรกิจและการกอบกู้ระบบ (BCDR) มีความสำคัญสำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ Dataverse เพิ่มความพร้อมใช้งานสูงสุดด้วยบริการความน่าเชื่อถือ Azure การจำลองแบบของเซิร์ฟเวอร์หลักและเซิร์ฟเวอร์รองเป็นแบบซิงโครนัส โดยมีแฟบริกด้านล่างที่สามารถตรวจจับความล้มเหลวและเลือกเซิร์ฟเวอร์หลักใหม่ตามโปรโตคอลความถูกต้อง ความล้มเหลวด้านความพร้อมใช้งานสูง ซึ่งเกิดขึ้น ภายใน ภูมิภาค Azure นั้นราบรื่นและผู้ใช้ไม่ค่อยสังเกตเห็น เพราะมักเกิดขึ้นไม่กี่วินาที พวกเขารับประกันว่าการสูญหายของข้อมูลจะเป็นศูนย์ ไม่ว่าจะมีการวางแผนการหยุดทำงานหรือไม่ได้วางแผนไว้

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

นอกเหนือจากการใช้งานทางเทคนิคของความพร้อมใช้งานสูงและ BCDR แล้วทีมปฏิบัติการยังทดสอบความพร้อมในการตอบสนองต่อเหตุการณ์ประเภทต่างๆ อย่างสม่ำเสมอ

ภายใน Power Automate

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

ภายใน Power Apps

โปรแกรมรันไทม์ Power Apps สร้างขึ้นบนเฟรมเวิร์ก React แอปพลิเคชันสร้างขึ้นภายในตัวออกแบบ Power Apps ซึ่งใช้อินเทอร์เฟซแบบลากและวางเพื่อสร้างหน้าจอ สูตร Power Fx ใช้ตรรกะ ตัวเชื่อมต่อขยายการเข้าถึงของแอปไปยังบริการอื่นๆ และตรรกะและส่วนประกอบที่อนุญาตให้ใช้ส่วนขยายแบบภาพที่ใช้ซ้ำได้ นักพัฒนาสามารถใช้ Power Apps Component framework (PCF) เพื่อสร้างตัวควบคุมแบบกำหนดเองได้ แม้ว่าเฟรมเวิร์ก UI จำนวนมากสามารถใช้ควบคู่กับ PCF แต่คุณลักษณะ Power Apps มีการสนับสนุนภายในสำหรับ React

ภายในตัวเชื่อมต่อ

ตัวเชื่อมต่อใช้การจัดการ Azure API เพื่อจัดการข้อมูลประจำตัวและการเชื่อมต่อจากผู้ใช้แต่ละราย

สถาปัตยกรรมเดียวกันนี้ใช้สำหรับตัวเชื่อมต่อทั้งหมด รวมถึงตัวเชื่อมต่อแบบกำหนดเองที่คุณสร้างสำหรับ API ของคุณเอง การใช้การจัดการ Azure API ช่วยให้มั่นใจได้ถึงอินเทอร์เฟซที่สอดคล้องกันสำหรับผลิตภัณฑ์ Power Platform ต่างๆ เช่น Power Apps และ Power Automate ที่มีตัวเชื่อมต่อทั้งหมด

ข้อยกเว้นคือตัวเชื่อมต่อ Dataverse ซึ่งจะปรากฏในรายการตัวเชื่อมต่อสำหรับแอปและโฟลว์ แต่มีการใช้งานแตกต่างกัน เมื่อแอปหรือโฟลว์ใช้ข้อมูลหรือการดำเนินการ Dataverse การโต้ตอบจะเป็นแบบโดยตรงผ่าน OData API ของ Dataverse

ตัวเลือกความสามารถในการขยาย Power Platform

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

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

ตัวเลือก	Description
API และตัวเชื่อมต่อที่กำหนดเอง	ตัวเชื่อมต่อที่กำหนดเองสำหรับ REST API ของคุณรวมศูนย์ตรรกะของแอปและอนุญาตให้มีการแสดงส่วนประกอบแบบเขียนโค้ดน้อยด้วยวิธีที่ปลอดภัยและมีการควบคุม คุณสามารถใช้แนวทางนี้ในกลยุทธ์ที่เน้น API เป็นอันดับหลักสำหรับการปรับปรุงแอปพลิเคชันให้ทันสมัย ตัวเชื่อมต่อที่กำหนดเองใช้เอกสาร OpenAPI เพื่อกำหนดวิธีที่ส่วนประกอบแบบเขียนโค้ดน้อยสามารถโต้ตอบกับ REST API ตัวอย่างเช่น คุณสามารถสร้าง API โดยใช้ Azure Functions และเผยแพร่ไปยังการจัดการ Azure API การจัดการ Azure API สามารถส่งออกข้อกำหนด OpenAPI เพื่อสร้างตัวเชื่อมต่อที่กำหนดเองโดยอัตโนมัติสำหรับใช้ในโซลูชันแบบเขียนโค้ดน้อย วิธีการนี้จะแยกแอปพลิเคชันไคลเอ็นต์ออกจาก API ทำให้สามารถพัฒนาได้อย่างอิสระ API ได้รับการจัดการจากส่วนกลาง โดยเพิ่มชั้นความปลอดภัยที่ไม่เปิดเผย API โดยตรง และใช้เทคนิคการรับรองความถูกต้อง เช่น คีย์การสมัครใช้งาน โทเค็น ใบรับรองไคลเอ็นต์ และส่วนหัวที่กำหนดเอง
Power Apps Component framework	Power Apps Component framework เป็นเฟรมเวิร์กความสามารถในการขยายสำหรับการสร้างวิชวลแบบกำหนดเองสำหรับ Power Apps และ Power Pages ส่วนประกอบของโค้ดสร้างขึ้นโดยใช้ HTML, JavaScript หรือ TypeScript คิดว่าส่วนประกอบของโค้ดเป็นบล็อคส่วนประกอบ UI ที่สามารถนำกลับมาใช้ใหม่เพื่อสร้างแอปตั้งแต่หนึ่งแอปขึ้นไป ส่วนประกอบต่างๆ ประกอบด้วยรายการที่กำหนดว่าส่วนประกอบแบบเขียนโค้ดน้อยสามารถโต้ตอบกับส่วนประกอบของโค้ดได้อย่างไร อินเทอร์เฟซส่วนประกอบช่วยให้โปรแกรมรันไทม์ของการโฮสต์สามารถสื่อสารเหตุการณ์วงจรชีวิตของคอนเทนเนอร์การโฮสต์ได้ ซึ่งช่วยให้ส่วนประกอบของโค้ดสามารถแสดงภาพโดยใช้ข้อมูลบริบทที่ได้รับจากคอนเทนเนอร์การโฮสต์ สำหรับไอเดีย เรียกดูแกลเลอรีชุมชนที่ https://pcf.gallery
ตารางเสมือน	ตารางเสมือนช่วยให้รวมข้อมูลที่อยู่ในระบบภายนอกได้ง่ายขึ้น มีการแสดงข้อมูลจากภายนอกเป็นตารางใน Microsoft Dataverse ได้อย่างราบรื่นโดยไม่ต้องทำซ้ำข้อมูลและโดยไม่ต้องมีการเขียนโค้ดเฉพาะ Dataverse มาพร้อมกับตัวให้บริการข้อมูลสำหรับ OData v4 และ Azure Cosmos DB ตัวให้บริการตัวเชื่อมต่อเสมือนซึ่งอยู่ในรุ่นพรีวิวกำลังขยายตัวให้บริการข้อมูลที่มีอยู่เพื่อรวมชุดย่อยของตัวเชื่อมต่อ Power Platform รวมถึง SharePoint และ SQL Server สำหรับสถานการณ์ขั้นสูง นักพัฒนาสามารถสร้างตัวให้บริการข้อมูลแบบกำหนดเองได้ การสร้างตัวให้บริการข้อมูลแบบกำหนดเองจำเป็นต้องมีความรู้เชิงลึกเกี่ยวกับทั้งข้อมูลจากภายนอกและ Dataverse ความสามารถในการสร้างปลั๊กอิน Dataverse ที่ใช้ Power Fx สำหรับตรรกะอยู่ในระยะพรีวิว
ปลั๊กอิน Dataverse	ปลั๊กอิน Dataverse คือตัวจัดการเหตุการณ์แบบกำหนดเองที่ดำเนินการเพื่อตอบสนองต่อเหตุการณ์เฉพาะ ลองนึกถึงปลั๊กอิน เช่น กระบวนการที่เก็บไว้ในฐานข้อมูล แต่เขียนด้วย .NET ตัวอย่างเช่น เหตุการณ์จะถูกเริ่มต้นระหว่างการประมวลผลการดำเนินการข้อมูล Microsoft Dataverse หรือตามความต้องการสำหรับเหตุการณ์ API ที่กำหนดเอง ปลั๊กอินถูกนำไปใช้เป็นคลาสแบบกำหนดเองที่คอมไพล์เป็นแอสเซมบลี .NET Framework ที่สามารถอัปโหลดและลงทะเบียนกับ Dataverse เมื่อใช้อินเทอร์เฟซที่กำหนด ปลั๊กอินสามารถรับข้อมูลบริบทเกี่ยวกับเหตุการณ์ที่กำลังประมวลผลได้ ปลั๊กอินสามารถเรียกใช้เป็นส่วนหนึ่งของธุรกรรม Dataverse และสามารถดำเนินการข้อมูลอื่นๆ ที่เป็นส่วนหนึ่งของธุรกรรมปัจจุบันได้ ปลั๊กอินมีไว้สำหรับหน่วยงานขนาดเล็ก ประสิทธิภาพของปลั๊กอินต้องได้รับการปรับให้เหมาะสมเพื่อไม่ให้ส่งผลเสียต่อประสิทธิภาพโดยรวม ปลั๊กอินจะดำเนินการเสมอ โดยไม่คำนึงถึงการดำเนินการจากอินเทอร์เฟซผู้ใช้หรือ API ทำให้เป็นวิธีที่มีประสิทธิภาพในการบังคับใช้ตรรกะทางธุรกิจอย่างสม่ำเสมอ

การสำรวจสถานการณ์สถาปัตยกรรมการปรับปรุงให้ทันสมัยแบบเขียนโค้ดน้อย

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

ประสบการณ์การใช้งาน

การปรับปรุงประสบการณ์ผู้ใช้ให้ทันสมัยสามารถสร้างความแตกต่างอย่างมากให้กับผู้ใช้ Power Apps เป็นวิธีหลักในการสร้างประสบการณ์การใช้งานแอปพลิเคชันภายในกับ Power Platform คุณสามารถใช้ Power Pages สำหรับเว็บแอปพลิเคชันภายในได้ แต่เป็นเรื่องปกติสำหรับแอปพลิเคชันที่เชื่อมต่อกับภายนอก

Power Apps

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

ตารางต่อไปนี้อธิบายแอปสองประเภทที่คุณสามารถสร้างด้วย Power Apps ได้แก่ แอปพื้นที่ทำงานและแอปแบบจำลอง

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

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมพื้นฐานสำหรับแอปพื้นที่ทำงานหรือแอปแบบจำลอง ซึ่งแอปเชื่อมต่อโดยตรงกับแหล่งข้อมูล

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

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

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

Power Pages

แหล่งข้อมูลหลักสำหรับ Power Pages คือ Dataverse เมื่อคุณเพิ่มหน้าลงในเว็บไซต์ คุณจะจัดเก็บข้อกำหนดของหน้าไว้ใน Dataverse หน้าสามารถนำเสนอข้อมูล Dataverse และรวบรวมข้อมูลจากผู้ใช้เพื่อจัดเก็บในตาราง Dataverse

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

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

การจัดการข้อมูล

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

คุณมีตัวเลือกต่อไปนี้สำหรับสถาปัตยกรรมข้อมูลของแอปพลิเคชันที่ทันสมัย:

• ปล่อยให้ข้อมูลอยู่กับที่: ใช้ตัวเชื่อมต่อหรือ API ที่มีตัวเชื่อมต่อที่กำหนดเองเพื่อเข้าถึงข้อมูลที่มีอยู่ เมื่อข้อมูลอยู่ในองค์กร เกตเวย์ข้อมูลสามารถอำนวยความสะดวกในการเชื่อมต่อที่ปลอดภัย ใช้ตารางเสมือนเพื่อรวมข้อมูลจากภายนอกที่เข้ากันได้กับตาราง Dataverse

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

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

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

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

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

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

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

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

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

ข้อมูลจากภายนอกและ Dataverse

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

ตารางเสมือนถูกนำไปใช้โดยใช้สถาปัตยกรรมตัวให้บริการข้อมูล Dataverse ประกอบด้วยตัวให้บริการ OData ที่สามารถใช้กับบริการเว็บ OData v4 ตัวให้บริการข้อมูลตัวเชื่อมต่อเสมือนซึ่งกำลังอยู่ในรุ่นพรีวิว อนุญาตให้ใช้ตัวเชื่อมต่อ Power Platform แบบตารางเป็นตารางเสมือน

แผนภาพต่อไปนี้แสดงการใช้ตัวเชื่อมต่อเสมือน

นักพัฒนายังสามารถสร้างตัวให้บริการที่กำหนดเองสำหรับแหล่งข้อมูลภายนอกอื่นๆ อย่างไรก็ตาม พวกเขาต้องเข้าใจและใช้การแมปและการสนับสนุนการดำเนินงานทั้งหมดของ Dataverse

ข้อควรพิจารณาต่อไปนี้สามารถช่วยคุณประเมินการใช้ตารางเสมือนในโครงการปรับปรุงให้ทันสมัยของคุณ:

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

ไฟล์และรูปภาพ

เมื่อปรับปรุงแอปพลิเคชันที่ใช้ไฟล์และรูปภาพให้ทันสมัย สิ่งสำคัญคือต้องพิจารณาว่าโซลูชันใหม่จะจัดเก็บไว้ที่ใด Dataverse มีความสามารถพิเศษในการจัดเก็บไฟล์และรูปภาพ ทั้งสองอย่างสามารถเพิ่มลงในตารางเป็นคอลัมน์และจัดเก็บไว้ในที่เก็บข้อมูล Azure Blob ที่จัดการโดย Dataverse แอปสามารถทำงานกับตารางได้โดยใช้ตัวเชื่อมต่อ Dataverse โดยไม่จำเป็นต้องมีการรับรองความถูกต้องหรือ API แยกต่างหาก

การใช้ Dataverse สำหรับไฟล์และรูปภาพจะเหมาะสมเมื่อมีการเชื่อมต่อโดยตรงกับข้อมูล และผู้ใช้หลายคนไม่จำเป็นต้องทำงานร่วมกัน ตัวอย่างเช่น ภาพถ่ายของผลิตภัณฑ์หรือตำแหน่งที่ตั้ง หรือสำเนาสุดท้ายของสัญญาทางกฎหมาย อย่างไรก็ตาม หากผู้ใช้หลายคนจำเป็นต้องแก้ไขสัญญาทางกฎหมายพร้อมกัน การใช้ SharePoint จะให้ความสามารถในการทำงานร่วมกันมากขึ้น พิจารณาใช้ Azure Blob Storage โดยตรงหากคุณต้องการจัดการความปลอดภัยแยกต่างหากจาก Dataverse หรือหากคุณต้องการใช้คุณลักษณะเฉพาะไฟล์บางอย่าง

การรวมระบบ

การปรับปรุงแอปพลิเคชันให้ทันสมัยมักรวมถึงการผสานรวมกับระบบภายในหรือภายนอก การผสานรวมสามารถแบ่งประเภทกว้างๆ ออกเป็นข้อมูล แอปพลิเคชัน หรือกระบวนการ

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

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

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

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

ข้อควรพิจารณาต่อไปนี้สามารถช่วยคุณประเมินวิธีการนำการผสานรวมที่มีอยู่มาใช้:

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

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

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

ก่อนที่จะดำเนินการรวมแบบกำหนดเองใดๆ คุณควรประเมินความสามารถในการรวมในตัวลงใน Power Apps

• Microsoft Teams: แอปพื้นที่ทำงาน Power Apps และเอเจนต์ Copilot Studio สามารถฝังอยู่ในช่องทาง Teams ได้ เมื่อใช้ตัวเชื่อมต่อ Teams แอปและโฟลว์สามารถโพสต์และใช้ข้อความ Teams ได้อย่างง่ายดาย การ์ด Power Apps สามารถใช้เหมือนไมโครแอปเพื่อแชร์ข้อมูลที่ดำเนินการได้ในช่องทาง Teams

• SharePoint: แอปแบบจำลอง Power Apps สามารถกำหนดค่าให้เชื่อมต่อกับเอกสารที่เก็บไว้ในไลบรารี SharePoint เพื่อให้พร้อมใช้งานในแถว Dataverse ด้วย Microsoft Lists หรือรายการ SharePoint ผู้ใช้สามารถเรียกใช้โฟลว์ของ Power Automate ในบริบทของข้อมูลรายการได้

• Power BI: ข้อมูลเชิงลึก Power BI สามารถแสดงได้ในบริบทของแอปพื้นที่ทำงาน Power Apps คุณสามารถฝังแอปแบบจำลองในรายงาน Power BI เพื่อให้ผู้ใช้สามารถดำเนินการตามข้อมูลเชิงลึกได้โดยไม่ต้องออกจาก Power BI

การใช้ Dataverse เป็นที่เก็บข้อมูลหลักสำหรับแอปพลิเคชันที่ทันสมัยให้ความสามารถในตัวบางอย่างที่จะเป็นประโยชน์สำหรับการรวม

• API ที่กำหนดเองของ Dataverse สามารถใช้สำหรับการรวมระดับแอปพลิเคชันขาเข้า API ที่กำหนดเองมีการดำเนินการเฉพาะที่เกี่ยวข้องกับตรรกะของโค้ดที่กำหนดเองจำนวนเล็กน้อย ตัวอย่างเช่น ระบบที่ส่งสามารถใช้ API ที่กำหนดเองของ RequestNewProject และตรรกะที่เกี่ยวข้องจะรู้วิธีวางข้อมูลที่ได้รับลงในตาราง Dataverse ที่เหมาะสม ระบบที่ส่งจะถูกแยกออกจากโครงสร้างตาราง Dataverse

• การรวมขาออกสามารถทำได้โดยใช้ความสามารถในการเผยแพร่เหตุการณ์ของ Dataverse Dataverse สามารถกำหนดค่าให้เผยแพร่ไปยัง Azure Service Bus, Azure Event Hubs หรือตัวรับ Webhook ใดๆ ตัวอย่างเช่น เมื่อมีการสร้างแถวตารางโครงการ Dataverse ใหม่ แถวนั้นอาจถูกเผยแพร่ไปยังคิวของ Azure Service Bus คุณยังสามารถเผยแพร่เหตุการณ์เชิงแนวคิดเพิ่มเติมที่ตรงกับเหตุการณ์กระบวนการทางธุรกิจได้อีกด้วย ตัวอย่างเช่น คุณสามารถกำหนดและเผยแพร่เหตุการณ์เมื่อโครงการเสร็จสมบูรณ์

แผนภาพต่อไปนี้แสดงตัวอย่างของเหตุการณ์ขาเข้าและขาออกในสภาพแวดล้อม Dataverse

องค์กรควรพิจารณาตัวเลือกการรวมที่สร้างไว้ล่วงหน้าจากบุคคลที่สามใน Microsoft AppSource ตัวอย่างเช่น Microsoft มีโซลูชันที่สร้างไว้ล่วงหน้าสำหรับองค์กรที่ต้องการรวม SAP กับ Power Platform โซลูชันที่สร้างไว้ล่วงหน้านี้รวมแอปและโฟลว์ และเพิ่มฟังก์ชันการทำงานใหม่ที่อำนวยความสะดวกในการสื่อสารระหว่างระบบ SAP ขององค์กรของคุณกับ Power Platform

ตัวอย่างเช่น Ernst & Young ใช้การรวมระบบ SAP ที่สร้างไว้ล่วงหน้าเพื่อพัฒนาโซลูชันอย่างรวดเร็ว เพื่อเพิ่มประสิทธิภาพกระบวนการทางการเงินทั่วโลกที่มีความถี่สูง แผนภาพต่อไปนี้ของ โซลูชัน PowerPost ของบริษัท แสดงให้เห็นว่าผู้ใช้ด้านการเงินโพสต์เอกสารไปยังระบบ SAP ERP บัญชีแยกประเภททั่วไปโดยใช้ Power Platform

ตัวเลือกการเชื่อมต่อการผนวกรวม

เมื่อโซลูชันย้ายไปยังระบบคลาวด์ การเชื่อมต่อกลับไปยังทรัพยากรภายในองค์กรอาจมีความสำคัญในการสร้างความมั่นใจว่าการผนวกรวมยังคงทำงานร่วมกับแอปพลิเคชันที่ทันสมัยได้ แอปพลิเคชันเหล่านี้ต้องสามารถรวมเข้ากับทรัพยากรระบบคลาวด์แบบดั้งเดิมอื่นๆ ที่อาจอยู่ในสภาพแวดล้อมเครือข่ายที่แตกต่างกันได้ Power Platform รองรับสี่ตัวเลือกหลักสำหรับการเชื่อมต่อที่ปลอดภัย: เกตเวย์ข้อมูล เกตเวย์ข้อมูลเครือข่ายเสมือน ลิงก์ส่วนตัว และ ExpressRoute

• เกต์เวย์ข้อมูล อนุญาตให้ส่วนประกอบแบบเขียนโค้ดน้อยจาก Power Apps, Power Automate และ Power BI เพื่อเข้าถึงทรัพยากรภายในสถานที่เพื่อรองรับสถานการณ์การรวมแบบไฮบริด เกตเวย์เป็นวิธีที่รวดเร็วสำหรับแอปพลิเคชันแบบเขียนโค้ดน้อยที่ทันสมัยในการเข้าถึงแหล่งข้อมูลที่ยังคงอยู่ในองค์กร ด้วยเกตเวย์ คุณสามารถเชื่อมต่อกับข้อมูลภายในองค์กรจากแหล่งต่างๆ เช่น ระบบไฟล์ภายในเครื่อง, DB2, Oracle, SAP ERP, SQL Server และ SharePoint เกตเวย์เดียวสามารถรองรับผู้ใช้หลายคนและเข้าถึงหลายแหล่งได้ คุณยังสามารถกำหนดค่าเกตเวย์ข้อมูลเป็นคลัสเตอร์เพื่อให้มีความพร้อมใช้งานสูง

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

  

• เกตเวย์ข้อมูลเครือข่ายเสมือน อนุญาตให้กระแสข้อมูล Power BI และ Power Platform เพื่อเชื่อมต่อกับบริการข้อมูลในเครือข่ายเสมือน Azure โดยไม่ต้องใช้เกตเวย์ข้อมูลภายในองค์กรบนเครื่องเสมือนภายในเครือข่ายเสมือน

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

• Azure ExpressRoute มีวิธีขั้นสูงในการเชื่อมต่อเครือข่ายในสถานที่ของคุณกับบริการระบบคลาวด์ของ Microsoft โดยใช้การเชื่อมต่อส่วนตัว การเชื่อมต่อ ExpressRoute เดียวสามารถเข้าถึงบริการออนไลน์หลายรายการ เช่น Power Platform, Dynamics 365, Microsoft 365 และบริการระบบคลาวด์ Azure โดยไม่ต้องส่งผ่านอินเทอร์เน็ตสาธารณะ ExpressRoute ต้องการการวางแผนและการกำหนดค่าที่สำคัญและมีค่าใช้จ่ายมากขึ้นสำหรับบริการ ExpressRoute และผู้ให้บริการการเชื่อมต่อ

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

ตรรกะทางธุรกิจ

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

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

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

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

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

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

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

ใช้ API โค้ด

คุณสามารถใช้ API ในรันไทม์การโฮสต์ API ที่คุณชื่นชอบ เช่น Azure Functions, Azure Container Apps หรือบริการใดๆ ที่สามารถโฮสต์ REST API ได้ API ที่กำหนดเองเหล่านี้สามารถใช้ตรรกะใดก็ได้ และทั้งแอปพลิเคชันแบบเขียนโค้ดน้อยและโค้ดแบบดั้งเดิมก็สามารถใช้งานได้ API ที่กำหนดเองไม่ได้ให้การสนับสนุนธุรกรรมใดๆ นอกเหนือจากที่ API ที่พวกเขาใช้อาจมีให้ ตัวอย่างเช่น API ที่กำหนดเองสามารถใช้โครงสร้างธุรกรรม SQL Server หากใช้ SQL Server การปรับใช้งาน API โค้ดจะไม่อิงกับทรัพยากรแบบเขียนโค้ดน้อยที่อาจใช้ คุณสามารถใช้การจัดการ API Azure เพื่อควบคุมการใช้ API เหล่านี้และช่วยให้ค้นหาได้มากขึ้น

การรักษาความปลอดภัย

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

Power Platform ใช้วิธีการรักษาความปลอดภัยหลายชั้นที่คุณสามารถใช้เพื่อสร้างสถาปัตยกรรมความปลอดภัยของคุณ หลักการสำคัญของความสามารถเหล่านี้คือโซลูชันแบบเขียนโค้ดน้อยควรผสานรวมกับระบบรักษาความปลอดภัยที่มีอยู่ของคุณเพื่อลดผลกระทบจากการนำมาใช้

มาดูระดับสูงเกี่ยวกับการรักษาความปลอดภัยหลายชั้นประกอบกันเป็นรูปแบบความปลอดภัยของ Power Platform

• ผู้ใช้ที่ได้รับการรับรองความถูกต้องโดย Microsoft Entra ID และสามารถจำกัดการใช้งานได้โดยใช้นโยบายการเข้าถึงแบบมีเงื่อนไข
• การออกใบอนุญาตเป็นด่านควบคุมแรกที่อนุญาตให้เข้าถึงส่วนประกอบ Power Platform
• ความสามารถในการสร้างแอปพลิเคชันและเวิร์กโฟลว์ถูกควบคุมโดยบทบาทความปลอดภัยในบริบทของสภาพแวดล้อม
• ความสามารถของผู้ใช้ในการมองเห็นและใช้งานทรัพยากร Power Platform ถูกควบคุมโดยการแบ่งปันแอปพลิเคชันกับผู้ใช้ ทรัพยากรจะถูกแชร์โดยตรงกับผู้ใช้หรือกลุ่ม Entra ID
• สภาพแวดล้อมทำหน้าที่เป็นขอบเขตความปลอดภัยที่อนุญาตให้มีการรักษาความปลอดภัยที่แตกต่างกันในแต่ละสภาพแวดล้อม
• โฟลว์และแอปพื้นที่ทำงาน Power Automate ใช้ตัวเชื่อมต่อ ข้อมูลรับรองการเชื่อมต่อที่ระบุและสิทธิ์บริการที่เกี่ยวข้องจะกำหนดสิทธิ์เมื่อแอปใช้ตัวเชื่อมต่อ
• สภาพแวดล้อมที่มีอินสแตนซ์ Dataverse สนับสนุนโมเดลความปลอดภัยขั้นสูงขึ้นที่เฉพาะเจาะจงเพื่อควบคุมการเข้าถึงข้อมูลและบริการในอินซแตนช์ Dataverse นั้น
• การใช้ตัวเชื่อมต่อสามารถจำกัดเพิ่มเติมได้ด้วยนโยบายการป้องกันข้อมูลสูญหาย (DLP) ข้อจำกัดขาเข้าและขาออกข้ามผู้เช่ายังสามารถนำไปใช้กับตัวเชื่อมต่อได้

สิ่งสำคัญคือต้องทราบว่าเมื่อเข้าถึงแหล่งข้อมูลโดยใช้ตัวเชื่อมต่อ การรักษาความปลอดภัยพื้นฐานทั้งหมดที่แหล่งข้อมูล นำเสนอนั้นเพิ่มเติมจากเลเยอร์ความปลอดภัยที่อธิบายไว้ Power Apps และ Power Automate ไม่ให้ผู้ใช้สามารถเข้าถึงตัวเชื่อมต่อแหล่งข้อมูลที่พวกเขายังไม่มีโดยค่าเริ่มต้น ผู้ใช้ควรมีสิทธิ์เข้าถึงข้อมูลที่พวกเขาจำเป็นต้องเข้าถึงอย่างแท้จริง

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

ออกแบบโมเดลความปลอดภัยของคุณ

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

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

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

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

ปัญญาประดิษฐ์

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

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

Microsoft ได้แนะนำ Copilot ในผลิตภัณฑ์และบริการหลักเพื่อให้เข้าถึงเทคโนโลยี AI ขั้นสูงได้ง่ายขึ้น Copilot ใช้เทคนิค AI ที่ทันสมัยและโมเดลภาษาขนาดใหญ่ และผู้ใช้สามารถโต้ตอบด้วยในแอปพลิเคชันที่พวกเขาใช้ทุกวัน เช่น Microsoft 365 Windows, Dynamics 365 และ Power Platform

ขยายด้วยปลั๊กอิน

ผู้ใช้แอปพลิเคชันที่ขับเคลื่อนด้วย Copilot สามารถขอความช่วยเหลือจาก Copilot เกี่ยวกับงานทั่วไปในแอปพลิเคชันได้ คุณสามารถขยาย Copilot เพื่อรวมข้อมูลและงานที่พวกเขายังไม่รู้ และอยู่นอกเหนือขอบเขตของแอปที่ผู้ใช้ทำงานด้วยได้ Microsoft 365 Copilot สามารถรวมข้อมูล Power Platform ที่จัดเก็บไว้ใน Dataverse เพื่อให้ผู้ใช้ไม่ต้องสลับไปมาระหว่างแอปพลิเคชัน ตัวอย่างเช่น จาก Outlook ผู้ใช้สามารถขอให้ Copilot สร้างการอัปเดตสถานะสำหรับการตรวจสอบที่ล้มเหลวทั้งหมดที่เสร็จสมบูรณ์ในวันนี้ Microsoft 365 Copilot สืบทอดกรอบการทำงานความปลอดภัยและการกำกับดูแล Dataverse ดั้งเดิมโดยอัตโนมัติและใช้ความปลอดภัยและสิทธิ์ของผู้ใช้ในเวลาทำงาน

ตัวเชื่อมต่อเป็นปลั๊กอิน

ตัวเชื่อมต่อ Power Platform มีความสำคัญต่อประสบการณ์ Copilot เช่นกัน ตัวเชื่อมต่อสามารถเชื่อมต่อเป็นปลั๊กอินเพื่อขยายความสามารถของ Copilot ตัวอย่างเช่น Microsoft 365 Copilot ที่มี ตัวเชื่อมต่อ Power Platform สำหรับ Jira Software สามารถเปิดใช้งานตัวจัดการโครงการเพื่อขอสถานะของตั๋วการสนับสนุน Jira และดำเนินการตามคำตอบ เช่น การกำหนดเส้นทางเพื่อขออนุมัติเพิ่มเติม หรือเริ่มใบสั่งซื้อสำหรับฮาร์ดแวร์ใหม่ เมื่อใช้ปลั๊กอิน คุณสามารถรวมกระบวนการทางธุรกิจและข้อมูลของคุณกับ Copilot เพื่อให้ผู้ใช้สามารถโต้ตอบจากแอปใดก็ตามที่พวกเขาใช้

สร้าง Copilot ของคุณเอง

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

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

การจัดการวงจรชีวิตของแอปพลิเคชัน

ส่วนสำคัญของความพยายามในการปรับปรุงให้ทันสมัยคือ การสร้างกระบวนการจัดการวงจรชีวิตของแอปพลิเคชันที่เหมาะสม องค์กรมักต้องการให้การพัฒนาแอปพลิเคชันแบบเขียนโค้ดน้อยให้สอดคล้องกับวิธีการทำงานของ ALM โค้ดแบบดั้งเดิม Power Platform มีเครื่องมือ ALM เพื่อให้คุณสามารถรวมอาร์ทิแฟกต์แบบเขียนโค้ดน้อยในหรือควบคู่กับกระบวนการที่คุณใช้ตามปกติ

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

ไปป์ไลน์ Power Platform มีแนวทางแบบเขียนโค้ดน้อยในการทำให้การปรับใช้เป็นแบบอัตโนมัติ และใช้การรวมอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง (CI/CD) Power Platform จัดการกระบวนการเมื่อมีการกำหนดค่าไปป์ไลน์ ผู้ดูแลระบบสามารถจัดการและควบคุมไปป์ไลน์ได้จากส่วนกลาง

องค์กรยังสามารถใช้เครื่องมือ CI/CD ที่พวกเขาเลือกได้ Power Platform CLI เป็นเครื่องมือบรรทัดคำสั่งที่คุณสามารถใช้กับเครื่องมืออัตโนมัติ CI/CD ส่วนใหญ่ Power Platform Build Tools มีการดำเนินการสำหรับ GitHub และงานสำหรับ Azure DevOps ที่มีการดำเนินการทั่วไปทั้งหมดที่จำเป็นในการสร้างระบบอัตโนมัติ CI/CD ที่มีอาร์ทิแฟกต์แบบเขียนโค้ดน้อย

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

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

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

เมื่อแอปพลิเคชันที่ทันสมัยของคุณมีทรัพยากรที่เขียนโค้ดน้อยและโค้ดแบบดั้งเดิม คุณสามารถรวมไว้ในกระบวนการ CI/CD เดียวหรือจัดการแยกกันได้ ด้วยการจัดการที่เป็นอิสระ ทรัพยากรสามารถปรับใช้แยกกันได้ และทีมโครงการสามารถได้รับความคล่องตัวที่มากขึ้น ตัวอย่างเช่น API ที่แอปพลิเคชันแบบเขียนโค้ดน้อยใช้สามารถปรับใช้ได้อย่างอิสระหากทีมไม่แนะนำการเปลี่ยนแปลงที่ทำให้ระบบไม่ทำงาน

การตรวจสอบและข้อมูลเชิงลึก

แอปพลิเคชันที่ทันสมัยจำเป็นต้องรวมเข้ากับสภาพแวดล้อมการดำเนินงานที่ให้ความสามารถในการวินิจฉัยปัญหาในสภาพแวดล้อมต่างๆ ตั้งแต่การพัฒนาไปจนถึงการทำงานจริง Application Insights, ส่วนขยาย Azure Monitor รวบรวมการวัดและส่งข้อมูลทางไกลจาก Power Apps และ Dataverse ข้อมูลนี้ไม่เพียงแต่ช่วยในการระบุและแก้ไขปัญหา แต่ยังให้ข้อมูลเชิงลึกเกี่ยวกับสิ่งที่ผู้ใช้ทำในแอปพลิเคชันอีกด้วย คุณสามารถใช้ข้อมูลเชิงลึกเหล่านี้เพื่อช่วยปรับปรุงแอปและกระบวนการในแอปพลิเคชันที่ทันสมัยของคุณ

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

ผู้ดูแลระบบยังสามารถกำหนดค่าสภาพแวดล้อม Dataverse ที่จะส่งออกการวัดและส่งข้อมูลทางไกลไปยัง Application Insights ข้อมูลที่บันทึกไว้อาจรวมถึงการเรียก Dataverse API, การดำเนินการของปลั๊กอิน, การทำงานของ SDK และข้อยกเว้น นักพัฒนาที่สร้างตรรกะปลั๊กอินแบบกำหนดเองสามารถบันทึกข้อมูลการวัดและส่งข้อมูลทางไกลแบบกำหนดเองเพิ่มเติมไปยัง Application Insights ได้โดยตรง

การใช้ Application Insights ในแอปพลิเคชันของคุณจะช่วยให้เชื่อมโยงปัญหากับทรัพยากรหลายรายการได้ง่ายขึ้น เจ้าหน้าที่ฝ่ายปฏิบัติการสามารถสร้างการแจ้งเตือนใน Azure Monitor เพื่อทริกเกอร์เมื่อตรวจพบข้อยกเว้นจำนวนมาก การวิเคราะห์แอปพลิเคชันที่ทันสมัยของคุณเป็นประจำสามารถระบุแนวโน้มที่ต้องมีการตรวจสอบเพิ่มเติม

บทสรุป

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

แอปพลิเคชันรุ่นเก่านำเสนอความท้าทายมากมายสำหรับองค์กร องค์กรต่างๆ ต้องเริ่มดำเนินการริเริ่มการปรับปรุงแอปพลิเคชันให้ทันสมัยเพื่อฟื้นฟูโครงสร้างพื้นฐานและใช้ประโยชน์จากเทคโนโลยีที่ทันสมัย ในเอกสารนี้ คุณจะได้เห็นวิธีการใช้แนวทางแบบใช้โค้ดน้อยในความพยายามการปรับปรุงให้ทันสมัย โดยเฉพาะอย่างยิ่ง ความสามารถในการพัฒนาแบบใช้โค้ดน้อยของ Microsoft Power Platform ช่วยให้คุณสร้างและปรับใช้แอปพลิเคชันสมัยใหม่ได้อย่างรวดเร็วได้อย่างไร

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

เอกสารนี้กำหนดรากฐานให้กับคุณ ขั้นตอนต่อไปเป็นของคุณ นี่คือคำแนะนำบางอย่าง:

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

เส้นทางสู่การปรับปรุงแอปพลิเคชันให้ทันสมัยของทุกองค์กรต่างมีเอกลักษณ์เฉพาะตัว ทีมบัญชี Microsoft ของคุณหรือคู่ค้า Power Platform สามารถช่วยคุณวางแผนการเดินทางและพาคุณไปถูกทางตลอดการเดินทาง

แหล่งข้อมูล

• ผลกระทบทางเศรษฐกิจโดยรวมของ™ ของความสามารถของ Microsoft Power Platform Premium
• แอพ ConnectMe ของ American Airlines สร้างประสบการณ์การเดินทางที่ราบรื่นยิ่งขึ้นสำหรับลูกค้าและเครื่องมือเทคโนโลยีที่ดีขึ้นสำหรับสมาชิกในทีม
• ที่เก็บข้อมูลโอเพ่นซอร์ส Power Fx บน GitHub
• ชุดเริ่มต้น CoE
• การประเมินการใช้งาน Power Platform
• บริษัทตัวแทนประกันภัยดิจิทัลทำให้กระบวนการจัดซื้อที่ซับซ้อนเป็นไปโดยอัตโนมัติโดยใช้ Power Platform
• แกลเลอรี PCF
• EY ช่วยให้สามารถเข้าถึงแหล่งสำหรับกระบวนการทางการเงินระดับโลกได้ด้วย Power Platform ซึ่งช่วยลดเวลาที่ใช้ในกระบวนการทางการเงินลง 95 เปอร์เซ็นต์
• ลิงก์ส่วนตัว Azure
• Microsoft Azure ExpressRoute
• โปรแกรมวางแผนการเผยแพร่ Power Platform
• คู่มือการให้สิทธิการใช้งาน Microsoft Power Platform
• Microsoft สรุปเฟรมเวิร์กสำหรับการสร้างแอป AI และ Copilot; ขยายระบบนิเวศปลั๊กอิน AI