Dela via

Migreringsmetoder för BizTalk Server till Azure Integration Services

  • Artikel

Den här guiden beskriver migreringsstrategier och resurser samt planeringsöverväganden och metodtips som hjälper dig att leverera lyckade migreringslösningar.

Kommentar

En migreringsöversikt och guide till hur du väljer tjänster i Azure för migreringen finns i följande dokumentation:

Strategialternativ

I följande avsnitt beskrivs olika migreringsstrategier tillsammans med deras fördelar och nackdelar:

Lift and Shift

På Azure Marketplace hittar du alternativet att etablera virtuella datorer som inkluderar BizTalk-licensiering med modellen betala per användning. Det här erbjudandet ger dig fördelen av att använda Microsofts IaaS-funktioner (Infrastruktur som en tjänst) via en förbrukningsbaserad prismodell. Även om användning av dessa virtuella datorer kan lindra vissa utmaningar vid hantering av BizTalk Server-infrastruktur, hanterar den här metoden inte supportens livscykelscheman och tidsgränser för BizTalk Server.

Med organisationer som omfamnar digital omvandling genom att flytta till eller använda molnet har många vanliga uppgifter för att avbryta sin infrastruktur för VMware, Hyper-V eller fysisk server och migrera den här funktionen till IaaS i Azure. Det här valet hjälper till att minska de tidigare nämnda utmaningarna, men hanterar inte BizTalk-kodbasen.

Med BizTalk Server 2013 och senare kan du välja att köra dina BizTalk-servrar lokalt som tidigare eller köra dem på en virtuell server i Azure. Att köra din BizTalk Server-miljö i molnet har följande fördelar:

  • Inget behov av privat maskinvara eller infrastruktur, så inget maskinvaruunderhåll.
  • Ökad tillgänglighet för serverinfrastrukturen, som kan omfatta flera datacenter eller replikeras i tillgänglighetszoner.
  • Få åtkomst till dina servrar var som helst via Internet.
  • Microsoft säkerhetskopierar dina bilder.
  • Snabb distribution för nya servrar med inbyggda avbildningar som är tillgängliga på Azure Marketplace.
  • Snabb uppskalning för dina servrar genom att ändra storleken på virtuella datorer för att lägga till minne och CPU, lägga till hårddiskar och så vidare
  • Förbättrad säkerhet för din miljö med hjälp av Azure Security Center. Den här tjänsten identifierar säkerhetshot och ger dig en undersökningssökväg när säkerhetsincidenter inträffar

Hybridintegrering

Även om BizTalk Server- och Azure Integration Services-funktionerna kan överlappa varandra fungerar de bättre när du använder dem tillsammans. De flesta organisationer som inte flyttar hela infrastrukturen till molnet har huvudsakligen följande orsaker:

  • Företagsprinciper
  • Lands-/regionalpolitik
  • Branschdomänspecifika principer

Dessutom finns inte alla funktioner eller program i molnet, eller så kanske vissa som är tillgängliga inte är lika robusta som de som finns lokalt. Men för att hålla jämna steg med molnrevolutionen och utöka affärsfunktionerna börjar många organisationer med saaS-erbjudanden tillsammans med sina lokala system. Många affärsprocesser kan dra nytta av molnbaserade utveckling och implementeringsstrategier.

Genom att införa en hybridintegreringsstrategi kan du fortfarande dra nytta av teknikinvesteringarna i de system som din organisation är beroende av, men ändå dra nytta av nya funktioner, bättre prestanda och lägre kostnadsstruktur för molnbaserade program som Azure.

Med BizTalk Server 2016 har den separata versionen av Microsoft BizTalk Server Adapter för Logic Apps gett dig möjlighet att implementera en del av din integreringslogik som en tjänst i Azure med hjälp av Azure Logic Apps för att ansluta hundratals molntjänster. Det här adaptern hjälpte till med både lokala integreringar och hybridintegreringar genom att erbjuda följande funktioner:

  • Integrera molntjänster med BizTalk Server med inbyggda kort som Azure Logic Apps, Azure Service Bus, Azure Event Hubs, Azure Blob Storage och Office 365 Mail, Schedule och Contacts.

  • Använd BizTalk Server-anslutningsappen i Azure Logic Apps för att ansluta från Azure Logic Apps till BizTalk-servern.

  • Publicera BizTalk Server-slutpunkter med Hjälp av Azure API Management så att organisationer kan exponera slutpunkter för interna utvecklare och externa partner.

Med BizTalk Server 2020 inkluderade installationen automatiskt adaptern för Azure Logic Apps tillsammans med de inbyggda korten för att enkelt ansluta till molnmiljön.

Big bang

En metod för "big bang" eller "direkt övergång" kräver mycket planering och rekommenderas inte för organisationer som inte är bekanta med Azure Logic Apps eller som har stora system eller lösningar att migrera. När en organisation implementerar en ny teknikstack resulterar ofta nya lärdomar. Genom att investera för tidigt eller för mycket har du inte möjlighet att dra nytta av lärdomar och anpassa dig utan att riskera betydande omarbete.

Den här metoden kan också ta längre tid att skörda eller ackumulera värde. Om du redan har slutfört vissa migreringsaktiviteter, men du ännu inte har släppt dem i produktion på grund av annat väntande eller pågående arbete, genererar inte dina migrerade artefakter värde för din organisation.

Den här metoden ger din organisation möjlighet att stegvis uppnå värde, men tidigare än de annars skulle kunna göra. Ditt projektteam kan lära sig om teknikstacken tidigt med hjälp av retrospektiv. Du kan till exempel distribuera ett befintligt BizTalk-gränssnitt eller projekt till produktion och sedan lära dig mer om lösningens behov, till exempel hantering, skalbarhet, åtgärder och övervakning. När du har fått den här kunskapen kan du planera sprintar för att optimera befintliga funktioner eller introducera nya mönster som du senare kan använda i framtida arbete.

Oavsett din metod bör du överväga att omstrukturera BizTalk Server-lösningar till serverlösa eller molnbaserade lösningar innan du inaktiverar serverinfrastrukturen om du planerar att flytta till Azure Integration Services eller Azure i allmänhet. Det här valet är en utmärkt strategi om din organisation vill omvandla verksamheten helt till molnet.

Planera en migrering

Följande avsnitt innehåller vägledning om planering för migrering och vilka områden du bör tänka på.

Beredskapsplanering

Beredskap representerar en viktig del i planeringsprocessen. När du förstår projektets bredd och djup förbättras förutsägbarheten i flera dimensioner, till exempel kostnader, komplexitet, tidslinjer och projektets övergripande framgång. Följande lista innehåller specifika områden att granska och åtgärda som en del av projektets charterprocess.

Område beskrivning
Lagersaldo Samla in data om alla dina gränssnitt och program så att du kan lära dig hur många gränssnitt och program som du behöver migrera. Under den här katalogiseringsprocessen samlar du in följande information för att tillhandahålla kontext:

– Adaptrar som används
– BizTalk Server-funktioner som används, till exempel övervakning av affärsaktivitet, motor för affärsregler, EDI och så vidare
– Anpassad kod, till exempel uttryck, kartor och pipelinekomponenter
– Dataflöde för meddelanden
– Meddelandestorlekar
-Beroenden
Komplexitet För att hjälpa dig att lära dig komplexitetsnivåer i dina gränssnitt kan du granska typerna av affärsregler i dessa gränssnitt och de tekniska krav som behöver anpassas för att uppfylla deras behov eller prestandakrav.
Värde Utvärdera värdet för dina gränssnitt så att du kan fastställa prioriteten för vilka gränssnitt som ska omimplementera. När du börjar med lågriskgränssnitt kan det vara meningsfullt att först fokusera på arbetet med det högsta värdet när du har arbetat med Azure Integration Services.
Kostnader Upprätta projektets omfång och beräkna kostnader eftersom ett migreringsprojekt kräver kapital för att starta körningen. Skydda projektets budget, oavsett om den uppnås via kapital- eller driftbudgetplanering, och hantera projektets omfång längs vägen.
Program- och systemberoenden Identifiera och ta hänsyn till dessa beroenden när du påbörjar projektplaneringen, så att du kan undvika överraskningar när du startar projektkörningen.
Riskregister Skapa och använd den här artefakten för att identifiera och spåra eventuella risker som uppstår när du arbetar med projektplaneringsövningar. När du förstår riskerna kan du proaktivt minimera dem och kommunicera med ledningen. Du kan också ta bort blockerare tidigt när de är billigare att hantera.

Migreringsverktyg

Kommandoradsverktyget För Azure Integration Migrator, även kallat BizTalk Migration-verktyget, är ett Microsoft-projekt med öppen källkod som kan hjälpa dig i planerings- och körningsfaserna för migreringsprojektet tillsammans med att flytta BizTalk Server-program till Azure Integration Services. Du kan också använda det här verktyget för att upptäcka användbara insikter och strategier för att migrera dina lösningar till molnet.

Det här verktyget går igenom följande faser:

  1. Upptäck

    Hämtar BizTalk Server-resurser och identifierar BizTalk-artefakterna som ska migreras. Läser sammansättningar och bindningsfilinformation.

    Krav: MSI för Biztalk Server-programmet och alla refererade BizTalk Server-program

  2. Parse

    Läser BizTalk Server-artefakterna och skapar en källdatamodell för BizTalk Server-programmet.

  3. Analysera

    Skapar en Azure Integration Services-måldatamodell med hjälp av källdatamodellen från Parse-fasen. I grund och botten granskar verktyget BizTalk Server-resurserna, identifierar vilka objekt som kan migreras och skapar en datamodell för Azure Integration Services-målet. 

  4. Rapport

    Genererar en rapport som beskriver de funna BizTalk Server-resurserna och de objekt som kan migreras. Rapporten innehåller också detaljerad information om innehållet i käll- och målprogrammen tillsammans med information om eventuella problem med konverteringen.

  5. Konvertera

    Genererar Azure Manager-resursmallar och Azure CLI-skript som du kan använda för att skapa programmen i Azure med hjälp av måldatamodellen.

  6. Verifiera

    Den här fasen är för närvarande inte inbyggd i verktyget, men du kör installationsskripten för att distribuera ditt program till Azure. Du kan sedan utvärdera om det genererade programmet har samma funktioner som ditt lokala BizTalk Server-program.

Följande diagram visar de faser som Azure Integration Migrator-verktyget går igenom:

Diagram showing phases that Azure Integration Services member services.

Viktiga teamroller och färdigheter för lyckad migrering

Om du vill migrera integreringsarbetsflöden från BizTalk Server till Azure Integration Services, etablerar du ett team som har följande viktiga roller och färdigheter som sträcker sig över flera områden:

Roll Kompetens
Projektledare Ansvarig för att leda det övergripande projektet och levererar det överenskomna omfånget inom gränserna för tid och budget.
Scrum ledare Hanterar aktivt kvarvarande uppgifter och underlättar prioriteringen av projektets aktiviteter.
Arkitekter Se till att projektet överensstämmer med företagets arkitekturprinciper och ge vägledning om hur du navigerar i osäkerhet och vägspärrar.
Utvecklare Arbeta aktivt med att migrera komponenter från BizTalk Server till Azure Integration Services.
Kvalitetssäkringstestare Skapa testplaner och kör testning mot dessa planer. Spåra, kommunicera och sortera buggar och defekter som en del av projektsprintplaneringen.
Användargodkännandetestare (UAT) Ange de affärsintressenter som hjälper till att se till att inga regressioner introduceras genom att flytta gränssnitt från en befintlig plattform till en ny plattform.
Specialister på ändringshantering Utvärdera effekten på befintliga processer och roller. Skapa en plan för att minimera eventuella upplevda problem innan de dyker upp.

Överväg partner som har erfarenhet av att utföra migreringar för att tillhandahålla vissa eller alla resurser som beskrivits tidigare. Som teammedlemmar kan de bidra till att minska risken, förbättra tiden till marknaden och göra projektet mer förutsägbart med sina kunskaper och expertis.

Byggprocessplanering

För byggplanering rekommenderar Microsoft att du inkluderar sprintar och arbetsobjekt för att hantera grundläggande tjänster, till exempel autentisering, loggning, undantagshantering och så vidare. Den här inkluderingen hjälper till att undvika omarbetning senare i utvecklingscykler som orsakas av att underliggande behov inte tillgodoses. Du vill också undvika blockerade utvecklare på grund av beslut som kräver att andra intressenter fattar.

Följande lista omfattar endast vissa områden att tänka på:

Område beskrivning
Autentisering Åtgärda följande frågor och andra om autentisering innan du går in för djupt i utvecklingscyklerna.

– Har din organisation några standarder kring autentiseringsscheman?
– Kan du använda hanterade identiteter och tjänstens huvudnamn i Azure?
– Tillåts grundläggande autentisering och API-nycklar eller inte?

Den här aktiviteten kan vara ett bra tillfälle att ta in företagsarkitekter som kan se till att få tydliga avtal om vilka autentiseringsscheman som ska användas.
Loggning Överväg att samla in och lagra telemetri i en centraliserad datalagringsplats, vilket är ett populärt mönster som integrationslösningar använder.

Azure Logic Apps (Standard) kan till exempel skicka telemetri till Application Insights i Azure Monitor. Azure Logic Apps (Förbrukning) kan skicka telemetri till Log Analytics, även i Azure Monitor. Du kan också inkludera spårade egenskaper så att utvecklare kan inkludera mer kontext när meddelanden flödar via integrationsplattformen. Dessa data kan till exempel innehålla arbetsordernummer, inköpsorderinformation eller något annat som kan vara användbart, användbart och relevant för din organisation.

Förmodligen kan varje organisations lösning skilja sig åt, baserat på organisationens behov. Vissa organisationer vill till exempel ha fullständig kontroll över vad och när data loggas. I det här scenariot kan du skapa API:er eller anpassade anslutningsappar och sedan instrumentera koden baserat på specifika milstolpar.

Oavsett vilken metod du väljer bör du se till att utvecklarna tydligt förstår förväntningarna för att undvika framtida omarbetning.
Undantagshantering Hantera att ha en strategi och ett konsekvent mönster tidigt för att hantera undantag och fel för att undvika framtida omarbetning. Se till att skapa klarhet kring det här området tidigt innan du skapar några logikappar. Följande lista innehåller några frågor att besvara när du hanterar undantagshantering:

– Hur ska du använda omfångsinställningar och "Kör efter"-inställningar för att identifiera undantag?
– Hur kan du använda result() uttrycket för att bättre förstå var ett undantag inträffar i ett arbetsflöde och för att hitta mer information om den underliggande rotorsaken?
– Hur vill du logga dessa data och kommunicera med intressenter när du har valt att fånga undantag?

Se till att dessa beslut överensstämmer med din loggningsstrategi som tidigare nämnts. Helst har du upprättat en process som aktivt söker efter nya felhändelser i loggningsdatalagret. Därifrån kan du svara på dessa händelser och samordna en undantagsprocess. Du kan behöva filtrera bort eller aggregera duplicerade felhändelser, logga ett ärende i organisationens IT-tjänsthanteringslösning och välja hur du vill skicka meddelanden. Du kan ha olika sökvägar för meddelanden, baserat på allvarlighetsgrad och tid på dagen. Du kan uppnå flexibilitet genom att skapa ett arbetsflöde för att hantera den här processen.
Analys För att demonstrera lösningens allmänna hälsa och hygien för dina intressenter bör du överväga de olika linser som dina intressenter använder för att titta igenom, till exempel:

- Chefer kan vara mer intresserade av övergripande hälsa, transaktionsantal eller volym och affärsvärdet som dessa transaktioner genererar, men inte övergripande tekniska nyanser.
- En chef i frontlinjen kanske är mer intresserad av allmän hälsa men kan också bli intresserad av teknisk information, till exempel prestandaegenskaper, för att se till att serviceavtalen uppfylls.
– Supportanalytiker är sannolikt intresserade av övergripande tjänsthälsa, undantag och flaskhalsar för prestanda.

När du sammanställer din analysstrategi bör du tänka på dina intressenter och vilken typ av data som intresserar dem. Den här tankeprocessen hjälper dig att se till att du spårar användbar och användbar information och gör dessa data tillgängliga i rapporteringssyfte. Om du hittar täckningsluckor kan du behöva gå tillbaka till dina loggningsrelaterade arbetsobjekt och lägga till lämpliga uppgifter för att åtgärda dessa luckor.
Sekvens När du skickar dina integrationsprojekt och lär dig av dessa erfarenheter, se till att fånga de lärdomar som oundvikligen dyker upp. Planera reparationssprintar eller cykler tidigt på resan så att du kan korrigera kursen tidigt, innan kostnaden blir för stor. På så sätt kan du undvika att införa för mycket teknisk skuld i din nya plattform.

Distributionsplanering

När du förväntar dig och förbereder en distributionsplan ökar du dina möjligheter till en lyckad distribution. När du har skapat all infrastruktur och alla miljöer med BizTalk Server har du flyttat fokus till lösningsdistribution.

Med Azure skiljer sig den här upplevelsen åt med vissa aktiviteter att tänka på först, till exempel att hantera infrastrukturdistribution mellan olika miljöer, som kan innehålla olika Azure-prenumerationer, Azure-resursgrupper eller någon kombination, till exempel:

  • Azure Key Vault: hemligheter och åtkomstprinciper
  • Azure Service Bus: köer, ämnen, prenumerationer, filter och åtkomstprinciper
  • Azure App Service: planer, nätverk och autentisering

Därefter kan du fokusera på lösningsdistribution mellan olika miljöer.

Testplanering

För att säkerställa att dina intressenter är nöjda med den lösning som du tillhandahåller är testning viktigt att tänka på för alla migreringsprojekt. En ny lösning bör ge mer värde jämfört med den tidigare lösningen, utan några regressioner som kan påverka verksamheten.

Överväg följande testrekommendationer för migreringsprojektet:

  • Upprätta din baslinje genom att svara på följande frågor:

    1. Har du befintliga tester?
    2. Körs testerna utan fel?
    3. Är testresultaten korrekta?

    För att vara säker på att ditt team inte har introducerat regressioner behöver du möjligheten att jämföra resultat från den nya plattformen med tillförlitliga tester från din befintliga plattform. Om du inte har någon baslinje måste du därför upprätta en.

    Naturligtvis vill du inte spendera många resurser på att etablera tester mot en plattform som går i pension, men du måste svara på frågan "Hur gör jag för att vet att allt fungerar bra?" Om du är i den här situationen börjar du upprätta din baslinje baserat på prioriteringar och skapar en plan för att minimera områden där du har luckor.

  • Konfigurera din teststrategi för den nya plattformen.

    Om du antar att du är bekväm med din baslinje kan du nu tänka på hur du ska testa på din nya plattform. Om du hade problem med att upprätta baslinjen kan du ta tillfället i akt att skapa en stark grund för din nya plattform.

    När du funderar på att testa för din nya plattform bör du ha automatiseringen i åtanke. Även om du har en plattform kan du snabbt skapa gränssnitt, men att förlita sig på manuella tester urholkar dessa produktivitetsvinster.

  • Automatisera dina tester.

    Azure Logic Apps (Standard) innehåller möjligheten att utföra automatiserad testning. Följande lista innehåller mer information och resurser som är fritt tillgängliga på GitHub:

    • Automatiserad testning med Azure Logic Apps (Standard) från Azure Logic Apps-teamet

      Med Azure Logic Apps (Standard) är automatiserad testning inte längre svår att utföra på grund av den underliggande arkitekturen, som baseras på Azure Functions-körningen och kan köras var som helst där Azure Functions kan köras. Du kan skriva tester för arbetsflöden som körs lokalt eller i en CI/CD-pipeline. Mer information finns i exempelprojektet för Azure Logic Apps Test Framework.

      Det här testramverket innehåller följande funktioner:

      • Skriva automatiserade tester för funktioner från slutpunkt till slutpunkt i Azure Logic Apps.
      • Utför detaljerad validering på arbetsflödeskörnings- och åtgärdsnivå.
      • Kontrollera testerna på en Git-lagringsplats och kör antingen lokalt eller inom CI/CD-pipelines.
      • Simulerade testfunktioner för HTTP-åtgärder och Azure-anslutningsappar.
      • Konfigurera tester för att använda olika inställningsvärden från produktion.

    • Integration Playbook: Logic Apps Standard Testing från Michael Stephenson, Microsoft MVP

      Testramverket för Integration Playbook bygger på det Microsoft-tillhandahållna testramverket och stöder ytterligare scenarier:

      • Anslut till ett arbetsflöde i en standardlogikapp.
      • Hämta motringnings-URL:en så att du kan utlösa arbetsflödet från ett test.
      • Kontrollera resultatet från arbetsflödeskörningen.
      • Kontrollera åtgärdens indata och utdata från arbetsflödets körningshistorik.
      • Anslut till automatiserade testramverk som utvecklare av logikappar kan använda.
      • Anslut till SpecFlow för att stödja beteendedriven utveckling (BDD) för logikappar.

    Oavsett vilka metoder eller resurser du använder är du på god väg att få repeterbara, konsekventa automatiserade integreringstester.

  • Konfigurera testning av mock-svar med hjälp av statiska resultat.

    Oavsett om du konfigurerar automatiserade tester kan du använda funktionen för statiska resultat i Azure Logic Apps för att tillfälligt ställa in falska svar på åtgärdsnivå. Med den här funktionen kan du emulera beteendet från ett visst system som du vill anropa. Du kan sedan utföra vissa inledande tester isolerat och minska mängden data som du skapar i affärssystem.

  • Kör sida vid sida-tester.

    Helst har du redan baslinjeintegreringstester för din BizTalk Server-miljö och etablerade automatiserade tester för Azure Integration Services. Du kan sedan köra tester sida vid sida på ett sätt som hjälper dig att kontrollera dina gränssnitt med hjälp av samma datamängder och förbättra den övergripande testnoggrannheten.

Publicera

När ditt team har slutfört testningen bör du tänka på de uppgifter som krävs för att sätta din nya integrationsplattform i produktion:

  1. Skapa en kommunikationsplan.

    Även om du kanske har ett litet team som implementerar de tekniska aspekterna och informationen för ett moderniseringsprojekt för integrationsplattformen, har du förmodligen många intressenter som du behöver hålla dig informerad om migreringsprojektet. Om du inte har en tydlig kommunikationsstrategi skapar du ångest för andra inblandade. Tänk också på de externa intressenter som du behöver inkludera i din kommunikationsplan. Du kanske till exempel vill inkludera andra handelspartner eller kunder som kan påverkas av kommande händelser. Glöm inte de här intressenterna också.

    Så kommunicera tidigt och ofta genom att ge klarhet inom de områden som påverkar dina intressenter, till exempel vad du förväntar dig av dem, när de behövs, hur länge de behövs och så vidare. Genom att tillhandahålla en koncis och tydlig plan skapar du förtroende för intressenterna och behåller positiv energi kring ditt projekt. Ta bort eventuella tvivel genom att se till att ditt team är redo att köra. Annars riskerar du att förstöra moralen på grund av uppfattningar, spekulationer och rykten om att ditt projekt kan misslyckas.

  2. Gör en "cut-over"-plan.

    En detaljerad plan omfattar information om de uppgifter och aktiviteter som krävs för att växla från den aktuella plattformen till den nya plattformen, inklusive de steg som ditt team planerar att utföra. Ta med följande överväganden i din översiktsplan:

    • Nödvändiga steg

      Identifiera de åtgärder som du kan eller måste utföra i förväg, så att du inte lämnar allt för cut-over-dagen. I allmänhet innebär en cut-over till en ny integreringsplattform vanligtvis att du har en "grön fält"-distribution, så att du kan mellanlagra många komponenter och konfigurationer tidigt i cykeln. Ju mer du kan slutföra innan den ursprungliga plattformens underhållsperiod, desto mer ångest kan du ta bort och förbättra det övergripande resultatet av din cut-over-händelse.

    • Genrep

      Intressenter vill vanligtvis ha viss förutsägbarhet kring kommande händelser. Så, hur ger du förutsägbarhet kring något du aldrig har gjort förut? Genom att köra en repetition som distribuerar din integreringsplattform till en förproduktionsmiljö kan du verifiera din plan för utskärning och den förväntade tidpunkten för varje steg i processen.

      Annars kan en underskattning av den tid som ett steg kan ta leda till en krusningseffekt i fördröjningar. Sammantaget kan dessa förseningar kosta en betydande tid och störa verksamheten. När du kör en repetition kan du basera schemat på faktiska data. Ditt team kan också hitta problem som skulle ha orsakat problem under live-drift i produktion. När ditt team upptäcker och dokumenterar problem tidigt är de bättre förberedda och riskerar färre överraskningar under den verkliga cut-over-händelsen.

    • Personer

      Se till att det finns ett tydligt ansvar kring vilken person som äger varje enskilt steg i planen. Som en klok åtgärdsstrategi kan du identifiera och förbereda säkerhetskopieringspersoner om den primära personen inte är tillgänglig för att utföra uppgiften på grund av oväntade omständigheter.

    • Schemalägg uppskattningar

      När du har kört en repetition bör ditt team ha en bättre förståelse för hur lång tid varje uppgift kan ta att slutföra. Du kan använda dessa uppskattningar för att prognostisera ett schema så att personer vet när du behöver dem och ungefär hur lång tid de måste slutföra sin uppgift.

    • Inaktivera gränssnitt i den gamla plattformen

      Förutsatt att du förstår alla befintliga beroenden kan du börja inaktivera gränssnitt i din gamla integrationsplattform innan du aktiverar gränssnitt i den nya plattformen. Vissa komplexa arkitekturer kan kräva att du inaktiverar sekventiella gränssnitt i en specifik ordning för att undvika överraskningar. Beroende på gränssnittets natur kanske du inte heller kan inaktivera alla gränssnitt i din gamla integrationsplattform. Om du till exempel har ett affärssystem som skickar meddelanden till din integrationsplattform måste du ta hänsyn till de här situationerna i din plan.

    • Aktivera gränssnitt i den nya plattformen

      På samma sätt som du kan ha sekventiella gränssnitt som kräver att du inaktiverar i en viss ordning, kan du ha nya sekventiella gränssnitt att aktivera med samma krav. Innan du börjar aktivera gränssnitt måste du se till att du förstår alla beroenden och att du har identifierat den ordning som krävs för att aktivera nya sekventiella gränssnitt.

      Kommentar

      Se till att du utför steg för att aktivera gränssnitt på ett metodiskt och systematiskt sätt för att undvika felsteg som riskerar att projektet lyckas.

    • Valideringstestning

      Den här aktiviteten är oerhört viktig, så inkludera det här arbetet i din plan. När du har aktiverat dina gränssnitt kontrollerar du att gränssnitten fungerar som förväntat innan du går vidare till fasen "Go or No-go". Helst kan du utföra valideringstester som inte påverkar kärnaffärsdata. Den här guiden innehåller mer information om valideringstestning för dina nya gränssnitt i ett senare avsnitt.

  3. Fastställ en återställningsplan.

    Förhoppningsvis har du nu en strukturerad och detaljerad metod för att implementera din nya integrationsplattform. Överraskningar kan dock inträffa, så ta reda på vilka steg som krävs för att återställa till din tidigare integrationsplattform. På så sätt har du en plan redo att gå, förresten.

    När du tänker igenom de här stegen bör du överväga de händelser som kan utlösa en återställning. Anpassa även din plan till de personer som du behöver för att fatta återställningsbeslutet. Den här guiden innehåller mer information i avsnittet om att fatta beslutet "Go or No-go".

  4. Kör valideringstestning.

    Din plan bör ha inkluderat informationen för det här arbetet. När du har aktiverat dina gränssnitt kontrollerar du att gränssnitten fungerar som förväntat innan du går vidare till fasen "Go or No-go". Helst kan du utföra valideringstester som inte påverkar kärnaffärsdata.

    Det är till exempel bra att dina valideringstester kan läsa data från ett produktionssystem, men de kan inte skriva data, vilket skapar ett efterlevnadsproblem. Annars måste du vänta tills en affärstransaktion flödar genom dina gränssnitt och verifiera att allt fungerar som ditt team förväntar sig.

  5. Planera för drift eller produktionsstöd.

    Även om arbetet med att migrera gränssnitt mellan plattformar vanligtvis förbrukar de flesta projektresurser, tar du hänsyn till löpande stöd för dina gränssnitt och den nya plattformen.

    • Se till att dela lämplig mängd och kunskapsnivå mellan projektteamet och driftteamet.

    • Skapa och behåll en aktuell kontaktlista som har både teknisk och affärskontaktinformation så att vem som helst kan nå lämpliga teammedlemmar när det behövs.

    • Om du vill ha ett smidigare och snabbare supportsvar till kunderna måste du ha dina supportprocesser och dokumentation redo innan du går live. Du kan hjälpa till att minska stressen för kunder, supportteamet och projektteamet när du kan undvika att en supportmedlem försöker ta reda på allt när en faktisk incident inträffar.

  6. Välj "Go or No-go" för att flytta till produktion.

    I det här steget ska du samarbeta med relevanta intressenter för att avgöra om projektet kan flyttas till produktion. Intressenter kan till exempel inkludera ledarskap, projektledning, drift och affärsrepresentanter.

  7. Fira teamets framgång.

    Klar! När du har slutfört ett projekt som påverkar din organisation eller ditt företag positivt är det dags att känna igen ditt team för allt deras hårda arbete och fira en fantastisk milstolpe! Se till att kreditera ditt team på ett lämpligt och meningsfullt sätt. Inget erkännande är ett säkert sätt att förstöra moralen.

  8. Håll en retrospektiv.

    Precis som alla tekniska aktiviteter får ditt team värdefull insikt och utökar sina kunskaper genom att lära sig av erfarenhet. Träffa ditt team för att diskutera och fånga områden som gick bra, inte gick bra, och de som kan förändras till det bättre. Var noga med att du är värd för den här konversationen i en icke-hotfull och stödjande miljö och håll dig fokuserad på målet att lära dig och växa, inte skylla. Dela dina lektioner med ditt ledarskap och andra intresserade intressenter. Den här övningen skapar förtroende i hela teamet och representerar teknisk mognad.

Metodtips för migrering

Även om bästa praxis kan variera mellan organisationer, bör du överväga en medveten insats för att främja konsekvens, vilket bidrar till att minska onödiga ansträngningar som "återuppfinner hjulet" och redundansen för liknande vanliga komponenter. När du hjälper till att aktivera återanvändning kan din organisation snabbare skapa gränssnitt som blir enklare att stödja. Tid till marknad är en viktig möjliggörare för digital omvandling, så högsta prioritet är att minska onödig friktion för utvecklare och supportteam.

När du upprättar dina egna metodtips bör du överväga att följa följande vägledning:

Allmänna namngivningskonventioner för Azure-resurser

Se till att konfigurera och konsekvent tillämpa bra namngivningskonventioner för alla Azure-resurser från resursgrupper till varje resurstyp. För att lägga en solid grund för identifiering och support kommunicerar en bra namngivningskonvention syftet. Den viktigaste punkten för namngivningskonventioner är att du har dem och att din organisation förstår dem. Varje organisation har nyanser som de kan behöva ta hänsyn till.

Mer information om den här metoden finns i följande Microsoft-rekommendationer och -resurser:

Namngivningskonventioner för Azure Logic Apps-resurser

Designen för logikappen och arbetsflödet ger en viktig startpunkt eftersom det här området ger utvecklare flexibilitet att skapa unika namn.

Resursnamn för logikapp

Om du vill skilja mellan förbruknings- och standardlogikappresurser kan du använda olika förkortningar, till exempel:

  • Förbrukning: LACon
  • Standard: LAStd

Ur ett organisationsperspektiv kan du utforma ett namngivningsmönster som innehåller affärsenheten, avdelningen, programmet och eventuellt distributionsmiljön, till DEVexempel , UAT, PRODoch så vidare, till exempel:

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

Anta att du har en standardlogikapp under utveckling som implementerar arbetsflöden för HR-avdelningen i affärsenheten Corporate Services. Du kan namnge logikappresursen LAStd-CorporateServices-HR-DEV och använda Pascal Case-notation när det är lämpligt för konsekvens.

Arbetsflödesnamn för logikapp

En förbrukningslogikappresurs mappar alltid till endast ett arbetsflöde, så du behöver bara ett enda namn. En standardlogikappresurs kan innehålla flera arbetsflöden, så utforma en namngivningskonvention som du också kan använda för medlemsarbetsflöden. För dessa arbetsflöden bör du överväga en namngivningskonvention som baseras på processnamnet, till exempel:

Process-<*process-name*>

Om du har ett arbetsflöde som implementerar registreringsuppgifter för anställda, till exempel att skapa en anställds post, kan du ge arbetsflödet namnet Process-EmployeeOnboarding.

Här är fler saker att tänka på när du utformar namngivningskonventionen för arbetsflöden:

  • Följ mönstret Överordnad-underordnad för logikappar där du vill markera en relation mellan ett eller flera arbetsflöden.
  • Ta hänsyn till om ett arbetsflöde publicerar eller använder ett meddelande.

Namn på arbetsflödesåtgärder

När du lägger till en utlösare eller åtgärd i arbetsflödet tilldelar designern automatiskt det allmänna standardnamnet för åtgärden. Åtgärdsnamn måste dock vara unika i arbetsflödet, så designern lägger till sekventiella numeriska suffix på efterföljande åtgärdsinstanser, vilket gör det svårt att läsa och dechiffrera utvecklarens ursprungliga avsikt.

Om du vill göra åtgärdsnamn mer meningsfulla och lättare att förstå kan du lägga till en kort uppgiftsbeskrivning efter standardtexten och använda Pascal Case-notation för konsekvens. För åtgärden Parsa JSON kan du till exempel använda ett namn som Parsa JSON-ChangeEmployeeRecord. Med den här metoden eller andra liknande metoder fortsätter du att komma ihåg att åtgärden är Parsa JSON och åtgärdens specifika syfte. Så om du behöver använda den här åtgärdens utdata senare i efterföljande arbetsflödesåtgärder kan du enklare identifiera och hitta dessa utdata.

Kommentar

För organisationer som använder uttryck i stor utsträckning bör du överväga en namngivningskonvention som inte höjs upp med hjälp av blanksteg (' '). Uttrycksspråket i Azure Logic Apps ersätter blanksteg med understreck ('_') , vilket kan komplicera redigeringen. Genom att undvika blanksteg i förväg kan du minska friktionen vid redigering av uttryck. Använd i stället ett bindestreck eller bindestreck ('-), som ger läsbarhet och inte påverkar uttrycksredigering.

För att undvika senare möjliga omarbetningar och problem kring underordnade beroenden, som skapas när du använder åtgärdsutdata, byter du namn på dina åtgärder omedelbart när du lägger till dem i arbetsflödet. Vanligtvis uppdateras underordnade åtgärder automatiskt när du byter namn på en åtgärd. Azure Logic Apps byter dock inte automatiskt namn på anpassade uttryck som du skapade innan du byter namn.

Anslut ionsnamn

När du skapar en anslutning i arbetsflödet får den underliggande anslutningsresursen automatiskt ett allmänt namn, till exempel sql eller office365. Precis som åtgärdsnamn måste anslutningsnamn också vara unika. Efterföljande anslutningar med samma typ får ett sekventiellt numeriskt suffix, till exempel sql-1, sql-2 och så vidare. Sådana namn har ingen kontext och gör det mycket svårt att skilja och mappa anslutningar till deras logikappar, särskilt för utvecklare som inte känner till utrymmet och måste ta på sig underhåll för dessa logikappar.

Därför är meningsfulla och konsekventa anslutningsnamn viktiga av följande skäl:

  • Läsbarhet
  • Enklare kunskapsöverföring och support
  • Kontroll

Återigen är det viktigt att ha en namngivningskonvention, även om formatet inte är alltför viktigt. Du kan till exempel använda följande mönster som en riktlinje:

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

Som ett konkret exempel kan du byta namn på en Service Bus-anslutning i en OrderQueue-logikapp eller ett arbetsflöde med CN-ServiceBus-OrderQueue som det nya namnet. Mer information finns i blogginlägget Turbo360 (tidigare Serverless360) logikappens metodtips, tips och tricks: #11 namngivningskonvention för anslutningsappar.

Hantera undantag med omfång och alternativ för "Kör efter"

Omfång ger möjlighet att gruppera flera åtgärder så att du kan implementera Try-Catch-Finally-beteende. Omfångsåtgärdens funktioner liknar regionkoncepteti Visual Studio. I designern kan du komprimera och utöka innehållet i ett omfång för att förbättra utvecklarproduktiviteten.

När du implementerar det här mönstret kan du också ange när omfångsåtgärden och åtgärderna ska köras inuti, baserat på föregående åtgärds körningsstatus, som kan vara Succeeded, Failed, Skipped eller TimedOut. Om du vill konfigurera det här beteendet använder du omfångsåtgärdens alternativ Kör efter ():runAfter

  • Lyckas
  • Har misslyckats
  • Hoppas över
  • Tidsgränsen har överskrids

Konsolidera delade tjänster

När du skapar integreringslösningar bör du överväga att skapa och använda delade tjänster för vanliga uppgifter. Du kan låta ditt team skapa och exponera en samling delade tjänster som ditt projektteam och andra kan använda. Alla får ökad produktivitet, enhetlighet och möjlighet att framtvinga styrning på organisationens lösningar. I följande avsnitt beskrivs några områden där du kan överväga att introducera delade tjänster:

Delad tjänst Orsaker
Centraliserad loggning Ge vanliga mönster för hur utvecklare instrumentera sin kod med lämplig loggning. Du kan sedan konfigurera diagnostikvyer som hjälper dig att fastställa gränssnittets hälsa och support.
Övervakning av affärsspårning och affärsaktivitet Samla in och exponera data så att experter på affärsämnen bättre kan förstå tillståndet för sina affärstransaktioner och utföra analysfrågor med självbetjäning.
Konfigurationsdata Separera programkonfigurationsdata från koden så att du enklare kan flytta programmet mellan miljöer. Se till att tillhandahålla en enhetlig konsekvent och enkelt replikerbar metod för åtkomst till konfigurationsdata så att projektteamen kan fokusera på att lösa affärsproblemet i stället för att lägga tid på programkonfigurationer för distribution. Annars, om varje projekt närmade sig denna separation på ett unikt sätt, kan du inte dra nytta av stordriftsfördelar.
Anpassade anslutningsprogram Skapa anpassade anslutningsappar för interna system som inte har fördefinierade anslutningsappar i Azure Logic Apps för att förenkla för projektteamet och andra.
Vanliga datauppsättningar eller dataflöden Exponera vanliga datauppsättningar och feeds som API:er eller anslutningsappar som projektteam kan använda och undvik att återuppfinna hjulet. Varje organisation har gemensamma datauppsättningar som de behöver för att integrera system i en företagsmiljö.

Granska, reflektera och lär dig

Då och då utvärderar du dina befintliga logikappar, särskilt när de misslyckas. Analysera inte bara affärsprocessen för att hitta vad och var du kan förbättra, utan även analysera arbetsflödets körningshistorik för att lära dig av fel, misstag och fel som har inträffat. Azure Logic Apps ger en så omfattande körningshistorik att du har hög sannolikhet att upptäcka nya saker om din app när du granskar arbetsflödets körningshistorik. Precis som all kodutveckling kan vissa kant- eller hörnfall uppstå. När du gör upptäckter uppdaterar du dina gränssnitt för att ta hänsyn till dessa situationer och förbättrar dina lösningars övergripande tillförlitlighet.

En verklighet för projektteam är att utvecklare försöker samla in fel allmänt för att åtminstone få ett visst skydd mot problem. När ditt team upptäcker och bättre förstår var saker kan gå fel kan du få mer beskrivande information om hur du skyddar mot problem.

På samma sätt som organisationer regelbundet utför "röda team"-övningar, till exempel intrångstestning eller nätfiskeförsök, är säkerhet inte en "set-and-forget"-aktivitet. När nya autentiseringsscheman och metoder blir tillgängliga går du regelbundet tillbaka till dina gränssnitt, granskar dina säkerhetsåtgärder och införlivar relevanta och lämpliga nya utvecklingar som ger de säkraste metoderna.

DevOps är ett annat område som du regelbundet vill utvärdera. När Microsoft eller communityn introducerar nya mallar eller metoder utvärderar du dessa uppdateringar för att avgöra om du kan få fler fördelar.

Nästa steg

Nu har du lärt dig mer om tillgängliga migreringsmetoder, planeringsöverväganden och metodtips för att flytta BizTalk Server-arbetsbelastningar till Azure Integration Services. Om du vill ge detaljerad feedback om den här guiden kan du använda följande formulär:

Ge feedback om migreringsvägledning för BizTalk Server till Azure Integration Services