Microsoft BizTalk Server 2004 – schémata, transformace a kanály

V tomto článku se dozvíte, jak se v BizTalku vytvářejí schémata zpráv, jak provádět jednoduché i složitější transformace mezi různými schématy a jak nastavovat vstupní a výstupní kanály. Všechny tyto úkoly jsou řešeny vizuálními návrháři v prostředí VS.NET.

Schema Designer

Aby se odesilatel a příjemce zprávy navzájem pochopili, musí používat nejen určitý komunikační kanál, ale také mluvit stejným jazykem. Jak jsme si již dříve naznačili, zprávy jsou zapsány pomocí XML, ten je však moc obecný a definuje pouze jakousi gramatiku jazyka. Ovšem aby komunikace byla smysluplná, je nutné také používat předem danou slovní zásobu. Každá aplikace, která je ochotná komunikovat se svým okolím, by měla mít své komunikační rozhraní důkladně zdokumentované a měla by přesně specifikovat strukturu dat, která přijímá z jiných aplikací, nebo která odesílá. K tomu dříve sloužila definice typu dokumentu (DTD), dnes se používá XSD (XML Schema Definition). Schéma popisuje, jak mají být v XML dokumentu uspořádány elementy a atributy, jaké mohou být jejich hodnoty a podobně.

V BizTalku musí každá zpráva odpovídat nějakému schématu, které je možné buď odněkud načíst, nechat vygenerovat podle vzorového XML dokumentu (obvykle je pak nutné jej ještě poupravit), nebo je vytvořit přímo v prostředí Visual Studia .NET. To již obsahuje vestavěný vizuální XSD návrhář. Jak se s ním pracuje, to si lze představit již na základě letmého pohledu na následující obrázek.

Způsob práce s tímto návrhářem odpovídá spíše návrhu relační databáze, tedy jako bychom vytvářeli tabulky a jejich sloupce a spojovali je relacemi. Tento princip odpovídá koncepci DataSetů, které můžeme XML dokumenty plnit. Ovšem BizTalk s DataSety nepracuje, a proto obsahuje svůj vlastní návrhář, který je pro jeho potřeby poněkud přehlednější a účelnější a navíc do schématu ukládá také informace, které v XSD stardardu nejsou definovány, avšak pro BizTalk mají svůj specifický význam. Jsou ovšem samozřejmě umístěny ve vlastním jmenném prostoru, takže aplikace, které je neznají, je budou prostě ignorovat. Opět následuje ilustrační obrázek, na kterém je ukázka XSD schématu shodného s předchozím příkladem.

BizTalk – Schema Designer (plná velikost, cca 10 kB)

BizTalk Mapper

Velmi často potřebujeme změnit strukturu zprávy, tedy vlastně přemapovat jedno schéma na jiné schéma. Někdy se také může hodit spojit dvě či více zpráv do jedné, nebo naopak rozdělit jednu zprávu do několika. Přitom nemusí jít o jednoduché přejmenování elementů a atributů, nýbrž může být nutné vykonat nad daty nějaké komplikovanější operace. Všechny tyto úkoly řeší BizTalk mapper. Je to jakási mocnější obdoba XML transformací (XSLT). Pojďme se nejdříve podívat, jak tento vizuální nástroj vypadá, jistě budete souhlasit, že práce s ním je opět velmi intuitivní.

Na levé straně je zobrazeno schéma zprávy, která do procesu vstupuje, vpravo je schéma výsledné zprávy a uprostřed je mapovací (transformační) logika. Elementy či atributy, jejichž obsah chceme na výstup jednoduše překopírovat bez jakýchkoli úprav, stačí napojit na související prvek pouhým přetažením myší. Prvky se propojí černou linkou, kterých je na našem obrázku celá řada. Pokud chceme některému prvku nastavit konstantní hodnotu (nezávislou na vstupující zprávě), klikneme na něj a hodnotu nastavíme v okně vlastností objektu (Properties, na obrázku není vidět).

A jakým způsobem vzniká nějaká složitější transformační logika? Pomocí takzvaných functoidů, což je vizuální reprezentace nějakého elementárního logického prvku, který může mít několik vstupních parametrů a jeden výstupní. Každý parametr má určen datový typ, který zpracovává, a pokud datový typ neodpovídá, pokusí se BizTalk o jeho konverzi. Do každého functoidu mohou data vstupovat z vybraného prvku ve vstupní zprávě, nebo z výstupu jiného functoidu, nebo mohou být také nastavena na konstantní hodnotu. V našem ukázkovém příkladu je použit jediný typ functoidu, nazývaný Looping, sloužící k opakování vstupního prvku na výstup. Díky němu se ve výstupní zprávě vygeneruje element Gen._Journal_Line vygeneruje tolikrát, kolikrát se vyskytuje element UCTPODKLAD ve vstupní zprávě.

Functoidů existuje poměrně velké množství, jak ukazuje následující pohled na ToolBox BizTalk mapperu, kde jsou functoidy zařazeny do několika skupin. Pokud by nám zabudované functoidy nestačily a potřebovali bychom nějakou velmi specifickou logiku, můžeme si ji sami naprogramovat a vyvolat prostřednictvím functoidu Scripting.

Podívejme se na trochu komplikovanější ukázku využití functoidů:

Ve vstupní zprávě je v elementu Bank_Account_No. číslo bankovního účtu ve složeném tvaru, tedy dohromady s kódem banky. My jej potřebujeme rozdělit na kód účtu a kód banky. Nejdříve functoidem String Find nalezneme lomítko, kterým jsou obě čísla oddělena. Výsledkem je index (pořadí) znaku ve vstupním řetězci. K tomu pomocí functoidů Addition a Subtraction přičteme a odečteme jedničku, čímž získáme index posledního znaku kódu účtu a prvního znaku kódu banky. Tyto indexy využijeme jako vstupy do functoidů String Left a String Extract, které již ze vstupního pole vyřežou potřebné části.

Pipeline designer

Protože existují dva typy portů (vstupní a výstupní), rozlišujeme také dva typy kanálů (pipeline). Na obrázku níže je návrhář s otevřeným výstupním kanálem, vstupní kanál vypadá velice obdobně. Jak víme, kanály řeší celou řadu problémů při zpracovávání protékajících zpráv – testují validitu dokumentu, konvertují jeho formát (BizTalk navenek nepodporuje pouze XML, ale také další formáty), šifrují či dešifrují, komprimují či dekomprimují, ověřují totožnost odesilatele nebo naopak podepisují zprávu certifikátem uživatele a plní další obdobné úkoly. Každý elementární úkol je řešen příslušnou BizTalk komponentou, kterou můžeme umístit do příslušné etapy zpracování zprávy. Na našem obrázku jsou tři etapy, obvykle každá z nich může obsahovat několik komponent. Komponenty lze také konfigurovat, což znamená nastavovat jim vlastnosti – například pokud chceme zprávu validovat, je třeba vybrat schéma, podle kterého má validace probíhat.

Je to příliš snadné? Zdání klame!

Popsali jsme si vytváření orchestrací, schémat, mapování a kanálů. Připadá vám BizTalk Server 2004 jednoduchý? Pokud ano, asi vás zklamu, protože je to uvnitř velmi složitý a komplexní systém, a pokud mu nebudete důkladně rozumět, jistě narazíte na celou řadu záludných problémů. Lze říci, že je to vlastně blackbox – černá skříňka, do které není vidět a která uvnitř nějak funguje. Pokud se ale něco pokazí, lze zvenku často velmi těžko odhadnout, co je vlastně špatně. Jde ale pravděpodobně o jedinou špatnou vlastnost tohoto zajímavého aplikačního serveru.