Migratie van Biztalk 2002 naar Biztalk 2006 - PART 2
Inleiding
Tijdens het migratieproject kwamen ook de verbeteringen aan het deployment-proces van Biztalk 2006 aan de orde. In dit tweede deel van het artikel wil ik jullie daar deelgenoot van maken.
Deployment
De deployment-tools zijn veel mooier in Biztalk 2006. Vanuit de Visual Studio omgeving kun je deployen. Als je in de properties van je project een Application aangeeft, dan worden alle bij zaken bij elkaar in een applicatie geplaatst.
Fig. 1: Application Name in de project settings
In de Biztalk Administration Console ziet dat er dan als volgt uit:
Fig. 2: Application Name in Administration Console
Mocht je bovenstaande niet gedaan hebben in je Visual Studio Biztalk project properties, dan kan dat altijd later nog. In de Biztalk Administrator Console kun je, met een rechtermuis klik op het Applications niveau, kiezen voor New->Application. Er verschijnt dan een scherm, waarop je de naam van de nieuwe application kunt invullen. De default application voor een Biztalk project is “Biztalk Application 1”. Het is mogelijk om alle artifacts te verplaatsen naar de nieuwe application. Als je bijvoorbeeld op een orchestration een rechtermuisklik doet, dan kun je uit het pop-up menu kiezen voor ‘Move to Application…”.
Fig. 3: Move to Application menu
Deze actie levert een scherm op waarin je de applicatie kunt aangeven waar de geselecteerde Biztalk artifacts naar toe moeten verhuizen.
Fig. 4: Destionation application
Aangezien een orchestration allerlei afhankelijkheden heeft met andere biztalk artifacts (objecten uit de applicatie, zoals schema’s, mappings, resources, etc.), worden deze automatisch mee verhuisd. Voor het feitelijke verhuizen wordt getoond welke artifacts verhuisd zullen gaan worden.
Fig. 5: Het feitelijke verplaatsen
Dat het verplaatsen gelukt is, is in de Biztalk Administration Console te zien.
Fig. 6: Moved orchestration to new application
In je orchestrations definieer je Send en Receive poorten met een binding ‘specify later’. Deze binding betekent, dat je zelf het aanmaken van de Send en Receive poorten voor je rekening neemt. Dit moet je dan doen, voordat je de orchestration probeert te enlisten en te starten. In de Biztalk Administration Console zie je bij de bindings van een orchestration wat je nog moet definiëren. Het is niet langer zoals in Biztalk 2004 waar je dat zelf moet onthouden of documenteren. Dit ontslaat je natuurlijk niet van de plicht tot documenteren!
Ook hoef je nu niet meer naar een andere tool of naar een andere positie binnen de Biztalk Management console om de zaken te definiëren, Je kunt bij de bindings van een orchestration gewoon klikken op de keuze ‘New receive port’ en het scherm om een receive port te definiëren verschijnt.
“Single Point of definition and ease of management”
Fig. 7: Het vullen van de bindings en het creëren van een nieuwe poort
Als je al deze poorten en bindings gedefinieerd hebt, dan is het handig om deze ergens op te slaan. Daartoe biedt de Biztalk Administration Console de mogelijkheid deze bindings te exporteren naar een bestand.
Fig. 8: Het exporteren van de bindings
Fig. 9: Export Bindings scherm
Zoals je in het figuur 8 al ziet, kun je deze bindings ook weer importeren. Handig bijvoorbeeld als je de applicatie weggooit en het Biztalk project opnieuw deployt. Tijdens het deployen met een MSI is dit ook uitermate handig. Hier kom ik later op terug.
HAT / Biztalk Administration Console
Als je een Biztalk application gedeployed hebt, dan kun je de berichten volgen. Dit kon al met HAT (Health And Tracking application). Dit was met Biztalk 2004 (gecombineerd met de event log) een van de weinige plekken om het proces te controleren en in de gaten te houden. Van een bericht kun je dan de bijbehorende orchestration zien en de message flow bekijken.
Fig. 10: HAT tool
In Biztalk 2006 is een deel van de functionaliteit van HAT verplaatst naar de Biztalk Administration Console. Met de Biztalk Administration Console applicatie heb je nu toegang tot al deze informatie en meer.
Fig. 11: Hub view
Op het plaatje zie je een tweede tabblad staan met de welluidende naam ‘New Query’. Dit geeft de mogelijkheid om een overzicht te krijgen van:
- All Service Instances
- Runnig Service Instances
- Suspended Service Instances
- Messages
- Subscriptions
Fig. 12: Query mogelijkheid
Fig. 13: Result Query
Als je dan het resultaat hebt gekregen en je doet een rechtermuisklik op de resultaten, dan krijg je een popup menu (bijna gelijk aan in de HAT van Biztalk 2004). Je kunt daar kiezen voor:
- Service Details
- Message Flow
- Orchestration Debugger
- Show Messages
- Show Instance Subscriptions
- Terminate Instance
- Suspend Instance
Als er fouten of problemen zijn, dan zie je deze hier staan. Het is min of meer dezelfde foutmelding als in het event log. De informatie hier is uitgebreider en heeft meer koppelingen met andere delen voor nog meer informatie.
Fig. 14: Het popup menu
Via de HAT en de Biztalk Administration Console kun je ook toegang krijgen tot de Orchestration Debugger. Met de Orchestration Debugger kun je dan door de procesflow van een orchestration steppen:
- In de ‘find message view’ doe je een rechtermuisklik
- Je kiest voor de Orchestration Debugger
- Op een shape kun je dan eveneens een rechtermuisklik doen en kiezen voor ‘Set breakpoint on Class’ of F9
- Uit het menu Debug kies je dan voor ‘Attach’
Stappen 1 tot en met 3 moet je doen voordat je de orchestration in gang zet. Vervolgens start je de orchestration; in mijn testgeval zet ik een message in de receive location. Daarna doe je stappen 1 en 2 gevolgd door stap 4. Je komt dan in de debugger.
Fig. 15: Debuggen in de Orchestration debugger.
Tijdens deze sessie kun je dan kijken naar de verschillende standen van je messages, etc. Erg handig. Tijdens mijn ontwikkeling voor het migratieproject ontdekte ik dat de mogelijkheid tot debuggen soms beperkt is. Het is dan niet mogelijk om een breakpoint te zetten. De reden hiervoor is me nog niet helemaal duidelijk, dat ga ik nog uitzoeken.
Deployment met een MSI
De deployment met behulp van een MSI (Microsoft Installer) is erg mooi en handig geworden in Biztalk 2006. Via Google kwam ik op de volgende site:
http://www.topxml.com/BizTalk-2006/re-21587_How-To-Package-and-Deploy-BizTalk-2006-Applications.aspx
Natuurlijk heb ik het uitgeprobeerd op mijn eigen situatie. Hieronder vind je toegepaste uitwerking van dit webartikel.
Voordat je hiermee aan de gang gaat, zul je aan een aantal dingen moeten voldoen.
- je zult een Application met zijn bijbehorende Biztalk artifacts moeten hebben;
- je zult alle receive poorten, receive locations, send poorten en dergelijke gedefinieerd moeten hebben;
- je zult de bindings geëxporteerd moeten hebben naar een bestand.
De export van de bindings levert een bestand op met alle instellingen van de receive poorten, receive location, send poorten en dergelijke. Als je deze export doet op een ontwikkelomgeving, dan kloppen de instellingen dus voor de ontwikkelomgeving. Voor de overige omgevingen uit een OTAP-proces (Ontwikkel, Test, Acceptatie en Productie) gelden heel vaak andere waarden voor de verschillende instellingen, b.v. voor server-namen of Message Queue-namen.
Het exportbestand met de bindings is een XML-bestand; dit kun je eenvoudig met een editor aanpassen. Een andere manier zou het aanpassen van de instellingen via de Biztalk Administrator Console kunnen zijn. Vervolgens kun je deze bindings exporteren naar een nieuw bindings-file.
Voor het voorbeeld heb ik een bindings-file gemaakt voor DEVELOPMENT en een voor PRODUCTION. Deze twee bestanden ga ik toevoegen als resource aan de application.
Fig. 16: Toevoegen van Resources aan een application
In het scherm om de resources toe te voegen kun je aangeven voor welke doelomgeving de Biztalk bindingsfile resource van toepassing is. De reden zal later duidelijk worden.
Fig. 17: Toevoegen resources scherm
Fig. 18: Overzicht aanwezige resources in de application
Vervolgens maken we een MSI van de geselecteerde applicatie. Hiervoor doen we wederom een rechtermuisklik op de gewenste applicatie. We kiezen voor Export->MSI File (zie figuur 8) en we geven een locatie aan voor de MSI. Met deze MSI gaan we naar de gewenste omgeving.
Voor demo-doeleinden heb ik de aanwezige applicatie via de Biztalk Administrator Console gestopt en verwijderd.
Bij de gewenste omgeving dubbelklikken we op de MSI. Een standaard Windows Installer wizard zal verschijnen. Na het standaard “Next -> Next -> Finish” procedure is de applicatie geïnstalleerd.
Als je de Biztalk Administrator Console op de achtergrond open hebt staan, zul je bemerkt hebben dat er ogenschijnlijk niets gebeurt. Maak je geen zorgen: met het starten van de MSI gebeurt er wel degelijk iets. De Windows Installer zet de assemblies van de applicatie in de programma-directory op de schijf en heeft de assemblies geregistreerd in de GAC (Global Assembly Cache).
Na de installatie van de MSI klik je met een rechtermuisklik in de Biztalk Administration Console op Applications niveau op de menukeuze “Import->MSI file” van het popup menu.
Fig. 19: Import MSI file.
Hierna verschijnt de Import MSI Wizard. Na twee keer de “Next”-button krijg je de mogelijkheid om te kiezen voor de “Application Target Enviroment” (doelomgeving). Hier komen de namen terug die we bij het toevoegen van de resources hebben opgegeven. Het maken van de keuze zorgt ervoor, dat de bindingsgegevens van het gekozen bindingsbestand gebruikt worden.
Fig. 20: Kiezen van de doel omgeving bij het importeren van de MSI file.
En voila! Klus geklaard! Zo handig was het nog nooit.
Conclusie
Tijdens deze migratieklus heb ik behoorlijk wat kennis kunnen opdoen van Biztalk 2006. Afgezet tegen de kennis die ik heb van de vorige versies, moet ik toegeven dat Microsoft met Biztalk 2006 erg goed op weg is. Ik heb nog wel een aantal wensen. mochten ze het mij willen vragen.
Voor volgend jaar staat natuurlijk de integratie met Windows Workflow en Windows Communication Foundation op de planning. Ik kijk er met vertrouwen naar uit.
Deel 1 van de 2-delige reeks kunt u hier lezen.