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.

Microsoft Teams verwendet für die Rechteverwaltung die Office 365 Groups. Worauf man deswegen achten sollte, um die IT weiterhin sauber zu halten, wird im Folgenden beschrieben.

Für jedes neue Team in Microsoft Teams wird eine neue SharePoint Seite und eine neue Office 365 Gruppe angelegt. Daraus ergeben sich 2 Probleme:

• Wird ein neues Team angelegt für ein organisatorisch bereits aktives Team welches seine Arbeit in SharePoint bereits organisiert wird die SharePoint Landschaft schnell sehr unübersichtlich und unverständlich, da durch die Erstellung nun zwei gleichnamige SharePoint Seiten existieren.
• Eine Office 365 Group hat eine eigene E-Mail Inbox mit gleichnamiger Adresse. Falls ihr nun bereits einen E-Mail-Verteiler mit dem gleichen Namen habt, könnt ihr euch vorstellen, dass Mails nicht dort ankommen wo sie hinsollen, da die Gruppe leicht mit dem Verteiler verwechselt werden kann.

Was man dagegen machen kann:

Microsoft hat zur Lösung der oben genannten Probleme eine Möglichkeit geschaffen die Rechteverwaltung Tool-Übergreifend zu gestalten. Da Groups grundlegender für die Systemlandschaft sind als die einzelnen Services, empfiehlt es sich in erster Linie bestehenden Gruppen ein MS-Team zuzuweisen (Abbildung 2).

Falls ihr E-Mail Verteiler Listen verwendet und diese nicht umbenennen wollt, solltet ihr ein Präfix bei der Benennung des Teams verwenden (was sich auch auf die Group und SharePoint Seite auswirkt). Ein Beispiel könnte sein: „GRP_Teamname“. Auf diese Weise ist es auf einem Blick ersichtlich wohin die Mail geht.

Auch wenn jedes Microsoft Tool seine eigene, leicht zu verwendende Rechteverwaltung mitbringt, ist es auch möglich diese Tool-übergreifend zu gestalten. Es ist gut dies im Hinterkopf zu haben, bevor man ein neues Programm einführt. So erspart ihr euch später viel Frust.

Die SQLPass Deutschland hat dieses Jahr vom 26.-28.02. wieder die SQLKonferenz ausgerichtet. Stattgefunden hat die Veranstaltung im Darmstadium in Darmstadt. Ein Pre- und zwei Konferenztage, die vollgepackt waren mit interessanten und informativen Vorträgen rund um den SQL Server, Azure sowie BI- und Big Data - Themen.

Pass Deutschland e.V. ist die deutsche Microsoft Data Platform Community und richtet verschiedene Events rund um dieses Thema aus, unter anderem einmal im Jahr die SQLServer Konferenz. Der Verein ist nicht kommerziell und sieht es als sein Ziel, den Nutzern der Microsoft Data Plattform die notwendigen Mittel zu geben, um die taktischen und strategischen Ziele ihrer Organisation, unter Einsatz der Microsoft Data Plattform zu erreichen. (siehe www.sqlpass.de)

Der Vorstand des Vereins eröffnete dann auch die Konferenz mit einer entsprechenden Keynote. Unter anderem wurden einige der Aussteller und deren Tools vorgestellt. Besonders in Erinnerung geblieben ist mir die Firma DataCore-Software mit dem Tool MaxParallel. Damit wird die IO-Last eines Servers besser auf die zur Verfügung stehenden Kerne aufgeteilt und damit, wie der Name schon sagt, parallelisiert. Das ermöglicht eine Performanceverbesserung ohne jegliche Anpassung der eigenen Anwendung. 

Bei 58 Sessions und fast immer 6 gleichzeitig stattfindenden Vorträgen, fiel es mir bei manchen Slots schon wirklich schwer, mich zu entscheiden und fast immer waren die Sessions sehr informativ und interessant. Das alles hier aufzuführen würde wohl den Rahmen sprengen, deshalb beschränke ich mich auf eine kleine Auswahl, der für mich interessantesten Themen.

Aus dem Business Intelligent (BI) Bereich gab es einen Vortrag zum Power BI Report Server von Wolfgang Straßer. PowerBI.com ist ja bereits seit über 2 Jahren als cloudbasierter Dienst verfügbar, aber nicht jeder möchte seine Reports über die Cloud bereitstellen. Mit der Veröffentlichung des Power BI Report Server (PBIRS) im Juni 2017 wurde ein Teil der Power BI Funktionalität nun auch für das eigene Rechenzentrum und somit die eigenen Server verfügbar gemacht. Dies ermöglicht es, firmenintern Reports abrufbar zu machen. Der Funktionsumfang ist etwas eingeschränkt und die Nutzung muss entsprechend lizenziert sein. Man braucht entweder eine Power BI Premium Lizenz oder eine SQL Server Enterprise Edition mit Software Assurance. Mit dem geplanten Cloud- und on-premises Feature-Gleichstand von Microsoft kann man hier aber vermutlich noch einiges erwarten.

Ein weiterer Vortrag dieser Themenreihe war Power BI und IoT von Markus Raatz. Hier wurden die verschiedenen Streaming Möglichkeiten und deren Visualisierung vorgestellt. Leider geriet der Vortrag etwas kurz, da wir auf Grund eines Feueralarms das Gebäude verlassen mussten.

Aus Entwicklersicht war der Vortrag „SQL für alle Lebenslagen“ von Christoph Muthmann sehr spannend. Kurzweilig und mit vielen Beispielen aus dem alltäglichen Leben in der SQL Entwicklung, konnte man sich hier die ein oder andere Idee mitnehmen.

Einige interessante Vorträge gab es außerdem zu Datenbankanalyse und -optimierung. Besonders gut fand ich hier „Database tuning advisor vs. Database management views“ von Torsten Strauss und „Automatische Datenbankoptimierung … Funktioniert das wirklich?“ von Mark Aslan Kuschel.

Dabei ging es vorrangig darum, wie man die Indizierung der Datenbank optimal hält, also herausfindet, welche Indizes fehlen, nicht mehr gebraucht werden oder ineffizient sind. Ab SQL Server 2017 steht dafür eine automatische Datenbankoptimierung zur Verfügung. Genutzt werden dabei die DMV (Datenbank Management Views) und auf deren Grundlage wird über Neuanlage oder Löschen eines Index entschieden. Über die IndexUsage und MissingIndex Views kann man das natürlich auch manuell mit entsprechenden Abfragen ermitteln, aber blindlings ausführen würde ich das nicht. Oft gibt es hier doppelte oder sich überschneidende Vorschläge für neue Indizes und auch bei der Benutzung der Indizes werden nur Ausführungen seit dem letzten Neustart des Servers herangezogen. Ein deutlich besseres Ergebnis erhält man mit Hilfe des Database Tuning Advisors, auch wenn hier etwas mehr Vorbereitung nötig ist, bevor man ein Ergebnis erhält.

Seit SQL Server 2016 gibt es den QueryStore. Eine Live Abfragestatistik mit graphischer Oberfläche, über die ressourcenintensive Queries ausgewertet werden können, was die Analyse und auch Bearbeitung dieser Queries deutlich vereinfacht. Um dieses Feature auch Usern älterer Server Versionen verfügbar zu machen, wurde das Open Source Projekt OpenQueryStore ins Leben gerufen. Einer der Co-Kreatoren William Durkin hat in dieser Session das Design von OQS vorgestellt und in einigen Demos die Feature und auch Grenzen gezeigt. Wenn auch die graphische Oberfläche hier nicht interaktiv ist und einige Schritte per direktem SQL-Befehl gemacht werden müssen, ist das eine super Alternative und die Weiterentwicklung sicher noch nicht abgeschlossen.

Im Großen und Ganzen eine gelungene Veranstaltung, aus der ich sehr viel Input mitnehmen konnte und die SQLKonferenz im nächsten Jahr ist schon vorgemerkt.

Tame the Data Monster! Das Maskottchen der SQLPass gab es zur Erinnerung für alle am Ende der Konferenz noch zum Mitnehmen.