將 BizTalk Server 移轉至 Azure 整合服務的方法
本指南涵蓋移轉策略和資源以及規劃考量和最佳做法，可協助您提供成功的移轉解決方案。
注意
如需移轉概觀和在 Azure 中選擇服務以進行移轉的指南，請檢閱下列文件：
策略選項
下一節說明各種移轉策略及其優點和缺點：
隨即轉移
在 Azure Marketplace 中，您可以找到選項以使用即用即付模型來佈建包含 BizTalk 授權虛擬機器。 此供應項目透過以使用量為基礎的定價模型，提供使用 Microsoft 的基礎結構即服務 (IaaS) 功能優點。 雖然使用這些虛擬機可以緩解管理 BizTalk Server 基礎結構的一些挑戰，但這種方法無法解決 BizTalk Server 的支援生命週期排程和期限問題。
隨著組織藉由移至或採用雲端來擁抱數位轉型，許多組織的共同任務是停止使用其 VMware、Hyper-V 或實體伺服器基礎結構，並將此功能遷移至 Azure 上的 IaaS。 此選項有助於減少先前提到的挑戰，但無法解決 BizTalk 程式碼基底問題。
使用 BizTalk Server 2013 和更新版本，您可選擇像之前一樣在內部部署環境執行 BizTalk 伺服器，或在 Azure 中的虛擬伺服器上執行。 在雲端執行 BizTalk Server 環境提供下列優點：
- 不需要私人硬體或基礎結構，因此不需維護硬體。
- 伺服器基礎結構的可用性增加，其可跨越多個資料中心或在可用性區域中複製。
- 透過網際網路從任何位置存取您的伺服器。
- Microsoft 會備份您的映像。
- 使用 Azure Marketplace 上可用的內建映像快速部署新伺服器。
- 藉由變更虛擬機器大小來新增記憶體和CPU、新增硬碟等，快速擴大伺服器規模
- 使用 Azure 資訊安全中心改善環境的安全性。 此服務會識別安全性威脅，並在發生安全性事件時提供調查路徑
混合式整合
雖然 BizTalk Server 和 Azure 整合服務功能可能重疊，但是當您一起使用它們時，其運作效果更好。 未將整個基礎結構移至雲端的大部分組織主要有下列幾個原因：
- 公司原則
- 國家/地區原則
- 產業領域特定原則
此外，並非所有功能或應用程式都存在於雲端，或有些可用的功能可能不像內部部署功能那麼強大。 不過，為了跟上雲端革命及擴展商務功能，許多組織一開始會將 SaaS 供應項目與其內部部署系統一起使用。 許多商務流程可以受益於雲端式開發和實作策略。
藉由採用混合式整合策略，您仍可從貴組織依賴的系統技術投資獲得價值，但仍受益於新功能、改善的效能，以及 Azure 等雲端式應用程式的成本較低結構。
使用 BizTalk Server 2016，個別發行的 Microsoft BizTalk Server Adapter for Logic Apps 提供了機會，讓您使用 Azure Logic Apps 來連線數百項雲端服務，以在 Azure 上實作部分的整合邏輯即服務。 此配接器藉由提供下列功能，協助進行內部部署整合和混合式整合：
使用 Azure Logic Apps、Azure 服務匯流排、Azure 事件中樞、Azure Blob 儲存體和 Office 365 郵件、排程和連絡人等內建配接器來整合雲端服務與 BizTalk Server。
使用 Azure Logic Apps 中的 BizTalk Server 連接器，從 Azure Logic Apps 連線到 BizTalk 伺服器。
使用 Azure API 管理發佈 BizTalk Server 端點，以便組織將端點公開給內部開發人員和外部合作夥伴。
透過 BizTalk Server 2020，安裝自動包含了適用於 Azure Logic Apps 的配接器以及內建適配器，以便輕鬆地與雲端環境連線。
大爆炸
「大爆炸」或「直接轉換」方法需要經過大量規劃，不建議不熟悉 Azure Logic Apps 或有大型系統或解決方案要遷移的組織使用。 當組織實作新技術堆疊時，通常會產生新的學習成果。 太早或太多投資，您就沒機會受益於所學到的經驗，以及在不冒重大重新作業風險的情況下進行調整。
這種方法可能還需要更長的時間才能獲得或累積價值。 如果您已完成某些移轉活動，但由於其他擱置或進行中的工作，尚未將其釋出至生產環境，則已移轉的成品不會為您的組織產生價值。
反覆式 (建議)
這種方法讓您的組織有機會以累加方式達成價值，但比其他方法更快。 您的專案小組可以利用回顧，儘早了解技術堆疊。 例如，您可以將現有的 BizTalk 介面或專案部署到生產環境，然後了解解決方案的需求，包括管理、可擴縮性、作業和監視。 取得此知識之後，您可以規劃短期衝刺，將現有的功能最佳化，或引進可在後續工作中使用的新模式。
無論您的方法為何，如果您打算移至 Azure 整合服務或一般 Azure，務必考量在解除委任伺服器基礎結構之前，先將 BizTalk Server 解決方案重構為無伺服器或雲端原生解決方案。 如果您的組織想要將業務完全轉換至雲端，這個選擇是絕佳的策略。
規劃移轉
下一節提供規劃移轉的指引，以及要考量的領域。
整備規劃
整備程度代表規劃程序中的重要部分。 當您瞭解專案的廣度和深度時，可預測性可改善多個維度，例如成本、複雜度、時間表，以及專案的整體成功。 下列清單包含要在專案的規範流程中檢閱和處理的特定區域。
| 區域 | 描述 |
|---|---|
| 存貨 | 擷取所有介面和應用程式的相關資料，以便了解您需要移轉的介面和應用程式數目。 在此編目過程中，收集下列資訊以提供內容： - 使用中的配接器 - 使用中的 BizTalk Server 功能，例如商務活動監視、商務規則引擎、EDI 等等 - 自訂程式碼，例如運算式、地圖和管線元件 - 訊息輸送量 - 訊息大小 - 相依性 |
| 簡化 | 若要協助您了解介面的複雜度層級，請檢查這些介面中的商務規則類型，以及需要自訂以符合其需求或效能需求的技術需求。 |
| 值 | 評估介面的價值，以便判斷要重新實作介面的優先順序。 從低風險介面著手可能很合理，在熟悉使用 Azure 整合服務之後，務必先專注於最高價值的工作。 |
| 成本 | 建立專案的範圍和預估成本，因為移轉專案需要資本才能開始執行。 無論是透過資本或營運預算規劃來達成，都要確保專案的預算，以及一路管理專案的範圍。 |
| 應用程式和系統相依性 | 在開始專案規劃時識別並考量這些相依性，因此您可以在開始專案執行時避免意外。 |
| 風險登錄 | 建立並使用此成品來識別及追蹤您在進行專案規劃練習時所浮現的任何風險。 當您瞭解風險時，可以主動減輕風險並傳達給領導階層。 您也可以儘早移除封鎖程式，因為其處理成本較低。 |
移轉工具
Azure Integration Migrationor 命令列工具也稱為 BizTalk 移轉工具，這是一個 Microsoft 開放原始碼專案，可在移轉專案的規劃和執行階段中協助您，以及協助將 BizTalk Server 應用程式移至 Azure 整合服務。 您也可以使用這項工具來找出將解決方案移轉至雲端的實用見解和策略。
此工具會經歷下列階段：
探索
提取 BizTalk Server 資源並識別要移轉的 BizTalk 成品。 讀取組件和繫結檔案資訊。
需求：Biztalk Server 應用程式的 MSI 和所有參考的 BizTalk Server 應用程式
剖析
讀取 BizTalk Server 成品，並建置 BizTalk Server 應用程式的來源資料模型。
分析
使用剖析階段的來源資料模型，建置 Azure 整合服務目標資料模型。 基本上，此工具會檢閱 BizTalk Server 資源、識別哪些項目可移轉，以及建置 Azure 整合服務目標的資料模型。
報告
產生報告，概述找到的 BizTalk Server 資源和可移轉的項目。 此報告也包含來源和目標應用程式中內容的詳細資訊，以及任何轉換潛在問題的詳細資料。
轉換
產生 Azure Resource Manager 範本和 Azure CLI 指令碼，您可使用目標資料模型在 Azure 中建置應用程式。
Verify
此工具目前並未內建此階段，但您可執行安裝指令碼，將應用程式部署至 Azure。 然後，您可以評估所產生的應用程式是否提供與 BizTalk Server 內部部署應用程式相同的功能。
下圖顯示 Azure Integration Migrator 工具經歷的階段：
成功移轉的主要小組角色和技能
若要成功將整合工作流程從 BizTalk Server 遷移至 Azure 整合服務，請建立具有下列重要角色和技能的小組，其跨越多個專業領域：
| 角色 | 技能 |
|---|---|
| 專案經理 | 負責領導整體專案，並在時間和預算的界限內提供議定的範圍。 |
| Scrum 領導者 | 主動管理待處理項目 (backlog)，並協助設定專案的活動優先順序。 |
| 結構設計師 | 確定專案符合企業架構原則，並提供如何瀏覽不確定性和障礙的指引。 |
| 開發人員 | 主動將元件從 BizTalk Server 遷移至 Azure 整合服務。 |
| 品質保證測試人員 | 建立測試計劃並針對這些計劃執行測試。 在專案短期衝刺規劃中追蹤、溝通和分級錯誤 (bug) 和瑕疵。 |
| 使用者驗收測試人員 (UAT) | 提供業務專案關係人，協助確保將介面從現有平台移至新平台，不會帶來任何退步情形。 |
| 變更管理專家 | 評估對現有流程和角色的影響。 建置計劃，協助在任何察覺到的問題出現之前減輕。 |
為了協助提供先前所述的部分或所有資源，請考慮有執行移轉經驗的合作夥伴。 小組成員可以協助降低風險、改善上市時間，以及使用其技能集和專業知識讓專案更可預測。
建置流程規劃
針對組建規劃，Microsoft 建議您包含短期衝刺和工作項目來處理基礎服務，例如驗證、記錄、例外狀況處理等等。 此種包含有助於避免稍後在開發週期中因無法因應基礎需求而進行重新作業。 您也想要避免因為需要其他專案關係人做出決策而遭到封鎖的開發人員。
下列清單僅涵蓋一些要考量的區域：
| 區域 | 描述 |
|---|---|
| 驗證 | 在您太深入介入開發週期之前，請先解決下列問題和其他驗證相關問題。 - 您的組織是否有任何驗證配置的標準？ - 您可以在 Azure 中使用受控識別和服務主體嗎？ - 是否允許基本驗證和 API 金鑰？ 這項活動是引入企業架構設計人員的絕佳機會，他們可確保要使用那些驗證配置取得清楚的協議。 |
| 記錄 | 請考慮收集遙測並將其儲存在集中式資料存放庫中，這是整合解決方案所使用的熱門模式。 例如，Azure Logic Apps (標準) 可將遙測推送至 Azure 監視器中的 Application Insights。 Azure Logic Apps (取用) 也可以將遙測推送至 Log Analytics (也位於 Azure 監視器中)。 您也可以包含追蹤的屬性，讓開發人員可以包含更多內容，因為訊息會流經整合平台。 例如，此資料可能包含工單號碼、採購單資訊，或可能對您組織有用、有幫助且相關的任何其他資料。 可以說，根據組織的需求，每個組織的解決方案可能有所不同。 例如，有些組織想要完全控制記錄資料的內容和時機。 在此案例中，您可以建立 API 或自訂連接器，然後根據特定里程碑檢測程式碼。 無論您選擇哪種方法，請確定開發人員都清楚瞭解期望，以避免將來重新作業。 |
| 例外狀況處理 | 儘早制定策略和一致的模式來處理例外狀況和錯誤，以避免將來重新作業。 建立任何邏輯應用程式之前，務必儘早釐清此區域。 下列清單包含進行例外狀況處理時要回答的一些問題： - 您將如何使用範圍和「執行時間點」設定來偵測例外狀況？ - 如何使用 result() 運算式來進一步瞭解工作流程中發生例外狀況的位置，以及尋找基礎根本原因的詳細資訊？ - 選擇如何攔截例外狀況之後，您要如何記錄此資料並傳達給專案關係人？ 請確定這些決策與先前所提的記錄策略一致。 在理想的情況下，您已建立一個流程，主動在記錄資料存放區中尋找新的錯誤事件。 您可以從該處回應這些事件並協調例外狀況流程。 您可能必須篩選出或彙總重複的錯誤事件、在組織的 IT 服務管理解決方案中記錄票證，然後選擇如何傳送通知。 根據問題嚴重性和當天的時間，您可能有不同的通知路徑。 您可以建立工作流程來管理此流程，以達到靈活度。 |
| 分析 | 若要向專案關係人展示解決方案的整體健康情況，請考慮專案關係人使用的不同視角，例如： - 主管可能對於整體健康情況、交易計數或數量，以及這些交易產生的商業價值更感興趣，而不是整體技術細微差別。 - 一線經理可能對整體健康情況更感興趣，但也可能對技術細節感興趣 (例如效能特性) 以確保符合 SLA。 - 支援分析師可能會對整體服務健康情況、例外狀況和效能瓶頸感興趣。 當您制定分析策略時，請考慮您的專案關係人和感興趣的資料類型。 此想法流程可協助您確定追蹤實用且有幫助的資訊，並讓資料可供報告之用。 如果您發現涵蓋範圍差距，您可能必須重新瀏覽與記錄相關的工作項目，並新增適當的工作來解決這些落差。 |
| 步調 | 當您交付整合專案並從這些經驗學習時，確保獲取不可避免的教訓。 在旅程初期規劃補救短期衝刺或週期，以便在成本變得太大之前，儘早修正路線。 如此一來，您就可以避免在新平台中引入過多的技術債務。 |
部署規劃
當您預期並準備部署計劃時，您可提高成功部署的機會。 使用 BizTalk Server，在建立所有基礎結構和環境之後，您會將焦點轉移到解決方案部署。
使用 Azure 時，這種體驗因首先要考慮的一些活動而有所不同，例如解決不同環境之間的基礎結構部署，其中可能包括不同的 Azure 訂閱、Azure 資源組或某種組合，例如：
- Azure Key Vault：秘密和存取原則
- Azure 服務匯流排：佇列、主題、訂閱、篩選條件和存取原則
- Azure App Service：方案、網路和驗證
接著，您可以專注於不同環境之間的解決方案部署。
測試計劃
為了確保專案關係人滿意您提供的解決方案，測試對於任何移轉專案都很重要。 相較於先前的解決方案，新的解決方案應提供更多價值，而沒有任何可能影響業務的退步情形。
請考慮移轉專案的下列測試建議：
藉由回答下列問題來建立基準：
- 您有現有的測試嗎？
- 測試執行時沒有錯誤嗎？
- 測試結果是否正確？
若要確信您的小組未帶來退步情形，您需要能夠將新平台的結果與現有平台的可靠測試進行比較。 因此，如果您沒有基準，務必建立基準。
當然，您不想花費許多資源來對即將淘汰的平台建立測試，但您需要回答問題：「如何知道一切運作順利？」如果您處於這種情況，請根據優先順序開始建立基準，並建立計劃以減輕您有落差的區域。
設定新平台的測試策略。
假設您已熟悉基準，您現在可以思考如何在新的平台上進行測試。 如果您在建立基準時遇到問題，藉此機會為新平台建立強大的基礎。
當您考慮測試新平台時，請將自動化放在首位。 雖然擁有平台可讓您快速建置介面，但依賴手動測試會削弱生產力的提升。
將測試自動化。
Azure Logic Apps (標準) 包含執行自動化測試的功能。 下列清單包含 GitHub 上可自由取得的詳細資訊和資源：
從 Azure Logic Apps 小組使用 Azure Logic Apps (標準) 自動化測試
使用 Azure Logic Apps (標準)，自動化測試就不再難以執行，因為基礎架構是以 Azure Functions 執行階段為基礎，而且可以在 Azure Functions 可執行的任何位置執行。 您可以針對在本機或在 CI/CD 管線中執行的工作流程撰寫測試。 如需詳細資訊，請參閱 Azure Logic Apps 測試架構的範例專案。
此測試架構包含下列功能：
- 在 Azure Logic Apps 中撰寫端對端功能的自動化測試。
- 在工作流程執行和動作層級上執行更細緻的驗證。
- 將測試簽入 Git 存放庫，並在本機或在 CI/CD 管線內執行。
- HTTP 動作和 Azure 連接器的模擬測試功能。
- 設定測試以使用與生產環境不同的設定值。
整合劇本：邏輯應用程式標準測試 (出自 Microsoft MVP Michael Stephenson)
整合劇本測試架構是以 Microsoft 提供的測試架構為基礎並支援其他案例：
- 連線到標準邏輯應用程式中的工作流程。
- 取得回呼 URL，讓您可以從測試觸發工作流程。
- 檢查工作流程執行的結果。
- 檢查工作流程的執行歷程記錄中的作業輸入和輸出。
- 插入邏輯應用程式開發人員可能使用的自動化測試架構。
- 插入 SpecFlow 以支援邏輯應用程式的行為驅動開發 (BDD)。
無論您使用哪種方法或資源，您都能順利進行可重複且一致的自動化整合測試。
使用靜態結果設定模擬回應測試。
無論您是否設定自動化測試，都可以使用 Azure Logic Apps 中的靜態結果功能，在動作層級暫時設定模擬回應。 這項功能可讓您模擬您想要呼叫的特定系統行為。 然後，您可以隔離執行一些初始測試，並減少您在企業營運系統中建立的資料量。
執行並排測試。
在理想情況下，您已經有 BizTalk Server 環境的基準整合測試，並已針對 Azure 整合服務建立自動化測試。 然後，您可以使用相同的資料集，並排執行測試，以協助您檢查介面，並改善整體測試精確度。
上線
在小組完成測試之後，請考慮將新的整合平台投入生產所需的工作：
建立通訊計畫。
雖然您可能有一個小型小組可實作整合平台現代化專案的技術層面和詳細資料，但可能有許多專案關係人需要隨時瞭解移轉專案。 如果您沒有明確的溝通策略，您會為其他相關的人帶來焦慮。 此外，請考慮您需要包含在通訊計劃中的外部專案關係人。 例如，您可能想要納入其他可能受到即將發生的事件影響的合作對象或客戶。 也別忘了這些專案關係人。
因此，藉由釐清會影響專案關係人的領域 (例如，您的期望為何、何時需要、需要的時間多長等等)，儘早並經常進行溝通。 藉由提供簡潔清楚的計劃，您可為專案關係人建立信心，並對您的專案保持正能量。 確定您的小組已準備好執行，藉此消除任何疑慮。 否則，您有可能因為您的專案可能失敗的看法、猜測和謠言，而面臨士氣受損的風險。
制定「完全移轉」計劃。
完全移轉計劃涵蓋從目前平台切換至新平台所需的工作和活動詳細資料，包括小組計劃執行的步驟。 在您的完全移轉計劃中納入下列考量：
必要步驟
識別您可以或必須事先執行的動作，讓您不會將一切都留到完全移轉這天。 一般而言，新整合平台的完全移轉通常表示您有「綠地」部署，因此您可以在週期儘早暫存許多元件和組態。 您可在原始平台的維護期間之前完成越多，您可以消除的焦慮越多，並改善完全移轉事件的整體結果。
彩排
專案關係人希望對即將發生的事件有些可預測性。 那麼，如何為你以前從未做過的事情提供可預測性？ 藉由執行將整合平台部署至生產前環境的彩排，您即可驗證完全移轉計劃以及流程中每個步驟的預期時機。
否則，低估步驟可能花費的時間可能會導致延遲的連鎖反應。 累積起來，這些延遲可能會花費大量時間並且干擾業務。 當您執行彩排時，您可以根據實際資料進行排程。 您的小組可能也發現在生產上線期間會導致問題的問題。 當小組儘早發現並記載問題時，他們就能做更好的準備，而且在真的完全移轉事件中承擔的意外風險也更少。
人員
確保負責計劃中每個特定步驟的人員都有明確的責任。 作為明智的風險降低策略，請識別並準備備份人員，以防主要人員因非預期的情況而無法執行工作。
排程預估
執行一次彩排之後，您的小組應該更瞭解每項工作可能需要多久時間才能完成。 您可以使用這些估計來預測排程，讓人員知道您何時需要他們，他們大約需要多少時間來完成其工作。
在舊平台中停用介面
假設您瞭解所有現有的相依性，您可以在新平台中啟用介面之前，先開始在舊整合平台中停用介面。 某些複雜的架構可能會要求您以特定順序停用循序介面，以免發生意外。 根據介面的性質，您可能也無法在舊整合平台中停用所有的介面。 例如，如果您有一個可將訊息推送至整合平台的企業營運系統，務必在完全移轉計畫中考量這些情況。
在新平台中啟用介面
類似於您可能有需要您以特定順序停用的循序介面，您可能有新的循序介面可滿足相同的需求。 開始啟用介面之前，請確定您已瞭解所有相依性，並識別出啟用新循序介面所需的順序。
注意
請注意以有條理和系統化的方式執行啟用介面的步驟，以避免讓專案成功承受風險的失誤。
驗證測試
此活動非常重要，因此請將這項工作納入您的完全移轉計劃中。 啟用介面之後，請先確認介面如預期般運作，再進入「去或不去」階段。 在理想情況下，您可執行不會影響核心商務資料的驗證測試。 本指南會在稍後的章節中提供新介面驗證測試的詳細資訊。
決定復原計劃。
希望您現在有一個結構化且詳細的方法可實作新的整合平台。 不過，可能會發生意外狀況，因此請決定復原至先前整合平台所需的步驟。 如此一來，您已準備好計劃，以防萬一。
當您思考這些步驟時，請考慮可能觸發復原的事件。 此外，讓您的計劃與進行復原決策所需的人員保持一致。 本指南提供有關進行「去或不去」決策一節中的詳細資訊。
執行驗證測試。
您的完全移轉計劃應該已包含這項工作的詳細資料。 啟用介面之後，請先確認介面如預期般運作，再進入「去或不去」階段。 在理想情況下，您可執行不會影響核心商務資料的驗證測試。
例如，在理想情況下，您的驗證測試可以從生產企業營運系統讀取資料，但無法寫入資料，這會產生合規性問題。 否則，您必須等候商務交易流經您的介面，並驗證一切如小組預期般運作。
規劃作業或生產支援。
雖然在平台之間移轉介面的工作通常會耗用大部分的專案資源，但請考慮持續支援您的介面和新平台。
務必在專案小組與作業小組之間共用適當的知識數量和層級。
建立並保留同時包含技術和商務連絡人詳細資料的目前連絡人清單，讓任何人都可以在必要時聯繫適當的小組成員。
若要更順暢且及時地回應客戶，請在上線之前備妥支援流程和文件。 當實際事件發生時，您可避免支援成員嘗試弄清楚一切，以協助降低客戶、支援小組和專案小組的壓力。
選擇 [去或不續] 以便移至生產環境。
在此步驟中，與相關專案關係人合作，以決定專案是否可以移至生產環境。 例如，專案關係人可以包含領導層、專案管理、營運和業務代表。
慶祝小組成功。
恭喜！ 當您完成對組織或業務有正面影響的專案之後，是時候表彰小組的辛勤工作並慶祝驚人的里程碑了！ 務必以適當且有意義的方式將功勞歸於您的小組。 不認可是摧毀士氣的必然方式。
進行回顧。
就像任何工程活動一樣，您的小組可獲得寶貴的見解，並藉由從經驗中學習來擴充其知識。 與您的小組會面，一起討論和記錄進展順利的領域，以及可改善的領域。 請注意，您要在無威脅和支持性的環境中進行這次對話，並專注於學習和成長的目標，而不是指責。 與領導層和其他感興趣的專案關係人分享您學到的經驗。 此練習可在您的小組中建立信任並代表工程成熟度。
移轉的最佳做法
雖然最佳做法可能會因組織而異，但請考慮有意識地提升一致性，這有助於減少「多此一舉」的非必要工作和相似常見元件的備援。 當您協助啟用可重複使用性時，您的組織可以更快速地建置更容易支援的介面。 上市時間是數位轉型的關鍵推動因素，因此首要任務是減少開發人員與支援小組的不必要摩擦。
當您建立自己的最佳做法時，請考慮遵循下列指引：
Azure 資源的一般命名慣例
務必在所有 Azure 資源 (從資源群組到每個資源類型) 中設定並一致地套用良好的命名慣例。 為了針對可探索性和可支援性奠定堅實的基礎，良好的命名慣例可傳達目的。 命名慣例最重要的點是您擁有這些慣例，而且您的組織瞭解這些慣例。 每個組織都有可能必須考慮的細微差別。
如需此做法的指引，請檢閱下列 Microsoft 建議和資源：
- Azure 資源的縮寫範例
- Azure 命名工具，該工具可產生 Azure 相容名稱，協助您將名稱標準化，並將命名流程自動化。
Azure Logic Apps 資源的命名慣例
邏輯應用程式和工作流程的設計提供關鍵起點，因為此區域為開發人員提供建立唯一名稱的彈性。
邏輯應用程式資源名稱
若要區分取用和標準邏輯應用程式資源，您可以使用不同的縮寫，例如：
- 取用：LACon
- 標準：LAStd
從組織的觀點來看，您可以設計包含業務單位、部門、應用程式及選擇性包含部署環境的命名模式，例如 DEV、UAT、PROD 等等：
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
假設您在開發中擁有標準邏輯應用程式，其可在公司服務業務單位中實作人力資源部門的工作流程。 您可將邏輯應用程式資源命名為 LAStd-CorporateServices-HR-DEV，並適時使用 Pascal Case 標記法以保持一致。
邏輯應用程式工作流程名稱
取用邏輯應用程式資源一律只會對應至一個工作流程，因此您只需要單一名稱。 標準邏輯應用程式資源可以包含多個工作流程，因此設計您也可套用至成員工作流程的命名慣例。 針對這些工作流程，請考慮以流程名稱為基礎的命名慣例，例如：
Process-<*process-name*>
因此，如果您有可實作員工入職工作的工作流程，例如建立員工記錄，可將工作流程命名為 Process-EmployeeOnboarding。
以下是設計工作流程命名慣例的更多考量：
- 對於您想要強調一或多個工作流程之間某種關聯性的邏輯應用程式，請遵循父子模式。
- 將工作流程發佈或取用訊息納入考慮。
工作流程作業名稱
當您將觸發程序或動作新增至工作流程時，設計工具會自動指派該作業的預設泛型名稱。 不過，作業名稱在您的工作流程中必須是唯一的，因此設計工具會在後續的作業執行個體上附加循序數值尾碼，讓開發人員的原始意圖變得難以閱讀和解譯。
若要讓作業名稱更有意義且更容易瞭解，您可以在預設文字之後新增簡短的工作描述項，並使用 Pascal Case 標示法以保持一致。 例如，針對剖析 JSON 動作，您可使用剖析 JSON-ChangeEmployeeRecord 之類的名稱。 使用此方法或其他類似的方法，您會繼續記住動作是 [剖析 JSON] 和動作的特定用途。 因此，如果您需要稍後在下游工作流程動作中使用此動作的輸出，您可以更輕鬆地識別及尋找這些輸出。
注意
對於廣泛使用運算式的組織，請考慮不會使用空白 (' ') 升階的命名慣例。 Azure Logic Apps 中的運算式語言會以底線 ('_') 取代空白，這可能會使撰寫變複雜。 藉由避免前面的空格，您可協助減少撰寫運算式時的摩擦。 請改用虛線或連字元 ('-') 來提供可讀性，且不影響運算式撰寫。
若要避免後續可能的重新作業和下游相依性 (這些相依性會在您使用作業輸出時建立) 問題，請在將作業新增至工作流程時立即重新命名作業。 通常，當您重新命名作業時，就會自動更新下游動作。 不過，在執行重新命名之前，Azure Logic Apps 不會自動重新命名您建立的自訂運算式。
連線名稱
當您在工作流程中建立連線時，基礎連線資源會自動取得泛型名稱，例如 sql or office365。 如同作業名稱，連線名稱也必須是唯一的。 具有相同類型的後續連線會取得循序數值尾碼，例如 sql-1、sql-2 等等。 這類名稱沒有任何內容，而且使得區分及對應連線至其邏輯應用程式極具挑戰性，尤其是不熟悉該領域且必須負責維護這些邏輯應用程式的開發人員。
因此，有意義且一致的連線名稱很重要，原因如下：
- 可讀性
- 更容易的知識轉移和支援性
- 治理
同樣地，具有命名慣例非常重要，不過格式並不重要。 例如，您可以使用下列模式作為指導方針：
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
具體範例是，您可以在 OrderQueue 邏輯應用程式或工作流程中將服務匯流排連線重新命名，以 CN-ServiceBus-OrderQueue 作為新名稱。 如需詳細資訊，請參閱 Turbo360 (先前稱為 Serverless360) 部落格文章：邏輯應用程式最佳做法、秘訣和訣竅：#11 連接器命名慣例 (英文)。
處理範圍和「執行時間點」選項的例外狀況
範圍提供將多個動作分組的功能，以便實作 Try-Catch-Finally 行為。 範圍動作的功能類似於Visual Studio中的區域概念。 在設計工具上，您可以摺疊和展開範圍的內容，以改善開發人員生產力。
當您實作此模式時，也可以根據上述動作的執行狀態，指定何時執行範圍動作以及其內部動作，狀態可以是 Succeeded、Failed、Skipped 或 TimedOut。 若要設定此行為，請使用 [範圍] 動作的 [執行時間點] (runAfter) 選項：
- 成功
- 失敗
- 略過
- 逾時
合併共用服務
當您建置整合解決方案時，請考慮針對一般工作建立和使用共用服務。 您可以讓小組建置並公開專案小組和其他人可以使用的共用服務集合。 每個人都能提升生產力、統一性，以及強制治理組織解決方案的能力。 下列各節說明一些您可能考慮引進共用服務的領域：
| 共用服務 | 原因 |
|---|---|
| 集中式記錄 | 針對開發人員如何使用適當的記錄來檢測其程式碼，提供常見的模式。 然後，您可設定診斷檢視，以協助您判斷介面健康情況和支援性。 |
| 商務追蹤和商務活動監視 | 擷取並公開資料，讓商務主題專家可以進一步瞭解其商務交易的狀態並執行自助式分析查詢。 |
| 設定資料 | 將應用程式組態資料與程式碼分開，以便在環境之間更輕鬆地移動應用程式。 務必提供統一一致且易於複製的方法來存取組態資料，讓專案小組能夠專注於解決商務問題，而不是花時間處理用於部署的應用程式組態。 否則，如果每個專案都以獨特的方式實現這種分離，您就無法從規模經濟中獲益。 |
| 自訂連接器 | 針對 Azure Logic Apps 中未預先建置連接器的內部系統建立自訂連接器，為專案小組和其他人進行簡化。 |
| 通用資料集或資料摘要 | 將通用資料集和摘要公開為 API 或連接器，讓專案小組使用，以及避免多此一舉。 每個組織都有通用資料集，他們需要在企業環境中整合系統。 |
檢閱、反映和學習
不時評量及評估現有的邏輯應用程式，尤其在失敗的時候。 不僅分析商務流程以找出可改善的項目和位置，也分析工作流程的執行歷程記錄，以從所發生的失敗、失誤和錯誤中學習。 Azure Logic Apps 提供如此豐富的執行歷程記錄，當您檢閱工作流程的執行歷程記錄時，您很有可能發現應用程式的新事物。 如同所有程式碼開發，有些邊緣或角落案例可能會出現。 當您進行探索時，請更新介面以考量這些情況，並改善解決方案的整體可靠性。
專案小組的一個現況是開發人員嘗試一般擷取錯誤，至少從問題中獲得一些保護。 當小組發現且進一步瞭解發生問題的地方時，您可以獲得有關如何防範問題的更多說明。
類似於組織定期執行「紅隊」練習 (例如滲透測試或網路釣魚嘗試) 的方式，安全性不是「一勞永逸」的活動。 當新的驗證配置和方法可供使用時，請定期重新瀏覽您的介面、檢閱您的安全措施，並納入可提供最安全方法的相關且適當的新發展。
DevOps 是您想要定期評估的另一個區域。 當 Microsoft 或社群引進新的範本或方法時，請評估這些更新，以判斷您是否可以獲得更多好處。
下一步
您現在已深入了解將 BizTalk Server 工作負載移至 Azure 整合服務的可用移轉方法、規劃考量和最佳做法。 若要提供本指南的詳細意見反應，您可以使用下列表單：
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應