Azure Logic Apps Standard 協助組織擴展並逐步現代化大型主機與中階工作負載，無需先重寫既有主機程式或將所有處理移至 Azure。 利用工作流程與內建連接器，將現有的交易、資料、訊息、檔案及螢幕驅動應用程式暴露給現代消費者。 可在 Azure、App Service 環境 v3（ASE v3）或透過 Azure Arc 啟用的 Kubernetes 的混合部署，在客戶管理的基礎設施上執行整合層。
從 BizTalk Server 遷移的客戶可保留相容的主機整合元資料，並利用現有的介面卡配置作為新內建連接器連接的輸入。 此方法支持現有與現代化系統的漸進共存，同時團隊以可控的波次移動介面與業務能力。
客戶價值
Azure Logic Apps Standard 為大型主機與中階現代化提供以下數值：
| 客戶目標 | Azure Logic Apps 標準值 |
|---|---|
| 保留工作系統 | 在現代化整合層的同時，重用現有的主機程式、資料結構、佇列、檔案及相容的元資料。 |
| 逐步現代化 | 將工作流程作為整合的表象，一次調整一個介面或業務能力，並在轉型期間讓舊有系統與現代系統共存。 |
| 減少自訂整合程式碼 | 使用視覺化工作流程、內建連接器、轉換功能以及工作流程範圍的程式碼，而不是從零開始打造每個整合元件。 |
| 選擇處理流程的執行位置 | 在 Azure 中託管工作流程，或在靠近本機系統的已啟用 Arc 的 Kubernetes 上執行這些工作流程，以在延遲、資料駐留或網路需求較適合本機處理時使用。 |
| 支援不同的工作負載特性 | 對於持久且長時間運行的程序，使用有狀態工作流程，當不需要持久性時，則使用無狀態工作流程以降低延遲、記憶體內處理。 |
| 採用現代交付方式 | 將工作流程定義、設定、元資料及支援程式碼儲存在原始碼控制中，並使用自動化建置與部署流程。 |
Azure Logic Apps Standard 是此解決方案的核心編排與整合執行階段。 其他訊息、API 管理、事件分發、資料庫或客戶管理服務預設並非必需。 只有當重構架構需要獨立的能力、規模邊界、生命週期或所有權模型時，才可加入。
為什麼要使用 Azure Logic Apps Standard
Standard 提供適合主機與系統整合的功能，這些功能並非全部同時在消費資源類型中提供：
- 內建的服務提供者基礎連接器可與 Azure Logic Apps 執行環境同步運行，並提供對支援大型主機及中階系統的直接存取。
- 標準邏輯應用程式可以包含多個相關的工作流程，這些流程共享運算、儲存、網路、設定及部署邊界。
- 有狀態與無狀態工作流程支援持久的流程與低延遲的請求-回應場景。
- Azure 託管的標準工作流程支援虛擬網路整合及私有端點以存取私有系統。
- 混合部署在客戶管理的基礎設施上執行工作流程與內建連接器操作。
- Visual Studio Code 開發支援本地測試、原始碼控制及 CI/CD。
Azure Logic Apps Standard 提供許多由主機整合伺服器（HIS）過去提供的核心整合能力的雲端原生實作，包括存取 IBM 交易程式、訊息系統、資料庫、主機檔案及 3270 個應用程式。 某些協定與情境，如 LU6.2 連線，仍需 HIS。
選擇執行工作流程的位置
本文中提到的大型主機與中階內建連接器，皆支援各標準主機方案。 選擇符合工作負載對基礎設施擁有權、隔離、連接性、延遲及資料定位需求的選項。
| 託管選項 | 最適用 | 重要考慮 |
|---|---|---|
| 工作流程服務計畫 | 管理型 Azure 主機，適用於透過私有或公共網路路徑連接主機系統的工作流程。 | 使用預留的 WS1、WS2 或 WS3 容量，並支援虛擬網路整合、私有端點及 Azure 監控。 |
| App Service 環境 v3 | 需要專用隔離、網路、合規性邊界，或與其他 App Service 工作負載整併的 Azure 託管工作負載。 | 需要 ASE v3 和隔離式 v2 App Service 方案。 |
| 混合 | 本地處理、資料駐留、低延遲存取主機系統，或客戶管理基礎設施。 | 可在已啟用 Azure Arc 的 Kubernetes 上執行，且需要由客戶管理的 Kubernetes、SQL Server、SMB 儲存體、網路、縮放及作業。 |
混合式部署為部分連線，並非實體隔離。 內建連接器操作需與本地 Azure Logic Apps 執行環境同步，而 Azure 管理及任何雲端託管連接器則需外站連線。 關於目前的基礎設施需求與限制，請參閱「 使用混合部署建立標準邏輯應用的自有基礎架構」。
保留現有的整合投資
數十年來，Microsoft 透過 Microsoft Host Integration Server 提供大型主機與中階主機整合能力。 Azure Logic Apps Standard 延續這項經驗，透過中繼資料驅動的工具和連接器，協助保留既有的應用程式投資。
Microsoft HIS Designer for Azure Logic Apps
這個 Visual Studio 工具會產生主機整合設計器 XML（HIDX）元資料，讓 Azure Logic Apps 連接器用來與大型主機及中階程式及資料結構互動。 圖形設計器讓你能建立、檢視、編輯並映射程式介面、方法、參數、記錄和資料型態。 你也可以匯入 COBOL 和 RPG 的複製簿。 欲了解更多資訊，請參閱 HIS Designer for Azure Logic Apps。
Microsoft 3270 設計工具
此工具記錄 3270 應用程式中任務的畫面、導航路徑、方法與參數。 該工具產生 HIDX 元資料，IBM 3270 連接器用以執行已記錄的導航計畫。 如需詳細資訊，請參閱 3270 設計工具。
遷移 BizTalk 主機與系統整合
如果您的 BizTalk Server 應用程式使用主機系統的轉接器，您可以利用許多現有的產物與設定細節，加速遷移至 Azure Logic Apps 標準：
- 可透過 CICS、IMS、IBM i、IBM 3270 及 IBM Host File 內建連接器重用相容的 HIDX 元資料。
- 利用現有的 COBOL 和 RPG 手冊來建立或更新 HIDX 的元資料。
- 使用 Azure Logic Apps 遷移代理程式來發現支援的 BizTalk 工件，包括綁定、端點設定和 HIDX 檔案，並在分析、規劃與轉換時使用它們。
現有設定若未經檢閱，無法轉換為可部署的 Azure Logic Apps 連線。 為目標託管環境重新建立特定環境的設定、認證資訊、憑證及網路設定，並驗證其最終行為。 依賴 LU6.2 的 BizTalk 整合需要重構或重新設計。 欲了解更多資訊，請參閱 Migrate BizTalk Server with Azure Logic Apps Migration Agent。
將現有資產映射到內建連接器
以下內建的基於服務提供者的連接器可與標準執行時一同運行。 部分連接器也有可在全域 Azure 運行的管理版本，但本文著重於內建版本。
| 現有資產或整合 | Azure Logic Apps Standard 現代化路徑 | 投資以保存 |
|---|---|---|
| IBM 3270 應用程式 | 使用 IBM 3270 連接器，在 TN3270 資料串流上執行錄製的螢幕導航。 此選項適合不提供程式介面的應用程式。 | HIDX 導航元資料與 TN3270 連線需求。 詳見 整合 IBM 3270 應用程式。 |
| CICS交易計畫 | 使用 CICS 程式呼叫連接器，透過 TCP/IP 或 HTTP 將現有交易暴露給工作流程及現代應用程式。 當需要 LU6.2 時，請使用 HIS。 | HIDX 元資料、抄本，以及主機和 CICS 連線需求。 請參閱 整合 CICS 計畫。 |
| IBM DB2 資料庫 | 使用 IBM DB2 連接器，直接透過 TCP/IP 讀取並修改支援的 DB2 資料庫，無需本地資料閘道器。 | 伺服器、資料庫、套件、代碼頁及認證要求。 請參閱 「連接 IBM DB2 資源」。 |
| IBM 主機檔案 | 使用 IBM Host File 連接器將二進位內容解析成結構化資料或產生二進位主機檔案內容。 這個連接器不需要直接連接主機。 | HIDX 版面、手冊及代碼頁資訊。 請參閱 解析並產生 IBM 主機檔案。 |
| IBM i COBOL 或 RPG 程式 | 使用 IBM i 程式呼叫連接器，透過分散式程式呼叫伺服器（Distributed Program Call）伺服器，透過 TCP/IP 重用已建立的商業邏輯。 當需要 LU6.2 時，請使用 HIS。 | HIDX 元資料、抄本及 IBM i 連線需求。 參見 整合 IBM i 程式。 |
| IMS 交易程式 | 使用 IMS 程式呼叫連接器，透過 IMS Connect 透過 TCP/IP 呼叫程式。 在幕後，IMS Connect 使用 IMS 訊息佇列來路由請求與回應。 | HIDX 中繼資料、副本簿和 IMS Connect 設定。 請參閱 整合 IMS 計畫。 |
| IBM MQ 訊息傳遞 | 使用 IBM MQ 連接器將現有佇列與訊息連接到現代工作流程。 | 佇列管理器、通道、佇列、TLS 及訊息格式需求。 請參見 「連接 IBM MQ」。 |
逐步現代化
大型主機與中型環境通常包含緊密連結的程式、資料、檔案、排程器及外部介面。 單一大規模遷移嘗試在一次協調釋出中替換所選範圍。 這種方法適合規模較小且熟悉的環境，但隨著相依關係數量與專案持續時間的增加，交付與切換風險會增加。
對大多數遺產而言，使用迭代波以維持運作狀態並更早交付價值：
- 庫存計畫、資料、介面、工作、相依關係、服務目標及營運需求。
- 選擇具備明確商業價值與可管理依賴的端對端整合流程。
- 在主機系統仍運作期間，將 Azure Logic Apps Standard 作為整合介面引入。
- 重用相容的元資料並設定所需的內建連接器。
- 測試功能行為、吞吐量、復原、安全性，以及與舊有實作的共存性。
- 引導消費者使用現代化介面並監控生產流程。
- 後續各波次皆重複此作法，且僅在其使用方與相依項目完成遷移後，才淘汰舊介面。
每個波浪可產生一個特徵或相關的整合流群。 共享工作與高度互聯的應用程式可能會持續到後續波次，當較低風險的介面建立可重用的工作流程、安全性、部署及營運模式後。
套用現代化模式
根據目標工作負載使用架構模式，而非將任何一種模式視為強制。
防損毀層模式
考慮使用 Azure Logic Apps Standard 作為舊有介面與現代消費者之間的防損層。 工作流程可以轉換協定、格式與互動模型，而無需消費者理解主機特定細節。 這個外觀模式可以在 Azure 中或靠近託管環境的已啟用 Arc 的 Kubernetes 上執行。
更多資訊請參閱 反腐敗層模式。
絞殺榕模式
使用 Strangler Fig 模式，將選定的介面或能力路由到新的整合層，同時剩餘的工作負載繼續在主機上執行。 逐步替換各項實作，驗證每次切換作業，並且僅在其相依項目完成遷移後，才將舊有元件除役。
如需詳細資訊，請參閱絞殺榕模式。
Saga 和編舞模式
當業務流程跨越無法參與單一分散式交易的系統時，可以使用 Saga 模式。 具狀態的工作流程可以作為中央 Saga 協調器，藉由協調參與者並明確處理重試、失敗和補償動作來發揮作用。 每個參與者執行自己的本地交易。 工作流程動作在群組化時並不會自動具備原子性，且 Azure Logic Apps 也不會自動還原外部系統中的變更。 設計冪性運算，並透過動作、作用域及後置條件來實現補償。
在採用編排式的 saga 中，參與的服務會透過訊息傳遞基礎架構交換事件，而不由中央工作流程協調整個交易。 只有在架構需要獨立訊息傳遞或事件分發時，才可新增 Azure 服務匯流排 或 Azure 事件方格 等服務。 更多資訊請參閱 Saga 分散式交易模式 與 編舞模式。
計畫安全、營運與成本
- 使用私有網路連線及適合主機環境與主機系統的安全認證。 將秘密存放在核准的秘密儲存庫，而非工作流程定義中。
- 將工作流程定義、HIDX 檔案、設定範本及支援程式碼保留在原始碼控制中。 將環境特定的值與可部署的產出物分離，並使用自動化管線。
- 設計時應支援重試與至少一次處理。 使用冪등 性、去重、相關識別碼及安全寫入以防止重複效應。
- 在正式切換至生產環境前，先定義監控、警示、執行歷程保留、災難復原，以及支援責任歸屬。 Azure 託管與混合式部署在監控能力與限制上有所不同。
- 比較主機、連接器使用、網路、儲存、監控及客戶管理基礎設施的總擁有成本。 標準包含內建的操作執行，而管理式連接器操作及支援資源則可增加費用。
有關目前的限制與價格，請參閱 Azure Logic Apps 限制與設定，以及 Azure Logic Apps 定價與計費模型。
現代化情境範例
將 CICS 交易暴露給現代應用程式
建立標準工作流程，透過內建連接器呼叫現有 CICS 程式，轉換回應，並將現代介面回傳給應用程式或 API 層。 在消費者逐漸遠離主機專屬連線時，將 CICS 計畫作為記錄系統。
讓 DB2 資料對分析機構開放
使用標準工作流程從 DB2 讀取核准的營運資料，驗證並轉換紀錄，然後傳送給 Azure 資料或分析服務。 此方法可避免為每個使用方建立獨立的大型主機擷取程式，同時保留對資料何時以及如何離開主機的控管。
在主機系統附近執行整合
當工作流程需要本地處理、資料駐留或低延遲存取 IBM 系統時，可在支援 Azure Arc 的 Kubernetes 上部署 Azure Logic Apps Standard。 內建連接器操作與本地執行時一同運行，而工作流程則可選擇性地連接 Azure 服務，視架構與網路政策允許而定。