Stordator och mellanregistermodernisering med Azure Logic Apps

Artikel
03/10/2024

Den här guiden beskriver hur din organisation kan öka affärsvärdet och flexibiliteten genom att modernisera din stordator och mellanregistermiljöer med hjälp av Azure Logic Apps. Den nuvarande affärsvärlden upplever en era av hyperinnovation och är på en permanent strävan att få företagseffektivitet, kostnadsminskning, tillväxt och affärsanpassning. Organisationer letar efter sätt att modernisera och en effektiv strategi är att öka affärsvärdet samtidigt som befintliga äldre tillgångar används.

För organisationer med investeringar i stordator- och mellanregistersystem innebär det att man använder plattformar som hjälper till att skicka människor till månen eller hjälpte till att bygga nuvarande finansmarknader och utöka deras värde med hjälp av molnet och artificiell intelligens (AI). Det här scenariot är där Azure Logic Apps och dess inbyggda funktioner för integrering med stordator- och mellanregistersystem spelar in genom att öppna dörren till AI-världen för äldre investeringar. Bland andra funktioner innehåller Azure Logic Apps kärnfunktionerna i Host Integration Server (HIS), som har använts för stordator- och mellanregisterintegrering i kärnan av Microsofts mest strategiska kunder över 20 år. Därför har Azure Logic Apps blivit en integrationsplattform som en tjänst (iPaaS) för stordator- och mellanregistersystem.

När företagsutvecklare skapar integreringsarbetsflöden med Azure Logic Apps kan de snabbare leverera nya program med lite eller ingen kod eller mindre anpassad kod. Utvecklare som använder Visual Studio Code och Visual Studio kan vara mer produktiva än de som använder IBM-utvecklingsverktyg och -tekniker för stordatorer eftersom de inte behöver kunskap om stordatorsystem och infrastruktur. Med Azure Logic Apps kan affärsanalytiker och beslutsfattare snabbare analysera och rapportera viktig äldre information. De kan komma åt data direkt i stordatordatakällor, vilket tar bort behovet av att låta stordatorutvecklare skapa program som extraherar och konverterar komplexa stordatorstrukturer.

Molnbaserade funktioner för stordator- och mellanregistersystemintegrering

Sedan 1990 har Microsoft tillhandahållit integrering med stordator- och mellanregistersystem via Microsoft Communications Server. Ytterligare utveckling av Microsoft Communications Server skapade Host Integration Server (HIS) år 2000. Medan HIS började som en SNA-gateway (System Network Architecture) expanderade HIS till att omfatta IBM-datalager (DB2, VSAM och Informix), IBM-transaktionssystem (CICS, IMS och IBM i) och IBM-meddelanden (MQ Series). Microsofts strategiska kunder har använt dessa tekniker i mer än 20 år.

För att ge kunder som kör program och data i Azure möjlighet att fortsätta använda dessa tekniker har Azure Logic Apps och Visual Studio gradvis införlivat dessa funktioner. His Designer for Logic Apps som körs i Visual Studio och designverktyget 3270 hjälper dig till exempel att skapa metadataartefakter som krävs av de inbyggda anslutningsappar som du använder för stordator- och mellanregisterintegrering i Azure Logic Apps. Dessa inbyggda anslutningsappar körs med samma beräkningsresurser som standardarbetsflöden för logikappar. Med den här designen kan du inte bara uppnå scenarier med låg svarstid, utan även utöka din räckvidd för att hantera mer haveriberedskap och kundbehov med hög tillgänglighet.

Mer information om Microsofts funktioner för stordator- och mellanregisterintegrering finns i följande avsnitt.

Microsoft HIS Designer för Logic Apps

Det här verktyget skapar metadataartefakter för stordatorer och mellanregister för Azure Logic Apps och fungerar med Microsoft Visual Studio genom att tillhandahålla en grafisk designer så att du kan skapa, visa, redigera och mappa metadataobjekt till stordatorartefakter. Azure Logic Apps använder dessa kartor för att spegla program och data i stordator- och mellanregistersystem. Mer information finns i HIS Designer för Logic Apps.

Designverktyg för Microsoft 3270

Det här verktyget registrerar skärmar, navigeringsvägar, metoder och parametrar för aktiviteterna i ditt program så att du kan lägga till och köra dessa uppgifter som 3270 anslutningsåtgärder. HIS Designer for Logic Apps riktar sig mot transaktionssystem och data, men 3270-designverktyget riktar sig till 3270 program. Mer information finns i 3270-designverktyget.

Azure Logic Apps-anslutningsappar för IBM-stordatorer och mellanregistersystem

I följande avsnitt beskrivs de inbyggda tjänstleverantörsbaserade anslutningsappar som du kan använda för att komma åt och interagera med IBM-stordatorer och mellanregistersystem när du skapar Standard-arbetsflöden i Azure Logic Apps.

Kommentar

Även om några av följande anslutningsappar är tillgängliga som "delade" anslutningsappar som körs i globala Azure, fokuserar den här guiden på de inbyggda tjänstleverantörsbaserade anslutningsprogrammen, som endast är tillgängliga när du skapar Standard-arbetsflöden i Azure Logic Apps.

IBM 3270

Med den här Azure Logic Apps-anslutningsappen för 3270 kan standardarbetsflöden komma åt och köra IBM-stordatorprogram som du vanligtvis kör genom att navigera genom 3270 emulatorskärmar. Anslutningsappen använder TN3270-strömmen. Mer information finns i Integrera 3270-skärmdrivna appar på IBM-stordatorer med Azure med hjälp av Azure Logic Apps och IBM 3270-anslutningsappen.

IBM Customer Information Control System (CICS)

Den här Azure Logic Apps-anslutningsappen för CICS ger standardarbetsflöden möjlighet att interagera och integrera med CICS-program med flera protokoll, till exempel TCP/IP och HTTP. Om du behöver komma åt CICS-miljöer med hjälp av LU6.2 måste du använda Host Integration Server (HIS). Mer information finns i Integrera CICS-program på IBM-stordatorer med Standard-arbetsflöden i Azure Logic Apps med hjälp av IBM CICS-anslutningstjänsten.

IBM DB2

Den här Azure Logic Apps-anslutningsappen för DB2 möjliggör anslutningar mellan Standard-arbetsflöden och DB2-databaser som antingen finns lokalt eller i Azure. Anslutningsappen ger företagets IT-proffs och utvecklare direkt åtkomst till viktig information som lagras i DB2-databashanteringssystem. Mer information finns i Komma åt och hantera IBM DB2-resurser med hjälp av Azure Logic Apps.

IBM-värdfiler

Den här Azure Logic Apps-anslutningsappen för värdfiler ger en tunn omslutning runt funktionen "Flat File Parser" i Värdintegreringsservern. Den här offlineanslutningsappen tillhandahåller åtgärder som parsar eller genererar binära data till och från värdfiler. Dessa åtgärder kräver att dessa data kommer från en utlösare eller en annan åtgärd som genererar binära data. Mer information finns i Parsa och generera IBM-värdfiler med hjälp av Azure Logic Apps.

IBM i

Den här Azure Logic Apps-anslutningsappen för IBM i låter Standard-arbetsflöden interagera och integrera med COBOL- och RPG-program som körs på IBM i-system med TCP/IP. Om du behöver komma åt IBM i-miljöer med hjälp av LU6.2 måste du använda Host Integration Server (HIS). Mer information finns i Integrera COBOL- och RPG-program på IBM-mellanregister med Standard-arbetsflöden i Azure Logic Apps med hjälp av IBM i-anslutningsappen.

IBM Information Management System (IMS)

Den här Azure Logic Apps-anslutningsappen för IMS använder IBM IMS-Anslut komponenten, som ger åtkomst med höga prestanda från Standard-arbetsflöden till IMS-transaktioner med hjälp av TCP/IP. Den här modellen använder IMS-meddelandekön för bearbetning av data. Mer information finns i Integrera IMS-program på IBM-stordatorer med Standard-arbetsflöden i Azure Logic Apps med IBM IMS-anslutningstjänsten.

IBM MQ

Den här Azure Logic Apps-anslutningsappen för MQ möjliggör anslutningar mellan Standard-arbetsflöden och IBM MQ-servrar lokalt eller i Azure. Microsoft tillhandahåller även IBM MQ-integreringsfunktioner med Värdintegreringsserver och BizTalk Server. Mer information finns i Anslut till en IBM MQ-server från ett arbetsflöde i Azure Logic Apps.

Utmaningar för modernisering av stordator- och mellanregistersystem

Stordator- och mellanregistersystem kan vara värdar för flera miljöer som innehåller program, data, filer och verktyg. Under årens lopp kanske dessa miljöer inte har omstrukturerats eller lämnats att växa och nå sina gränser, trots maskinvaruuppgraderingar. Dessa miljöer kan också ha underhållits av flera utvecklare och IT-administratörer, som följer olika programmeringsmönster och tekniker, eller rekryterat andra parter för att hjälpa till med uppgifter som kräver brist på expertis på marknaden. Tillsammans med en krympande pool av erfarna proffs skapar alla dessa faktorer ett komplext och utmanande jobb med att modernisera stordator- och mellanregistermiljöer.

Även om följande lista inte är omfattande innehåller definitionen av en lyckad moderniseringsstrategi minimalt olika sätt att hantera följande uppgifter:

Underhåll de aktuella indikatorerna och målen på tjänstnivå för dina miljöer.
Hantera samexistens mellan äldre data tillsammans med migrerade data.
Genomför DevOps i olika miljöer under samexistens.
Hantera beroenden mellan program.
Definiera framtiden för stordatorschemaläggaren och jobben.
Definiera en strategi för att ersätta kommersiella cots-produkter (off-the-shelf).
Utföra hybridfunktionella och icke-funktionella testaktiviteter.
Underhålla externa beroenden eller gränssnitt.

Med dessa uppgifter i åtanke väljer kunderna vanligtvis någon av följande vägar för att genomföra modernisering av stordatorer och mellanregistersystem:

Big bang

Den här metoden baseras till stor del på vattenfallsmodellen för programvaruleverans, men med iterationer i faser. Metoden big bang används mer av kunder med små stordatorer eller mellanregistersystem och miljöer med låg komplexitet på grund av ett lågt antal kodrader, låg programdensitet och välkända äldre system eller programmeringsspråk.
Agila vågor

Den här metoden följer de agila principerna för programvaruteknik. Metoden Agile waves används mer av kunder med större stordator- eller mellanregistersystem och miljöer med hög komplexitet på grund av ett stort antal kodrader, hög programdensitet, mindre kända system eller programmeringsspråk och ett stort antal beroenden och gränssnitt.

Valet mellan dessa sökvägar beror på organisationens behov och scenarier. Varje väg har fördelar och nackdelar att tänka på. Följande avsnitt innehåller mer information om dessa moderniseringsmetoder.

Big bang eller vattenfall

En big bang-migrering har vanligtvis följande faser:

Föreställ dig: Kickoff
Planering: Identifiera och förbereda planeringsprodukt, till exempel omfång, tid och resurser.
Byggnad: Börjar efter att planeringen av slutprodukt har godkänts

Den här fasen förväntar sig också att allt arbete för beroenden har identifierats och att migreringsaktiviteter kan börja. Flera iterationer utförs för att slutföra migreringsarbetet.
Stabilisera eller testa: Börjar när den migrerade miljön, beroenden och program testas mot testregionerna i stordatormiljön.
Distribuera: När allt har godkänts går migreringen live till produktion.

Organisationer som vanligtvis väljer den här metoden fokuserar på låsningstid, migreringsomfång och resurser. Den här sökvägen låter som ett positivt val men innehåller följande risker:

Migreringar kan ta månader eller till och med år.
Distributioner till produktion är mer riskfyllda.
Den analys som du utför i början av migreringsresan eller under planeringen är inte längre korrekt eftersom den informationen vanligtvis är inaktuell.
Organisationer fokuserar vanligtvis på att ha omfattande dokumentation för att minska leveransriskerna för leverans.

Den tid som ägnas åt att tillhandahålla planeringsartefakter orsakar dock exakt motsatt effekt. Att fokusera på att planera mer än att köra tenderar att skapa körningsfördröjningar, vilket orsakar ökade kostnader på lång sikt.

Agila vågor

Ett agilt tillvägagångssätt är resultatorienterat och fokuserat på att skapa programvara och inte planera slutprodukt. De första stegen i en flexibel leverans kan vara kaotiska och komplexa för de organisationsbarriärer som behöver brytas ned och för att anpassa migreringsteamet. Men när migreringsteamet har mognat efter flera körningssprintar blir resan smidigare. Målet med den här metoden är att ofta släppa funktioner till produktion och att tillhandahålla affärsvärde tidigare än med en big bang-metod.

En agil migrering av vågor har vanligtvis följande sprintar:

Sprint noll (0)
- Definiera teamet, en inledande kvarvarande arbetslogg och kärnberoenden.
- Identifiera de funktioner och en MVP (Minimum Viable Product) som ska levereras.
- Starta stordatorns beredskap med en vald uppsättning arbetsobjekt eller användarberättelser för att påbörja arbetet.
Sprint 1, 2, ..., N

Varje sprint har ett mål där teamet har ett leveranstänk, vilket innebär att de fokuserar på att slutföra migreringsmål och släppa slutprodukt till produktion. Teamet kan använda en grupp sprintar för att leverera en specifik funktion eller en våg av funktioner. Varje funktion innehåller sektorer av integreringsarbetsbelastningar.

Delade element, till exempel jobb och beroenden, finns och påverkar hela miljön. En lyckad strategi fokuserar på att delvis aktivera jobb, omdesigna program för modernisering och lämna systemen med de flesta beroenden till slutet för att först minska mängden migreringsarbete och sedan slutföra moderniseringsarbetets omfattning.

Microsoft rekommenderar att du moderniserar stordator- och mellanregistersystemarbetsbelastningar genom att följa en iterativ, agil vågbaserad modell genom att fokusera på investeringar i den nya plattformen, samtidigt som tillväxten av äldre system begränsas. Den här metoden minskar avsevärt implementeringsriskerna genom att bevara det befintliga affärsvärdet, samtidigt som den moderniserade miljön införs. På så sätt kan ditt team också utnyttja teknikkunskaper som hjälper ditt företag att bli mer konkurrenskraftigt. I det här scenariot kan Azure Logic Apps hjälpa dig med moderniseringen.

Moderniseringsmönster

Bra design omfattar faktorer som konsekvens och konsekvens i komponentdesign och -distribution, underhållsbarhet för att förenkla administration och utveckling samt återanvändning som gör att andra program och scenarier kan återanvända komponenter och undersystem. För molnbaserade program och tjänster har beslut som fattas under design- och implementeringsfasen en enorm inverkan på kvaliteten och den totala ägandekostnaden.

Azure Architecture Center innehåller testade design- och implementeringsmönster som beskriver problemet, överväganden för att tillämpa mönstret och ett exempel baserat på Microsoft Azure. Det finns flera design- och implementeringsmönster, men några av de mest relevanta mönstren för stordatormodernisering är mönster för "Anti-corruption Layer", "Strangler Fig", "Saga" och "Choreography".

Lagermönster för skydd mot korruption

Oavsett vilken moderniseringsmetod du väljer måste du implementera ett "lager mot korruption" med hjälp av Azure Logic Apps. Den här tjänsten blir fasad- eller adapterlagret mellan det äldre stordatorsystemet och Azure. En effektiv metod är att identifiera de stordatorarbetsbelastningar som ska integreras eller samexistera som arbetsbelastningar för stordatorintegrering. Skapa en strategi för varje integreringsarbetsbelastning, vilket är den uppsättning gränssnitt som du behöver aktivera för att migrera ett stordatorprogram.

Mer information finns i Lager mot korruption.

Strangler Fig-mönster

När du har implementerat antikorruptionsskiktet sker moderniseringen gradvis. För den här fasen måste du använda mönstret "Strangler Fig" där du identifierar stordatorarbetsbelastningar eller funktioner som du kan modernisera stegvis. Om du till exempel väljer att modernisera ett CICS-program måste du modernisera inte bara CICS-programmen, utan troligtvis de 3270 programmen tillsammans med motsvarande externa beroenden, data och jobb.

Så småningom, när du har ersatt alla arbetsbelastningar eller funktioner i stordatorsystemet med ditt nya system, slutför du migreringsprocessen, vilket innebär att du kan inaktivera ditt äldre system.

Mer information finns i Strangler Fig-mönster.

Saga- och koreografimönster

Distribuerade transaktioner, till exempel 2PC-protokollet (two-phase commit) kräver att alla deltagare i en transaktion checkar in eller återställer innan transaktionen kan fortsätta. Molnhybridarkitekturer fungerar bättre efter ett slutligt konsekvensparadigm i stället för en distribuerad transaktionsmodell.

Designmönstret "Saga" är ett sätt att hantera konsekvens mellan tjänster i distribuerade transaktionsscenarier. En saga är en sekvens med transaktioner som uppdaterar varje tjänst och publicerar ett meddelande eller en händelse för att utlösa nästa transaktionssteg. Om ett steg misslyckas kör sagan kompenserande transaktioner som motverkar föregående transaktioner. Mer information finns i Sagas mönster för distribuerade transaktioner.

I Azure Logic Apps kan arbetsflöden fungera som koreografer för att samordna sagor. Arbetsflödesåtgärder är atomiska, så du kan köra dem individuellt igen. Åtgärdstypen Omfång ger möjlighet att köra en grupp med åtgärder först efter att en annan åtgärdsgrupp har slutförts eller misslyckats. Azure Logic Apps utför kompenserande transaktioner på omfångsnivå, medan Azure Event Grid och Azure Service Bus tillhandahåller den händelsehantering som krävs för specifika domäner. Alla dessa tjänster, som utgör Azure Integration Services, ger den support som kunderna behöver när de behöver en tillförlitlig integrationsplattform för verksamhetskritiska scenarier. Mer information finns i Koreografimönster.

Den här artikeln beskriver flera moderniseringsmönster, men komplexa lösningar kräver många fler mönster och att du tydligt förstår organisationens moderniseringsmål. Även om uppgiften att utöka värdet på äldre tillgångar är utmanande, är det här alternativet det bästa sättet att bevara investeringar i dessa tillgångar och förlänga deras affärsvärde.

Nästa steg

Azure Architecture Center för stordatorer och mellanregistersystem

Dela via