Administravia

Microsoft BizTalk 2004\2006 je poměrně komplexní produkt. Před tím, než začnete s návrhem a implementaci řešení v prostředí BizTalk, se vyplatí promyslet strukturu jednotlivých projektových částí celého řešení (solution). Klíčové otázky, které dle mých zkušeností definují hranice mezi jednotlivými projektovými částmi jsou tyto:

1. Je nutné udržovat nezávislé verze pro danou část projektu (komponentu)?
   • Je během životního cyklu aplikace pravděpodobný současný běh různých verzí dané komponenty?
2. Kdo bude komponentu vyvíjet (různé teamy, jeden team, externí firma  apod.)?
3. Jak často bude nutné danou komponentu měnit?
4. Závisí daná část projektu na důležité externí komponentě nad kterou nemáte plnou kontrolu? 

Malý dodatek k použité terminologii. "Projektovou částí" mám zde na mysli zejména .NET "assembly". Nesnažím se používat české výrazy za každou cenu ale míchání velkého množství anglických slov v českém textu nevypadá přiliž dobře. Nejsem odborníkem na český jazyk čí překladatel. To jste ale z mých příspěvků určitě poznali :-). Jednou z mých osobních motivací pro psaní tohoto veřejného zápisníku (blogu) je snaha o zlepšení svého písemného projevu. Přiznávám, že v oboru, kde dominuje angličtina, je hledání vhodných českých výrazů opravdovým oříškem.

Projektové řešení (Solution)

Ale zpět k podstatě věci. Při vývoji aplikací používajících Microsoft BizTalk se mi osvědčila následující struktura projektu:

Šablonu tohoto projektového zadání (solution) spolu ze základním kódem si můžete stáhnout zde. V následujících článcích budu tento kód podle daných témat dále doplňovat.

Instalační program produktu Microsoft BizTalk 2004\2006 rozšíří vývojové prostředí Visual Studio .NET o nové typy projektu. Tyto specifické BizTalk projekty se pak tváří jako jakýkoliv jiný .NET projekt. V rámci jedné "solution" je proto možné míchat BizTalk projekty spolu s "normálními" .NET projekty. Základní solution Concepts se skládá ze čtyř projektů typu "C# Class library" a ze dvou BizTalk projektů.

Kořenovým projektem je C# assembly Concepts.Config. Pro konfigurační proměnné mých projektů používám poměrně zhusta .config soubory. Concepts.Config assembly hostuje veškeré konfigurační ovladače (config handlers) a .NET třídy, které provádí deserializaci specifických konfiguračních sekcí do daného .NET typu. Typická implementace takového ovladače pro konfigurační sekci pak vypadá takto:

public class SettingsHandler : IConfigurationSectionHandler
{
    private XmlSerializer ser_ = new XmlSerializer(typeof(GlobalSettings));
    public object Create (object parent, object configContext, XmlNode section)
    {
        GlobalSettings settings = (GlobalSettings)
                                  ser_.Deserialize (new XmlNodeReader(section));
        return settings;
    }
}

Třída GlobalSettings je "oznámkována" pomocí XML atributů definujících XML serializaci. 

Poté, co  je provedena deserializace určité konfigurační sekce v .config souboru, lze k jednotlivým konfiguračním parametrům přistupovat přes pevně daný .NET typ.

Kód, který má na starost správu konfiguračních parametrů jsem zde umístil do samostatné assembly Concepts.Config. To proto, že tento kód je velmi statický ve srovnání s jinými částmi projektu. Běhové prostředí BizTalk požaduje umístění všech podpůrných (dependent) assembly do GAC. To také znamená, že všechny podpůrné assembly musí mít jedinečné jméno (strong name). Pokud používáte své vlastní konfigurační sekce v daném .config souboru, pak nejdříve musíte v daném .config souboru určit typ, který je odpovědný pro interpretaci dané konfigurační sekce:

<configSections>
    <section name="global" 
             type="Concepts.Config.GlobalHandler,Concepts.Config, 
                   Version=1.2.3.0, 
                   Culture=neutral, 
                   PublicKeyToken=07ccf21d1aa5a6dc" />
</configSections> 
                        

A zde vězí problém. Pokud je  GlobalHandler součástí assembly, která se mění často, nesmíte zapomenout při instalaci nové verze této assembly aktualizovat veškeré .config soubory, které odkazují na GlobalHandler. Bavíme se zde o integraci a tudíž o řešeních, které je často složeno z komponent, které jsou nainstalovány na několika různých serverech. Opomenout tyto detaily je velmi snadná záležitost a není nic zábavnějšího než ladění problému způsobených chybnou instalací a konfigurací.

Odbočka - Správa verzí (versioning)

Microsoft BizTalk 2004\2006 je postaven na infrastruktuře .NET a tedy podporuje souběžnou instalaci komponent různých verzí dané assembly. Je například možné provést deployment různých verzí téže choreografie procesu (orchestration) a v případě potřeby provést "rollback" nové verze na verzi předchozí. Představte si situaci, kdy máte několik aktivních instancí dané choreografie procesu a chcete provést deployment nové verze aniž byste tím ovlivnili existující instance. V běhovém prostředí BizTalk to lze provést velmi snadno. Nejdříve provedete instalaci nové verze choreografie procesu do běhového prostředí BizTalk. Samotná instalace nové verze choreografie procesu nemá žádný vedlejší efekt na existující instance této choreografie. Pak provedete přesměrování (binding) na novou verzi choreografie procesu. Existující instance dokončí svůj běh oproti původním verzím .NET komponent a nové instance dané choreografie budou spuštěny oproti novým verzím komponent. Staré instance vám postupně "vyhnijí" a uvolní místo novým.

Abyste dosáhli této nirvány, je třeba důsledně provádět správu verzí jednotlivých komponent. Každá assembly, kterou nainstalujete na server musí mít novou jedinečnou verzi. Vím, že je to známá věc. Píši o tom proto, že také vím, že správa verzi je často tou poslední věcí, na kterou je kladen extra důraz. Přepisování komponent téže verze v GAC je poměrně běžný jev. Pokud nezačnete BizTalk projekt s jasnou představou o správě verzí jednotlivých komponent, tak dříve nebo později narazíte na opravdové problémy. V podstatě nebudete schopni provádět údržbu vaší aplikace bez "downtime".

Správě verzí v prostředí BizTalk bych chtěl věnovat samostatný článek. Konkrétně, správa verzí schémat je téma, které stojí za samostatnou úvahu. V přiloženém projektu najdete příklad, jak lze provést správa verzí schématu v běhovém prostředí BizTalk. Je to příprava na budoucí článek.

Rozdělení Assemblies

Jak jsem zmínil výše, Concepts.Config je kořenovým projektem hostující kód pro správu konfiguračních parametrů. Nad touto assembly je postavená assembly Concepts.Base. Concepts.Base závisí na Concepts.Config. Concepts.Base obsahuje sdílené typy pro celé solution, jako například definice globálních rozhraní (interfaces), hierarchii tříd vyjímek, definici atributů apod. Tato assembly obsahuje především bázové typy, které se nemění často a mají globální rozsah (scope).

V tomto místě je možná více viditelný důvod pro oddělení Concepts.Config od Concepts.Base. Pokud by konfigurační ovladače (handlers) byly součástí Concepts.Base, tak by při přidání nové výjimky, například, došlo ke změně verze Concepts.Base. To by také znamenalo aktualizaci všech konfiguračních souborů a to rozhodně není intuitivní pro programátora, který chce pouze provést check-in nového typu výjimky.

Concepts.Task obsahuje definice typů Tasks, což jsou typy, které implementují rozhraní ITask:

public interface ITask
{
    object       Execute();
    IAsyncResult BeginInvoke();
    object       EndInvoke(IAsyncResult asyncResult);
    bool CompletedSynchronously
    {
        get;
    }
}

Tyto třídy implementují jednotlivé atomické operace, které se pak volají z choreografie procesu (orchestration). Tasks se jsou svým významem podobné Activity třídám z WWF. Přiložené solution zatím obsahuje jedinou třídu - třídu TaskToInjectException, která slouží k vyvolání výjimky pro testovací účely. Tato třída také existuje z důvodu mé přípravy na další články o zpracovávání vyjímek. Concepts.Task závisí na Context.Base a Context.Config.

Nyní zbývají dvě BizTalk assembly. Concepts.Schemas obsahuje pouze definice XSD schémat pro jednotlivé zprávy daného projektového řešení (solution). To je osvědčený postup, a to právě z důvodů správe verzí schémat.

Concept.Orchestration je projekt, který obsahuje kód pro choreografie procesů a mapy. Tento projekt závisí na projektech Conceps.Config, Concepts.Base, Concepts.Tasks a Concepts.Schemas. Všechny typy, které jsou definované v rámci projektového řešení (solution) jsou viditelné uvnitř Concept.Orchestration a integrace jednotlivých typů může začít. 

BizTalk projekt bohužel nemá možnost nastavit post-build operace. Proto používám v solution pomocné projekty s koncovkou .PostBuild. Tyto projekty existují pouze pro aktivaci post build operací a jsou tedy pomocnými projekty v daném solution.

Adresářová struktura

Na závěr pár malých poznámek k adresářové struktuře projektu. Po rozbalení zip souboru se vám na disku vytvoří adresářová struktura celého projektu. Adresář \bin slouží jako repositář pro veškeré binární soubory. A to jak pro binární soubory, které jsou sestaveny v rámci projektu, tak pro binární soubory externích komponent (typové knihovny COM komponent, interop DLL soubory apod.). Podadresáře v adresáři \loc slouží jako zdrojové\cílové adresy pro File Adapter. \loc\in je vstupní adresa, \loc\out je výstupní adresa a \loc\replay slouží jako žurnál minulých zpráv. File Adapter je velmi jednoduchý adapter co se týče nastavení a je proto ideální pro testování. Zde je ukázka nastavení "Receive Port" v nástroji BizTalk Explorer (View -> BizTalk Explorer na systému, kde máte nainstalován Microsoft BizTalk 2004 a VS.NET. V produktu Microsoft BizTalk 2006 se konfigurace "Receive Port" provádí pomocí BizTalk Server 2006 Administration Console):

Pole "Address" obsahuje místo na disku, kde je adapter připraven zpracovat nové zprávy. "Receive Handler" je Windows NT proces, který je zodpovědný za hostování adapteru. Adapter je implementován jako DLL knihovna a jako každá DLL knihovna i tato musí běžet uvnitř nějakého NT procesu. "Receive Pipeline" je typ vstupní fronty, přes kterou proteče nově přijatá zpráva. Zde je použitá "XMLReceive" vstupní fronta, což znamená, že zpráva musí odpovídat zaregistrovanému XML schématu a že také dojde k automatickému "property promotion" z těla přijatého XML dokumentu podle definice "Property Schématu".

V podadresáři Concepts.Schemas naleznete instance XML dokumentů pro schémata definovaná v assembly Concepts.Schemas.