Přístupy k migraci pro BizTalk Server do Azure Logic Apps
Tato příručka popisuje strategie a zdroje migrace spolu s aspekty plánování a osvědčenými postupy, které vám pomůžou zajistit úspěšná řešení migrace.
Poznámka:
Přehled migrace a průvodce výběrem služeb v Azure pro migraci najdete v následující dokumentaci:
Možnosti strategie
Následující části popisují různé strategie migrace spolu s jejich výhodami a nevýhodami:
Velký třesk
"Velký třesk" nebo "přímá změna" je přístup, který vyžaduje velké množství plánování a nedoporučuje se pro organizace, které nejsou neznámé v Azure Logic Apps nebo které mají velké systémy nebo řešení pro migraci. Když organizace implementuje nový technologický zásobník, nové učení obvykle často vede k výsledku. Díky tomu, že investovat příliš brzy nebo příliš mnoho, nebudete mít příležitost využít poznatky získané a upravit bez rizika významného přepracování.
Tento přístup může také trvat delší dobu, než se zhodnotí nebo nabíhá hodnota. Pokud jste už dokončili některé aktivity migrace, ale zatím jste je nevyvolali do produkčního prostředí kvůli jiným čekajícími nebo probíhajícím pracím, vaše migrované artefakty negenerují pro vaši organizaci hodnotu.
Tento přístup doporučujeme vzít v úvahu pouze v případě, že máte malé, nízké složitosti úloh BizTalk, odborníky na danou problematiku (SME), kteří znají vaše prostředí BizTalk, a přímé mapování mezi funkcemi BizTalk, které aktuálně používáte, a Azure Logic Apps. Zkušenosti s Azure Logic Apps také výrazně snižují rizika s využitím tohoto přístupu.
Iterativní nebo vlnové (doporučeno)
Tento přístup poskytuje vaší organizaci příležitost k postupnému dosažení hodnoty, ale dříve, než by jinak mohlo. Váš projektový tým se o technologickém zásobníku může brzy dozvědět pomocí retrospektivních sestav. Můžete například nasadit existující rozhraní BizTalk nebo projekt do produkčního prostředí a pak se seznámit s potřebami řešení, mezi které patří správa, škálovatelnost, operace a monitorování. Po získání těchto znalostí můžete sprinty naplánovat tak, aby optimalizovaly stávající možnosti, nebo zavést nové vzory, které můžete následně použít v budoucí práci.
Bez ohledu na váš přístup, pokud plánujete přejít na Azure Logic Apps nebo Azure obecně, důrazně zvažte refaktoring řešení BizTalk Serveru na bezserverová nebo cloudová nativní řešení, než vyřadíte infrastrukturu serveru z provozu. Tato volba je vynikající strategií, pokud vaše organizace chce firmu zcela transformovat na cloud.
BizTalk Server a Azure Logic Apps mají různé architektury. Pokud chcete dále modernizovat vaše řešení, můžete pomocí integračních služeb Azure rozšířit možnosti v Azure Logic Apps, které řeší základní potřeby integrace zákazníků.
Pro vyšší návratnost investic (ROI) doporučujeme, aby jakákoli migrace BizTalk používala co nejvíce základních nativních funkcí v Azure Logic Apps (Standard) a podle potřeby rozšířena o další integrační služby Azure. Tato kombinace umožňuje další scénáře, například:
- Hybridní funkce nativní pro cloud s využitím Azure Logic Apps (Standard) s hybridním nasazením
- Stavové nebo bezstavové funkce pracovního postupu v Azure Logic Apps (Standard)
- Integrace nativního integrovaného sálového počítače (v aplikaci) a středních uspořádání s konektory v Azure Logic Apps (Standard)
- Pub-sub messaging using Azure Service Bus
- Pokročilé funkce SOAP ve službě Azure API Management
Doručení projektu migrace BizTalk
K dokončení takového projektu doporučujeme postupovat podle iterativního nebo vlnového přístupu a použít proces Scrum. I když Scrum neobsahuje koncept Sprint Zero (Sprint 0) pro aktivity před sprintem, doporučujeme zaměřit se na první sprint na týmové sladění a technické zjišťování. Po sprintu 0 postupujte podle provádění několika sprintů migrace a zaměřte se na vydávání funkcí směrem k minimálnímu realizovatelnému produktu (MVP).
Sprint 0
Během tohoto sprintu doporučujeme spustit zjišťování prostředí BizTalk Serveru s plánováním vln. Pochopení šířky a hloubky projektu je pro úspěch velmi důležité. Následující seznam obsahuje konkrétní oblasti, které se mají během sprintu 0 řešit:
| Oblast | Popis |
|---|---|
| Zjišťování | Zachyťte data o všech vašich rozhraních a aplikacích, abyste se dozvěděli, kolik rozhraní a aplikací potřebujete migrovat. Ke každému rozhraní nebo procesu je také potřeba přiřadit složitost. Během tohoto procesu katalogizace shromážděte následující informace, které vám umožní určit prioritu práce: - Používané adaptéry – Funkce BizTalk Serveru používané, jako je monitorování obchodních aktivit, modul obchodních pravidel, EDI atd. – Vlastní kód, jako jsou výrazy, mapy a součásti kanálu – Propustnost zprávy - Velikosti zpráv -Závislosti – Závislosti aplikací a systémů |
| Návrh architektury | Vytvořte architekturu vysoké úrovně, která se použije jako ústřední bod migrace. Tento návrh zahrnuje prvky, které řeší funkční a nefunkční potřeby vysoké úrovně. |
| Definice minimálního realizovatelného produktu | Definujte první vlnové funkce. Jinými slovy, procesy, které potřebují podporu po dokončení první vlny. |
| Počáteční backlog migrace | Definujte funkce první vlny a jejich pracovní položky s technickými podklady. |
Nástroje pro zjišťování
K usnadnění zjišťování migrace můžete použít nástroj příkazového řádku Azure Integration Migrator, který se označuje také jako nástroj BizTalk Migration, což je opensourcový projekt Microsoftu. Tento nástroj používá fázovaný přístup, který vám pomůže odhalit užitečné poznatky a strategie pro migraci řešení do cloudu. Nástroj pro migraci doporučujeme používat jenom pro generování sestav a zjišťování. Můžete také zvážit použití dalších produktů pro zjišťování od partnerů, kteří poskytují řešení v tomto prostoru.
Pro další způsob, jak vygenerovat inventář pomocí prvků BizTalk Serveru, můžete použít BizTalk Documenter, který je vyvinut Mark Brimble. Tento nástroj funguje s BizTalk Server 2020, přestože hlásí, že je podporován pouze BizTalk Server 2016.
Návrh architektury
Azure Logic Apps sice nabízí možnosti, které umožňují opakovaně používat prostředky BizTalk Serveru, ale musíte mít moderní návrh architektury, který bude využívat výhody modernějších funkcí. Z funkční perspektivy používejte co nejvíce obchodní logiku. Z pohledu modernizace produktů používejte integrační služby Azure stejně jako vy. Pro kvalitu a průřezové aspekty doporučujeme používat architekturu Azure Well-Architected Framework.
V této architektuře jsou migrace BizTalk klíčové úlohy. Tento termín popisuje kolekce prostředků aplikace, které vyžadují vysokou dostupnost na platformě, což znamená, že musí být vždy dostupné, provozní a odolné vůči selháním.
Pokud chcete dokončit návrh architektury pro migraci BizTalk, postupujte podle metodologie návrhu pro klíčové úlohy v Azure. V případě počáteční architektury a topologie si projděte referenční architekturu popsanou v základní podnikové integraci v Azure v Centru architektury Azure.
K nastavení počátečního prostředí použijte akcelerátor cílových zón Azure Integration Services, který je určený k vytvoření a nasazení integrační platformy pomocí typického návrhu cílové zóny podniku.
Definice minimálního realizovatelného projektu
MVP je verze produktu, která má jenom dostatek funkcí použitelných pro zákazníky. Tato verze ukazuje možnosti produktu a potenciál shromáždit zpětnou vazbu zákazníků a pokračovat v práci. V případě migrace BizTalk se definice MVP odráží iterace, vlny nebo skupiny sprintů, které potřebujete postupovat směrem k pracovním funkcím a ke splnění počátečních úloh integrace.
Doporučujeme, aby definice MVP obsahovala následující obchodní výsledky, které jsou vyjádřeny jako Náměty v terminologii Scrum:
Obchodní výsledky (náměty)
- Jakého primárního cíle chcete dosáhnout?
- Jaké možnosti nebo funkce musíte pro tohoto MVP řešit?
- Jaké jsou toky obchodních procesů? Tato otázka poskytuje příležitost optimalizovat existující procesy podporované BizTalk Serverem.
- Jaká jsou obchodní rozhodnutí, například obchodní výsledky, které ovlivňují MVP nebo jaká je dostupnost prostředků?
Doporučujeme, aby váš MVP zahrnoval následující procesy v oboru, které jsou vyjádřeny jako funkce v terminologii Scrum:
Procesy v oboru (funkce)
| Funkce | Popis |
|---|---|
| Funkce systému vysoké úrovně | Tyto informace můžete extrahovat pomocí nástrojů zjišťování a vyjádřit popisy z hlediska funkcí. |
| Aktéři nebo osoby | Pomocí těchto informací můžete určit osoby ovlivněné podporovanými scénáři MVP. |
| Orchestrace | Tyto informace můžete extrahovat pomocí nástrojů pro zjišťování. |
| Datové entity a zprávy | Tyto prvky vám umožňují zjistit, jestli můžete do dat vyměňovaných prostředím BizTalk Serveru zahrnout další vylepšení. |
| Mapování dat | Dnešní svět spoléhá na JSON. BizTalk Server však používá XML. Tato chvíle je skvělou příležitostí k rozhodování o potřebách formátu dat a převodu pro novou platformu. |
| Obchodní pravidla | Tato pravidla zaměřená na data otevírají příležitost k tomu, abyste si jejich přístup znovu promysleli nebo je znovu použili pomocí funkcí Azure Logic Apps. |
| Důležité informace o ochraně osobních údajů | Musíte nastavit ochranu osobních údajů jako nejvyšší prioritu. Pokud zákazník v Azure Logic Apps (Standard) nevolí model hybridního nasazení, musíte tuto oblast řešit v každé vlně kvůli možným změnám prostředí nasazení. |
| Důležité informace o právních předpisech | Tento aspekt je relevantnější, pokud vaši zákazníci nemají cloudové úlohy. |
| Zabezpečení součástí návrhu | Je nutné navrhnout každou funkci s ohledem na zabezpečení. |
| Navrhované funkce pro koexistence | Když doručíte každou vlnu, máte určitou míru koexistence. Tuto hybridní architekturu musíte sladit se stávajícími ukazateli úrovně služeb (SLI) a cíli úrovně služeb (SLO). |
| Nefunkční aspekty | Obchodní procesy můžou mít jiné než funkční požadavky. Ne všechno se musí stát v reálném čase. Naopak ne všechno je dávkové zpracování. |
| Obchodní metriky | Volitelná příležitost k zobrazení průběhu práce migrace |
Budete také chtít identifikovat a zobrazit seznam různých proměnných mimo rozsah, které tvarují rozsah vaší práce MVP, například:
- Dostupnost zdroje
- Rizika
- Dokumentace
- Rychlost uvedení na trh
Počáteční backlog
Počáteční backlog je sada uživatelských scénářů, kterou seskupíte do funkcí a sestavíte procesy v oboru pro MVP. Jinými slovy, MVP je reprezentován položkami Scrum označovanými jako náměty, funkce a uživatelské scénáře. V ideálním případě každý námět zahrnuje skupinu aplikací BizTalk nebo projektů BizTalk. Můžete použít jednoduché pravidlo, které přidruží jednu aplikaci BizTalk nebo projekt BizTalk k funkci.
Předpokládejme například, že máte projekt BizTalk Serveru s orchestrací nazvanou "LoanRequests", kterou zákazníci používají k vyžádání bankovních úvěrů. Proto máte následující navrženou funkci a uživatelský scénář:
Funkce: Zpracování půjčky
Uživatelský příběh: "Jako zákazník chci odeslat žádost o půjčku, aby banka mohl přidat finanční prostředky do mého zabezpečeného účtu."
Tento uživatelský příběh, který může v současné době existovat jako implementace v BizTalk Serveru, má následující úlohy k implementaci pomocí Azure Logic Apps a Azure Integration Services:
- Shromážděte opakovaně použitelné artefakty BizTalk.
- Vytvořte pracovní postup žádosti o půjčku pomocí Azure Logic Apps.
- Konfigurace asynchronního zasílání zpráv pomocí služby Azure Service Bus nebo IBM MQ
- Mapování JSON na data XML pomocí pracovního postupu Azure Logic Apps
- Přizpůsobte integrační služby Azure podle potřeby pro vzory zasílání zpráv.
Následující diagram znázorňuje navrhované doby trvání námětů, funkcí, uživatelských scénářů a úkolů, které rozdělují uživatelské scénáře. Přestože rozhodnutí o implementaci ovlivňují tyto doby trvání, předpokládají, že používáte existující artefakty BizTalk v Azure Logic Apps. Vytvářejte standardní pracovní postupy pomocí předem připravených šablon pracovních postupů co nejvíce.
Vlny migrace (sprinty)
Po dokončení sprintu 0 byste měli mít jasný přehled o MVP k sestavení. Vlna je sada sprintů. Počáteční backlog by měl obsahovat pracovní položky, které následují po následujícím diagramu co nejvíce:
Během vlny váš tým dokončí aktivity pro migraci, testování a uvolnění do produkčního prostředí. Pojďme podrobněji prozkoumat, co se stane v každé vlně.
Migrate
Během každé vlny se migrace zaměřuje na schválené uživatelské scénáře. V první vlně se váš tým zaměřuje na počáteční backlog. Rozhodnutí o technologiích musí používat informace v mapování funkcí BizTalk Serveru, které popisuje shoda funkcí – Proč migrovat z BizTalk Serveru do Azure Logic Apps?
Následující diagram znázorňuje události, ke kterým by mělo dojít během vlny migrace:
| Krok | Description |
|---|---|
| 1 | Seznamte se s existujícími aplikacemi a rozhraními BizTalk. I když se tato aktivita zavedla ve sprintu 0, měla by k této aktivitě dojít, když se každá vlna spustí. Zákazníci můžou v prostředí BizTalk pokračovat v provádění změn. Prostředky: - Nástroj BizTalk Migration - Nástroj BizTalk Documenter |
| 2 | Nastavte počáteční prostředí migrace. Můžete použít akcelerátor cílových zón služby Azure Integration Services, což je architektura přechodu na cloud pro sestavování a nasazování integrační platformy, která má typický návrh cílové zóny podniku. Jako vlastník úlohy můžete s jistotou dosáhnout svého cílového technického stavu pomocí poskytnutých pokynů k architektuře a prostředků migrace BizTalk. Ukázkovou architekturu najdete v příkladu prostředí migrace. |
| 3 | Vytvářejte a testujte pracovní postupy standardní aplikace logiky, které běží v Azure Logic Apps s jedním tenantem pomocí webu Azure Portal nebo editoru Visual Studio Code s rozšířením Azure Logic Apps (Standard). Pomocí editoru Visual Studio Code můžete místně vyvíjet, testovat a ukládat projekt aplikace logiky pomocí libovolného systému správy zdrojového kódu. Další informace najdete v následující dokumentaci: - Vytvoření ukázkového pracovního postupu standardní aplikace logiky pomocí webu Azure Portal - Vytvoření ukázkového pracovního postupu standardní aplikace logiky pomocí editoru Visual Studio Code Diagram znázorňující ukázkovou aplikaci logiky a připojení najdete v ukázkovém prostředí migrace. |
| 4 | Pokud chcete získat úplné výhody při snadném a konzistentním nasazování pracovních postupů standardní aplikace logiky napříč různými prostředími a platformami, musíte také automatizovat proces sestavení a nasazení. Rozšíření Azure Logic Apps (Standard) pro Visual Studio Code poskytuje nástroje pro vytváření a údržbu automatizovaných procesů sestavení a nasazení pomocí Azure DevOps. Další informace najdete v tématu Automatizace sestavení a nasazení pracovních postupů aplikací logiky Standard pomocí Azure DevOps. |
| 5 | Pokud chcete nasadit klíčové standardní aplikace logiky, které jsou vždy dostupné a responzivní, a to i během aktualizací nebo údržby, povolte nasazení nulového výpadku vytvořením a použitím slotů nasazení. Nulový výpadek znamená, že když nasadíte nové verze aplikace, koncoví uživatelé by neměli zaznamenat přerušení nebo výpadek. Další informace najdete v tématu Nastavení slotů nasazení pro povolení nulového výpadku v Azure Logic Apps. |
Následující diagram znázorňuje příklad počátečního prostředí migrace pomocí standardní aplikace logiky, která orchestruje pracovní postupy, které komunikují s rozhraními API, službami, hybridními řešeními a místními prostředky:
Test
Každá vlna má vlastní testovací aktivity, které jsou vloženy do každého uživatelského scénáře. Pokud chcete použít testování posunu doleva, ujistěte se, že jste dokončili následující úlohy:
Automatizujte testy.
Azure Logic Apps (Standard) zahrnuje schopnost provádět automatizované testování. Následující seznam obsahuje další informace a prostředky, které jsou volně dostupné na GitHubu:
Automatizované testování s využitím Azure Logic Apps (Standard) od týmu Azure Logic Apps
S využitím Azure Logic Apps (Standard) už není automatizované testování obtížné provádět, protože základní architektura je založená na modulu runtime Azure Functions a může běžet kdekoli, kde může služba Azure Functions běžet. Můžete psát testy pro pracovní postupy, které běží místně nebo v kanálu CI/CD. Další informace najdete v ukázkovém projektu pro testovací architekturu Azure Logic Apps.
Tato testovací architektura zahrnuje následující funkce:
- Psaní automatizovaných testů pro komplexní funkce v Azure Logic Apps
- Proveďte jemně odstupňované ověřování na úrovních spuštění pracovního postupu a akcí.
- Zkontrolujte testy v úložišti Git a spusťte je místně nebo v kanálech CI/CD.
- Napodobení možností testování pro akce HTTP a konektory Azure
- Nakonfigurujte testy tak, aby používaly různé hodnoty nastavení z produkčního prostředí.
Playbook integrace: Standardní testování Logic Apps od Michaela Stephensona, Microsoft MVP
Architektura testování playbooku integrace vychází z testovací architektury poskytované Microsoftem a podporuje další scénáře:
- Připojte se k pracovnímu postupu ve standardní aplikaci logiky.
- Získejte adresu URL zpětného volání, abyste mohli pracovní postup aktivovat z testu.
- Zkontrolujte výsledky spuštění pracovního postupu.
- Zkontrolujte vstupy a výstupy operací z historie spuštění pracovního postupu.
- Připojte se k automatizovaným testovacím architekturám, které můžou vývojáři aplikací logiky používat.
- Připojte se ke specflow, který podporuje vývoj založený na chování (BDD) pro aplikace logiky.
Bez ohledu na to, které přístupy automatizace nebo prostředky používáte, jste na cestě k opakovatelným, konzistentním a automatizovaným integračním testům.
Nastavte testování napodobení odpovědí pomocí statických výsledků.
Bez ohledu na to, jestli nastavíte automatizované testy, můžete použít funkci statických výsledků v Azure Logic Apps k dočasnému nastavení napodobení odpovědí na úrovni akce. Tato funkce umožňuje emulovat chování z konkrétního systému, který chcete volat. Pak můžete provést nějaké počáteční testování izolovaně a snížit množství dat, která byste vytvořili v obchodních systémech.
Souběžné testy.
V ideálním případě už máte základní integrační testy pro prostředí BizTalk Serveru a vytvořili jste automatizované testy pro Azure Logic Apps. Testy pak můžete spouštět souběžně tak, aby vám to pomůže zkontrolovat rozhraní pomocí stejných datových sad a zlepšit celkovou přesnost testů.
Uvolnění do produkčního prostředí
Jakmile se váš tým dokončí a splní "definici dokončení" uživatelských scénářů, zvažte následující úkoly:
Vytvořte plán komunikace pro vaši verzi do produkčního prostředí.
Vytvořte plán "překryvné".
Podrobný plán obsahuje podrobnosti o úkolech a aktivitách potřebných k přechodu z aktuální platformy na novou platformu, včetně kroků, které váš tým plánuje provést. Do plánu přímé migrace uveďte následující aspekty:
- Požadované kroky
- Generální zkouška
- Lidé
- Odhady plánů
- Zakázání rozhraní ve staré platformě
- Povolení rozhraní v nové platformě
- Ověřovací testování
Určení plánu vrácení zpět
Spusťte ověřovací testování.
Naplánujte provozní nebo produkční podporu.
Zvolte kritéria "Přejít nebo nejdou" pro uvolnění do produkčního prostředí.
Oslavte úspěch vašeho týmu.
Držte retrospektivní.
Osvědčené postupy pro migraci BizTalk
I když se osvědčené postupy můžou v různých organizacích lišit, zvažte vědomé úsilí o podporu konzistence, což pomáhá snížit zbytečné úsilí, které "znovu vymyslí kolo" a redundanci podobných společných komponent. Když pomůžete s opětovnou použitelností, může vaše organizace rychleji vytvářet rozhraní, která se snadněji podporují. Doba uvedení na trh je klíčovým faktorem pro digitální transformaci, takže hlavní prioritou je snížení zbytečného tření pro vývojáře a týmy podpory.
Při vytváření vlastníchosvědčených
Obecné zásady vytváření názvů pro prostředky Azure
Nezapomeňte nastavit a konzistentně používat dobré zásady vytváření názvů ve všech prostředcích Azure ze skupin prostředků na jednotlivé typy prostředků. Pro vytvoření solidního základu pro zjistitelnost a podporu, je vhodné konvence vytváření názvů komunikovat účel. Nejdůležitějším bodem pro zásady vytváření názvů je, že je máte a že jim vaše organizace rozumí. Každá organizace má drobné odlišnosti, které by mohly vzít v úvahu.
Pokyny k tomuto postupu najdete v následujících doporučeních a zdrojích microsoftu:
- Příklady zkratek pro prostředky Azure
- Nástroj pro vytváření názvů Azure, který generuje názvy kompatibilní s Azure, pomáhá standardizovat názvy a automatizovat proces pojmenování.
Zásady vytváření názvů pro prostředky Azure Logic Apps
Návrh aplikace logiky a pracovního postupu poskytuje klíčový výchozí bod, protože tato oblast vývojářům poskytuje flexibilitu při vytváření jedinečných názvů.
Názvy prostředků aplikace logiky
Pokud chcete rozlišovat mezi prostředky aplikace logiky Consumption a Standard, můžete použít různé zkratky, například:
- Spotřeba: LACon
- Standard: LAStd
Z hlediska organizace můžete navrhnout vzor pojmenování, který zahrnuje organizační jednotku, oddělení, aplikaci a volitelně i prostředí nasazení, například DEV, UAT, PRODatd., například:
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Předpokládejme, že máte ve vývoji standardní aplikaci logiky, která implementuje pracovní postupy pro personální oddělení v organizační jednotce Podnikové služby. Prostředek aplikace logiky můžete pojmenovat LAStd-CorporateServices-HR-DEV a v případě potřeby použít zápis pascalových případů pro konzistenci.
Názvy pracovních postupů aplikace logiky
Prostředek aplikace logiky Consumption se vždy mapuje jenom na jeden pracovní postup, takže potřebujete jenom jeden název. Prostředek standardní aplikace logiky může obsahovat více pracovních postupů, takže navrhňte zásady vytváření názvů, které můžete použít také u členských pracovních postupů. U těchto pracovních postupů zvažte konvenci vytváření názvů na základě názvu procesu, například:
Process-<*process-name*>
Pokud jste tedy měli pracovní postup, který implementuje úkoly připojování zaměstnanců, například vytvoření záznamu zaměstnance, můžete pracovní postup pojmenovat Process-EmployeeOnboarding.
Tady jsou další aspekty návrhu zásad vytváření názvů pracovních postupů:
- Pro pracovní postupy, ve kterých chcete zvýraznit vztah mezi jedním nebo více pracovními postupy, postupujte podle vzoru nadřazenosti a podřízenosti.
- Vezměte v úvahu, jestli pracovní postup publikuje nebo spotřebovává zprávu.
Názvy operací pracovního postupu
Když do pracovního postupu přidáte trigger nebo akci, návrhář automaticky přiřadí výchozí obecný název této operace. Názvy operací však musí být v rámci pracovního postupu jedinečné, takže návrhář připojí postupné číselné přípony k následným instancím operací, což ztěžuje čitelnost a dešifrování původního záměru vývojáře.
Aby byly názvy operací smysluplnější a srozumitelnější, můžete za výchozí text přidat stručný popisovač úkolu a pro konzistenci použít notaci Pascal Case. Například pro akci Parsovat JSON můžete použít název, například Parsovat JSON-ChangeEmployeeRecord. S tímto přístupem nebo jinými podobnými přístupy si budete i nadále pamatovat, že akce je Parsovat JSON a konkrétní účel akce. Pokud tedy potřebujete později použít výstupy této akce v podřízených akcích pracovního postupu, můžete tyto výstupy snadněji identifikovat a najít.
Poznámka:
Pro organizace, které výrazy široce používají, zvažte konvenci vytváření názvů, která nepodporuje použití prázdných znaků ('). Jazyk výrazu v Azure Logic Apps nahrazuje prázdné znaky podtržítky ('_'), což může komplikovat vytváření. Díky tomu, že se vyhnete mezerám předem, snížíte tření při vytváření výrazů. Místo toho použijte pomlčku nebo spojovník (-), který poskytuje čitelnost a nemá vliv na vytváření výrazů.
Abyste se vyhnuli pozdějšímu možnému přepracování a problémům souvisejícím s podřízenými závislostmi, které se vytvoří při použití výstupů operací, přejmenujte operace okamžitě, když je přidáte do pracovního postupu. Při přejmenování operace se obvykle automaticky aktualizují podřízené akce. Azure Logic Apps ale před provedením přejmenování automaticky nepřejmenovává vlastní výrazy, které jste vytvořili.
Názvy připojení
Když vytvoříte připojení v pracovním postupu, základní prostředek připojení automaticky získá obecný název, například SQL nebo Office365. Stejně jako názvy operací musí být názvy připojení také jedinečné. Následná připojení se stejným typem získávají sekvenční číselnou příponu, například sql-1, sql-2 atd. Tyto názvy neposkytují žádný kontext, což výrazně znesměrňuje a mapuje připojení k pracovním postupům, zejména pro vývojáře, kteří prostor řešení nezná a musí tyto pracovní postupy udržovat.
Proto jsou smysluplné a konzistentní názvy připojení důležité z následujících důvodů:
- Čitelnost
- Jednodušší přenos znalostí a možnosti podpory
- Řízení
Opět platí, že zásady vytváření názvů jsou kritické, i když formát není příliš důležitý. Jako vodítko můžete například použít následující vzor:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Jako konkrétní příklad můžete přejmenovat připojení služby Service Bus v pracovním postupu aplikace logiky OrderQueue s CN-ServiceBus-OrderQueue jako novým názvem. Další informace najdete v blogovém příspěvku Turbo360 (dříve bezserverové verze 360), osvědčených postupech pro aplikace logiky, tipy a triky: konvence vytváření názvů konektorů #11.
Zpracování výjimek pomocí oborů a možností Spustit po
Obory poskytují možnost seskupit více akcí, abyste mohli implementovat chování Try-Catch-Finally. V návrháři můžete obsah oboru sbalit a rozšířit, aby se zlepšila produktivita vývojářů.
Při implementaci tohoto modelu můžete také určit, kdy se má spustit akce Oboru a akce uvnitř na základě stavu provádění předchozí akce, což může být Úspěšné, Neúspěšné, Přeskočeno nebo Časový limit. Pokud chcete toto chování nastavit, použijte možnosti Spustit po (runAfter) akci Oboru:
- Je úspěšný.
- Došlo k chybě
- Přeskočeno
- Vypršel časový limit
Konsolidace sdílených služeb
Při vytváření řešení integrace zvažte vytvoření a používání sdílených služeb pro běžné úlohy. Svůj tým můžete sestavit a vystavit kolekci sdílených služeb, které může váš projektový tým a ostatní používat. Všichni získávají vyšší produktivitu, jednotnost a schopnost vynucovat zásady správného řízení v řešeních vaší organizace. Následující části popisují některé oblasti, ve kterých byste mohli zvážit zavedení sdílených služeb:
| Sdílená služba | Důvody |
|---|---|
| Centralizované protokolování | Poskytněte běžné vzory, jak vývojáři instrumentují svůj kód s odpovídajícím protokolováním. Pak můžete nastavit diagnostická zobrazení, která vám pomůžou určit stav a možnosti podpory rozhraní. |
| Sledování obchodních aktivit a monitorování obchodních aktivit | Zachytávání a zveřejnění dat, aby odborníci na danou problematiku mohli lépe porozumět stavu svých obchodních transakcí a provádět samoobslužné analytické dotazy. |
| Konfigurační data | Oddělte konfigurační data aplikace od kódu, abyste mohli snadněji přesouvat aplikaci mezi prostředími. Ujistěte se, že poskytuje jednotný a snadno replikovatelný přístup pro přístup ke konfiguračním datům, aby se projektové týmy mohly soustředit na řešení obchodního problému a netrávit čas na konfiguraci aplikací pro nasazení. V opačném případě, pokud každý projekt přistupoval k tomuto oddělení jedinečným způsobem, nemůžete těžit z úspor z rozsahu. |
| Vlastní konektory | Vytvořte vlastní konektory pro interní systémy, které nemají předem připravené konektory v Azure Logic Apps, aby se zjednodušily pro váš projektový tým a další. |
| Běžné datové sady nebo datové kanály | Zveřejnění běžných datových sad a informačních kanálů jako rozhraní API nebo konektorů pro projektové týmy, které mohou používat, a vyhněte se opětovnému vytvoření kola. Každá organizace má společné datové sady, které potřebují integrovat systémy v podnikovém prostředí. |
Další kroky
Teď jste se seznámili s dostupnými přístupy k migraci a osvědčenými postupy pro přesun úloh BizTalk Serveru do Azure Logic Apps. Pokud chcete poskytnout podrobnou zpětnou vazbu k tomuto průvodci, můžete použít následující formulář: