共用方式為


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

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

對於投資大型主機和中層系統的組織,這表示充分利用平臺,協助人類前往月球,或協助建立目前的金融市場,並使用雲端和人工智慧(AI)擴充其價值。 此案例是 Azure Logic Apps 及其原生功能與大型主機和中層系統整合,藉由為舊版投資打開 AI 世界的大門來發揮作用。 除了其他功能外,Azure Logic Apps 還納入主機整合伺服器的核心功能,該伺服器已用於大型主機和中型整合,這是 Microsoft 20 多年來最具策略性客戶的核心。 因此,Azure Logic Apps 已成為大型主機和中層系統的整合平臺即服務 (iPaaS)。

當企業開發人員使用 Azure Logic Apps 建置整合工作流程時,他們可以使用幾乎不需要程式代碼或更少的自定義程式代碼,更快速地提供新的應用程式。 使用 Visual Studio Code 和 Visual Studio 的開發人員可以比使用 IBM 大型主機開發工具和技術的人更有生產力,因為它們不需要瞭解大型主機系統和基礎結構。 Azure Logic Apps 可讓商務分析師和決策者更快速地分析和報告重要的舊版資訊。 他們可以直接存取大型主機數據源中的數據,而不需要讓大型主機開發人員建立程式來擷取和轉換複雜的大型主機結構。

大型主機和中層系統整合的雲端原生功能

自 1990 年以來,Microsoft 已透過 Microsoft Communications Server 與大型主機和中範圍系統整合。 Microsoft Communications Server 在 2000 年建立了主機整合伺服器 (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 中大型主機和中層整合的內建連接器所需的元數據成品。 這些內建連接器會使用與標準邏輯應用程式工作流程相同的計算資源來執行。 此設計不僅可讓您達到低延遲的案例,還能擴充您的觸達範圍,以解決更多災害復原和高可用性客戶需求。

Conceptual diagram showing Microsoft cloud native capabilities for mainframe integration.

如需 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 客戶資訊控制系統 (CICS)

此適用於 CICS 的 Azure Logic Apps 連接器提供標準工作流程,能夠使用多個通訊協定,例如 TCP/IP 和 HTTP,與 CICS 程式互動和整合。 如果您需要使用 LU6.2 存取 CICS 環境,則必須使用主機整合伺服器 (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「連接器」提供主機整合伺服器中「一般檔案剖析器」功能的精簡包裝函式。 這個離線的「連接器」提供可剖析或從主機檔案產生二進位數據的作業。 這些作業需要此數據來自任何觸發程式或其他產生二進位數據的動作。 如需詳細資訊,請參閱 使用 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 資訊管理系統 (IMS)

此適用於 IMS 的 Azure Logic Apps 連接器會使用 IBM IMS 連線 元件,透過 TCP/IP 從標準工作流程到 IMS 交易提供高效能存取。 此模型會使用IMS消息佇列來處理數據。 如需詳細資訊,請參閱 使用 IBM IMS 連接器在 Azure Logic Apps 中整合 IBM 大型主機上的 IMS 程式與標準工作流程。

IBM MQ

此適用於 MQ 的 Azure Logic Apps 連接器可讓標準工作流程與內部部署或 Azure 中的 IBM MQ 伺服器之間的連線。 Microsoft 也提供 IBM MQ 整合功能與主機整合伺服器和 BizTalk Server。 如需詳細資訊,請參閱從 Azure Logic Apps 中的工作流程 連線 IBM MQ 伺服器。

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

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

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

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

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

  • 大爆炸

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

  • 敏捷式波浪

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

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

大爆炸或瀑布

大爆炸式移轉通常具有下列階段:

Conceptual diagram showing big bang migration phases approach.

  1. 構想:啟動

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

  3. 建置:規劃交付專案核准後開始

    此階段也預期已識別相依性的所有工作,然後移轉活動就可以開始。 發生多次反覆專案以完成移轉工作。

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

  5. 部署:在核准所有項目之後,移轉會實時進入生產環境。

通常選擇此方法的組織著重於鎖定時間、移轉範圍和資源。 此路徑聽起來像是積極的選擇,但包含下列風險:

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

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

  • 您在移轉旅程開始時或規劃期間執行的分析已不再準確,因為該資訊通常已過時。

  • 組織通常會專注於擁有完整的檔,以減少傳遞的傳遞風險。

    不過,提供規劃成品所花費的時間確實會產生相反的效果。 專注於規劃比執行更傾向於建立執行延遲,這會導致長期成本增加。

敏捷式波浪

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

敏捷式波浪移轉通常具有下列短期衝刺:

Conceptual diagram showing mainframe migration with Agile waves approach.

  • 衝刺零 (0)

    • 定義小組、初始工作待辦專案和核心相依性。
    • 識別要傳遞的功能和最低可行產品 (MVP)。
    • 使用一組選取的工作專案或使用者劇本開始工作,開始大型主機整備。
  • Sprint 1, 2, ..., N

    每個短期衝刺都有一個目標,小組會保持出貨心態,這表示他們專注於完成移轉目標,並將交付專案發行至生產環境。 小組可以使用一組短期衝刺來提供特定功能或一波功能。 每個功能都包含整合工作負載的配量。

Conceptual diagram showing mainframe migration with Agile waves per streams.

共用元素,例如作業和相互依存性,存在於整個環境中併產生影響。 成功的策略著重於部分啟用作業、重新設計現代化應用程式,以及讓系統與最相依性,直到最後減少移轉工作量,然後完成現代化工作的範圍。

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

現代化模式

良好的設計包括元件設計和部署中的一致性和一致性、簡化管理和開發的維護性,以及允許其他應用程式和案例重複使用元件和子系統的重複使用性等因素。 針對雲端裝載的應用程式和服務,在設計和實作階段做出的決策會對品質和總擁有成本產生巨大影響。

Azure 架構中心提供經過測試 的設計和實作模式 ,描述其所解決的問題、套用模式的考慮,以及以 Microsoft Azure 為基礎的範例。 雖然有多個設計和實作模式存在,但大型主機現代化的一些最相關的模式包括“反腐層”、“Strangler Fig”、“Saga” 和 “Choreography” 模式。

反損毀層模式

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

Conceptual diagram showing the Anti-corruption Layer pattern.

如需詳細資訊,請參閱 反損毀層

Strangler Fig 圖樣

在實作反損毀層之後,現代化會逐漸發生。 在這個階段中,您必須使用「階層圖」模式,您可以在其中識別可以累加現代化的大型主機工作負載或功能。 例如,如果您選擇將 CICS 應用程式現代化,您不僅必須現代化 CICS 程式,而且最有可能是 3270 應用程式及其對應的外部相依性、數據和作業。

最後,在您以新的系統取代大型主機系統中的所有工作負載或功能之後,您將完成移轉程式,這表示您可以解除委任舊版系統。

Conceptual diagram showing the Strangler Fig pattern.

如需詳細資訊,請參閱 Strangler Fig 模式

傳奇和編舞模式

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

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

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

Conceptual diagram showing the SAGA pattern.

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

下一步