eBizTalk - Berichten, Unterhalten, Weiterbilden

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:

Die Prozesse:

• Vorbereiten eines Projekts
• Lenken eines Projekts
• Initiieren eines Projekts
• Managen eines Phasenübergangs ebizcon
• 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.

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.