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. Další informace najdete v tématu Proč migrovat z BizTalk Serveru do Azure Logic Apps?

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ý přechod" je přístup, který vyžaduje velké množství plánování a nedoporučuje se pro organizace, které nejsou obeznámeny s Azure Logic Apps nebo které mají velké systémy nebo řešení k migraci. Když organizace implementuje nový technologický zásobník, nové učení obvykle často vede k výsledku. Pokud investujete příliš brzy nebo příliš mnoho, nebudete mít příležitost využít získané poznatky a provést úpravy bez rizika významného přepracování.

Tento přístup může také trvat delší dobu, než se zhodnotí nebo hromadí 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 může o technologickém stacku dozvědět brzy pomocí retrospektiv. 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. 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 je rozšiřovala 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)
• Nativní, vestavěná (v aplikaci) integrace mainframe a midrange počítačů s konektory v Azure Logic Apps (Standard)
• Systém pub-sub zasílání zpráv pomocí Azure Service Bus nebo RabbitMQ
• Pokročilé funkce SOAP ve službě Azure API Management
• Převod aplikací logiky na pracovní postupy agentů AI

Implementace 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 potrubí – 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 funkce první vlny. 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 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 co nejvíce. Pro kvalitu a průřezové aspekty doporučujeme používat architekturu Azure Well-Architected Framework.

V tomto rámci jsou migrace BizTalk kriticky důležitými úlohami. 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áží v iteracích, vlnách nebo skupinách sprintů, které potřebujete k dosažení funkčních vlastností a ke splnění počáteční zátěže integrace.

Doporučujeme, aby definice MVP obsahovala následující obchodní výsledky, které jsou vyjádřeny jako Epics v terminologii Scrum:

Obchodní výsledky (epiky)

• 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í.
Regulační úvahy	Tento aspekt je relevantnější, pokud vaši zákazníci nemají cloudové úlohy.
Zabezpečeno od 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á možnost zobrazení průběhu migrační práce

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 příběhů, kterou seskupíte do funkcí a sestavíte procesy v rámci rozsahu 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ý Epic 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 artefakty BizTalk, které lze opakovaně použít.
  • 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, které je třeba sestavit. Vlna je sada sprintů. Prvotní backlog by měl obsahovat pracovní položky, které co nejvíce odpovídají zásadám uvedeným na následujícím diagramu:

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ě.

Migrovat

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	Popis
1	Seznamte se s existujícími aplikacemi a rozhraními BizTalk. I když byla tato aktivita zavedena ve Sprintu 0, měla by se uskutečnit, když se spustí každá vlna. 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í pracovního postupu standardní aplikace logiky pomocí webu Azure Portal - Vytvoření pracovního postupu standardní aplikace logiky pomocí editoru Visual Studio Code Pokud chcete zahájit rychlou migraci pomocí zdrojového kódu a vazeb aplikace BizTalk, použijte úvodní sadu BizTalk Migration Starter. Pomocí tohoto nástroje můžete rychle vytvořit důkaz konceptu migrace, který vám pomůže snížit rizika a počet vln migrace. Tento nástroj vytvoří definici pracovního postupu aplikace logiky, která se podobá orchestraci BizTalk. Pro scénáře směrování na základě obsahu (CBR) nástroj vytvoří také pracovní postup. Pro diagram znázorňující ukázkový pracovní postup a připojení logické aplikace, viz Ukázkové 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é pro mise standardní aplikace logiky, které jsou vždy dostupné a responzivní, a to i během aktualizací nebo údržby, povolte nasazení bez výpadků vytvořením a používáním slotů pro 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:

Následující diagram znázorňuje příklad počátečního prostředí migrace s místní nasazenou aplikací logiky Standard, která orchestruje pracovní postupy pro komunikaci s rozhraními API, službami, hybridními řešeními a místními prostředky:

Otestujte vaši migraci

Každá vlna má vlastní testovací aktivity, které jsou vloženy do jednotlivých uživatelských příběhů. Pokud chcete použít testování posunu doleva, ujistěte se, že používáte následující doprovodné materiály:

• Vytváření jednotkových testů z běhů standardních pracovních postupů v Azure Logic Apps pomocí editoru Visual Studio Code.

  Pro tuto úlohu vytvořte ukázkový pracovní postup standardní aplikace logiky, který můžete spustit v Azure Logic Apps s jedním tenantem pomocí editoru Visual Studio Code s rozšířením Azure Logic Apps (Standard). Postupujte podle kroků v části Vytvoření standardních pracovních postupů aplikace logiky pomocí editoru Visual Studio Code.

• Používejte profily agenta testování jednotek pro aplikace logiky a mapy dat.

  Profily agenta testování jednotek jsou zaměřená sada agentů, která vám pomůže zjišťovat pracovní postupy a mapy, zapisovat opakovaně použitelné specifikace, generovat typované napodobení a testovací data a implementovat sady MSTest pro standardní projekty Azure Logic Apps. Postupujte podle kroků v dokumentu Představení profilů agenta jednotkového testování pro Logic Apps a Mapy dat.

Nasazení

Jakmile se váš tým dokončí a splní "definici dokončení" uživatelských scénářů, zvažte následující úkoly:

1. Vytvořte plán komunikace pro vaše nasazení do produkce.

2. Vytvořte plán přechodu.

   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řechodu uveďte následující aspekty:

   • Požadované kroky
   • Generální zkouška
   • Lidé
   • Odhady plánů
   • Zakázání rozhraní v prostředí BizTalk Serveru
   • Povolení rozhraní v prostředí Logic Apps
   • Ověřovací testování

3. Určení plánu obnovení

4. Spusťte ověřovací testování.

5. Naplánujte provozní nebo produkční podporu.

6. Zvolte kritéria "rozjet nebo zastavit" pro nasazení do produkčního prostředí.

7. Oslavte úspěch vašeho týmu.

8. Usaďte retrospektivu.

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ích osvědčených postupů zvažte sladění s následujícím doporučením:

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 dobře sestavená konvence pojmenování vyjadřuje úč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 použít zápis Pascal Case tam, kde je to vhodné, pro konzistenci.

Názvy pracovních postupů aplikace logiky

Prostředek logické aplikace Consumption mapuje jen na jeden pracovní postup, takže potřebujete jen jediný název. Standardní logická aplikace může obsahovat více pracovních postupů, takže navrhněte konvenci pojmenování, kterou můžete použít také u podřízený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 se budete i nadále pamatovat, že úkolem je analyzovat JSON a jeho specifický účel. 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ž velmi ztěžuje rozlišování a mapování propojení na jejich pracovní postupy, zejména pro vývojáře, kteří neznají prostor řešení 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 Serverless360), osvědčené praktiky, tipy a triky pro Logic app: #11 konvence pojmenovávání konektorů.

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 vzoru můžete také určit, kdy se má spustit akce Scope a akce uvnitř, podle stavu provedení předchozí akce, což může být Úspěch, Selhalo, Přeskočeno nebo Čas vypršel. Pokud chcete toto chování nastavit, použijte akci Scope a její možnosti Spustit po (runAfter):

• 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 by každý projekt přistupoval k tomuto oddělení jedinečným způsobem, nemůžete těžit z úspor z rozsahu výroby.
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	Zpřístupněte běžné datové sady a informační kanály jako rozhraní API nebo konektory, které mohou používat projektové týmy, a zamezte zbytečnému vynalézání již objeveného. Každá organizace má společné datové sady, které potřebují integrovat systémy v podnikovém prostředí.

Další kroky

Dozvěděli jste se více o dostupných přístupech k migraci a osvědčených postupech pro přesun úloh BizTalk Serveru do Azure Logic Apps. Pokud chcete poskytnout podrobnou zpětnou vazbu k tomuto průvodci, použijte následující formulář:

Váš názor na pokyny k migraci pro BizTalk Server do Azure Logic Apps