Proč migrovat z BizTalk Serveru do Azure Logic Apps?

Tato příručka obsahuje přehled důvodů a výhod, možností a dalších informací, které vám pomůžou začít migrovat z BizTalk Serveru do Azure Logic Apps. V této příručce najdete další příručky, které se týkají strategií migrace, aspektů plánování a osvědčených postupů, které vám pomůžou zajistit úspěšné výsledky.

Důvody a výhody

Migrací úloh integrace do Azure Logic Apps můžete využít následující hlavní výhody:

Výhoda	Popis
Moderní integrační platforma jako služba (iPaaS)	Azure Logic Apps je součástí služby Azure Integration Services, která poskytuje funkce, které neexistovaly při původním sestavení BizTalk Serveru, například: – Schopnost vytvářet a spravovat rozhraní REST API – Škálovatelná cloudová infrastruktura - Schémata ověřování, která jsou moderní, bezpečnější a snadněji implementovaná – Zjednodušené vývojové nástroje, včetně mnoha prostředí založených na webovém prohlížeči – Automatické aktualizace platformy a integrace s dalšími nativními službami cloudu – Schopnost spouštět místně (model hybridního nasazení Azure Logic Apps) - Schopnost převést orchestrace na agentní obchodní procesy
BizTalk Server 2020 je konečná verze BizTalk Serveru.	BizTalk Server po dobu více než 25 let podporoval klíčové úlohy integrace pro organizace po celém světě. Od automatizace obchodních procesů a zasílání zpráv B2B až po připojení napříč odvětvími, jako jsou finanční služby, zdravotnictví, výroba a státní správa, BizTalk Server hrál základní roli ve strategiích podnikové integrace. Azure Logic Apps, která je součástí Azure Integration Services, je moderní integrační platforma, která přináší zákazníkům hodnotu v BizTalku a zároveň přináší nové inovace, škálování a inteligentní funkce.
Funkce BizTalk Serveru	Azure Logic Apps, následník BizTalk Serveru, obsahuje mnoho základních funkcí BizTalk Serveru. Například modul pravidel Azure Logic Apps používá stejný modul runtime jako Modul pravidel BizTalk Business Rules Engine (BRE). HL7, MLLP, SWIFT a mnoho dalších technologií mají v Azure Logic Apps přímý ekvivalent, který zachovává vaše investice do BizTalk Serveru, snižuje refaktoring a podporuje spouštění vlastního kódu, rozhraní .NET Framework a nativní podpory XML.
Ceny založené na spotřebě	U tradičních platforem middlewaru musíte často provádět významné kapitálové investice do získání licencí a infrastruktury, což vás nutí budovat pro špičkovou kapacitu a vytvářet neefektivitu. Azure Integration Services poskytuje více cenových modelů, které vám obecně umožňují platit za to, co používáte. I když některé cenové modely umožňují a poskytují přístup k pokročilejším funkcím, máte flexibilitu platit za to, co využíváte.
Dolní bariéra pro vstup	BizTalk Server je velmi schopný middlewarový zprostředkovatel, ale vyžaduje významný čas učit se a získat odbornost. Azure Logic Apps zkracuje čas potřebný ke spuštění, učení, sestavování a doručování řešení. Například Azure Logic Apps obsahuje vizuální návrhář, který poskytuje prostředí bez potřeby psaní kódu nebo s nízkou mírou kódování pro vytváření deklarativních pracovních postupů, které chcete nahradit orchestrací BizTalk.
Připojení SaaS	S rozhraními REST API se stávají standardem pro integraci aplikací, více společností SaaS tento přístup přijalo při výměně dat. Microsoft vytvořil rozsáhlý a neustále se rozšiřující ekosystém konektorů se stovkami rozhraní API pro práci s microsoftovými i nemicrosoftovými službami, systémy a protokoly. V Azure Logic Apps můžete pomocí návrháře pracovních postupů vybrat operace z těchto konektorů, snadno vytvářet a ověřovat připojení a konfigurovat operace, které chtějí použít. Tato funkce urychluje vývoj a poskytuje větší konzistenci při ověřování přístupu k těmto službám pomocí OAuth2.
Několik geografických nasazení	Azure v současné době nabízí více než 60 oznámených oblastí, více než jakýkoli jiný poskytovatel cloudu, abyste si mohli snadno vybrat datacentra a oblasti, které jsou pro vás a vaše zákazníky vhodné. Díky tomuto dosahu můžete nasadit řešení konzistentním způsobem napříč mnoha zeměpisnými oblastmi a poskytuje příležitosti z hlediska škálovatelnosti i redundance.

Jak BizTalk Server funguje?

BizTalk Server používá architekturu modulu zasílání zpráv pro publikování a odběr zpráv s databází MessageBox v srdci. MessageBox zodpovídá za ukládání zpráv, vlastností zpráv, odběrů, stavů orchestrace, sledování dat a dalších informací.

Když BizTalk Server obdrží zprávu, server ji předá a zpracuje prostřednictvím potrubí. Tento krok normalizuje a publikuje zprávu do MessageBoxu. BizTalk Server pak vyhodnotí všechna existující odběry a určí zamýšlený příjemce zprávy na základě vlastností kontextu zprávy. BizTalk Server nakonec směruje zprávu zamýšlenému příjemci na základě odběrů nebo filtrů. Tento příjemce je buď portem pro odesílání, nebo orchestrací, což je cíl, kam BizTalk Server odesílá zprávy, nebo zdroj, odkud může BizTalk Server přijímat zprávy. BizTalk Server přenáší zprávy prostřednictvím portu pro odesílání tím, že je předává přes kanál pro odesílání. Kanál Send serializuje zprávy do nativního formátu očekávaného příjemcem před odesláním zpráv prostřednictvím adaptéru.

Databáze MessageBox má následující komponenty:

• Agent zasílání zpráv

  BizTalk Server komunikuje se MessageBox pomocí tohoto agenta, který poskytuje rozhraní pro publikování zpráv, přihlášení k odběru zpráv, načítání zpráv a další.

• Jedna nebo více databází SQL Serveru

  Tyto databáze poskytují trvalé úložiště pro zprávy, části zpráv, vlastnosti zpráv, odběry, stav orchestrace, sledující data, fronty hostitelů pro směrování a další.

Následující obrázek ukazuje, jak funguje modul zasílání zpráv BizTalk Serveru:

Jakmile port příjmu přijme zprávu, MessageBox uloží tuto zprávu ke zpracování obchodními procesy nebo ke směrování na všechny porty Pro odesílání, které mají odběry konkrétních zpráv.

Další informace najdete v části Architektura publikování a přihlášení k odběru dále v této příručce.

Azure Logic Apps: Následník BizTalku

Azure Logic Apps je platforma pro orchestraci a integraci pracovních postupů na podnikové úrovni od Microsoftu. Tato platforma je určená pro deterministické, dlouhotrvající stavové procesy napříč cloudovými a hybridními prostředími. Klíčový rozdílový modul kombinuje vizuální pracovní postupy s nízkým kódem a prvotřídními funkcemi platformy Azure: zabezpečení, identita, sítě, monitorování a zásady správného řízení. Azure Logic Apps podporuje více modelů nasazení (Consumption, Standard, Hybrid), které zákazníkům umožňují spouštět pracovní postupy plně spravované v Azure nebo v blízkosti místních systémů a přitom udržovat spolehlivost, správu stavu a auditovatelné spouštění. Díky této flexibilitě je platforma přirozenou oporou pro modernizaci infrastruktury BizTalk Serveru, orchestraci integrací B2B/EDI a propojení SaaS, ERP, CRM a starších systémů, kde spolehlivost a sledovatelnost jsou nepostradatelné.

Azure Logic Apps ale není výhradně "low-code". Zákazníci běžně používají rozšiřitelnost pomocí profesionálního kódu společně s vizuálními pracovními postupy: integrované C#, JavaScript a PowerShell, vlastní kód prostřednictvím místních funkcí, které běží v Azure Logic Apps, a vlastní konektory. Tato rozšiřitelnost umožňuje týmům vkládat složitou obchodní logiku, transformace, zpracování protokolů a ověřování přímo do orchestrací, aniž by porušily model pracovního postupu. V reálných scénářích, jako je zpracování deklarací identity, onboarding, kanály dodržování předpisů, sálový počítač a integrace zdravotní péče, se zákazníci spoléhají na Azure Logic Apps, aby fungovali jako řízená vrstva spouštění, která kombinuje deterministický orchestraci s vlastním kódem a stále častěji rozhodování s asistencí umělé inteligence a současně zachovává zásady správného řízení, zabezpečení a provozní spolehlivost ve velkém měřítku.

V Azure Logic Apps můžete vytvářet spustitelné obchodní procesy a aplikace jako pracovní postupy aplikací logiky pomocí programování ve stylu "stavebních bloků". Při tom využijete vizuálního návrháře a předem připravených operací ze stovek konektorů, což vyžaduje jen minimální množství kódu. Pracovní postup logické aplikace začíná spouštěcí operací, po které následuje jedna nebo více operačních akcí, přičemž každá operace funguje jako logický krok v procesu implementace pracovního postupu. Pracovní postup může používat akce k volání externího softwaru, služeb a systémů. Některé akce provádějí programovací úlohy, jako jsou podmínky, smyčky, operace s daty, správa proměnných a další.

Azure Logic Apps nabízí následující příklady výhod:

• Návrhář na prvním místě (deklarativní)

  Návrh složitých procesů pomocí snadno pochopitelného návrhového nástroje pro implementaci vzorů a pracovních postupů, které by jinak mohly být obtížné implementovat v kódu.

• Vývoj založený na kódu

  Vytvářejte komplexní řešení založená na kódu pomocí editoru Visual Studio Code, abyste mohli znovu použít stávající starší kód rozhraní .NET Framework a začlenit nejnovější verze .NET.

• Flexibilní a škálovatelné

  Azure Logic Apps je cloudová bezserverová, vysoce škálovatelná výpočetní služba, která se automaticky škáluje a přizpůsobuje měnícím se obchodním potřebám.

Prostředí pro vývojáře

Tato část shrnuje, jak se mění vývojové nástroje při migraci z BizTalk Serveru (zaměřeného na Visual Studio) na Azure Logic Apps (zaměřené na Visual Studio Code) a proč mnoho týmů považuje model pracovního postupu Azure Logic Apps za rychlejší na vytvoření a snazší na údržbu.

• Model nástrojů a vytváření

  Díky BizTalku probíhá každodenní integrace v sadě Visual Studio a je rozložená do více typů artefaktů, jako jsou schémata, mapy, orchestrace a kanály a balení nasazení (MSI/vazby) do prostředí sdíleného serveru.

  S Azure Logic Apps se mnoho týmů přesune do editoru Visual Studio Code pro úpravy definic pracovních postupů a souvisejících souborů pomocí jednoduššího přístupu "pracovní postup a konektory", který snižuje složitost řešení a podporuje menší a přírůstkové změny. V praxi je Visual Studio Code obvykle rychlejší na instalaci, aktualizaci a standardizaci mezi týmy než udržovat sladění verzí BizTalk a Visual Studio. Definice pracovních postupů založených na textu obvykle zlepšují Git diff, zracionalizují slučování, kontrolu kódu i opakované použití v porovnání s velkými zkompilovanými řešeními BizTalk.

• Co dělá přechod na Azure Logic Apps vylepšením

  Azure Logic Apps spáruje vývoj založený na editoru Visual Studio Code s diagnostikou nativní pro cloud. Můžete rychle ověřit a aktualizovat pracovní postupy a pak pomocí historie spuštění pracovního postupu zobrazit vstupy a výstupy operací, aniž byste museli spoléhat na konzoly na straně serveru a řešit potíže s instancemi hostitele. V migračních projektech tato výhoda obvykle urychluje iterace (úprava, nasazení, aktualizace, ověření), zlepšuje spolupráci, protože pracovní postupy jsou snadněji kontrolovatelné a vhodné pro verzování, a podporuje čistší oddělení prostředí díky externalizaci připojení a nastavení, což snižuje odchylky v konfiguraci typu „funguje na tomto serveru“.

Connectors

Konektory poskytují operace, které můžete použít jako kroky v pracovních postupech. Když vytváříte pracovní postupy pomocí Azure Logic Apps, konektory vám pomůžou pracovat s daty, událostmi a prostředky napříč aplikacemi, službami, systémy, protokoly a platformami často bez psaní kódu. Můžete vytvářet integrační řešení pro služby a systémy od Microsoftu i partnerů, včetně BizTalk Serveru, Salesforce, Office 365, mainframů IBM, databází SQL a mnoha služeb Azure, jako jsou Azure Functions, Azure Storage a Azure Service Bus, a také místní aplikace, SaaS a rozhraní API. Pokud pro prostředek, ke který chcete získat přístup, neexistuje žádný předem vytvořený konektor, můžete ke komunikaci se službou použít obecnou operaci HTTP nebo můžete vytvořit vlastní konektor.

Technicky vzato, konektor je proxy nebo obálka kolem rozhraní API, které používá podkladová služba nebo systém ke komunikaci s Azure Logic Apps. Konektory poskytují možnosti připojení v Azure Logic Apps a nabízejí abstrakci nad rozhraními API, která obvykle vlastní základní systém SaaS. Ke zjednodušení volání těchto rozhraní API používají konektory metadata k popisu kontraktu zasílání zpráv, aby vývojáři věděli, jaká data se v požadavku očekávají, a v odpovědi. Konektor pak zveřejňuje operace jako triggery nebo akce s konfigurovatelnými vlastnostmi. Některé triggery a akce vyžadují, abyste nejprve vytvořili a nakonfigurovali připojení k podkladové službě nebo systému a ověřili přístup k uživatelskému účtu.

Většina konektorů v Azure Logic Apps je integrovaná nebo spravovaná. Některé konektory jsou dostupné v obou verzích a dostupnost závisí na tom, jestli vytvoříte pracovní postup aplikace logiky Consumption nebo Standard. Pro scénáře migrace BizTalk Serveru se doporučují pracovní postupy standardní aplikace logiky, protože možnosti migrace BizTalk jsou k dispozici na úrovni Standard.

U mnoha migrací BizTalk se konektory, které vyberete, řídí běžnými požadavky na integraci, jako jsou místní připojení, přenos souborů, jako je SFTP, systémy zasílání zpráv a obchodní systémy.

• Integrované konektory nativně běží v modulu runtime Azure Logic Apps. Ve srovnání se spravovanými konektory integrované konektory obvykle snižují latenci a v závislosti na scénáři a konektoru se vyhýbají voláním jednotlivých připojení ke službě spravovaného konektoru.

• Spravované konektory se nasazují, hostují a spravují Microsoft v Azure. Tyto konektory poskytují triggery a akce pro cloudové služby, místní systémy nebo obojí.

V galerii konektorů návrháře se integrované konektory zobrazí pod předdefinovaný popisek, zatímco spravované konektory se zobrazí pod sdíleným popiskem. U pracovních postupů aplikace logiky Consumption se spravované konektory řídí cenovými modely Standard nebo Enterprise.

• Vlastní konektory umožňují zabalit rozhraní REST API, běžně pomocí definice OpenAPI nebo rozhraní SOAP API pomocí WSDL, pokud neexistuje žádný předem připravený konektor. Pokud pro rozhraní API, která chcete použít, neexistují žádné předem vytvořené konektory, můžete vytvořit vlastní konektor a získat přístup k ho z pracovních postupů aplikace logiky s příslušnými oprávněními.

V případě rozhraní REST API obvykle popisujete rozhraní API pomocí definice OpenAPI. Pro rozhraní SOAP API použijete WSDL. Vlastní konektor vytvoří kontrakt mezi Azure Logic Apps a rozhraním API, které vám pomůže sestavit zprávy požadavků a přijímat typové odpovědi, které můžete použít v podřízených akcích. Vlastní konektory můžou odkazovat na veřejná rozhraní API nebo privátní rozhraní API, včetně rozhraní API ve vaší místní síti.

Při implementaci vlastního konektoru poskytnete společné rozhraní pro odesílání požadavků a přijímání typovaných odpovědí, což zjednodušuje zkušenosti s vývojem.

Další informace najdete tady:

• Přehled integrovaných konektorů
• Přehled spravovaných konektorů
• V Azure Logic Apps dostupné spravované konektory
• Vlastní konektory a rozhraní API

Formování dat a artefakty

Při migraci integrací do Azure Logic Apps obvykle potřebujete následující:

• Strukturování dat v pracovním postupu, například analýza, vytváření a mapování.

• Jasná strategie pro ukládání a nasazování opakovaně použitelných artefaktů, jako jsou schémata, mapy, šablony a sestavení.

Následující části shrnují hlavní předdefinované možnosti pro transformace a běžná místa pro ukládání podpůrných artefaktů pro standardní pracovní postupy a sdílené scénáře B2B.

• Formování dat v pracovních postupech: operace s daty, výrazy a šablony Liquid

  U většiny transformací JSON v pracovních postupech aplikace logiky použijte integrované operace s daty, jako jsou akce Compose a Parse JSON, společně s výrazy a akcemi řízení pracovních postupů, jako jsou podmínky a smyčky, k tvarování dat. Pro pokročilejší scénáře mapování, zejména v případě, že chcete opakovaně použít šablonu pro transformace, jako je JSON-to-JSON, JSON-to-text, XML-to-JSON nebo XML-to-text, můžete použít šablonu Liquid. Šablony Liquid popisují mapování pomocí opensourcového jazyka šablon Liquid. Šablony můžete verzovat a nasazovat jako artefakty vedle vašeho pracovního postupu.

• Operace XML založené na schématu: Parsování XML a psaní XML

  V případě scénářů vytváření a ověřování XML v pracovních postupech aplikace logiky můžete použít integrované operace XML, jako je psaní XML se schématem a parsování XML pomocí akcí schématu . Tyto akce jsou nejužitečnější, pokud potřebujete zpracování XML silného typu (založené na XSD) místo zpracování datové části jako prostého textu. Potřebujete například konzistentní názvy prvků, datové typy a strukturu napříč několika pracovními postupy.

• Ukládání artefaktů ve standardních aplikacích logiky

  U standardních pracovních postupů aplikace logiky můžete artefakty integrace ukládat do samotného prostředku aplikace logiky. Na webu Azure Portal můžete nahrávat mapy a schémata přímo do prostředku aplikace logiky Standard. Pokud pracujete v editoru Visual Studio Code, můžete do příslušných složek v adresáři Artifacts projektu přidat schémata, mapy a šablony a nasadit je společně s pracovním postupem. Tato funkce usnadňuje zachování artefaktů při správě zdrojového kódu.

  Standardní pracovní postupy podporují volání vlastních kompilovaných sestavení, jako jsou sestavení rozhraní .NET Framework, z map XSLT. Tato podpora vám pomůže se scénáři migrace BizTalk, které spoléhají na existující logiku transformace.

• Uložení sdílených artefaktů B2B v integračním účtu

  Účet integrace je prostředek Azure, který poskytuje centralizovaný přístup k opakovaně použitelným B2B a artefaktům integrace, které může sdílet více pracovních postupů. Artefakty můžou zahrnovat obchodní partnery, smlouvy, schémata XSD, mapy XSLT, mapy založené na šablonách Liquid, certifikáty, dávkové konfigurace a sestavení rozhraní .NET Framework.

  Účty integrace se běžně používají ve scénářích B2B/EDI, ve kterých chcete sdílené a řízené úložiště artefaktů oddělit od každého pracovního postupu. U standardních pracovních postupů se často můžete vyhnout účtu integrace tím, že zabalíte schémata, mapy a šablony pomocí projektu standardní aplikace logiky a nasadíte je společně. Standardní pracovní postupy také podporují volání sestavení rozhraní .NET Framework z transformací XSLT, které vám můžou pomoct při portování existujících map BizTalk a pomocných knihoven. Pokud dáváte přednost přístupu založenému na projektu, přidejte schémata, mapy a sestavení v editoru Visual Studio Code a pak je nasaďte do Azure.

• Schémata EDI: Specializované artefakty XSD pro integrace B2B

  Schémata dokumentů EDI definují strukturu nebo tělo pro typ dokumentu transakce EDI. V projektech migrace BizTalk týmy často začínají opětovným použitím stejných definic XSD a následným iterativním ověřením variant specifických pro obchodní partnery. V případě pracovních postupů v Azure Logic Apps je mnoho schémat BizTalk EDI v úložišti Microsoft Integration GitHub veřejně dostupné pro použití. Na základě vašeho přístupu k implementaci můžete tato schémata ukládat společně se standardní aplikací logiky jako artefakty projektu nebo centrálně v účtu integrace pro opakované použití napříč několika pracovními postupy.

Connectivity

Model připojení v Azure Logic Apps se liší od BizTalk Serveru, částečně kvůli vývoji ekonomiky rozhraní API. Vzhledem k tomu, že více organizací zpřístupňuje přístup k podkladovým systémům a datům, byl potřeba přístup nezávislý na platformě. REST je nyní dominantním přístupem k architektuře návrhu moderních webových služeb.

V Azure Logic Apps je výchozí přístup REST pro připojení systémů. Vzhledem k tomu, že microsoft a další dodavatelé softwaru zpřístupňují služby RESTful nad svými systémy a daty, azure Logic Apps může tento typ informací zveřejnit a využívat. Specifikace OpenAPI umožňuje této funkci lidem i počítačům pochopit interakci mezi klientem a serverem prostřednictvím metadat. V rámci tohoto porozumění se odvozují datové části požadavků i odpovědí, což znamená, že můžete použít dynamický obsah k naplnění vstupů akce pracovního postupu a použití výstupů z odpovědi v podřízených akcích.

Na základě dodavatele softwaru, který implementuje podkladovou službu, kterou konektor volá, se schémata ověřování liší podle konektoru. Obecně platí, že tato schémata zahrnují následující typy:

• Základní
• Klientský certifikát
• Active Directory OAuth
• Nezpracovaný
• Spravovaná identita

Microsoft poskytuje silné vrstvy ochrany šifrováním dat během přenosu a v klidu. Když se zákaznický provoz Azure přesune mezi datovými centry, mimo fyzické hranice, které nejsou řízené Microsoftem nebo jménem Microsoftu, použije metodu šifrování vrstvy datového propojení, která používá standardy zabezpečení MAC IEEE 802.1AE MAC (MACsec) z bodu do bodu napříč základním síťovým hardwarem.

Microsoft vám dává možnost použít protokol TLS (Transport Layer Security) k ochraně dat, která cestují mezi cloudovými službami a zákazníky. Datacentra Microsoftu vyjednávají připojení TLS s klientskými systémy, které se připojují ke službám Azure. Tls poskytuje silné ověřování, ochranu osobních údajů a integritu zpráv, což umožňuje detekci manipulace se zprávami, zachycení a padělání spolu s interoperabilitou, flexibilitou algoritmů a snadným nasazením a používáním.

I když se tato část zaměřuje na připojení RESTful prostřednictvím konektorů, můžete implementovat připojení webové služby SOAP prostřednictvím vlastního prostředí konektoru nebo pomocí rozhraní API Management, které poskytuje skvělé možnosti SOAP. Další informace najdete v tématu Zvýšení obchodní hodnoty integrací starších prostředků PROTOKOLU SOAP se službou Azure Logic Apps a službou Azure API Management.

Odolnost zpráv

Azure Logic Apps poskytuje odolnost zpráv následujícími způsoby:

• Stavové pracovní postupy v aplikacích logiky Standard uchovávají stav pracovního postupu a vstupy operací a výstupy do úložiště pomocí kontrolních bodů. Tato trvalost zajišťuje trvalé provádění a bohatou historii pracovních postupů, abyste mohli zkontrolovat podrobné vstupy a výstupy operací.

• Můžete znovu odeslat nebo znovu spustit běh pracovního postupu v Azure portálu nebo pomocí rozhraní API.

  Opětovné odeslání může způsobit, že pracovní postup zpracuje stejnou zprávu znovu, proto se ujistěte, že návrhy předpokládají alespoň jedno zpracování a implementují idempotenci. Můžete například použít klíče odstranění duplicitních dat, upserty nebo přesně jednou efekty v cíli.

  Na základě typu a konfigurace pracovního postupu můžete znovu odeslat také z konkrétního bodu spuštění. Ujistěte se ale, že podřízené systémy můžou bezpečně zpracovávat opakování a potenciální duplicity.

• Díky zprávám s náhledovým zámkem ve službě Azure Service Bus může příjemce zpracovat zprávu a poté tuto zprávu výslovně potvrdit. Příjemce může například zprávu dokončit a pak ji odebrat z fronty, nebo příjemce může zprávu opustit a zpřístupnit ji pro opětovné nasazení.

  Pokud chcete tuto funkci použít v Azure Logic Apps, použijte konektor Azure Service Bus. Režim peek-lock zlepšuje spolehlivost a podporuje vzory pro opakování nebo opětovné doručení. Kompletní zpracování však obvykle vyžaduje idempotenci v podřízených systémech.

• S RabbitMQ můžete běžně dosáhnout odolnosti pomocí trvalých front nebo výměn společně s trvalými zprávami a spoléhat se na potvrzení příjemce, aby systém mohl znovu doručit zprávy, pokud zpracování selže před odesláním potvrzení. Při integraci pomocí konektoru RabbitMQ použijte stejný princip návrhu jako ostatní zprostředkovatele: předpokládejte opakování a potenciální duplicity a zajistěte, aby zpracování následných úloh bylo idempotentní.

• S IBM MQ můžete obvykle adresovat stálost a spolehlivé doručování pomocí trvalých zpráv a transakčního zpracování (jednotky práce). Pak máte možnost potvrdit nebo vrátit zpět přijaté zprávy a následné práce jako celek. Pokud dojde k selhání před uložením práce nebo potvrzením zprávy, může být zpráva k dispozici pro opětovné doručení.

  Při použití konektoru IBM MQ navrhujte systém pro zajištění alespoň jednoho doručení a ošetřete možné duplicity na cílovém místě. Ve scénářích migrace BizTalk se tento model obvykle mapuje na návrh pracovního postupu aplikace logiky a podřízených koncových bodů pro bezpečné opětovné zpracování, například pomocí identifikátorů korelace, odstranění duplicitních dat a idempotentních zápisů, a ne spoléhání se na zprostředkovatele samotného pro komplexní chování přesně jednou.

Architektura publikování a odběru

V porovnání s modulem zasílání zpráv BizTalk Server služba Azure Logic Apps používá konektory a externí služby zasílání zpráv k implementaci vzorů zasílání zpráv spolu s orchestrací pracovních postupů. U vzorů publikování a odběru (pub-sub) pomocí Azure Logic Apps zahrnují běžné možnosti zprostředkovatele Azure Service Bus (témata a předplatná) a RabbitMQ. Azure Service Bus je plně spravovaný podnikový zprostředkovatel zpráv s frontami a tématy pub-sub, která můžete použít k oddělení aplikací a služeb, což přináší následující výhody:

• Vyrovnávání zatížení práce mezi konkurenčními pracovníky
• Bezpečně směrujte a přenášejte data s kontrolou přes hranice služeb a aplikací.
• Koordinovat transakční práci, která vyžaduje vysoký stupeň spolehlivosti.

Azure Logic Apps obsahuje konektor služby Azure Service Bus, který můžete použít k publikování a přihlášení k odběru zpráv. Výhodou je, že zasílání zpráv můžete používat nezávisle na pracovním postupu. Na rozdíl od BizTalk Serveru je zasílání zpráv oddělené od modulu pracovního postupu. Ve službě Azure Service Bus můžete vytvářet odběry zpráv a používat vlastnosti zpráv (vlastnosti uživatele) jako páry klíč-hodnota, které se vyhodnocují filtry v odběru tématu. Tyto vlastnosti uživatele definujete při nastavování operace služby Azure Service Bus přidáním jednoho nebo více párů klíč-hodnota. Ukázku najdete ve videu: Pub Sub Messaging using Azure Integration Services – část 2: Směrování založené na obsahu.

Azure Logic Apps s pracovními postupy Standard zahrnuje také integrovaný konektor RabbitMQ, který můžete použít k odesílání a přijímání zpráv. V RabbitMQ obvykle implementujete pub-sub model publikováním do exchange a umožníte více příjemcům přijímat zprávy prostřednictvím samostatných front, které jsou svázány s touto exchange. To se často provádí pomocí směrovacích klíčů nebo směrování na základě hlaviček, v závislosti na typu exchange. Tento přístup podporuje vzory distribuce založené na ventilátorech a směrování podobných tématům a pravidlům odběru služby Service Bus, ale konfiguruje se pomocí výměn, vazeb a nastavení fronty RabbitMQ. RabbitMQ je často silnou možností, pokud máte existující místní infrastrukturu RabbitMQ, potřebujete možnosti zprostředkovatele v prostředích, kde Azure Service Bus není k dispozici, nebo chcete uchovávat zasílání zpráv lokální v rámci sítě, kde běží producenti a spotřebitelé. Stejně jako u jakékoli integrace založené na zprostředkovatelích navrhujte mechanismy pro opakování a ochranu proti potenciálním duplicitám, například pomocí potvrzení, perzistentních front a perzistentních zpráv, kde je to vhodné, a zajistěte idempotentnost následného zpracování.

U mnoha migračních projektů BizTalk je Azure Service Bus běžnou standardní volbou pro cloudově nativní pub-sub, protože služba je plně spravovaná a poskytuje integrovanou tematiku a sémantiku předplatného s filtrováním. Pro místní požadavky pub-sub může být RabbitMQ vhodnější, zejména s modelem hybridního nasazení Azure Logic Apps, protože Azure Service Bus je cloudová služba a nemá možnost místního nasazení. V těchto případech standardizujte stálost a sémantiku opakování a použijte idempotenci na hranicích pracovního postupu a koncového bodu.

Modul obchodních pravidel

Azure Logic Apps zahrnuje modul pravidel Azure Logic Apps. Tento modul pravidel zahrnuje modul runtime BizTalk Business Rules Engine (BRE), abyste mohli znovu použít existující zásady BizTalk BRE. V současné době existuje podpora pouze pro fakta XML a rozhraní .NET Framework.

Sítě

V případě příchozího a odchozího připojení poskytuje Azure několik způsobů, jak izolovat své služby v rámci hranice sítě a připojit místní a cloudové úlohy. Následující seznam popisuje různé způsoby integrace prostředků Azure s prostředky uvnitř hraniční sítě:

• Hybridní připojení

  Služba Hybrid Connections je jak službou, tak funkcí v rámci Azure App Service a podporuje scénáře a funkcionality, které přesahují možnosti dostupné ve standardní službě Azure App Service. Další informace o využití mimo službu Aplikace Azure Service najdete v tématu Azure Relay Hybrid Connections. Ve službě Azure App Service můžete pomocí hybridních připojení přistupovat k prostředkům aplikace v jakékoli síti, která může provádět odchozí volání do Azure přes port 443. Hybridní připojení poskytují přístup z vaší aplikace ke koncovému bodu TCP a neumožňují nový způsob přístupu k aplikaci. V Aplikace Azure Service každé hybridní připojení koreluje s jedním hostitelem TCP a kombinací portů. Tato funkce umožňuje aplikacím přístup k prostředkům v jakémkoli operačním systému za předpokladu, že existuje koncový bod TCP. Hybridní připojení neví nebo nezajímá aplikační protokol nebo to, k čemu chcete získat přístup. Tato funkce jednoduše poskytuje přístup k síti.

• Integrace virtuální sítě

  Díky integraci služby Azure Virtual Network můžete svůj prostředek Azure připojit k virtuální síti nakonfigurované v Azure a poskytnout tak aplikaci přístup k prostředkům v této virtuální síti. Integrace virtuální sítě v Azure Logic Apps se používá jenom k odchozím voláním z vašeho prostředku Azure do vaší virtuální sítě.

  Pomocí partnerského vztahu virtuálních sítí můžete připojit místní sítě k Azure, což poskytuje obousměrné připojení mezi místními prostředky a službami Azure. Služba Azure Integration Services poskytuje připojení k virtuální síti, což umožňuje hybridní integraci.

  Následující obrázek ukazuje prostředek logické aplikace Standard s otevřenou stránkou Síť a povolenou integrací virtuální sítě, jak je zvýrazněno v poli Odchozí provoz. Tato konfigurace zajišťuje, že veškerý odchozí provoz opustí tuto virtuální síť.

  

• Privátní koncové body

  Privátní koncový bod je síťové rozhraní, které používá privátní IP adresu z vaší virtuální sítě. Toto síťové rozhraní se soukromě a bezpečně připojuje k prostředku Azure, který využívá Azure Private Link. Když povolíte privátní koncový bod, přenesete tento prostředek Azure do vaší virtuální sítě a povolíte prostředkům v síti provádět příchozí volání vašeho prostředku Azure.

Vlastní kód

V Azure Logic Apps můžete vytvořit a spustit kód .NET v pracovním postupu standardní aplikace logiky. K tomu je potřeba použít Visual Studio Code s rozšířením Azure Logic Apps (Standard).

Konektor Operace vloženého kódu poskytuje akce s názvem Execute JavaScript Code, Execute CSharp Script Code a Execute PowerShell Code. Pomocí těchto akcí můžete přidat kód, který podporuje vstupy a výstupy dynamického obsahu. Modul Azure Logic Apps očekává, že tento kód bude mít krátkou dobu provádění. Po dokončení provádění kódu je výstup k dispozici pro podřízené akce, které se mají použít v pracovním postupu.

Jak jsme už zmínili, podpora volání sestavení rozhraní .NET Framework z mapy XSLT je aktuálně k dispozici v pracovních postupech aplikace logiky při nahrávání těchto sestavení do účtu integrace. Tato funkce pomáhá podporovat vlastní pravidla transformace dat. Pro standardní pracovní postupy Logic Apps můžete volat kód .NET Framework z XSLT map bez potřeby účtu pro integraci. Můžete také přidat sestavení a mapy do projektu standardní aplikace logiky v editoru Visual Studio Code a následně je nasadit do Azure. Další informace najdete v tématu Podpora sestavení rozhraní .NET Framework přidaná v transformacích XSLT pro Azure Logic Apps (Standard).

Skupiny aplikací

V Azure Logic Apps můžete zahrnout a spustit více pracovních postupů v prostředku standardní logické aplikace, což vede k relaci jedna k mnoha. Pokud pracujete místně na projektu standardní aplikace logiky v editoru Visual Studio Code, prostředek aplikace logiky se mapuje na tento jediný projekt. Díky tomuto přístupu můžete snadno a logicky seskupit související úlohy, kód a artefakty ve stejném projektu a nasadit tento projekt jako jednu jednotku.

Cloudové architektury fungují jinak než serverová paradigmata, jako je BizTalk. Azure Logic Apps (Standard) používá model vyžádání změn k přenesení kódu a artefaktů. V důsledku toho zkopírujete všechny další nezbytné artefakty do projektu a následně je nasadíte pomocí kódu a dalších artefaktů. V některých případech se můžete chtít vyhnout kopírování potřebného kódu a artefaktů. Pokud ano, můžete zvážit přeměnu této funkce na službu, kterou můžete spravovat samostatně, ale můžete volat z pracovního postupu.

Předpokládejme například, že máte transformaci dat, kterou vaše organizace široce používá. Místo zahrnutí mapy pro transformaci napříč několika projekty aplikace logiky můžete implementovat rozhraní, které transformaci poskytuje jako službu. Životní cyklus této služby pak můžete spravovat odděleně od projektů aplikací logiky a volat tuto službu z pracovních postupů.

Když máte možnost zahrnout do projektu aplikace logiky standard více pracovních postupů, můžete se zeptat, jak byste tyto pracovní postupy uspořádali v rámci projektu nebo napříč více projekty? Odpověď obvykle závisí na vašich požadavcích, například:

• Spřažení obchodních procesů
• Kompletní monitorování a podpora
• Zabezpečení, řízení přístupu na základě role a izolace sítě
• Výkon a důležitost obchodních aktivit
• Geografická poloha a geografická redundance

Další informace najdete v tématu Uspořádání pracovních postupů aplikací logiky ve službě Azure Logic Apps (Standard).

Zabezpečení a zásady správného řízení

Azure Logic Apps podporuje následující možnosti zabezpečení:

• Azure Key Vault

  Přihlašovací údaje, tajné kódy, klíče rozhraní API a certifikáty můžete ukládat pomocí služby Azure Key Vault. V Azure Logic Apps můžete k informacím přistupovat pomocí konektoru služby Azure Key Vault a vyloučit tyto informace z protokolů platformy a historie spuštění pomocí zabezpečených vstupů a výstupních funkcí.

  V části Sledování tato příručka dále popisuje funkcionalitu historie spuštění, která poskytuje podrobné přehrání provádění pracovního postupu. Přestože Azure Logic Apps nabízí hodnotu zachycení každého vstupu a výstupu při spuštění pracovního postupu, někdy potřebujete spravovat přístup k citlivým datům podrobněji. Pro tato data můžete nastavit obfuskaci pomocí funkce zabezpečených vstupů a výstupů pro triggery a akce, které tento obsah skryjí z historie spuštění a zabrání odesílání těchto dat do služby Azure Monitor, konkrétně Log Analytics a Application Insights. Následující obrázek ukazuje příklad výsledku povolení zabezpečených vstupů a zabezpečených výstupů v historii spuštění.

  

• Integrace založená na OAuth

  Většina konektorů používá tento typ ověřování při vytváření připojení. Díky tomuto přístupu je integrace s mnoha službami SaaS stejně snadná jako poskytování e-mailové adresy a hesla. Azure API Management také podporuje OAuth, takže obě služby můžete používat společně tím, že poskytuje jednotné schéma ověřování.

  Tato funkce není nativně dostupná na BizTalk Serveru.

• Spravované identity

  Azure Logic Apps (Standard) může ověřovat přístup k účtům úložiště pomocí spravované identity. Některé konektory také podporují použití spravovaných identit pro ověřování přístupu k prostředkům chráněným ID Microsoft Entra. Pokud ke ověřování připojení používáte spravovanou identitu, nemusíte zadávat přihlašovací údaje, tajné kódy ani tokeny Microsoft Entra.

Správa aplikací a správa přístupu

Azure Portal je běžný nástroj, který správci a pracovníci podpory používají k zobrazení a monitorování stavu rozhraní. Pro Azure Logic Apps toto prostředí zahrnuje bohaté trasování transakcí, které jsou dostupné prostřednictvím historie spuštění. K dispozici jsou také podrobné řízení přístupu na základě role (RBAC), abyste mohli spravovat a omezovat přístup k prostředkům Azure na různých úrovních.

Storage

Azure Logic Apps spoléhá na Službu Azure Storage k ukládání a automatickému šifrování neaktivních uložených dat. Toto šifrování chrání vaše data a pomáhá dodržet závazky vaší organizace z hlediska zabezpečení a dodržování předpisů. Ve výchozím nastavení služba Azure Storage používá k šifrování dat klíče spravované Microsoftem. Další informace najdete v tématu Šifrování služby Azure Storage pro neaktivní uložená data.

Když pracujete se službou Azure Storage na webu Azure Portal, probíhají všechny transakce přes PROTOKOL HTTPS. S Azure Storage můžete pracovat také pomocí rozhraní REST API služby Storage přes HTTPS. Pokud chcete vynutit použití protokolu HTTPS při volání rozhraní REST API pro přístup k objektům v účtech úložiště, povolte zabezpečený přenos požadovaný pro účet úložiště.

Model hybridního nasazení Azure Logic Apps (Standard) spoléhá na SQL Server. Tato závislost umožňuje používat existující místní prostředí SQL Serveru s BizTalk Serverem.

Zpracování velkých souborů

Mezi zpracováním velkých souborů pomocí BizTalk Serveru a Azure Logic Apps existují některé základní rozdíly. Například pečlivě prověřte scénáře velkých zpráv, abyste našli správné řešení, protože potenciálně existují různé způsoby řešení tohoto problému v moderním cloudovém prostředí.

Omezení velikosti souboru

V Azure existují limity velikosti souborů, které zajišťují konzistentní a spolehlivé prostředí. Pokud chcete svůj scénář ověřit, nezapomeňte si projít dokumentaci k limitům služeb pro Azure Logic Apps. Některé konektory podporují vytváření bloků zpráv pro zprávy, které překračují výchozí limit velikosti zpráv, což se liší podle konektoru. Bloky zpráv fungují rozdělením velké zprávy na menší zprávy.

Azure Logic Apps není jedinou službou, která má omezení velikosti zpráv. Například Azure Service Bus má také taková omezení. Další informace o zpracování velkých zpráv ve službě Azure Service Bus najdete v tématu Podpora velkých zpráv.

Abyste se vyhnuli omezením velikosti souborů, můžete implementovat vzor kontroly deklarací identity, který funguje rozdělením velké zprávy na kontrolu deklarací identity a datovou částí. Tuto kontrolu žádosti odešlete na platformu pro zasílání zpráv a uložíte datovou část do externí služby. Tímto způsobem můžete zpracovávat velké zprávy, zatímco chráníte sběrnici zpráv a klienta před přetížením. Tento model také pomáhá snížit náklady, protože úložiště je obvykle levnější než jednotky prostředků používané platformou zasílání zpráv.

Monitorování a upozornění

V Azure Logic Apps můžete povolit podporu Application Insights, která poskytuje kurátorované vizualizace jako základ pro monitorování služeb Azure. Tyto vizualizace vám pomůžou efektivněji monitorovat standardní pracovní postupy pomocí řídicích panelů určených speciálně pro Azure Logic Apps (Standard). Obor řídicího panelu pokrývá pracovní postupy v rámci standardní aplikace logiky. Řídicí panel je založený na Azure Workbooks a nabízí různé vizualizace. Tyto sešity můžete snadno rozšířit a přizpůsobit tak, aby vyhovovaly konkrétním potřebám.

Bezserverová verze 360 je externí řešení od Kovai , které poskytuje monitorování a správu prostřednictvím mapování služeb Azure, jako jsou Azure Logic Apps, Azure Service Bus, Azure API Management a Azure Functions. Zprávy můžete znovu zpracovat pomocí front nevyřízených zpráv ve službě Azure Service Bus, povolit samoléčení k řešení občasných narušení služeb a nastavit proaktivní monitorování prostřednictvím umělých transakcí.

V prostředí portálu můžete nakonfigurovat vlastní pravidla monitorování a zobrazit protokoly. Oznámení můžete posílat prostřednictvím různých kanálů, jako jsou e-maily, Microsoft Teams a ServiceNow. K vizuálnímu určení stavu vašich rozhraní jsou k dispozici mapy služeb.

Monitorování obchodních aktivit

Jako vývojář nebo obchodní analytik pracující na řešeních, která integrují služby a systémy pomocí různých prostředků Azure, můžete mít potíže s vizualizací vztahu mezi technickými součástmi ve vašem řešení a obchodním scénářem. Pokud chcete do svého řešení zahrnout obchodní kontext o prostředcích Azure, můžete vytvářet obchodní procesy, které vizuálně reprezentují obchodní logiku implementovanou těmito prostředky. Ve službě Azure Business Process Tracking je obchodní proces řadou fází, které představují úlohy procházející reálným obchodním scénářem.

Další možností je, že můžete použít externí řešení z Kovai s názvem Bezserverová verze 360. Společně s monitorovací platformou můžete použít funkci monitorování obchodních aktivit, která poskytuje kompletní sledování toků obchodních procesů napříč nativními cloudovými a hybridními integracemi. Tato funkce zahrnuje spravovaný konektor, který můžou vývojáři použít k instrumentaci kódu a zachycení důležitých obchodních dat. Správci můžou následně vytvářet řídicí panely a sdílet je s obchodními analytiky.

Sledování

Azure Logic Apps poskytuje bohatou historii spuštění pracovních postupů, aby vývojáři a analytici podpory mohli zkontrolovat telemetrii akcí po akci, včetně všech zpracovaných vstupů a výstupů. Pokud chcete chránit všechna citlivá data, můžete povolit zabezpečené vstupy a výstupy jednotlivých akcí v pracovních postupech. Tato funkce obfuskuje nebo skryje data v protokolech a historii spuštění pracovního postupu, aby nedocházelo k únikům.

Kromě obfuskace dat můžete k ochraně přístupu k datům použít pravidla Azure RBAC . Azure RBAC zahrnuje konkrétní předdefinované role pro Azure Logic Apps (Standard). Kromě Azure RBAC můžete omezit přístup k historii spuštění v Azure Logic Apps podle rozsahu IP adres.

Hosting

• Plány hostingu

  V Azure Logic Apps s jedním tenantem můžete k hostování více standardních aplikací logiky použít jeden plán služby pracovního postupu. To znamená, že nemusíte nasazovat všechny pracovní postupy v jednom prostředku Standard logic app. Místo toho můžete tyto pracovní postupy uspořádat do logických skupin (aplikací logiky), které vám pomůžou lépe spravovat další aspekty vašeho řešení. Tento přístup vám pomůže maximálně využít plán služby pracovních postupů a připravit vaše aplikace na budoucnost tím, že je budete implementovat tak, aby mohly být individuálně škálovány.

  Aplikace logiky Standard má následující cenové úrovně: WS1, WS2 a WS3. Funkčně poskytuje každá úroveň stejné možnosti. Požadavky na výpočetní prostředky a paměť určují, co je pro váš scénář nejvhodnější, například:

  Cenová úroveň	Virtuální procesor (vCPU)	Paměť (GB)
  WS1	1	3.5
  WS2	2	7
  WS3	4	14

  Další informace najdete v tématu Cenové úrovně v modelu Standard.

• Model hybridního nasazení

  Azure Logic Apps nabízí model hybridního nasazení, abyste mohli nasadit a hostovat pracovní postupy standardních aplikací logiky v místních scénářích, privátním cloudu nebo veřejném cloudu. Tento model poskytuje možnosti hostování řešení integrace v částečně propojených prostředích, když potřebujete použít místní zpracování, úložiště dat a síťový přístup. Díky hybridní možnosti máte volnost a flexibilitu při výběru nejvhodnějšího prostředí pro pracovní postupy. Další informace najdete v tématu Nastavení vlastní infrastruktury pro aplikace logiky standardu pomocí hybridního nasazení.

• Dostupnost a redundance

  Zóny dostupnosti v Azure poskytují odolnost, distribuovanou dostupnost a škálovatelnost zón aktivní-aktivní. Pokud chcete zvýšit dostupnost úloh aplikace logiky, můžete povolit podporu zóny dostupnosti, ale jenom při vytváření aplikace logiky. V libovolné oblasti Azure, která podporuje a umožňuje redundanci zón, budete potřebovat aspoň tři samostatné zóny. Platforma Azure Logic Apps distribuuje tyto zóny a úlohy aplikací logiky napříč těmito zónami. Tato funkce je klíčovým požadavkem na povolení odolných architektur a zajištění vysoké dostupnosti v případě selhání datacenter v určité oblasti. Další informace najdete v tématu Vytváření řešení pro zajištění vysoké dostupnosti pomocí zón dostupnosti.

• Izolované a vyhrazené prostředí

  U standardních aplikací logiky máte možnost vybrat službu App Service Environment (ASE) v3 pro vaše prostředí nasazení. S ase v3 získáte plně izolované a vyhrazené prostředí pro spouštění aplikací ve velkém měřítku s předvídatelnými cenami. Platíte jenom za ASE App Service plán, bez ohledu na to, kolik logických aplikací vytvoříte a spustíte.

Scénáře, které vyžadují další integrační služby Azure, najdete v následující dokumentaci:

• Plány zasílání zpráv pro Azure Service Bus Premium a Standard
• Azure API Management – Porovnání vrstev na základě funkcí

Nasazení

Azure Logic Apps podporuje infrastrukturu jako kód (IaC) tím, že poskytuje možnost vytvářet prostředky infrastruktury pomocí šablon Azure Resource Management. I když se šablony ARM můžou zdát složité pochopit a implementovat jako sjednocené řešení, můžete použít abstrakční nástroje, jako jsou Bicep, Terraform nebo Pulumi, které poskytují prostředí podobné kódu pro vytvoření definice infrastruktury. I když tyto nástroje poskytují abstraktní vrstvy nad šablonami ARM, nástroje nakonec generují šablony ARM a můžou tyto šablony nasadit za vás.

S vaší infrastrukturou můžete nasadit logiku, která implementuje kompletní pracovní postupy. Vzhledem k tomu, že služba Azure Integration Services nabízí kolekci nástrojů pro implementaci pracovních postupů integrace, musíte nasadit každou komponentu. U řešení vytvořených pomocí Azure Integration Services jsou kanály CI/CD obvykle založené na nasazení orchestrace komponent. Technici DevOps můžou používat integrované akce, které abstrahují aktivity nasazení, nebo používají obecné akce, které spouštějí příkazy rozhraní příkazového řádku nebo automatizační skripty, jako jsou PowerShell a Bash. Ve většině případů technici přizpůsobují kanály podle potřeb aplikace, prověřují pokyny z oficiální dokumentace a jako výchozí bod používají ukázková úložiště.

Proces přípravy jednotlivých komponent na nasazení obvykle bere v úvahu následující kroky:

• Fáze kontinuální integrace

  1. Získejte nejnovější verzi zdrojového kódu.

  2. Připravte kód s konfigurací specifickou pro prostředí.

     Podrobnosti pro tento krok závisí na podpoře každé technologie pro externí injektáž proměnných prostředí. Základní myšlenkou je, že informace o konfiguraci založené na prostředí, jako jsou připojovací řetězce a odkazy na externí prostředky, jsou abstrahovány tak, aby bylo možné odkazovat na úložiště nastavení aplikace. V tomto scénáři byste proto uložili odkazy, které mohou existovat jako prostý text přímo v úložišti nastavení aplikace, ale citlivé hodnoty, jako jsou tajemství, byste uložili jako ukazatele na položky v úložišti tajemství, jako je například Azure Key Vault.

     Azure Logic Apps umožňuje tento přístup pro prostředek standardní aplikace logiky tím, že podporuje odkazy na úložiště nastavení aplikace, které pak můžete mapovat páry název-hodnota na položky v trezoru klíčů.

  3. Zabalte kód pro nasazení v různých prostředích.

• Fáze průběžného nasazování

  1. Nasaďte zabalený kód v cílovém prostředí.

  2. Aktualizujte úložiště nastavení aplikace správnými hodnotami prostředí, a to buď jako prostý text, nebo odkazy na položky ve vašem trezoru klíčů.

  3. Aktualizujte všechna požadovaná oprávnění, která závisí na kódu.

  4. V případě potřeby připravte aplikaci na spuštění.

Porovnání funkcí

Následující tabulka a diagram ukazuje, jak se prostředky, artefakty, funkce a možnosti porovnávají a shodují mezi BizTalk Serverem, Azure Logic Apps (Standard) a dalšími službami. Snažte se využívat funkce Azure Logic Apps co nejvíce k vytvoření soudržného a nákladově efektivnějšího řešení.

Azure Logic Apps Standard (cloud)

Funkce nebo funkcionalita	BizTalk Server	Azure Logic Apps (cloud)
Orchestrace	– Orchestrace BizTalk Serveru – Kód jazyka C#	– Pracovní postup Azure Logic Apps – Šablony pracovních postupů Azure Logic Apps – Místní funkce
Pipelines	– Kanály BizTalk Serveru – Součásti kanálu	– Pracovní postupy Azure Logic Apps jako kanály – Místní funkce
Směrování zprávy	-Messagebox - Propagace majetku - Filtry	– Fronty a témata služby Azure Service Bus (hlavičky zpráv, vlastnosti zpráv a předplatná) - RabbitMQ Výměny
Připojení aplikace	- BizTalk Server standardní a vlastní adaptéry – Internetová informační služba (IIS) a Azure API Management (hybridní funkce)	– Konektory Azure Logic Apps
Křížové odkazy	xref_ * tabulky v databázi bizTalk Management (BizTalkMgmtDb)	– Místní funkce
Schémata (XSD)	– Schémata BizTalk Serveru – schémata XML, JSON a plochých souborů	– Azure Logic Apps (Standard) – Účet integrace Azure – Účet úložiště Azure
Maps	– BizTalk Mapper - Mapy XSLT – Azure API Management (hybridní funkce)	– Azure Logic Apps (Standard) – mapy XSLT, šablony Liquid – Účet integrace Azure (mapy XSLT, šablony Liquid) – Účet úložiště Azure – Nástroj mapovač dat (rozšíření Azure Logic Apps Standard pro Visual Studio Code)
Obchodní pravidla	BizTalk Server Stroj pro obchodní pravidla	Stroj pravidel Azure Logic Apps
Monitorování obchodních aktivit	Monitorování obchodních aktivit BizTalk Serveru	Sledování obchodních procesů Azure
EDI	- Standardní funkce BizTalk Serveru - Strany, partneři, dohody, AS2, X12, EDIFACT	Azure Logic Apps a účet integrace Azure (partneři, smlouvy, AS2, X12, EDIFACT)
HL7, RosettaNet a SWIFT	Akcelerátory BizTalk Serveru pro HL7, RosettaNet a SWIFT	– Azure Logic Apps: Účet integrace Azure a konektory HL7, MLLP, RosettaNet a SWIFT
Tajné kódy	Jednotné přihlašování organizace (SSO)	– Azure Key Vault – SQL Server – Konfigurace aplikace
Zabezpečení a zásady správného řízení	– Jednotné přihlašování organizace (SSO) - partnerské aplikace SSO – Active Directory - Podpisové certifikáty – Ověřování zabezpečení služby IIS - Zabezpečení sítě	– Microsoft Entra ID – Zabezpečení sítě Azure – Řízení přístupu na základě role v Azure (Azure RBAC) - Nároky, tokeny – Zásady sdíleného přístupu
Konfigurace dat	– Konfigurační soubory – Konfigurace aplikace podnikového jednotného přihlašování – Vlastní součásti mezipaměti – Vlastní databáze – Registr Systému Windows	– Azure Key Vault – konfigurace Aplikace Azure – Azure Cosmos DB – Azure Table Storage – Konfigurace Azure Logic Apps (Standard) – SQL Server – Vlastní ukládání do mezipaměti – Vlastní databáze
Nasazení	– Soubor vazby BizTalk Serveru	– Azure Pipelines – Skripty Bicep - Terraform
Sledování	– Možnosti sledování BizTalk Serveru (přijímací porty, odesílací porty, kanály, orchestrace) – Sledování služby IIS – Integrovaná analýza služby Azure API Management (hybridní funkce)	– Historie spuštění pracovního postupu Azure Logic Apps a sledované vlastnosti – Účet služby Azure Storage – Azure Monitor (Application Insights)
Sledování	– Konzola pro správu BizTalk – BizTalk Health Monitor	Azure Monitor (Application Insights, Log Analytics)
Operace	– Konzola pro správu BizTalk Serveru – Azure Pipelines – MSI, PowerShell – BizTalk Deployment Framework	– Azure Portal – Azure Monitor – Šablony Azure Resource Manageru – Azure Pipelines – PowerShell, CLI, Bicep

Azure Logic Apps Standard pro hybridní prostředí (místní)

Funkce nebo funkcionalita	BizTalk Server	Azure Logic Apps (hybridní)
Orchestrace	– Orchestrace BizTalk Serveru – Kód jazyka C#	– Pracovní postup Azure Logic Apps – Šablony pracovních postupů Azure Logic Apps – Místní funkce
Pipelines	– Kanály BizTalk Serveru – Součásti kanálu	– Pracovní postupy Azure Logic Apps (jako pipeliny) – Místní funkce
Směrování zprávy	-Messagebox - Propagace majetku - Filtry	- RabbitMQ Výměny
Připojení aplikace	- BizTalk Server standardní a vlastní adaptéry – Internetová informační služba (IIS) a Azure API Management (hybridní funkce)	– Konektory Azure Logic Apps
Křížové odkazy	xref_ * tabulky v databázi bizTalk Management (BizTalkMgmtDb)	– Místní funkce
Schémata (XSD)	– Schémata BizTalk Serveru – schémata XML, JSON a plochých souborů	– Azure Logic Apps (Standard) – Účet integrace Azure – Účet úložiště Azure
Maps	– BizTalk Mapper - Mapy XSLT – Azure API Management (hybridní funkce)	– Azure Logic Apps (Standard) – mapy XSLT, šablony Liquid – Účet integrace Azure (mapy XSLT, šablony Liquid) – Nástroj mapovač dat (rozšíření Azure Logic Apps Standard pro Visual Studio Code)
Obchodní pravidla	BizTalk Server Stroj pro obchodní pravidla	Stroj pravidel Azure Logic Apps
Monitorování obchodních aktivit	Monitorování obchodních aktivit BizTalk Serveru	Sledování obchodních procesů Azure
EDI	- Standardní funkce BizTalk Serveru - Strany, partneři, dohody, AS2, X12, EDIFACT	Azure Logic Apps a účet integrace Azure (partneři, smlouvy, AS2, X12, EDIFACT)
HL7, RosettaNet a SWIFT	Akcelerátory BizTalk Serveru pro HL7, RosettaNet a SWIFT	– Azure Logic Apps: Účet integrace Azure, HL7, MLLP, RosettaNet a konektory SWIFT
Tajné kódy	Jednotné přihlašování organizace (SSO)	– Azure Key Vault – SQL Server – Konfigurace aplikace
Zabezpečení a zásady správného řízení	– Jednotné přihlašování organizace (SSO) - partnerské aplikace SSO – Active Directory - Podpisové certifikáty – Ověřování zabezpečení služby IIS - Zabezpečení sítě	– Microsoft Entra ID – Zabezpečení sítě Azure – Řízení přístupu na základě role v Azure (Azure RBAC) - Nároky, tokeny – Zásady sdíleného přístupu
Konfigurace dat	– Konfigurační soubory – Konfigurace aplikace podnikového jednotného přihlašování – Vlastní součásti mezipaměti – Vlastní databáze – Registr Systému Windows	– Azure Key Vault – konfigurace Aplikace Azure – Azure Cosmos DB – Mapy konfigurace Kubernetes – Konfigurace Azure Logic Apps (Standard) – SQL Server – Vlastní ukládání do mezipaměti – Vlastní databáze
Nasazení	– Soubor vazby BizTalk Serveru	– Azure Pipelines – Skripty Bicep - Terraform
Sledování	– Možnosti sledování BizTalk Serveru (přijímací porty, odesílací porty, kanály, orchestrace) – Sledování služby IIS – Integrovaná analýza služby Azure API Management (hybridní funkce)	– Historie spuštění pracovního postupu Azure Logic Apps a sledované vlastnosti – Účet služby Azure Storage – Azure Monitor (Application Insights)
Sledování	– Konzola pro správu BizTalk – BizTalk Health Monitor	OpenTelemetry
Operace	– Konzola pro správu BizTalk Serveru – Azure Pipelines – MSI, PowerShell – BizTalk Deployment Framework	– Azure Portal - OpenTelemetry – Šablony Azure Resource Manageru – Azure Pipelines – PowerShell, CLI, Bicep

Pokud chcete mít přehled o nejnovějších investicích, přihlaste se k odběru integrace na blogu Azure – Tech Community.

Další kroky

Dozvěděli jste se více o tom, jak Azure Logic Apps porovnává s BizTalk Serverem. Dále si projděte navrhované přístupy a prostředky, aspekty plánování a osvědčené postupy pro vaši migraci.

Přístupy k migraci pro BizTalk Server do Azure Logic Apps