共用方式為

使用 Azure Logic Apps 進行大型主機和中階現代化

  • 發行項

本指南說明貴組織如何使用 Azure Logic Apps 將大型主機和中型環境現代化，以提升商業價值和靈活度。 目前的商業界正經歷著一個超創新的時代，並長期尋求獲得企業效率、降低成本、成長和業務一致性。 組織正在尋找現代化的方法，其中一個有效策略是使用現有的舊版資產來增強商業價值。

對於投資大型主機和中階系統的組織，這意味著充分利用過去協助人類登月，或是協助建立目前金融市場的平台，並且利用雲端和人工智慧 (AI) 讓平台價值發揮得淋漓盡致。 此案例是 Azure Logic Apps 及其原生功能與大型主機和中層系統整合，藉由為舊版投資打開 AI 世界的大門來發揮作用。 除了其他功能，Azure Logic Apps 還整合 Host Integration Server (HIS) 的核心功能，該伺服器是 Microsoft 最具策略性客戶的核心，20 多年來用於大型主機和中階整合。 因此，Azure Logic Apps 已成為大型主機和中層系統的整合平臺即服務 （iPaaS）。

企業開發人員使用 Azure Logic Apps 建置整合工作流程時，幾乎不需要程式碼或使用較少的自訂程式碼，即可以更快的速度交付新的應用程式。 使用 Visual Studio 的開發人員比使用 IBM 大型主機開發工具和技術的人更有生產力，因為它們不需要瞭解大型主機系統和基礎結構。 Azure Logic Apps 可讓企業分析師和決策者更快分析及報告重要的舊版資訊。 他們可以直接存取大型主機資料來源的資料，因此不需要為了擷取和轉換複雜的大型主機結構，請大型主機開發人員建立程式。

適用於大型主機和中階系統整合的雲端原生功能

1990 年以來，Microsoft 已透過 Microsoft Communications Server 與大型主機和中階系統整合。 Microsoft Communications Server 在 2000 年更上層樓，建立了 Host Integration Server (HIS)。 HIS 起初作為系統網路架構 (SNA) 閘道，但 HIS 後來經過擴充，整合了 IBM 資料存放區 (DB2、VSAM 和 Informix)、IBM 交易系統 (CICS、IMS 和 IBM i)，以及 IBM 傳訊 (MQ 系列)。 Microsoft 的策略性客戶已使用這些技術超過 20 年。

為了讓在 Azure 上執行應用程式和數據的客戶繼續使用這些技術，Azure Logic Apps 和 Visual Studio 已逐漸納入這些功能。 例如，在 Visual Studio 執行之適用於 Logic Apps 的 HIS 設計工具，以及 3270 設計工具，可協助您建立用於 Azure Logic Apps 大型主機和中階整合之內建連接器所需的中繼資料成品。 這些內建連接器執行時使用的計算資源，與標準邏輯應用程式工作流程相同。 此設計不僅讓您實現低延遲的案例，還能擴充您的觸達範圍，因應更多災害復原和高可用性客戶需求。

顯示大型主機整合Microsoft雲端原生功能的概念圖。

如需 Microsoft 大型主機和中階整合功能的詳細資訊，請繼續閱讀下列各節。

適用於 Logic Apps 的 Microsoft HIS 設計工具

此工具為 Azure Logic Apps 建立大型主機和中階系統中繼資料成品，並提供圖形設計工具與 Microsoft Visual Studio 搭配運作，讓您建立、檢視、編輯中繼資料物件，以及將該物件對應至大型主機成品。 Azure Logic Apps 使用這些對應，鏡像大型主機和中階系統的程式和資料。 如需詳細資訊，請參閱適用於 Logic Apps 的 HIS 設計工具。

Microsoft 3270 設計工具

此工具可記錄應用程式中工作的畫面、瀏覽路徑、方法及參數，以便您以 3270 連接器動作的方式新增及執行那些工作。 雖然適用於 Logic Apps 的 HIS 設計工具是以交易系統和資料為目標，但 3270 設計工具的目標則是 3270 個應用程式。 如需詳細資訊，請參閱 3270 設計工具。

適用於 IBM 大型主機和中階系統的 Azure Logic Apps 連接器

下列各節說明，在 Azure Logic Apps 建立標準工作流程時，可用來存取 IBM 大型主機和中階系統並進行互動的內建服務提供者型連接器。

注意

下列連接器有些可作為在全域 Azure 執行的「共用」連接器，但本指南側重於介紹內建的服務提供者型連接器；這類連接器僅限於在 Azure Logic Apps 建立標準工作流程時才能使用。

IBM 3270

這款適用於 3270 的 Azure Logic Apps 連接器，可讓標準工作流程存取及執行通常透過瀏覽 3270 模擬器畫面驅動的 IBM 大型主機應用程式。 連接器使用 TN3270 串流。 如需詳細資訊，請參閱使用 Azure Logic Apps 和 IBM 3270 連接器，整合 IBM 大型主機上的 3270 畫面控制項驅動應用程式與 Azure。

IBM Customer Information Control System (CICS)

此適用於 CICS 的 Azure Logic Apps 連接器提供標準工作流程，能夠使用多個通訊協定，例如 TCP/IP 和 HTTP，與 CICS 程式互動及整合。 如果您需要使用 LU6.2 存取 CICS 環境，則必須使用 Host Integration Server (HIS)。 如需詳細資訊，請參閱使用 IBM CICS 連接器，將 IBM 大型主機的 CICS 程式與 Azure Logic Apps 中的標準工作流程整合。

IBM DB2

此適用於 DB2 的 Azure Logic Apps 連接器，支援標準工作流程與內部部署或 Azure 的 DB2 資料庫連線。 連接器讓企業 IT 專業人員和開發人員直接存取儲存在 DB2 資料庫管理系統的重要資訊。 如需詳細資訊，請參閱使用 Azure Logic Apps 存取和管理 IBM DB2 資源。

IBM 主機檔案

此適用於主機檔案的 Azure Logic Apps「連接器」，提供 Host Integration Server 「一般檔案剖析器」功能的精簡包裝函式。 這個離線「連接器」提供的作業剖析二進位資料，或是雙向利用主機檔案產生二進位資料。 這些作業需要來自任何觸發程序，或是其他產生二進位資料動作的這項資料。 如需詳細資訊，請參閱使用 Azure Logic Apps 剖析和產生 IBM 主機檔案。

IBM i

此適用於 IBM i 的 Azure Logic Apps 連接器可讓標準工作流程與使用 TCP/IP 在 IBM i 系統上執行的 COBOL 和 RPG 程式互動並整合。 如果您需要使用 LU6.2 存取 IBM i 環境，則必須使用主機整合伺服器 （HIS）。 如需詳細資訊，請參閱 使用 IBM i 連接器在 Azure Logic Apps 中整合 COBOL 和 RPG 程式與標準工作流程。

IBM Information Management System (IMS)

此適用於 IMS 的 Azure Logic Apps 連接器採用 IBM IMS Connect 元件，使用 TCP/IP 為標準工作流程和 IMS 交易提供高效能存取。 此模型使用 IMS 訊息佇列處理資料。 如需詳細資訊，請參閱使用 IBM IMS 連接器，將 IBM 大型主機的 IMS 程式與 Azure Logic Apps 中的標準工作流程整合。

IBM MQ

此適用於 MQ 的 Azure Logic Apps 連接器，支援標準工作流程與內部部署或 Azure 的 IBM MQ 伺服器連線。 Microsoft 也為 Host Integration Server 與 BizTalk Server 提供 IBM MQ 整合功能。 如需詳細資訊，請參閱從 Azure Logic Apps 的工作流程連線至 IBM MQ 伺服器。

大型主機和中層系統現代化的挑戰

大型主機和中層系統可以裝載包含程式、數據、檔案和工具的多個環境。 多年來，儘管硬體升級，這些環境可能尚未重構或保留成長並達到其限制。 這些環境也可能由多個開發人員和IT系統管理員維護，這些開發人員和IT系統管理員遵循不同的程序設計模式和技術，或招募其他合作對象來協助處理需要市場上專業知識的工作。 除了經驗豐富的專業人員的縮減集區外，所有這些因素都為現代化大型主機和中層環境創造了複雜而具有挑戰性的工作。

雖然下列清單並不全面，但定義成功的現代化策略幾乎包括處理下列工作的方式：

  • 維持環境當前的服務等級指標和目標。
  • 管理舊版資料與移轉資料共存的情形。
  • 在共存期間跨環境執行DevOps。
  • 管理應用程式相依性。
  • 定義大型主機排程器和作業的未來。
  • 定義取代商規品 (COTS) 產品的策略。
  • 執行混合式功能和非功能性測試活動。
  • 維護外部相依性或介面。

考慮到這些工作，客戶通常會選擇下列任一路徑來執行大型主機和中層系統現代化：

  • 大爆炸

    此方法主要以瀑布式軟體傳遞模型為基礎，但分階段處理反覆項目。 由於程式代碼行數低、應用程式密度低，以及已知的舊版系統或程式設計語言，小型大型主機或中層系統的客戶會採用大爆炸方法。

  • 敏捷式波浪

    此方法遵循軟體工程的敏捷式原則。 由於大量程式代碼、高應用密度、較不知名的系統或程式設計語言，以及大量的相依性和介面，因此採用敏捷式波浪方法的客戶會採用更多方法，以及大量的相依性與介面。

這些途徑的選擇取決於貴組織的需求和案例。 每個途徑都有需要考慮的優點和缺點。 下列各節提供這些現代化方式的詳細資訊。

大爆炸或瀑布

大爆炸式移轉通常分為下列階段：

顯示大爆炸移轉階段方法的概念圖。

  1. 構想：啟動

  2. 規劃：識別和準備規劃交付專案，例如範圍、時間和資源。

  3. 建置：規劃交付項目核准後開始

    此階段應該也已識別出相依性的所有工作，然後移轉活動就可以開始。 為完成移轉工作，發生多項反覆項目。

  4. 穩定或測試：移轉的環境、相依性和應用程式針對大型主機環境中的測試區域進行測試時展開。

  5. 部署：全面核准之後，移轉隨即在實際執行環境進行。

選擇此方法的組織通常著重於鎖定時間、移轉範圍和資源。 此途徑似乎是積極的選擇，但包含下列風險：

  • 移轉可能需要數月甚至數年的時間。

  • 對生產環境的部署風險更大。

  • 您在移轉過程之初或是規劃期間執行的分析已失準，因為該資訊通常已過時。

  • 組織通常側重擁有完整的文件，以減少交付項目的傳遞風險。

    不過，提供規劃成品所花的時間確實會產生反效果。 側重於規劃往往比執行容易產生執行延遲，進而導致長期成本增加。

敏捷式波浪

敏捷式方法屬於結果導向，側重於建置軟體，而非規劃交付項目。 敏捷式傳遞的第一個階段對於需要分解和配合移轉小組的組織障礙而言，可能會混亂且複雜。 不過，在移轉小組在經過數次短期衝刺執行之後成熟之後，旅程會變得更順暢。 這種方法的目標是要經常將功能發行至生產環境，並比大爆炸方法更快提供商業價值。

敏捷式波浪移轉通常分為下列階段：

顯示使用敏捷式波浪方法進行大型主機移轉的概念圖。

  • 短期衝刺零 (0)

    • 定義小組、初始工作待辦項目和核心相依性。
    • 識別要交付的功能和最低可行產品 (MVP)。
    • 透過一組選定的工作項目或使用者劇本開始工作，展開大型主機整備。

  • 短期衝刺 1、2 至 N

    每個短期衝刺都設有目標，小組抱持出貨的心態工作，也就是說他們側重於完成移轉目標，並將交付項目發佈至實際執行環境。 小組可以用一組短期衝刺，提供特定功能或一波功能。 每項功能都包含整合工作負載的配量。

顯示大型主機移轉與每個數據流敏捷式波浪的概念圖。

共用元素，例如作業和相互依存性，存在於整個環境，而且會造成影響。 成功的策略側重於部分啟用作業、重新設計現代化應用程式，以及讓相依性最多的系統留到最後，先減少移轉工作量，然後再完成現代化投入量的範圍。

Microsoft建議遵循反覆、敏捷式的波浪式模型，專注於新平臺的投資，同時限制舊版系統的成長，將大型主機和中型系統工作負載現代化。 這種方法可藉由保留現有的商業價值，同時引進現代化環境，大幅降低實作風險。 如此一來，您的小組也可以利用技術技能，協助企業更具競爭力。 此案例是 Azure Logic Apps 可協助您進行現代化旅程的地方。

現代化模式

良好設計包含各項要素，例如元件設計和部署的一致性及連貫性、簡化管理及開發的可維護性，以及可讓其他應用程式和案例重複使用元件和子系統的重複使用性。 針對雲端託管的應用程式和服務，設計和實作階段所做的決策，對於擁有權總成本的影響很大。

Azure 架構中心提供經過測試的設計和實作模式，描述了其所解決的問題、套用模式的考慮事項，以及以 Microsoft Azure 為基礎的範例。 雖然存在多個設計和實作模式，但大型主機現代化最相關的幾個模式包括「防損毀層」、「扼制圖」、「Saga」和「編排」模式。

防損毀層模式

無論您選取何種現代化方法，都需要使用 Azure Logic Apps 實作「防損毀層」。 此服務會成為大型主機舊版系統與 Azure 之間的表面或配接器層。 若要讓方法發揮效果，請識別要整合或共存為大型主機整合工作負載的大型主機工作負載。 為每個整合工作負載建立策略，也就是移轉大型主機應用程式所需的一組介面。

顯示反損毀層模式的概念圖。

如需詳細資訊，請參閱防損毀層。

扼制圖模式

實作防損毀層之後，現代化便逐漸發生。 在這個階段，您必須使用「扼制圖」模式」，藉此識別可以用遞增方式現代化的大型主機工作負載或功能。 例如，如果您選擇將 CICS 應用程式現代化，您不僅要將 CICS 程式現代化，而且最有可能也要將 3270 應用程式及其對應的外部相依性、資料和作業現代化。

最後，以新系統取代大型主機系統中的所有工作負載或功能之後，移轉流程隨即完成，也就是說您可以解除舊版系統。

顯示 Strangler Fig 模式的概念圖。

如需詳細資訊，請參閱扼制圖模式。

Saga 和編排模式

分散式交易，例如兩階段交易認可 (2PC) 通訊協定，要求交易中的所有參與者在交易可以繼續進行之前認可或復原。 雲端混合式架構在最終一致性範例之後執行，效果比在分散式交易模型之後執行更好。

「Saga」設計模式是管理分散式交易案例服務間一致性的方法。 Saga 是一連串的交易，會更新每項服務並發佈訊息或事件，觸發下一個交易步驟。 如果步驟失敗，Saga 會執行補償交易，抵消前述交易。 如需詳細資訊，請參閱 Saga 分散式交易模式。

在 Azure Logic Apps 中，工作流程形同協調 Saga 的編排者。 工作流程動作不可部分完成，因此您可以個別重新執行動作。 範圍動作類型能夠在另一組動作成功或失敗之後才執行一組動作。 Azure Logic Apps 在範圍層級進行補償交易，而 Azure 事件方格和 Azure 服務匯流排則提供特定網域所需的事件管理。 組成 Azure 整合服務的所有這些服務，都會在客戶針對任務關鍵案例需要可靠整合平台時，提供所需的支援。 如需詳細資訊，請參閱編排模式。

顯示 SAGA 模式的概念圖。

本文涵蓋數種現代化模式，但複雜的解決方案需要更多模式，而且您必須對組織的現代化目標一清二楚。 雖然延伸舊版資產價值的工作挑戰性高，但此選項是保留這些資產投資並延長其商業價值的最佳方式。

下一步