在當今快速發展的數位環境中，企業面臨著不斷更新其舊有應用程式以跟上不斷變化的業務需求的挑戰。 應用程式現代化對於提高營運效率、增強客戶體驗和保持競爭優勢至關重要。 Microsoft Power Platform 提供了一套全面的工具和技術，使企業能夠快速有效地轉變和現代化其應用程式。
本文探討使用 Microsoft Power Platform 將應用程式現代化的好處、策略和最佳做法。 它提供了深入解析和指導，說明 Microsoft 低程式碼平台如何協助您在組織數位轉型過程中成功現代化應用程式。
簡介
舊有應用程式為組織帶來許多挑戰。 這些應用程式通常建立在過時的技術堆疊和框架上，因此難以與現代系統和工具整合。 它們通常具有可擴展性和效能限制，從而阻礙了組織處理日益增加的工作量和客戶需求的能力。 傳統應用程式缺乏靈活性和敏捷性，限制了它們快速適應不斷變化的業務需求和市場動態的能力。 安全漏洞、高昂的維護成本、有限的整合能力以及對供應商的依賴風險進一步加劇了舊有應用程式的挑戰。 為了克服這些問題，組織需要更新其應用程式基礎結構以利用新技術。
Microsoft Power Platform 的低程式碼開發功能可讓您以更快速和更經濟的方式建立和部署現代應用程式。 輕鬆整合您現有的系統和資料來源，實現順暢的資料交換和協作。 新增 AI 來增強使用者體驗、自動化流程並從資料中獲得有價值的深入解析。 無論您是一位在邊緣進行修修補補的公民開發人員，還是一名致力於複雜定制的專業開發人員，您都可以直觀、快速地推動數位轉型，並且比傳統方法成本更低。
為什麼選擇 Power Platform？
構成 Power Platform 的綜合工具和技術大幅降低了現代化和數位轉型專案的時間、成本和開發要求。 它的低程式碼方法減少甚至消除了對昂貴的編碼、資料科學和 AI 工程資源的需求。 公民開發者和專業開發者同樣受益。 公民開發者可以積極參與現代化程序，直接根據他們的領域專業知識建立應用程式，並減少對 IT 團隊的依賴。 專業開發人員可以在更短的時間內提供更複雜的解決方案，從而更快地轉向下一個專案。
Power Platform 產品與概念
Power Platform 系列中的每個產品都有獨特的重點領域。 組織可以單獨或組合實作這些產品以滿足其特定要求。 這些產品相互關聯，無論如何組合，形成一個順暢的整體。
下表概述了每個 Power Platform 產品的高階概觀。
| Product | Description |
|---|---|
| Power Apps | 在直覺的拖放畫布中建立自訂應用程式。 透過一千多個連接器，只需點擊幾下即可獲得內部和外部資料來源和服務。 您的應用程式可以在瀏覽器、桌面或行動裝置上執行。 |
| Power Automate（自動化服務） | 建立工作流程來自動化甚至複雜的流程。 使用內建和自訂連接器整合內部和外部資料來源和服務。 當應用程式具有應用程式介面 (API) 時，使用數位流程自動化 (DPA)。 使用機器人流程自動化 (RPA) 自動執行在瀏覽器或桌面應用程式中執行的重複任務。 當其他系統和服務中發生事件時觸發工作流程執行或安排它們在特定時間執行。 |
| 副駕駛工作室 | 使用無程式碼圖形介面建立對話代理程式。 您可以將代理程式部署到多個管道，包括網站、行動應用程式和訊息傳遞平台 (如 Microsoft Teams)。 AI 輔助製作可以加快主題的建立。 生成式答案可以從多個來源尋找和呈現訊息，而無需建立主題。 |
| Power BI | 將圖表、資料表和其他視覺效果拖曳到畫布上，即可輕鬆建立複雜的報告，揭示資料中隱藏的深入解析。 包括用於預測建模的自動機器學習和帶有分解樹的 AI 視覺化，以便進行詳細的根本原因分析。 透過以簡單的問答形式提出自然語言問題來探索您的資料。 |
| Power 頁面 | 在安全、企業級、低程式碼的軟體即服務 (SaaS) 平台上快速建立有吸引力的資料驅動的網站。 借助豐富、可自訂的範本和流暢的視覺體驗，建立、託管和管理面向外部的現代商業網站變得更加容易。 |
Power Platform 產品系列依賴一些支援功能和概念。 下表介紹了需要理解的最重要的內容。
| 概念 | Description |
|---|---|
| Power Fx | Power Fx 是一種受 Excel 公式啟發的開放原始碼低程式碼語言。 Power Fx 具有強大類型、宣告性和功能性，具有命令式邏輯和狀態管理，全部以人性化的文字表達，使公民開發人員和專業開發人員都能輕鬆完成常見的程式設計任務。 它支援全方位的開發，從從未編程過的人的無程式碼到經驗豐富的專業人士的「專業程式碼」，使不同的團隊能夠協作並節省時間和費用。 |
| 連接器 | 連接器對於允許低程式碼和傳統編碼協同工作以提供現代應用程式至關重要。 連接器是 API 的包裝器，可讓 Power Apps 和 Power Automate 使用內部和外部資料來源和服務。 有超過一千個預先建置的連接器可供使用，您可以為任何 RESTful API 建立自己的連接器。 連接器定義包含必要的中繼資料，以使低程式碼應用程式可以輕鬆使用該 API。 |
| Dataverse | Dataverse 是一個以 Azure 資料管理服務為基礎建置的雲端規模混合式資料存放區，但它不僅僅是一個資料庫。 它是 Dynamics 365 和 Power Platform 的基礎資料平台，具有工作流程和外掛程式形式的伺服器端邏輯、商務規則和流程流程、高度複雜的安全性模型，以及具有內建支援的可擴展開發平台，適用於多語言和多貨幣應用程式。 可以從資料模型快速建立應用程式，使其成為部署表單資料解決方案的最快方法之一。 |
| 人工智慧產生器 | AI Builder 讓您可以輕鬆地在 Power Apps 和 Power Automate 中使用 AI 來從資料中尋找深入解析、實現流程自動化並提高應用程式的生產力。 有了 AI Builder，您無需編碼或資料科學技能即可獲得 AI 的強大功能。 預先建立的可自訂模型可用於許多常見的業務情境，並且您可以建立自己的模型來滿足特定的業務需求。 |
| Copilot | Copilot AI 的協助使 Power Platform 使用者和開發者 (無論是普通使用者還是專業人士) 更有效率，讓他們能夠將更多時間投入在工作中最有價值的部分，減少處理日常瑣事的時間。 向 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 透過以下方式減少技術負債：讓解決方案更容易且更便宜地第一次就構建成功，簡化了透過通用資料模型和連接器進行資料整合和治理，提供了一個集中式平台來管理解決方案，並透過分析和 AI 支援持續改進。
增強安全性並確保合規性。 所有 Power Platform 產品都包含完全整合的、開箱即用的企業級安全性、合規性和治理，從它們執行的環境開始。 受控環境是一套工具，可讓管理員大規模管理 Power Platform，並且控制力更強、工作量更少。 除其他功能外，您還可以限制誰可以共用哪些流程和應用程式以及與誰共用，並使用策略來限制製作者可以使用的連接器。 原生且靈活的資料安全性模型代表每個應用程式不必建立自己的模型。
隨時現代化。 您想要現代化的應用程式越重要，您就越不可能一次性將它們全部替換掉。 低程式碼方法非常適合以可管理的增量建置解決方案。
整合舊版應用程式。 較舊的應用程式通常沒有 API。 Power Platform 的 RPA 功能可以自動化傳統應用程式，並將其納入您的新現代商務程序中。 RPA 還可以幫助逐步現代化大型複雜應用程式。
無需花費更多即可進行創新。 Power Platform 功能不斷完善。 在該平台上建立的應用程式受益於 Microsoft 的創新，而您無需承擔更多成本。
提高現代工作場所的工作人員生產力。 Power Platform 是 Microsoft 現代工作場所的一部分。 在該平台上現代化的應用程式可以利用 Microsoft 365的功能，包括引人入勝的行動體驗和簡單直覺的協作。 Copilot、AI Builder 等尖端 AI 以及即將發佈的功能可讓使用者和開發人員提高工作效率，減少挫折感並降低學習曲線。
為第一線工作人員提供創新
第一線工作人員需要可以在任何裝置、任何工作地點使用的現代化應用程式。 他們需要即時獲取深入解析，以便更快做出更好的決策。 他們需要與同事和管理層合作以確保一切順利進行。 當美國航空決定對其運營的各個方面進行現代化改造時，他們獲得了所有這些，甚至更多。
American Airlines 與 Microsoft 合作建立了 ConnectMe，這是一個以 Power Apps 和 Azure 為基礎建構的 Microsoft Teams 應用程式。 透過在任何行動裝置上使用該應用程式，一線團隊可以即時掌握關鍵的到達、登機、行李和登機口資訊，從而簡化地面作業、加快飛機週轉時間，並為顧客帶來更愉快的旅行體驗。 了解有關該航空公司轉型的更多資訊。
AI 賦能知識型員工
知識工作者暢遊在資料的海洋中——但他們常常感覺自己快要溺斃了。 幾乎所有應用程式都會收集資料。 它們很少能幫助使用者理解所收集的資料，更不用說得出可能有助於員工更好地完成工作的深入解析了。 作為現代化的一部分， AI 功能可以新增到應用程式中，不僅可以自動收集和分析資料，還可以讓知識工作者更容易發現模式和趨勢。 預測分析可以使用 AI 模型根據歷史資料高精度地預測未來結果，讓領導者可以充滿信心地進行規劃。 現代化的應用程式可以包括副手 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 Marketplace 的應用程式開始，當使用情境與預建能力相符時，能幫助啟動現代化。 然後，組織可以使用 Power Platform 元件根據其獨特需求自訂應用程式。 |
Power Platform 的低程式碼方法有可能提供的不僅僅是另一種開發工具。 將低程式碼作為現代應用程式策略的一部分還可以為非開發人員 (如主題專家) 參與現代化工作奠定基礎。 組織發現，圍繞 Power Platform 建立卓越中心 (CoE) 並使用 CoE Starter Kit 等工具來建立指南和治理，有助於使用者成功建立低程式碼應用程式和自動化，並確保 API 和元件等資產可以重複使用。 低程式碼可以加速應用程式開發並幫助組織更快地從資料中提取價值，無論資料位於何處。 事實上，許多組織決定將低程式碼思維融入其文化。
現代化之旅指南
當您開始考慮對舊有應用程式進行現代化改造時，很容易感到不知所措。 導遊可以幫助您規劃旅程並確保您在旅途中走上正確的道路。 一個很好的起點是這三個步驟，並以低程式碼的思維考慮每個步驟。
規劃。 仔細考慮您對舊有應用程式進行現代化改造的目標，並制定實現這些目標的策略。 明確說明您希望透過現代化解決的問題。 現在是評估您的應用程式和環境的時候了，著眼於哪些地方不起作用，哪些地方起作用但可以改進，以及——最重要的是——任何變化能為企業或使用者帶來什麼價值。 評估每個現代化機會是否有可能利用低程式碼方法。 優先考慮採用低程式碼解決方案的機會。 使用雲端採用策略評估器來建立應用程式現代化的業務案例。
實作。 不僅要逐步地更新您的應用程式，還要迭代地更新。 迭代方法使組織能夠根據需要靈活地改變其專案範圍或策略。 Power Platform 低程式碼解決方案的開發和測試速度比傳統開發的應用程式更快，並且在受控環境中部署只需幾個步驟。 雖然低程式碼比傳統程式設計所需的技能更少，但請確保您的員工接受了適當的訓練，了解如何作為融合團隊工作，將低程式碼和傳統資源融合在一起。
營運. 應用程式現代化並不止於實作。 透過低程式碼、雲端優先方法，您可以使用雲端平台服務和工具來保護、治理、管理和最佳化您的應用程式。
評估低程式碼解決方案的機會
組織使用各種方法，從非正式審查到詳細的決策樹，來確定低程式碼方法是否是現代化舊有應用程式的正確方法。 需要考慮的最重要的事情是低程式碼並不是一個全有或全無的決定。 使用 Power Platform 元件建立應用程式的一部分，另一部分則使用傳統編碼技術開發的元件來開發，這是很常見的做法。
在評估應用程式時，建議您先確定它是否仍然需要和有用，或者應該淘汰。 如果您認為仍然需要，請評估低程式碼解決方案是否可以取代整個應用程式。 如果整個應用程式不適合用低程式碼替換，請評估應用程式的某些工作負載或元件是否可能適合低代碼解決方案。 您可能會發現，將低程式碼解決方案與傳統開發的程式碼結合，能夠提供兩者的最佳優勢。
例如，如果您確定某個應用程式不適合，因為 Power Apps 缺少所需的控制項，則可以使用 Power Apps Component Framework (PCF) 和傳統程式碼來建立自訂控制項。 另一個例子是具有複雜邏輯的應用程式。 您可以將邏輯集中於一個 API，並透過自訂連接器讓 Power Apps 存取該 API。 在這兩個例子中，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 中，讓低程式碼解決方案進型呼叫。 |
| 使用非 RESTful 通訊協定的 API | Power Platform 連接器僅支援 REST API。 如果您需要連接到另一種風格的 API (如 SOAP 或 gRPC)，請提供自己的 REST API 來與不相容的 API 進行通訊。 |
持續關注 Power Platform 的版本更新，因為這些更新將不斷縮小低程式碼解決方案能夠實現的功能差距。 建立低程式碼概念驗證是確定您的情境是否適合的好方法。
優先考慮低程式碼機會
當您評估應用程式組合時，僅僅確定適合低程式碼轉換的優秀候選者是不夠的。 您的團隊必須優先考慮這些因素，以最大限度地提高現代化工作的成功率。
在決定優先順序時應考慮以下因素：
- 貴組織的低程式碼成熟度
- 機會的複雜性
- 組織、使用者和 IT 的投資報酬率
- 價值實現時間
對貴組織的低程式碼能力有現實的認識可以幫助您選擇一個挑戰您的團隊成長但不會讓他們失敗的機會。 您不必選擇最簡單、沒有任何挑戰的應用程式。 理想的做法是提供一些機會來探索如何將傳統程式碼與低程式碼解決方案結合。
與其他系統整合複雜的應用程式通常不是最好的起點。 嘗試解決太大或太複雜的應用程式可能會導致挫折和失敗。 避免任何可疑的低程式碼候選者。 在您的團隊完成一些成功的現代化之後再儲存它們。
在對大型單片應用程式進行現代化改造時，請考慮是否可以逐步對其小部分進行現代化改造。 單片應用程式曾經很常見。 現在，小型的以角色或任務為中心的應用程式更為常見。 它們允許建立它們的團隊進行增量開發、增強和擴展。
最初幾次現代化改造非常重要，因為它們讓組織看到了低程式碼解決方案的影響。 在確定機會的優先順序時，評估應用程式利害關係人的利益和風險非常重要。 選擇沒有人關心或對組織影響較小的應用程式並不能最好地展示低程式碼解決方案的優勢。
使用者採用現代化的應用程式非常重要。 使用者需要感覺到他們的新低程式碼應用程式與他們使用的其他應用程式相適應。 採用的另一個風險是他們習慣的客製化程度。 如果他們期望獲得高度客製化的體驗，他們可能不太願意採用感覺不太個人化的低程式碼解決方案。
組織和提升您的團隊
成功現代化舊有應用程式的組織不會僅僅將現代化專案分配給傳統程式碼開發人員團隊並希望他們成功。 讓您的團隊掌握成功完成現代化工作所需的低程式碼開發知識和信心非常重要。
與傳統程式碼資源一起工作的低程式碼資源團隊稱為融合團隊。 融合團隊旨在透過訓練兩種類型的資源將低程式碼解決方案與傳統程式碼結合來促進協作。 解決方案架構師確定如何在低程式碼和傳統程式碼之間建立解決方案。
雖然很容易預設將所有工作分配給傳統開發人員，但低程式碼現代化工作是擴大專案團隊的好機會。 許多商業使用者製作了優秀的低程式碼資源。 他們可以加速團隊的工作，因為他們已經了解業務問題。 他們只需要學習如何完成團隊承擔的低程式碼工作類型，並熟悉測試和 ALM 程式。 這可能代表學習如何在 Power Apps 中建立應用程式，或在 Power Automate 中建立工作流程。 他們還應該了解傳統程式設計師可以開發什麼來讓他們的低程式碼工作變得更容易。 這並不代表他們需要知道如何編寫傳統程式碼。
傳統程式碼資源需要對低程式碼方法有基本的了解，並了解這些方法與他們通常編寫的程式碼有何不同。 最重要的是，他們需要學習低程式碼解決方案的可擴展性選項。 他們應該能夠輕鬆地建立使用自己編寫的程式碼的測試應用程式或流程，以確保其正常執行，並準備好支援低程式碼資源使用其可擴展性資產。
低程式碼和傳統程式碼資源都需要了解低程式碼和傳統程式碼解決方案的起點和終點以及它們的相交之處。
收集需求
您可能會發現您擁有的應用程式已有十年甚至更久的歷史，但卻沒有記錄。 它們可能需要逆向工程或商業使用者知識來重新建立。 重要的是要記住，雖然低程式碼方法很有效，但它並不能更快地收集需求和商務程序知識，也不能使複雜的需求變得不那麼複雜。 人們通常對對應用程式進行現代化改造的團隊抱有不切實際的期望，認為他們能與使用低程式碼建立新應用程式的團隊完成同樣多的工作。 建立組織的期望時要考慮這些挑戰。
有兩種方法可以幫助加速獲取有關舊有應用程式的知識。 首先，擴大團隊，吸收具有領域知識的業務使用者。 其次，著重了解商務程序及其預期結果，而不是記錄它在舊有系統中的實作方式。 例外情況是，如果舊有應用程式需要執行您必須遵循的商務規則的專門邏輯。
避免違反低程式碼方法
剛開始使用低程式碼解決方案對應用程式進行現代化改造的組織經常會犯這樣的錯誤：以開發傳統程式碼的方式開發低程式碼。 例如，組織可能會將為 Angular 應用程式編寫的 UX 標準套用於其第一個 Power Apps 實作。 專案團隊會花費不必要的時間來嘗試滿足為 Angular 框架功能而不是業務需求而設計的標準。
習慣使用傳統程式碼的團隊可能會嘗試盡量減少低程式碼。 例如，團隊可以不使用 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 由 25 多種完全受控的 Azure 服務提供支援，例如 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 儲存體 (用於檔案) Azure Data Lake Storage Gen 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 資料或動作時，可以透過 Dataverse 的 OData API 直接進行互動。
Power Platform 擴充選項
可擴充性是 Microsoft Power Platform 有別於其他低程式碼平台的關鍵特性。 該平台的指導原則是「沒有懸崖」——即使需要傳統程式碼，也不應該讓您在使用低代碼時遇到阻礙。 如果有必要，您可以使用傳統程式碼將整個工作負載作為更大應用程式的一部分進行建置。 但是，該平台提供了許多可擴展選項，允許在相同的工作負載中同時使用低程式碼和傳統程式碼。
下表提供了一些常見擴充選項的進階概述。 稍後當我們討論如何現代化以及您可以應用的模式時，我們會再次提到其中一些選項。
| 選項 | Description |
|---|---|
| API 和自訂連接器 | REST API 的自訂連接器集中了應用程式邏輯，並允許以安全且受管控的方式將其暴露給低程式碼元件。 您可以在 API 優先策略中使用此方法實現應用程式現代化。 自訂連接器使用 OpenAPI 文件來定義低程式碼元件如何與 REST API 互動。 例如，您可以使用 Azure Functions 建立 API 並將其發佈到 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 有深入的了解。 使用 Power Fx 為邏輯建立 Dataverse 外掛程式的功能目前處於預覽階段。 |
| Dataverse 外掛程式 | Dataverse 外掛程式是回應特定事件而執行的自訂事件處理常式。 可以將外掛程式想像成資料庫引擎中的預存程序，但是用.NET 寫的。 例如，在處理 Microsoft Dataverse 資料作業期間或根據自訂 API 事件的需求引發事件。 該外掛程式以自訂類別實作，編譯成.NET 框架程式集，可以上傳並註冊到 Dataverse。 使用定義的接口，外掛程式可以獲取有關正在處理的事件的上下文資訊。 外掛程式可以作為 Dataverse 交易的一部分執行，並且可以執行目前交易中的其他資料作業。 外掛程式適用於小型工作單元。 必須最佳化它們的效能，以免對整體效能產生負面影響。 無論使用者介面或 API 的作業如何，外掛程式始終都會執行，這使得它們成為一致執行業務邏輯的強大方法。 |
探索低程式碼現代化架構情境
與大多數平台一樣，您可以使用 Power Platform 元件和其他 Microsoft 雲端服務組成無數的架構情境。 在本文的這一部分中，我們將探討一些更常見的情境，並討論在使用它們時應該牢記的一些注意事項。
應用程式體驗
現代化的使用者體驗可以帶給使用者很大的不同。 Power Apps 是使用 Power Platform 建立內部應用程式體驗的主要方式。 您可以將 Power Pages 用於內部 Web 應用程式，但它更常用於面向外部的應用程式。
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 V4 Web 服務一起使用的 OData 提供者。 目前處於預覽階段的虛擬連接器資料提供者，允許將表格式 Power Platform 連接器作為虛擬表格使用。
下圖說明了虛擬連接器的使用。
開發人員還可以為其他外部資料來源建立自訂提供者。 但是，他們必須了解並實作所有 Dataverse 對應和作業支援。
以下注意事項可以幫助您評估現代化專案中虛擬表格的使用情況：
- 所有外部資料來源都必須有主索引鍵，且資料提供者必須將其作為 GUID 呈現給 Dataverse。 如果填充值穩定且唯一，則可以使用填充來容納非 GUID 鍵。
- 資料安全是在虛擬表格層級設定的。 行級和列級安全性不可用。
- 虛擬表格的效能取決於資料提供者、外部資料來源 API 以及與資料來源的連接性。 在大多數情況下，虛擬表格存取比本機 Dataverse 表存取慢。
- 虛擬表格不提供某些 Dataverse 功能 (例如搜尋、稽核、圖表和儀表板以及離線存取)。
- 使用虛擬表格來參考資料可能會降低同步性。
文件和影像
在對使用文件和影像的應用程式進行現代化改造時，重要的是考慮新的解決方案將它們儲存在何處。 Dataverse 具有儲存檔案和影像的專門功能。 兩者都可以作為列新增到表中，並儲存在由 Dataverse 管理的 Azure Blob 儲存體中。 應用程式可以使用 Dataverse 連接器與它們協作，無需單獨的驗證或 API。
當檔案和影像與資料直接連接且不需要多個使用者協作時，就適合使用 Dataverse；例如，產品或地點的照片或法律合約的最終副本。 但是，如果多個使用者需要同時修改法律合同，使用 SharePoint 將提供更強的協作能力。 如果您需要與 Dataverse 分開管理安全性，或需要使用某些特定於檔案的功能，請考慮直接使用 Azure Blob 儲存體。
整合
應用程式的現代化通常包括與內部或外部系統的整合。 整合可以大致分為資料、應用程式或流程。
資料整合會將來自不同來源的資料結合在一起，為使用者提供整合的檢視。 它提供了一種解耦的方法，但不允許即時建立邏輯或流程。 由於所有資料都是本機的，因此效能可以更好。
應用程式整合連線在應用程式層，通常透過 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 作為現代化應用程式的主要資料存放庫提供了一些有助於整合的內建功能。
Dataverse 自訂 API 可用於入站應用程式級整合。 自訂 API 提供了與少量自訂程式碼邏輯相關的獨特作業。 例如，發送系統可以使用
RequestNewProject自訂 API，並且相關邏輯將知道如何將接收到的資料放入適當的 Dataverse 表中。 發送系統將從 Dataverse 表結構中抽象化。可以使用 Dataverse 的發佈事件功能完成出站整合。 Dataverse 可以設定為發佈到 Azure 服務總線、Azure 事件中心或任何 Webhook 接收器。 例如，當建立新的 Dataverse 專案表資料列時，可以將其發佈到 Azure 服務匯流排佇列。 您也可以發佈更多與商務程序事件相符的概念事件。 例如，您可以定義專案完成時的事件並發佈。
下圖說明了 Dataverse 環境中入站和出站事件的範例。
組織也應考慮在 Microsoft Marketplace 上由第三方提供的預建整合選項。 例如，Microsoft 為需要將 SAP 與 Power Platform 整合的組織提供了預先建置的解決方案。 此預先建置的解決方案整合了應用程式和流程，並新增了新功能，以促進您組織的 SAP 系統和 Power Platform 之間的通訊。
例如，安永 (Ernst &Young) 使用預先建置的 SAP 整合快速開發解決方案來最佳化高頻率的全球財務流程。 下圖是該公司的 PowerPost 解決方案，展示了財務使用者如何使用 Power Platform 將文件發佈到其總帳 SAP ERP 系統。
整合連線選項
隨著解決方案轉移到雲端，重新連接到內部部署資源對於確保整合仍然與現代化應用程式相容至關重要。 這些應用程式還必須能夠與可能位於不同網路環境中的其他傳統雲端資源整合。 Power Platform 支援四種主要的安全連線選項：資料閘道、虛擬網路資料閘道、私人連結和 ExpressRoute。
資料閘道允許 Power Apps、Power Automate 和 Power BI 的低程式碼元件返回到內部部署資源，以支援混合整合情境。 閘道為現代化的低程式碼應用程式提供了一種快速存取仍在內部部署的資料來源的方法。 透過閘道，您可以連線到來自本機檔案系統、DB2、Oracle、SAP ERP、SQL Server 和 SharePoint 等來源的內部部署資料。 一個閘道可以支援多個使用者和存取多個來源。 您也可以將資料閘道設定為叢集以提供高可用性。
閘道支援整合到連接器的連接過程中，允許指示何時需要閘道，然後選擇設定的閘道。 設定連接後，應用程式和流程可以像沒有閘道一樣使用連接器。
虛擬網路資料閘道允許 Power BI 和 Power Platform 資料流程連接到 Azure 虛擬網路中的資料服務，而無需虛擬網路內的虛擬機器上的內部部署資料閘道。
Azure Private Link 和 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 資料變更都是交易性的，並且要么全部完成，要么全部復原。 外掛程式邏輯必須簡短、高效，不要試圖實作長時間執行的工作。 有時，如果您必須監聽多個表上的事件才能完成單一業務事件 (例如「關閉檢查」)，那麼事件外掛程式並不是最好的方法。 例如，您可以考慮使用 Dataverse 自訂 API，而不是在多個表上安裝外掛程式。 外掛程式可以執行使用者通常沒有的提升權限的邏輯。 這種方法還可以最大限度地減少應用程式使用者可能需要的權限。 外掛程式可以與應用程式和流程一起部署在 Dataverse 解決方案中。
在 Dataverse 自訂 API 中：Dataverse 自訂 API 可讓您實作自己的可執行邏輯的自訂 API 訊息。 例如，您可以建立一個「關閉檢查」自訂 API，呼叫它來完成檢查和關閉檢查的所有工作。 它不是事件驅動的，而是由需要它的應用程式和流程依需要使用。 與事件驅動的外掛程式一樣，自訂 API 外掛程式中完成的資料變更是交易性的。 當自訂 API 使用的唯一服務是用於其他資料工作的 Dataverse API 時，它是最好的。 自訂 API 的外掛程式可以與應用程式和流程一起部署在 Dataverse 解決方案中。
實作程式碼 API
您可以在自己最喜歡的 API 託管執行階段中實作 API，例如 Azure Functions、Azure 容器應用程式或任何能夠託管 REST API 的服務。 這些自訂API可以實作任何邏輯，低程式碼和傳統程式碼應用程式都可以使用它們。 自訂 API 不提供除其使用的 API 可能提供的交易支援之外的任何交易支援。 例如，如果自訂 API 使用 SQL Server，則它可以使用 SQL Server 交易建構。 程式碼 API 的部署將獨立於可能使用它的低程式碼資源。 您可以使用 Azure API 管理來管理這些 API 的使用並協助使它們更容易發現。
安全性
安全性 (包括驗證和授權) 是現代化應用程式結構的重要組成部分。 現代應用程式的安全性通常比傳統應用程式更具挑戰性。 它們包含多種雲端服務，使用者可以從更多不同的位置使用它們。 從概念上講，平台的安全性是為了確保使用者能夠以最少的摩擦完成他們需要做的工作，同時保護資料和服務。
Power Platform 採用多層安全方法，您可以使用它來建立您的安全架構。 這些功能的核心原則是，低程式碼解決方案應該與您現有的安全裝置整合，以最大限度地減少引入它們的影響。
讓我們從高層來看一下構成 Power Platform 安全性模型的多層安全性。
- 使用者透過 Microsoft Entra ID 進行驗證，並且可以使用條件式存取原則限制使用。
- 授權是第一個允許存取 Power Platform 元件的控制門。
- 建立應用程式和工作流程的能力由環境中的資訊安全角色控制。
- 透過與使用者共用應用程式來控制使用者查看和使用 Power Platform 資源的能力。 資源直接與使用者或Entra ID群組共用。
- 環境充當安全邊界，允許在每個環境中實作不同的安全需求。
- Power Automate 流程和畫布應用程式使用連接器。 特定的連接憑證和相關的服務權利決定了應用程式使用連接器時的權限。
- 具有 Dataverse 執行個體的環境支援更進階的安全性模型，這些模型專門用於控制對該 Dataverse 執行個體中的資料和服務的存取。
- 連接器的使用可以透過資料原則進一步限制。 跨租用戶入站和出站限制也可以套用到連接器。
值得注意的是，當使用連接器存取資料來源時，資料來源提供的所有底層安全性都是對所述安全層的補充。 Power Apps 和 Power Automate 預設不會提供使用者尚未擁有的連接器資料來源的存取權限。 使用者只能存取他們真正需要存取的資料。
當您使用 Dataverse 作為解決方案的一部分時，它包含一個可適應多種業務情境的角色型安全性模型。 資料可以安全地儲存至資料行中的單一資料列。 使用者被指派一個或多個資訊安全角色，這些角色共同決定了他們的整體權限。 Dataverse 提供業務單位和團隊等安全建模建構元素。 例如，可以使用業務單位來定義安全邊界，以使兩個不同的組織使用者群組之間的資料保持隔離。 您可以使用團隊對需要類似資料存取權限的使用者進行分組。 您甚至可以指派資料列的群組擁有權。 下圖說明如何使用業務單位隔離組織各部門的資料。
設計您的安全性模型
為應用程式的整體架構客製化現代化應用程式的安全性模型。 使用單一資料存放庫且不需要連接器的應用程式，所需的安全設計工作較少。 隨著應用程式使用更多的連接器和資料存放庫，您的安全性模型必須包括其他考慮因素。
使用者身分識別：使用者如何進行驗證，在來自內部部署的情境中，該驗證是否已對應到 Microsoft Entra ID？ 這包括在 Dataverse 等雲端資料存放區中支援應用程式群組或團隊分配所需的群組對應。
連接器連線身分識別：當應用程式使用一個或多個連接器時，對連線進行哪種類型的驗證，以及它是否提供實作所需安全控制所需的控制層級？ 例如，使用服務主體進行連接的應用程式不需要應用程式的使用者直接存取連接器，這在某些情況下是有益的。 單獨的使用者連線可能適用於需要知道哪個使用者執行了作業或將回應範圍限定為特定使用者的應用程式。
安全性構造可攜性：當您的應用程式使用更多的連接器和資料存放庫時，請務必記住，並非所有安全構造都會直接對應到另一個安全性構造。 例如，在 Dataverse 中，使用者可以透過多種方式存取資料列，包括與使用者共用該資料列。 如果應用程式將 SharePoint 文件庫與行關聯，則授予對文件庫的存取權限的安全性與控制 Dataverse 存取的安全性是分開的。 它們不直接對應。 現代化的應用程式必須適應它們所使用的連接器和資料存放庫中的這些類型的不匹配。
AI
在過去的幾年裡， AI 已經進入應用程式現代化工作之中。 在對應用程式進行現代化改造時，組織應該考慮使用 AI 來幫助使用者提高工作效率並更好地做出明智的決策。 注入 AI 的結果還可以轉化為更好的客戶體驗，進而對業務成果產生正面影響。
包括 AI 在內，整合應用程式邏輯和建立客製化訓練模型曾涉及繁重的工作。 借助大型語言模型的可用性和強大功能，應用程式現在可以引入使用 AI 的新方法來幫助使用者獲得答案和執行任務。 使用者可以使用自然語言提示在廣泛的輔助業務情境中與 AI 功能互動。
Microsoft 在核心產品和服務中引入了 Copilots，以便更輕鬆地存取先進的 AI 技術。 Copilot 使用現代 AI 技術和大型語言模型，使用者可以在日常使用的應用程式 (如 Microsoft 365、Windows、Dynamics 365 和 Power Platform) 中與其進行互動。
使用外掛程式擴充
由 Copilot 提供支援的應用程式的使用者可以向 Copilot 尋求有關應用程式中常見任務的協助。 您可以擴展 Copilots 以包含他們尚不知道的資料和任務，而這些資料和任務超出了使用者正在使用的應用程式的範圍。 Microsoft 365 Copilot 可以合併儲存在 Dataverse 中的 Power Platform 資料，這樣使用者就不必在應用程式之間來回切換。 例如，從 Outlook 中，使用者可以要求 Copilot 為今天完成的所有未透過的檢查產生狀態更新。 Microsoft 365 Copilot 會自動繼承 Dataverse 的原生安全和治理框架，並在執行階段套用使用者安全性和權限。
連接器作為外掛程式
Power Platform 連接器對於 Copilot 體驗也很重要。 連接器可以作為外掛程式連接以擴展 Copilot 的功能。 例如，具有 Jira Software 的 Power Platform 連接器的 Microsoft 365 Copilot 可以使專案經理請求 Jira 支援票的狀態並根據回應採取行動，例如將其路由以獲得更多核准或啟動新硬體的採購訂單。 使用外掛程式，您可以將您的商務程序和資料與 Copilot 整合，以使使用者能夠從他們使用的任何應用程式進行互動。
打造自己的副手
隨著使用者越來越習慣在應用程式中使用副手 AI 輔助，他們期望在所有應用程式中都能使用這種輔助。 您可以透過納入使用 AI 開發框架 Copilot 堆疊建立的副手，讓您的現代應用程式更具吸引力。
您可以使用 Power Apps 中預先建置的 Copilot 控制項，將副手新增至畫布應用程式和模型導向應用程式。 透過設定資料來源檢視和一些基本的提示訊息，您可以快速提供自己的應用程式內副手體驗。
應用程式生命週期管理
任何現代化工作的重要部分是建立適當的應用程式生命週期管理流程。 組織通常希望他們的低程式碼工作能夠適應傳統程式碼 ALM 的工作方式。 Power Platform 提供 ALM 工具，以便您可以在常使用的流程中或旁邊包含低程式碼成品。
Power Platform 中的 ALM 從如何建立低程式碼資源開始。 您建置的資源位於 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 應用程式為客戶創造了更順暢的旅行體驗，並為團隊成員創造更好的技術工具
- GitHub 上的 Power Fx 開放原始碼存放庫
- CoE 入門套件
- Power Platform 採用評量
- 數位保險代理程式使用 Power Platform 自動化複雜的購買流程
- PCF 畫廊
- 安永利用 Microsoft Power Platform 重新設計其全球財務流程
- Azure 私人連結
- Microsoft Azure ExpressRoute
- Power Platform 發行規劃工具
- Microsoft Power Platform 授權指南
- Microsoft 概述了建立 AI 應用程式和副手的框架；擴充 AI 外掛程式生態系統