eBizTalk - Berichten, Unterhalten, Weiterbilden

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. Das macht es viel lesenswerter als die ursprüngliche Bachelorarbeit, weil es nicht für Dozenten und Prüfer gemacht ist, sondern für Leute mit Herausforderungen.

Das ist wenigstens für mich eine Befreiung, da der Fokus jetzt weg geht von Quellverweisen und Seitenzahlen. Es geht auch nicht mehr darum, auf möglichst viele Bereiche meines Studiums Bezug zu nehmen, damit die Dozenten und Prüfer sich freuen.

Es geht jetzt nur noch um das, was wichtig ist: konkrete Lösungen für konkrete Herausforderungen.

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).

Das World Wide Web und wie wir es nutzen hat sich im Laufe seines Daseins verändert. Von einzelnen, statischen Hypertext-Dokumenten hin zu komplexen, interaktiven Seiten voller multimedialer Inhalte. Dies zeigt sich auch in den Statistiken: Seit 2010 hat sich die durchschnittliche Website-Größe (in Desktop-Darstellung) mehr als verdreifacht. Die durchschnittliche Anzahl an Requests pro Seite liegt mittlerweile bei über 80. Dies hat vor allem Auswirkungen auf die Seitenladezeit, aber HTTP/2 schafft Abhilfe!

Mehr Bandbreite, mehr Bandbreite!

Eine höhere Bandbreite wirkt sich auch immer positiv auf die Seitenladezeit aus. Das möchte man meinen, doch die Seitenladezeit (PLT, Page Load time) hat sich in den letzten Jahren, trotz höherer Bandbreiten, kaum verändert hat. Woran liegt das?
Untersuchungen haben gezeigt, dass sich ab einer Bandbreite von 5 Mbit/s nur minimale Verbesserungen der Seitenladezeit feststellen lassen. So resultiert aus einer Verdoppelung der Bandbreite von 5 auf 10 Mbit/s, eine nur um 5% bessere PLT. Einen viel größeren Einfluss hat die Latenz, auf die nur schwer und mit hohem Aufwand Einfluss genommen werden kann. Eine Verringerung der Latenz spiegelte sich also unmittelbar in einer verbesserten PLT wider. Wieso?
Websites und ihre Bestandteile werden über das Hypertext Transfer Protocol (HTTP) geladen, welches das Transmission Control Protocol (TCP) als Transportprotokoll nutzt. Auf Grund verschiedener Eigenschaften von TCP (Reliable Transmission, Retransmission, Congestion Control) ist dessen Performance unmittelbar abhängig von der Latenz des Netzes. Noch deutlicher spürbar in mobilen Netzen, in denen die Latenz stärker schwankt und deutlich höher liegt als über Kabel. Eine Möglichkeit der Abhilfe in Bezug auf die PLT kann also eine optimierte Nutzung der TCP-Verbindungen sein – HTTP/2 macht das möglich!

Von HTTP/1.1 zu 2.0 in „nur“ 20 Jahren

Im Jahr 1997 wurde HTTP/1.1 (RFC2068) als Update der nur ein Jahr zuvor erschienenen Version 1.0 veröffentlicht. Denn es gab Nachbesserungsbedarf: Wie in HTTP/1.0 beschrieben, muss für jeden Request eine neue TCP-Verbindung (short-lived connection) geöffnet werden. Durch den zeitintensiven TCP Three-Way-Handshake und der Nutzung als „Cold Connection“ (TCP Slow Start) führte dies zu starken Performance-Einbußen. In HTTP/1.1 wurde deshalb der keep-alive-Header eingeführt, wodurch eine geöffnete TCP-Verbindung nicht mehr sofort geschlossen wird, sondern für einen bestimmten Zeitraum geöffnet bleibt (persistent connection), sodass sie für weitere Request/Responses genutzt werden kann.

Seitdem hat sich das Web weiterentwickelt, das HTTP-Protokoll erfuhr jedoch für über 20 Jahre hinweg nur wenige Änderungen. Vielleicht war es der Vorstoß von Google mit dem Protokoll SPDY (gesprochen „Spidi“), der neue Bewegung in das Thema brachte. In jedem Fall sind große Teile des Protokolls in die neue Version des HTTP-Protokolls (RFC 7540) eingeflossen. SPDY selbst wurde von Google in Hinblick auf den neuen, kommenden Standard HTTP/2 zurückgezogen und der Support eingestellt.

Was ist neu in HTTP/2?

HTTP/2 ermöglicht eine effizientere Nutzung der Netzwerkressourcen und merzt somit einige Mängel von HTTP/1.1 aus, ohne dabei die Semantik des Vorgängers zu verändern. Dabei sind die folgenden drei Neuerungen ausschlaggebend.

Multiplexing

Ein Problem, das mit HTTP/2 adressiert wird, ist Head-of-line blocking. Dabei stauen sich die ausgehenden Request in einer Warteschlange an, da eine Verbindung immer nur für einen Request/Response gleichzeitig genutzt werden kann. Die Verarbeitung erfolgt also pro Verbindung sequentiell. In HTTP/1.1 wurde bereits versucht mittels HTTP Pipelining dieses Problem zu lösen, leider erfolglos. Stattdessen hilft der Browser, denn dieser verarbeitet Requests durch das Öffnen mehrerer Verbindungen parallel (je nach Browser bis zu 8 pro Hostname). Dennoch erfordern heutige Websites häufig ein Vielfaches der zur Verfügung stehenden gleichzeitigen Verbindungen zum vollständigen Laden.

In HTTP/2 können durch Multiplexing mehrere Request- und Response-Nachrichten parallel über dieselbe TCP Verbindung übertragen werden, wodurch das Öffnen mehrerer Verbindungen nicht mehr notwendig ist. Dadurch werden einige etablierte Workarounds wie Concatenation, CSS-Sprites oder Domain Sharding obsolet.

Header Compression

Durch die Zustandslosigkeit des HTTP-Protokolls ist es notwendig bei jedem Request alle für die Verarbeitung benötigten Informationen mitzusenden. Werden viele Ressourcen desselben Host abgefragt, werden vielfach redundante Header-Informationen übertragen, obwohl der Server diese möglicherweise durch vorangegangenen Requests bereits erhalten hat.
Um dieses Problem zu adressieren, wird ein speziell für HTTP/2 entwickeltes Kompressionsformat namens HPACK angewandt. Vereinfacht sieht dieses vor, dass sowohl Server als auch Client pro Verbindung eine dynamische Lookup-Table für die Header-Informationen halten. Der Client kann den Server dazu anweisen die empfangenen Header-Informationen in seiner Tabelle zu speichern. Muss der Client denselben Header nochmal schicken, sendet er nur den Index des Tabelleneintrags. Zusätzlich sind die Header-Informationen Huffman-kodiert.

Server Push

Fordert der Client eine Seite beim Server an, folgen nach der Analyse der Seite weitere Requests des Clients zur Anforderung benötigter Ressourcen, wie JavaScript-, CSS- oder Bilddateien. Um die Zeit bis alle Ressourcen vorliegen zu verkürzen, kann der Server diese Ressourcen bereits bei Anfrage der Seite mit an den Client schicken, sodass diese dann bereits im Cache des Clients vorliegen und kein weiterer Round-Trip notwendig ist.

Unterstützt mein Browser HTTP/2?

Die meisten Browser-Hersteller haben bereits seit längerem den Support für HTTP/2 implementiert. Eine detaillierte Übersicht findet sich bei caniuse.com. Da HTTP/2 abwärtskompatibel ist, gibt es nichts zu beachten. Das Protokoll wird im Rahmen des ersten Request „ausgehandelt“ (ALPN, Application-Layer Protocol Negotiation).

Kann ich HTTP/2 mit meinem Webserver verwenden?

Ein klares: „It depends!“ Konkret kommt es darauf an, ob der genutzte Webserver bereits HTTP/2 implementiert und die Seitenzugriffe verschlüsselt erfolgen. Die Spezifikation sieht zwar keinen Zwang für Verschlüsselungen wie TLS vor, trotzdem erfordern es die meisten Implementierungen. Eine Liste mit Implementierungen findet sich auf der Github-Seite für HTTP/2 der HTTP Working Group. In der Microsoft-Welt bietet IIS 10 die Unterstützung. Dieser ist allerdings an Windows Server 2016 geknüpft, weshalb sich der ein oder andere bis zum nächsten OS-Update gedulden muss.

Fazit

Mit HTTP/2 wurde die Basis für das Protokoll des WWWs erneuert und es wurde auch Zeit.
In Hinblick auf die Performance lohnt sich die Aktivierung von HTTP/2 vor allem dann, wenn zum Laden der Seiten eine Vielzahl an Ressourcen vom Server abfragt werden muss. Auf Grund der Abwärtskompatibilität zu HTTP/1.1 hat eine Aktivierung aber auch keine negativen Aspekte. Zu berücksichtigen ist die Unterstützung des eingesetzten Webservers. Wir selbst hosten unsere Website als Azure App Service in der Cloud. Eine Umstellung bedeutet hier nicht mehr Aufwand als das Umlegen eines Schalters in der Administrationsoberfläche. Vielleicht auch für Sie ein Anreiz über einen Cloud Move nachzudenken!

In den letzten Jahren hat sich HTTP, dank REST, als eines der wichtigsten Protokolle zur Kommunikation zwischen Web-Services etabliert. Die Verwaltung und Betreuung solcher Services ist eine große Herausforderung. Mit Azure API Management will Microsoft das ändern.

Eine API (Application Programming Interface) beschreibt Operationen, die die Schnittstelle für Kommunikation zwischen Systemen zur Nutzung ihrer Funktionalitäten, vorschreiben.

Die Bereitstellung komplexer APIs stellt für Entwickler und Administratoren viele Herausforderungen dar, die sich stark voneinander unterscheiden und die umfangreiche Kenntnisse erfordern, um diese verwalten zu können. Die Verwaltung einer API befasst sich u.a. mit folgendem:

• Zugriffsteuerung

• Analytik

• Dokumentation für Entwickler

• Ratenbegrenzung

Azure API Management, ist ein Microsoft „Platform as a Service“ (PaaS) zur Lösung oben genannter Aufgaben. Er bietet u.a. einen Proxy zwischen der zu verwaltenden API und Anwendungen, die die Dienste der API nutzen. Durch Azure API Management verwaltete APIs müssen nicht in Azure gehostet werden, sondern können auch on premises oder in anderen Cloud Diensten gehostet werden.

Azure API Management teilt sich in drei Komponenten auf:

• Publisher Portal: Eine Web-Applikation, womit Herausgeber der API unterschiedliche Konfigurationen des Proxys verwalten können.

• Developer Portal: Bietet den Entwicklern eine Web-Applikation, um auf die Dokumentation der API sowie ihre eigenen Monitoring Dienste zuzugreifen.

• API Proxy: Es besteht kein direkter Zugriff auf die API. Client Anwendungen kommunizieren mit dem Proxy zur Weiterleitung der Aufrufe an die API.

Da verschiedene APIs sich des gleichen Geschäftsmodels bedienen können, bietet Azure API Management das Produkt (Products) Konzept an. Ein Produkt stellt den Entwicklern eine Art von Abonnement zur Verfügung, womit verschiedene APIs zusammen verwaltet werden können.

Ein Produkt und seine APIs können durch Richtlinien (Policies) konfiguriert werden.

Die Macht der Richtlinien

Wie oben erwähnt, findet jede Kommunikation zwischen einer API und einer Anwendung, durch den Proxy statt. Dadurch ist es möglich alle Anfragen (Inbound) sowie Antworten (Outbound) vom Proxy abzufangen und je nach Anfrage oder Antwort, zusätzliche Dienste anzubieten.

Diese Richtlinien können innerhalb des Lebenszyklus einer Anfrage ausgeführt werden. Dieser Lebenszyklus  besteht aus 4 Phasen:

1. Inbound: beim Eingang eines Aufrufs.

2. Outbound: beim Ausgang eines Aufrufs (Antwort auf den eingehenden Aufruf).

3. Backend: nach Inbound Richtlinien und bevor die Anfrage an die Backend API geschickt wird.

4. Error: beim Auftritt von Fehlern.

Richtlinien sind XML basiert und können auf Produkte, APIs und Operation angewandt werden. Außerdem unterstützen sie C#-6, womit sich sämtliche Szenarien dynamischer und flexibler verwalten lassen.
Die Abbildung zeigt die Konfigurationsoberfläche für die Richtlinien.

Sollen z.B. die Anfragen aller APIs als XML beantwortet werden, müssen die folgenden Rechtlinie für alle Produkte, APIs und Operationen spezifiziert werden:

Solche Richtlinien sind zustandslos. Mit der vordefinierten Context-Variable ist es aber durchaus möglich auf Anfragen bezogene Informationen und Metadaten zuzugreifen. So kann man z.B. festlegen, dass von einer IP-Adresse maximal 5 Aufrufe pro Sekunde behandelt werden.

Wird ein Endpunkt mehr als 5 Mal innerhalb von 20 Sekunden aufgerufen, erhält man einen Rate Limit-Fehler:

Es ist zu beachten, dass das erste Beispiel eine Outbound-Richtlinie und das zweite eine Inbound-Richtlinie zeigt. D.h. dass, das erste Beispiel auf allen Antworten anzuwenden ist. Beim zweiten sind nur eingehende Aufrufe betroffen.

Innerhalb des „on-error“ Abschnitt, kann man Richtlinien, die beim Auftreten von Fehlern ausgewertet werden, festlegen.  Im folgenden Beispiel wird nach Fehlern, die durch die Auswertung der Ratenbegrenzungsrichtlinie ausgelöst werden, gesucht. Dafür ist von den Ablaufsteuerungselementen wie z.B. „choose“ und „when“ Gebrauch zu machen. Damit lassen sich Antworten modifizieren.

Richtlinien sind nicht nur für die Kommunikation einer Applikation, dem Proxy und der API gedacht. Aufrufe an externe Dienste können z.B. mittels der Richtlinie „send-request“ definiert werden.

In diesem Artikel wurde insbesondere auf das Thema Richtlinien in Azure API Management eingegangen. Eine XML basierte Konfiguration, zur Behandlung und Bearbeitung von Anfragen, welche nicht nur statische Konfigurationen sind. Auch dynamische und flexible Konfigurationen, die sich innerhalb des Lebenszyklus einer Anfrage, auswerten lassen sind möglich und einfach zu gestalten.

Fazit

Vielen lassen sich vom Azure API Management täuschen und stellen es sich als ein weiteres Werkzeug, um APIs in der Cloud zu hosten, vor. Das ist aber nicht der Fall.

Azure API Management stellt ein mächtiges Werkzeug in Azure für den Einsatz, Verwaltung und sogar bis zur Erweiterung dieser APIs. Ob für Administratoren oder Entwickler, lassen sich solche Aufgaben, flexibel mittels Richtlinien erledigen.