Migratiemethoden voor BizTalk Server naar Azure Logic Apps
Deze handleiding behandelt migratiestrategieën en -resources, samen met planningsoverwegingen en aanbevolen procedures om u te helpen bij het leveren van succesvolle migratieoplossingen.
Notitie
Raadpleeg de volgende documentatie voor een migratieoverzicht en handleiding voor het kiezen van services in Azure voor uw migratie:
Strategieopties
In de volgende secties worden verschillende migratiestrategieën beschreven, samen met hun voor- en nadelen:
Oerknal
Een 'big bang' of 'directe overstap' is een benadering waarvoor veel planning is vereist en die niet wordt aanbevolen voor organisaties die niet bekend zijn met Azure Logic Apps of die grote systemen of oplossingen hebben die moeten worden gemigreerd. Wanneer een organisatie een nieuwe technologiestack implementeert, leiden nieuwe leertrajecten meestal vaak tot gevolg. Door te vroeg of te veel te investeren, hebt u niet de mogelijkheid om te profiteren van geleerde lessen en aanpassen zonder dat u aanzienlijke aanpassingen riskeert.
Deze benadering kan ook langer duren om de waarde te verkrijgen of te maken. Als u al enkele migratieactiviteiten hebt voltooid, maar u deze nog niet in productie hebt vrijgegeven vanwege andere lopende of actieve werkzaamheden, genereren uw gemigreerde artefacten geen waarde voor uw organisatie.
We raden u aan deze aanpak alleen te overwegen als u kleine, lage complexiteit BizTalk-workloads, deskundigen (KMO's) hebt die uw BizTalk-omgeving kennen en directe toewijzingen tussen de BizTalk-functies die u momenteel gebruikt en Azure Logic Apps. Ervaring met Azure Logic Apps vermindert ook aanzienlijk de risico's met het volgen van deze aanpak.
Iteratief of golf gebaseerd (aanbevolen)
Deze aanpak biedt uw organisatie de mogelijkheid om incrementeel waarde te bereiken, maar eerder dan anders. Uw projectteam kan vroeg leren over de technologiestack met behulp van retrospectieven. U kunt bijvoorbeeld een bestaande BizTalk-interface of -project implementeren in productie en vervolgens meer te weten komen over de behoeften van de oplossing, waaronder beheer, schaalbaarheid, bewerkingen en bewaking. Nadat u deze kennis hebt bereikt, kunt u sprints plannen om bestaande mogelijkheden te optimaliseren of nieuwe patronen introduceren die u vervolgens in toekomstige werkzaamheden kunt gebruiken.
Ongeacht uw aanpak, als u van plan bent over te stappen op Azure Logic Apps of Azure in het algemeen, is het raadzaam om uw BizTalk Server-oplossingen te herstructureren in serverloze of cloudeigen oplossingen voordat u uw serverinfrastructuur buiten gebruik gaat stellen. Deze keuze is een uitstekende strategie als uw organisatie het bedrijf volledig wil transformeren naar de cloud.
BizTalk Server en Azure Logic Apps hebben verschillende architecturen. Als u uw oplossingen verder wilt moderniseren, kunt u Azure Integration Services gebruiken om de mogelijkheden in Azure Logic Apps uit te breiden die voldoen aan de belangrijkste behoeften van de klantintegratie.
Voor een hoger rendement op investeringen (ROI) raden we aan dat elke BizTalk-migratie zoveel mogelijk gebruikmaakt van de belangrijkste systeemeigen mogelijkheden in Azure Logic Apps (Standard) en zo nodig wordt uitgebreid met andere Azure Integration Services. Deze combinatie maakt extra scenario's mogelijk, bijvoorbeeld:
- Systeemeigen hybride cloudmogelijkheden met Azure Logic Apps (Standard) met hybride implementatie
- Stateful of stateless werkstroommogelijkheden in Azure Logic Apps (Standard)
- Systeemeigen, ingebouwde (in-app) mainframe en midranges-integratie met connectors in Azure Logic Apps (Standard)
- Pub-subberichten met Behulp van Azure Service Bus
- Geavanceerde SOAP-mogelijkheden in Azure API Management
Een BizTalk-migratieproject leveren
Om een dergelijk project te voltooien, raden we u aan de iteratieve of golfgebaseerde benadering te volgen en het Scrum-proces te gebruiken. Hoewel Scrum geen Sprint Zero-concept (Sprint 0) bevat voor pre-sprintactiviteiten, raden we u aan uw eerste sprint te richten op teamuitlijning en technische detectie. Na Sprint 0 volgt u de uitvoering van meerdere migratiesprints en richt u zich op het vrijgeven van functies voor een minimum viable product (MVP).
Sprint 0
Tijdens deze sprint raden we u aan BizTalk Server Environments Discovery uit te voeren met Waves Planning. Inzicht in de breedte en diepte van het project is essentieel voor succes. De volgende lijst bevat de specifieke gebieden die tijdens Sprint 0 moeten worden aangepakt:
| Oppervlakte | Description |
|---|---|
| Detectie | Leg gegevens vast over al uw interfaces en toepassingen, zodat u het aantal interfaces en toepassingen kunt leren dat u moet migreren. U moet ook complexiteit toewijzen aan elke interface of elk proces. Verzamel tijdens dit catalogusproces de volgende informatie om prioriteit te geven aan het werk: - Adapters die in gebruik zijn - BizTalk Server-functies die in gebruik zijn, zoals Bewaking van bedrijfsactiviteiten, Engine voor bedrijfsregels, EDI, enzovoort - Aangepaste code, zoals expressies, kaarten en pijplijnonderdelen - Berichtdoorvoer - Berichtgrootten -Afhankelijkheden - Toepassings- en systeemafhankelijkheden |
| Architectuurontwerp | Maak de architectuur op hoog niveau die moet worden gebruikt als het centrale punt voor de migratie. Dit ontwerp bevat elementen die betrekking hebben op functionele en niet-functionele behoeften op hoog niveau. |
| Minimum viable product (MVP) definitie | Definieer de eerste golffuncties. Met andere woorden, de processen die ondersteuning nodig hebben nadat u de eerste golf hebt voltooid. |
| Initiële migratieachterstand | Definieer de eerste golffuncties en hun werkitems met technische uitwerking. |
Detectiehulpprogramma's
Voor hulp bij migratiedetectie kunt u het opdrachtregelprogramma Azure Integration Migrator gebruiken, ook wel het BizTalk Migration-hulpprogramma genoemd. Dit is een opensource-project van Microsoft. Dit hulpprogramma maakt gebruik van een gefaseerde benadering om nuttige inzichten en strategieën te ontdekken voor het migreren van uw oplossingen naar de cloud. U wordt aangeraden het migratiehulpprogramma alleen te gebruiken voor detectie en het genereren van rapporten. U kunt ook andere producten gebruiken voor detectie van partners die oplossingen in deze ruimte bieden.
Voor een andere manier om een inventaris te genereren met BizTalk Server-elementen, kunt u De BizTalk Documenter gebruiken, die is ontwikkeld door Mark Brimble. Dit hulpprogramma werkt met BizTalk Server 2020, ondanks dat alleen BizTalk Server 2016 wordt ondersteund.
Architectuurontwerp
Hoewel Azure Logic Apps mogelijkheden biedt waarmee u BizTalk Server-assets opnieuw kunt gebruiken, moet u een modern architectuurontwerp hebben om de voordelen van modernere mogelijkheden te omarmen. Gebruik vanuit functioneel perspectief uw bedrijfslogica zo veel mogelijk. Gebruik Azure Integration Services zoveel mogelijk vanuit het perspectief van product modernisatie. Voor kwaliteits- en kruislingse problemen raden we u aan het Azure Well-Architected Framework te gebruiken.
In dit kader zijn BizTalk-migraties bedrijfskritieke workloads. In deze term worden verzamelingen toepassingsresources beschreven waarvoor hoge beschikbaarheid op het platform is vereist, wat betekent dat ze altijd beschikbaar, operationeel en bestand moeten zijn tegen fouten.
Volg ontwerpmethodologie voor bedrijfskritieke workloads in Azure om het architectuurontwerp voor uw BizTalk-migratie te voltooien. Voor een eerste architectuur en topologie bekijkt en gebruikt u de referentiearchitectuur die wordt beschreven in Basic Enterprise Integration in Azure in het Azure Architecture Center.
Als u uw eerste omgeving wilt instellen, gebruikt u de Azure Integration Services Landing Zone Accelerator, die is bedoeld voor het bouwen en implementeren van een integratieplatform met behulp van een typisch ontwerp voor een landingszone voor ondernemingen.
Minimum viable project (MVP) definitie
Een MVP is een productversie die net genoeg bruikbare functies van de klant heeft. Deze versie toont de mogelijkheden en mogelijkheden van het product om feedback van klanten te verzamelen en het werk voort te zetten. Voor een BizTalk-migratie weerspiegelt uw MVP-definitie de iteraties, golven of groepen sprints die u nodig hebt om vooruitgang te boeken in de richting van werkfuncties en om te voldoen aan de eerste integratieworkloads.
Het is raadzaam dat uw MVP-definitie de volgende bedrijfsresultaten bevat, die worden uitgedrukt als Epics in Scrum-terminologie:
Bedrijfsresultaten (Epics)
- Wat is het primaire doel dat u wilt bereiken?
- Welke mogelijkheden of functies moet u gebruiken voor deze MVP?
- Wat zijn de bedrijfsprocesstromen? Deze vraag biedt de mogelijkheid om bestaande processen te optimaliseren die worden ondersteund door BizTalk Server.
- Wat zijn de zakelijke beslissingen, bijvoorbeeld bedrijfsresultaten die van invloed zijn op de MVP of wat is de beschikbaarheid van resources?
Het is raadzaam dat uw MVP de volgende in-scope processen bevat, die worden uitgedrukt als functies in Scrum-terminologie:
Processen binnen het bereik (functies)
| Functie | Beschrijving |
|---|---|
| Systeemfunctionaliteit op hoog niveau | U kunt deze informatie extraheren met behulp van de detectiehulpprogramma's en de beschrijvingen in termen van functies uitdrukken. |
| Acteurs of persona's | Gebruik deze informatie om de personen te bepalen die worden beïnvloed door de ondersteunde scenario's van de MVP. |
| Indelingen | U kunt deze informatie extraheren met behulp van de detectiehulpprogramma's. |
| Gegevensentiteiten en -berichten | Deze elementen bieden u de mogelijkheid om te leren of u verdere verbeteringen kunt aanbrengen in de gegevens die worden uitgewisseld door de BizTalk Server-omgeving. |
| Gegevenstoewijzingen | De wereld van vandaag is afhankelijk van JSON. BizTalk Server maakt echter gebruik van XML. Dit moment is een geweldige kans om de gegevensindeling en conversiebehoeften voor het nieuwe platform te bepalen. |
| Bedrijfsregels | Deze gegevensgerichte regels bieden u de mogelijkheid om hun benadering te herzien of opnieuw te gebruiken door gebruik te maken van de mogelijkheden van Azure Logic Apps. |
| Overwegingen voor gegevensprivacy | U moet privacy een hoogste prioriteit hebben. Tenzij uw klant het hybride implementatiemodel in Azure Logic Apps (Standard) kiest, moet u dit gebied in elke golf aanpakken vanwege mogelijke wijzigingen in de implementatieomgeving. |
| Overwegingen voor regelgeving | Dit aspect is relevanter als uw klanten geen cloudworkloads hebben. |
| Geïntegreerde beveiliging | U moet elke functie ontwerpen met het oog op beveiliging. |
| Voorgestelde functies voor co-existentie | Wanneer u elke golf levert, hebt u een zekere mate van co-existentie. U moet deze hybride architectuur afstemmen op bestaande SLA's (Service Level Indicators) en Service Level Objectives (SLO's). |
| Niet-functionele overwegingen | Bedrijfsprocessen kunnen verschillende niet-functionele vereisten hebben. Niet alles moet in realtime gebeuren. Omgekeerd is niet alles een batchproces. |
| Zakelijke metrische gegevens | Een optionele mogelijkheid om de voortgang van het migratiewerk weer te geven. |
U wilt ook de verschillende niet-bereikvariabelen identificeren en vermelden die het bereik van uw MVP vormen, bijvoorbeeld:
- Resourcebeschikbaarheid
- Risico's
- Documentatie
- Implementatietijd
Initiële achterstand
De eerste achterstand is een set gebruikersverhalen die u groepeert in Functies om de processen binnen het bereik voor uw MVP te bouwen. Met andere woorden, een MVP wordt vertegenwoordigd door Scrum-items die epics, functies en gebruikersverhalen worden genoemd. Idealiter omvat elke Epic een groep BizTalk-toepassingen of BizTalk-projecten. U kunt de eenvoudige regel gebruiken die één BizTalk-toepassing of BizTalk-project koppelt aan een functie.
Stel dat u een BizTalk Server-project hebt met een indeling met de naam 'LoanRequests' die klanten gebruiken om bankleningen aan te vragen. U hebt dus de volgende voorgestelde functie en gebruikersverhaal:
Functie: Verwerking van leningen
Gebruikersverhaal: "Als klant wil ik een leningsaanvraag indienen zodat de bank geld kan toevoegen aan mijn beveiligde rekening."
Dit gebruikersverhaal, dat momenteel bestaat als een implementatie in BizTalk Server, heeft de volgende taken om te implementeren met behulp van Azure Logic Apps en Azure Integration Services:
- Verzamel herbruikbare artefacten van BizTalk.
- Een werkstroom voor een leningsaanvraag maken met behulp van Azure Logic Apps.
- Configureer asynchrone berichten met behulp van Azure Service Bus of IBM MQ.
- JSON toewijzen aan XML-gegevens met behulp van een Azure Logic Apps-werkstroom.
- Pas Azure Integration Services aan zoals vereist voor berichtpatronen.
In het volgende diagram ziet u de voorgestelde duur voor Epics, Functies, Gebruikersverhalen en Taken, die gebruikersverhalen onderverdelen. Hoewel implementatiebeslissingen van invloed zijn op deze duur, gaan ze ervan uit dat u bestaande BizTalk-artefacten in Azure Logic Apps gebruikt. Maak uw Standaardwerkstromen zoveel mogelijk met behulp van de vooraf gemaakte werkstroomsjablonen .
Migratiegolven (Sprints)
Nadat uw team Sprint 0 heeft voltooid, moet u een duidelijk beeld hebben van de MVP die u wilt bouwen. Een golf is een reeks sprints. De eerste achterstand moet werkitems bevatten die zo veel mogelijk aan het volgende diagram voldoen:
Tijdens een golf voltooit uw team de activiteiten voor het migreren, testen en vrijgeven van productie. Laten we eens kijken wat er in elke golf gebeurt.
Migrate
Tijdens elke golf richt de migratie zich op de overeengekomen gebruikersverhalen. Voor de eerste golf richt uw team zich op de eerste achterstand. Beslissingen over technologie moeten gebruikmaken van de informatie in de toewijzing van BizTalk Server-functies, zoals beschreven in functiematchup: waarom migreren van BizTalk Server naar Azure Logic Apps?
In het volgende diagram ziet u de gebeurtenissen die moeten plaatsvinden tijdens migratiegolven:
| Stap | Omschrijving |
|---|---|
| 1 | Ontdek bestaande BizTalk-apps en -interfaces. Hoewel deze activiteit is geïntroduceerd in Sprint 0, moet deze activiteit plaatsvinden wanneer elke golf begint. Klanten kunnen wijzigingen blijven aanbrengen in uw BizTalk-omgeving. Weg: - BizTalk Migration Tool - BizTalk Documenter-hulpprogramma |
| 2 | Stel uw eerste migratieomgeving in. U kunt de Azure Integration Services Landing Zone Accelerator gebruiken. Dit is een cloudacceptatieframework voor het bouwen en implementeren van een integratieplatform met een typisch ontwerp voor een landingszone voor ondernemingen. Als eigenaar van de workload kunt u uw technische doelstatus zeker bereiken met behulp van de opgegeven architectuurrichtlijnen en BizTalk-migratieresources. Zie Voorbeeld van een migratieomgeving voor een voorbeeldarchitectuur. |
| 3 | Maak en test standaardwerkstromen voor logische apps die worden uitgevoerd in Azure Logic Apps met één tenant met behulp van Azure Portal of Visual Studio Code met de Extensie Azure Logic Apps (Standard). Met Visual Studio Code kunt u uw logische app-project lokaal ontwikkelen, testen en opslaan met behulp van elk broncodebeheersysteem. Zie de volgende documentatie voor meer informatie: - Een voorbeeld van een standaardwerkstroom voor logische apps maken met behulp van Azure Portal - Een voorbeeld van een standaardwerkstroom voor logische apps maken met Visual Studio Code Zie Voorbeeldmigratieomgeving voor een diagram met een voorbeeld van een logische app en verbindingen. |
| 4 | Als u de volledige voordelen van het eenvoudig en consistent implementeren van uw standaardwerkstromen voor logische apps in verschillende omgevingen en platforms wilt krijgen, moet u ook uw build- en implementatieproces automatiseren. De Azure Logic Apps-extensie (Standard) voor Visual Studio Code biedt hulpprogramma's voor het maken en onderhouden van geautomatiseerde build- en implementatieprocessen met behulp van Azure DevOps. Zie Build en implementatie automatiseren voor standaardwerkstromen voor logische apps met Azure DevOps voor meer informatie. |
| 5 | Als u essentiële logische standaard-apps wilt implementeren die altijd beschikbaar en responsief zijn, zelfs tijdens updates of onderhoud, schakelt u geen downtime-implementatie in door implementatiesites te maken en te gebruiken. Geen downtime betekent dat wanneer u nieuwe versies van uw app implementeert, eindgebruikers geen onderbreking of downtime ervaren. Zie Implementatiesites instellen om implementatiesites zonder downtime in te schakelen in Azure Logic Apps voor meer informatie. |
In het volgende diagram ziet u een voorbeeld van een eerste migratieomgeving met een standaard logische app waarmee werkstromen worden ingedeeld die communiceren met API's, services, hybride oplossingen en on-premises resources:
Testen
Elke golf heeft zijn eigen testactiviteiten, die zijn ingesloten in elk gebruikersverhaal. Als u shift-left testen wilt gebruiken, moet u de volgende taken uitvoeren:
Automatiseer uw tests.
Azure Logic Apps (Standard) bevat de mogelijkheid om geautomatiseerde tests uit te voeren. De volgende lijst bevat meer informatie en bronnen die vrij beschikbaar zijn op GitHub:
Geautomatiseerd testen met Azure Logic Apps (Standard) van het Azure Logic Apps-team
Met Azure Logic Apps (Standard) is geautomatiseerd testen niet langer moeilijk uit te voeren, vanwege de onderliggende architectuur, die is gebaseerd op de Azure Functions-runtime en overal kan worden uitgevoerd die Azure Functions kan uitvoeren. U kunt tests schrijven voor werkstromen die lokaal of in een CI/CD-pijplijn worden uitgevoerd. Zie het voorbeeldproject voor het Azure Logic Apps Test Framework voor meer informatie.
Dit testframework bevat de volgende mogelijkheden:
- Schrijf geautomatiseerde tests voor end-to-end-functionaliteit in Azure Logic Apps.
- Voer gedetailleerde validatie uit op het uitvoerings- en actieniveau van de werkstroom.
- Controleer tests in een Git-opslagplaats en voer lokaal of binnen CI/CD-pijplijnen uit.
- Mock-testmogelijkheden voor HTTP-acties en Azure-connectors.
- Configureer tests om verschillende instellingswaarden uit productie te gebruiken.
Integratieplaybook: Logic Apps Standard Testing van Michael Stephenson, Microsoft MVP
Het testframework integration playbook is gebaseerd op het door Microsoft geleverde testframework en biedt ondersteuning voor aanvullende scenario's:
- Verbinding maken met een werkstroom in een standaard logische app.
- Haal de callback-URL op, zodat u de werkstroom vanuit een test kunt activeren.
- Controleer de resultaten van de werkstroomuitvoering.
- Controleer de invoer en uitvoer van de bewerking uit de uitvoeringsgeschiedenis van de werkstroom.
- Sluit aan op geautomatiseerde testframeworks die ontwikkelaars van logische apps kunnen gebruiken.
- Sluit u aan op SpecFlow om gedraggestuurde ontwikkeling (BDD) voor logische apps te ondersteunen.
Ongeacht welke automatiseringsmethoden of resources u gebruikt, bent u goed op weg naar herhaalbare, consistente en geautomatiseerde integratietests.
Test met gesimuleerde antwoorden instellen met behulp van statische resultaten.
Ongeacht of u geautomatiseerde tests instelt, kunt u de mogelijkheid voor statische resultaten in Azure Logic Apps gebruiken om tijdelijk gesimuleerde antwoorden op actieniveau in te stellen. Met deze functionaliteit kunt u het gedrag van een specifiek systeem emuleren dat u wilt aanroepen. Vervolgens kunt u enkele eerste tests in isolatie uitvoeren en de hoeveelheid gegevens verminderen die u in line-of-businesssystemen zou maken.
Voer naast elkaar tests uit.
Idealiter hebt u al basislijnintegratietests voor uw BizTalk Server-omgeving en geautomatiseerde tests voor Azure Logic Apps tot stand gebracht. Vervolgens kunt u tests naast elkaar uitvoeren om uw interfaces te controleren met behulp van dezelfde gegevenssets en de algehele nauwkeurigheid van de test te verbeteren.
Release naar productie
Nadat uw team is voltooid en voldoet aan de definitie van voltooid voor de gebruikersverhalen, moet u rekening houden met de volgende taken:
Maak een communicatieplan voor uw release naar productie.
Maak een 'cut-over'-plan.
In een cut-over-plan worden de details behandeld over de taken en activiteiten die nodig zijn om over te schakelen van het huidige platform naar het nieuwe platform, inclusief de stappen die uw team gaat uitvoeren. Neem de volgende overwegingen op in uw cut-over-plan:
- Vereiste stappen
- Repetitie
- Personen
- Schattingen plannen
- Interfaces uitschakelen in het oude platform
- Interfaces inschakelen in het nieuwe platform
- Validatietests
Bepaal een terugdraaiplan.
Voer validatietests uit.
Plannen voor bewerkingen of productieondersteuning.
Kies 'go or no go'-criteria voor het vrijgeven van productie.
Vier het succes van uw team.
Houd een retrospectief.
Aanbevolen procedures voor een BizTalk-migratie
Hoewel best practices kunnen variëren tussen organisaties, kunt u overwegen om consistentie te bevorderen, wat helpt onnodige inspanningen te verminderen die "het wiel opnieuw uitvinden" en de redundantie van vergelijkbare gemeenschappelijke onderdelen. Wanneer u hergebruik mogelijk maakt, kan uw organisatie sneller interfaces bouwen die gemakkelijker te ondersteunen zijn. Time to market is een belangrijke factor voor digitale transformatie, dus een hoge prioriteit vermindert onnodige wrijving voor ontwikkelaars en ondersteuningsteams.
Wanneer u uw eigen best practices tot stand brengt, kunt u overwegen de volgende richtlijnen te volgen:
Algemene naamconventies voor Azure-resources
Zorg ervoor dat u goede naamconventies instelt en consistent toepast op alle Azure-resources, van resourcegroepen naar elk resourcetype. Een goede naamconventie communiceert met het doel om een solide basis te leggen voor zichtbaarheid en ondersteuning. Het belangrijkste punt voor naamconventies is dat u ze hebt en dat uw organisatie ze begrijpt. Elke organisatie heeft nuances waarmee ze rekening moeten houden.
Raadpleeg de volgende aanbevelingen en bronnen van Microsoft voor hulp bij deze procedure:
- Voorbeelden van afkortingen voor Azure-resources
- Azure Naming Tool, waarmee azure-compatibele namen worden gegenereerd, helpt u bij het standaardiseren van namen en het automatiseren van uw naamgevingsproces.
Naamconventies voor Azure Logic Apps-resources
Het ontwerp voor uw logische app en werkstroom biedt een belangrijk uitgangspunt, omdat dit gebied ontwikkelaars flexibiliteit biedt om unieke namen te maken.
Resourcenamen van logische apps
Als u onderscheid wilt maken tussen resources voor logische apps Verbruik en Standard, kunt u verschillende afkortingen gebruiken, bijvoorbeeld:
- Verbruik: LACon
- Standaard: LAStd
Vanuit organisatieperspectief kunt u een naamgevingspatroon ontwerpen dat de bedrijfseenheid, afdeling, toepassing en eventueel de implementatieomgeving omvat, zoals DEVUAT, , PRODenzovoort:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Stel dat u een logische standaard-app hebt die werkstromen implementeert voor de HR-afdeling in de bedrijfseenheid Bedrijfsservices. U kunt de resource LAStd-CorporateServices-HR-DEV van de logische app een naam geven en waar nodig Pascal Case-notatie gebruiken voor consistentie.
Werkstroomnamen voor logische apps
Een resource van de logische app Verbruik wordt altijd toegewezen aan slechts één werkstroom, dus u hebt slechts één naam nodig. Een resource voor een standaard logische app kan meerdere werkstromen bevatten, dus ontwerp een naamconventie die u ook kunt toepassen op lidwerkstromen. Voor deze werkstromen kunt u een naamconventie overwegen op basis van de procesnaam, bijvoorbeeld:
Process-<*process-name*>
Als u dus een werkstroom hebt waarmee onboardingtaken voor werknemers worden geïmplementeerd, zoals het maken van een werknemersrecord, kunt u de werkstroom Process-EmployeeOnboarding noemen.
Hier volgen meer overwegingen voor het ontwerpen van uw naamconventie voor werkstromen:
- Volg het bovenliggende/onderliggende patroon voor werkstromen waarin u een bepaalde relatie tussen een of meer werkstromen wilt markeren.
- Let op of een werkstroom een bericht publiceert of verbruikt.
Namen van werkstroombewerkingen
Wanneer u een trigger of actie aan uw werkstroom toevoegt, wijst de ontwerper automatisch de standaard algemene naam voor die bewerking toe. Bewerkingsnamen moeten echter uniek zijn binnen uw werkstroom, zodat de ontwerpfunctie opeenvolgende numerieke achtervoegsels toevoegt aan volgende bewerkingsexemplaren, waardoor leesbaarheid en ontcijfering van de oorspronkelijke intentie van de ontwikkelaar moeilijk is.
Als u bewerkingsnamen zinvoller en begrijpelijker wilt maken, kunt u een korte taakdescriptor toevoegen na de standaardtekst en Pascal Case-notatie gebruiken voor consistentie. Voor de actie JSON parseren kunt u bijvoorbeeld een naam gebruiken, zoals JSON-ChangeEmployeeRecord parseren. Met deze benadering of andere vergelijkbare benaderingen blijft u er rekening mee houden dat de actie JSON parseert en het specifieke doel van de actie. Dus als u de uitvoer van deze actie later in downstreamwerkstroomacties moet gebruiken, kunt u deze uitvoer gemakkelijker identificeren en vinden.
Notitie
Voor organisaties die veel expressies gebruiken, kunt u een naamconventie overwegen die geen gebruik maakt van witruimte (' '). De expressietaal in Azure Logic Apps vervangt witruimte door onderstrepingstekens ('_'), wat het ontwerpen kan bemoeilijken. Door spaties vooraf te vermijden, kunt u de wrijving verminderen bij het ontwerpen van expressies. Gebruik in plaats daarvan een streepje of afbreekstreepje ('-'), dat leesbaarheid biedt en geen invloed heeft op het ontwerpen van expressies.
Wijzig de bewerkingen onmiddellijk wanneer u ze toevoegt aan uw werkstroom om later mogelijke herwerkbewerkingen en problemen rond downstreamafhankelijkheden te voorkomen, die worden gemaakt wanneer u bewerkingen gebruikt. Downstreamacties worden meestal automatisch bijgewerkt wanneer u de naam van een bewerking wijzigt. Azure Logic Apps wijzigt echter niet automatisch de naam van aangepaste expressies die u hebt gemaakt voordat u de naam wijzigt.
Verbindingsnamen
Wanneer u een verbinding in uw werkstroom maakt, krijgt de onderliggende verbindingsresource automatisch een algemene naam, zoals sql of office365. Net als bij bewerkingsnamen moeten verbindingsnamen ook uniek zijn. Volgende verbindingen met hetzelfde type krijgen een opeenvolgend numeriek achtervoegsel, bijvoorbeeld sql-1, sql-2, enzovoort. Dergelijke namen bieden geen context, waardoor het onderscheiden en toewijzen van verbindingen met hun werkstromen zeer lastig is, met name voor ontwikkelaars die de oplossingsruimte niet kennen en deze werkstromen moeten onderhouden.
Daarom zijn betekenisvolle en consistente verbindingsnamen belangrijk om de volgende redenen:
- Leesbaarheid
- Eenvoudigere kennisoverdracht en ondersteuning
- Beheer
Nogmaals, het hebben van een naamconventie is essentieel, hoewel de indeling niet te belangrijk is. U kunt bijvoorbeeld het volgende patroon gebruiken als richtlijn:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Als concreet voorbeeld kunt u de naam van een Service Bus-verbinding wijzigen in een werkstroom van een logische OrderQueue-app met CN-ServiceBus-OrderQueue als de nieuwe naam. Zie voor meer informatie het blogbericht Turbo360 (voorheen Serverless360), best practices voor logische apps, tips en trucs: naamconventie voor #11 connectors.
Uitzonderingen verwerken met bereiken en opties Uitvoeren na
Bereiken bieden de mogelijkheid om meerdere acties te groeperen, zodat u Try-Catch-Finally-gedrag kunt implementeren. In de ontwerpfunctie kunt u de inhoud van een bereik samenvouwen en uitbreiden om de productiviteit van ontwikkelaars te verbeteren.
Wanneer u dit patroon implementeert, kunt u ook opgeven wanneer de actie Bereik en de acties binnen moeten worden uitgevoerd, op basis van de uitvoeringsstatus van de voorgaande actie, die kan worden geslaagd, mislukt, overgeslagen of TimedOut. Als u dit gedrag wilt instellen, gebruikt u de opties Uitvoeren na (runAfter) van de actie Bereik:
- Is geslaagd
- Is mislukt
- Is overgeslagen
- Er is een time-out opgetreden
Gedeelde services samenvoegen
Wanneer u integratieoplossingen bouwt, kunt u overwegen gedeelde services te maken en te gebruiken voor algemene taken. U kunt uw team een verzameling gedeelde services laten bouwen en beschikbaar maken die uw projectteam en anderen kunnen gebruiken. Iedereen krijgt meer productiviteit, uniformiteit en de mogelijkheid om governance af te dwingen op de oplossingen van uw organisatie. In de volgende secties worden enkele gebieden beschreven waarin u kunt overwegen om gedeelde services te introduceren:
| Gedeelde service | Redenen |
|---|---|
| Gecentraliseerde logboekregistratie | Geef veelvoorkomende patronen op voor de manier waarop ontwikkelaars hun code instrumenteren met de juiste logboekregistratie. Vervolgens kunt u diagnostische weergaven instellen waarmee u de interfacestatus en ondersteuning kunt bepalen. |
| Bedrijfstracking en bewaking van bedrijfsactiviteiten | Gegevens vastleggen en beschikbaar maken, zodat experts van zakelijke onderwerpen meer inzicht kunnen krijgen in de status van hun zakelijke transacties en selfservice analytische query's kunnen uitvoeren. |
| Configuratiegegevens | Scheid uw toepassingsconfiguratiegegevens van uw code, zodat u uw toepassing gemakkelijker tussen omgevingen kunt verplaatsen. Zorg ervoor dat u een uniforme consistente en eenvoudig repliceerbare benadering voor toegang tot configuratiegegevens biedt, zodat projectteams zich kunnen richten op het oplossen van het bedrijfsprobleem in plaats van tijd te besteden aan toepassingsconfiguraties voor implementatie. Als elk project deze scheiding op een unieke manier benaderde, kunt u niet profiteren van schaalvoordelen. |
| Aangepaste connectoren | Maak aangepaste connectors voor interne systemen die geen vooraf gedefinieerde connectors in Azure Logic Apps hebben om uw projectteam en anderen te vereenvoudigen. |
| Algemene gegevenssets of gegevensfeeds | Maak algemene gegevenssets en feeds beschikbaar als API's of connectors die projectteams kunnen gebruiken en vermijd het opnieuw uitvinden van het wiel. Elke organisatie heeft algemene gegevenssets die ze nodig hebben om systemen in een bedrijfsomgeving te integreren. |
Volgende stappen
U hebt nu meer geleerd over beschikbare migratiemethoden en aanbevolen procedures voor het verplaatsen van BizTalk Server-workloads naar Azure Logic Apps. Als u gedetailleerde feedback wilt geven over deze handleiding, kunt u het volgende formulier gebruiken: