Nieuwe Features in BizTalk 2006
Toen BizTalk 2004 verscheen was dat ten opzichte van zijn voorganger niets minder dan een aardverschuiving. Het leek nog het meeste op zo’n restauratieproject waarbij alleen die fotogenieke rococo-gevel blijft staan, maar de rest geheel volgens de eisen van de 21e eeuw opnieuw wordt opgetrokken.
Zo waren bij versie 2004 alleen de productnaam en het doel, het koppelen van divergente gegevensverzamelingen, nog gelijk gebleven. Maar van achterliggende functionele logica, de daaruit voortvloeiende architectuur tot en met de onderliggende technologie (.Net versus COM) waren compleet veranderd. Eigenlijk stond er een volledig nieuw product.
Plezierig gegeven was echter dat het nieuwe product zoveel logischer in elkaar stak. Hoewel de leercurve nog steeds erg steil was, was die wel dusdanig dat ook iemand als ik (met een beperkt technologisch intellect) zich Biztalk eigen kon maken.
Het leek wel alsof Microsoft voor het eerst was uitgegaan van de functie en niet van de techniek.
“really cool technology, man”
Het was nog steeds “really cool technology, man”, maar er was ook gekeken naar het dagelijkse nut. En dat pikt toch wat makkelijker aan. Met mij waren er velen, want waar de versies 2000 en 2002 een ietwat schimmig bestaan leidden in een bescheiden niche in Nerdland, daar deed de incarnatie 2004 ineens alle wenkbrauwen rijzen. En hoewel de eerste relativerende rebellen zich al hebben gemeld (BizTalk zou te groot, te log en te duur zijn voor de meeste bedrijven), lijkt er zowaar iets van een hype te ontstaan.
Een hype is als die mooie vrouw in wiens gezelschap je iets te vaak verkeert. Op een gegeven moment begin je toch oog te krijgen voor haar minder oogverblindende kanten, innerlijk zowel als uiterlijk. Zo was ook op BizTalk 2004 het nodige aan te merken. Op bijeenkomsten waar je andere Bizzies tegenkwam, hoorde je vaak dezelfde lamentaties, meestal gevolgd door een sardonische schouderophaal: “’t blijft toch Microsoft, nietwaar?”
Bij de monoliet uit Redmond is er de laatste jaren echter wel iets veranderd. Waar vroeger de gebruiker werd gezien als een onmondig schepsel, dat eigenlijk te dom was om de almachtige wijsheid van Gates c.s. volledig te doorgronden, Daar luistert men nu naar die gebruiker en neemt er zowaar nog iets van aan ook. Het resultaat van die ontwikkeling wordt duidelijk in BizTalk 2006. Het is geen revolutionair nieuwe aanpak van de materie (zoals zijn voorganger), maar een verzameling kleinere en grotere verbeteringen. Verbeteringen waar de gebruikers al die jaren eigenlijk al op gehoopt hadden, maar waarvan ze niet hadden durven bevroeden dat die smeekbedes ook verhoord zouden worden.
De verbeteringen kunnen in twee groepen worden verdeeld:
- die aan het ontwikkelgedeelte en
- die aan de installatie- en beheerkant (was die er dan, hoor ik de cynicus nu zeggen en daar heeft die cynicus een zeker punt).
Dit artikel is dan ook verdeeld in twee delen. Lees, waarde lezer, de kant waar Uw hart naar uitgaat. Dit artikel pretendeert niet een volledige opsomming te zijn van alle toevoegingen van de afgelopen twee jaar (daarover zal Microsoft zelf t.z.t. wel een uiterst complete en vooral gortdroog stuk proza leveren), maar eerder een (onvermijdelijk subjectieve) snelle kennismaking met die features waar we met zijn allen al die tijd op hebben zitten wachten.
Ontwikkeling
BizTalk ondersteunt nu ook SQL Server 2005, maar gebruikt geen van de nieuwe features, waarschijnlijk met het oog op de backwards compatibility met dat werkpaard van menig Microsoft Server product, SQL Server 2000. Minder vrijblijvend is het gebruik van het .Net framework versie 2.0, wat inhoudt dat Visual Studio 2005 als ontwikkelgereedschap vrijwel onontkoombaar is.
Intern is er verder eigenlijk niet veel schokkends bijgekomen, wat misschien verklaart, waarom Microsoft zelf nogal hoog opgeeft van het aantal adapters dat nu standaard wordt meegeleverd. Men heeft de iWays catalogus mogen plunderen en de meest in het oog springende zaken daar zijn de Oracle en PeopleSoft adapters. Maar ook de MQSeries, de WSS en uitgebreidere SMTP en POP3 adapters zijn eigenlijk net zo welkom.
Fig. 1: SMTP Adapter properties
Fig. 2: POP3 properties
Vooral de mogelijkheid om de layout van de body design time te definiëren - nu nog een complex C# klusje in een Expression Shape van een Orchestration - zou menig ontwikkelaar moeten aanspreken. De incoming POP3 adapter is helaas vooralsnog redelijk bot: het is alles of niets en verder niet zeuren. Ruimte voor verbeteringen is er dus nog genoeg.
Een nadelige bijkomstigheid van deze rijkelijk gevulde doos is, dat de licentiekosten waarschijnlijk (harde cijfers zijn er nog niet) omhoog zullen gaan. En dat zal de hierboven gememoreerde cynici zeker in de kaart spelen: als je maar een beperkt aantal systemen aan elkaar wilt koppelen, dan doe je dat goedkoper met een maatwerk (web) service.
BizTalk heeft vooralsnog dus weinig te zoeken bij het MKB
Iets waar de meeste Bizzies zich nog wel eens aan gestoord zullen hebben, was de gebrekkige foutafhandeling. Natuurlijk: binnen een Orchestration kon je het zo gek niet bedenken, maar daarbuiten was er alleen het event log en eventueel de HAT, alwaar je de suspended message wel mocht aanschouwen, maar niet kon doorsturen en laat staan resubmitten. Helaas was er maar één plek waar je de messages op structurele en namespace-lijke aberraties aan de tand kon voelen en dat was de Pipeline. En waar stond die Pipeline? Heel juist: buiten die Orchestration, in de suspension zone. In versie 2006 is daar eindelijk wat aan gedaan. Ten eerste kun je de error queue uitvragen, gewoon met een receive port:
Fig. 3: Filter Expression voor Errors
Daarnaast kun je nu vanuit de Orchestration (in een Expression Shape) een Pipeline aanroepen, zodat validatie van een message t.o.v. een schema nu geheel zonder zelfgebroddelde C# hulpstukken kan worden uitgevoerd.
Ook de overige aanpassingen vallen onder de optie “daar hebben we al een tijdje op zitten wachten”, zonder dat men daarmee nu een nieuwe Rubicon overtrekt. Voor al die mensen die met grotere Orchestrations al snel het overzicht kwijtraakten: er is nu een zoom-functie, waarbij je de gehele Orchestration in een window kunt tonen. Dat daarbij de leesbaarheid van het geheel niet bepaald beter wordt, laten we maar even buiten beschouwing. Wat we echter wel altijd al hadden willen hebben, maar waar Microsoft kennelijk geen tijd voor heeft willen vrijmaken, is een design time Orchestration debugger. Wil je weten wat een Orchestration nu echt doet, dan zul je eerst een Assembly moeten laten crashen; alleen dan staat er een Orchestration debugger in de HAT tot je beschikking.
Een aardig extraatje is dat een groot aantal schermen nu kunnen worden geresized. Vooral bij de Expression Shapes, waar een wat forsere hoeveelheid code al snel niet meer te overzien was, is deze mogelijkheid meer dan welkom. Nog een dergelijke, leuke extra is de mogelijkheid om bij Receive en Send Ports het bestandspad via een browse knop te bepalen.
Voor diegenen die veel met flat files werken, moet de Flat File Wizard een welkome aanvulling zijn. Waar je in 2004 nog heel goed moest kunnen tellen, daar doet nu BizTalk het tel-, hak- en benoemwerk zelf, inclusief tags en multi-line regels. Alleen bij echt complexe Flat File structuren wordt er van de argeloze ontwikkelaar nog inzicht en creativiteit gevraagd.
Fig. 4: Flat File Schema Wizard
Verder is er nu de optie om ook bij gewone FILE-messages een volgorde van aanbieding af te dwingen. Dit was tot dusver alleen mogelijk bij MQ.
Helemaal niets is er veranderd bij de Human Workflow Services. Maak een dergelijk BizTalk project aan en je wordt nog steeds getrakteerd op een Orchestration waar je subiet angina pectoris van zult krijgen. Het geheel is nog steeds een voorname kandidaat voor de CA trofee voor slechtst gedocumenteerde software module ooit. Gelukkig spreekt die oorverdovende ontwikkelstilte op dit terrein boekdelen. Microsoft lijkt het te hebben opgegeven. De Human Workflow Services zitten er alleen nog maar in voor de upwards compatibility, maar hun volgende incarnatie zal vrijwel zeker de (nog te ontwikkelen) Windows Workflow Services zijn. Hoorde ik daar een zucht van opluchting of is er gewoon niemand die ooit echt wat met Human Workflow Services gedaan heeft?
Beheer
Voor de installatie en de configuratie van BizTalk bestond tot nu toe eigenlijk maar één manier. Als het de eerste keer niet ging, wis alles en installeer bij voorkeur maar weer een volledige omgeving (vanaf het besturingssysteem) en probeer opnieuw. Kortom: het recept voor een compleet gestresste beheerder nog voordat je zelfs maar bent begonnen te BizTalken. Ook hier heeft Microsoft iets aan proberen te doen met het BizTalk Server Configuration console:
Fig. 5: Configuration-scherm
Als Default installeert BizTalk alleen die delen die het daadwerkelijk kan installeren. De overige delen kunnen op een later tijdstip worden toegevoegd of zelfs weer worden verwijderd. Zo moet het “niet hebben van de laatste patches” niet meer leiden tot vertragingen van enkele dagen.
Deployment is ook niet echt eenvoudig geweest. Natuurlijk, het ging wel, maar gemakkelijk was anders, vooral bij herhaaldelijk deployen en undeployen. Dat gebeurt tijdens ontwikkeling natuurlijk nogal eens, dus er bleef er wel eens wat in de GAC “hangen” waardoor nieuwe aanpassingen niet leken te worden doorgevoerd. Met een enkele klik kan nu worden ge-unenlist en ge-undeployed, waarbij er minder afhankelijkheid is van gerefereerde builds. Althans, dat belooft Microsoft.
We zullen het zien in de praktijk
Wat binnen dit kader wel mooi is, is het concept van de Virtual Application. Tot dusver wilde een BizTalk omgeving nog maar al te vaak ontaarden in een kluwe van onderling gerelateerde assemblies. Daarbij had het hele deploy/undeploy circus nog het meeste weg van het eten van spaghetti, er bleven maar afhankelijkheden voorkomen voordat je kon undeployen.
Binnen een Virtual Application geef je zelf aan welke onderdelen van welke assemblies jouws inziens tot een enkele applicatie behoren. Bij het deploy/undeploy tracht BizTalk daar dan zoveel mogelijk rekening mee te houden door parallel c.q. complementair benodigde (un)deploys zoveel mogelijk automatisch uit te voeren.
Een aardige aanvulling bij het dagelijkse reilen en zeilen van BizTalk is de automatische Host Throttling. Host Throttling laat de Host niet meer “stikken” bij grote hoeveelheden messages. Het systeem herkent wanneer er meer data aankomt dan hem lief is en zet dan automatisch de receive port even uit, zodat hij de tijd heeft om gegevens te verwerken. Het is als eindgebruiker mogelijk om de grenswaarden die hiervoor worden gehanteerd, aan te passen. Het nut daarvan zie ik overigens niet echt in: het systeem weet altijd beter wanneer het wordt overvoerd dan de beheerder.
Een laatste, belangrijke nieuwe troef is de sterk uitgebreide Biztalk management Console, waarin nu ook Port properties kunnen worden gewijzigd. We hoeven dus niet langer elke keer de binding files te installeren, als we een port willen wijzigen. Wat wel jammer is, is dat die binding files nog steeds in slechts twee smaken te verkrijgen zijn: alles of alleen de ports die (via Pipeline of Mapping) aan een bepaalde assembly kunnen worden gekoppeld. Vooral bij drukke omgevingen levert dit een enorme hoeveelheid ruis in de building files op, die er alleen met ouderwets handwerk (Notepad) weer uit te hacken zijn.
Conclusie
De introductie van BizTalk 2006 zal geen storm veroorzaken, zoals destijds met versie 2004. Ook zal de nog altijd steile leercurve er niet van afvlakken. Maar deze versie gaat de nodige sympathie opleveren, dat is overduidelijk. Het resultaat is de vele vragen en opmerkingen die de BizTalk gemeenschap wereldwijd de laatste twee jaar aan het adres van Microsoft heeft afgegeven. Je krijgt het idee, dat er is geluisterd naar je en dat geeft je weer het gevoel dat dit ook een beetje jouw baby is.
Blijmoedig op naar de volgende suspended message?