eBizTalk - Berichten, Unterhalten, Weiterbilden

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.

Im Rahmen meiner Projektmanagement-Weiterbildung, musste ich mich entscheiden: klassisch oder agil?
Auf dem PM Forum in Nürnberg, das ich im November zusammen mit Hieronymus besucht hatte, wurde dieses Thema auch behandelt. Eine „richtige“ Antwort, konnte dort aber auch nicht gegeben werden. Nach einigen Überlegungen und Gesprächen mit Kollegen habe ich mich dann dazu entschlossen in die agile Welt einzutauchen.

Damit wäre die erste Frage geklärt, wodurch ich mir im zweiten Schritt die Frage stellte: Welche Zertifizierung möchte ich eigentlich machen? Denn da gibt es allerhand: Scrum Master, Product Owner, PRINCE2 Agile, PMI, AgilePM etc…

Nach einiger Recherche stand fest: PRINCE2 Agile wird es werden. Wieso ausgerechnet PRINCE2 und dann auch noch Agile? Agile aus dem Grund, da ich mich in die agile Projektschiene eingliedern möchte. PRINCE2, da es ein echt spannendes Konzept und De-facto-Standard für das Projektmanagement ist.

Im Grunde genommen ist PRINCE2 Agile eine Verschmelzung des klassischen Projektmanagement Frameworks mit agilen Methoden. Beide haben jeweils eigene Stärken und ergänzen sich somit in der Kombination zu einem ganzheitlichen Ansatz für ein agiles Projektmanagement. Wobei die Stärke von PRINCE2 in den Bereichen Projektlenkung sowie Projektmanagement liegt, die agile Methode ihren Schwerpunkt eher bei der Produktlieferung hat. Mit der Kombination aus beiden, sollen also alle, für ein erfolgreiches Projekt, wichtigen Bereiche abgedeckt werden.

Das Training zur Foundation-Zertifizierung fand bei Serview in Bad Homburg statt. 3 Tage vollgepackt mit Unterrichtsstunden und Übungen, um bestens auf die Prüfung vorbereitet zu sein.

Themen des ersten Tages waren, unter anderem, klassisches PRINCE2.

Dabei bildeten einen Schwerpunkt die Prozesse:

• Vorbereiten eines Projekts
• Lenken eines Projekts
• Initiieren eines Projekts
• Managen eines Phasenübergangs
• Steuern einer Phase
• Managen der Produktlieferung
• Abschließen eines Projekts

Und aus dem agilen Bereich (ohne Bezug zu PRINCE2):

• Scrum
• Kanban
• Lean Startup
• Anforderungen und User Stories
• Agile Schätzung und Story Points
• Priorisierung von Anforderungen

Am zweiten Tag wurde alles, was wir an agilen Themen nicht besprochen hatten, durchgenommen. Die Verschmelzung PRINCE2 Agile war auch Thema:

• Vorbereiten und Initiieren eines Projekts
• Steuern einer Phase und Managen der Produktlieferung
• Managen eines Phasenübergangs und Abschließen eines Projekts
• Lenken eines Projekts
• Themen Organisation, BC, Pläne, Qualität, Änderungen Risiken, Fortschritt.

Für Tag 3 stand dann die Prüfung inkl. Prüfungsvorbereitung und Fragerunde an. Eine Probeprüfung wurde uns schon an Tag 1 ausgeteilt und die Durchführung wurde wärmstens empfohlen, um ein Gefühl für die Fragestellungen zu entwickeln und die eigenen Defizite zu erkennen. In der Vorbereitung sind wir also auch diese Probeprüfung durchgegangen und haben Fragen diskutiert.

Dann war es soweit. Die Prüfung stand an! 60 (+20) Minuten für 50 Fragen. An sich ausreichend Zeit, allerdings fand der Kurs auf Deutsch, die Prüfung auf Englisch statt, ein Grund weshalb es 20 zusätzliche Minuten gab.

Was ich über den Kurs bzw. die Zertifizierung sagen kann:

Der Kurs an sich war anstrengend, da einem sehr viel Wissen in kürzester Zeit vermittelt wurde. Seitens Serview war der Kurs aber wirklich gut vorbereitet und wir hatten eine großartige Trainerin, die uns gut durch den Stoff geführt und auf die Prüfung vorbereitet hat. Es wurde individuell auf die Teilnehmer eingegangen und auch darauf geachtet, dass immer wieder Pausen eingelegt wurden, damit wir uns nicht überfordert fühlten. Alles in allem habe ich mich gut aufgehoben gefühlt.

Erst kürzlich wollten wir einen SOAP 1.1-Request mit WS-Security aus einem BizTalk Send Port heraus senden. Wir dachten anfangs nicht, dass dies eine große Herausforderung werden könnte - andere Authentifizierungsverfahren sind ja nun auch reichlich in den diversen Adaptern (z.B. BasicHttp-Adapter) implementiert. Tatsächlich ist es jedoch anders als vermutet, In BizTalk sind mehrere, schwer zu recherchierende Schritte nötig, um dies nach unseren Voraussetzungen umzusetzen. Daher hier nun eine kleine Zusammenfassung unserer Erkenntnisse.

Zunächst möchte ich einmal die Anforderungen definieren. Wir möchten:

1. Einen SOAP 1.1-Request mit WS-Security aus einem BizTalk-Send Port versenden
2. Zusätzliche Informationen in den HTTP-Headern hinterlegen
3. Auf Transport-Ebene benötigen wir eine Verschlüsselung, da sonst das Passwort auf dem Weg zum Ziel gelesen werden kann

Die Punkte 2 und 3 klingen zunächst trivial. Ich habe sie jedoch mit aufgeführt, da der erste Punkt Seiteneffekte auf genau diese beiden Punkte haben wird.

WS-Security im SOAP-Request

Wie bereits einleitend beschrieben, haben wir erst einmal versucht den BasicHttp-Adapter zu verwenden. Problem: Dieser Adapter unterstützt keine WS-Security. Und der WSHttp-Adapter kommt wegen dessen Bindung zu SOAP 1.2 nicht in Frage. Hier musste also eine andere Lösung her:

WCF-Custom Send Port einrichten

Zunächst erstellen wir uns ein WCF-Custom Send Port und setzen wie gewohnt unsere Einstellungen. Das bedeutet z.B. die richtige Pipeline auszuwählen, Filter zu setzen usw.

Ist das getan müssen wir noch ein paar andere Schritte erledigen:

1. Zum Binding-Tab wechseln
2. customBinding auswählen
3. httpTransport mit einem Rechtsklick entfernen und mit einem erneuten "Rechtsklick->Add extension" die httpsTransport Erweiterung hinzufügen
4. Mit einem letzten "Rechtsklick->Add extension" fügen wir noch die Security-Erweiterung hinzu

Damit haben wir alle nötigen Komponenten hinzugefügt. Diese müssen nun nur noch konfiguriert werden. Dabei müssen folgenden Punkte beachtet werden:

Username und Passwort könnt ihr wie gewohnt im Credentials-Tab oder direkt im Code (z.B. in einer Pipeline-Komponente) setzen.

Nach diesem Abschnitt ist man dazu in der Lage Soap-Nachrichten mit der WS-Authentifizierung zu verschicken. Problem: Wie erlangt man nun die Kontrolle über die HTTP-Header zurück? Mit einem WCF-WebHttp Adapter hatte man immer die Möglichkeit die Outbound Http Headers über die Admin-Console oder die MessageContext-Properties zu setzen. Diese Möglichkeit wurde entfernt.

WCF-Behavior zum Setzen der HTTP-Header

An dieser Stelle möchte ich überhaupt nicht näher darauf eingehen wie man WCF-Behaviors in BizTalk implementiert. Stattdessen stelle ich einige Links zur Verfügung - denn dieses Vorgehen ist im Internet sehr gut dokumentiert.

https://www.bencode.net/biztalk,wcf/2011/06/26/biztalk-custom-wcf-behaviour

wcf-samples message-inspectors

Nun sollten wir eigentlich zufrieden sein: Wir können ein SOAP 1.1 Request mit WS-Security und selbst gesetzten HTTP-Headern an einen beliebigen Endpunkt senden. In unserem Fall kam es jedoch vor, dass wir wegen der Umstellung auf HTTPS Probleme bekamen. Nämlich die folgende Fehlermeldung:

The request was aborted: Could not create SSL/TLS secure channel!

TLS 1.2 auf einem Windows-Server aktivieren

Der Fehler liegt hierbei in den meisten Fällen bei der Konfiguration des Windows Servers, da veraltete Sicherheitsstandards verwendet werden und der zu erreichende Endpunkt diesen Standard nicht mehr unterstützt. Die Rede ist von SSL3 (hier gab es vor einiger Zeit den POODLE-Exploit, den ein paar nette Google-Mitarbeiter gefunden haben – siehe hier: Exploiting SSL 3.0 ).

SSL3 gilt es nun zu deaktivieren. Stattdessen wollen wir ausschließlich TLS 1.2 verwenden. Dabei geht man wie folgt vor:

1. Unbedingt ein Backup von der Registry machen! Dafür muss man einfach den obersten Knoten rechtsklicken und die Daten exportieren.
2. Wechsel zu "HKLM\System\CurrentControlSet\Control\ SecurityProviders\Schannel\Protocols"
3. Nun geht man in JEDEN Unterordner hinein (Client/Server) und setzt den Wert von "DisabledByDefault" auf "1"
   
4. Den Unterordner "TLS 1.2" lässt man dabei unberührt. Stattdessen setzt man den Wert "Enabled" auf "1"
   
5. Wechsel zu "HKLM\SOFTWARE\Wow6432Node\Microsoft\ .NetFramework\v4.0.30319" und ein neues "DWORD-Value(32 bit)" erstellen

a. Namen auf "SchUseStrongCrypto" setzen

b. Im Inhalt steht der Wert 1

6. Den Punkt 5 wiederholt man unter dem folgenden Pfad: "HKLM\SOFTWARE\Microsoft\ .NetFramework\v4.0.30319"
   

Nun können wir unsere Zugangsdaten über die WS-Security sicher übertragen und sollten auch keine Fehlermeldung erhalten - denn wir nutzen eine sichere, transportorientierte Verschlüsselung.