eBizTalk - Berichten, Unterhalten, Weiterbilden

In den letzten Monaten habe ich einen unserer Kunden bei der Entwicklung einer Azure Cloud Lösung unterstützt. Kern dieser Lösung ist Azure Service Bus, der dank seiner horizontalen Skalierbarkeit, dem zuverlässigen Messaging und der einfachen Nutzung in hybriden Szenarien, ein integraler Bestandteil vieler Integrationslösungen geworden ist.

Für Azure Service Bus existiert eine lange Liste an Beschränkungen (Quotas), z. B. was Kontingente und Drosselungsschwellenwerte angeht. Das Nichtbeachten einer dieser Quotas kann schwerwiegende Folgen haben. In unserem Fall war das System jeden zweiten Tag nicht mehr erreichbar und ein Neustart war der einzige Workaround.

Die Fehlermeldung lautete folgendermaßen: „Cannot allocate more handles. The maximum number of handles is 4999”. Wenn man die Meldung näher betrachtet, erkennt man, dass es sich um eine Limitierung handelt.

Für uns war aus den folgenden Gründen nicht klar, warum der Fehler aufgetreten ist:

• Der Fehler ist auch an Uhrzeiten aufgetreten, an denen sehr wahrscheinlich keine 5000 Verbindungen zum Service Bus bestanden.
• Laut der Beschreibung, sind nur NetMessaging und AMQP Verbindungen mit 1000 bzw. 5000 jeweils bestehenden Verbindungen betroffen: Der Fehler ist aber auch an Stellen aufgetreten, an denen wir keine AMQP Verbindungen erstellt haben. Das dachten wir zumindest…

Fast alle unserer Aufrufe machen von der Klasse „ClientEntity“ Gebrauch. Durch die Instanziierung und die Nutzung dieser Klasse werden implizit AMQP Verbindungen aufgebaut.

Die Lösung war zum Glück einfacher als gedacht, die Fehlersuche auf einem Test-System jedoch intensiv und komplex: AMQP Verbindungen werden implizit aufgebaut und müssen explizit geschlossen werden. D.h. da, wo eine Instanz von „ClientEntity“ nicht mehr gebraucht wird, soll die Verbindung explizit geschlossen werden. In der Dokumentation ist dieses Verhalten nirgendwo dokumentiert. Das lässt sich zum Glück mittels des Aufrufs von „ClientEntity.CloseAsync()“ einfach lösen.

Fazit

Das Motto „Kenne deine Grenzen“ war in meinem Fall leider nicht hilfreich, um diesen schwerwiegenden Fehler in der Produktionsumgebung zu vermeiden. Ich musste diese Grenzen zunächst selbst erforschen, um eine passende Lösung zu finden.

Letztes Jahr stand ich vor der großen Frage wo ich mich denn beruflich sehe und wie ich mich gerne weiterentwickeln würde. Schnell war klar: Ich möchte in die Projektmanagementwelt eintauchen. Die Vielschichtigkeit und die doch sehr unterschiedlichen Aufgabenbereiche, die mit Projektmanagement verbunden sind, haben mich neugierig gemacht, mich tiefer in dieses Thema einzuarbeiten.

Die Suche nach der richtigen Wissens-“Quelle”

Als diese wichtige Entscheidung gefällt war, stand ich vor der nächsten großen Herausforderung: Wo bekomme ich für den Wissensaufbau unter anderem gute Literatur, die nicht allzu trocken ist und man trotzdem einiges an Wissen mitnimmt, her. Die Suche nach der für mich richtigen Literatur gestaltete sich nicht ganz so einfach- bis ich eines Tages auf das Buch von Mario Neumann aufmerksam geworden bin: „Projekt-Safari - Das Handbuch für souveränes Projektmanagement“. Die Beschreibung von Mario Neumann zum Buch:

Was haben Kolumbus, Lindbergh und ein Projektmanager gemeinsam? - Ihre Abenteuer sind Projekte, überall lauern Gefahren, doch bei Erfolg winken Ruhm und Ehre! […]

Dieser Guide zeigt, wie Sie die abenteuerliche Reise durchs Projekt vorbereiten, Hürden überwinden und nie das Ziel aus dem Blick verlieren. Tipps für den Ernstfall, Erlebnisse erfahrener Projektleiter und theoretische Hintergründe fügen sich zu einem völlig neuartigen Handbuch für Projektmanager. So wird jedes Projekt aufregend und inspirierend wie eine Safari!

Okay, cool, scheint mal ein etwas anderer Ansatz zu sein. So schnell war das Buch auch schon bestellt und ich mitten in der Projektsafari eingetaucht.

Der Aufbau des Buches

Eine Etappenüberschrift mit einer kurzen Erklärung, auf welches Abenteuer man sich gerade begibt. Untergliedert wird das Ganze in verschiedene Etappenziele, welche einen Bezug zu einem fiktiven Projekt haben und in „Toms Tagebuch“ erläutert werden sowie eine kurze Zusammenfassung des Etappenziels und einer (negativen) Situation mit dazugehörigem Tipp, wie man diese vermeiden bzw. meistern kann.

Gerade für Neulinge (aber auch für gestandene Projektleiter) auf dem Gebiet eine super Sache, denn man kann sich direkt in die Situation hineinversetzen und kurz darüber nachdenken wie man selbst wohl mit dieser Herausforderung umgegangen wäre. Auch bekommt man durch die Tipps eine mögliche Herangehensweise vorgestellt. Natürlich muss man diese Tipps der Situation anpassen, aber zumindest als Anregung sind sie super.

Welche Etappen gibt es?

• Etappe 1: Lust auf ein Abenteuer? » Von der Idee zum Projektauftrag
• Etappe 2: Der Abenteuer-Plan » Das Geheimnis erfolgreicher Projektplanung
• Etappe 3: Das Abenteuer beginnt » Einen Fehlstart vermeiden
• Etappe 4: Das Umfeld gewinnen » Widerstände managen
• Etappe 5: Alles hört auf mein Kommando » Führen, ohne Chef zu sein
• Etappe 6: Kurs halten in gefährlichen Gewässern » Konflikte und Krisen meistern
• Etappe 7: Zum Endspurt ansetzen » Das Projekt erfolgreich abschließen

Die Etappen werden von einem kurzen Beispiel von „früher“ (z.B. wie Kolumbus ein Projekt gestartet hat) eingeleitet und dann auf die heutige Zeit bezogen, auch diese Segmente lockern das Projektmanagementthema etwas auf. Es wird also ein kompletter Projektzyklus, von der Idee, über die Planung bis hin zum Abschluss beschrieben.

Zusätzlich kann man sich, anhand der Beispiele im Buch, ein komplettes Workbook zusammenstellen. Auf folgende Dokumente wird eingegangen und anhand eines Beispiels vorgestellt:

• Statusbericht
• Projektplan
• Risikologbuch
• Änderungsantrag
• Projekttagebuch
• AIL (Action Item List)

In wie weit man alle Dokumente genauso einsetzt, ist jedem selbst überlassen, aber als Anregung ist es wirklich gut und man lernt zumindest die Begriffe und den Aufbau kennen.

Mein Fazit

Alles in allem hat mir die Projektsafari wirklich Spaß gemacht und was fast noch wichtiger ist: Ich habe sehr viel von diesem Buch gelernt und konnte doch einiges an Tipps mitnehmen und auch im Projekt einsetzen. Auch heute schlage ich immer mal wieder darin nach, wenn ich einen anderen Blick auf meine Herangehensweise haben möchte, oder mir wieder mal ein Thema vor Augen führen möchte. Ich würde das Buch definitiv (gerade für Junior PL / PMO) weiterempfehlen.

Jahrelang kannte ich nur den Team Foundation Server, kurz TFS, von Microsoft als Quellcode-Verwaltung. Er konnte alles, was ich bis dato brauchte. Check-in und Checkout, Shelve, Work-Item Verknüpfung, Historie. Auch Branching ging mit wenigen Klicks von der Hand.

Und dann kam Git

Git war erst einmal "nur" eine weitere Quellcode-Verwaltung. Wie groß kann der Unterschied schon sein? Das waren meine ersten Gedanken. Bis ich mich mehr mit Git beschäftigte. Ich muss zugeben, Git ist für den Umstieg vom TFS gewöhnungsbedürftig. Die Lernkurve ist steil. Es ist einfach nach einem anderen Konzept gestrickt.

Der erste Unterschied ist, dass Git ein verteiltes Versionskontrollsystem (Distributed Version Control System, DVCS) ist. Der TFS hingegen ist ein zentralisiertes System (Centralized Version Control System, CVCS). D.h. im TFS sind alle Informationen zu Dateien, Historie, Changesets etc. auf einem Server abgelegt, während bei Git eine lokale Kopie auf dem Rechner vorliegt, mit allen Informationen zu Dateien, Commits, Historie etc. Es Bedarf keiner Verbindung zu einem Server, es sei denn man möchte seine Arbeit mit dem Remote-Repository synchronisieren.

Meine ersten Erfahrungen mit Git sahen so aus, dass ich mir erst einmal die Bedeutung der Befehle klar machen musste. Commit, Push, Pull, Fetch, Checkout, um hier einige zu nennen. Während Checkout im TFS bedeutet, eine Datei zum Bearbeiten zu öffnen, heißt es in Git in einen anderen Branch zu wechseln. Check-in im TFS besteht in Git aus zwei Befehlen: Commit und Push.

Hier eine kleine Gegenüberstellung der Befehle:

Der zweite Unterschied ist die Art und Weise wie Git Dateien betrachtet. Der TFS betrachtet Dateien einzeln, mit deren Änderungen über die Zeit. Git hingegen, betrachtet alle Dateien als einen Stream sogenannte Snapshots. Diese „Schnappschüsse“ entstehen jedes Mal, wenn ein Commit ausgeführt wird. Git speichert nun diesen Zustand aller Dateien, in diesem Moment als Snapshot.

Diese Art der Verwaltung hat natürlich Vorteile in Sachen Geschwindigkeit. Ein Commit dauert nur den Bruchteil einer Sekunde. Blame oder die Historie aufrufen und filtern geht unglaublich schnell. Da Git alles lokal vorhält und somit keine Verbindung zu einem Server benötigt, kann Git hier viel Performance rausholen.

Wirklich interessant, wurde es erst mit Branches und Mergen.

Volle Power mit Branches

Die volle Power von Git bekam ich erst beim Anlegen und Arbeiten mit Feature-Branches zu spüren. Hier zeigt sich der dritte Unterschied. Der TFS muss für jeden Feature- oder Release-Branch einen eigenen Ordner angelegen und alle Dateien dorthin kopieren. Dieser muss dann vom Entwickler per „Get Latest“ abgeholt werden, was bedeutet, dass ein weiterer Ordner auf der Festplatte vorliegt und Speicherplatz verschwendet.

Git hingegen kopiert nicht den gesamten Parent-Branch. Stattdessen handelt es sich einfach um einen Zeiger auf den Parent-Branch, von wo aus wir unseren neuen Branch erzeugt haben.

Im Folgenden zeige ich euch wie das funktioniert.

Wir gehen davon aus, dass ihr bereits ein „git clone“ von einem Projekt eurer Wahl gemacht habt. Für gewöhnlich nennt sich dieser geklonte Branch „master“. Wir möchten nun ein neues Feature entwickeln und legen uns dafür einen Feature-Branch namens „tolles-feature“ an.

Mit dem folgenden Befehl kann ein neuer Branch angelegt werden:

$ git branch tolles-feature

Der Branch ist nun angelegt, wir sind aber noch nicht auf dem neuen Branch. Das sieht ungefähr so aus (man achte auf das Sternchen, es markiert den aktuellen Branch):

Wir führen nun folgenden Befehl aus, um zu wechseln:

$ git checkout tolles-feature

In Git sieht das wie folgt aus (auf das Sternchen achten):

Und hier noch die Kurzform der beiden oben genannten Befehle:

$ git checkout -b tolles-feature

Nun können wir auf dem neuen Branch arbeiten und Committen, Pushen etc.

Nachdem das Feature fertig entwickelt ist, müssen wir unsere Änderungen wieder zurück in den „master“-Branch integrieren. Wir führen ein Merge durch, um den Feature-Branch zurückzuführen. Um das zu bewerkstelligen, wechseln wir zurück auf „master“:

$ git checkout master

Anschließend kommt der Merge:

$ git merge tolles-feature

Das war’s schon. Und wo ist jetzt die Power? Nun, Git ist so intelligent und hat beim „mergen“ erkannt, dass in „master“ keine Änderungen (also Commits) vorliegen, die den Merge beeinflussen. Also wird ein „Fast-Forward“ gemacht. Das heißt, der Zeiger von „master“, wird einfach auf das letzte Commit von „tolles-feature“ gesetzt, wie in der Abbildung unten zu sehen ist:

Sollten Konflikte auftreten, weil in „master“ ebenfalls Commits vorhanden sind, können diese, wie im TFS auch, einfach aufgelöst (Resolved) werden. Im oben genannten Fall gibt es aber keine Konflikte, ergo kann der Zeiger verschoben werden. Im TFS würde dennoch eine große Merge-Operation stattfinden, die Dateien vergleicht und Änderungen übernehmen muss.

Da der Branch „tolles-feature“ nun nicht weiter benötigt wird, können wir den Branch mit folgendem Befehl löschen:

$ git branch -d tolles-feature

Und so wird in Git mit Branches gearbeitet. Cool oder?

Mein Fazit

Da ich nun seit ein paar Monaten mit Git arbeite und den anfänglichen Git-Schock überwunden habe, hat sich mein Arbeitsablauf verbessert. Ich bin schneller geworden. Dafür gibt es eine Reihe von Gründen:

1. Git selbst ist sehr schnell
2. Ich mache lokale Commits, das spart Zeit und ich kann Code committen ohne dass ich Gefahr laufe, den Build zu zerstören
3. Branches! Ich kann für alles einen Branch anlegen und darin arbeiten. Ist die Arbeit erledigt, kann ich die Branches einfach zurück mergen. Es ist zum Teil meines Arbeitsworkflows geworden.

Ich kann nur sagen: Der Umstieg lohnt sich!

Zum Abschluss möchte ich noch ein paar Tools erwähnen, die das Leben mit Git erleichtern, wenn man nicht auf der Kommandozeile arbeiten möchte:

• TortoiseGit – Integriert sich in das Explorer Kontextmenü und bietet umfangreiche Möglichkeiten in Verbindung mit Git
• TGit Extension – Eine Visual Studio Extension, die TortoiseGit ins Visual Studio integriert
• Git Diff Margin Extension – Eine Visual Studio Extension, zum Anzeigen von Änderungen

Im Rahmen eines unserer Kundenprojekte ergab sich die Notwendigkeit, aus dem BizTalk heraus unsere SQL Database mit XML Strukturen zu befüllen. Eine entsprechende Stored Procedure mit der Bezeichnung "SpFillTableFromXML" existiert in der Datenbank, die eine XML-Datei entgegennimmt, um deren Felder auszulesen und deren Werte in eine äquivalente Datenbanktabelle einzutragen.

Wie die SP genau funktioniert, ist nicht relevant. Aus BizTalk-Sicht interessiert uns nur, dass wir sie aufrufen müssen, und der Body der aktuellen Message als Parameter übergeben werden soll.

Auf den ersten Blick bietet die Dokumentation von Microsoft eine Anleitung zu genau dem Thema und fordert dazu gerade mal sieben Minuten Lesezeit: https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/adapter-sql/execute-stored-procedures-with-a-single-xml-parameter-in-sql-using-biztalk

Auf den zweiten Blick spart Microsoft nicht nur an Minuten, sondern auch an Details. Sich durch die Querverweise zu kämpfen, hilft dabei nicht bis zum Schluss.

Daher nun die Schritt-für-Schritt-Anleitung, um ohne Umwege zum Ziel zu kommen:

Setup

• BizTalk Server 2016
• Receive Port für Entgegennahme der XML-Datei
• WCF-Custom Send Port für Aufrufen der SP
• MS SQL Server 2014
• SpFillTableFromXML(xml)
• Tabelle in die von der SP hineingeschrieben wird

Vorgehen: „Mal schnell den Send Port erstellen“

• InvokeStoredProcedureThatTakesXml
• WCF-Custom
• TypedProcedure/dbo/SpFillTableFromXML

Wir erstellen einen neuen Static One-Way Send Port mit dem ausdrucksstarken Namen "InvokeStoredProcedureThatTakesXml":

Dieser ist vom Typ "WCF-Custom". Die "PassThruTransmit" Pipeline genügt für uns.

Klick auf [Configure…] > Wir tragen die Uri zu unserer Datenbank ein (Syntax: mssql://[Server]/[InstanceName]/[Database]), sowie die nötige Action:

Als nächstes legen wir das [Binding] fest:

Und ausgehend davon, dass BizTalk sich mit seinem Windows-User am SQL Server authentifizieren soll, lassen wir bei den [Credentials] alles frei:

Anschließend legen wir unter [Messages] nur noch das Template fest:

Ist doch easy, oder? Der Teufel steckt im Detail.

Offensichtlich sind die folgenden Fragen:

1. Wo bekomme ich denn die Action "TypedProcedure/dbo/SpFillTableFromXML" überhaupt her und
2. was genau hat es mit der Template-Option unter "Outbound WCF message body" auf sich? Was ist <ns0:XML> (bzw. <xml_info> in der Microsoft-Doku)

Zweck dieses Artikels ist es, genau diese Fragen zu beantworten.

1. [General] > [SOAP Action Header] > [Action] richtig befüllen

Einen Hinweis auf die erste Frage bekommt man unter Punkt 8, der oben genannten Microsoft-Dokumentation:

Folgt man dem link, dann gelangt man zu…

Und schließlich zu…

Aha. Das Schema für die korrekte Action lautet also

TypedProcedure/[SCHEMA]/[STRNG_SP_NAME]

Und in unserem Fall lautet dann die konkrete Action

TypedProcedure/dbo/SpFillTableFromXML

[SCHEMA] und [STRNG_SP_NAME] kann man via MS SQL Management Studio ablesen:

2. [Messages] > [Outbound WCF message body] > [Template] richtig einsetzen

Folgendes haben wir in dem Feld eingetragen

<ns0:SpFillTableFromXML xmlns:ns0="http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo">

<ns0:XML>

<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/>

</ns0:XML>

</ns0:SpFillTableFromXML>

Hier die Details

Das XML Template besteht inhaltlich aus zwei Teilen:

1. Grundstruktur der Stored Procedure (Name der SP + Bezeichner des Parameters)
2. Platzhalter für den Payload, die XML-Datei, die wir der SP als Parameter übergeben

Hinweise

• Der Namespace ns0 ist stets derselbe: "http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo"
• Ebenso der Platzhalter: <bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/> (hier beachten: encoding muss string sein)

Erklärung

Das Template ist dafür vorgesehen, genau diese Art von Stored Procedures aufzurufen. Nämlich solche, die eine XML als einzigen Parameter entgegennehmen, um dann Dinge zu tun.

Nun bin ich zwar zuversichtlich, dass es in den meisten Fällen gut gehen wird, die markierten Felder von oben durch die eigenen Werte zu ersetzen. Es gibt aber noch eine todsichere Variante, um garantiert die korrekte Template-Action-Kombination zu erzeugen, um Fehler wie diesen hier zu vermeiden:

"... It will be retransmitted after the retry interval specified for this Send Port. Details:"System.Data.SqlClient.SqlException (0x80131904): Procedure or function 'SpFillTableFromXML' expects parameter '@XML', which was not supplied."

Template und Action mit Visual Studio generieren

Zwar findet man in der Dokumentation von Microsoft den folgenden Hinweis:

Das konkrete Vorgehen, inklusive korrekter Abbiegungen fehlt jedoch, und wird deswegen im Folgenden erläutert.

Dazu begeben wir uns ins Visual Studio

[Rechtsklick auf Schema-Projekt] > [Add] > [Add Generated Items…]

hier wählen wir [Consume Adapter Service]:

Falls die Option fehlt, muss das WCF LOB Adapter SDK installiert werden (eine Anleitung dazu hier). Im Wizard führen wir die folgenden Schritte aus:

1. "sqlBinding" auswählen
2. Datenbank-URI eintragen (dieselbe, wie im Send Port)
3. Unter "StronglyTyped Procedures" wählen wir unsere SP "SpFillTableFromXML" aus
4. Und fügen Sie mit [Add] zu den items hinzu, zu denen ein Schema erstellt werden soll
5. Abschließend klicken wir auf [OK]

Nun finden wir unter anderem das Schema "TypedProcedure.dbo.xsd" in unserem Projekt. In diesem Schema finden wir übrigens auch die nötige Action für unseren Send Port:

Um nun an das Template zu kommen, generieren wir eine XML-Instanz vom Schema "TypedProcedure.dbo.xsd"…

Und passen diese Instanz entsprechend dem Hinweis von Microsoft an…

Sodass wir das Template für unseren Send Port erhalten:

<ns0:SpFillTableFromXML xmlns:ns0="http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo">

<ns0:XML>

<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/>

</ns0:XML>

</ns0:SpFillTableFromXML>

Als ein Unternehmen mit starkem Fokus auf Integrationsprojekten, haben wir es uns in diesem Jahr nicht nehmen lassen, an Microsofts Fachkonferenz „Integrate 2019“ in London teilzunehmen. In der beeindruckenden englischen Metropole erwarteten uns spannende Vorträge von MVPs, der Microsoft Produktgruppe und Industrievertretern – die eine oder andere Neuigkeit wurde auch verkündet!

Die Integrate ist die führende Fachkonferenz, wenn es um das Thema Integration mit Microsoft Technologien geht. Verschiedene Referenten aus der Microsoft Produktgruppe informieren über technische Neuheiten und die internationale Integration Community präsentiert Tipps und Tricks aus der Praxis. Dieses Jahr fanden zwei dreitägige Konferenzen in London (3.-5. Juni) und Redmond (24.-26. Juni) statt. Die interessantesten Infos aus den Vorträgen haben wir im Folgenden kurz zusammengefasst:

Tag 1

Die Konferenz begann mit der Keynote von Jon Fancey (Microsoft Integration Platform Product Manager), der darin deutlich machte, dass Integration für Microsoft den Schlüssel für die digitale Transformation und Innovation darstellt. Der eigene Anspruch, nämlich führender Enterprise iPaaS-Anbieter zu sein, wurde auch 2019 wieder durch Gartner bestätigt. Im Rahmen der Keynote präsentierten auch drei Industrievertreter, darunter H&M und Shell, ihre entwickelten Integrationslösungen mit Microsoft Technologie.

Azure Logic Apps: Update

Im Anschluss gewährte uns Kevin Lam (Microsoft Principal Program Manager, Azure Logic Apps) Einblicke in die letzten Neuerungen in Azure Logic Apps. Mit Logic Apps lassen sich diverse Dienste miteinander verbinden und ganze Geschäftsprozesse orchestrieren. Sie laufen komplett in der Cloud. Besonders erfreulich war, dass Logic Apps sehr gut von den Kunden angenommen werden. Mittlerweile gibt es mehr als 500.000 aktive Apps. Folgend sind die wesentlichen Neuigkeiten aufgeführt:

• Es gibt viele neue Konnektoren (z.B. für Blockchain). Mittlerweile kann Logic Apps über 300 Konnektoren aufweisen.
• Azure Resource Manager (ARM) Templates von Logic Apps können parametrisiert werden, um somit z. B. einfacher in unterschiedliche Umgebungen deployed werden zu können.
• Es gibt nun eine Inline Code Action, die es ermöglicht im Rahmen der Ausführung JavaScript Code auszuführen. Die Unterstützung weiterer Sprachen ist geplant.
• In Hinblick auf eine bessere Testbarkeit von Logic Apps ist es nun möglich statische Werte von Actions zurückgeben zu lassen. Dadurch lassen sich z. B. Antworten externer Systeme simulieren.
• Bei einer fehlerhaften Ausführung einer Logic App ist es nun möglich die erneute Ausführung dort zu beginnen, wo der Fehler aufgetreten ist (resubmit from action). Bisher konnte nur die gesamte Logic App erneut ausgeführt werden.

Die interessanteste Ankündigung war jedoch die Global Availability (GA) der Integration Services Environment (ISE). Die ISE ist eine isolierte Umgebung im eigenen Azure VNET, in der für die Ausführung von Logic-Apps dedizierte Ressourcen zur Verfügung stehen. Dass somit keine verbrauchsbasierte Abrechnung (pay what you use) angeboten werden kann, liegt auf der Hand. Stattdessen wird für die ISE ein Fixpreismodell angeboten. Die Kosten sind somit im Voraus kalkulierbar und man profitiert von verbesserter Zuverlässigkeit, geringerer Latenz, erhöhtem Durchsatz und Auto-Skalierbarkeit.

Azure API Management: Update

Im Anschluss gab Vlad Vinogradsky (Microsoft Principal Program Manager, Azure API Management) ein Update zu Azure API Management. Neben aktualisierten Policies, dem neuen Support von Managed Identities und dem neuen API Scope für Subscription Keys, war die größte Neuigkeit der self-hosted API-Management Gateway. Verpackt in einem Docker-Container, wird dadurch ein on-premises API Management ermöglicht, dass jedoch weiterhin durch eine API-Management Instanz in der Cloud verwaltet wird.

BizTalk 2020

Ein weiteres Highlight des Tages war sicherlich die Ankündigung des neuen BizTalk Server 2020. Wenn ihr das erste Mal von BizTalk hört, könnt ihr hier nach der Definition schauen: https://docs.microsoft.com/de-de/biztalk/core/introducing-biztalk-server

Folgende Neuerungen kommen mit der neuen Version:

• Viele verschiedene Adapter für Cloud-Lösungen wie LogicApps, Service Bus und O365
• Deployment via VSTS
• TLS 1.2
• Verschlüsselte SQL CRUD-Operationen mit dem SQL-Server Adapter
• Application Insights

Wie bei jeder neuen Version werden die gängigen, neuen Plattformen von Microsoft - wie MSSQL 2019 - unterstützt.

Für die Migration auf die neue Version, hat Microsoft ein Migrationstool entwickelt. Ihr findet es hier:

• BizTalk Migration Tool Team Blog: https://aka.ms/btsmigration
• Runtime Shared at One Drive: https://aka.ms/btsmigrationtool
• BizTalk Migration Source code on GitHub: https://aka.ms/btsmigrationtoolsource

Tag 2

Tag 2 begann mit einem Vortrag von Alex Karcher (Microsoft Program Manager, Azure Functions) mit „5 Tips for production-ready Azure Functions“. Darin wurde hauptsächlich auf Skalierbarkeit, Event Stream Processing, Messaging, Monitoring und CI/CD eingegangen.

Azure API Management: Deep Dive

Anschließend führte uns Miao Jiang (Microsoft Senior Program Manager, Azure API Management) durch eine beeindruckende CI/CD-Demo für API Management. Die Herausforderung ARM-Templates einer API Management Instanz zu erstellen, stellte bisher eine große Schwierigkeit dar. Microsoft begegnet dieser nun mit den Open Source Tools Creator und Extractor. Während Creator die Generierung eines ARM-Templates anhand der Open API Specification einer API ermöglicht, extrahiert Extractor Konfigurationen aus bestehenden API Management Instanzen. Für den gesamten Deployment-Prozess ist es sinnvoll ein Master Template einzusetzen, dass die einzelnen API-Templates referenziert. Somit ist es möglich entweder einzelne APIs oder alle zusammen zu deployen. Für Staging-Szenarien ist es sinnvoll für jede Umgebung eine eigene API Management Instanz zu nutzen. Der gesamte Prozess ist hier vollständig beschrieben.

Quelle: https://github.com/Azure/azure-api-management-devops-resource-kit

Einen weiteren Vortrag zum Thema API Management hielt Mike Budzynski (Microsoft Program Manager II, Azure API Management). Er stellte das neue, verbesserte Developer Portal vor. Dieses erscheint nun mit einem angepassten Technologie-Stack (JavaScript, APIs und Markup) in einem moderneren und flexibleren Gewand. Tatsächlich lässt es sich umfangreich anpassen und erweitern. In letzter Instanz sogar durch Eigenentwicklung, denn das Portal ist Open Source und auf Github verfügbar.

Azure Logic Apps: Deep Dive

Derek Li (Microsoft Program Manager, Azure Logic Apps) zeigte uns in seinem Vortrag verschiedene Tipps und Tricks für Logic Apps, z. B.:

• Trigger Conditions, wodurch vor Ausführung bestimmte Bedingungen geprüft und somit die Ausführung der Logic App verhindert werden kann (Kostenersparnis!)
• Sliding Window Trigger für verlässliche, wiederkehrende Ausführungen
• die Versionierung von Logic Apps mit Hilfe von API Management
• eine verbesserte VS Code Extension

In einem weiten Vortrag zu Logic Apps (Azure Logic Apps vs. Microsoft Flow, why not both?) zeigte Kent Weare (Microsoft Principal Program Manager, Microsoft Flow) Vor- und Nachteile der beiden Technologien auf. So benötigt man für Microsoft Flow z.B. keine Azure Subscription, dafür bieten Logic Apps aber auch einige Konnektoren für Enterprise-Systeme, wie z. B. SAP. Es kann also sehr interessant sein für einfache, automatisierbare Aufgaben Microsoft Flow zu verwenden, während man für Enterprise Integrationen Logic Apps den Vorzug gewährt. Beide Services können aber auch gerne kombiniert werden!

Azure Integration Services

Einen sehr interessanten Vortrag hielt Matthew Farmer (Microsoft Senior Program Manager, Azure Integration Services) mit dem Titel "Making Azure Integration Services real".

Quelle: https://www.serverless360.com/blog/integrate-2019-day-2

Matthew zeigte uns wie die Integration Services zur Orchestrierung von Geschäftsprozessen benutzt werden können. Dabei erzeugt eine Client-App, die mit Azure Active Directory ihre Authentifizierung regelt, eine HTTP-Anfrage an das API-Management. Hier kann eine erste Validierung stattfinden, bevor der Request an eine Logic App weitergeleitet wird. Diese nimmt den Http-Request entgegen und speichert eine Nachricht im Service Bus. Im Service Bus können verschiedene Produkte lose miteinander gekoppelt werden - also mittels Message-Queue eine asynchrone Kommunikation zwischen ihnen hergestellt werden. Dabei muss der Service Bus nicht genau einen Subscriber oder Publisher haben. Es können z. B. x Personen eine Nachricht hineinlegen (hier: Logic App und Message Based Services im Backend). Das Event Grid abonniert den Service Bus und informiert eine zweite Logic App über die Ankunft einer Nachricht, die diese dann z. B an ein SaaS Service im Backend senden kann. 

Natürlich kannten wir diese Konzepte bereits. Aber es ist interessant zu sehen, wie Kollegen die verschiedenen Integration Services einsetzen und wie oft doch Parallelen zum BizTalk Server hergestellt werden können.

Tag 3

Der dritte Tag war geprägt von Vorträgen unterschiedlicher Microsoft MVPs. Er begann mit zwei BizTalk-Vorträgen, einer davon von Sandro Pereira, der Einblicke in ein komplexes Problemszenario aus einem BizTalk-Kundenprojekt gab und den Lösungsweg präsentierte.

Tom Kerkhove zeigte auf, welche Herausforderungen bei der Entwicklung von multi-tenant PaaS in Azure bedacht werden müssen und gab zu bedenken, dass eine Cloud-Lösung ständig im Wandel ist, da auch die Plattform, auf der sie läuft, sich ständig wandelt. Etwas später hob Nino Crudele in seinem Vortrag die Bedeutung von Governance in der Azure Cloud hervor und zeigte bad und best Practices. Als letztes demonstrierte Wagner Silveira wie mit Azure Functions und den Azure Integration Services eine Processing Pipeline implementiert werden kann und präsentierte anschließend ein architekturelles Redesign einer Cloud-Lösung einer staatlichen Behörde.

Fazit

Es ist schön zu sehen, dass die Integration Community wächst und wächst und auch Microsoft das Thema immer stärker in den Vordergrund rückt. Das sieht man auch an den zahlreichen Vorträgen zu den vier Azure Integration Services: API Management, Logic Apps, Service Bus und Event Grid. Insgesamt kann man den kurzen Trip auf die Insel durchaus als gelungen betrachten. Zwar haben uns besonders die Vorträge der Microsoft Produktgruppe überzeugt, doch aus den übrigen Vorträgen konnten wir einige Kniffe für das eigene Kundenprojekt mitnehmen. Letztendlich blieb auch noch etwas Zeit am Nachmittag, um den ein oder anderen Stadtteil zu erkunden und gemütlich im Pub einzukehren. Wir machen weiter mit: Plan. Design. Integrate.