Sdílet prostřednictvím


Modernizace sálového a středního uspořádání s využitím Azure Logic Apps

Tato příručka popisuje, jak může vaše organizace zvýšit obchodní hodnotu a flexibilitu díky modernizaci sálových a středně uspořádaných prostředí pomocí Azure Logic Apps. Současný obchodní svět má éru hyper-inovací a je na trvalém úkolu získat efektivitu podniku, snížení nákladů, růst a obchodní sladění. Organizace hledají způsoby modernizace a jednou efektivní strategií je rozšířit obchodní hodnotu při používání stávajících starších prostředků.

Pro organizace s investicemi do sálových a středních systémů to znamená, že nejlepší využití platforem, které pomohly posílat lidi na měsíc, nebo pomáhaly vytvářet aktuální finanční trhy a rozšiřovat jejich hodnotu pomocí cloudu a umělé inteligence (AI). V tomto scénáři přichází do hry Azure Logic Apps a její nativní funkce pro integraci se sálovými a středními systémy, a to otevřením dveří do světa AI pro starší investice. Kromě dalších funkcí azure Logic Apps zahrnuje základní funkce hostitelského integračního serveru (HIS), které se používaly pro sálový počítač a střední integraci v jádru nejstrategických zákazníků Microsoftu za více než 20 let. V důsledku toho se Azure Logic Apps stala integrační platformou jako službou (iPaaS) pro sálové a střední systémy.

Když podnikoví vývojáři vytvářejí pracovní postupy integrace s Azure Logic Apps, můžou rychleji dodávat nové aplikace bez použití kódu nebo méně vlastního kódu. Vývojáři, kteří používají Visual Studio Code a Visual Studio, mohou být produktivnější než vývojáři, kteří používají vývojové nástroje a technologie IBM, protože nevyžadují znalosti o sálových systémech a infrastruktuře. Azure Logic Apps umožňuje obchodním analytikům a zaměstnancům s rozhodovací pravomocí rychleji analyzovat a hlásit důležité starší informace. Mají přímý přístup k datům v mainframových zdrojích dat, což eliminuje nutnost, aby vývojáři sálových počítačů vytvářeli programy, které extrahují a převádějí složité struktury sálových počítačů.

Nativní cloudové funkce pro integraci sálového a středního systému

Od roku 1990 microsoft poskytuje integraci se sálovými a středními systémy prostřednictvím Microsoft Communications Serveru. Další vývoj systému Microsoft Communications Server vytvořil server SSIS (Host Integration Server) v roce 2000. Zatímco HIS začal jako brána SNA (System Network Architecture), his rozšířil, aby zahrnoval úložiště dat IBM (DB2, VSAM a Informix), transakční systémy IBM (CICS, IMS a IBM i) a zasílání zpráv IBM (MQ Series). Strategické zákazníky Microsoftu tyto technologie používaly více než 20 let.

Aby zákazníci, kteří spouštějí aplikace a data v Azure, mohli tyto technologie dál používat, postupně tyto funkce začlenily azure Logic Apps a Visual Studio. Například HIS Designer for Logic Apps, který běží v sadě Visual Studio, a nástroj pro návrh 3270 vám pomůže vytvářet artefakty metadat vyžadované integrovanými konektory, které používáte pro integraci mainframů a středních uspořádání v Azure Logic Apps. Tyto integrované konektory běží pomocí stejných výpočetních prostředků jako pracovní postupy standardní aplikace logiky. Tento návrh umožňuje nejen dosáhnout scénářů s nízkou latencí, ale také rozšiřuje dosah, aby se vyřešilo více potřeb zákazníků pro zotavení po havárii a vysokou dostupnost.

Conceptual diagram showing Microsoft cloud native capabilities for mainframe integration.

Další informace o možnostech microsoftu pro integraci sálového a středního uspořádání najdete v následujících částech.

Microsoft HIS Designer for Logic Apps

Tento nástroj vytvoří artefakty metadat systému a střední struktury pro Azure Logic Apps a pracuje s Microsoft Visual Studio tím, že poskytuje grafického návrháře, který umožňuje vytvářet, zobrazovat, upravovat a mapovat objekty metadat na artefakty mainframů. Azure Logic Apps tyto mapy používá k zrcadlení programů a dat v sálových a středních systémech. Další informace najdete v tématu HIS Designer pro Logic Apps.

Microsoft 3270 Design Tool

Tento nástroj zaznamenává obrazovky, navigační cesty, metody a parametry pro úlohy v aplikaci, abyste je mohli přidat a spustit jako akce konektoru 3270. Zatímco HIS Designer pro Logic Apps cílí na transakční systémy a data, 3270 Design Tool cílí na 3270 aplikací. Další informace naleznete v tématu 3270 Návrh nástroj.

Konektory Azure Logic Apps pro sálové a střední systémy IBM

Následující části popisují integrované konektory založené na poskytovatelích služeb, které můžete použít pro přístup k sálovým počítačům IBM a systémům středního uspořádání při vytváření standardních pracovních postupů v Azure Logic Apps a jejich interakci.

Poznámka:

Některé z následujících konektorů jsou sice k dispozici jako "sdílené" konektory, které běží v globálním Azure, ale tato příručka se zaměřuje na integrované konektory založené na poskytovatelích služeb, které jsou dostupné jenom při vytváření standardních pracovních postupů v Azure Logic Apps.

IBM 3270

Tento konektor Azure Logic Apps pro verzi 3270 umožňuje standardním pracovním postupům přístup k mainframovým aplikacím IBM, které obvykle řídíte procházením 3270 obrazovek emulátoru. Konektor používá stream TN3270. Další informace najdete v tématu Integrace aplikací 3270 řízených obrazovkami do sálových počítačů IBM s Azure pomocí konektoru Azure Logic Apps a IBM 3270.

IBM Customer Information Control System (CICS)

Tento konektor Azure Logic Apps pro CICS poskytuje standardní pracovní postupy s možností interakce a integrace s programy CICS pomocí více protokolů, jako je TCP/IP a HTTP. Pokud potřebujete přistupovat k prostředím CICS pomocí LU6.2, musíte použít hostitelský integrační server (HIS). Další informace najdete v tématu Integrace programů CICS v sálových počítačích IBM s pracovními postupy Standard v Azure Logic Apps pomocí konektoru IBM CICS.

IBM DB2

Tento konektor Azure Logic Apps pro DB2 umožňuje připojení mezi standardními pracovními postupy a databázemi DB2, které jsou buď místně, nebo v Azure. Konektor nabízí podnikovým IT odborníkům a vývojářům přímý přístup k důležitým informacím uloženým v systémech pro správu databází DB2. Další informace najdete v tématu Přístup a správa prostředků IBM DB2 pomocí Azure Logic Apps.

Hostitelské soubory IBM

Tento konektor Azure Logic Apps pro hostitelské soubory poskytuje tenkou obálku kolem funkce "Plochá analýza souborů" na hostitelském integračním serveru. Tento offline konektor poskytuje operace, které analyzují nebo generují binární data do a ze souborů hostitelů. Tyto operace vyžadují, aby tato data pocházejí z jakékoli aktivační události nebo jiné akce, která vytváří binární data. Další informace najdete v tématu Analýza a generování souborů hostitelů IBM pomocí Azure Logic Apps.

IBM i

Tento konektor Azure Logic Apps pro IBM i umožňuje standardním pracovním postupům pracovat a integrovat je s programy COBOL a RPG běžícími na systémech IBM i pomocí protokolu TCP/IP. Pokud potřebujete přistupovat k prostředím IBM i pomocí LU6.2, musíte použít server SSIS (Host Integration Server). Další informace naleznete v tématu Integrace programů COBOL a RPG v ibm midranges s pracovními postupy Standard v Azure Logic Apps pomocí konektoru IBM i.

IBM Information Management System (IMS)

Tento konektor Azure Logic Apps pro IMS používá komponentu IBM IMS Připojení, která poskytuje vysoký přístup ze standardních pracovních postupů k transakcím IMS pomocí protokolu TCP/IP. Tento model používá frontu zpráv IMS ke zpracování dat. Další informace najdete v tématu Integrace programů IMS v sálových počítačích IBM s pracovními postupy Standard v Azure Logic Apps pomocí konektoru IBM IMS.

IBM MQ V8.0.0.1

Tento konektor Azure Logic Apps pro MQ umožňuje připojení mezi standardními pracovními postupy a servery IBM MQ místně nebo v Azure. Microsoft také poskytuje možnosti integrace IBM MQ s hostitelským integračním serverem a BizTalk Serverem. Další informace najdete v tématu Připojení k serveru IBM MQ z pracovního postupu v Azure Logic Apps.

Výzvy pro modernizaci sálových a středně velkých systémů

Sálové a střední systémy můžou hostovat více prostředí, která obsahují programy, data, soubory a nástroje. V průběhu let se tato prostředí nemusela refaktorovat nebo byla ponechána na růstu a dosažení jejich limitů, a to i přes upgrady hardwaru. Tato prostředí mohou být také udržována několika vývojáři a správci IT, kteří sledují různé programovací vzory a techniky nebo najali jiné strany, aby pomohli s úlohami, které vyžadují nedostatek odborných znalostí na trhu. Spolu se zmenšujícím fondem zkušených odborníků vytvářejí všechny tyto faktory složitou a náročnou práci s modernizací sálových počítačů a středně složitých prostředí.

I když následující seznam není vyčerpávající, definování úspěšné strategie modernizace minimálně zahrnuje způsoby, jak zvládnout následující úlohy:

  • Udržujte aktuální indikátory a cíle úrovně služeb pro vaše prostředí.
  • Umožňuje spravovat koexistence mezi staršími daty spolu s migrovanými daty.
  • Provádění DevOps napříč prostředími během koexistence
  • Správa závislostí aplikací
  • Definujte budoucnost plánovače a úloh sálového počítače.
  • Definujte strategii pro nahrazení komerčních produktů mimo police (COTS).
  • Provádění hybridních funkčních a nefunkčních testovacích aktivit
  • Udržujte externí závislosti nebo rozhraní.

S ohledem na tyto úlohy si zákazníci obvykle vyberou některou z následujících cest k provedení modernizace sálových a středně velkých systémů:

  • Velký třesk

    Tento přístup je z velké části založený na modelu doručování vodopádového softwaru, ale s iteracemi ve fázích. Přístup velkého třesku je přijat více zákazníky s malými sálovými nebo středními systémy a prostředími s nízkou složitostí z důvodu nízkého počtu řádků kódu, nízké hustoty aplikací a známých starších systémů nebo programovacích jazyků.

  • Agilní vlny

    Tento přístup se řídí principy agilního softwarového inženýrství. Přístup k agilním vlnám používají zákazníci s většími sálovými nebo středními systémy a prostředími s vysokou složitostí z důvodu vysokého počtu řádků kódu, vysoké hustoty aplikací, méně známých systémů nebo programovacích jazyků a vysokého počtu závislostí a rozhraní.

Volba mezi těmito cestami závisí na potřebách a scénářích vaší organizace. Každá cesta má výhody a nevýhody, které je potřeba vzít v úvahu. Následující části obsahují další informace o těchto přístupech k modernizaci.

Velký třesk nebo vodopád

Migrace velkého třesku má obvykle následující fáze:

Conceptual diagram showing big bang migration phases approach.

  1. Představování: Zahájení

  2. Plánování: Identifikace a příprava dodávek, jako je rozsah, čas a zdroje

  3. Budova: Začíná po schválení dodávky

    Tato fáze také očekává, že byla zjištěna veškerá práce pro závislosti a pak se můžou zahájit aktivity migrace. K dokončení migrace dochází k několika iteracím.

  4. Stabilizování nebo testování: Začíná, když se migrované prostředí, závislosti a aplikace testují v testovacích oblastech v prostředí sálového počítače.

  5. Nasazení: Po schválení všeho se migrace přesune do produkčního prostředí.

Organizace, které tento přístup obvykle volí, se zaměřují na uzamykání času, rozsahu migrace a prostředků. Tato cesta zní jako pozitivní volba, ale zahrnuje následující rizika:

  • Migrace můžou trvat měsíce nebo dokonce roky.

  • Nasazení do produkčního prostředí jsou riziknější.

  • Analýza, kterou provedete na začátku cesty migrace nebo během plánování, už není přesná, protože tyto informace jsou obvykle zastaralé.

  • Organizace se obvykle zaměřují na komplexní dokumentaci ke snížení rizik doručování.

    Čas strávený poskytováním artefaktů plánování však způsobuje přesně opačný účinek. Zaměření na plánování více než provádění obvykle vytváří zpoždění provádění, což způsobuje vyšší náklady v dlouhodobém horizontu.

Agilní vlny

Agilní přístup je orientovaný na výsledky a zaměřuje se na vytváření softwaru a neplánuje dodávky. První fáze agilního doručování můžou být pro organizační bariéry, které je potřeba rozdělit a sladit tým migrace, chaotický a složitý. Jakmile ale migrační tým zralý po několika sprintech provádění, bude cesta plynulejší. Cílem tohoto přístupu je často vydávat funkce do produkčního prostředí a poskytovat obchodní hodnotu dříve než s velkým třeskem.

Migrace agilních vln obvykle zahrnuje následující sprinty:

Conceptual diagram showing mainframe migration with Agile waves approach.

  • Sprint nula (0)

    • Definujte tým, backlog počáteční práce a základní závislosti.
    • Identifikujte funkce a minimální realizovatelný produkt (MVP) k poskytování.
    • Zahájení připravenosti sálového počítače s vybranou sadou pracovních položek nebo uživatelských scénářů pro zahájení práce
  • Sprint 1, 2, ..., N

    Každý sprint má cíl, ve kterém tým udržuje přepravní myšlení, což znamená, že se soustředí na dokončení cílů migrace a uvolnění dodávek do produkčního prostředí. Tým může k doručení konkrétní funkce nebo vlny funkcí použít skupinu sprintů. Každá funkce zahrnuje řezy úloh integrace.

Conceptual diagram showing mainframe migration with Agile waves per streams.

Sdílené prvky, jako jsou úlohy a vzájemné závislosti, existují a mají vliv na celé prostředí. Úspěšná strategie se zaměřuje na částečné povolení úloh, přepracovávání aplikací pro modernizaci a ponechání systémů s největší závislostí až do konce, aby se nejprve snížil objem práce migrace a pak dokončil rozsah modernizačního úsilí.

Microsoft doporučuje modernizovat sálové a střední systémové úlohy pomocí iterativního a agilního modelu založeného na vlnách tím, že se zaměřuje na investice do nové platformy a zároveň omezuje růst starších systémů. Tento přístup výrazně snižuje rizika implementace tím, že zachovává stávající obchodní hodnotu a zároveň zavádí modernizované prostředí. Díky tomu může váš tým využít také technologické dovednosti, které vaší firmě pomůžou být konkurenceschopnější. V tomto scénáři vám azure Logic Apps může pomoct při modernizaci.

Vzory modernizace

Dobrý návrh zahrnuje faktory, jako je konzistence a soudržnost v návrhu a nasazení součástí, udržovatelnost pro zjednodušení správy a vývoje a opakované použití, které umožňuje dalším aplikacím a scénářům opakovaně používat komponenty a subsystémy. U aplikací a služeb hostovaných v cloudu mají rozhodnutí přijatá během fáze návrhu a implementace obrovský dopad na kvalitu a celkové náklady na vlastnictví.

Centrum architektury Azure poskytuje otestované vzory návrhu a implementace, které popisují problém, který řeší, důležité informace o použití vzoru a příklad založený na Microsoft Azure. I když existuje více vzorů návrhu a implementace, některé z nejrelevantnějších vzorů pro modernizaci sálových počítačů zahrnují vzory "Anti-corruption Layer", "Strangler Fig", "Saga" a "Telemetrie".

Vzor vrstvy proti poškození

Bez ohledu na to, který přístup k modernizaci vyberete, musíte implementovat vrstvu proti poškození pomocí Azure Logic Apps. Tato služba se stane vrstvou fasády nebo adaptéru mezi starší verzí sálového počítače a Azure. Pro efektivní přístup identifikujte úlohy mainframů, které se mají integrovat nebo spoluexistovat jako úlohy integrace sálového počítače. Vytvořte strategii pro každou úlohu integrace, což je sada rozhraní, která potřebujete povolit pro migraci mainframové aplikace.

Conceptual diagram showing the Anti-corruption Layer pattern.

Další informace naleznete v tématu Vrstva proti poškození.

Strangler Fig pattern

Po implementaci vrstvy proti poškození dojde k postupné modernizaci. V této fázi musíte použít vzor Strangler Fig, kde identifikujete úlohy nebo funkce sálového počítače, které můžete postupně modernizovat. Pokud se například rozhodnete modernizovat aplikaci CICS, musíte modernizovat nejen programy CICS, ale s největší pravděpodobností i aplikace 3270 spolu s odpovídajícími externími závislostmi, daty a úlohami.

Nakonec po nahrazení všech úloh nebo funkcí v systému sálových počítačů novým systémem dokončíte proces migrace, což znamená, že starší systém můžete vyřadit z provozu.

Conceptual diagram showing the Strangler Fig pattern.

Další informace naleznete v tématu Strangler Fig pattern.

Saga a telemetrie vzory

Distribuované transakce, jako je dvoufázové potvrzení (2PC), vyžadují, aby všichni účastníci transakce potvrzení nebo vrácení zpět, než transakce může pokračovat. Cloudové hybridní architektury fungují lépe po paradigmatu konečné konzistence místo distribuovaného transakčního modelu.

Vzor návrhu "Saga" je způsob, jak spravovat konzistenci napříč službami ve scénářích distribuovaných transakcí. Saga je posloupnost transakcí, které aktualizují každou službu a publikují zprávu nebo událost pro aktivaci dalšího kroku transakce. Pokud krok selže, sága provede kompenzační transakce, které brání předchozím transakcím. Další informace naleznete v tématu Model distribuovaných transakcí Saga.

V Azure Logic Apps můžou pracovní postupy fungovat jako tanečníci ke koordinaci ság. Akce pracovního postupu jsou atomické, takže je můžete znovu spustit jednotlivě. Typ akce Rozsah poskytuje možnost spustit skupinu akcí až po úspěšném nebo neúspěšné jiné skupině akcí. Azure Logic Apps provádí kompenzační transakce na úrovni oboru, zatímco Azure Event Grid a Azure Service Bus poskytují správu událostí vyžadovanou pro konkrétní domény. Všechny tyto služby, které tvoří Integrační služby Azure, poskytují podporu vyžadovanou zákazníky, když potřebují spolehlivou integrační platformu pro klíčové scénáře. Další informace naleznete v tématu Model hierarchie.

Conceptual diagram showing the SAGA pattern.

I když tento článek popisuje několik vzorů modernizace, složitá řešení vyžadují mnoho dalších vzorů a jasně rozumíte cílům modernizace vaší organizace. I když je úkol rozšířit hodnotu starších aktiv náročné, je tato možnost nejlepším způsobem, jak zachovat investice do těchto aktiv a prodloužit jejich obchodní hodnotu.

Další kroky