eBizTalk - Berichten, Unterhalten, Weiterbilden

Wenn man es kurz und prägnant bräuchte, dann passt die Headline dieses Artikels recht gut als Zusammenfassung zur Mitte November stattgefundenen INTEGRATE Konferenz Deutschland in Berlin. Eine informative, gut organisierte Veranstaltung zum Thema Enterprise Integration im Microsoft Umfeld, die durch eine Schaltung in die USA definitiv nochmal an Attraktivität gewonnen hat.

Bei Microsoft in Berlin „Unter den Linden“ – in Sichtweite des Brandenburger Tores – organisierte die Quibiq GmbH als Gastgeber gemeinsam mit Microsoft die INTEGRATE Conference Deutschland in 2018. Die im Vorfeld bereitgestellte Agenda der ganz dem Thema Integration mit der Microsoft Integration Plattform verschriebenen Konferenz, passte zu 100% zum eBiz Portfolio und beinhaltete Themen rund um Enterprise Integration / Architecture.

Thematisch wurde der Fokus, neben den Neuerungen des BizTalk Server als Microsoft OnPremises Integrationsprodukt, vor allem auf die Integration Services der Azure Plattform gelegt:

· Logic Apps

· API Management

· Service Bus

· EventGrid/-Hub

Als Quintessenz lässt sich mitnehmen, dass Microsoft weiterhin auf den BizTalk-Server setzt, dieser aber mehr und mehr als eine Komponente in hybriden Integrationsszenarien aufgehen wird. Somit rücken die oben genannten Azure Integration Services immer mehr in den Mittelpunkt der Betrachtung. Mittels des Azure Angebots von OnPremises Data Gateway und Virtual Network Gateways lassen sich diese mit diversen OnPremises Services wunderbar kombinieren und entsprechend flexible Integrations-Szenarien aufbauen.

Als Randnotiz: In zwei unserer Kundenprojekte setzen wir oben genannte Technologien bereits ein, sowohl in der reinen Azure Cloud Lösung als auch in einem hybriden Ansatz mit dem OnPremises BizTalk Server als Herzstück der Integrationslösung. Dadurch konnten wir gut in 1:1-Pausengespräche mit den Integrations-Kollegen von der Quibiq einsteigen und hatten einen interessanten Austausch.

In Summe war die INTEGRATE eine gute Veranstaltung, die an der ein oder anderen Stelle thematisch noch etwas tiefer hätte gehen können, jedoch wären dies dann vermutlich bereits ein Experten-Talk gewesen, der sich nur schwer ohne Whiteboard und nur in kleineren Runden bewerkstelligen lässt.

Inspiriert von dieser Veranstaltung fiebern wir dem Besuch an der Integrate UK 2019 entgegen, quasi der „großen Schwester“ Veranstaltung. Diese findet vom 03.-05. Juni in London statt und im Mittelpunkt stehen – wer hätte es gedacht – die Integration Services der Azure Plattform.

https://www.biztalk360.com/integrate-2019/uk/

Natürlich freuen wir uns ebenso auf die nächste INTEGRATE hier in Deutschland und denken parallel auch bei der eBiz über ein Format zum Austausch zu Integrationsthemen nach. Hierzu dann aber an geeigneter Stelle mehr.

Stay Tuned!

Wer schon einmal mit Azure Logic Apps herumgespielt hat, weiß wie nützlich sie sein können. Wer weiß wie nützlich sie sein können, möchte sie auch im professionellen Rahmen einsetzen. Wer sie im professionellen Rahmen einsetzen möchte fragt sich irgendwann: Wie sieht das denn mit der Continuous Integration aus?

Unser Szenario

Beginnen wir mit folgendem Beispiel: Wir nehmen eine Azure Resource Group, welche ca. fünf Logic Apps enthält. Als nächstes hätten wir gerne den Quellcode von den Logic Apps in Azure um ihn in unser Git-Repository einzupflegen und dort zu verwalten.

ARM Templates erstellen

Dieser Schritt gestaltet sich allerdings etwas schwierig. Man kann sich z.B. in Azure das „Automation Script“ erzeugen lassen und herunterladen. Damit bekommt man die sogenannten ARM (Azure Resource Manager) Templates aller Ressourcen der ausgewählten Resource Group. Die Erzeugung eines einzelnen Logic App Templates ist aktuell scheinbar nicht möglich. Als nächstes stellt man fest, dass in den Templates die Subscription-Id des Azure Accounts mehrfach referenziert wird. Ohne Änderungen lässt sich das Deployment auf eine andere Azure Subscription mit einem solchen Template nicht bewerkstelligen. Abhilfe schafft hier zum Glück der LogicAppTemplateCreator. Diesen Schritt würde man sich sparen, wenn man die Logic App von Beginn an in Visual Studio entwickelt, da Visual Studio beim Erstellen einer Logic App auch das Template erstellt.

Einstellen in Git

Jetzt wo die ARM Templates für die einzelnen Logic Apps vorhanden sind, können sie in das Git-Repository eingepflegt werden. Als nächstes hätten wir dann ganz gerne die Möglichkeit das Deployment nach Belieben durchzuführen.

Logic Apps erstellen

Hierfür erstellen wir einzelne Projekte in Visual Studio für die Logic Apps. Als Projekttyp wird hier Azure Resource Group und im nächsten Schritt Logic App gewählt.

Die Solution enthält zwei JSON-Skripte: Eins für die Logic App und ein Weiteres für die Parameter. Diese können wir durch Templates des „LogicAppTemplateCreators“ ersetzen. Es bietet sich ebenfalls an, eine weitere „Parameter-Datei“, für andere Zielsysteme, wie die Produktion zu erstellen.

Nun kommen wir endlich zur eigentlichen Continuous Integration: Wir konfigurieren Azure DevOps.

Build und Release Pipeline in Azure DevOps anlegen

Hier setzen wir Azure Pipelines ein. Zuerst definieren wir eine neue Build Pipeline für unsere Solution, um sie bei einem Commit zu kompilieren. Zusätzlich sorgen wir dafür, dass die Build Artifacts auf dem Server abgelegt werden. So haben wir eine versionierte Ablage der Templates auf dem Build-Server.

Als nächstes erstellen wir eine Release Pipeline. Als Stage Template nehmen wir zu Beginn das leere Template. Als Artefakt wählen wir als Quelle die eben von uns erstellte Build Pipeline. Bei der Stage fügen wir nun einen neuen Task hinzu und wählen "Azure Resource Group Deployment". Dort können wir nun einstellen wohin bereitgestellt (“deployed”) werden soll. Weiterhin können wir die Templates für die Bereitstellung auswählen. Parameter Templates werden hier ebenfalls ausgewählt. Dies gibt uns die Möglichkeit z. B. ein Development Parameter Template zu wählen.

Wozu kann ich die Lösung nutzen?

Nun haben wir ein automatisiertes Deployment unserer LogicApps, sobald eine Änderung am Quellcode eingecheckt wurde. Es werden automatisch Build Artifacts erstellt und z.B. mit einer Development Parameter Konfiguration auf unsere Development Azure Subscription bereitgestellt. Dort können wir anschließend die Änderungen testen.

Für den Fall, dass uns dieser Stand gefällt, können wir eine weitere Release Pipeline erstellen. Diese wird manuell getriggert und dabei können wir das Artefakt wählen welches bereitgestellt werden soll. Wir können also gezielt ein funktionierendes Artefakt auswählen und dieses in die Produktionsumgebung bereitstellen.

Fazit

Wir haben nun unsere Logic Apps in einem Git-Repository verwaltet und erstellen automatisch Build-Artefakte, wenn sich etwas geändert hat. Zusätzlich werden die Apps bei Änderung automatisch auf einer Test-Umgebung bereitgestellt. Und schließlich haben wir die Möglichkeit eine bestimmte Version manuell in der Produktionsumgebung bereitzustellen.

Die eBiz Consulting GmbH (kurz eBiz) ist Microsoft Partner mit den Schwerpunkten Integration, Automation und Kollaboration. In meiner Zeit als dualer Student bei der eBiz sollte sich in der letzten Phase meines Studiums natürlich auch meine Bachelorarbeit um diese Themen drehen. Ich hatte mir zum Ziel gesetzt, alle Bereiche in einem praktischen Anwendungsfall zu verheiraten und als Bachelorthesis zu dokumentieren. Dabei kommt der Anlass (häufig auch Need) aus dem Bereich Kollaboration. Der Kern der Software, BizTalk, kommt aus dem Bereich Integration. Und Automation ist schließlich der Effekt, den die Software erzielen soll.

Kollaboration im Microsoft-Umfeld bedeutet, dass das Ökosystem um Office 365 zu den täglichen Arbeitsmitteln in der Firma gehört. Daher gehört es zum Aufnahmeprozess eines neuen Mitarbeiters in der Firma, dass der Mitarbeiter eine O365-Lizenz bekommt und in die Domäne der eBiz aufgenommen wird, sodass er (oder sie) in Exchange, SharePoint etc. aufgenommen werden kann.

Nun ist es ein lang gehegter Wunsch des einzigen Administrators in der Firma, dass neue Mitarbeiter nicht mehr manuell angelegt werden müssen, sondern dass die dazu nötigen Schritte automatisch erfolgen. Das hat weniger etwas mit der extremen Mitarbeiter-Fluktuation in der Firma zu tun, als vielmehr damit, dass manuelle Prozesse generell anfällig für Fehler sind. So möchte man sicherstellen, dass ein neuer Mitarbeiter vom ersten Arbeitstag an Zugriff auf seine Arbeitsmittel hat, auch wenn der Administrator durch Dinge wie Urlaub, Krankheit oder Kaffee in der Tastatur verhindert ist.

Das Dokument am Ende des Artikels ist nicht die Bachelorarbeit selbst, sondern viel mehr eine überarbeitete Version mit Fokus auf die praktische Umsetzung der Lösung.

Topics Covered

• Erweiterung von Dynamics 365 CRM
• PowerShell @ WCF – Verwendung der System.Management.Automation Library zur Kommunikation mit Azure
• BizTalk Server Development
• Erstellung und Konfiguration einer Custom Receive Pipeline für die Verarbeitung von JSONs
• Porperty Promotion
• Entwicklung einer WCF Custom Behavior zur Implementierung von OAuth 2.0

Das Dokument steht hier zum Download bereit

Auf der Suche nach Weiterbildungsmöglichkeiten im Netz bin ich auf das PM Forum aufmerksam geworden. Ein Event speziell für Projektmanager? Das hat mich neugierig gemacht und ich habe mich mit der Veranstaltung auseinandergesetzt. Schnell war klar: Das kann für die Projektmanager in unserer Firma interessant sein.

Kurz zum PM Forum: Es ist das größte Projektmanager-Event Deutschlands und nach eigener Aussage “Der führende Fachkongress für Projektmanagement in Europa” mit ungefähr 1000 Teilnehmern und findet einmal jährlich in Nürnberg statt. Versprochen werden Trends, Innovation, Inspiration und Vernetzung innerhalb der deutschen PM-Community.

Tag 1, 23.10.2018:

Nun war es soweit. Das Event stand vor der Türe. Von der eBiz waren der Projektmanager-Nachwuchs, Hieronymus und ich, dabei. Voller Motivation ging es also nach Nürnberg. Um 09:00 Uhr sollte es los gehen. Zuvor trafen wir uns aber zum Frühstück und stellten einen Plan für den Tag auf. Für uns standen folgende Fragen im Vordergrund: Wie möchten wir uns in der Projektwelt weiterentwickeln, welche Zertifizierung macht für uns Sinn? Dementsprechend wählten wir Vorträge und Workshops aus.

Dort angekommen waren wir von der Größe des Events beeindruckt. Zuerst liefen wir über das Event, um uns zurecht zu finden, was auch ziemlich schnell gelang. Die Vorträge konnten also starten! Da Hieronymus und ich verschiedene Interessensgebiete haben, teilten wir uns auf, um das bestmögliche für uns aus dem Event herauszuholen.

Mein erster besuchter Vortrag trug den Titel “90 Day´s Project”. Ein sehr spannendes Thema, wenn es darum geht klassische Projekte zu verkürzen und Agilität zu schaffen. Generell wurde auf diesem Forum das Thema agiles und auch hybrides Projektmanagement in den Vordergrund gebracht.

Es war sehr interessant zu sehen, dass viele klassische Projektmethoden in der Erarbeitungsphase einer agil angepassten Zertifizierung (IPMA Agile) sind, oder diese schon auf dem Markt haben (PRINCE 2 Agile).

In einem anderen erwähnenswerten Workshop wurde in 45 Minuten versucht Scrum spielerisch und vereinfacht darzustellen. Es gab einen groben Überblick über die Rollen des Product Owners, Scrum Masters und der Teammitglieder. Danach wurden Rollen und die zugehörigen Aufgaben verteilt. Jeder Gruppe wurde ein Stapel Aufgabenkarten vom Product Owner vorgelesen und die Teammitglieder inkl. Scrum Master mussten diese innerhalb von 5 Minuten nach ihrer Schwierigkeit bewerten. Nachdem alle Karten bewertet waren, hatte jedes Teammitglied Zeit, eine Prognose zu geben, wie viele und vor allem was für Karten (z.B. 10 Papierhüte bauen, 40 Zahlen addieren etc.) innerhalb von 10 Minuten geschafft werden können. Schon ging es darum die Aufgaben zu erledigen und sich gegenseitig auszuhelfen, wenn die eigenen Aufgaben schon vor Ablauf der Zeit erledigt waren. Hier wurden die Rollen von Scrum Master und Product Owner hervorgehoben: der Scrum Master konnte und durfte bei den Aufgaben helfen, der Product Owner nur beobachten, nicht aktiv mitarbeiten. Dieser Workshop brachte die Rollen spielerisch gut rüber und man konnte einen ersten Eindruck erhaschen.

Am ersten Tag war eine Abendveranstaltung geplant, die mit der „Blauen Stunde“ eingeleitet wurde. Die Blaue Stunde, die in Wahrheit zwei Stunden betrug, war als eine Art Einstimmung auf die Abendveranstaltung gedacht. An vielen Messeständen wurde Gimmicks angeboten, wie z.B. eine Cocktailbar (mit super leckeren Cocktails ), Fußballspielen gegen einen Roboter, eine Fotobox, verschiedene VR-Szenarien und noch vieles mehr.

Nach dieser Blauen Stunde fing dann die eigentliche Abendveranstaltung an. Es gab leckeres Essen, während ein kleines Programm abgehalten wurde, denn bei der Abendveranstaltung wurde auch noch der Deutsche Studienpreis Projektmanagement (DSPM) verliehen. Für alle, die nicht schon vom Essen gesättigt waren und nur noch ins Bett wollten, eröffnete noch eine Bar in der man den Abend ausgelassen ausklingen lassen konnte.

Tag 2, 24.10.2018:

Am nächsten Tag ging es mit sehr interessanten Vorträgen weiter. Da an diesem Tag die Zertifizierungsfrage für uns im Vordergrund stand, besuchten wir die vielen Aussteller, unterhielten uns angeregt und stellten einen Plan für unsere persönliche Weiterbildung auf.

Außerdem besuchten wir einen sehr spannenden Workshop, in dem die Wu-De Methode (https://www.wu-de.com/) anhand eines Beispiels erklärt wurde. Ein Ansatz aus der chinesischen Kultur, um die Problembewältigung in einem Projekt mithilfe der fünf Wirkkräfte anzugehen. Dies ist ein Thema, welches ich persönlich gerne weiterverfolgen würde, denn ich finde es eine interessante Methode, um Konflikte im Projekt zu lösen und daraus resultierende weitere Konflikte nach Möglichkeit schon vorauszusehen.

Mit diesem Workshop endete auch der zweite Tag auf dem PM Forum für uns. Alles in allem war es ein sehr interessantes Event und definitiv eine Erfahrung bzw. einen Besuch wert. Da viele Projektmanager aus den unterschiedlichsten Bereichen vertreten waren, gab es immer jemanden, mit dem man sich austauschen konnte. Die Vorträge waren inhaltlich spannend gestaltet und haben uns „unentschlossenen“ wirklich geholfen eine Richtung zu finden, in die wir uns weiterbilden möchten. Da allerdings, wie auf jedem größeren Event, viele verschiedene Vorträge und Workshops auch parallel stattfinden, sollte man mit einem guten Plan auf das PM Forum fahren, um nicht womöglich wichtige Themen zu verpassen.

Mein persönliches Fazit: Ich konnte mir viele Anregungen holen und kann bescheinigen, dass neben der Organisation des Events auch die Themenauswahl ausgesprochen gut war. Alle unsere Fragen wurden beantwortet und ich denke, dass sich jeder Projektmanager mit einem der vorgetragenen Themen identifizieren und etwas für sich mitnehmen konnte. Bis zum nächsten Jahr!

In einem unserer aktuellen Projekte haben wir uns gefragt, welche Art des Deployment wohl für BizTalk und seine Nebenkomponenten (z.B. Webservices) am besten geeignet ist. Da es sich um verteilte Systeme handelt, war die Herausforderung zunächst, für jede logische Komponente ein eigenes Paket in Form einer MSI zur Verfügung zu stellen. Diese sollen dann über ein Software-Verteilungssystem automatisiert installiert und bereitgestellt werden. Zur Umsetzung ist aus unserer Sicht das BizTalk Deployment Framework (kurz: BTDF) hervorragend geeignet. Wir möchten daher im Folgenden auf einige Fallstricke eingehen, welche während des Projekts aufgefallen sind und einige Best Practices herleiten.

Was ist BTDF?

BTDF ist ein Framework, welches zum Konfigurieren und zur Bereitstellung von BizTalk-Anwendungen verwendet werden kann. Ins Leben gerufen wurde es durch Thomas F. Abraham, wobei die Anwendung frei verfügbar und ein somit mittlerweile ein Community-Projekt ist. Mit dem Biztalk Deployment Framework ist es mittlerweile sehr einfach extrem komplexe Biztalk-Komponenten, wie Orchestrations oder Pipelines zu deployen. Der Admin muss zur Installation der Biztalk-Anwendungen und zugehöriger Artefakte keine manuellen Schritte mehr tätigen, sondern kann die Installation komplett automatisiert durchführen lassen.
Um einen Überblick über das BizTalk Deployment Framework zu erhalten, gibt es bereits eine große Anzahl an Quellen und Tutorials, weshalb wir in diesem Artikel darauf nicht näher eingehen wollen. Viel mehr beschäftigen wir uns mit Fragen, welche aus unserer Sicht nicht ausreichend dokumentiert sind und euch das Deployment etwas vereinfachen. Die Erkenntnisse, die wir im Laufe des Projekts gesammelt haben, beziehen sich alle auf die dort eingesetzte (und dokumentierte) Version 5.5 des BTDF. Ein Release-Datum von der Version 6.0 (aktuell im Beta-Stadium) ist noch nicht bekanntgegeben.

Vorenthalten möchten wir euch die Einführungen natürlich trotzdem nicht, daher hier ein paar Quellen für die, die sich erst einmal grundlegend mit BTDF vertraut machen möchten:

• Community-Projekt: https://github.com/BTDF/DeploymentFramework
• Wiki: http://www.tfabraham.com/BTDFDocs/V5_5/
• Tutorials: https://www.biztalk-server-tutorial.com/2013/02/05/btd/    https://randypaulo.com/2012/01/13/biztalk-deployment-framework-btdf-tutorial-walkthrough/
• Blog: https://blog.sandro-pereira.com/

Aber genug einleitende Worte. Hier kommen nun unsere gesammelten Fallstricke und Best Practices zum Biztalk Deployment Framework:

Das Problem mit dem AppPool

Webservices anlegen

In der Version 5.5 des BizTalk Deployment Frameworks ist dokumentiert, dass evtl. bereitzustellende Webservices über die folgenden Einträge der ".btdfproj"-Datei zu hinterlegen sind:

1. "IncludeVirtualDirectories" auf den Wert "true" setzen:
<PropertyGroup>
…
<IncludeVirtualDirectories>true</IncludeVirtualDirectories>
…
<PropertyGroup>

2. Eine "VDirList"-ItemGroup hinterlegen:
<ItemGroup>
  <VDirList Include="*">
    <Vdir>MyVDirName</Vdir>
    <Physdir>..\MyVDir</Physdir>
    <AppPool>MyAppPool</AppPool>
    <AppPoolNetVersion>v4.0</AppPoolNetVersion>
  </VDirList>
</ItemGroup>

Natürlich funktioniert das nur, insofern ihr daran gedacht habt, alle Webservices mittels einem "Copy-Befehl" in die MSI zu integrieren. Denn wenn die Services beim Deployment-Vorgang auf dem Zielserver nicht vorhanden sind, können sie auch nicht veröffentlicht werden. Hier exemplarisch der entsprechende Copy-Befehl dazu:

<Target Name="CustomRedist">

  <MakeDir Directories="$(RedistDir)\TestFiles" />

  <CreateItem Include="..\TestFiles\**\*.*">

    <Output TaskParameter="Include" ItemName="TestFileSourceGroup" />

  </CreateItem>

  <Copy DestinationFolder="$(RedistDir)\TestFiles\%(RecursiveDir)" SourceFiles="@(TestFileSourceGroup)"/>

</Target>

Die WebServices werden auf diese Art und Weise vollkommen problemlos bereitgestellt. Der AppPool wird sogar fehlerfrei angelegt, insofern er nicht schon vorhanden ist - allerdings im PipeLine-Modus "Classic". Was aber tun wir, wenn wir den PipeLine-Modus auf "Integrated" stellen möchten? Klar - manuell geht das schnell. Aber das ist eben nicht der Sinn eines automatisierten Deployments. Zu viele Einzelschritte - vor Allem, wenn sie von Personen ausgeführt werden, die vielleicht weniger Fachkenntnis in diesem Bereich haben, führen potentiell zu Fehlern. Außerdem steigt der Aufwand mit der Anzahl der Webserver immens. Was also tun?

Die Lösung fand die Community mit der Veröffentlichung der Version 5.7. Hier erhält der Nutzer die volle Kontrolle über den IISAppPool:

https://github.com/BTDF/DeploymentFramework/blob/master/src/Samples/BizTalk/IIS/IIS.Deployment/IIS.Deployment.btdfproj

Falls ihr aber aus irgendeinem Grund eine andere Version des Deployment Frameworks benutzen wollt oder müsst, haben wir folgenden Workaround für euch:

BTDF bietet euch eine einfache Möglichkeit, externe Programme auszuführen - Powershell-Skripte eingeschlossen. Hier können wir die ganze Power von Powershell für uns nutzen, aber lasst uns Schritt für Schritt vorgehen:

1. Zunächst erstellen wir uns ein Powershell-Skript, welches die folgenden Eingangsparameter enthält:
param(
  [string] $WebSitePath,
  [string] $WebsiteName,
  [string] $AppName,
  [string] $AppPoolName,
  [string] $UserName,
  [string] $Password
)

Wieso ist das wichtig? Ganz einfach! Wir werden später im BTDF alle Parameter beim Aufruf des Skripts mitgeben. So können wir je nach Umgebung eine andere Webseite, Pfad usw. auswählen und müssen diese nicht manuell einpflegen. Weiterer Vorteil: Durch die Eingabe des AppNames können wir das selbe Skript für eine Vielzahl an unterschiedlichen Webservices einsetzen. Wir haben hier also eine generische Lösung. Den Rest kennt man sicherlich von anderen Deployment-Szenarien im Kontext von Webservices:

2. Wir erstellen zwei Funktionen, eine zum Bereitstellen des AppPools und eine zum Bereitstellen und Zuordnen der Services:

Function Add-IISAppool([string]$AppPoolName, [string]$UserName, [string]$Password)
{
  C:\Windows\system32\inetsrv\appcmd add apppool /name:$AppPoolName
  C:\Windows\system32\inetsrv\appcmd set apppool $AppPoolName /processModel.userName:$UserName /processModel.password:$Password
  C:\Windows\system32\inetsrv\appcmd set config /section:applicationPools "/[name='$AppPoolName'].processModel.identityType:SpecificUser"
}

Function Add-IISApp([string]$AppPoolName, [string]$SiteName, [string]$PhysicalPath, [string]$AppName)

{

  C:\Windows\system32\inetsrv\appcmd add app /site.name:$SiteName /path:/$AppName /physicalPath:$PhysicalPath

  C:\Windows\system32\inetsrv\appcmd set app "$SiteName/$AppName" /applicationPool:$AppPoolName

}

3. Nun können die Funktionen ganz normal abgerufen werden:

If (!Test-Path "IIS:\AppPools\$AppPoolName"))
{
  Add-IISApppool -AppPoolName $AppPoolName -UserName $UserName -Password $Password
}

If (Test-Path $WebsitePath\$AppName)
{
  Remove-Item -path $WebsitePath\$AppName\* -include *.publishproj -recurse

  If (Test-Path $WebsitePath\$AppName\App_Data )
  {
     Remove-Item -path $WebsitePath\$AppName\App_Data -recurse
  }

  Add-IISApp -SiteName:$WebsiteName -AppName:$AppName-AppPoolName:$AppPoolName -PhysicalPath:$WebsitePath\$AppName
}

So haben wir eine einfache Lösung unsere Services und die zugehörigen AppPools auf die gewünschten Server zu deployen und dabei so flexibel wie möglich zu bleiben. Der AppPool ist daraufhin mit dem Pipeline-Modus "Integrated" erstellt, womit wir unser Ziel erreicht haben. Und noch viel mehr: Dadurch, dass der Write-Host Output während des Deployments seitens BTDF mit ausgegeben wird, sind wir im Bereich Logging maximal flexibel. Man könnte beispielsweise hinter jedem Einzelschritt einen entsprechenden Text ausgeben.

Wie die Integration seitens BTDF aussieht, könnt ihr ganz einfach im oben aufgeführten Wiki nachlesen.

Wohin mit der Business-Rule-Engine?

Da wir, wie oben erwähnt, über verteilte Systeme sprechen, ist diese Frage nach der Rules Engine absolut berechtigt. Ich persönlich war am Anfang davon ausgegangen, dass die Business-Rules ganz einfach zusammengefasst in einem Teil des Deployments implementiert werden sollten. Was aber, wenn ein Teil des Projekts auf einem anderen Server bereitgestellt werden soll? Die Business Rule würde nicht mehr greifen und unsere Nachrichten würden in der MessageBox versauern!
Es ist daher unsere Empfehlung, pro Fachapplikation ein eigenes Business-RuleSet zu erstellen und letztlich auch zu deployen. Gemeinsam genutzte Komponenten, wie z.B. eine Orchestration, werden in einer Biztalk-Applikation deployed. Fachspezifische Artefakte (z.B. ein für einen fachlichen UseCase spezifischer SendPort) erhalten dann wiederum eine eigene Applikation. Und jede Applikation erhält Ihre eigenen Business Rules. Das verspricht die maximale Flexibilität während des Deployments.

Übrigens: Falls ihr euch auch wundern solltet, weshalb eure Business Rule zwar published, aber nicht deployed werden. Ihr müsst die MSBuild-Property "ExplicitlyDeployRulePoliciesOnDeploy" auf den Wert "true" setzen. Das wird leicht übersehen, da im Wiki nur das Publishing näher beschrieben und der Deployment-Vorgang nur referenziert wird.

Wie erstelle ich Hosts, Hostinstanzen und Adapter?

Zwar bietet BTDF die Möglichkeit Hostinstanzen neuzustarten - eine Neuanlage inkl. Der dazugehörigen Adapter wird bis dato jedoch nicht unterstützt. Wie im Fall der WebServices müssen wir uns auch hier eine eigene Lösung überlegen und was bietet sich hier besser an als das zu nutzen, was wir sowieso schon im Einsatz haben? Richtig, das bedeutet Hosts, Hostinstanzen und Adapter, können wir ohne Probleme mithilfe von Powershell erstellen und vom BizTalk Deployment Framework aus aufrufen. Dabei sollten wir wieder darauf achten, das Skript so generisch wie möglich zu halten. Aufgerufen werden die Skripte genauso wie die Skripte der WebServices. Ein genaues Tutorial hierzu findet ihr im referenzierten Wiki am Anfang des Artikels.
Wie bereits erwähnt, wollen wir ein hohes Maß an Generalität erzeugen, weshalb wir im ersten Schritt wieder unsere altbekannten Parameter in das Powershell-Skript einfügen. Wir werden hier beispielhaft einen Receive-Host inklusive Hostinstanz und WCF-WebHTTP Adapter erstellen.

Parameter hinterlegen:

param(

[string] $Isolated_UserName,

[string] $Isolated_Password,

[string] $InProc_UserName,

[string] $InProc_Password,

[string] $BTSPath)

Warum haben wir hier zwei unterschiedliche User-Variablen in unserem Skript? Das liegt daran, dass wir einen Adapter erstellen, welcher im "Isolated-Mode" (WCF-WebHTTP) agiert und uns offen halten wollen einen weiteren Adapter, welcher im "InProcess-Mode" (WCF-BasicHTTP) agiert zu erstellen.

Powershell Extensions für BizTalk:

Für die Kommunikation mit BizTalk existiert bereits eine Extension für Powershell, das vereinfacht die Arbeit um ein Vielfaches. Bevor wir unsere Befehle also ausführen können, müssen wir die Extension einfügen, welche sich unter dem BizTalk-Installationspfad befindet:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe $BTSPath"SDK\Utilities\PowerShell\BizTalkFactory.Powershell.Extensions.dll"

Jetzt noch aktivieren:

Add-PSSnapin -Name BizTalkFactory.Powershell.Extensions

Und nun können wir auf alle Funktionen der Extension zugreifen und mit der eigentlichen Ausführung beginnen. Das funktioniert dann wie folgt: Wir erstellen uns ein Powershell-Drive und bewegen uns anschließend darin, um zu den einzelnen Zielen, wie den Hosts, in BizTalk zu gelangen.

PSDrive und Hosts erstellen:

Mit dem ersten Befehl erstellen wir unseren PSDrive.

$Server = (Get-ItemProperty "hklm:SOFTWARE\Microsoft\Biztalk Server\3.0\Administration").MgmtDbServer

New-PSDrive -Name BizTalk -Root BizTalk:\ -PsProvider BizTalk -Instance $Server -Database BizTalkMgmtDb

Set-Location -Path BizTalk

Um jetzt in diesem Drive den „Ordner“ zu wechseln und z.B. im Bereich der Hosts zu arbeiten, wechseln wir den Pfad wie folgt

Set-Location -Path 'Platform Settings\Hosts'

Die Hosts können wir dann unter diesem Pfad wie folgt erstellen:

$HostGroupName = Get-ItemProperty -Path 'BizTalkServerIsolatedHost' -Name 'NtGroupName'

New-Item ReceiveHost -NtGroupName $HostGroupName.NtGroupName -HostType 'Isolated'

Set-ItemProperty -Path ReceiveHost -name 'Is32BitOnly' -Value 'False'

Jetzt haben wir in unserem Beispiel einen Isolated-Host erstellt und die Beschränkung auf 32-Bit ausgeschaltet. Das Vorgehen für die Adapter, sowie der Hostinstanzen ist ähnlich. Die Besonderheit an den Hostinstanzen ist allerdings, dass wir an dieser Stelle bereits die Zugangsdaten hinterlegen müssen. Dies sieht dann in etwa wie folgt aus:

$IsolatedPassword = ConvertTo-SecureString -String $Isolated_Password -AsPlainText -Force

$IsolatedCredentials = New-Object -TypeName:System.Management.Automation.PsCredential -ArgumentList $Isolated_UserName, $IsolatedPassword

New-Item -Path:'HostInstance' -HostName:ReceiveHost -Credentials:$HostisoCredentials

Erstellen eines WCF-WebHTTP Adapter:

New-Item -Path .\ReceiveHost -Hostname ReceiveHost -Direction Receive

Es ist wichtig daran zu denken, immer vorab den Pfad - wie weiter oben bereits erwähnt - zu ändern, ansonsten läuft die Anforderung ins Leere. Die Pfade sind hierbei äquivalent zu den Bereichen der Biztalk Management Console.
Leider ist die Extension im World Wide Web nicht so gut dokumentiert wie das BTDF. Allerdings findet man eine kleine Readme-Datei unter dem Installationspfad des BizTalk-Servers, hier sind nicht nur die verfügbaren Befehle hinterlegt, sondern auch eine kleine Installationsanweisung der Extension.

Und wie deploye ich das nun ohne die MSI manuell zu bedienen?

Im Best Case seid ihr nun an den Punkt angekommen, an dem ihr zumindest eine MSI habt, welche ihr nun auf euren Ziel-Server ausführen lassen möchtet. Eingangs hatte ich beschrieben, dass sowas idealerweise durch ein Softwareverteilungsprogramm geschieht, allerdings kann dieses Programm sich nicht durch die Installationsroutine der MSI klicken, was also tun?

MSI unterstützt standardmäßig Befehlszeilenargumente. Das bedeutet, dass ihr euch für das Deployment beispielsweise eine kleine Batch-Datei schreiben könnt, die das Deployment automatisiert vornimmt. Diese kopiert ihr einfach gemeinsam mit der MSI auf das Zielsystem und führt sie aus. Aber Achtung: Da ihr im Befehlszeilenargument eine bestimmte Umgebung bzw. ein bestimmtes Settings-File für eure Umgebung auswählt, benötigt ihr für jede Umgebung eine eigene Batch-Datei.

Ich zeige euch nun in kleinen Schritten exemplarisch, wie ihr eine Batch-Datei für ein bestimmtes Environment definiert.

Installation ausführen:

@echo off

msiexec.exe /I /YourGreatBizTalkApplication.msi

/log YourGreatLog.log /passive

INSTALLDIR="C:\Program Files\YourGreatBizTalkApplication\1.0"

Bevor wir etwas deployen, muss natürlich die Applikation installiert werden. Ich habe hierfür den Pfad "…/Program Files/" gewählt - aber letztlich, bleibt das euch überlassen. Bitte denkt daran "YourGreatBizTalkApplication.msi" durch den Namen eurer MSI zu ersetzen.

Settings exportieren:

Im nächsten Schritt exportiert ihr alle eure Environment-Settings vom SettingsFileGenerator.xml in das Ziel-Verzeichnis. Ihr benötigt diesen Schritt, um beim Deployment die richtige Datei und somit das richtige Environment wählen zu können. Die MSI kann leider nicht anhand der XML entscheiden, welches Environment das Richtige ist:

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\Framework\DeployTools\EnvironmentSettingsExporter.exe"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings\SettingsFileGenerator.xml"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings"

Application deployment:

Nun können wir unsere Applikation deployen, alle Vorbereitungen dafür sind ja bereits getroffen. Hierzu verwenden wir die MSBuild.exe, welche standardmäßig im angegebenen Pfad installiert sein sollte.

"%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"

/p:DeployBizTalkMgmtDB=true;Configuration=Server;SkipUndeploy=true /target:Deploy

/l:FileLogger, Microsoft.Build.Engine;logfile="C:\Program Files\YourGreatBizTalkApplication\1.0\DeployResults\DeployResult.txt"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\Deployment.btdfproj"

/p:ENV_SETTINGS:"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings\Exported_Test_Settings.xml"

Damit sind alle Schritte getan und mit einem Klick auf die Batch-Datei sollte nun die MSI ausgeführt und die Applikation bereitgestellt werden.

Unsere Erfahrungen mit dem Biztalk Deployment Framwork waren durchweg positiv. Natürlich gibt es einige Fallstricke. Aber diese sind verglichen mit einem manuellen oder ggf. alternativen Deployment zu vernachlässigen – BTDF vereinfacht die Bereitstellung eurer Anwendungen enorm. Sicherlich werden uns in Folgeprojekten weitere Fallstricke auffallen – denn wir werden das Framework weiterverwenden. Sobald wir diese gefunden haben, könnt ihr genau hier nach unseren Erkenntnissen suchen (und sie finden).