Migratie van Biztalk 2002 naar Biztalk 2006 - PART 1

Inleiding

In de afgelopen maanden heb ik een migratieproject van Biztalk 2002 naar Biztalk 2006 uitgevoerd. In dit eerste deel van het artikel wil ik jullie deelgenoot maken van mijn bevindingen. Biztalk 2006 is vorig jaar gelijk met Visual Studio 2005 en SQL Server 2005 groots gelanceerd. Sinds begin dit jaar is de versie voor iedereen beschikbaar. De klant waar ik het migratieproject heb uitgevoerd, maakt nu gebruik van Biztalk 2002 voor een groot aantal van hun processen.

Voor degenen die de Biztalk 2000/2002 versie niet kennen… Microsoft zag het bouwen en beheren van processen met behulp van Biztalk toen nog als een taak voor de beheerders. Alle gereedschappen en dergelijke gingen ook van dat standpunt uit.

Verder dateren deze versies van Biztalk nog uit de pre-dotnet periode. Communicatie met custom componenten liepen bijna allemaal via Com+ objecten. Daarvoor wordt vaak gebruik gemaakt van Visual Basic 6.0.

Met Biztalk 2004 en 2006 verschoven de ideeën, dat Biztalk een zuiver serverproduct is en dus iets voor beheerders. Het besef groeide, dat het bouwen van processen (schedules) toch een ontwikkelactiviteit was. Door deze verschillen is de migratie van Biztalk 2002 naar Biztalk 2006 er niet eentje die je op de automatische piloot kunt uitvoeren.

Nog een paar van de verschillen zijn:

Oké, een aantal van deze verbeteringen is al aanwezig in Biztalk 2004, maar in Biztalk 2006 zijn ze verder uitgebreid en de meeste editors zijn verbeterd. Zoals al genoemd zitten de grootste verschillende in de beheer- en deployment tools.

Het grootste verschil tussen Biztalk 2004 en Biztalk 2006 is de versie van het .Net framework. Hoewel Biztalk 2006 wel gebruik maakt van SQL Server 2005, worden niet alle nieuwe features van deze database gebruikt.

Ontwikkeling

Aangezien ik geen fysieke ontwikkelserver tot mijn beschikking heb, heb ik er voor gekozen om een virtual machine te maken met daarin een Biztalk 2006 installatie. Om deze Biztalk installatie te testen heb ik een simpele orchestration (calculator) gemaakt.

Met deze calculator kon ik gelijk kennis maken met de nieuwe beheer- en deployment tools. Er is nu een tool, de Biztalk 2006 Administration Console, die duidelijk alle zaken voor een Biztalk applicatie in zijn geheel laat zien. Had je bij Biztalk 2004 nog een Visual Studio omgeving nodig om enkele deployment zaken uit te voeren, in Biztalk 2006 is dat zeker niet meer nodig. Maar goed ook, want een development tool op een productieserver maakt de systeembeheerder of de beheerorganisatie niet gelukkig.

Fig. 1: Biztalk 2006 Administration Console

Een development tool op een productieserver maakt de systeembeheerder niet gelukkig

Als Biztalk 2004 ontwikkelaar heb je een Windows 2003 Server met een Visual Studio 2003 omgeving nodig, want ook voor het ontwikkelen was het een zuiver serverproduct. Nu met Biztalk 2006 kun je voor het ontwikkelen ook gebruik maken van een Windows XP machine. Dat is een hele vooruitgang en verbetering. In de praktijk werd er bij Biztalk 2004 ontwikkelingen gekozen voor virtuele omgevingen zoals Microsoft Virtual Server of Virtual Server van VMware. Het nadeel van deze omgevingen is, dat er extra beheersactiviteiten (updates, backups, etc) bij komen.

Terug naar het migratieproject. Aangezien de software bij de klant wel besteld maar nog niet geleverd was, begon ik het project met mijn virtual machine. Met de virtual machine kon ik echter niet connecten naar de Biztalk database van de ontwikkelserver bij de klant. Daarbij liep ik tegen allerlei security instellingen aan. Normaal gesproken zou Biztalk kunnen connecten naar de database van de Biztalk 2002 server en de benodigde gegevens converteren. Ook zal het migratie project dan proberen om de poorten en channels te converteren. Wat het resultaat daarvan is, kan ik je helaas niet vertellen.

Document Designer

Omdat het migreren niet helemaal automatisch kon gaan, moest ik een heleboel dingen handmatig doen. Ik had dit risico vooraf ingecalculeerd, en gelukkig viel de benodigde tijd uiteindelijk geweldig mee. Voor de migratie van de message definities (documenten) heb ik een simpele maar doeltreffende manier gebruikt. Op de Biztalk 2002 server heb ik van de message definities allemaal XML-instanties gegenereerd. Op de Biztalk 2006 server heb ik aan de hand van deze XML-instanties nieuwe XSD’s laten genereren.

Daarvoor heeft Biztalk 2004/2006 een handige tool. Binnen je Biztalk project in Visual Studio klik je op de rechtermuisknop en kies dan voor Add, dan kun je bij “Add Generated Items” kiezen voor Generate Schemas. Vervolgens moet je aangeven wat de basis is voor de generatie en je kunt onder andere kiezen voor “Well Formed Xml”. (Als de documenttypes niet beschikbaar zijn, dan komen ze beschikbaar na het starten van een tweetal scripts. Deze scripts staan in \SDK\Utilities\Schema Generator en ze heten InstallDTD.vbs en InstallWFX.vbs.)

Fig. 2: Biztalk 2006 Add Generated Items

Wel moesten de relaties en de metadata (zoals namespaces etc) gecontroleerd en aangepast worden. Maar toch scheelde dit erg veel tijd. Het aanmaken van de message definities had ook op een andere manier gedaan kunnen worden, nl. bij het migreren van de mappings, maar daarover later meer.

Fig. 3: Biztalk 2002 Document Editor

Fig. 4: Biztalk 2006 Document Editor

Als je de XSD-editor van de Visual Studio omgeving niet prettig vindt, dan kun je ook switchen naar een XML-editor. Voor een aantal attributen, elementen, namespaces en dergelijke is dat handig, aangezien deze niet via de XSD-editor getoond worden. Doordat we de beschikking hebben over Visual Studio 2005, hebben we in de XML-editor ook Code completion.

Fig. 5: Open With…

Mapper

De migratie van de mappings was eigenlijk nog simpeler. Gewoon de extensie veranderen van .xml naar .btm. Daarna het bestand ‘includen’ in een Visual Studio Biztalk project en de mapping is gemigreerd. Met het migreren van de mapping files ontdekte ik, dat het genereren van de message definities ook anders kon. Op het moment dat je het gegenereerde mappings-file opent, zal de mapper de bron- en het doeldocument uit de mapping halen en apart opslaan. Ten slotte bevat de mapping ok de message definities.

Als er in de mapping gebruik wordt gemaakt van custom functoids, dan zal de migratie op zichzelf lukken. Wel zullen in de mappings koppelingen tussen velden waar een custom functoid gebruikt wordt, verdwenen zijn. De nieuwe mapper kan daar niets mee. In mijn migratieproject wordt ook gebruik gemaakt van een custom functoid. Helaas was ik de koppelingen kwijt; voor de kleine en simpele mappings was dat niet zo erg maar voor de complexe varianten wel.

Het maken van een functoid is redelijk eenvoudig, het deployen ervan is lastiger

Het maken van een functoid is redelijk eenvoudig, het deployen ervan is lastiger. In de SDK van Biztalk 2006 zit een voorbeeld project. Bij een full install wordt deze standaard mee geïnstalleerd. Verander de juiste namen en GUID’s, installeer de functoid volgens de procedure en je kunt gebruik maken van de functoid in de mappings.

Vreemd was dat ik bij het Googlen vond dat het ID van een functoid boven de 6000 moest liggen. In het voorbeeld project echter staat een ID van 3001. Deze range zou voor een interne functoid gelden.

De mapper in Biztalk 2006 is functionaliteit kwijt geraakt ten opzichte van de mapper in Biztalk 2002. Als je in de mapper van Biztalk 2002 een functoid selecteert, dan werden de bijbehorende elementen van doel- en bronbericht mee geselecteerd. De mapper van Biztalk 2006 doet dat nu niet meer. Dit maakt het erg lastig om te zien, waar de lijntjes heen lopen. Het selecteren van een lijntje in een ingewikkelde mapping is in ieder geval geen sinecure.

Fig. 6: Biztalk 2002 Mapper

Fig, 7: Biztalk 2006 Mapper

In de mapper is er tussen het bron- en het doeldocument een ruimte (een tabblad) om functoids te zetten. Zodra je de functoids erop zet, blijven ze op die plaats staan. Als je scrollt in het bron- of het doeldocument, dan behouden de functoids hun gefixeerde positie. Binnen het tabblad met de functoids kun je ook weer afzonderlijk scrollen. Als je met de muis naar de randen gaat en daarbij de lijntjes of andere objecten vermijdt, dan verschijnt er een grote pijl. Als je klikt, dan zal de inhoud in het tabblad gaan scrollen. Ook kun je meerdere tabbladen maken, zodat je functoids zou kunnen scheiden. Wel jammer, hier is weinig aan verbeterd en de functionaliteit van de mapper is sinds Biztalk 2002 nagenoeg gelijk.

Als er in de mappings gebruik wordt gemaakt van script functoids, dan zullen deze behandeld worden als VB.NET script. De meeste functies van VBscript bestaan wel, maar staan in een andere namespace en de functies moeten daarmee geprefixed worden. Ook moet de code stronger getyped worden en meer voldoen aan de VB.NET regels.

Wat ik een gemiste kans vind, zijn de script-functoids. In deze script-funtoids kun je nu kiezen voor verschillende soorten van script talen (VB.NET, C#, J#, XSLT, XSLT template, Assembly). Op het configuratiescherm van een script functoid is ruimte om de scriptcode in te voeren. Heel vervelend en erg jammer is, dat syntax coloring en code completion daar niet werken. Je zult dus een aparte Visual Studio moeten openen om je code te valideren.

Fig. 8: Script Functoid script keuzes

Orchestrations

Bij de orchestrations is een aantal zaken veranderd. Bij Biztalk 2002 wordt gebruik gemaakt van de Biztalk Orchestration Designer. Deze is gebaseerd op Visio, het tekenpakket van Microsoft. Bij het installeren van Biztalk 2000/2002 is Visio dan ook een van de prerequisites. De basis is een tekenpakket en hoewel Visio een heel krachtig tekenpakket is, mist het wel wat functionaliteit voor het maken van Biztalk orchestration / schedules.

In Biztalk 2004/2006 is de Orchestration designer geïntegreerd in de Visual Studio omgeving. De Visual Studio Orchestration designer is geen echt tekenpakket (onder water is het allemaal XML), maar het ziet er wel erg goed uit. Ook is de functionaliteit veel uitgebreider dan de Visio variant. Er zijn nu veel meer shapes (actions) mogelijk en aan een orchestration is meer in te stellen.

Fig. 9: Biztalk 2002 Orchestration Designer

Fig. 10: Biztalk 2006 Orchestration designer

Fig. 11: Biztalk 2002 Orchestration Toolbox

Fig. 12: Biztalk 2006 Orchestration Toolbox

De orchestration designer van Biztalk 2004 en Biztalk 2006 lijken erg op elkaar. Als je in Biztalk 2004 een grote orchestration had, dan was er geen mogelijkheid om in te zoomen. In nieuwe Biztalk 2006 orchestration designer kan wel gezoomd worden. Erg handig als je met grootte orchestrations te maken hebt.

Overige verschillen tussen Biztalk 2002 en Biztalk 2006 zijn:

Er zijn nog een paar wijzigingen. In Biztalk 2002 was het nog mogelijk om gebruik te maken van Xpath expressies op de poorten. Hiermee was het mogelijk om een poort zijn werk te laten doen op basis van een waarde in de XML-message. In Biztalk 2004/2006 geef je in de message definitie aan op welke velden je zou willen filteren. Dit heet dan het promoten van properties. Met deze promoted properties is het mogelijk om te filteren op de receive port/location.

Bij het migratieproject was er een eigen pipeline component voor Biztalk 2002 geschreven. Het principe van een pipeline is in Biztalk 2006 van betekenis veranderd. Een receive pipeline wordt nu gebruikt voor het decoden, disassemblen, valideren en het resolven van de aanleverende partij. Voor een send pipeline geldt het omgekeerde van de receive pipeline. Het onderstaande plaatje geeft de opsplitsing van de message artifacts van Biztalk 2002 en Biztalk 2004 aan.

Fig. 13: Verschillen in Message Artifacts

Op de send port kan een filter gezet worden, maar helaas is dit niet op de receive port of location (in Biztalk 2002 termen: een filter op het inbound document). Nu moet je in een orchestration filteren op een waarde binnen het document.

Tot zover het 1^e deel van mijn verslag over de conversie …
Deel 2 van de 2-delige reeks kunt u hier lezen.