Migreringsmetoder för BizTalk Server till Azure Logic Apps
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:
Big bang
En "big bang" eller "direkt övergång" är en metod som 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.
Vi rekommenderar att du endast överväger den här metoden om du har små, låg komplexitet BizTalk-arbetsbelastningar, ämnesexperter (SMF) som känner till din BizTalk-miljö och direkta mappningar mellan BizTalk-funktionerna som du för närvarande använder och Azure Logic Apps. Erfarenhet av Azure Logic Apps minskar också riskerna avsevärt med att följa den här metoden.
Iterativ eller vågbaserad (rekommenderas)
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 dina BizTalk Server-lösningar till serverlösa eller molnbaserade lösningar innan du inaktiverar serverinfrastrukturen om du planerar att flytta till Azure Logic Apps eller Azure i allmänhet. Det här valet är en utmärkt strategi om din organisation vill omvandla verksamheten helt till molnet.
BizTalk Server och Azure Logic Apps har olika arkitekturer. För att ytterligare modernisera dina lösningar kan du använda Azure Integration Services för att utöka funktionerna i Azure Logic Apps som hanterar viktiga kundintegreringsbehov.
För en högre avkastning på investeringen (ROI) rekommenderar vi att alla BizTalk-migreringar använder de grundläggande inbyggda funktionerna i Azure Logic Apps (Standard) så mycket som möjligt och utökas med andra Azure Integration Services efter behov. Den här kombinationen gör ytterligare scenarier möjliga, till exempel:
- Molnbaserade hybridfunktioner med Azure Logic Apps (Standard) med hybriddistribution
- Tillståndskänsliga eller tillståndslösa arbetsflödesfunktioner i Azure Logic Apps (Standard)
- Intern, inbyggd (inbyggt) stordator och mellanregisterintegrering med anslutningsappar i Azure Logic Apps (Standard)
- Pub-sub-meddelanden med Azure Service Bus
- Avancerade SOAP-funktioner i Azure API Management
Leverera ett BizTalk-migreringsprojekt
För att slutföra ett sådant projekt rekommenderar vi att du följer den iterativa eller vågbaserade metoden och använder Scrum-processen. Även om Scrum inte innehåller ett Sprint Zero-koncept (Sprint 0) för aktiviteter före sprinten rekommenderar vi att du fokuserar din första sprint på laganpassning och teknisk identifiering. Efter Sprint 0 följer du körningen av flera migreringssprintar och fokuserar på att släppa funktioner mot en minsta livskraftig produkt (MVP).
Sprint 0
Under den här sprinten rekommenderar vi att du kör BizTalk Server Environments Discovery med Waves Planning. Att förstå projektets bredd och djup är avgörande för framgång. Följande lista innehåller de specifika områden som ska åtgärdas under Sprint 0:
| Område | beskrivning |
|---|---|
| Identifiering | 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. Du måste också tilldela komplexitet till varje gränssnitt eller process. Under den här katalogiseringsprocessen samlar du in följande information för att prioritera arbetet: – 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 – Program- och systemberoenden |
| Arkitekturdesign | Skapa den arkitektur på hög nivå som ska användas som fokuspunkt för migreringen. Den här designen innehåller element som hanterar funktionella och icke-funktionella behov på hög nivå. |
| Mvp-definition (Minimum Viable Product) | Definiera de första vågfunktionerna. Med andra ord de processer som behöver stöd när du har slutfört den första vågen. |
| Inledande kvarvarande migreringslogg | Definiera de första vågfunktionerna och deras arbetsobjekt med teknisk utarbetande. |
Identifieringsverktyg
För att hjälpa dig med identifiering av migrering kan du använda kommandoradsverktyget Azure Integration Migrator, även kallat biztalkmigreringsverktyget, som är ett Microsoft-projekt med öppen källkod. Det här verktyget använder en stegvis metod som hjälper dig att hitta användbara insikter och strategier för att migrera dina lösningar till molnet. Vi rekommenderar att du endast använder migreringsverktyget för identifiering och rapportgenerering. Du kanske också vill överväga att använda andra produkter för identifiering från partner som tillhandahåller lösningar i det här utrymmet.
Om du vill ha ett annat sätt att generera en inventering med BizTalk Server-element kan du använda BizTalk Documenter, som har utvecklats av Mark Brimble. Det här verktyget fungerar med BizTalk Server 2020, trots att det anges att endast BizTalk Server 2016 stöds.
Arkitekturdesign
Azure Logic Apps har funktioner som gör att du kan återanvända BizTalk Server-tillgångar, men du måste ha en modern arkitekturdesign för att kunna utnyttja fördelarna med modernare funktioner. Ur ett funktionellt perspektiv använder du din affärslogik så mycket som möjligt. Ur ett produktmoderniseringsperspektiv använder du Azure Integration Services så mycket du kan. När det gäller kvalitet och övergripande problem rekommenderar vi att du använder Azure Well-Architected Framework.
I det här ramverket är BizTalk-migreringar verksamhetskritiska arbetsbelastningar. Den här termen beskriver samlingar av programresurser som kräver hög tillgänglighet på plattformen, vilket innebär att de alltid måste vara tillgängliga, operativa och motståndskraftiga mot fel.
Om du vill slutföra arkitekturdesignen för din BizTalk-migrering följer du Designmetodik för verksamhetskritiska arbetsbelastningar i Azure. En inledande arkitektur och topologi finns i och använder referensarkitekturen som beskrivs i Grundläggande företagsintegrering i Azure i Azure Architecture Center.
Om du vill konfigurera din första miljö använder du Azure Integration Services Landing Zone Accelerator, som är avsedd för att skapa och distribuera en integrationsplattform med en typisk design för landningszoner för företag.
Mvp-definition (Minimum Viable Project)
En MVP är en produktversion som har precis tillräckligt med funktioner som kan användas av kunder. Den här versionen visar produktens möjligheter och potential att samla in kundfeedback och fortsätta arbetet. För en BizTalk-migrering återspeglar MVP-definitionen de iterationer, vågor eller grupper av sprintar som du behöver för att göra framsteg mot arbetsfunktioner och för att uppfylla de inledande integreringsarbetsbelastningarna.
Vi rekommenderar att MVP-definitionen innehåller följande affärsresultat, som uttrycks som epos i Scrum-terminologi:
Affärsresultat (epos)
- Vilket är det primära målet som du vill uppnå?
- Vilka funktioner eller funktioner måste du ta itu med för den här MVP:en?
- Vilka är affärsprocessflödena? Den här frågan ger möjlighet att optimera befintliga processer som stöds av BizTalk Server.
- Vilka är affärsbesluten, till exempel affärsresultat som påverkar MVP eller vad är resurstillgängligheten?
Vi rekommenderar att din MVP inkluderar följande processer i omfånget, som uttrycks som funktioner i Scrum-terminologi:
Processer inom omfånget (funktioner)
| Funktion | beskrivning |
|---|---|
| Systemfunktioner på hög nivå | Du kan extrahera den här informationen med hjälp av identifieringsverktygen och uttrycka beskrivningarna när det gäller funktioner. |
| Skådespelare eller personas | Använd den här informationen för att fastställa vilka personer som påverkas av MVP:s scenarier som stöds. |
| Orkestreringar | Du kan extrahera den här informationen med hjälp av identifieringsverktygen. |
| Dataentiteter och meddelanden | De här elementen ger dig möjlighet att lära dig om du kan inkludera ytterligare förbättringar i de data som utbyts av BizTalk Server-miljön. |
| Datamappningar | Dagens värld förlitar sig på JSON. BizTalk Server använder dock XML. Det här ögonblicket är ett utmärkt tillfälle att bestämma dataformatet och konverteringsbehoven för den nya plattformen. |
| Affärsregler | Dessa datacentrerade regler ger dig möjlighet att tänka om eller återanvända dem genom att använda Azure Logic Apps-funktioner. |
| Överväganden för datasekretess | Du måste prioritera sekretessen. Såvida inte kunden väljer hybriddistributionsmodellen i Azure Logic Apps (Standard) måste du hantera det här området i varje våg på grund av potentiella ändringar i distributionsmiljön. |
| Regelöverväganden | Den här aspekten är mer relevant om dina kunder inte har molnbaserade arbetsbelastningar. |
| Byggt för säkerhet | Du måste utforma varje funktion med säkerhet i åtanke. |
| Föreslagna funktioner för samexistens | När du levererar varje våg har du en viss grad av samexistens. Du måste justera den här hybridarkitekturen med befintliga servicenivåindikatorer (SLO: er) och servicenivåmål (SLO). |
| Icke-funktionella överväganden | Affärsprocesser kan ha olika icke-funktionella krav. Allt måste inte ske i realtid. Omvänt är inte allt en batchprocess. |
| Affärsmått | En valfri möjlighet att visa förloppet för migreringsarbetet. |
Du vill också identifiera och lista de olika variabler utanför omfånget som formar omfånget för ditt MVP-arbete, till exempel:
- Resurstillgänglighet
- Risker
- Dokumentation
- Tid till marknad
Inledande kvarvarande uppgifter
Den första kvarvarande informationen är en uppsättning användarberättelser som du grupperar i Funktioner för att skapa processerna i omfånget för din MVP. Med andra ord representeras en MVP av Scrum-objekt som kallas epos, funktioner och användarberättelser. Helst omfattar varje Epic en grupp BizTalk-program eller BizTalk-projekt. Du kan använda den enkla regeln som associerar ett BizTalk-program eller BizTalk-projekt med en funktion.
Anta till exempel att du har ett BizTalk Server-projekt med orkestreringen "LoanRequests" som kunderna använder för att begära banklån. Så du har följande föreslagna funktion och användarberättelse:
Funktion: Lånebearbetning
Användarberättelse: "Som kund vill jag skicka in en låneansökan så att banken kan lägga till pengar på mitt säkra konto."
Den här användarberättelsen, som för närvarande kan finnas som en implementering i BizTalk Server, har följande uppgifter att implementera med hjälp av Azure Logic Apps och Azure Integration Services:
- Samla in BizTalk-återanvändbara artefakter.
- Skapa ett arbetsflöde för lånebegäran med Hjälp av Azure Logic Apps.
- Konfigurera asynkrona meddelanden med Hjälp av Azure Service Bus eller IBM MQ.
- Mappa JSON till XML-data med ett Azure Logic Apps-arbetsflöde.
- Anpassa Azure Integration Services efter behov för meddelandemönster.
Följande diagram visar de föreslagna varaktigheterna för epos, funktioner, användarberättelser och uppgifter, som delar upp användarberättelser. Även om implementeringsbeslut påverkar dessa varaktigheter förutsätter de att du använder befintliga BizTalk-artefakter i Azure Logic Apps. Skapa dina Standard-arbetsflöden med hjälp av de fördefinierade arbetsflödesmallarna så mycket som möjligt.
Migreringsvågor (sprintar)
När ditt team har slutfört Sprint 0 bör du ha en tydlig vy över MVP:en att bygga. En våg är en uppsättning sprintar. Den första kvarvarande informationen bör innehålla arbetsobjekt som följer nästa diagram så mycket som möjligt:
Under en våg slutför teamet aktiviteterna för att migrera, testa och släppa till produktion. Vi tittar närmare på vad som händer i varje våg.
Migrera
Under varje våg fokuserar migreringen på de överenskomna användarberättelserna. För den första vågen fokuserar ditt team på den första kvarvarande informationen. Teknikbeslut måste använda informationen i mappningen av BizTalk Server-funktioner, som beskrivs av Funktionsmatchning – Varför migrera från BizTalk Server till Azure Logic Apps?
Följande diagram visar de händelser som ska inträffa under migreringsvågor:
| Steg | Description |
|---|---|
| 1 | Identifiera befintliga BizTalk-appar och gränssnitt. Även om den introducerades i Sprint 0 bör den här aktiviteten inträffa när varje våg startar. Kunder kan fortsätta att göra ändringar i din BizTalk-miljö. Resurser: - BizTalk-migreringsverktyg - BizTalk Documenter-verktyg |
| 2 | Konfigurera din första migreringsmiljö. Du kan använda Azure Integration Services Landing Zone Accelerator, som är ett ramverk för molnimplementering för att skapa och distribuera en integrationsplattform som har en typisk design för landningszoner för företag. Som arbetsbelastningsägare kan du uppnå ditt måltekniska tillstånd med hjälp av den tillhandahållna arkitekturvägledningen och BizTalk-migreringsresurserna. Ett exempel på arkitektur finns i Exempel på migreringsmiljö. |
| 3 | Skapa och testa standardarbetsflöden för logikappar som körs i Azure Logic Apps med en enda klientorganisation med hjälp av antingen Azure Portal eller Visual Studio Code med Tillägget Azure Logic Apps (Standard). Med Visual Studio Code kan du lokalt utveckla, testa och lagra ditt logikappprojekt med valfritt källkontrollsystem. Mer information finns i följande dokumentation: - Skapa ett exempel på ett standardarbetsflöde för logikappar med hjälp av Azure Portal - Skapa ett exempel på ett standardarbetsflöde för logikappar med Visual Studio Code Ett diagram som visar ett exempel på logikappar och anslutningar finns i Exempel på migreringsmiljö. |
| 4 | För att få alla fördelar med att enkelt och konsekvent distribuera dina standardlogikapparbetsflöden i olika miljöer och plattformar måste du också automatisera bygg- och distributionsprocessen. Tillägget Azure Logic Apps (Standard) för Visual Studio Code innehåller verktyg för att skapa och underhålla automatiserade bygg- och distributionsprocesser med Hjälp av Azure DevOps. Mer information finns i Automatisera kompilering och distribution för standardarbetsflöden för logikappar med Azure DevOps. |
| 5 | Om du vill distribuera verksamhetskritiska standardlogikappar som alltid är tillgängliga och dynamiska, även under uppdateringar eller underhåll, aktiverar du noll driftstoppsdistribution genom att skapa och använda distributionsplatser. Noll stilleståndstid innebär att slutanvändarna inte ska uppleva avbrott eller driftstopp när du distribuerar nya versioner av din app. Mer information finns i Konfigurera distributionsplatser för att aktivera distribution utan driftstopp i Azure Logic Apps. |
Följande diagram visar ett exempel på en inledande migreringsmiljö med en standardlogikapp som samordnar arbetsflöden som kommunicerar med API:er, tjänster, hybridlösningar och lokala resurser:
Test
Varje våg har sina egna testaktiviteter, som är inbäddade i varje användarberättelse. Om du vill använda shift-left-testning kontrollerar du att du slutför följande uppgifter:
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 automatiseringsmetoder eller resurser du använder är du på god väg att få repeterbara, konsekventa och 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 Logic Apps. 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.
Frisläpp till produktion
När ditt team har slutfört och uppfyller definitionen av klar för Användarberättelser bör du överväga följande uppgifter:
Skapa en kommunikationsplan för din lansering till produktion.
Gör en "cut-over"-plan.
En detaljerad plan innehåller 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
- Genrep
- Personer
- Schemalägg uppskattningar
- Inaktivera gränssnitt i den gamla plattformen
- Aktivera gränssnitt i den nya plattformen
- Valideringstestning
Fastställ en återställningsplan.
Kör valideringstestning.
Planera för drift eller produktionsstöd.
Välj "go or no go"-kriterier för att släppa till produktion.
Fira teamets framgång.
Håll en retrospektiv.
Metodtips för en BizTalk-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:
- Förkortningsexempel för Azure-resurser
- Azure Naming Tool, som genererar Azure-kompatibla namn, hjälper dig att standardisera på namn och automatiserar namngivningsprocessen.
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 arbetsflöden 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.
Anslutningsnamn
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 ger ingen kontext, vilket gör det mycket svårt att skilja och mappa anslutningar till deras arbetsflöden, särskilt för utvecklare som inte känner till lösningsutrymmet och måste underhålla dessa arbetsflöden.
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 ett OrderQueue-logikapparbetsflöde med CN-ServiceBus-OrderQueue som det nya namnet. Mer information finns i blogginlägget Turbo360 (tidigare Serverless360), Metodtips för logikapp, 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. 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ö. |
Nästa steg
Nu har du lärt dig mer om tillgängliga migreringsmetoder och metodtips för att flytta BizTalk Server-arbetsbelastningar till Azure Logic Apps. Om du vill ge detaljerad feedback om den här guiden kan du använda följande formulär: