將 BizTalk Server 移轉至 Azure Logic Apps 的方法
本指南涵蓋移轉策略和資源以及規劃考量和最佳做法，可協助您提供成功的移轉解決方案。
注意
如需移轉概觀和在 Azure 中選擇服務以進行移轉的指南，請檢閱下列文件：
策略選項
下列各節說明各種移轉策略及其優點和缺點：
大爆炸
「大爆炸」或「直接變更」是一種需要大量規劃的方法，不建議不熟悉 Azure Logic Apps 或具有大型系統或解決方案來移轉的組織使用。 當組織實作新技術堆疊時，通常會產生新的學習成果。 太早或太多投資，您就沒機會受益於所學到的經驗，以及在不冒重大重新作業風險的情況下進行調整。
這種方法可能還需要更長的時間才能獲得或累積價值。 如果您已完成某些移轉活動，但由於其他擱置或進行中的工作，尚未將其釋出至生產環境，則已移轉的成品不會為您的組織產生價值。
只有在您擁有小型、低複雜性的 BizTalk 工作負載、瞭解 BizTalk 環境的主題專家（SME），以及您目前使用的 BizTalk 功能與 Azure Logic Apps 之間的直接對應時，才建議您考慮此方法。 使用 Azure Logic Apps 的體驗也會大幅降低遵循此方法的風險。
反覆式或波浪型 （建議）
這種方法讓您的組織有機會以累加方式達成價值，但比其他方法更快。 您的專案小組可以利用回顧，儘早了解技術堆疊。 例如，您可以將現有的 BizTalk 介面或專案部署到生產環境，然後了解解決方案的需求，包括管理、可擴縮性、作業和監視。 取得此知識之後，您可以規劃短期衝刺，將現有的功能最佳化，或引進可在後續工作中使用的新模式。
無論您的方法為何，如果您一般打算移至 Azure Logic Apps 或 Azure，請務必在解除委任伺服器基礎結構之前，先將 BizTalk Server 解決方案重構為無伺服器或雲端原生解決方案。 如果您的組織想要將業務完全轉換至雲端，這個選擇是絕佳的策略。
BizTalk Server 和 Azure Logic Apps 有不同的架構。 若要進一步將解決方案現代化，您可以使用 Azure Integration Services 來擴充 Azure Logic Apps 中解決核心客戶整合需求的功能。
為了獲得更高的投資報酬率（ROI），我們建議任何 BizTalk 移轉都盡可能使用 Azure Logic Apps （Standard） 中的核心原生功能，並視需要擴充至其他 Azure Integration Services。 這種組合可讓其他案例成為可能，例如：
- 使用 Azure Logic Apps 的雲端原生混合式功能（標準）搭配混合式部署
- Azure Logic Apps 中的具狀態或無狀態工作流程功能（標準）
- 原生、內建（應用程式內）大型主機和中層主機與 Azure Logic Apps 中的連接器整合（標準）
- 使用 Azure 服務匯流排 的發佈子訊息
- Azure API 管理 中的進階 SOAP 功能
傳遞 BizTalk 移轉專案
若要完成這類項目，建議您遵循反覆或以波浪為基礎的方法，並使用 Scrum 程式。 雖然 Scrum 不包含短期衝刺前活動的短期衝刺零 （Sprint 0） 概念，但建議您將第一個短期衝刺放在小組對齊和技術探索上。 在Sprint 0之後，請遵循執行多個移轉短期衝刺，並專注於將功能發行至最低可行產品 （MVP）。
短期衝刺 0
在此短期衝刺期間，建議您使用波浪規劃執行 BizTalk Server 環境探索。 瞭解項目的廣度和深度對於成功至關重要。 下列清單包含短期衝刺 0 期間要解決的特定區域：
| 區域 | 描述 |
|---|---|
| 探索 | 擷取所有介面和應用程式的相關資料，以便了解您需要移轉的介面和應用程式數目。 您也需要將複雜度指派給每個介面或進程。 在此編錄程式期間，收集下列資訊來排定工作的優先順序： - 使用中的配接器 - 使用中的 BizTalk Server 功能，例如商務活動監視、商務規則引擎、EDI 等等 - 自訂程式碼，例如運算式、地圖和管線元件 - 訊息輸送量 - 訊息大小 -依賴 - 應用程式和系統相依性 |
| 結構設計 | 建立要作為移轉焦點的高階架構。 此設計包含可解決高階功能和非功能性需求的元素。 |
| 最小可行產品 （MVP） 定義 | 定義第一波特徵。 換句話說，完成第一波之後需要支持的程式。 |
| 初始移轉待辦專案 | 使用技術解釋定義第一波特徵及其工作專案。 |
探索工具
為了協助您進行移轉探索，您可以使用 Azure Integration Migrationor 命令行工具，也稱為 BizTalk 移轉工具，這是Microsoft開放原始碼專案。 此工具會使用階段式方法，協助您找出將解決方案移轉至雲端的實用見解和策略。 我們建議只針對探索和產生報表使用移轉工具。 您也可以考慮使用其他產品來探索在此空間中提供解決方案的合作夥伴。
若要使用 BizTalk Server 元素產生清查的另一種方式，您可以使用 Mark Brimble 開發的 BizTalk 檔工具。 此工具可與 BizTalk Server 2020 搭配運作，儘管說明只支援 BizTalk Server 2016。
結構設計
雖然 Azure Logic Apps 提供的功能可讓您重複使用 BizTalk Server 資產，但您必須具備現代化架構設計，才能接受更多新式功能的優點。 從功能的觀點來看，盡可能使用商業規則。 從產品現代化的觀點來看，盡可能使用 Azure Integration Services。 針對品質和跨領域考慮，建議您使用 Azure Well-Architected Framework。
在此架構下，BizTalk 移轉是 任務關鍵性工作負載。 此詞彙描述需要平臺上高可用性的應用程式資源集合，這表示它們必須一律可供使用、操作和復原失敗。
若要完成 BizTalk 移轉的架構設計，請遵循 Azure 上任務關鍵性工作負載的設計方法。 如需初始架構和拓撲，請檢閱和使用 Azure 架構中心 Azure 上基本企業整合中所述的參考架構。
若要設定初始環境，請使用 Azure Integration Services 登陸區域加速器，其目標是使用典型的企業登陸區域設計來建置和部署整合平臺。
最小可行專案 （MVP） 定義
MVP 是一個產品版本，其具有足夠的客戶可用功能。 此版本顯示產品收集客戶意見反應的可能性和潛力，並繼續工作。 針對 BizTalk 移轉，您的 MVP 定義會反映反覆專案、波浪或短期衝刺群組，而您需要進行工作功能，並符合初始整合工作負載。
我們建議您的 MVP 定義包含下列商務成果，其以 Scrum 術語中的 Epic 表示：
業務成果（Epics）
- 您想要達成的主要目標為何？
- 您必須為此 MVP 處理哪些功能或功能？
- 商務程式流程為何？ 此問題提供將 BizTalk Server 支援的現有進程優化的機會。
- 例如，影響 MVP 的商務成果，或資源可用性為何？商務決策為何？
我們建議您的 MVP 包含下列範圍中的程式，這些程式會以 Scrum 術語中的功能 表示：
範圍內行程 （功能）
| 功能 | 描述 |
|---|---|
| 高階系統功能 | 您可以使用探索工具來擷取此資訊，並以功能來表達描述。 |
| 動作專案或角色 | 使用這項信息來判斷受 MVP 支援案例影響的個人。 |
| 協調流程 | 您可以使用探索工具擷取此資訊。 |
| 數據實體和訊息 | 這些元素可讓您瞭解是否可以在 BizTalk Server 環境交換的數據中包含進一步改善。 |
| 資料對應 | 現今的世界依賴 JSON。 不過，BizTalk Server 會使用 XML。 此刻是決定新平台數據格式和轉換需求的絕佳機會。 |
| 商務規則 | 這些以數據為中心的規則可讓您重新思考其方法，或藉由採用 Azure Logic Apps 功能來重複使用它們。 |
| 數據隱私權考慮 | 您必須將隱私權設為最高優先順序。 除非您的客戶在 Azure Logic Apps 中選擇混合式部署模型（標準），否則您必須在每個波中解決此區域，因為潛在的部署環境變更。 |
| 法規考慮 | 如果您的客戶沒有雲端式工作負載，則此層面更相關。 |
| 設計成就安全 | 您必須以安全性為考慮設計每個功能。 |
| 共存的建議功能 | 當您傳遞每一波時，您都有某種程度的共存性。 您必須將此混合式架構與現有的服務等級指標 （SLA） 和服務等級目標 （SLO） 一致。 |
| 非功能性考慮 | 商務程式可能有不同的非功能需求。 並非所有項目都必須實時發生。 相反地，並非所有專案都是批處理。 |
| 商務計量 | 顯示移轉工作的進度的選擇性機會。 |
您也會想要識別並列出各種影響 MVP 工作範圍的跨範圍變數，例如：
- 資源可用性
- 風險
- 文件集
- 上市時間
初始待辦專案
初始 待辦專案 是一組用戶劇本，您會將它分組到功能中，以建 置 MVP 的範圍內程式 。 換句話說，MVP 是由稱為 Epics、Features 和 User Storys 的 Scrum 專案表示。 在理想情況下，每個 Epic 都包含一組 BizTalk 應用程式或 BizTalk 專案。 您可以使用將一個 BizTalk 應用程式或 BizTalk 專案與功能建立關聯的簡單規則。
例如，假設您有 BizTalk Server 專案，其協調流程稱為 “LoanRequests”，客戶會用來要求銀行貸款。 因此，您有下列建議的功能和用戶劇本：
功能：貸款處理
使用者故事：「作為客戶，我想提交貸款申請，以便銀行可以將資金新增至我的安全帳戶。
此用戶劇本目前可能以 BizTalk Server 中的實作的形式存在，有下列工作可使用 Azure Logic Apps 和 Azure Integration Services 來實作：
- 收集 BizTalk 可重複使用的成品。
- 使用 Azure Logic Apps 建立貸款要求工作流程。
- 使用 Azure 服務匯流排 或 IBM MQ 設定異步傳訊。
- 使用 Azure Logic Apps 工作流程將 JSON 對應至 XML 數據。
- 視訊息模式需要自定義 Azure Integration Services。
下圖顯示 Epic、功能、使用者劇本和工作的建議持續時間，這些持續時間會細分用戶劇本。 雖然實作決策會影響這些持續時間，但它們假設您在 Azure Logic Apps 中使用現有的 BizTalk 成品。 盡可能使用 預先建置的工作流程範本 來建立您的標準工作流程。
移轉波 （短期衝刺）
在小組完成 Sprint 0 之後，您應該清楚瞭解要建置的 MVP。 波是一組短期衝刺。 您的初始待辦項目應包含盡可能遵循下一個圖表的工作專案：
在一波中，您的小組會完成移轉、測試及發行至生產環境的活動。 讓我們更仔細地檢查每個波中會發生什麼事。
移轉
在每一波期間，移轉著重於已同意的用戶劇本。 在第一波中，您的小組著重於初始待辦專案。 技術決策必須使用 BizTalk Server 功能對應中的資訊，如功能比對中所述 - 為什麼從 BizTalk Server 遷移至 Azure Logic Apps？
下圖顯示移轉波期間應該發生的事件：
| 步驟 | 描述: |
|---|---|
| 1 | 探索現有的 BizTalk 應用程式和介面。 雖然在Sprint 0中引進，但當每個波開始時，應該會發生此活動。 客戶可能會在 BizTalk 環境中繼續進行變更。 資源： - BizTalk 移轉工具 - BizTalk 檔工具 |
| 2 | 設定初始移轉環境。 您可以使用 Azure Integration Services 登陸區域加速器，這是雲端採用架構，可用來建置和部署具有典型企業登陸區域設計的整合平臺。 身為工作負載擁有者，您可以使用提供的 架構指引和 BizTalk 移轉資源，自信地達到目標技術狀態。 如需範例架構，請參閱 範例移轉環境。 |
| 3 | 使用 Azure 入口網站 或 Visual Studio Code 搭配 Azure Logic Apps （Standard） 擴充功能，建立及測試在單一租使用者 Azure Logic Apps 中執行的標準邏輯應用程式工作流程。 使用 Visual Studio Code，您可以使用任何原始檔控制系統，在本機開發、測試及儲存邏輯應用程式專案。 如需詳細資訊，請參閱下列文件： - 使用 Azure 入口網站 建立標準邏輯應用程式工作流程範例 - 使用 Visual Studio Code 建立標準邏輯應用程式工作流程範例 如需顯示邏輯應用程式和連線範例的圖表，請參閱 範例移轉環境。 |
| 4 | 若要獲得跨不同環境和平臺輕鬆且一致地部署標準邏輯應用程式工作流程的完整優點，您也必須將建置和部署程序自動化。 適用於 Visual Studio Code 的 Azure Logic Apps （Standard） 延伸模組提供工具，可讓您使用 Azure DevOps 來建立和維護自動化建置和部署程式。 如需詳細資訊，請參閱 使用 Azure DevOps 自動化標準邏輯應用程式工作流程的建置和部署。 |
| 5 | 若要部署永遠可用且回應性的任務關鍵標準邏輯應用程式，即使在更新或維護期間，也能建立和使用部署位置來啟用零停機時間部署。 零停機表示當您部署新版本的應用程式時，終端使用者不應遇到中斷或停機。 如需詳細資訊，請參閱 設定部署位置以在 Azure Logic Apps 中啟用零停機時間部署。 |
下圖顯示標準邏輯應用程式的範例初始移轉環境，可協調與 API、服務、混合式解決方案和內部部署資源通訊的工作流程：
Test
每個 波 都有自己的測試活動，這些活動會內嵌在每個用戶劇本中。 如果您想要使用 shift-left 測試，請確定您已完成下列工作：
將測試自動化。
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 Logic Apps 建立自動化測試。 然後，您可以使用相同的資料集，並排執行測試，以協助您檢查介面，並改善整體測試精確度。
發行至生產環境
在小組完成並符合用戶劇本的「完成定義」之後，請考慮下列工作：
建立發行至生產環境的通訊計劃。
制定「完全移轉」計劃。
完全移轉計劃涵蓋從目前平臺切換至新平臺所需的工作和活動詳細數據，包括小組計劃執行的步驟。 在您的完全移轉計劃中納入下列考量：
- 必要步驟
- 彩排
- 人員
- 排程預估
- 在舊平台中停用介面
- 在新平台中啟用介面
- 驗證測試
決定復原計劃。
執行驗證測試。
規劃作業或生產支援。
選擇 [移至] 或 [不進入] 準則以發行至生產環境。
慶祝小組成功。
進行回顧。
BizTalk 移轉的最佳做法
雖然最佳做法可能會因組織而異，但請考慮有意識地提升一致性，這有助於減少「多此一舉」的非必要工作和相似常見元件的備援。 當您協助啟用可重複使用性時，您的組織可以更快速地建置更容易支援的介面。 上市時間是數位轉型的關鍵推動因素，因此首要任務是減少開發人員與支援小組的不必要摩擦。
當您建立自己的最佳做法時，請考慮遵循下列指引：
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*>
具體範例是，您可以使用 CN-ServiceBus-OrderQueue 將 OrderQueue 邏輯應用程式工作流程中的 服務匯流排 連線重新命名為新名稱。 如需詳細資訊，請參閱 Turbo360 （先前稱為 Serverless360） 部落格文章、 邏輯應用程式最佳做法、秘訣和訣竅：#11 連接器命名慣例。
處理範圍和「執行時間點」選項的例外狀況
範圍提供將多個動作分組的功能，以便實作 Try-Catch-Finally 行為。 在設計工具上，您可以摺疊和展開範圍的內容，以改善開發人員生產力。
當您實作此模式時，也可以根據上述動作的執行狀態，指定何時執行範圍動作以及其內部動作，狀態可以是 Succeeded、Failed、Skipped 或 TimedOut。 若要設定此行為，請使用 [範圍] 動作的 [執行時間點] (runAfter) 選項：
- 成功
- 失敗
- 略過
- 逾時
合併共用服務
當您建置整合解決方案時，請考慮針對一般工作建立和使用共用服務。 您可以讓小組建置並公開專案小組和其他人可以使用的共用服務集合。 每個人都能提升生產力、統一性，以及強制治理組織解決方案的能力。 下列各節說明一些您可能考慮引進共用服務的領域：
| 共用服務 | 原因 |
|---|---|
| 集中式記錄 | 針對開發人員如何使用適當的記錄來檢測其程式碼，提供常見的模式。 然後，您可設定診斷檢視，以協助您判斷介面健康情況和支援性。 |
| 商務追蹤和商務活動監視 | 擷取並公開資料，讓商務主題專家可以進一步瞭解其商務交易的狀態並執行自助式分析查詢。 |
| 設定資料 | 將應用程式組態資料與程式碼分開，以便在環境之間更輕鬆地移動應用程式。 務必提供統一一致且易於複製的方法來存取組態資料，讓專案小組能夠專注於解決商務問題，而不是花時間處理用於部署的應用程式組態。 否則，如果每個專案都以獨特的方式實現這種分離，您就無法從規模經濟中獲益。 |
| 自訂連接器 | 針對 Azure Logic Apps 中未預先建置連接器的內部系統建立自訂連接器，為專案小組和其他人進行簡化。 |
| 通用資料集或資料摘要 | 將通用資料集和摘要公開為 API 或連接器，讓專案小組使用，以及避免多此一舉。 每個組織都有通用資料集，他們需要在企業環境中整合系統。 |
下一步
您現在已深入瞭解將 BizTalk Server 工作負載移至 Azure Logic Apps 的可用移轉方法和最佳做法。 若要提供本指南的詳細意見反應，您可以使用下列表單：