eBizTalk - Berichten, Unterhalten, Weiterbilden

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.

Kurz nach der Unterzeichnung des Arbeitsvertrages bei der eBiz bekam ich ein Buch mit dem Titel „Folienkrieg und Bullshitbingo: Handbuch für Unternehmensberater, Opfer und Angehörige“ als Willkommensgeschenk zugesendet. Sofort fing ich mit voller Begeisterung an dieses Buch zu lesen. Ich war sehr gespannt über meine zukünftige Tätigkeit und wollte alle möglichen Informationen bekommen… Das Buch hat meinen Erwartungen entsprochen und ich möchte hier kurz darüber berichten.

Als erstes ein paar Worte über den Autor. Ewald F. Weiden ist studierter Betriebswirt und promovierter Kommunikationswissenschaftler. Er war neun Jahre Unternehmensberater. Auf dem Höhepunkt seiner Beraterlaufbahn konnte er in 18 Hauptstädten der Welt einen Touchdown verbuchen und hatte Hilton Diamond Status. Heute lebt er in Berlin, hat seine work-life Balance austariert und schreibt Bücher.

Der Autor warnt vor dem Beruf des Beraters, denn er ist nicht für alle geeignet. Als Berater erwartet einen die Arbeit in unterschiedlichen Firmen, deswegen muss man sich schnell an das neue Umfeld gewöhnen können. Man ist viel unterwegs und arbeitet oft mit minimaler Büroausrüstung.

Falls man sich doch für den Beruf entscheidet, hat man mehrere Einstiegsmöglichkeiten: unter anderem, direkt nach dem Studium, oft über Recruiting-Events, auch als Quereinsteiger nach erfolgreicher Karriere.

Im Berufsalltag braucht jeder Berater sein Werkzeug. Dazu gehören:

• Trolley in passender Handgepäckgröße und mit persönlicher Note, um schnell ihn wiederfinden zu können
• Notebook – es verrät sofort alles über seinen Besitzer
• IT-Berater: „ThinkPad … Alle Anschlüsse sind vorhanden und gut erreichbar, das Konzept ist durchdacht, und der legendäre Ruf suggeriert, dass man mit den Geräten zur Not auch noch einen Nagel in die Wand schlagen kann.“
• Dell & HP: „Die „Arbeitstiere“ unter den Rechnern, wie sie alle großen Unternehmensberatungen und Konzerne auf der Grundlage von Rahmenverträgen an ihre Mitarbeiter ausgeben.“
• 10- bis 12-Zoll: „… Partner oder Vice Presidents, die darauf vertrauen können, dass alle Details, …, von ihren Untergebenen erfüllt werden. …“
• und Smartphone, als wichtiges Kommunikationsmittel

Fazit

In diesem Buch ist es dem Autor meiner Meinung nach sehr gut gelungen, seine Erfahrungen und Vorstellungen über den Beruf des Beraters umfassend und humorvoll wiederzugeben. Ich kann dieses Buch sowohl Beratern, als auch zukünftigen Berater empfehlen.

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

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

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

· Logic Apps

· API Management

· Service Bus

· EventGrid/-Hub

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

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

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

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

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

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

Stay Tuned!

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

Unser Szenario

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

ARM Templates erstellen

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

Einstellen in Git

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

Logic Apps erstellen

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

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

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

Build und Release Pipeline in Azure DevOps anlegen

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

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

Wozu kann ich die Lösung nutzen?

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

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

Fazit

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

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

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

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

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

Topics Covered

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

Das Dokument steht hier zum Download bereit