Headerbild

eBizTalk - Berichten, Unterhalten, Weiterbilden

Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

API Management - Teil 5 - Provisionierung

Veröffentlicht am 30.09.2020 von Hieronymus Deutsch , APIM

Dieser Artikel ist Teil einer Serie zum Thema API Management in großen Unternehmen. Ziel ist es, meine Sicht auf verschiedene Themen zu teilen und die Komplexitäten aufzudecken. In diesem Artikel werde ich Fragestellungen behandeln, die mit der Provisionierung von API Management und APIs zu tun haben. Hierfür nehme ich mir Azure API Management als Beispiel.


Viele Möglichkeiten ein API Management zu provisionieren

Wenn man ein API Management aufsetzen möchte, hat man folgende Möglichkeiten das zu erreichen.

  • Manuell über das Azure Portal
  • Mit PowerShell
  • Über die CLI
  • Mit Hilfe vom Azure Ressource Manager (ARM)
  • Terraform & Ähnlich
  • u.v.m.

Welcher Weg jedoch derjenige ist, der für den Anwendungsfall am Sinnvollsten ist, hängt zu 100% davon ab wie das API Management in Zukunft verwendet werden soll. Hierzu empfehle ich auch Teil 4 von dieser Serie zu lesen. Um die Richtige Entscheidung zu treffen, sollte man sich zu den folgenden Anforderungen eine Antwort suchen:

  • Wie wichtig ist ein schnelles Desaster-Recovery?
  • Werden mehrere Teams das APIM nutzen?
  • Gibt es ein Team, welches die Zuständigkeit inne hat?
  • Brauchen Änderungen am APIM ein vorheriges Approval?
  • Gibt es mehrere Umgebungen (dev, test, prod), die identisch konfiguriert sein müssen?


To IaC or not to IaC

IaC (Infrastructure as Code) ermöglicht, eine gesamte Infrastrukturarchitektur durch die Ausführung eines Skripts zu beschleunigen. Nicht nur können virtuelle Server bereitgestellt werden, sondern auch vorkonfigurierte Datenbanken, Netzwerkinfrastrukturen, Speichersysteme, Lastausgleiche und vieles mehr.


All das kann schnell und einfach für Entwicklungs-, Test- und Produktionsumgebungen konfiguriert werden, was den Softwareentwicklungsprozess wesentlich effizienter machen kann. Außerdem können problemlos Standardinfrastrukturumgebungen in anderen Projekten wiederverwendet werden.

Die Möglichkeit eine gesamte Infrastruktur durch Ausführung eines Skripts zu konfigurieren ist ein großer Vorteil für die, die ein gutes Desaster Recovery benötigen.

Für Hackathons und kleinere Hobby-projekte ist die Komplexität der Konfiguration und auch die organisatorische Hürde sehr gering. Das verleitet gerne dazu, die Cloud-infrastruktur manuell aufzusetzen. Das ist vielleicht für das eine Projekt auch ausreichend. Trotzdem empfehle ich auch hier die Verwendung von IaC. Der Grund dafür ist, dass die meisten Architekturen auf die ein oder andere Weise wiederverwendet werden. Ein Lösung, die im Hackathon entwickelt wurde findet häufig auch Anwendung in der Organisation.

Ich empfehle generell die Verwendung von Provisionierungs-Automatisierung. Für große Unternehmen ist der Nutzen nicht wegzudenken und mitigiert viele Risiken. Desasterf Recovery ist hier vielleicht das offensichtlichste Beispiel. Ein weiteres ist jedoch auch der Transfer von Wissen und Knowhow. Es wäre schlecht, wenn das Wissen über die Konfiguration der Infrastruktur zusammen mit dem Mitarbeiter die Firma verlässt.


Organisatorische Bedenken

Im vorangehenden Kapitel habe ich meine klare Empfehlung ausgesprochen IaC zu verwenden. In großen Firmen, die aus verschiedenen Gründen die einfachsten Sicherheitsanforderungen an die Infrastruktur generell haben, sind beim Einsatz von IaC jedoch einige Dinge zu beachten.

Viele Firmen haben mehrere IT-Entwicklungsprojekte und Teams. Die Frage ergibt sich also in wie weit diese Teams die gleichen Komponenten der Infrastruktur wiederverwenden dürfen, sollten oder können. Ein Team- und Projektübergreifendes API Management zum Beispiel stellt klare Fragen an die Sicherheit. Aber wie viel Kontrolle erhalten die einzelnen Teams auf das API Management? Wie verhindert man, dass Teams sich nicht gegenseitig Probleme bereiten?

Im Folgenden möchte ich 4 Möglichkeiten aufzeigen, die in 1000 Metern Höhe beschreiben, wie API Management in den verschiedenen Teams verwendet werden könnte.

Im ersten und einfachsten Fall verwendet jedes Entwicklungsteam sein eigenes API Management, welches durch das IaC-Tool der Wahl provisioniert wird. Es kann nur das zuständige Team die Konfiguration des API Managements ändern und ist somit auch zu 100% zuständig für die Prozesse die damit einhergehen. Ein Vorteil von dieser Struktur ist, dass Teams sehr unabhängig agieren können, was die Entwicklungsgeschwindigkeit erhöht.

Abbildung 1: Infrastruktur Entwicklungsprozess in unabhängigen Teams

Wenn sich die Organisation dazu entschieden hat, das API Management zu zentralisieren, um zum Beispiel zentrale Kontrolle über die Sicherheitsmaßnahmen und Zugriffssteuerung zu haben oder einfach im Budget einzusparen, dann stellt sich die Frage wie die Entwicklung und Provisionierung des API Managements dann vonstatten geht.

Hier gibt es mehrere Möglichkeiten.

  • Man erlaubt den Teams, ähnlich einer open-source Lösung, an der gemeinsamen Konfiguration des API Managements mitzuwirken.
  • Man erlaubt es ihnen, APIs in ein bestehendes APIM direkt zu provisionieren.
  • Man erlaubt es nur indirekt über eine API die Provisionierung von APIs.

Welche dieser Möglichkeiten die richtige ist hängt von den Anforderungen ab und ist auch zum großen Teil Geschmacksache. Erlauben die Sicherheitsanforderungen es, dass Teams die Definition von APIs der jeweils anderen sehen dürfen? In welchem Ausmaß haben die Teams die Kontrolle über eigene APIs und dürfen von den Funktionalitäten des API Managements Gebrauch machen?

Möglichkeit 1 bedeutet, dass die gesamte Konfiguration vom API Management in, zum Beispiel, einem Git-repository liegt, auf das  die Teams Zugriff haben. Jedes Team würde im Laufe seiner Entwicklungsphasen Änderungen des API Management vorschlagen. Eine Änderung könnte beinhalten, eine weitere API hinzuzufügen oder zu entfernen, könnte aber auch beinhalten, dass bestimmte Protokolle oder Zertifikate verwendet werden müssen. Team A, welches dafür zuständig ist, das API Management und die APIs sauber und sicher zu halten, würde die vorgeschlagenen Änderungen kontrollieren und evaluieren ob die Änderungen auch andere APIs beeinflussen würden. Wenn die Änderung akzeptabel ist, würde die neue Version des Systems oder der Konfiguration angewandt werden.

Möglichkeit 2 entzieht den Teams das Recht, API Management-weite Änderungen zu unternehmen. Die Teams dürfen APIs anlegen, können jedoch nicht mehr konfigurieren, ob das gesamte API Management zum Beispiel isoliert in einem V-netz ist oder nicht. Diese Entscheidung bleibt Team A vorbehalten.

Möglichkeit 3 limitiert die Rechte der Teams weiter. Team A ist in voller Kontrolle des Systems und stellt eine API bereit, die es den Entwicklungsteams ermöglicht ihre API in dem System zu erstellen. Wie diese API aussieht und welche Kontrollmechanismen angewandt werden, um nur sichere APIs in dem System zu erlauben ist Team A überlassen.

Auch wenn diese Methode die höchsten Sicherheitsvorkehrungen erlaubt, ist das Team jedoch so weit eingeschränkt, dass dies einen starken Einfluss auf die Geschwindigkeit hat.


Fazit

Wie ein API Management oder die APIs provisioniert und verwaltet werden sollten hängt stark von den Anforderungen der Firma ab. Dieser Prozess sollte mit dem Zweck des API Managements übereinstimmen. Unterliegen die APIs besonderen Sicherheitsauflagen, die eine unternehmensweite Transparenz nicht erlaubt, dann empfehle ich ein zentralisiertes API Management, welches den Teams nur via einer kontrollierenden API erlaubt, APIs zu konfigurieren. Der Vorteil ist, dass so sichergestellt werden kann, dass APIs sicher sind und auch sicher sind vor unternehminternen Risiken.

Dies ist jedoch meist eine Extremsituation und trifft bei weitem nicht auf alle Firmen zu. Für die Unternehmen, die nicht diesen Auflagen unterliegen, empfehle ich Möglichkeit 1; die Verwendung von Konfigurations-Versionierung eines zentralen API Managements. Dies maximiert Kostenersparnis und gibt zentralisiert Kontrolle über die APIs. API-Strategien können so leichter verfolgt werden.

Wenn man sich gegen die Verwendung von einem zentralisierten API Managements entscheidet umso die Geschwindigkeit der Entwickler-Teams zu erhöhen stellen sich wiederum andere Fragen. Wie verschaffen wir trotzdem eine gute Transparenz innerhalb des Unternehmens, um die Wiederverwendung von bestehenden APIs zu fördern? Darauf werde ich später in dieser Serie auch noch eingehen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

API Management - Teil 4 - API-Sicherheit

Veröffentlicht am 21.08.2020 von Hieronymus Deutsch , APIM

Dieser Artikel ist Teil einer Serie zu API Management. Ziel der Serie ist es, meine Sicht darauf zu geben wie API Management im Enterprise-Kontext eingesetzt werden kann. Es werden also mit jedem Artikel Themen angesprochen, die eine Komplexität aufdeckt, mit der sich Unternehmen auseinandersetzen sollten. In diesem Teil, der vierte, gehe ich auf Sicherheitsaspekte ein.


Was ist „API-Sicherheit“

APIs sind, wie auch schon im Teil 2 der Serie erwähnt, wichtiger Teil einer Geschäftsstrategie in allen Branchen, und dieser Trend scheint nicht so schnell nachzulassen, insbesondere mit dem Aufstieg von IoT.

Die Zahl der öffentlichen APIs, die auf „ProgrammableWeb“ gelistet sind, liegt bei etwa 25.000, während die Zahl der privaten APIs um vieles höher ist als die Zahl der öffentlichen APIs. Diese Zahl wird auch weiter wachsen wie eine Studie von RapidAPI ergibt (Quelle: https://rapidapi.com/blog/rapidapi-developer-survey-insights/). Die gleiche Studie zeigt auch, dass die Zahl der APIs die in einer Firma verwendet werden mit der Größe des Unternehmens ansteigt.

Das sind eine Menge Daten, die über das Internet oder Netzwerk weitergeleitet werden, einige davon sind vertraulich.

Wie kann man also sicherstellen, dass die eigene Firma nicht auf die Liste der Unternehmen kommt, die von erfolgreichen Angriffen betroffen waren?


Viele Blickwinkel auf „Sicherheit“

Wenn man den Zugriff auf APIs sichern möchte, dann muss man sich nicht nur mit der Zugriffssteuerung beschäftigen, sondern auch mit der Sicherung der Umgebung, in der sich die API aufhält. Themen, die also betrachtet werden sollten, sind:

  • Verbindungen direkt oder über das Internet
  • IP white/black-listing
  • Isolierung und Sichtbarkeit der Endpunkte
  • Isolierung des Backends
  • Verschlüsselung der Verbindung
  • Zugriffssteuerung der Aufrufe
  • Zugriffssteuerung auf das Developer-Portal
  • Autorisierung der Aufrufer
  • Authentifizierung der Aufrufer
  • Ausfallsicherung und Load-Balancing
  • Absicherung nach OWASP regeln
  • DDoS Absicherung
  • Etc.


Rolle des API Managements 

Sicherheit ist ein wesentliches Element jeder Anwendung, insbesondere im Hinblick auf APIs, die täglich von Hunderten oder Tausenden von Anwendungen aufgerufen werden. Möglicherweise beseitigt ein API-Management System zwar nicht alle Bedrohungen, aber es kann Sie gegen einige der häufigsten Bedrohungen schützen. Wenn es als Proxy verwendet wird, kann es bösartige Angriffe auf Systeme verhindern. Viele der Sicherheitsmaßnahmen müssen jedoch konfiguriert und auch schon beim Aufsetzen des API Management Systems implementiert werden.

Der erste und fundamentalste Weg durch den das API Management die API schützen kann, ist die Vergabe von Autorisierungs-Schlüsseln, auch „Subscription keys“ genannt. Dieser Schlüssel muss bei jedem Aufruf der API im Header vorhanden sein. Aufrufe, die diesen Schlüssel nicht besitzen, werden bereits vom API Management abgefangen. Es entsteht also keine unnötige Last auf Seiten des Backends.So wie Requests abgefangen werden, die nicht den richtigen Subscription-Key haben, können auch andere Merkmale über „Policies“ konfiguriert werden, die nicht akzeptiert sind. Diese könnten zum Beispiel sein: IP-Bereiche, Größe des Requests, bestimmte Inhalte, Häufigkeit der Requests innerhalb eines Zeitrahmens und viele mehr.

Auch die am häufigsten und auch die nicht so häufig verwendeten Autorisierungsmethoden können bereits im API Management System angewandt werden. OAUTH und Client Certificates sind die am häufigsten verwendeten. Im Folgenden ein Beispiel wie eine solche Konfiguration aussehen könnte. Dieser Policy-Ausschnitt überprüft das Client Certificate, ob es im System hinterlegt ist:


<choose>

<when condition="@(context.Request.Certificate == null || !context.Deployment.Certificates.Any(c => c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >

<return-response>

<set-status code="403" reason="Invalid client certificate" />

</return-response>

</when>

</choose>

Policies geben dem/r API-Manager/in oder den Entwicklern die Möglichkeit, viele Aspekte der API zu konfigurieren, ohne dass ein Request erst zum Backend weitergeleitet werden muss. Das macht die API nicht nur performanter, sondern limitiert auch den Bereich, in dem neue Sicherheits-mechanismen angewandt werden müssen. So muss zum Beispiel nur im API Management das Zertifikat erneuert werden im Gegensatz zu jedem einzelnem Backend-Service.


Rolle der Systemumgebung & Architektur

Auch wenn die Zugriffssteuerung auf die API selbst essenziell ist, gibt es doch auch andere Risiken, die sich auf die Sicherheit und Verfügbarkeit einer API und das gesamte System auswirken. So könnte durch mögliche Infrastruktur-Probleme, Kriege, Naturkatastrophen und Vielem mehr das Rechenzentrum, in dem der Service oder das API Management laufen, ausfallen. Dies würde nicht direkt unbefugten Zugriff auf Daten erlauben, die unterbrochene Verfügbarkeit der Services könnte jedoch Auswirkungen auf die konsumierenden Systeme haben und somit auf den gesamten Wertschöpfungsprozess. Es ist demnach auch wichtig, die Systemverfügbarkeit sicherzustellen.

Dies kann ermöglicht werden indem kritische Systeme über mehrere Regionen hinweg verfügbar gemacht werden. Meist ist bei solchen Szenarien ein Loadbalancer gefragt um die Requests and den richtigen backend-service weiterzuleiten. API Management kann hier als einfacher Load-balancer fungieren. Eine weitere Möglichkeit, die den Service beinträchtigen kann, ist, wenn es mehr API-Aufrufe gibt als der Service bearbeiten kann. Das kann passieren, wenn der Service zu bestimmten Zeiten besonders häufig aufgerufen wird, oder wenn absichtlich jemand versucht, das System auf diese Weise lahm zu legen (Stichwort DDoS).

Um dieses Risiko zu minimieren, kann man vor einem API Management einen Service platzieren der Requests nach OWASP und Firewall Regeln prüft und auch automatisch DDoS Attacken erkennen und verhindern kann. Diese Services werden meist als Gateways bezeichnet. Im Azure gibt es für diese Funktion „Azure Front Door“ und auch das „Application Gateway“.


Logging, Analyse und Audit

Sicher zu sein ist gut, sicher zu bleiben ist jedoch auch eine Herausforderung. Anfragen sollten zurück verfolgbar sein, um nicht nur den staatlichen Regularien genüge zu leisten, sondern auch um eventuell mistrauen erweckende Verhalten von Konsumenten früh zu erkennen. Wenn ein Konsument zum Beispiel untypisch viele Daten über die API herunterlädt, dann könnte das ein Anzeichen dafür sein, dass dieser Schaden verursachen möchte.

API Management Systeme bieten meist eine umfassende Prüfungsmöglichkeit aller eingehenden Anfragen, jedoch nur für eine Teilmenge. Wenn ein vollständiges Audit oder verschiedene Rückverfolgungsdetails erforderlich sind, kann APIM so konfiguriert werden, dass diese Details an einen Logger weitergeleitet werden. Aus Performance-Gründen publiziert der Logger normalerweise an einen Event Hub. Es können Abonnenten des Event Hubs eingerichtet werden z.B: Azure Table Storage, Stream Analytics, PowerBI und Azure Machine Learning.


Fazit

Die Sicherheit von APIs ist nicht nur darauf beschränkt, ob ein Konsument der API ein Passwort braucht oder nicht. Es sollten alle Schichten des OSI Models in Betracht gezogen werden, wenn eine sicher API erstellt werden soll. Natürlich ist die Anforderung an die Sicherheit der API von Fall zu Fall unterschiedlich und meist wird der einfachste Weg gesucht, die API so gut wie möglich zu sichern. Hierbei sollte man sich ein API Management genau anschauen, da es mit Policies und Zugriffsbeschränkungen ein umfangreiches Tooling bereitstellt, um APIs zu sichern.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

API Management - Teil 3 - Life Cycle und warum eine API-Strategie wichtig ist

Veröffentlicht am 30.06.2020 von Hieronymus Deutsch , APIM

Dies ist der dritte Artikel über API Management in großen Unternehmen. Ziel der Reihe ist, Einblick in die vielen Aspekte und Themen zu gewähren, mit denen sich eine größere Firma mit besonderen Anforderungen auseinandersetzt. In diesem Artikel werde ich auf den Lebenszyklus von APIs eingehen.


Lebenszyklus von APIs

Häufig spricht man, wenn über den Lebenszyklus von APIs gesprochen wird, auch über den Prozess der API-Entwicklung. Beides ist sehr eng miteinander verknüpft. Generell spricht man meist von Aktivitäten, die in eine der vier Hauptphasen fallen: Entwickeln, Veröffentlichen, Verwalten und Entfernen. Jeder dieser Schritte kann beliebig tief detailliert werden.

Entwicklung beinhaltet Aspekte wie Technologie, Sicherheit, Provisionierung und Deployment-Automatisierung. Ebenfalls zu betrachten ist, und das wird häufig vernachlässigt, die Dokumentation der API oder auch das Testen im weiteren Sinne (eg: Mock, Load- und Penetration Test). Entwickler-, Design-, und Strategieleitfäden gehören hier ebenfalls dazu.

Veröffentlichen umfasst nicht allein die Aktion, eine API bereitzustellen. Hier könnte man auch in Betracht ziehen, eine API öffentlich oder intern zu monetarisieren, um eine neue Einkommensquelle für die Firma zu schaffen. In den meisten Fällen, wenn eine API wiederverwendbar zur Nutzung angeboten wird, ergibt sich das Problem wie die Kosten die Services gedeckt oder aufgeteilt werden sollen. Interne Monetarisierung, also die nutzungsbasierte Bezahlung, wäre hierfür eine saubere Lösung wenn die Dimensionen, wie Anzahl der APIs, Verursachte Last, Anzahl der Operationen, und viele mehr, dabei beachtet werden.

Analysieren der Verwendung von APIs ist ein wichtiger Teil des Lebenszyklus, der nicht zu unterschätzen ist. Mit Statistiken zu vielen verschiedenen Metriken, wie Latenzen, Peak-Zeiten, Requesthäufigkeit und ähnlichem können die Services optimiert, angepasst und Probleme schnell behoben werden.

Entfernen von APIs ist häufiger nötig als man denkt. Das liegt daran, dass sich die Services meist weiterentwickelt haben und die veraltete Version nicht mehr verwendet wird. Es ist daher angebracht, auch hierfür einen sauberen Prozess anzulegen, der möglichst automatisch angestoßen wird, um die API-Landschaft sauber zu halten (bspw. Einen Alarmsetzen, der Benachrichtigt, wenn APIs länger als drei Monate nicht verwendet werden).


better

Abbildung 1 - API Lebenszyklus


Weitere Aspekte der einzelnen Phasen

Entwicklung

1. Entwicklung: Sobald eine solide Strategie und einen solider Plan verfügbar ist, kann die API erstellt werden.

2. Testen: Vor der Veröffentlichung ist es wichtig, API-Tests abzuschließen, um sicherzustellen, dass sie die Leistungs-, Funktionalitäts- und Sicherheitserwartungen erfüllen.

3. Sicherung: Sicherheitsrisiken und -bedenken sind heute ein häufiges Problem. Auf technischer Ebene kann API Management Tooling behilflich sein. Jedoch auch auf Prozessebene muss die Sicherheit sichergestellt werden. Beispielsweise durch Verwendung von sauber implementierten Dev-Ops Prozessen.


Veröffentlichen

1. Veröffentlichen: Nach dem Testen ist es an der Zeit, die API zu veröffentlichen, um für Entwickler verfügbar zu werden. Das Developer Portal stellt diese dann zur Verfügung.

2. Vermarktung: Es gibt mehrere Möglichkeiten, Ihre API zu vermarkten, einschließlich der Auflistung in einem API-Marktplatz wie RapidAPI. Das Developer Portal kann als firmeneigenes Portal dienen.

3. Monetarisieren: Es besteht die Wahl APIs kostenlos intern oder extern anzubieten. Wenn es eine Gelegenheit dafür gibt, können APIs auch monetarisiert und so zusätzliche Einnahmen für das Unternehmen erzielt werden.

4. Onboarding: Wenn APIs für den öffentlichen oder privaten Verbrauch angeboten werden, ist Onboarding eine wichtige Komponente, damit Entwickler die wichtigsten Funktionen verstehen. Eine gute Dokumentation ist hierfür ausschlaggebend. Wie eine solche auszusehen hat sollte firmenweit definiert sein.


Verwalten

1. Verwalten: Nach der Veröffentlichung müssen Entwickler die APIs auch verwalten, um sicherzustellen, dass sie auf dem neuesten Stand sind und die Integrität Ihrer APIs nicht beeinträchtigt wird.

2. Analysieren: Ihre APIs sind live, aber wie funktionieren sie? API-Trafik Analyse hilft Ihnen, Ihr digitales Geschäft zu verstehen und Anomalien zu erfassen, bevor sie sich auf Ihr Unternehmen auswirken.


Ruhestand

1. Ruhestand: Der Ruhestand von APIs ist die letzte Phase eines API-Lebenszyklus und geschieht aus einer Vielzahl von Gründen, einschließlich Technologieänderungen und Sicherheitsbedenken.


Eine Strategie ist ausschlaggebend für ein erfolgreiches Lifecycle Management

Bereits im vorherigen Teil der Blog-Serie habe ich bekräftigt, dass APIs nicht nur als Mittel zum Zweck gesehen werden sollen, sondern auch in die Unternehmensstrategie einfließen können.

Wenn man den Lebenszyklus betrachtet sieht man, dass an vielen Stellen eine Unternehmensstrategie angeraten ist, um sicher und einheitlich APIs zu veröffentlichen und zu verwenden. Eine Strategie sollte demnach aus mehreren Blickwinkeln betrachtet werden. Entwicklungs-Vorschriften, Sicherheitsanforderungen, Kostenverteilungsplan, Minimum service lifetime Versprechen, und vieles mehr. Die Wiederverwendung von bestehenden APIs muss politisch motiviert werden, da sonst die Entstehung von Insellösungen nicht verhindert wird und „Digitale Schulden“ entstehen. Digitale Schulden sind Kosten, die an einem späteren Zeitpunkt anfallen, wenn Fehlentscheidungen und falsche Verwendung von Lösungen nachträglich korrigiert werden müssen.


Fazit

Der Lebenszyklus von APIs unterscheidet sich wenig vom Lebenszyklus anderer Lösungen. Es ist auf Grund ihrer Schnittstellenfunktion ungemein wichtig, diesen klar definiert zu haben. Eine API Strategie ist hier eine Voraussetzung dafür da viele Aspekte unternehmensweit relevant sind.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

API Management - Teil 2 - APIs als Produkt

Veröffentlicht am 12.05.2020 von Hieronymus Deutsch , APIM

In diesem Artikel gehe ich auf eine häufig verwendete (ich möchte sagen „Vorurteil“) Rolle von APIs (Application Programming Interface bzw. Anwendungsschnittstelle) ein, in der sie als reine Middleware deklariert werden. Ich erkläre, dass APIs als Produkte behandelt werden sollten und was die daraus resultierenden Vorteile sind. Dieser Artikel gehört zu einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe, ist meine Sicht auf API Management zu geben, wie es im Enterprise-Kontext eingesetzt werden kann.


API-Lösungen und API-Produkte

Es gibt zwei Arten von APIs, API-Lösungen und API-Produkte.

Eine API-Lösung besteht aus einer oder mehreren APIs, die ein Integrationsproblem lösen. Genauer gesagt werden API-Lösungen eingesetzt, um direkte Kommunikation zwischen Computersystemen zu ermöglichen. Ein Beispiel hierfür könnte eine Situation sein, in der Kundendaten in mehreren Geschäftsbereichen, oder auch Silos, ausgetauscht werden müssen.

Ein API-Produkt besteht ebenfalls aus einer oder mehreren APIs, die jedoch eine Schnittstelle zu einem Wertversprechen bereitstellen. Mit anderen Worten, ein API-Produkt besteht aus Value Proposition-Schnittstellen. Um das obere Beispiel weiterzuführen, könnte ein API-Produkt unternehmensglobale Kundendaten zur Verfügung stellen, damit diese intern verwendet werden können.


API-Produkte sind mehr als Middleware

API-Lösungen sind also APIs die speziell für einen einzelnen Integrationsfall erstellt wurden. In diesem Fall erfüllen sie die Definition als Middleware, sie vermitteln zwischen Programmen um die Komplexität dieser zu verbergen. Viele Legacy-Architekturen auf diese Weise gewachsen. Aber APIs als reine Integrationstechnologie zu betrachten wäre ein Fehler, da der größte Teil des Mehrwertes, den APIs bieten können, ignoriert werden würde. Durch sie werden Werte im modernen Geschäft ausgetauscht. Dies macht APIs auch zur Sache der Geschäftsführung und Strategieentscheider. APIs sind allein Sache der IT-Abteilung.

Bei API-Lösungen, wie auch bei API-Produkten kann man den Konsumenten der API als intern oder extern klassifizieren. In der Welt der APIs ist ein Verbraucher einfach jeder, der einen Dienst nutzt, unabhängig davon ob er bezahlt wird oder nicht. Ein externer Verbraucher ist genau das, ein Dritter, der außerhalb der Unternehmenseinheit die API oder den Dienst, der durch eine API bereitgestellt wird, nutzt. Ein interner Verbraucher ist jedoch jemand, der innerhalb des Geschäftsbereichs existiert. Dies sind also Teams die unternehmensinternen Lösungen und Integrationen schaffen. Dies wird durch das untere Bild illustriert:

clip_image002Abbildung 1: externe vs interne Verbraucher


API sind nicht ein reines IT-Thema

Aus geschäftlicher Sicht steckt hinter jeder Transaktion ein Mehrwert, unabhängig von der Art der Datenverarbeitung oder ob sie den Umsatz direkt steigert. Es ist demnach nicht weithergeholt, wenn APIs als Produkt verwaltet werden, um so neue umsatzorientierte Einnahmequellen zu schaffen. Aus diesem Grund ist es wichtig, APIs als Geschäftsressource /Assets und nicht als amorphe Codebasis zu sehen. APIs sind also nicht nur Sache der IT-Abteilung.

50% of Salesforce transactions are done through their API.source

Viele betrachten API-Produkte jedoch als Dinge, die große Internetunternehmen verwenden, um Ökosysteme rund um ihre Dienste zu erstellen. Konsistent gestaltete RESTful-APIs tragen jedoch auch intern dazu bei, direkte Kosten und auch Opportunitätskosten zu sparen, die eine mehrfach wiederholte Entwicklung von API-Lösungen mit sich bringt. In größeren Unternehmen ist es häufig der Fall, dass für Integrationsprojekte neue API-Lösungen erstellt werden. Wiederholt sich der Integrationsbedarf des gleichen Backendsystems, wird wieder eine neue Lösung geschaffen. In solchen Fällen treibt ein API-Produkt die Idee der Wiederverwendbarkeit von Schnittstellen voran, indem es zahlreiche API-Ressourcen in Pakete sammelt, die auf die Bedürfnisse verschiedener Entwicklergemeinschaften zugeschnitten sind.

Wie bereits erwähnt, sind die Benutzer eines API-Produkts interne oder externe Verbraucher, die Dienste oder Integrationen erstellen, sei es für Kunden, für Mitarbeiter oder um Automatisierung und Effizienz zu erhöhen. APIs sind also eine Möglichkeit für Unternehmen, die Entwicklung zu beschleunigen und die Effizienz in Wochen oder Monaten, nicht in Jahren zu verbessern.


Fazit

Das Label der Middleware bleibt in größeren Unternehmen jedoch meist bestehen. Es gibt viele Gründe dafür: Legacy-Architekturen, Monolithic Applications und traditionelle Integrations- und Entwicklungstechniken, die alle dazu neigen, APIs als reines Mittel zum Zweck zu sehen.

In vielen Unternehmen ist diese Verwendung tief verwurzelt und wird demnach weiterhin gelebt und umgesetzt. Was bei einer API-Produktstrategie zu bedenken ist, betrachten wir später in dieser Serie zu API Management.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Der versteckte Teil des Eisbergs: API Management in großen Unternehmen - Teil 1 - Generelle Übersicht

Veröffentlicht am 27.03.2020 von Hieronymus Deutsch , APIM , Azure , Enterprise


Dieser Artikel ist der Erste in einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe ist es meine Sicht darauf zu geben, wie API Management im Enterprise-Kontext eingesetzt werden kann.


Die Rolle des API Managements (APIM)

Das API-Management ist der Prozess der Überwachung von Application Programming Interfaces (APIs) in einer sicheren, skalierbaren Umgebung. Das Ziel von des API Managements ist es den Lebenszyclus und die Verwendung einer API zu überwachen. Sie können so sicherstellen, dass Anforderungen von Entwicklern eingehalten werden.[1]

Um diesen Prozess zu unterstützen haben viele Unternehmen eine Softwarelösung geschaffen. Gartner hat diese am 09.Oktober 2019 in einem Magic Quadrant for Full Life Cycle API Management bewertet. Zu den „Leaders“ gehören unter anderem:

· AWS (Amazon Web Services)

· Google (mit Apigee)

· Microsoft (Azure API Management)

· Uvm.

Für technische Beispiele im Laufe der Blog-Serie zu API Management werde ich Azure API Management von Microsoft verwenden. Die meisten Konzepte sind jedoch meist problemlos übertragbar auf andere Anbieter.

Wenn das API-Management in einem Unternehmen richtig implementiert ist, führt es zu folgenden Ergebnissen:

· besser verwaltete Entwickler-Community

· gute Kontrolle über die API-Verwendung

· Entdecken von potenziellen Monetarisierungsmöglichkeiten

· robuster Sicherheits- und Governance-Prozess

· Geldeinsparung durch Vermeidung von Neuentwicklungen


Aufbau eines API Management Systems

Häufig sieht man, dass die Systeme von der logischen Architektur her aufgeteilt sind in einen API Developer und in einen API-Konsumenten fokussierten Teil; auch wenn diese Parteien nicht überall gleich benannt sind.

clip_image002

Figure 1: Architektur eines API Managements (Azure APIM). Quelle: azure.microsoft.com/en-us/services/api-management

Der Grund für diese Aufteilung liegt nicht nur in der zweiseitigen Natur von APIs. Ziel ist auch APIs, je nach Unternehmensstrategie verfügbar, auffindbar und insbesondere wiederverwendbar zu machen. In einem späteren Artikel werde ich näher auf die Best-Practices von API Management eingehen. So „stay tuned“!


API Gateway

Das API-Gateway ist der Endpunkt, der folgende Aufgaben übernimmt:

· Akzeptieren von API-Aufrufen und Weiterleiten dieser Aufrufe an Ihre Back-Ends

· Überprüfen von API-Schlüsseln, JWT-Token, Zertifikaten und anderen Anmeldeinformationen

· Erzwingen von Nutzungskontingenten und Übertragungsratenlimits

· Dynamisches Transformieren Ihrer API ohne Codeänderungen

· Zwischenspeichern von Back-End-Antworten, falls eingerichtet

· Protokollieren von Aufrufmetadaten zu Analysezwecken


Developer Portal

Das Developer Portal dient als wichtigste Webpräsenz für Veröffentlicher von APIs und als wichtigste Informationsquelle für Konsumenten/Entwickler. Es ermöglicht Folgendes:

· Lesen der API-Dokumentation

· Ausprobieren einer API mithilfe der interaktiven Konsole

· Erstellen eines Kontos und Anfordern von API-Zugriffsdaten

· Zugriff auf Nutzungsanalysen


Management Plane

Diese Oberfläche ist die Verwaltungsebene, über die das “API Management” durch die API-Administratoren verwaltet wird. Dazu gehört unter anderem:

· Definieren oder Importieren des API-Schemas

· Paketieren von APIs in Produkten

· Konfigurieren von Richtlinien wie z. B. Kontingenten oder Transformationen für die APIs

· Gewinnen von Erkenntnissen mithilfe von Analysen

· Verwalten von Benutzern


Sicherheit

Mit dem API Management lassen sich die backend-Services schützen. Eine typische Aufgabe ist die des „Edge“ Gateways, das zwischen Unternehmen und dem Internet typischerweise in einer demilitarisierten Zone (DMZ) angesiedelt ist. Ein API-Gateway kann Konsumenten authentifizieren und Anfragen autorisieren. Das Format und der Inhalt von Anfragen kann gegen Formatbeschreibungen (Schema) geprüft (validiert) werden. Die Transportverschlüsselung mit TLS bzw. SSL kann ebenfalls ein API Gateway übernehmen. Dadurch können sogar nicht explizit abgesicherte APIs sicher zur Nutzung angeboten werden.


Monitoring

Da das Gateway, wie der Name bereits vermuten lässt, die Anfragen entgegennimmt und validiert, werden dabei Metriken erfasst. Standartmäßig werden Last auf das Gateway, Anzahl der Verbindungen, Verfügbarkeit und Antwortzeiten erfasst. Diese werden in der Management Plane visualisiert. Es ist hier dann möglich „Alarme“ basierend auf den Metriken zu erstellen, um zum Beispiel schnell über kritische Probleme informiert zu werden.


Logging

Es ist möglich Logeinträge für alle Aufrufe des Gateways zu schreiben. Meist ist es jedoch üblich die Logs für einzelne APIs und Operationen zu gesonderten Log-Umgebungen zu senden, damit jeder API-Entwickler gesondert auf die für ihn relevanten Logs Zugriff hat.

 

Routing

Aufrufe können vom API Management Gateway an verschiedene Systeme weitergeleitet werden. Diese Regeln können den Inhalt des Aufrufes verwenden, um beispielsweise Aufrufe an verschiedene Versionen des Backendsystems zu senden.


Transformation

Häufig möchte man nicht, dass das Datenformat des Back-Ends auch in den Aufrufen verwendet wird. Hierfür bietet das API Management eine Funktion an, die es ermöglicht den Inhalt der Aufrufe zu transformieren, um Back-End-kompatibel zu sein.


Access Management

Durch die Aufteilung in API-Entwickler und API-Konsumenten ist das Zugriffsmanagement ähnlich aufgeteilt. So kann man beiden Gruppen in ihrem Bereich getrennt per RBAC (Role Based access controll) Zugriff auf die APIs geben.

Damit kann man genau definieren welcher Konsument welche APIs oder API-Produkte sehen darf und auf API-Entwickler Seite ebenso kontrollieren wer welche Eigenschaften einer API verändern darf.


Abrechnung/Monetarisierung

Für viele Firmen gehört es dazu die Nutzung von APIs an ein Bezahl-Model zu koppeln. Zur Limitierung der Anzahl an Aufrufen pro Konsumenten bieten API Management Systeme entsprechende Funktionalität an. Dadurch müssen solch aufwändig zu implementierende Limitierungen nicht in den Back-End APIs implementiert werden.


Fazit

Wenn du es bis hierhin geschafft hast, hast du ein gutes Grundverständnis erlangt um nun in jedes einzelne Thema gesondert einsteigen zu können.

Ein API Management als Tool ist vielseitig und gibt eine breite Palette an Funktionen vor, die von Unternehmen verwendet werden können, um nicht nur APIs zu sichern und zu verwalten, sondern auch um eine Strategie zu verfolgen, die über ein “einfaches Verwalten” von APIs hinausgeht.

Im Laufe der Serie plane ich unter anderem die folgenden Aspekte zu betrachten:

· APIs als Produkte

· API Live-Cycle

· Policy

· Monitoring & Logging

· Sicherheit

· Routing

· APIM mit Microservices oder Serverless

· …


[1] searchsoa.techtarget.com/definition/API-management

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Große Bilder dynamisch in PowerBI Reports verwenden

Veröffentlicht am 21.02.2020 von Ireen Raue , PowerBI

Grafiken oder Bilder mit einer guten Qualität und damit auch Größe austauschbar in einem PowerBI Report darzustellen ist durch die begrenzte Spaltengröße beim Laden der Daten gar nicht so einfach. Mit einem kleinen Trick lassen sich aber auch große Bilder dynamisch aus einer Datenbank laden.Wie ich dabei vorgegangen bin, möchte ich in diesem Artikel detailliert vorstellen.


Vorbereitung

Leider gibt es eine Größenbeschränkung für die als Datasource festgelegten Spalten. Die Spalten dürfen also eine bestimmte Größe nicht überschreiten, wodurch man auf dem im Artikel Dynamische Bilder in PowerBI beschriebenen Weg nur kleine Bilder verwenden kann.

Mein hier gezeigtes Beispiel setzt auf den in dem Artikel Dynamische Bilder in Power BI angelegten Daten auf.

Ich werde ein Projektlogo dynamisch hinzufügen. Das Logo hat aber eine Größe deutlich über 20 KB. Die Lösung ist es, das Image in viele kleine Teile zu zerlegen, sodass es pro Logo mehrere Imageteile gibt.

Für mein Beispiel habe ich folgende Tabellen hinzugefügt:

1

In der Project Tabelle wird die LogoID hinzugefügt.

2

Die Logos werden angelegt und den Projekten hinzugefügt.

Mit dem unten angegebenen Code wird das Logoimage zerlegt und in kleinen Teilen in der Tabelle LogoImage abgelegt. Der Index ist hier die Reihenfolge, in der das Bild hinterher wieder zusammengesetzt werden muss.

Textfeld

PowerBI Report

Im Report wird eine zweite Seite für die Projectdetails angelegt und dann muss die Datenquelle anpassen werden. Dafür gehen ich auf Edit Queries.

1

Die Tabellen Logo und LogoImage hinzufügen.

2

Für die Spalte mit den Bilddaten muss der Datentyp auf Text geändert werden.

3

Mit Close and Apply speichern.

In der Reportansicht muss der Logo-Tabelle ein neues Measure hinzugefügt werden

4


New Measure:

Textfeld


4

Nun kann der Detail-Report gebaut werden. Um das Logo hinzuzufügen, wird vom Marketplace ein Image Visual benötigt. Das simple Image hat hierfür leider nicht funktioniert. Ich habe Image by CloudScope verwendet.

5

Und als Ergebnis erscheint dann das vollständige Logo, obwohl es größer als 20 KB ist.

7

Auf diese Weise können Bilder beliebiger Größe aus einer Datenbank in den Report geladen werden und der eigentliche Report braucht zum Beispiel beim Hinzufügen eines neuen Projektes nicht mehr angefasst und neu gepublished werden.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Mein Einstieg in die Welt der Microservices

Veröffentlicht am 17.01.2020 von Hasan Uzun

Als ich bei der eBiz Consulting GmbH anfing, bekam ich die Gelegenheit an einem internen Projekt zu arbeiten, in dem eine Microservices Architektur verwendet werden sollte. Das Projekt, die sogenannte „eBizConSuite“, ist eine Sammlung von Services für KMUs. Die eBiz selbst ist der erste Kunde dieser „eBizConSuite“. Die im Rahmen des Projektes erarbeitete Basisplattform („Digital Plattform“) soll zukünftig auch für andere Kundenanwendungen verwendet werden. Darüber hinaus haben wir das wichtige Ziel verfolgt, unser Wissen in aktuellen Microservices Technologien wie Kubernetes, Docker und .NET Core auf- und auszubauen. Dieses neue Wissen habe ich zu verschiedenen Gelegenheiten (z.B. Company Meetings und eBizTalks) an meine Kollegen und Kolleginnen in der eBiz weitergeben können.

Bevor ich mit dem Projekt beginnen konnte, habe ich das Best Practices Beispielprojekt "eShopOnContainers" von Microsoft (siehe https://github.com/dotnet-architecture/eShopOnContainers) analysiert und schließlich die Erfahrungen aus diesem Projekt für uns immer wieder als Referenz herangezogen. Es war für mich sehr hilfreich, ein solches Best Practices Projekt vorliegen zu haben, um die Grundlagen der Microservices Architektur zu verstehen, da ich zu diesem Zeitpunkt noch relativ wenig Wissen dazu hatte.

clip_image002

Abbildung 1: Monolithische Architekturen und Microservices Architekturen

Nachdem ich mir das Projekt "eShopOnContainers" angesehen hatte, hatte ich das Gefühl mich auf einem anderen Planeten zu befinden. Bis dahin hatte ich nur mit monolithischen Architekturen gearbeitet, in denen typischerweise fast alle Softwarekomponenten in einer Gesamtanwendung zusammengefasst waren. Aber in Microservices Architekturen sind diese Komponenten einer Anwendung durch bestimmte logische (meistens fachliche Kriterien, manchmal technische Kriterien) Kriterien getrennt, so wie es im obigen Bild (Abbildung 1) grob dargestellt ist.

Diese Komponenten (=Microservices) sind autonom und laufen unabhängig voneinander. Dieser Unterschied wirkt sich auf viele Bereiche aus, wie z.B. auf die zu verwendenden Tools und Bibliotheken. Zum Beispiel das Konzept der „Containerisierung“, das Kubernetes-Ökosystem oder die Notwendigkeit der Nutzung eines Service Bus sind ganz neue relevante Bereiche.

Daher dauerte es einige Wochen, bis ich diese neue Architektur und die Komponenten in diesem Umfeld richtig verstanden hatte.

Nachdem die neu erstellten Microservices mit Hilfe von Docker-Compose erfolgreich in der lokalen Umgebung entwickelt und debugged wurden, stellte sich das Deployment der Anwendung in Kubernetes ebenfalls als eine Herausforderung dar, die es zu nehmen galt.

Die Herausforderung, die Deployment Konfiguration mit YAML zu formulieren ergab sich aufgrund der vielen Funktionen und Einstellungen, die man in einer Kubernetes Umgebung vornehmen kann und beachten muss. Aber nachdem es einmal funktionierte, war es erstaunlich zu sehen, wie mächtig Kubernetes ist. Dazu gehört die Replikation und das Load Balancing von Services, die Health Checks, usw.. All dies dient dazu minimale Ausfallzeiten der Services und damit der Gesamtanwendung sicherzustellen.

Rückblickend betrachtet bin ich sehr zufrieden damit, dass ich mich mit diesen modernen Technologien und der Microservices Architektur beschäftigen konnte und habe dabei viele neue Erkenntnisse gewinnen können.

Obwohl ich einige Bereiche des Best Practices Projekts "eShopContainers" (z.B. Akzeptanz von Code-Redundanzen, minimale Codebasis usw.) zunächst als falsch empfunden habe, habe ich während meiner Lernphase die dahinterstehenden Gründe (aufgrund der Microservices Architektur) nach und nach verstanden. Es ist offensichtlich, dass Containerisierung zukünftig eine noch viel größere Bedeutung haben wird, und meiner Meinung nach wird Kubernetes die Rolle des führenden Orchestrierungstools und Hosting-Ökosystems weiter ausbauen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Dynamische Bilder in PowerBI

Veröffentlicht am 28.12.2019 von Ireen Raue , PowerBI

Bilder in einen PowerBI Report zu integrieren ist eine leichte Aufgabe. Die Bilder abhängig von z.B. einem Status einzubinden wird schon etwas kniffliger. In diesem Beitrag möchte ich zeigen, wie man kleine Bilder, die in einer Datenbank gespeichert sind, dynamisch in einen Report einfügt.

Vorbereitung

Als Beispiel erstelle ich einen Projektreport. Für das Anzeigen eines Status habe ich hier folgende Bilder erzeugt:

image

Die Größe je Bild liegt bei ca. 11KB. Auf Grund der Größenbeschränkung von 32766 Byte beim Laden einer Spalte in den Report dürfen die Bilder eine bestimmte Größe nicht überschreiten. Meine Erfahrung hier ist, dass das Bild kleiner 20 KB sein sollte. Alles was darüber liegt, wird obwohl es unterhalb der Größenbeschränkung liegt, abgeschnitten.

Diese Bilder möchte ich nun in meinem Report als Projektstatus anzeigen lassen. Dafür habe ich die folgenden Tabellen angelegt.

image

Die State-Tabelle habe ich dann mit den Bildern befüllt

image

Daraufhin habe ich ein paar Beispielprojekte angelegt.

image

Mit diesen Daten bekommt man sicher keinen ganzen Report gefüllt, aber ich denke, das Prinzip des dynamischen Anzeigens der Bilder wird deutlich.

PowerBI Report

Im PowerBI Desktop wird ein neuer Report geöffnet und die gerade angelegte Datenquelle ausgewählt.

image

Die zwei Tabellen Project and State werden ausgewählt.

image

An den Queries müssen nun noch ein paar kleine Anpassungen gemacht werden. Dafür muss Edit Queries geöffnet werden.

image

In der State-Tabelle wird der Datentyp des Bildes auf Text geändert.

image

Und eine neue Spalte wird hinzugefügt. Diese neue Spalte muss wie folgt aussehen:

image

image

Mit Close and Apply diesen Schritt abschließen.

image

Dann wird auf die Tabellenansicht gewechselt.

image

Dort wird die Data Category der neuen Spalte auf Image URL geändert.

image

Auf der ersten Reportseite wird dann eine Tabellenansicht mit den Projekdaten und dem Statusbild angelegt.

image

Das Ergebnis ist eine Übersicht der Projeke und der Status wird als Ampel dargestellt.

image

Wird ein neues Projekt hinzugefügt oder ein bestehendes geändert, ändert sich das Statusbild im Report automatisch. Man muss bei diesem Vorgehen nur beachten, dass die zu verwendenden Bilder die Größe von ca. 20 KB nicht überschreiten, da sie sonst durch die Spaltengrößenbeschränkung beim Laden in den Report abgeschnitten werden.

Wie man bei größeren Bildern vorgeht, folgt in einem nächsten Beitrag.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Erforsche deine Grenzen mit Azure Service Bus

Veröffentlicht am 19.11.2019 von Mahmoud Habiballah , Cloud , Integration , Azure , Service Bus

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.


clip_image002


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.

clip_image004

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.

clip_image006

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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Lust auf eine Projektsafari?

Veröffentlicht am 24.10.2019 von Julia Krause , PM , PMO , Buch

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.

image

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.

clip_image008

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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Mein Umstieg auf Git

Veröffentlicht am 27.09.2019 von Marcel Fey , SDLC , Development

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:

image

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):

image

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):

image

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.

image

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:

image

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

image

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
google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Stored Procedure mit Send Port aufrufen

Veröffentlicht am 21.08.2019 von Clemens Kruse , BizTalk , Integration , Pattern

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.

image

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

clip_image002

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":

image

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:

clip_image002

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

clip_image004

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

clip_image006

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

clip_image008

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:

clip_image010

Folgt man dem link, dann gelangt man zu…

clip_image012

Und schließlich zu…

clip_image014

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:

clip_image016

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

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:

clip_image018

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…]

clip_image020

hier wählen wir [Consume Adapter Service]:

clip_image022

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:

clip_image002[4]

  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:

clip_image004[4]

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

clip_image006[4]

clip_image008[4]

Und passen diese Instanz entsprechend dem Hinweis von Microsoft an…

clip_image010

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>

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

eBiz auf der Integrate 2019 in London

Veröffentlicht am 23.07.2019 von Alexander Müller

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!

MicrosoftTeams-image (3)

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:

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.

APIM-DevOps

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".

Azure Enterprise Integration

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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

PRINCE2 AgileFoundation

Veröffentlicht am 14.06.2019 von Julia Krause , PRINCE2 , Agile

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.

 Prince2

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

BizTalk - SOAP-Requests mit WS-Security

Veröffentlicht am 23.04.2019 von Jean-Pierre Pereira , BizTalk , Security , Integration

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.

clip_image002[5]

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:

image

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"
    image
  4. Den Unterordner "TLS 1.2" lässt man dabei unberührt. Stattdessen setzt man den Wert "Enabled" auf "1"
    image
  5. Wechsel zu "HKLM\SOFTWARE\Wow6432Node\Microsoft\ .NetFramework\v4.0.30319" und ein neues "DWORD-Value(32 bit)" erstellen
  6. a. Namen auf "SchUseStrongCrypto" setzen

    b. Im Inhalt steht der Wert 1

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

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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

"Der macht was mit Computern ..."

Veröffentlicht am 27.03.2019 von Igor Butorin
Kurze Buchrezension über „Folienkrieg und Bullshitbingo“ von Ewald F. Weiden

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.

BuchAls 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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Zur Enterprise Integration mit nur vier Microsoft-Technologien!

Veröffentlicht am 06.03.2019 von Robert Schlachta , Event , BizTalk , Azure , Integration

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!

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Azure Logic Apps und Continuous Integration

Veröffentlicht am 11.02.2019 von Andreas Kurka , Azure , Continuous Integration , Integration

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.

image

image

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.

image

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.

image

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.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Automatisierung eines OnBoarding-Prozesses

Veröffentlicht am 07.01.2019 von Clemens Kruse , BizTalk , Powershell , CRM , Dynamics365 , WCF , OAuth , Azure

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

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

eBiz@ PM Forum - DER Fachkongress für Projektmanagement in Europa

Veröffentlicht am 29.11.2018 von Julia Krause , Agile , Event , PM

Auf der Suche nach Weiterbildungsmöglichkeiten im Netz bin ich auf das PM Forum aufmerksam geworden. Ein Event speziell für Projektmanager? Das hat mich neugierig gemacht und ich habe mich mit der Veranstaltung auseinandergesetzt. Schnell war klar: Das kann für die Projektmanager in unserer Firma interessant sein.

Kurz zum PM Forum: Es ist das größte Projektmanager-Event Deutschlands und nach eigener Aussage “Der führende Fachkongress für Projektmanagement in Europa” mit ungefähr 1000 Teilnehmern und findet einmal jährlich in Nürnberg statt. Versprochen werden Trends, Innovation, Inspiration und Vernetzung innerhalb der deutschen PM-Community.

Tag 1, 23.10.2018:

1Nun war es soweit. Das Event stand vor der Türe. Von der eBiz waren der Projektmanager-Nachwuchs, Hieronymus und ich, dabei. Voller Motivation ging es also nach Nürnberg. Um 09:00 Uhr sollte es los gehen. Zuvor trafen wir uns aber zum Frühstück und stellten einen Plan für den Tag auf. Für uns standen folgende Fragen im Vordergrund: Wie möchten wir uns in der Projektwelt weiterentwickeln, welche Zertifizierung macht für uns Sinn? Dementsprechend wählten wir Vorträge und Workshops aus.

Dort angekommen waren wir von der Größe des Events beeindruckt. Zuerst liefen wir über das Event, um uns zurecht zu finden, was auch ziemlich schnell gelang. Die Vorträge konnten also starten! Da Hieronymus und ich verschiedene Interessensgebiete haben, teilten wir uns auf, um das bestmögliche für uns aus dem Event herauszuholen.

Mein erster besuchter Vortrag trug den Titel “90 Day´s Project”. Ein sehr spannendes Thema, wenn es darum geht klassische Projekte zu verkürzen und Agilität zu schaffen. Generell wurde auf diesem Forum das Thema agiles und auch hybrides Projektmanagement in den Vordergrund gebracht.

2

Es war sehr interessant zu sehen, dass viele klassische Projektmethoden in der Erarbeitungsphase einer agil angepassten Zertifizierung (IPMA Agile) sind, oder diese schon auf dem Markt haben (PRINCE 2 Agile).

In einem anderen erwähnenswerten Workshop wurde in 45 Minuten versucht Scrum spielerisch und vereinfacht darzustellen. Es gab einen groben Überblick über die Rollen des Product Owners, Scrum Masters und der Teammitglieder. Danach wurden Rollen und die zugehörigen Aufgaben verteilt. Jeder Gruppe wurde ein Stapel Aufgabenkarten vom Product Owner vorgelesen und die Teammitglieder inkl. Scrum Master mussten diese innerhalb von 5 Minuten nach ihrer Schwierigkeit bewerten. Nachdem alle Karten bewertet waren, hatte jedes Teammitglied Zeit, eine Prognose zu geben, wie viele und vor allem was für Karten (z.B. 10 Papierhüte bauen, 40 Zahlen addieren etc.) innerhalb von 10 Minuten geschafft werden können. Schon ging es darum die Aufgaben zu erledigen und sich gegenseitig auszuhelfen, wenn die eigenen Aufgaben schon vor Ablauf der Zeit erledigt waren. Hier wurden die Rollen von Scrum Master und Product Owner hervorgehoben: der Scrum Master konnte und durfte bei den Aufgaben helfen, der Product Owner nur beobachten, nicht aktiv mitarbeiten. Dieser Workshop brachte die Rollen spielerisch gut rüber und man konnte einen ersten Eindruck erhaschen.

3

Am ersten Tag war eine Abendveranstaltung geplant, die mit der „Blauen Stunde“ eingeleitet wurde. Die Blaue Stunde, die in Wahrheit zwei Stunden betrug, war als eine Art Einstimmung auf die Abendveranstaltung gedacht. An vielen Messeständen wurde Gimmicks angeboten, wie z.B. eine Cocktailbar (mit super leckeren Cocktails ), Fußballspielen gegen einen Roboter, eine Fotobox, verschiedene VR-Szenarien und noch vieles mehr.

Nach dieser Blauen Stunde fing dann die eigentliche Abendveranstaltung an. Es gab leckeres Essen, während ein kleines Programm abgehalten wurde, denn bei der Abendveranstaltung wurde auch noch der Deutsche Studienpreis Projektmanagement (DSPM) verliehen. Für alle, die nicht schon vom Essen gesättigt waren und nur noch ins Bett wollten, eröffnete noch eine Bar in der man den Abend ausgelassen ausklingen lassen konnte.

4

Tag 2, 24.10.2018:

Am nächsten Tag ging es mit sehr interessanten Vorträgen weiter. Da an diesem Tag die Zertifizierungsfrage für uns im Vordergrund stand, besuchten wir die vielen Aussteller, unterhielten uns angeregt und stellten einen Plan für unsere persönliche Weiterbildung auf.

Außerdem besuchten wir einen sehr spannenden Workshop, in dem die Wu-De Methode (https://www.wu-de.com/) anhand eines Beispiels erklärt wurde. Ein Ansatz aus der chinesischen Kultur, um die Problembewältigung in einem Projekt mithilfe der fünf Wirkkräfte anzugehen. Dies ist ein Thema, welches ich persönlich gerne weiterverfolgen würde, denn ich finde es eine interessante Methode, um Konflikte im Projekt zu lösen und daraus resultierende weitere Konflikte nach Möglichkeit schon vorauszusehen.

5

Mit diesem Workshop endete auch der zweite Tag auf dem PM Forum für uns. Alles in allem war es ein sehr interessantes Event und definitiv eine Erfahrung bzw. einen Besuch wert. Da viele Projektmanager aus den unterschiedlichsten Bereichen vertreten waren, gab es immer jemanden, mit dem man sich austauschen konnte. Die Vorträge waren inhaltlich spannend gestaltet und haben uns „unentschlossenen“ wirklich geholfen eine Richtung zu finden, in die wir uns weiterbilden möchten. Da allerdings, wie auf jedem größeren Event, viele verschiedene Vorträge und Workshops auch parallel stattfinden, sollte man mit einem guten Plan auf das PM Forum fahren, um nicht womöglich wichtige Themen zu verpassen.

Mein persönliches Fazit: Ich konnte mir viele Anregungen holen und kann bescheinigen, dass neben der Organisation des Events auch die Themenauswahl ausgesprochen gut war. Alle unsere Fragen wurden beantwortet und ich denke, dass sich jeder Projektmanager mit einem der vorgetragenen Themen identifizieren und etwas für sich mitnehmen konnte. Bis zum nächsten Jahr!


google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

BizTalk Deployment Framework - Fallstricke und Best Practices

Veröffentlicht am 31.10.2018 von Jean-Pierre Pereira , BizTalk , DevOps , BTDF

In einem unserer aktuellen Projekte haben wir uns gefragt, welche Art des Deployment wohl für BizTalk und seine Nebenkomponenten (z.B. Webservices) am besten geeignet ist. Da es sich um verteilte Systeme handelt, war die Herausforderung zunächst, für jede logische Komponente ein eigenes Paket in Form einer MSI zur Verfügung zu stellen. Diese sollen dann über ein Software-Verteilungssystem automatisiert installiert und bereitgestellt werden. Zur Umsetzung ist aus unserer Sicht das BizTalk Deployment Framework (kurz: BTDF) hervorragend geeignet. Wir möchten daher im Folgenden auf einige Fallstricke eingehen, welche während des Projekts aufgefallen sind und einige Best Practices herleiten.

Was ist BTDF?

BTDF ist ein Framework, welches zum Konfigurieren und zur Bereitstellung von BizTalk-Anwendungen verwendet werden kann. Ins Leben gerufen wurde es durch Thomas F. Abraham, wobei die Anwendung frei verfügbar und ein somit mittlerweile ein Community-Projekt ist. Mit dem Biztalk Deployment Framework ist es mittlerweile sehr einfach extrem komplexe Biztalk-Komponenten, wie Orchestrations oder Pipelines zu deployen. Der Admin muss zur Installation der Biztalk-Anwendungen und zugehöriger Artefakte keine manuellen Schritte mehr tätigen, sondern kann die Installation komplett automatisiert durchführen lassen.
Um einen Überblick über das BizTalk Deployment Framework zu erhalten, gibt es bereits eine große Anzahl an Quellen und Tutorials, weshalb wir in diesem Artikel darauf nicht näher eingehen wollen. Viel mehr beschäftigen wir uns mit Fragen, welche aus unserer Sicht nicht ausreichend dokumentiert sind und euch das Deployment etwas vereinfachen. Die Erkenntnisse, die wir im Laufe des Projekts gesammelt haben, beziehen sich alle auf die dort eingesetzte (und dokumentierte) Version 5.5 des BTDF. Ein Release-Datum von der Version 6.0 (aktuell im Beta-Stadium) ist noch nicht bekanntgegeben.

Vorenthalten möchten wir euch die Einführungen natürlich trotzdem nicht, daher hier ein paar Quellen für die, die sich erst einmal grundlegend mit BTDF vertraut machen möchten:

Aber genug einleitende Worte. Hier kommen nun unsere gesammelten Fallstricke und Best Practices zum Biztalk Deployment Framework:

Das Problem mit dem AppPool

Webservices anlegen

In der Version 5.5 des BizTalk Deployment Frameworks ist dokumentiert, dass evtl. bereitzustellende Webservices über die folgenden Einträge der ".btdfproj"-Datei zu hinterlegen sind:

1. "IncludeVirtualDirectories" auf den Wert "true" setzen:
<PropertyGroup>

<IncludeVirtualDirectories>true</IncludeVirtualDirectories>

<PropertyGroup>

2. Eine "VDirList"-ItemGroup hinterlegen:
<ItemGroup>
  <VDirList Include="*">
    <Vdir>MyVDirName</Vdir>
    <Physdir>..\MyVDir</Physdir>
    <AppPool>MyAppPool</AppPool>
    <AppPoolNetVersion>v4.0</AppPoolNetVersion>
  </VDirList>
</ItemGroup>

Natürlich funktioniert das nur, insofern ihr daran gedacht habt, alle Webservices mittels einem "Copy-Befehl" in die MSI zu integrieren. Denn wenn die Services beim Deployment-Vorgang auf dem Zielserver nicht vorhanden sind, können sie auch nicht veröffentlicht werden. Hier exemplarisch der entsprechende Copy-Befehl dazu:

<Target Name="CustomRedist">

  <MakeDir Directories="$(RedistDir)\TestFiles" />

  <CreateItem Include="..\TestFiles\**\*.*">

    <Output TaskParameter="Include" ItemName="TestFileSourceGroup" />

  </CreateItem>

  <Copy DestinationFolder="$(RedistDir)\TestFiles\%(RecursiveDir)" SourceFiles="@(TestFileSourceGroup)"/>

</Target>

Die WebServices werden auf diese Art und Weise vollkommen problemlos bereitgestellt. Der AppPool wird sogar fehlerfrei angelegt, insofern er nicht schon vorhanden ist - allerdings im PipeLine-Modus "Classic". Was aber tun wir, wenn wir den PipeLine-Modus auf "Integrated" stellen möchten? Klar - manuell geht das schnell. Aber das ist eben nicht der Sinn eines automatisierten Deployments. Zu viele Einzelschritte - vor Allem, wenn sie von Personen ausgeführt werden, die vielleicht weniger Fachkenntnis in diesem Bereich haben, führen potentiell zu Fehlern. Außerdem steigt der Aufwand mit der Anzahl der Webserver immens. Was also tun?

Die Lösung fand die Community mit der Veröffentlichung der Version 5.7. Hier erhält der Nutzer die volle Kontrolle über den IISAppPool:

https://github.com/BTDF/DeploymentFramework/blob/master/src/Samples/BizTalk/IIS/IIS.Deployment/IIS.Deployment.btdfproj

Falls ihr aber aus irgendeinem Grund eine andere Version des Deployment Frameworks benutzen wollt oder müsst, haben wir folgenden Workaround für euch:

BTDF bietet euch eine einfache Möglichkeit, externe Programme auszuführen - Powershell-Skripte eingeschlossen. Hier können wir die ganze Power von Powershell für uns nutzen, aber lasst uns Schritt für Schritt vorgehen:

1. Zunächst erstellen wir uns ein Powershell-Skript, welches die folgenden Eingangsparameter enthält:
param(
  [string] $WebSitePath,
  [string] $WebsiteName,
  [string] $AppName,
  [string] $AppPoolName,
  [string] $UserName,
  [string] $Password
)

Wieso ist das wichtig? Ganz einfach! Wir werden später im BTDF alle Parameter beim Aufruf des Skripts mitgeben. So können wir je nach Umgebung eine andere Webseite, Pfad usw. auswählen und müssen diese nicht manuell einpflegen. Weiterer Vorteil: Durch die Eingabe des AppNames können wir das selbe Skript für eine Vielzahl an unterschiedlichen Webservices einsetzen. Wir haben hier also eine generische Lösung. Den Rest kennt man sicherlich von anderen Deployment-Szenarien im Kontext von Webservices:

2. Wir erstellen zwei Funktionen, eine zum Bereitstellen des AppPools und eine zum Bereitstellen und Zuordnen der Services:

Function Add-IISAppool([string]$AppPoolName, [string]$UserName, [string]$Password)
{
  C:\Windows\system32\inetsrv\appcmd add apppool /name:$AppPoolName
  C:\Windows\system32\inetsrv\appcmd set apppool $AppPoolName /processModel.userName:$UserName /processModel.password:$Password
  C:\Windows\system32\inetsrv\appcmd set config /section:applicationPools "/[name='$AppPoolName'].processModel.identityType:SpecificUser"
}

Function Add-IISApp([string]$AppPoolName, [string]$SiteName, [string]$PhysicalPath, [string]$AppName)

{

  C:\Windows\system32\inetsrv\appcmd add app /site.name:$SiteName /path:/$AppName /physicalPath:$PhysicalPath

  C:\Windows\system32\inetsrv\appcmd set app "$SiteName/$AppName" /applicationPool:$AppPoolName

}


3. Nun können die Funktionen ganz normal abgerufen werden:


If (!Test-Path "IIS:\AppPools\$AppPoolName"))
{
  Add-IISApppool -AppPoolName $AppPoolName -UserName $UserName -Password $Password
}

If (Test-Path $WebsitePath\$AppName)
{
  Remove-Item -path $WebsitePath\$AppName\* -include *.publishproj -recurse

  If (Test-Path $WebsitePath\$AppName\App_Data )
  {
     Remove-Item -path $WebsitePath\$AppName\App_Data -recurse
  }

  Add-IISApp -SiteName:$WebsiteName -AppName:$AppName-AppPoolName:$AppPoolName -PhysicalPath:$WebsitePath\$AppName
}

So haben wir eine einfache Lösung unsere Services und die zugehörigen AppPools auf die gewünschten Server zu deployen und dabei so flexibel wie möglich zu bleiben. Der AppPool ist daraufhin mit dem Pipeline-Modus "Integrated" erstellt, womit wir unser Ziel erreicht haben. Und noch viel mehr: Dadurch, dass der Write-Host Output während des Deployments seitens BTDF mit ausgegeben wird, sind wir im Bereich Logging maximal flexibel. Man könnte beispielsweise hinter jedem Einzelschritt einen entsprechenden Text ausgeben.

Wie die Integration seitens BTDF aussieht, könnt ihr ganz einfach im oben aufgeführten Wiki nachlesen.

Wohin mit der Business-Rule-Engine?

Da wir, wie oben erwähnt, über verteilte Systeme sprechen, ist diese Frage nach der Rules Engine absolut berechtigt. Ich persönlich war am Anfang davon ausgegangen, dass die Business-Rules ganz einfach zusammengefasst in einem Teil des Deployments implementiert werden sollten. Was aber, wenn ein Teil des Projekts auf einem anderen Server bereitgestellt werden soll? Die Business Rule würde nicht mehr greifen und unsere Nachrichten würden in der MessageBox versauern!
Es ist daher unsere Empfehlung, pro Fachapplikation ein eigenes Business-RuleSet zu erstellen und letztlich auch zu deployen. Gemeinsam genutzte Komponenten, wie z.B. eine Orchestration, werden in einer Biztalk-Applikation deployed. Fachspezifische Artefakte (z.B. ein für einen fachlichen UseCase spezifischer SendPort) erhalten dann wiederum eine eigene Applikation. Und jede Applikation erhält Ihre eigenen Business Rules. Das verspricht die maximale Flexibilität während des Deployments.

Übrigens: Falls ihr euch auch wundern solltet, weshalb eure Business Rule zwar published, aber nicht deployed werden. Ihr müsst die MSBuild-Property "ExplicitlyDeployRulePoliciesOnDeploy" auf den Wert "true" setzen. Das wird leicht übersehen, da im Wiki nur das Publishing näher beschrieben und der Deployment-Vorgang nur referenziert wird.

Wie erstelle ich Hosts, Hostinstanzen und Adapter?

Zwar bietet BTDF die Möglichkeit Hostinstanzen neuzustarten - eine Neuanlage inkl. Der dazugehörigen Adapter wird bis dato jedoch nicht unterstützt. Wie im Fall der WebServices müssen wir uns auch hier eine eigene Lösung überlegen und was bietet sich hier besser an als das zu nutzen, was wir sowieso schon im Einsatz haben? Richtig, das bedeutet Hosts, Hostinstanzen und Adapter, können wir ohne Probleme mithilfe von Powershell erstellen und vom BizTalk Deployment Framework aus aufrufen. Dabei sollten wir wieder darauf achten, das Skript so generisch wie möglich zu halten. Aufgerufen werden die Skripte genauso wie die Skripte der WebServices. Ein genaues Tutorial hierzu findet ihr im referenzierten Wiki am Anfang des Artikels.
Wie bereits erwähnt, wollen wir ein hohes Maß an Generalität erzeugen, weshalb wir im ersten Schritt wieder unsere altbekannten Parameter in das Powershell-Skript einfügen. Wir werden hier beispielhaft einen Receive-Host inklusive Hostinstanz und WCF-WebHTTP Adapter erstellen.


Parameter hinterlegen:

param(

[string] $Isolated_UserName,

[string] $Isolated_Password,

[string] $InProc_UserName,

[string] $InProc_Password,

[string] $BTSPath)

Warum haben wir hier zwei unterschiedliche User-Variablen in unserem Skript? Das liegt daran, dass wir einen Adapter erstellen, welcher im "Isolated-Mode" (WCF-WebHTTP) agiert und uns offen halten wollen einen weiteren Adapter, welcher im "InProcess-Mode" (WCF-BasicHTTP) agiert zu erstellen.


Powershell Extensions für BizTalk:

Für die Kommunikation mit BizTalk existiert bereits eine Extension für Powershell, das vereinfacht die Arbeit um ein Vielfaches. Bevor wir unsere Befehle also ausführen können, müssen wir die Extension einfügen, welche sich unter dem BizTalk-Installationspfad befindet:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe $BTSPath"SDK\Utilities\PowerShell\BizTalkFactory.Powershell.Extensions.dll"

Jetzt noch aktivieren:

Add-PSSnapin -Name BizTalkFactory.Powershell.Extensions

Und nun können wir auf alle Funktionen der Extension zugreifen und mit der eigentlichen Ausführung beginnen. Das funktioniert dann wie folgt: Wir erstellen uns ein Powershell-Drive und bewegen uns anschließend darin, um zu den einzelnen Zielen, wie den Hosts, in BizTalk zu gelangen.


PSDrive und Hosts erstellen:

Mit dem ersten Befehl erstellen wir unseren PSDrive.

$Server = (Get-ItemProperty "hklm:SOFTWARE\Microsoft\Biztalk Server\3.0\Administration").MgmtDbServer

New-PSDrive -Name BizTalk -Root BizTalk:\ -PsProvider BizTalk -Instance $Server -Database BizTalkMgmtDb

Set-Location -Path BizTalk

Um jetzt in diesem Drive den „Ordner“ zu wechseln und z.B. im Bereich der Hosts zu arbeiten, wechseln wir den Pfad wie folgt

Set-Location -Path 'Platform Settings\Hosts'

Die Hosts können wir dann unter diesem Pfad wie folgt erstellen:

$HostGroupName = Get-ItemProperty -Path 'BizTalkServerIsolatedHost' -Name 'NtGroupName'

New-Item ReceiveHost -NtGroupName $HostGroupName.NtGroupName -HostType 'Isolated'

Set-ItemProperty -Path ReceiveHost -name 'Is32BitOnly' -Value 'False'

Jetzt haben wir in unserem Beispiel einen Isolated-Host erstellt und die Beschränkung auf 32-Bit ausgeschaltet. Das Vorgehen für die Adapter, sowie der Hostinstanzen ist ähnlich. Die Besonderheit an den Hostinstanzen ist allerdings, dass wir an dieser Stelle bereits die Zugangsdaten hinterlegen müssen. Dies sieht dann in etwa wie folgt aus:

$IsolatedPassword = ConvertTo-SecureString -String $Isolated_Password -AsPlainText -Force

$IsolatedCredentials = New-Object -TypeName:System.Management.Automation.PsCredential -ArgumentList $Isolated_UserName, $IsolatedPassword

New-Item -Path:'HostInstance' -HostName:ReceiveHost -Credentials:$HostisoCredentials


Erstellen eines WCF-WebHTTP Adapter:

New-Item -Path .\ReceiveHost -Hostname ReceiveHost -Direction Receive

Es ist wichtig daran zu denken, immer vorab den Pfad - wie weiter oben bereits erwähnt - zu ändern, ansonsten läuft die Anforderung ins Leere. Die Pfade sind hierbei äquivalent zu den Bereichen der Biztalk Management Console.
Leider ist die Extension im World Wide Web nicht so gut dokumentiert wie das BTDF. Allerdings findet man eine kleine Readme-Datei unter dem Installationspfad des BizTalk-Servers, hier sind nicht nur die verfügbaren Befehle hinterlegt, sondern auch eine kleine Installationsanweisung der Extension.

Und wie deploye ich das nun ohne die MSI manuell zu bedienen?

Im Best Case seid ihr nun an den Punkt angekommen, an dem ihr zumindest eine MSI habt, welche ihr nun auf euren Ziel-Server ausführen lassen möchtet. Eingangs hatte ich beschrieben, dass sowas idealerweise durch ein Softwareverteilungsprogramm geschieht, allerdings kann dieses Programm sich nicht durch die Installationsroutine der MSI klicken, was also tun?

MSI unterstützt standardmäßig Befehlszeilenargumente. Das bedeutet, dass ihr euch für das Deployment beispielsweise eine kleine Batch-Datei schreiben könnt, die das Deployment automatisiert vornimmt. Diese kopiert ihr einfach gemeinsam mit der MSI auf das Zielsystem und führt sie aus. Aber Achtung: Da ihr im Befehlszeilenargument eine bestimmte Umgebung bzw. ein bestimmtes Settings-File für eure Umgebung auswählt, benötigt ihr für jede Umgebung eine eigene Batch-Datei.

Ich zeige euch nun in kleinen Schritten exemplarisch, wie ihr eine Batch-Datei für ein bestimmtes Environment definiert.


Installation ausführen:

@echo off

msiexec.exe /I /YourGreatBizTalkApplication.msi

/log YourGreatLog.log /passive

INSTALLDIR="C:\Program Files\YourGreatBizTalkApplication\1.0"

Bevor wir etwas deployen, muss natürlich die Applikation installiert werden. Ich habe hierfür den Pfad "…/Program Files/" gewählt - aber letztlich, bleibt das euch überlassen. Bitte denkt daran "YourGreatBizTalkApplication.msi" durch den Namen eurer MSI zu ersetzen.


Settings exportieren:

Im nächsten Schritt exportiert ihr alle eure Environment-Settings vom SettingsFileGenerator.xml in das Ziel-Verzeichnis. Ihr benötigt diesen Schritt, um beim Deployment die richtige Datei und somit das richtige Environment wählen zu können. Die MSI kann leider nicht anhand der XML entscheiden, welches Environment das Richtige ist:

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\Framework\DeployTools\EnvironmentSettingsExporter.exe"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings\SettingsFileGenerator.xml"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings"


Application deployment:

Nun können wir unsere Applikation deployen, alle Vorbereitungen dafür sind ja bereits getroffen. Hierzu verwenden wir die MSBuild.exe, welche standardmäßig im angegebenen Pfad installiert sein sollte.

"%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"

/p:DeployBizTalkMgmtDB=true;Configuration=Server;SkipUndeploy=true /target:Deploy

/l:FileLogger, Microsoft.Build.Engine;logfile="C:\Program Files\YourGreatBizTalkApplication\1.0\DeployResults\DeployResult.txt"

"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\Deployment.btdfproj"

/p:ENV_SETTINGS:"C:\Program Files\YourGreatBizTalkApplication\1.0\Deployment\EnvironmentSettings\Exported_Test_Settings.xml"

Damit sind alle Schritte getan und mit einem Klick auf die Batch-Datei sollte nun die MSI ausgeführt und die Applikation bereitgestellt werden.

Unsere Erfahrungen mit dem Biztalk Deployment Framwork waren durchweg positiv. Natürlich gibt es einige Fallstricke. Aber diese sind verglichen mit einem manuellen oder ggf. alternativen Deployment zu vernachlässigen – BTDF vereinfacht die Bereitstellung eurer Anwendungen enorm. Sicherlich werden uns in Folgeprojekten weitere Fallstricke auffallen – denn wir werden das Framework weiterverwenden. Sobald wir diese gefunden haben, könnt ihr genau hier nach unseren Erkenntnissen suchen (und sie finden).

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Seitenladezeit optimieren? HTTP/2 aktivieren!

Veröffentlicht am 02.07.2018 von Alexander Müller , Web , Cloud

Das World Wide Web und wie wir es nutzen hat sich im Laufe seines Daseins verändert. Von einzelnen, statischen Hypertext-Dokumenten hin zu komplexen, interaktiven Seiten voller multimedialer Inhalte. Dies zeigt sich auch in den Statistiken: Seit 2010 hat sich die durchschnittliche Website-Größe (in Desktop-Darstellung) mehr als verdreifacht. Die durchschnittliche Anzahl an Requests pro Seite liegt mittlerweile bei über 80. Dies hat vor allem Auswirkungen auf die Seitenladezeit, aber HTTP/2 schafft Abhilfe!

Mehr Bandbreite, mehr Bandbreite!

Eine höhere Bandbreite wirkt sich auch immer positiv auf die Seitenladezeit aus. Das möchte man meinen, doch die Seitenladezeit (PLT, Page Load time) hat sich in den letzten Jahren, trotz höherer Bandbreiten, kaum verändert hat. Woran liegt das?
Untersuchungen haben gezeigt, dass sich ab einer Bandbreite von 5 Mbit/s nur minimale Verbesserungen der Seitenladezeit feststellen lassen. So resultiert aus einer Verdoppelung der Bandbreite von 5 auf 10 Mbit/s, eine nur um 5% bessere PLT. Einen viel größeren Einfluss hat die Latenz, auf die nur schwer und mit hohem Aufwand Einfluss genommen werden kann. Eine Verringerung der Latenz spiegelte sich also unmittelbar in einer verbesserten PLT wider. Wieso?
Websites und ihre Bestandteile werden über das Hypertext Transfer Protocol (HTTP) geladen, welches das Transmission Control Protocol (TCP) als Transportprotokoll nutzt. Auf Grund verschiedener Eigenschaften von TCP (Reliable Transmission, Retransmission, Congestion Control) ist dessen Performance unmittelbar abhängig von der Latenz des Netzes. Noch deutlicher spürbar in mobilen Netzen, in denen die Latenz stärker schwankt und deutlich höher liegt als über Kabel. Eine Möglichkeit der Abhilfe in Bezug auf die PLT kann also eine optimierte Nutzung der TCP-Verbindungen sein – HTTP/2 macht das möglich!

Von HTTP/1.1 zu 2.0 in „nur“ 20 Jahren

Im Jahr 1997 wurde HTTP/1.1 (RFC2068) als Update der nur ein Jahr zuvor erschienenen Version 1.0 veröffentlicht. Denn es gab Nachbesserungsbedarf: Wie in HTTP/1.0 beschrieben, muss für jeden Request eine neue TCP-Verbindung (short-lived connection) geöffnet werden. Durch den zeitintensiven TCP Three-Way-Handshake und der Nutzung als „Cold Connection“ (TCP Slow Start) führte dies zu starken Performance-Einbußen. In HTTP/1.1 wurde deshalb der keep-alive-Header eingeführt, wodurch eine geöffnete TCP-Verbindung nicht mehr sofort geschlossen wird, sondern für einen bestimmten Zeitraum geöffnet bleibt (persistent connection), sodass sie für weitere Request/Responses genutzt werden kann.

Seitdem hat sich das Web weiterentwickelt, das HTTP-Protokoll erfuhr jedoch für über 20 Jahre hinweg nur wenige Änderungen. Vielleicht war es der Vorstoß von Google mit dem Protokoll SPDY (gesprochen „Spidi“), der neue Bewegung in das Thema brachte. In jedem Fall sind große Teile des Protokolls in die neue Version des HTTP-Protokolls (RFC 7540) eingeflossen. SPDY selbst wurde von Google in Hinblick auf den neuen, kommenden Standard HTTP/2 zurückgezogen und der Support eingestellt.

Was ist neu in HTTP/2?

HTTP/2 ermöglicht eine effizientere Nutzung der Netzwerkressourcen und merzt somit einige Mängel von HTTP/1.1 aus, ohne dabei die Semantik des Vorgängers zu verändern. Dabei sind die folgenden drei Neuerungen ausschlaggebend.

Multiplexing

Ein Problem, das mit HTTP/2 adressiert wird, ist Head-of-line blocking. Dabei stauen sich die ausgehenden Request in einer Warteschlange an, da eine Verbindung immer nur für einen Request/Response gleichzeitig genutzt werden kann. Die Verarbeitung erfolgt also pro Verbindung sequentiell. In HTTP/1.1 wurde bereits versucht mittels HTTP Pipelining dieses Problem zu lösen, leider erfolglos. Stattdessen hilft der Browser, denn dieser verarbeitet Requests durch das Öffnen mehrerer Verbindungen parallel (je nach Browser bis zu 8 pro Hostname). Dennoch erfordern heutige Websites häufig ein Vielfaches der zur Verfügung stehenden gleichzeitigen Verbindungen zum vollständigen Laden.

In HTTP/2 können durch Multiplexing mehrere Request- und Response-Nachrichten parallel über dieselbe TCP Verbindung übertragen werden, wodurch das Öffnen mehrerer Verbindungen nicht mehr notwendig ist. Dadurch werden einige etablierte Workarounds wie Concatenation, CSS-Sprites oder Domain Sharding obsolet.

Header Compression

Durch die Zustandslosigkeit des HTTP-Protokolls ist es notwendig bei jedem Request alle für die Verarbeitung benötigten Informationen mitzusenden. Werden viele Ressourcen desselben Host abgefragt, werden vielfach redundante Header-Informationen übertragen, obwohl der Server diese möglicherweise durch vorangegangenen Requests bereits erhalten hat.
Um dieses Problem zu adressieren, wird ein speziell für HTTP/2 entwickeltes Kompressionsformat namens HPACK angewandt. Vereinfacht sieht dieses vor, dass sowohl Server als auch Client pro Verbindung eine dynamische Lookup-Table für die Header-Informationen halten. Der Client kann den Server dazu anweisen die empfangenen Header-Informationen in seiner Tabelle zu speichern. Muss der Client denselben Header nochmal schicken, sendet er nur den Index des Tabelleneintrags. Zusätzlich sind die Header-Informationen Huffman-kodiert.

Server Push

Fordert der Client eine Seite beim Server an, folgen nach der Analyse der Seite weitere Requests des Clients zur Anforderung benötigter Ressourcen, wie JavaScript-, CSS- oder Bilddateien. Um die Zeit bis alle Ressourcen vorliegen zu verkürzen, kann der Server diese Ressourcen bereits bei Anfrage der Seite mit an den Client schicken, sodass diese dann bereits im Cache des Clients vorliegen und kein weiterer Round-Trip notwendig ist.

Unterstützt mein Browser HTTP/2?

Die meisten Browser-Hersteller haben bereits seit längerem den Support für HTTP/2 implementiert. Eine detaillierte Übersicht findet sich bei caniuse.com. Da HTTP/2 abwärtskompatibel ist, gibt es nichts zu beachten. Das Protokoll wird im Rahmen des ersten Request „ausgehandelt“ (ALPN, Application-Layer Protocol Negotiation).

image

Kann ich HTTP/2 mit meinem Webserver verwenden?

Ein klares: „It depends!“ Konkret kommt es darauf an, ob der genutzte Webserver bereits HTTP/2 implementiert und die Seitenzugriffe verschlüsselt erfolgen. Die Spezifikation sieht zwar keinen Zwang für Verschlüsselungen wie TLS vor, trotzdem erfordern es die meisten Implementierungen. Eine Liste mit Implementierungen findet sich auf der Github-Seite für HTTP/2 der HTTP Working Group. In der Microsoft-Welt bietet IIS 10 die Unterstützung. Dieser ist allerdings an Windows Server 2016 geknüpft, weshalb sich der ein oder andere bis zum nächsten OS-Update gedulden muss.

Fazit

Mit HTTP/2 wurde die Basis für das Protokoll des WWWs erneuert und es wurde auch Zeit.
In Hinblick auf die Performance lohnt sich die Aktivierung von HTTP/2 vor allem dann, wenn zum Laden der Seiten eine Vielzahl an Ressourcen vom Server abfragt werden muss. Auf Grund der Abwärtskompatibilität zu HTTP/1.1 hat eine Aktivierung aber auch keine negativen Aspekte. Zu berücksichtigen ist die Unterstützung des eingesetzten Webservers. Wir selbst hosten unsere Website als Azure App Service in der Cloud. Eine Umstellung bedeutet hier nicht mehr Aufwand als das Umlegen eines Schalters in der Administrationsoberfläche. Vielleicht auch für Sie ein Anreiz über einen Cloud Move nachzudenken!

image

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

XML basierte Konfiguration in Azure API Management

Veröffentlicht am 04.06.2018 von Mahmoud Habiballah , Azure , API Management

In den letzten Jahren hat sich HTTP, dank REST, als eines der wichtigsten Protokolle zur Kommunikation zwischen Web-Services etabliert. Die Verwaltung und Betreuung solcher Services ist eine große Herausforderung. Mit Azure API Management will Microsoft das ändern.

Eine API (Application Programming Interface) beschreibt Operationen, die die Schnittstelle für Kommunikation zwischen Systemen zur Nutzung ihrer Funktionalitäten, vorschreiben.

Die Bereitstellung komplexer APIs stellt für Entwickler und Administratoren viele Herausforderungen dar, die sich stark voneinander unterscheiden und die umfangreiche Kenntnisse erfordern, um diese verwalten zu können. Die Verwaltung einer API befasst sich u.a. mit folgendem:

  • Zugriffsteuerung

  • Analytik

  • Dokumentation für Entwickler

  • Ratenbegrenzung

Azure API Management, ist ein Microsoft „Platform as a Service“ (PaaS) zur Lösung oben genannter Aufgaben. Er bietet u.a. einen Proxy zwischen der zu verwaltenden API und Anwendungen, die die Dienste der API nutzen. Durch Azure API Management verwaltete APIs müssen nicht in Azure gehostet werden, sondern können auch on premises oder in anderen Cloud Diensten gehostet werden.

Azure API Management teilt sich in drei Komponenten auf:

  • Publisher Portal: Eine Web-Applikation, womit Herausgeber der API unterschiedliche Konfigurationen des Proxys verwalten können.

  • Developer Portal: Bietet den Entwicklern eine Web-Applikation, um auf die Dokumentation der API sowie ihre eigenen Monitoring Dienste zuzugreifen.

  • API Proxy: Es besteht kein direkter Zugriff auf die API. Client Anwendungen kommunizieren mit dem Proxy zur Weiterleitung der Aufrufe an die API.

Da verschiedene APIs sich des gleichen Geschäftsmodels bedienen können, bietet Azure API Management das Produkt (Products) Konzept an. Ein Produkt stellt den Entwicklern eine Art von Abonnement zur Verfügung, womit verschiedene APIs zusammen verwaltet werden können.

Ein Produkt und seine APIs können durch Richtlinien (Policies) konfiguriert werden.

Die Macht der Richtlinien

Wie oben erwähnt, findet jede Kommunikation zwischen einer API und einer Anwendung, durch den Proxy statt. Dadurch ist es möglich alle Anfragen (Inbound) sowie Antworten (Outbound) vom Proxy abzufangen und je nach Anfrage oder Antwort, zusätzliche Dienste anzubieten.

Diese Richtlinien können innerhalb des Lebenszyklus einer Anfrage ausgeführt werden. Dieser Lebenszyklus  besteht aus 4 Phasen:

  1. Inbound: beim Eingang eines Aufrufs.

  1. Outbound: beim Ausgang eines Aufrufs (Antwort auf den eingehenden Aufruf).

  1. Backend: nach Inbound Richtlinien und bevor die Anfrage an die Backend API geschickt wird.

  1. Error: beim Auftritt von Fehlern.

Richtlinien sind XML basiert und können auf Produkte, APIs und Operation angewandt werden. Außerdem unterstützen sie C#-6, womit sich sämtliche Szenarien dynamischer und flexibler verwalten lassen.
Die Abbildung zeigt die Konfigurationsoberfläche für die Richtlinien.

1

Sollen z.B. die Anfragen aller APIs als XML beantwortet werden, müssen die folgenden Rechtlinie für alle Produkte, APIs und Operationen spezifiziert werden:

2

Solche Richtlinien sind zustandslos. Mit der vordefinierten Context-Variable ist es aber durchaus möglich auf Anfragen bezogene Informationen und Metadaten zuzugreifen. So kann man z.B. festlegen, dass von einer IP-Adresse maximal 5 Aufrufe pro Sekunde behandelt werden.

3

Wird ein Endpunkt mehr als 5 Mal innerhalb von 20 Sekunden aufgerufen, erhält man einen Rate Limit-Fehler:

4

Es ist zu beachten, dass das erste Beispiel eine Outbound-Richtlinie und das zweite eine Inbound-Richtlinie zeigt. D.h. dass, das erste Beispiel auf allen Antworten anzuwenden ist. Beim zweiten sind nur eingehende Aufrufe betroffen.

Innerhalb des „on-error“ Abschnitt, kann man Richtlinien, die beim Auftreten von Fehlern ausgewertet werden, festlegen.  Im folgenden Beispiel wird nach Fehlern, die durch die Auswertung der Ratenbegrenzungsrichtlinie ausgelöst werden, gesucht. Dafür ist von den Ablaufsteuerungselementen wie z.B. „choose“ und „when“ Gebrauch zu machen. Damit lassen sich Antworten modifizieren.

5

Richtlinien sind nicht nur für die Kommunikation einer Applikation, dem Proxy und der API gedacht. Aufrufe an externe Dienste können z.B. mittels der Richtlinie „send-request“ definiert werden.

6

In diesem Artikel wurde insbesondere auf das Thema Richtlinien in Azure API Management eingegangen. Eine XML basierte Konfiguration, zur Behandlung und Bearbeitung von Anfragen, welche nicht nur statische Konfigurationen sind. Auch dynamische und flexible Konfigurationen, die sich innerhalb des Lebenszyklus einer Anfrage, auswerten lassen sind möglich und einfach zu gestalten.

Fazit

Vielen lassen sich vom Azure API Management täuschen und stellen es sich als ein weiteres Werkzeug, um APIs in der Cloud zu hosten, vor. Das ist aber nicht der Fall.

Azure API Management stellt ein mächtiges Werkzeug in Azure für den Einsatz, Verwaltung und sogar bis zur Erweiterung dieser APIs. Ob für Administratoren oder Entwickler, lassen sich solche Aufgaben, flexibel mittels Richtlinien erledigen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Warum man eine Namenkonvention bei Microsoft Teams braucht

Veröffentlicht am 01.05.2018 von Hieronymus Deutsch , Collaboration

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

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

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


Was man dagegen machen kann:

image

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

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

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

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

SQL Server Konferenz 2018 in Darmstadt

Veröffentlicht am 13.03.2018 von Ireen Raue , SQL Server , Data , Azure

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

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

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

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

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

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

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

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

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

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

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

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

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Wie mache ich mir die InMemory-Technologie des SQL Server 2014 für bestehende Projekte nutzbar!

Veröffentlicht am 05.03.2018 von Ireen Raue , SQL Server , Data

In einem aktuellen Projekt wurde im Zuge eines Hardwaretausches der SQL Server von 2008 auf 2014 migriert, wobei in diesem ersten Schritt keine funktionalen oder technischen Änderungen an den Datenbanken durchgeführt wurden. Da der SQL Server 2014 aber einige technische Verbesserungen mit sich bringt, soll nun überprüft werden, in wie weit diese für die bestehenden Datenbanken zur Verbesserung der Performance genutzt werden können. Die Ergebnisse meiner Recherche dazu möchte ich hier darstellen.

Wer kennt das nicht…?

  • In eine DB strömen große Datenmengen aus verschiedenen Quellen
  • Erwartet wird eine gute Leseperformance gekoppelt mit periodisch auftretenden Batch Inserts/Updates sowie eine niedrige Latenz
  • Intensive Business Logik, die auf dem DB-Server ausgeführt werden muss

Und diese Liste kann man sicher noch um einiges erweitern. Der SQL Server 2014 verspricht aber mit der neuen InMemory-Technologie, an diesen Stellen helfen zu können.

imageDurch den Übertrag ganzer Tabellen oder auch nur von Teilen einer Tabelle in memoryoptimized tables und die Umwandlung von Transact-SQL Code in Natively compiled Stored Procedures soll sich die Performance deutlich verbessern (siehe Bild unten). Voraussetzung dafür ist aber auf jeden Fall genügend Arbeitsspeicher, da die Daten aus diese Tabellen im Arbeitsspeicher gehalten werden.

Wer wünscht sich das nicht… Benefits von In-Memory OLTP (Online Transaction Processing )

  • Eliminierung von Konflikten
  • Effizientes Einfügen der Data
  • Geringere Wartezeiten
  • Minimierung der Code Ausführungszeiten

Und auch hier ist die Liste, der von Microsoft versprochenen Verbesserung noch erweiterbar. Je nachdem wieviel Daten und auch Prozeduren übertragen werden, wird versprochen:

imageUm das auch bei unserem Projekt einsetzten zu können, habe ich mich durch einige Microsoft-Seiten gelesen (die Linksliste befindet sich unter diesem Beitrag) und versucht auf kompakte Weise einen für uns und wahrscheinlich auch für viele andere Projekte machbaren Weg zur Analyse und evtl. Umsetzung zu finden. Eine Vorab-Analyse ist sehr wichtig, da nicht alle Tabellen und Prozeduren für einen Übertrag geeignet sind. In manchen Projekten kann das Ergebnis dieser Analyse auch sein, dass ein Einsatz der InMemory-Technologie nicht ohne großen Umbauaufwand realisierbar ist. In diesem Fall sollte man immer abwägen, ob die angestrebte Performanceverbesserung den Aufwand tatsächlich gerechtfertigt oder es wert ist.


image

Um eine valide Aussage zur Verbesserung geben zu können, muss man den Vorzustand mit dem Nachzustand vergleichen können. Es ist also unerlässlich ein paar Daten zur Performance zu sammeln.

Für die Analyse der Datenstruktur und möglicher Bottlenecks, die durch inMemory verbessert werden könnten, stehen im SQL ManagementStudio Tools zur Verfügung. Zum einen ist das das ARM-Tool. Hier wird mit Hilfe des Management DataWarehouse eine Analyse der aktuellen Performance der Datenbank gemacht und als Ergebnis gibt es den Transaction Performance Analysis Report.

Das ARM-Tool gibt Vorschläge welche Tabellen und Proceduren für inMemory in Frage kommen, wie hoch die Performanceverbesserung wäre und welchen Migrationsaufwand man bei den Objekten hätte.

Außerdem gibt es noch den Memory Optimization Advisor und Native Compilation Advisor. Damit werden die zur Transformation ausgewählten Objekte auf eventuelle InMemory Unverträglichkeiten überprüft. Was unter anderem dazugehört, habe ich bereits in einem anderen Blogbeitrag beschrieben. (Link zu Blog: SQL Server InMemory).

Im folgenden Bild sind alle Schritte noch mal feiner gegliedert dargestellt.

image

Diese Herangehensweise wird auch so von Microsoft empfohlen und kann unter „Determining if a Table or Stored Procedure Should Be Ported to In-Memory OLTP“ siehe Linkliste, genauer nachgelesen werden. Dort ist auch sehr gut beschrieben, wie der Data Collector eingerichtet werden kann.

Weiterführende Links:

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Cloud for All und Modern Workplaces - eBiz@TechSummit Frankfurt

Veröffentlicht am 28.02.2018 von Mahmoud Habiballah , Event , Azure , Collaboration

Mit mehr als 2000 Teilnehmern, 42 Sessions, zahlreiche Workshops und zahlreichen Partnern standen natürlich Azure und Microsoft 365 im Mittelpunkt des Microsoft Technical Summit 2018 in Frankfurt. Wie die letzten Jahre auch war die eBiz Consulting auch mittendrin.

Für die eBiz gehört die Microsoft Tech Summit schon seit ein paar Jahren fest zum Veranstaltungsplan, aber für mich war es die erste, größere Microsoft Veranstaltung, an der ich als Mitarbeiter der eBiz Consulting GmbH teilnehmen konnte. Und um es vorweg zu nehmen, aus meiner Sicht hat sich der Besuch gelohnt.

Test

Das Event hatte zwei thematische Schwerpunkte – Microsoft Azure und Microsoft 365 – und startete entsprechend mit zwei Keynotes – „Microsoft Azure - Cloud for All“ und „Create a modern workplace with Microsoft 365“. Große, neue Ankündigungen haben gefehlt, ein großes Moto jedoch nicht, welches später auch alle Sessions und Veranstaltungen begleitet

“The four pillars of Azure: Productive, Hybrid, Intelligent, Trusted”

Die Veranstaltung fand in der Frankfurter Messe - Halle 3 statt und verteilte sich auf zwei Tage. Passend zu den zwei Kernthemen war der erste Tag im Fokus von Sessions und Workshops rund um Microsoft 365, jedoch nicht ohne Bezug auf Azure. Für alle die Microsoft 365 bisher weniger oft gehört haben:

Microsoft 365 = Office 365 + Windows 10 + Enterprise Mobility & Security

Wie der Titel der Keynote bereits andeutet, ging es um das moderne Arbeitsumfeld und natürlich um das Zusammenarbeiten. Technisch war, neben der Office Suite im Allgemeinen, natürlich Microsoft Teams als Collaboration Tool ein wesentliches Thema. Für das Entwicklerherz von größtem Interesse war aber sicherlich die Microsoft Graph API. Themen wie die Integration zwischen Office365 und Cortana in Outlook, sowie neue Office365 Features wie z.B. „Powerpoint Ideas“ sind nennenswert und ein weiterer Schritt in der Modernisierung von Office.

image

Am zweiten Tag war eher das Thema Microsoft Azure im Fokus der Veranstaltung. Microsoft zeigte verschiedene Sessions zum Thema Serverless Computing und welche Features Azure Functions und Logic Apps bieten. Auch die Integration mit anderen Azure Diensten wie z.B. API Management, 3rd Party Lösungen, Entwicklungs- und Testwerkzeugen haben nicht gefehlt.
Vor allem aber beim Thema Hybrid Cloud war interessant zu sehen, was Microsoft unter „Cloud for All“ und „Hybrid Cloud“ versteht. In der Session „Unlocking your hybrid Cloud with Azure Stack“ wurden zahlreiche Szenarien gezeigt, wie man mit Azure Stack eine konsistente und effiziente Hybrid Cloud Strategie, mit minimalen Aufwand umsetzen kann.
Dass es bei Hybrid Cloud nicht nur um Infrastruktur-Lösungen geht, sondern auch mehr und mehr um die Verwaltung von Ressourcen in unterschiedlichen Infrastrukturen, konnte man Dank der Session zum Thema Security Center erkennen. Eine einheitliche intelligente Lösung für die Überwachung, sowie die Erkennung von Bedrohungen und Anomalitäten dank Advanced Threat Protection und Security Analytics, die dank Machine Learning neue Bedrohungen und Gefahren erkennen und analysieren können.
Ein Wort noch zur Session „Implement a secure and well managed Azure infrastructure“ von „Adwait Joshi“, die wegen sehr großem Teilnehmerinteresse wiederholt werden musste. Diese Tendenz hat man bei fast allen, sicherheitsbezogenen Sessions bemerkt und sie zeigt besonders gut die Interessenlage beim Thema Cloud in Deutschland wieder.

Fazit aus Sicht der eBiz:

Mit der Tech Summit 2018 ist es Microsoft gelungen, die aktuellen Trends und Best Practices in ihrem Umfeld aufzuzeigen und einen Ausblick auf seine Roadmap zu geben. Auch ihren Ansatz „Microsoft Azure - Cloud for All“ konnte man konsistent in der gesamten Veranstaltung wiederfinden.
Spezifische, technische Ansätze wie Cross Plattform oder Cross Device sind kein großes, neues Thema mehr bei Microsoft, sondern eher die Normalität, die bei jeder Lösung berücksichtigt ist. Der Fokus liegt eher darauf, die Partner optimal mit Lösungen zu unterstützen, damit diese mit und für ihre Kunden optimale Erfolge erzielen können. Es ist Microsoft gelungen, relevante Szenarien aufzuzeigen und zu präsentieren wie diese mit dem Microsoft Portfolio angegangen werden können.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Microsoft Zertifizierung von zu Hause - Proctored Exam

Veröffentlicht am 31.01.2018 von Ireen Raue , Insights@ebizcon , Weiterbildung

Nach fast zweijähriger Pause wollte ich endlich meinen Zertifizierungsplan weiterverfolgen. Wie das wohl fast jeder kennt, der auch schon eine Zertifizierung gemacht hat, kostet das einiges an Zeit. Zum einen muss man Zeit zum Lernen finden und dann einen Termin für die Prüfung selbst. Meist kann man die nur unter der Woche in einem Prüfungscenter ablegen. Bei mir kam dann noch eine längere Anfahrt dazu. Allein für die Prüfung wird also mindestens ein halber Arbeitstag gebraucht. Mit dem Proctored Exam soll genau diese Zeit verkürzt werden. Man kann die Prüfung mit einer online Überwachung von einem selbst gewählten Ort aus ablegen.

imageAuf dem Weg zur nächsten Zertifizierungsstufe standen mir 10 verschiedene Prüfungen zur Auswahl. Die erste Aufgabe bestand also darin zu entscheiden, welche dieser Prüfungen mache ich jetzt und wann lerne ich dafür. Ich suchte also eine der Prüfungen heraus und als ich mich halbwegs sicher mit den Prüfungsinhalten fühlte, machte ich mich daran, einen Prüfungstermin zu suchen Da wurde es dann schon schwieriger. Allzu weit in der Zukunft sollte der, wenn möglich nicht liegen, jetzt wo das ganze Wissen noch frisch im Kopf ist. Aber so viel Zeit gab mein Terminkalender auch nicht her und im Prüfungscenter musste es ja dann auch noch passen.

Auf meiner Suche nach einem Testcenter – das letzte war über eine Stunde Autofahrt entfernt – bin ich auf das Proctored Exam gestoßen. Ich hatte bis dato noch nicht davon gehört und habe dann ein wenig im Internet recherchiert. Das Proctored Exam ist eine überwachte Online Prüfung. Ich konnte mir nicht so recht vorstellen, wie Microsoft sicherstellen will, dass nicht gespickt oder die Prüfung eventuell aufgezeichnet wird. Eine kurze Beschreibung auf der Microsoft Seite: https://www.microsoft.com/en-us/learning/online-proctored-exams.aspx erklärt das Ganze auch nochmal und dort habe ich auch dieses Video gefunden. Hier wird gezeigt welche Vorbereitungen dafür getroffen werden müssen, wie der Raum auszusehen hat, in dem man sitzt, wie man „überwacht“ wird und welche weiteren Rahmenbedingungen gelten. Das klang alles machbar, also habe ich bei der von mir gewählten Prüfung geschaut und tatsächlich gab es dafür die Möglichkeit, diese als Proctored Exam abzulegen.

image

Über Pearson VUE habe ich mich also durch die Anmeldung geklickt und konnte dort ohne Verzögerung für den gleichen Tag die Prüfung buchen. Es bestand sogar die Möglichkeit eine Prüfung bis 22:00 Uhr zu beginnen, für diejenigen, die sich so spät abends noch konzentrieren können. Ich selbst habe mir einen Termin am späten Nachmittag rausgesucht, der nur 30 min nach der Anmeldung lag und konnte nach der Bezahlung direkt beginnen.

imageVor der Anmeldung sollte man unbedingt einen Testlauf machen, um festzustellen, ob der Rechner für die Ausführung der Software geeignet ist. Aber das wird alles während des Anmeldevorgangs beschrieben. Nach der Installation der Software PVProctor ging es los. Ein „Greeter“ (offizielle Bezeichnung) meldete sich zwei Minuten nach Eingabe des Prüfungscodes und führte mit mir den Check-in zur Prüfung durch. Dazu wird über die Kamera ein Bild von Gesicht und Ausweis gemacht. Ich hatte bereits im Vorfeld einen Großteil aller losen Blätter und Notizen weggeräumt, also gleich die Gelegenheit genutzt, den Schreibtisch mal wieder aufzuräumen und auszumisten. Mit der Kamera musste ich dem Proctor den Schreibtischbereich genau zeigen. Da wurde dann auch nochmal der ein oder andere Gegenstand bemängelt, den ich auch noch wegräumen musste, meine Stifte zum Beispiel. Trinkflasche und Becher musste ich genau in die Kamera halten und einen 360° Schwenk durchs Zimmer machen inklusive der Decke und dem Boden. Damit kennt Pearson VUE jetzt mein gesamtes Büro. Mir wurden nochmal die speziellen Prüfungsrichtlinien erklärt. Während der gesamten Prüfung:

  • muss mein Gesicht im Kamerasichtfeld bleiben
  • niemand darf das Zimmer betreten
  • ich darf nicht reden
  • das Handy darf nicht benutzt werden oder sogar in Greifweite liegen, aber im selben Raum musste es sein für den Fall technischer Probleme

Wird eine dieser Regeln nicht eingehalten, wird die Prüfung abgebrochen und gilt dann als nicht bestanden. Wer also nicht sicherstellen kann, ungestört zu sein, sollte sich besser für das Testcenter entscheiden. Der gesamte Vorgang hat ca. 10-15 Minuten gedauert und dann ging die eigentliche Prüfung los.

Ein bisschen eigenartig war es dann schon, vor dem Laptop zu sitzen und zu wissen, dass ich durch die Kamera beobachtet werde und im Hinterkopf Gedanken wie: „Hoffentlich klingelt jetzt keiner!“ oder „Bloß nicht zu viel bewegen, damit man nicht aus dem Bild kommt.“ Da hat man in einem Testcenter mit Kamera an der Decke schon mehr Bewegungsfreiheit.

Für die eigentliche Prüfung habe ich dann nochmal eine gute Stunde gebraucht. Wie im Testcenter auch, gab es direkt nach Beenden der Prüfung das Ergebnis mit der erleichternden Mitteilung: „Bestanden“. Damit war das Proctored Exam abgeschlossen und „Big Brother“ hat mich wieder verlassen.

Ich habe so zu den üblichen vier bis sechs Stunden zum Ablegen einer Prüfung nicht mal ganze zwei gebraucht und konnte sie zu einem Zeitpunkt ablegen, der mir passte. So spät hätte ich in einem Testcenter vermutlich keinen Termin mehr bekommen. Ich werde diesen Weg für weitere Prüfungen definitiv wieder in Betracht ziehen.

Das Beste zum Schluss: Ich bin mit der bestandenen Prüfung jetzt Microsoft Certified Solution Expert (MCSE) Data Management and Analytics.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Content Management @eBiz

Veröffentlicht am 19.01.2018 von Alexander Müller , Insights@ebizcon , Custom Development

Etwas mehr als zwei Jahre ist der Relaunch unserer Unternehmens-Website nun her. Zunächst als moderne Seite mit weitgehend statischem Inhalt konzipiert, veränderten sich über die Zeit die fachlichen Anforderungen an die Website. Das eBiz-Team wuchs, neue Projektreferenzen kamen hinzu und die Stellenausschreibungen wandelten sich. Ohne ein geeignetes Tool wurde die Datenpflege zum Zeitfresser neben dem Projektalltag. Wie jeder eBiz-Mitarbeiter erhielt ich in meiner Einarbeitungsphase ein internes Projekt, in meinem Fall war es die Entwicklung eines rudimentären Content-Management-Systems (CMS) für die eBiz-Website

Warum ein eigenes CMS?

Zu Beginn des Projekts entschieden wir uns gegen die Verwendung eines out-of-the-box Alleskönner-CMS und für die Entwicklung eines eigenen, auf unsere Bedürfnisse zugeschnittenes CMS. Zum einen weil Flexibilität im Funktionsumfang und ein leichtgewichtiges Tooling für uns im Fokus standen zum anderen, weil bei uns die Weiterbildung der Mitarbeiter in den unterschiedlichen Technologien und in der agilen Softwareentwicklung ebenso eine Triebfeder für solche internen Projekte sind.

Agil - Muss das sein?!

Als mir mitgeteilt wurde, dass wir in diesem Projekt SCRUM als Vorgehensmodell einsetzen, war ich zunächst skeptisch. Schließlich waren die ersten Anforderungen überschaubar und das Entwicklungsteam bestand nur aus einer Person, nämlich mir selbst. Das kam mir für ein solch kleines Projekt zunächst sehr aufgebläht vor. Im Nachhinein betrachtet, war es für ein Lernprojekt dieser Art genau das Richtige für mich. Zwei Kollegen trieben in den Rollen Scrum Master und Product Owner das Projekt voran. Das Product Backlog füllte sich, die Definition of Done wurde festgehalten, der Sprint wurde geplant (der Scrum Master wurde hier für Schätzungen auch schon mal zum Teil des Entwicklungsteams), User Stories mit Hilfe von Akzeptanzkriterien wurden abgenommen und Sprint Reviews abgehalten. Dies alles mit richten Mischung aus Lockerheit und der notwendigen Professionalität.

Was habe ich gelernt?

Was die agile Projektdurchführung angeht, musste ich feststellen, dass ich, trotz meiner anfänglichen Zweifel, auch im kleinen Stil ein gutes Verständnis für das agile Vorgehensmodel erlangen konnte. Zwar war mir die Theorie im Vorhinein bekannt, doch in der Praxis werden viele Dinge viel klarer und die Sinnhaftigkeit bewusster.

Technologisch gesehen, arbeitete ich mit alten Bekannten, wie ASP.NET MVC, Entity Framework, jQuery und Bootstrap, aber auch mit mir neuen Technologien und Services, wie Azure SQL, Azure BLOB Storage, Azure AD-Authentifizierung und Azure App Services. Zusätzlich konnte ich mich auch mit dem Thema Continuous Deployment in den Visual Studio Team Services (VSTS) auseinandersetzen. So etablierte ich für die automatisierten Deployments in unsere Test- und Live-Umgebungen einen automatisierten Build-, Release- und Genehmigungsprozess.

Fazit

Insgesamt hat das Projekt sehr viel Spaß gemacht und den gewünschten Lerneffekt gebracht. Nebenbei ist auch noch ein kleines CMS entstanden, mit dem wir nun neue Seiten anlegen und Inhalte pflegen können. Und so sieht das dann aus:

Admintool-Screenshot

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

eBiz Weihnachtscruise

Veröffentlicht am 05.01.2018 von Lena Liman , Event , Insights@ebizcon

Zu unserer diesjährigen Weihnachtsfeier belohnten wir uns mit einer schönen, geselligen Abendfahrt auf dem Main. Mit an Bord waren gute Stimmung, leckeres Essen und natürlich heißer Glühwein.

image

Wie jedes Jahr fand im Vorfeld unserer X-Mas Sause das letzte Company Meeting des Jahres statt. Neben Updates aus den aktuellen Projekten, arbeiteten wir gemeinsam an den Inhalten für unsere Homepage (www.ebizcon.de).
Als erste kleine Weihnachtsüberraschung wurden alle eBiz Mitarbeiter im Verlaufe des Company Meeting mit einer Nacken- und Rückenmassage durch www.relaxcompany.de verwöhnt. An den Gesichtern und Reaktionen der Kollegen ließ sich ablesen, dass diese Aufmerksamkeit der Geschäftsführung super ankam und die halbe Stunde Entspannung jedem nachhaltig guttat.

Das weihnachtliche Company Meeting endete etwas früher als die Anderen, so dass jeder noch Zeit hatte sich für den Abend einzustimmen und fertig zu machen. Gegen 18 Uhr trafen wir uns dann auf dem Frankfurter Weihnachtsmarkt. Hier konnten wir uns gemeinsam auf den weiteren Abend einstimmen. Natürlich gab es auch – passend zur Weihnachtszeit – einen Glühwein, um die Wartezeit zu überbrücken.

Pünktlich um 19:30 Uhr konnten wir dann an Bord unseres Ausflugsschiffes für diesen Abend gehen – die MS Palladium. Das Schiff war restlos ausgebucht und es herrschte eine weihnachtliche Stimmung an Bord . Um 20:30 Uhr hieß es dann: „Leinen los“, wir legten ab und kreuzten auf dem Main von Schwanheim zurück nach Offenbach. Durch die großen Panoramafenster bot sich eine wunderbare Aussicht auf die Frankfurter Skyline. Das Buffet war reichhaltig und sehr lecker und für Musik wurde auch gesorgt.

image

Mir hat es super gefallen und den Kollegen sicherlich auch. Es war ein wundervoller Abend, den ich mit tollen Kollegen verbringen durfte. Alles in allem war es ein schöner Ausklang des Jahres 2017 und ich freue mich riesig auf das nächste spannende Jahr bei der eBiz.

Allen Kollegen, Freunden, Kunden und Menschen, die diesen Beitrag lesen, wünsche ich alles Liebe und Gute für 2018.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Hub.Berlin Digitalisierung im Rampenlicht

Veröffentlicht am 08.12.2017 von Hieronymus Deutsch , Event , Collaboration , Digitalisierung

Hub.Berlin vereint Schlüsselpersonen der Industrie, Politik und 500 + Startups um über die digitale Transformation zu diskutieren. Die eBiz war dieses Jahr mit 2 Kollegen des neuen Berliner Standortes dabei.

clip_image002 Am 28.11.2017 kamen über 150 Referenten und mehr als 3.000 Besucher zusammen, um die Herausforderungen der Digitalisierung und mögliche Anwendungen neuer Technologien zu besprechen und zu demonstrieren. In der Station Berlin, welche für dieses Event in 7 Bereiche unterteilt wurde, konnte man sich den ganzen Tag über Trends informieren und mit Startups sowie Industrieexperten reden.

Wie die Technologien eingesetzt werden, wurde nicht nur in der Tech-Arena präsentiert, sondern konnte an den Ständen einiger Unternehmen auch direkt ausprobiert werden.

image Virtual Reality Brillen fanden Einsatz in der digitalen Kunst und in der medizinischen Produktsimulation. Drohnen nahmen über den Menschen 360° Filmaufnahmen, Roboterarme kopierten menschliche Bewegungen und man konnte sich in ein autonomes Konzeptauto setzen. Besonders interessant fand ich die Tatsache, dass viele Unternehmen mit Virtualisierung und Augmented Reality arbeiten, um ihre Prozesse zu verbessern und um noch enger mit ihren Partnern zusammenzuarbeiten. Das Thema Mixed Reality wird und hat bereits zum Teil einen großen Einfluss auf die Kerngebiete der eBiz: Team- und Systemintegration. Ich bin gespannt, welche Anwendungsfelder sich hierfür noch finden werden. Ich kann mir gut vorstellen, dass in wenigen Jahren die Meetings unserer Berliner und Frankfurter Kollegen zusammen an einem virtuellen Tisch stattfinden.

IoT, Edge-computing, Smart Factory, Smart Services und künstliche Intelligenz haben auch große Auswirkungen auf die Digitalisierung und waren deshalb auch ein großes Thema bei der Hub.Berlin. Accenture hat dazu beispielsweise auf der Innovation Stage sehr interessante Vorträge und Panel-Diskussionen gehalten. So waren sich die Sprecher einig, dass die zweite Welle der Digitalisierung das Verstehen und die Monetarisierung von digitalen Daten ist

In der Policy Arena gab es Vorträge von Politikern und Professoren. Hier konnte man sich zu der digitalen Entwicklung des deutschen Schulsystems und den neuen Forschungsergebnissen im Bereich Quality of Live informieren. Am Nachmittag wurde hier auch über die „digitale Agenda“ geredet und mit dem Publikum diskutiert.

Die Hub war das perfekte Event für die eBiz, um sowohl die Menschen und Firmen zu treffen, die maßgeblich an der Digitalisierung beteiligt sind, als auch um uns über neue Trends und Entwicklungen zu informieren, die in der Integration für die eBiz in Zukunft eine Rolle spielen werden.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Partner & Microsoft - IAMCP WIT

Veröffentlicht am 02.11.2017 von Ireen Raue , Event , Collaboration

Am zweiten Konferenztag der #DPK17 gab es eine spezielle Veranstaltung FOR WOMEN ONLY.

Über die Mittagszeit wurde ein Lunch an runden Tischen mit maximal acht Frauen pro Tisch organisiert. In dieser lockeren Form führte Alexandra Hanke, die Gründerin der WIT-Gruppe Deutschland, durch die Session.

imageZum einen gab es einen Vortrag von Prof. Dr. Isabell Welpe von der TU München, die bereits in der Vision KeyNote einen sehr interessanten Vortrag zum Thema Cultural Change in Organisationen gehalten hatte. Ihr Thema in diesem Vortrag: „Sehen was andere nicht erkennen: Warum Originalität, Musterbrechen und eigene Wege Erfolg versprechen“ - ganz nach dem Motto: Erkenne die Entwicklung und sei immer einen Schritt voraus. Sie hat damit an das Thema aus der KeyNote angeknüpft und hier die Stellung der Frau in Wirtschaft und Technik etwas hervorgehoben, unter anderem auch die Selbstwahrnehmung und die Wahrnehmung durch andere.

Als Fun-Fact konnte ich unter anderem mitnehmen, dass: in Amerika schwere Stürme mit Frauennamen weit mehr Todesopfer zu Folge haben als Stürme mit Männernamen. Was zu einem großen Teil daran liegt, dass Stürme mit Frauennamen nicht so ernst genommen werden und die Leute sich viel später in Sicherheit bringen. Im anschließenden Panel standen spannende Frauen zum Thema: "Mentorship Circle - Getting Started!" im Fokus, so z.B. Alexandra Hanke (Vice President Stategic Alliances, Sycor GmbH). Im Anschluss daran gab es Möglichkeiten zum Austausch und Networking. Über ein paar unkonventionelle Fragen wie z.B. der Berufswunsch als Kind, wurde der Einstieg in eine Tisch-Vorstellungs- und Diskussionsrunde erleichtert.

image

Ganz allgemein zur WIT:

Women in Technology (WIT) ist eine gemeinsame Initiative der IAMCP (International Association of Microsoft Channel Partners) und der WPG (Microsoft Worldwide Partner Group). Unter dem IAMCP Dach finden und unterstützen sich globale WIT Communities weltweit.

Die deutsche WIT-Gruppe wurde erst vor einem Jahr im Oktober 2016 gegründet und ist eine Community innerhalb der Microsoft Partnerlandschaft.

http://www.iamcp.de/ueber-iamcp/wit/

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Smart World designed together - eBiz@DPK2017

Veröffentlicht am 02.11.2017 von Ronny Ulbricht , Event , Insights@ebizcon , Cloud , Collaboration

Größer als zuvor und ganz im Fokus der bestmöglichen Zusammenarbeit mit seinen Partnern, so präsentierte sich Microsoft mit der Deutschen Partnerkonferenz 2017 in Leipzig. Nicht weniger als zwei Messehallen in einer der sich am schnellsten entwickelnden, deutschen Städte boten den passenden Rahmen für eine inspirierende Konferenz. Das Thema - wohl eines der aktuellsten unsere Zeit – „Digitale Transformation“ stand dabei im Mittelpunkt.

image

Groß, Größer, #DPK17

Für die eBiz Consulting war es der erste Besuch auf der größten Partnerkonferenz von Microsoft in Deutschland und eines kann man schon vorwegnehmen, es war sicherlich nicht der Letzte. In diesem Jahr hatte Microsoft seine Partner nach Leipzig geladen und richtete die #DPK17 auf dem Messegelände im Norden der Stadt aus. Die Dimensionen dieses Ausrichtungsortes spiegeln auch die Dimensionen des ganzen Events, denn die Deutsche Partnerkonferenz 2017 war gleichzeitig die Größte ihrer Art und die größte Microsoft Veranstaltung nach der Inspire. Mit über 2.100 angemeldeten Teilnehmern, 114 teils hochkarätigen Speakern, 80 Sessions, Workshops und Roundtables, sowie 55 Showcases, Ausstellern und Sponsoren füllte man die zwei genutzten Hallen der Messe ganz gut aus.

image

Worum ging es auf der #DPK17

Thematisch könnte man die ganze Konferenz unter dem Motto „Der Weg in die Smart World ist ein gemeinsamer“ zusammenfassen, denn die Mitarbeiter und Speaker von Microsoft verpassten zu keinem Moment hervorzuheben, wie wichtig die Partner und die gute Zusammenarbeit mit den Partnern für Microsoft ist. Der Fokus von Microsoft ist es seine Partner so zu befähigen, dass die neue Mission bestmöglich umgesetzt werden kann.

imageAn dieser Mission und der damit verbundenen Vision richteten sich die Inhalte und die thematischen Schwerpunkte der gesamten Konferenz aus. Im wesentlich waren die Digitale Transformation, Modern Workplace Areas und Unternehmenskultur (Cultural Changes) zentrale Themenkomplexe die man bei den Ausstellern aber auch in den Sessions wiederfinden konnte.

Die gesamte Partnerkonferenz verteilte sich auf zwei Haupttage und einen Pre-Event der ganz im Zeichen von Internet of Things (IoT) stand und sich gut in die Gesamtstory einfügte. Über die gesamte Veranstaltung hinweg standen der Austausch zwischen Microsoft und den Partnern, sowie der Partner untereinander im Vordergrund. Die Deutsche Partnerkonferenz ist eben kein Event für Developer oder Techies, sondern eher mit dem Fokus Business und Networking. Trotzdem kann ich in meiner Rolle als Senior Technical Consultant sagen, dass man auch als Techie durchaus auf seine Kosten kommen konnte.

Microsoft organisierte die gesamte Veranstaltung so, dass seine Mission und auch die bereits länger laufende strategische Neuausrichtung des Unternehmens mit dem Ausbau kooperativer Cloud-Dienstleistungen als Cloud Plattform Provider, stets im Vordergrund standen. So gab es gerade im Bereich der Aussteller viele Informationen und Partner aus dem Cloud Service Provider Bereich, aber auch in fast jeder der Sessions wurde darauf hingewiesen.

Wer mehr über die konkreten Inhalte der einzelnen Sessions erfahren möchte, dem empfehle ich den Nachlesebereich der #DPK17 in dem nach und nach die Präsentationen und eventuelles Videomaterial zur Verfügung gestellt werden. Darüber hinaus gab es noch das #DPK17 Studio , die konferenzeigene Talkshow. Dabei entstanden 300 Minuten inspirierender Talks mit Microsofties und Partnern die man u.a. bei YouTube und Soundcloud nachhören kann.

Besonders zu empfehlen sind dabei die Keynotes des ersten und zweiten Veranstaltungstages, inklusive der angeschlossenen Panel-Diskussionen. Erste Ausschnitte finden sich unter dem oben aufgeführten Link und weiteres Material wird nach Aussage von Microsoft Deutschland folgen. In der Keynote des ersten Tages stellte u.a. die Microsoft Deutschland Chefin Sabine Bendiek die Mission und die Gedanken von Microsoft hinsichtlich der eigenen Strategie aber auch allgemein zum Thema Digitale Transformation in Deutschland dar. Es waren sehr inspirierende Vorträge, untermauert von drei beeindruckenden Case Studies (u.a. sporttotal und Govii) die verdeutlichten, was mit innovativen Ideen und Microsoft als starken Partner alles möglich ist.

Was gab es sonst noch?

Über die eigentliche Veranstaltung hinaus gab es zum Abschluss des ersten Tages noch eine #DPK17 Night in der Leipziger Kongresshalle die sich nicht hinter dem Event verstecken musste, nicht zuletzt wegen eines wirklich speziellen Gaststars. So sorgte niemand geringerer als Alt-Schlagerbarde und Neu-Rocker Heino über 70 Minuten lang für Unterhaltung und eine ausgelassene Stimmung.

Außerdem gab es im Rahmen der Initiative „Women in Technology“ (WiT) unter dem Dach des IAMCP noch eine spezielle Veranstaltung „FOR WOMEN ONLY“, dazu mehr in einem eigenen kurzen Beitrag von meiner Kollegin Ireen Raue.

Und nicht zuletzt seien noch die Give-Aways erwähnt die es bei einer solchen Veranstaltung eigentlich traditionell immer gibt. Nun für den Surface Hub hat es am Ende nicht gereicht, aber dennoch hat jeder Teilnehmer ein schönes Geschenk erhalten. So gab es für jeden Teilnehmer 6 x 12 Monate kostenlosen Premium Status für das vor kurzem von Microsoft erworbene Netzwerk LinkedIn geschenkt.

Fazit aus Sicht der eBiz

Welche Erkenntnisse lassen sich aus dem Besuch der Deutschen Partnerkonferenz 2017 von Microsoft für die eBiz ableiten? Wie bereits eingangs erwähnt ist eine wichtige Erkenntnis, dass diese Veranstaltung sich allein schon aufgrund der vielen Networking Möglichkeiten lohnt und wir daher sicher im nächsten Jahr wieder dabei sein werden. Darüber hinaus zeigt sich, dass die eBiz mit den Schwerpunktfeldern Systemintegration und Teamintegration (Collaboration) basierend auf dem Microsoft Technologie-Stack und seiner Expertise im Bereich Azure Cloud strategisch sehr gut aufgestellt ist. Microsofts strategische Neuausrichtung und die sehr glaubhaft vermittelte Mission mit dem Fokus auf die „Digitale Transformation“ in Deutschland lassen eine Vielzahl interessanter und herausfordernder Aufgaben erkennen, die auf uns und unsere Kunden zukommen. Hier kann die eBiz mit Ihrer Expertise und einer Microsoft als starken Cloud Plattform Provider im Rücken sicher einiges bewegen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

eBiz Kommunikationstraining - Teamwork, Präsentationen, Apfelwein

Veröffentlicht am 23.10.2017 von Ronny Ulbricht , Event , Insights@ebizcon , Collaboration

Im hübschen Stadtteil Frankfurts, in Alt-Sachsenhausen, hat sich die gesamte eBiz versammelt, um sich weiterzuentwickeln. Das Thema des diesjährigen Kommunikationstrainings drehte sich voll und ganz um Präsentation und den Umgang mit Lampenfieber. Der zwei Tage Workshop wurde angeleitet von Andreas Konzack (Chef von Redewendung!) und war unterteilt in mehrere Themenkomplexe: Atmung, Struktur, Wahrnehmung, Kontrolle. Stimme und Lampenfieber.

Tag 1:

Von unserem eBiz Büro im THE SQUAIRE am Frankfurter Flughafen sind es nur ein paar S-Bahn-Stationen bis nach Alt-Sachsenhausen. Trotz Anreise aus verschiedenen Regionen Deutschlands waren Alle pünktlich um 9:00 Uhr am Treffpunkt. Kaffee und Snacks standen zu Glück schon bereit. Nach einer kurzen Vorstellung des Coaches ging es auch sofort los mit der ersten Übung. Bei dieser war es die Aufgabe sich selbst, ein zuvor ausgewähltes Bild und seine Aufgabe bei der eBiz vorzustellen. Auch die Kollegen durften nicht untätig herumsitzen. Jeder sollte auf etwas Bestimmtes beim Vortragenden achten. Derjenige mit dem Handschuh sollte auf – man kann es erraten – die Gestiken und Handpositionen Acht geben. So hatte jeder seine Bereiche: Blickkontakt, Stand, Lautstärke, Stimme und Struktur. Der Sprecher hatte für seine kleine Präsentation 3 Minuten zu füllen. Natürlich lagen viele von uns weit unter der Zeit, dafür waren die Feedback-Runden nach jeder Präsentation um so intensiver. Es zeugt von einem guten Team, wenn man sich gegenseitig offen Feedback geben kann und dieses mit einem ehrlichen Dank entgegengenommen wird. Eine Lektion für mich war beispielsweise, dass meine Selbstwahrnehmung in Präsentationen stark von dem abweicht, wie es wirklich rüberkommt. So stelle ich mir zum Beispiel vor nervös und unruhig zu reden, wobei die Rückmeldung in der Feedbackrunde eher das Gegenteil bewies.

Den Abend haben wir gemeinsam in Sachsenhausen ausklingen und uns den lokal gebrauten Apfelwein munden lassen.

Essen

Tag 2:

Am zweiten Tag wurde auf unsere Wünsche und erkannten Schwächen vom Vortag eingegangen. Nachdem Pünktlich um 9:00 die Agenda des Tags vorgestellt wurde, hatten wir die Option zwischen vier Übungen. Die Präsentationen „zur unerwarteten Frage“, „spontane Selbst-vorstellung“, dem „Elevator-Pitch“ und dem „Bullshit-Bingo“ wurden jeweils wieder sehr genau beobachtet und hinterher ausgewertet. Die unerwartete Frage war für diejenigen, die ein Problem damit haben sich in Stresssituationen auf neue Gegebenheiten einzustellen. Es ist verständlicherweise nicht leicht die Frage „Würdest du für 10 Jahre ins Gefängnis gehen, wenn du dafür 10 Mio.€ bekämst?“ zu beantworten, wenn man nervös ist. Bei der spontanen Selbst-Präsentation ist es wichtig, sich auf den gegenüber einzustellen und ihn bei Interesse zu halten und seinen eigenen Benefit für den gegenüber zu erklären. Ähnlich übten wir beim Elevator-Pitch, sich schnell auf die nötige Argumentationsweise einzurichten und mit dem AIDA Prinzip sein Gegenüber von einer Idee überzeugen. AIDA steht für die englischen Begriffe Attention (Aufmerksamkeit), Interest (Interesse), Desire (Verlangen) und Action (Handlung). Sie basieren auf psychologischen Erkenntnissen zu Wahrnehmungsprozessen von Kommunikation. Da es für viele schwer ist, einzuschätzen welche Fachwörter im allgemeinen Sprachgebrauch vorhanden sind und welche nur in seinem Fachgebiet Verwendung finden, sollte das Bullshit-Bingo eine Wort-Wolke produzieren, die bei zukünftigen Präsentationen beachtet, vermieden oder erklärt werden sollten.

Nach diesen Übungen gab uns der Coach noch weitere Tipps, wie wir Lampenfieber mit richtiger Atmung überwinden, wie Körpersprache sich auf die Körperhaltung auswirkt und wie wir als Vortragende stabil und selbstbewusst vor Publikum und Zuhörern stehen. Außerdem ist es schier unglaublich, wie ein Korken im Mund zu einer deutlicheren Aussprache beitragen kann. Nach einer kurzen Feedbackrunde für den Coach war der Samstag – und damit das eBiz Kommunikationstraining 2017 – auch schon wieder um.

Trainer


Zusammenfassend kann ich sagen, dass trotz der unterschiedlichen Erfahrung aller Kollegen jeder etwas bei dem Training gelernt hat. Die offene Kommunikation und die Bereitschaft Feedback anzunehmen, hat einen sichtbaren positiven Einfluss auf das gesamte Team und den Zusammenhalt. Ich freue mich bereits heute auf das nächste Training und bin gespannt was wir mit Flaschen-Korken noch alles machen können.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Ebiz @ Oktoberfest Frankfurt 2017

Veröffentlicht am 22.10.2017 von Julia Krause , Event , Insights@ebizcon

Anfang Oktober hieß es für das ebiz Team mit einigen Projektkollegen: „O‘ Zapft is!“ unter dem Motto „Flieger Wiesn“ mit Tim Toupet und der Oktoberfest Band. Vielen Dank an dieser Stelle an Lena für die Organisation auch in diesem Jahr.

imageNach unserer Ankunft um 17.30 Uhr ging es erst einmal darum uns mit Hendl und Pommes zu stärken, das erste Maß gab es natürlich gleich dazu. Zuerst unterhielt uns die Oktoberfest Band mit bekannten Schlagerhits zum Mitsingen bis dann das Highlight des Abends Tim Toupet die Bühne betrat und uns mit seinen besten Hits wie „Ich bin ein Döner“ und dem „Fliegerlied“ zum Mitmachen und Schunkeln auf den Bänken animierte. 

Wie schon im letzten Jahr bestand unsere Truppe aus einem guten Mix an eBiz’lern und Kolleginnen/Kollegen unserer Kundenprojekte. Immer getreu dem Motto „Wer erfolgreich zusammen arbeitet, der kann auch gut zusammen feiern“.

Die Stimmung war entsprechend ausgelassen und es war ein rundum gelungener und schöner Abend. Spätestens um 24 Uhr - als die Zelte dann auch schlossen - machten sich auch die letzten, hartgesottenen Vertreter unserer Truppe auf den Weg nach Hause oder ins Hotel. 

Für mich war es das erste Oktoberfest in Frankfurt und ich kann sagen, dass ich dieses Event als gelungen empfand. Nicht zuletzt, weil man einige Kollegen auch einmal von einer privaten Seite erleben konnte. 

Ich freue mich jetzt schon auf das nächste Jahr!

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

eBiz Sommerfest 2017 - Raft, Grill & Chill

Veröffentlicht am 08.09.2017 von Lena Liman , Insights@ebizcon , Event

Wer hätte schon gedacht, dass ein wenig Paddeln so anstrengend sein kann!? Die eBiz feierte ihr diesjähriges Sommerfest nach dem August Company Meeting in Bingen und Ingelheim. Auf eine Rafting-Tour über den Rhein folgte ein entspannter Grillabend mit gutem Essen und gutem Wein.

Schon die Anreise zum Startpunkt der Rafting Tour gestaltete sich als erste kleine Hürde, da am Freitagnachmittag Stau und zähfließender Verkehr um Frankfurt herum angesagt war. Dadurch verspätete sich der Start zwar etwas, aber die Vorfreude und gute Laune der eBiz’ler konnte es nicht trüben.

Vor der körperlichen Anstrengung gab es aber erstmal eine Stärkung in Form von Kaffee und Kuchen. Während sich der Großteil der Mitarbeiter und deren Angehörige versorgten, wurden die Pkws zum Zielort gebracht und dann ging es auch endlich los.

Schwimmwesten an, die Boote zu Wasser, Frauen und Kinder zuerst.

DSC_7588 (Large)

Nach kurzer Einweisung ging es dann gemütlich los und jedes Boot konnte sich aufeinander einspielen. Danach wurden die Paddel-Fähigkeiten in kleinen Wettkämpfen auf die Probe gestellt und schnell zeigte sich, dass zwischen Theorie und Praxis oft Welten liegen. Im Verlauf der Bootsfahrt sollte dann auch noch ein Quiz zu Fakten um „Vater Rhein“ und die Region entlang des Rheinlaufs ausgefüllt werden. Alles in Kombination keine so leichte Aufgabe.

Die Tour verlief zumeist ruhig und sehr lustig, bis zu dem Zeitpunkt als ein Gewitter den Rhein heraufzog, uns direkt entgegen. Gerade rechtzeitig am Ziel angekommen, um die Boote noch aus dem Wasser zu bekommen und das Quiz auszuwerten, begann der monsunartige Regen. Ziemlich durchnässt machten wir uns auf den Weg ins Hotel WASEM nach Ingelheim. Dort gingen wir dann zum Grill & Chill Teil des Sommerfests über.

DSC_7734 (Large)

Die Location war fantastisch, wir hatten den Gewölbekeller des alten Weinguts ganz für uns. Es wurde für uns gegrillt und außerdem standen viele leckere Vorspeisen, Salate und Beilagen zum Grillgut bereit. Und natürlich gab es eine Auswahl toller Weine, die als Begleitung durch den kulinarischen Abend bereitstanden. Gegen 02.00 Uhr endete dann auch für die letzten noch Verbliebenen ein toller Abend und die Nachtruhe wurde eingeläutet.

Am nächsten Morgen trafen sich dann alle – mehr oder weniger ausgeschlafen – zum (Kater)Frühstück und tauschten nochmal die Eindrücke über das Erlebte aus.

Insgesamt war es wieder einmal ein gelungenes Fest und eine gute Gelegenheit, die Kollegen auch mal etwas privater kennenzulernen.

Mir jedenfalls hat es riesigen Spaß gemacht.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

SQL Server 2016 - Improvements: Temporale Tabellen

Veröffentlicht am 04.08.2017 von Ireen Raue , SQL Server , Custom Development , Data

Am 06.12.2017 und 07.12.2017 fand in Darmstadt die TechSummit von Microsoft statt. Wie auch letztes Jahr, waren wir wieder mit einigen Kollegen vor Ort. In diesem Jahr gab es allerdings im Gegensatz zum letzten Jahr deutlich weniger SQL Server Sessions. Eine davon beschäftigte sich mit den temporalen Tabellen, ein neues Feature des SQL Server 2016, das ich bereits kurz bei den SQL Days in Leipzig kennengelernt habe.

Temporale Tabellen

Es handelt sich dabei um eine aus meiner Sicht sehr nützliche Erweiterung des SQL Server 2016. Hiermit ist ohne größeren Aufwand eine Versionierung und Historisierung der Daten möglich.

clip_image002[7]

Code Snippet

ALTER TABLE dbo.Orders

ADD SysStartTime datetime2 GENERATED ALWAYS AS ROW START

CONSTRAINT P_ValidFromConstraint DEFAULT SYSUTCDATETIME() NOT NULL,

       SysEndTime datetime2 GENERATED ALWAYS AS ROW END

CONSTRAINT P_ValidToConstraint DEFAULT CONVERT (DATETIME2, '9999-12-31 23:59:59.9999999') NOT NULL,

PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)

GO

ALTER TABLE dbo.Orders

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Orders_History))

GO


Der Tabelle wird ein Start- und Enddatum hinzugefügt und die System-Versionierung muss eingeschaltet werden. Danach wird automatisch bei jeder Änderung ein Historiendatensatz anlegt.

Ein großer Vorteil ist hier auch, dass man über die Originaltabelle Abfrage des Datenstandes zu einem bestimmten Zeitpunkt machen kann, ohne selbst die History-Tabelle zu durchsuchen.


Code Snippet

SELECT * FROM dbo.Orders FOR SYSTEM_TIME AS OF '2016-10-27 15:47:00.3823880'

WHERE orderID = 10248


Allerdings sollte man hier immer ein Auge auf die Datenmenge haben, da diese Art der Versionierung bei häufigen Änderungen der Daten und evtl. auch noch sehr großen Datenmengen je Datenzeile sehr viel Platz benötigt.

Einige Einschränkungen:

Trigger

In die Historie Tabelle kommt das rein, was geändert wurde. Das bedeutet Datenmanipulationen innerhalb des Trigger Aufrufs werden in der Historie Tabelle nicht wiedergespiegelt.

Schemaänderungen

Solange keine Historie Eintrage gemacht wurden, ist das Löschen, Hinzufügen oder Ändern von Spalten uneingeschränkt möglich. Sobald Daten vorhanden sind, funktioniert nur noch das Löschen einer Spalte. Dabei wird die Spalte nicht nur aus der Originaltabelle, sondern auch aus der Historie Tabelle mit allen Daten entfernt.

Index

Um eine Indexierung der Historie Tabelle muss und sollte man sich dann auch selbst kümmern.

CREATE CLUSTERED COLUMNSTORE INDEX IX_OrdersHistory
ON dbo.OrdersHistory
WITH (DROP_EXISTING = ON);

Wer schon mal selbst eine Historisierung bauen musste, weiß sicher genau, wie aufwendig sowas werden kann. Deshalb halte ich diese Erweiterung des SQL Server 2016 für eine der Nützlichsten. Solange man den Plattenplatz im Auge behält oder am Anfang entsprechend mit plant, kann man mit den temporalen Tabellen eine ganze Menge Entwicklungszeit einsparen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Wasser und Licht

Veröffentlicht am 15.06.2017 von Clemens Kruse , Insights@ebizcon

Es ist Montagmorgen, ich sitze an meinem Arbeitsplatz, klappe meine Höllenmaschine von Laptop auf und Blicke gespannt zum Rascheln an der Tür. Der Chef stürmt rein, heute sieht er noch entschlossener aus als sonst. Ich gehe in Deckung.

"Student, ich habe von Deiner Bachelorarbeit geträumt! Es wird fett!" - "Jawoll, Chef!" – es ist schön hier.

Dass wir uns mit Chef und Student anreden ist ein Artefakt aus alten Tagen, da wir beide aus Firmen kommen, wo man das noch so gemacht hat.

Tatsächlich bin ich nicht von Anfang an hier. Ich begann mein duales Studium bei einem Unternehmen, dessen Name mir entfallen ist und sah mich dort bald an den Grenzen meiner Entwicklungsmöglichkeiten. Um meine Situation zu verbessern bewarb ich mich also bei der eBiz. Unter anderem. Am Ende hatte ich die Wahl zwischen Firmen in meiner Heimat Dresden (was unheimlich bequem gewesen wäre) und der totalen Blackbox - fremde Firma, fremde Stadt, wieder in eine WG ziehen (ich dachte eigentlich, aus dem Alter wäre ich raus), organisatorischer und nervlicher Stress.

Da brauchte ich nicht lange nachzudenken: Blackbox.

Das kann nun daran liegen, dass ich ein Teufelskerl bin und die Gefahr liebe. Aber eigentlich liebe ich die Gefahr nicht sonderlich. Tatsächlich gehe ich gern auf Nummer sicher, was die wichtigen Entscheidungen im Leben betrifft.

Und genau darum geht es: die wichtigen Entscheidungen im Leben. 2014 Nach meinem Ausflug in die Medieninformatik an der TU nochmal von vorn zu beginnen fällt sicherlich in diese Kategorie. Ebenso die Entscheidung, mitten im Studium den Praxispartner zu wechseln. Das sollte man nicht leichtfertig abtun.

Nach der Zusage der eBiz hatte ich innerhalb von 24 Stunden alles unter Dach und Fach. WG in Frankfurt organisiert, die Zelte in Dresden abgerissen und die Mutti um Verzeihung gebeten, dass ich mein Glück in der Welt suchen gehe, auch wenn mir ihre Nusstorte fehlen wird.

Und, habe ich es gefunden?

Mein Bauchgefühl hat mir gesagt, dass ich nach Frankfurt muss, wenn ich es ernst meine mit dem "sich entwickeln, Potenzial ausschöpfen und so" - also habe ich darauf gehört und bin jetzt seit einem Jahr Part of the Team . Ich werde jetzt immer auf mein Bauchgefühl hören.

Bei der eBiz hat man als Student alles was das Herz begehrt. Und ich rede nicht vom Kaffeevollautomaten, vom fancy Laptop oder der Xbox. Klar, das haben die dort auch. Aber die Dinge die ich eigentlich meinte, sind viel größer als das.

Für mich ist meine Firma der Nährboden auf dem ich als kleine Blume wachsen kann. Hier habe ich alles was man als Blume so braucht: Wasser, Licht und unbegrenzt Bohnenkaffee.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Geheimnisse sichern mit Azure Key Vault

Veröffentlicht am 01.06.2017 von Alexander Müller , Azure , Security

Da IT-Sicherheit in der heutigen Zeit immer mehr an Bedeutung gewinnt, gehört das Basiswissen über kryptografische Protokolle, Verschlüsselungsalgorithmen und Hash-Funktionen sowie deren kryptografische Stärke zum Basisrepertoire eines jeden Entwicklers. Mit dem aktuellen Trend zur Cloud stellt sich häufig die Frage wie dort Geheimnisse und Schlüssel geschützt werden können. Microsoft bietet dafür den Service „Azure Key Vault“ an.

Durch einen Vortrag auf der Technical Summit 2016 bin ich auf Azure Key Vault aufmerksam geworden. Da das Thema im Vortrag nur in einem Nebensatz erwähnt wurde, habe ich beschlossen mich näher damit auseinanderzusetzen und meine Erkenntnisse zu teilen.

Die Herausforderung

Als .NET-Entwickler hat man sich daran gewöhnt Connection Strings, API Keys etc. im Klartext in der Konfigurationsdatei der Anwendung (z. B. app.config) gleich neben den Anwendungseinstellungen abzulegen – meist einhergehend mit dem Gefühl, dass dies nicht der sicherste Ort dafür ist. Denn die Konfigurationsdatei wird in der Quellcodeverwaltung hinzugefügt und ist dadurch für das gesamte Entwicklungsteam, aber auch für alle anderen Personen mit Zugriff auf das Repository oder das Dateisystem, sichtbar. 

Azure Key Vault 

Mit Azure Key Vault bietet Microsoft einen Cloud Service an, mit dessen Hilfe geheime Schlüssel von der Anwendung separiert und an einem gesicherten Ort abgelegt werden können. So bleibt die Kontrolle über diese Daten beim Besitzer. Der Anwendung selbst wird bei Bedarf die Verwendung eines Schlüssels eingeräumt, jedoch nie direkter Zugriff darauf gewährt. Weiterhin wird jede Aktion in Azure Key Vault geloggt. Dieses Log kann zur Analyse von Monitoring-Systemen genutzt werden, um im Falle einer kompromittierten Anwendung, schnell gewarnt zu werden. Selbst im Fall der Fälle, können bei Verwendung eines Read-only Service Users keine Schlüssel durch die Anwendung geändert oder gelöscht werden.

Schlüssel und Geheimnisse

 image

In Azure Key Vault können Schlüssel und Geheimnisse gespeichert werden, doch worin liegt der Unterschied?

Mit Schüssel (keys) sind kryptografische Schlüssel zum Verschlüsseln und Entschlüsseln von sensiblen Daten in der Anwendung gemeint. Besonders zu schützende Schlüssel können direkt in Hardwaresicherheitsmodule (HSM) importiert oder dort generiert werden (Premium Service Tier notwendig, siehe auch Key Vault – Preise). Damit ist sichergestellt, dass diese nur innerhalb der Modulgrenzen bekannt sind.

In Azure Key Vault gibt es keine semantische Vorgabe, was als Geheimnis zählt und was nicht. Allerdings existiert eine Größenlimitierung von 25KB. Passwörter, API Keys, Connection Strings sind dort bspw. richtig aufgehoben. 

Schutz durch Azure Active Directory

Wie können Anwendungen nun auf die geheimen Daten zugreifen, ohne selbst wieder ein Geheimnis für den Zugriff auf Azure Key Vault preiszugeben? Die Antwort ist „Azure Active Directory“Authentifizierung. Die Anwendung wird im Active Directory registriert und authentifiziert sich dann mit Hilfe von ClientID und ClientSecret. Daraufhin ist der Zugriff auf den Key Vault, welcher sich im selben Active Directory befindet, möglich.

Aber wohin nun mit ClientID und ClientSecret? Beide können als Anwendungseinstellung in der Konfigurationsdatei der Anwendung gespeichert werden, sind dann jedoch wieder für jede Person mit Berechtigung auf Repository oder Dateisystem sichtbar. Zur Umgehung dieses Problems, gibt es zwei Lösungsansätze:

  1. Statt die Werte im Klartext in der Konfigurationsdatei zu speichern, werden „leere“ Einstellungen für ClientID und ClientSecret erstellt und die Werte selbst in den Anwendungseinstellungen im Azure Portal hinzugefügt. Dadurch werden vorhandene Werte zur Laufzeit durch die im Portal konfigurierten Werte überschrieben. Das Portal gilt als sicherer, da es in der Regel nur von einem eingeschränkten Personenkreis administriert wird und durch Zwei-Faktor-Authentifizierung zusätzlich geschützt werden kann. Dennoch, das Geheimnis ist im Klartext im Portal ersichtlich. 
  2. Mehr Sicherheit bietet die Authentifizierung mit ClientID und Zertifikat. Dies ist die sicherste Methode, da in Azure hinzugefügte Zertifikate nicht heruntergeladen werden können und der private Schlüssel nicht über die Oberfläche sichtbar ist. 

Fazit

Azure Key Vault ist ein Service, mit dem Schlüssel und Geheimnisse leicht zentral und separiert von der Anwendung administriert werden können. Laut Produktbeschreibung kann nicht einmal Microsoft selbst diese Daten einsehen. Der zusätzliche Programmieraufwand zur Verwendung des Service hält sich sehr in Grenzen, sodass der Aufwand auch für kleinere Applikationen gerechtfertigt werden kann. Besonders für Cloud-Anwendungen, in denen mit personenbezogenen Daten gearbeitet wird, sollte die Verwendung in Erwägung gezogen werden. Erste Schritte mit Azure Key Vault habe ich in diesem Sway dokumentiert. Eine Kostenübersicht für Azure Key Vault ist hier zu finden.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

SQL Server 2016 - Improvements: InMemory

Veröffentlicht am 01.05.2017 von Ireen Raue , SQL Server , Custom Development , Data

Seit Juni 2016 steht der SQL Server 2016 zur Verfügung und bringt eine Unmenge an Weiterentwicklungen und Verbesserungen mit sich.

Einen ersten groben Überblick dazu habe ich bei den ‚SQL TechnologieDay SQL Server 2016‘ der ppedv in Leipzig bekommen. Dort wurde sehr kompakt auf die Neuerungen eingegangen. Manche dieser Neuerungen sind sehr interessant und spannend, weshalb ich mich damit etwas intensiver beschäftigt habe.

Sehr viele Verbesserungen gab es vor allem im InMemory-Bereich. Da ich mich aktuell für den SQL Server 2014 mit diesem Thema beschäftige, war das eine der für mich sehr interessanten Neuerungen.

InMemory-Erweiterung

Die erste inMemory-Technologie wurde mit dem SQL Server 2012 mit dem ColumnStore Index eingefügt und von Version zu Version stetig erweitert.

image

Auch die Analyse bestehender Projekte auf Migrationsmöglichkeiten hat sich deutlich vereinfacht. Wo beim SQL Server 2014 noch über ein Data Warehouse und DataCollector eine Datenbasis zum Auswerten aufgebaut werden muss, kann der ARM-Report beim SQL Server2016 direkt auf den Produktivdaten ausgeführt werden. So ist ohne größeren Aufwand eine Analyse möglich.

image

Durch die Aufhebung vieler Einschränkungen bei der Migration zu InMemory-Tabellen oder nativly compiled Procedures wird es mit dem SQL 2016 auch deutlich einfach für bestehende Projekte diese Technologie einzusetzen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

DevOps - eine schöne neue Welt?

Veröffentlicht am 17.04.2017 von Florian Hieber , DevOps , ALM

Die DevOps Welt ist recht neu und mit agilen Ansätzen versehen. Theoretisch klingt das sehr gut, aber wie sieht es in der Praxis aus? Wie gut ist das Produkt, dass dabei herauskommt? Wo liegen die Schwierigkeiten? Ich versuche mich einmal an einer Betrachtung.

Microsoft propagiert seit Neustem die Prinzipien von DevOps – also dem Schulterschluss zwischen Softwareentwicklern (Developer) und IT-Betrieb (Operations). Noch vor einem Jahr gab es auf der Technical Summit 2015 Empfehlungen, die auf der diesjährigen Tech Summit wieder verworfen wurden. DevOps ist dieses Jahr das Trendthema schlechthin. Es gab sehr viele Vorträge, eine Keynote und eine Diskussionsrunde zu dem Thema. SCRUM, Canban oder gar klassische Vorgehensmodelle wurden noch nicht einmal angesprochen. Als zertifizierter Projektleiter und SCRUM Master bin ich naturgemäß an neuen Vorgehensmodellen interessiert. Dementsprechend verfolge ich den DevOps-Ansatz schon über ein Jahr mit Interesse.

Deshalb habe ich mich unter anderem auch dazu entschlossen, an der Tech Summit in Darmstadt teilzunehmen und dort einige Veranstaltungen zu diesem Thema zu besuchen. Gerade die Diskussionsrunde war sehr spannend, da auch einige Teilnehmer dabei waren, für die DevOps nicht nur graue Theorie war, sondern gelebtes Verhalten. Zwei Teilnehmer waren sogar aus der mittleren Führungsebene, die DevOps in ihr Unternehmen gebracht haben und die ihre Erfahrungen ebenfalls bereitwillig geteilt haben. Ein weiterer Teilnehmer war Administrator und konnte seine Erfahrungen mit DevOps ebenfalls vorbringen. Um es vorweg zu nehmen, es gab niemanden, der DevOps lebte und unzufrieden war. Aber was ist DevOps überhaupt?

DevOps ist eine Methodik, die Softwareentwicklung unter agilen Gesichtspunkten ansieht.

  • Entwickelt werden Produkte, es geht nicht um Projekte
  • Produkte werden durch Funktionen beschrieben
  • Projekte dagegen werden durch Kosten, Zeit und Annahmen der Funktionen beschrieben
  • Projekte dagegen beziehen den Auftraggeber nur sehr eingeschränkt ein
  • Zum Team gehören Betreiber und Entwickler des Produktes
  • Release-Zyklen sind sehr kurz (bis zu mehrmals täglich)

Die Idee, Betrieb und Entwicklung als zusammengehörige Einheiten zu betrachten, ist sicherlich gut, erfordert aber ein Umdenken im gesamten Unternehmen und nicht zuletzt bei den Beteiligten. Ein Prozess, der bislang auch in den Aussagen der Beteiligten noch nicht abgeschlossen ist. Der Gedanke, Produkte zu entwickeln und nicht Projekte zu definieren ist nicht neu, sondern wird bei allen agilen Methoden genutzt. Die Nachteile (keine Kostenschätzung möglich, keine Kontrolle des Funktionsumfangs möglich, etc.) sind immer noch in den Köpfen der meisten Mitarbeiter und der Führungsebene fest verankert. Dieses Denken steht der DevOps Methode auch entgegen. Neue Ansätze, wie eine engere Zusammenarbeit zwischen Betrieb und Entwicklung finden sicher schnell Gefallen im Unternehmen, mehrmals am Tag ein produktives System neu zu releasen aber ganz sicher nicht. Unternehmen, die DevOps einsetzen, stellen mehrmals am Tag ein Release ein. Damit der Prozess aber von anderen Abteilungen akzeptiert wird, nennen sie den Vorgang dann „Update“.

Ein „Release“ hatte bislang immer eine Besonderheit inne. Nicht nur aus der Gefahr, Fehler in den produktiven Betrieb zu bringen, sondern auch aus Marketing Gesichtspunkten. Ein Release war eine Neuerung, die vielleicht sogar preisliche, sicher aber funktionale Änderungen beinhaltete, die es wert waren, angekündigt zu werden. Auch das fällt mit DevOps weg.

Besonders die sehr kurzen Zyklen zur Bereitstellung neuer Funktionen am Produkt werfen aber die Frage auf, wie man in so kurzer Zeit verlässlich Testen kann. Um es vorweg zu nehmen, keine der beteiligten Parteien und auch die anderen Beiträge brachten mir da eine wirklich befriedigende Antwort.

In der Diskussion kamen viele Stimmen auf, die meinten, Tests (von Unit bis Systemtests) würden nichts bringen und nur Zeit und Geld kosten, deshalb hätten sie das Testen auf Akzeptanztests reduziert. Diesen Ansatz halte ich für problematisch, auch wenn es bislang laut der Anwesenden zu keinen großen Problemen gekommen sei. Die Gefahr, dass es zu solchen Problemen kommen kann, ist doch sehr hoch. Ganz zu schweigen davon, dass weder Qualitätskontrollen noch Zertifizierungen möglich sind. Quality Gates sind in den Köpfen vieler Menschen keine Kostenfresser, sondern unerlässlich, wenn man ISO-zertifizierte Qualität liefern will.

Auch sollen nach der Meinung von Microsoft keine Branches zu Testzwecken im Code Repository genutzt werden. Nach der Entwicklung (und Test) auf dem lokalen Entwicklerrechner geht es in die Produktion. Richtig ist das Argument der DevOps-Verfechter, dass normalerweise keine großen Änderungen in den Zyklen gemacht werden und deshalb ein auftretender Fehler auch schnell rückgängig gemacht werden kann. Was ist jedoch mit schleichenden Fehlern, die erst sehr spät auffallen, da sie sich auf Bereiche im Produkt auswirken, die man nicht im Fokus hatte? Ein Fehler, der erst nach Wochen, also nach mehreren Zyklen, auffällt ist durchaus möglich und nicht nur Theorie. Ob man dann auch noch so schnell reagieren kann?

Bislang konnte ich keine Person ausfindig machen, die wirklich negative Erfahrungen mit DevOps gemacht und die Methodik dann wieder verworfen hat. Insofern scheinen meine Zweifel nicht berechtigt, dennoch werde ich sie nicht los. Meine Berufserfahrung scheint meiner Gutgläubigkeit etwas entgegenzustehen.

Trotz meiner Zweifel bezüglich Test und Dokumentation finde ich die Methodik sehr interessant und würde gerne einmal eine Produktentwicklung mit DevOps unterstützen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz

Ein kleiner Einstieg in die Windows 10 IoT Welt

Veröffentlicht am 31.03.2017 von Ronny Ulbricht , IoT , Azure

Das Internet der Dinge (englisch: Internet of Things) wird gern als die nächste industrielle Revolution bezeichnet. Das Thema der „intelligenten Gegenstände“ hat in den letzten Jahren immens an Fahrt aufgenommen und ist mittlerweile sowohl im Enterprise als auch im Consumer Umfeld angekommen. Mit Windows 10 als Plattform, den Universal Windows Platform Apps und dem Azure IoT Hub mischt auch Microsoft kräftig mit.

clip_image002

Für die eBiz Consulting GmbH als Beratungsunternehmen und Integrationspartner für Software-Systeme, aber auch für mich persönlich als interessierter Entwickler ist das Thema „Internet of Things“ (IoT) schon länger auf dem Radar relevanter Trendthemen.

Meine Erfahrungen beschränkten sich dabei jedoch eher auf theoretisches Wissen aus verschiedenen Blog-Artikeln und anderen Publikationen sowie Samples, die ich bei Kollegen und befreundeten Entwicklern bestaunen durfte.

Im Rahmen der Microsoft Veranstaltung „Technical Summit 2016“ bot sich die Möglichkeit, an einem Tages-Workshop teilzunehmen und so in den praktischen Teil der IoT-Welt einzusteigen. Ich bekam einen ersten Überblick mit welchen Dingen man sich beschäftigen sollte und mit welchen nicht, wenn man sich in der Microsoft Welt des Internet der Dinge bewegt. Im Folgenden möchte ich diese Erfahrungen nun gern teilen.

Die richtige Idee

„Einfach mal so probieren“ mag im Bereich der Software Entwicklung ein probater Ansatz sein, um in neue Themen einzusteigen und sich auszuprobieren, am Ende liefert aber ein konkreter Anwendungsfall das höchste Motivationspotenzial. Eine halbwegs sinnvolle Idee sollte daher am Anfang aller Bemühungen stehen. Das ist schon deshalb notwendig, weil die benötigte Hardware mit einem finanziellen Investment verbunden ist, das sich je nach Ausstattung der Hardware (Anschlüsse, Sensoren) unterscheiden kann. Hier zum Beispiel eine Liste verschiedener Windows 10 IoT-fähiger Devices:

clip_image004

Eine naheliegende Idee ist beispielsweise das Auslesen und Weiterverarbeiten von Sensordaten einer Kaffeemaschine, einer Wetterstation oder das Ansteuern eines LED Displays zur Darstellung von Zustandsinformationen.

Wie den richtigen Einstieg finden?

Weiß man was man machen möchte, dann ist es zielführend sich Hilfestellung zu organisieren um geleitet in das Thema einzusteigen. Microsoft bietet für den Einstieg in die Windows 10 IoT-Welt einen „Get started“-Bereich im Windows Dev Center.

https://developer.microsoft.com/de-de/windows/iot/getstarted

Hier wird man mit Hilfe eines Wizards beim Aufsetzen des Devices unterstützt.

Wichtig ist, dass man sich im Vorfeld alle für Setup, Entwicklung und Deployment notwendigen Tools besorgt. Die meisten der Tools werden im Wizard erwähnt und verlinkt, hier jedoch noch mal eine Liste der Tools, die man auf jeden Fall haben sollte:

· Windows Assessment and Deployment Kit - Tools, zum Anpassen von Windows-Images

· https://github.com/ms-iot/iot-adk-addonkit/ - command line Skripte zur Paketierung und zur Image Erstellung

· Windows Driver Kit – enthält toolset zum Entwickeln, Bauen, Paketieren, Ausliefern, Testen, und Debugging von Geräte Treibern für die Windows Plattform

Der Wizard geht von der Verwendung der Standard-Images für die Windows 10 IoT-Editionen aus. Es besteht darüber hinaus noch die Möglichkeit eigene Images zu erstellen, um bestimmte Device-Voreinstellungen und andere Constraints setzen zu können, wie beispielsweise das Abschalten von Gerätefeatures. Dies ist bei einfachen Samples und wenigen Geräten nach Verwendung eines Standard-Images aber auch direkt über das Device selbst möglich und in dem Fall das empfohlene Vorgehen.

Nicht zuletzt, weil der Prozess der Erstellung von eigenen Images noch nicht wirklich ausgereift und daher fehleranfällig ist.

Anmerkung: Eine Übersicht über die Windows 10 IoT-Editionen und weitere Zusatzinformationen zu Windows 10 für das Internet der Dinge findet man unter:

https://www.microsoft.com/de-de/WindowsForBusiness/windows-iot

Universal Windows Platform Apps

Hat man das Setup seines Devices abgeschlossen und eine laufende Version von Windows 10 IoT deployed, so kann man sich an die eigentliche Aufgabe machen und seine App Entwickeln.

Grundsätzlich gibt es im Umfeld von Windows IoT nicht sonderlich viel zu beachten. Aufgrund des Konzeptes von Windows Universal Platform und der Universal Windows Platform Apps ist es einzig notwendig, dass die App für die richtige Prozessorarchitektur gebaut wird, um lauffähig zu sein, z.B. ARM für Raspberry Pi 2, Raspberry Pi 3 oder x86 für MinnowBoard Max.

Was eine Universal Windows Plattform App ist und vieles mehr dazu erfährt man unter:

https://msdn.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp

Für Apps, die Hersteller-spezifische Bauteile und Features nutzen wollen, benötigt man entsprechende Bibliotheken. So ist z.B. für das Pin Board und die Nutzung von GPIO das Windows IoT Extension SDK notwendig.

Wie man seine Apps auf das IoT-Device deployed kann man hier gut nachvollziehen.

https://developer.microsoft.com/en-us/windows/iot/Docs/appdeployment#csharp

Befindet sich das IoT-Device im Netzwerk mit Zugang zum Internet, kann direkt vom Device eine Verbindung zu Cloud Services oder ähnlichem aufgebaut werden und zwar bidirektional.

Azure IoT Hub

Last but not least bietet Microsoft mit dem Azure IoT Hub noch die Möglichkeit, die IoT-Devices zu verbinden, überwachen und zu verwalten.

Neben zahlreichen hilfreichen Features ist hier vor allem die Möglichkeit einer zuverlässigen, bidirektionalen Kommunikation mit dem Device der Grund, warum man sich Azure IoT Hub auf jeden Fall einmal ansehen sollte.

Zugang zum Azure IoT Hub findet man hier:

https://azure.microsoft.com/de-de/services/iot-hub/

Zu Testzwecken kann man sich kostenlos für den Dienst registrieren und bis zu 8000 Nachrichten am Tag für Testszenarien an seine Devices verschicken.

Kurze Schlussbemerkung

Mir persönlich hat der IoT-Workshop Lust gemacht, mich nochmal etwas praktischer mit dem Thema auseinander zu setzen. Natürlich weiter im Umfeld von Windows IoT, da mein technischer Fokus im Arbeitsalltag auch auf Microsoft-Technologien liegt. Aber auch die Möglichkeiten, die Microsoft Entwicklern bietet, sich kostengünstig dem Thema zu nähern, haben mich überzeugt.

Stellt sich nun die Frage, ob ich an die Elektronik unserer Kaffeemaschine darf ☺