Microsoft Bot Framework

Das Microsoft Bot Framework mitsamt dem Bot Builder SDK, das für C# und Node.js verfügbar ist, bietet das Rüstzeug zum Senden und Empfangen von Nachrichten sowie eine Anbindung an verschiedene Chat Kanäle wie Facebook oder Skype. Weiters erleichtert es durch die Bereitstellung bereits vorgefertigter Hilfsklassen die Verwendung der Microsoft Cognitive Services.

Eine Übersicht über das Microsoft Bot Framework und dessen Schnittstellen ist in Abbildung 1 zu sehen.

Microsoft_Bot_Framework_und_dessen_Schnittstellen
Abbildung 1: Microsoft Bot Framework und dessen Schnittstellen

Bei den Microsoft Cognitive Services sind vor allem der QnA Maker sowie die Language Understanding Intelligent Services (LUIS) für die Bot-Kommunikation sehr hilfreich.

QnA Maker

Für die Erstellung eines neuen QnA Maker Services gibt es verschiedene Möglichkeiten. Die Knowledge Base kann erzeugt werden durch:

  • Die Angabe einer FAQ Website
  • Das Hochladen von FAQ Dokumenten
  • Die manuelle Eingabe der Frage Antwort Einträge

Mit der Knowledge-Base als Startpunkt können dann bei Bedarf Verbesserungen vorgenommen werden. Gibt ein Benutzer beispielsweise eine Frage ein, die nicht hinterlegt ist, werden die wahrscheinlichsten Alternativen zur Auswahl zurückgegeben. Wird eine dieser Alternativen vom Benutzer ausgewählt, erhält das System ein Feedback, welches zur Verbesserung beitragen kann. Ein Beispiel für diese Vorschläge ist in Abbildung 2 dargestellt.

Alternativen_bei_unbekannter_Frage
Abbildung 2: Alternativen bei unbekannter Frage

Eine weitere Möglichkeit zur Verbesserung ist es, den Bot zu trainieren. Hierbei kann man die besten Antworten auswählen und auch alternative Phrasen zu einer bestimmten Frage hinzufügen. Ein Beispiel hierfür ist in Abbildung 3 dargestellt.

Training_eines_Bots
Abbildung 3: Training eines Bots

Weiters können alle bestehenden Konversationen abgefragt und die Fragen sortiert nach Häufigkeit trainiert werden.

LUIS

Dieser Service analysiert die Bedeutung (Intent) und die dazugehörigen Objekte (Entities) von verschiedenen Aussagen. Abbildung 4 zeigt ein Beispiel, das die Bedeutung der Fragen (Intent) zu einer gewissen Person (Entity) behandelt.

Intents_und_Entities
Abbildung 4: Intents und Entities

Abbildung 5 zeigt, wie mit Hilfe des LUIS Service Portals Intents erzeugt werden können.

Intent_anlegen
Abbildung 5: Intent anlegen

Mit Hilfe dieser Trainingsdaten wird im nächsten Schritt eine bestimmte Wahrscheinlichkeit zugewiesen (siehe Labeled Intent in Abbildung 6).

Zugewiesene_Wahrscheinlichkeiten
Abbildung 6: Zugewiesene Wahrscheinlichkeiten

Das dabei erstellte Model kann danach für neue (auch unbekannte) Nachrichten die Wahrscheinlichkeiten berechnen.

Ist das Model fertig kann LUIS nun in der Bot-Implementierung verwendet werden. Als Einstiegspunkt bei jedem Bot dient der Messages Controller. Dieser ist in Abbildung 7 ersichtlich. Der Message Controller bekommt ein Activity Objekt übergeben. Ist das Activity Objekt vom Typ Message dann wird der LuisDialog aufgerufen. Andere Typen sind beispielsweise das Hinzufügen eines Chatteilnehmers oder das Beenden einer Konversation, auf welche wir hier nicht weiter eingehen.

Messages_Controller
Abbildung 7: Messages Controller

Die Nachricht wird dann über die REST Schnittstelle analysiert und je nachdem, welcher Intent am wahrscheinlichsten ist, wird der dazugehörige Task ausgeführt und eine entsprechende Rückmeldung an den Benutzer gesendet (siehe Abbildung 8).

LuisDialog
Abbildung 8: LuisDialog

Auch bei LUIS kann das Model stetig verbessert werden, indem bisherige Zuweisungen bei Bedarf korrigiert werden.

Advertisements

Was ist Microsoft AI?

Microsoft AI ist eine Sammlung von Services, Bibliotheken & Tools spezialisiert auf den Bereich der künstlichen Intelligenz. Die Plattform beinhaltet einfach zu verwendende, bereits vollständig konfigurierte Services sowie Tools mit denen komplexe, applikationsspezifische Modelle realisiert werden können. Microsoft AI kann in drei große Gruppen unterteilt werden:

Cognitive Services

In dieser Gruppe befinden sich vor allem Services, die die Mensch-Maschine-Kommunikation in verschiedenster Weise ermöglichen. Die Cognitive Services sind einfach zu verwenden und werden über REST Schnittstellen zur Verfügung gestellt. Die Integration kann meist mit sehr wenigen Codezeilen realisiert werden. Außerdem werden auch einige konfigurierbare Services angeboten. Ein Überblick über die verfügbaren Module ist in Abbildung „Verfügbare Module im Überblick“ zu sehen.

Blog_AI_Cognitive_Services
Abbildung: Verfügbare Module im Überblick

Azure Machine Learning

Eine Unterkategorie von AI ist das sogenannte Machine Learning. Die Azure Machine Learning Workbench bietet eine umfangreiche Umgebung mit einer Vielzahl an Tools zur Anwendung von gängigen Machine Learning Algorithmen. Außerdem verfügt das Programm über viele unterstützende Funktionen zur Vorbereitung der Daten sowie zum Veröffentlichen der erzeugten Modelle. Die Workbench kann auf dem lokalen Computer installiert werden und muss mit einer Azure Ressource verknüpft sein (siehe Abbildung „Azure Machine Learning“).

Blog_AI_Azure_Machine_Learning
Abbildung: Azure Machine Learning

Cognitive Toolkit

Deep Learning wird mit Hilfe des Cognitive Toolkits ermöglicht. Verschiedene Arten von Neuronalen Netzwerken können erstellt, trainiert und getestet werden. Durch eine Vielzahl an Konfigurationsmöglichkeiten kann eine hohe Präzision bei Vorhersagen mittels Neuronalen Netzwerken erreicht werden.

Ausblick

In den kommenden Wochen folgen weitere Blogeinträge zum Thema Microsoft AI, in denen auf ausgewählte Themenbereiche vertiefend eingegangen wird. Unter anderem wird gezeigt, wie mit Hilfe künstlicher Intelligenz ein Bot programmiert werden kann.

 

Microsoft SQL Server Master Data Services (MDM)

Einleitung

Master Data Services – kurz MDM – ist ein Bestandteil der SQL Server Produktpalette seit SQL Server 2008 R2 und hat sich in den letzten Jahren bis 2016 nur marginal weiterentwickelt. Dies lag vorwiegend daran, dass Microsoft den Schwerpunkt auf den Business Intelligence Stack gelegt hatte.

Mit dem Release von SQL Server 2017 wurde MDM grundlegend erneuert: HTML5 und neue Technologien tragen zu Stabilität und Akzeptanz bei.

Am Namen und der damit verbundenen, hohen Erwartungshaltung wurde (leider) nichts geändert: was dem Thema an sich zwar nicht schadet, aber für Erklärungsbedarf sorgt.

Was ist MDM und was sind die Herausforderungen, die damit gelöst werden sollen?

In der reinen Theorie ist MDM eine Grundsatzentscheidung dafür, seine Unternehmensdaten zentral zu verwalten, zu vereinheitlichen und dadurch die Grundlage für belastbare Aussagen/Auswertungen zu schaffen.

Auch 2017 sind Unternehmen noch immer damit konfrontiert, Daten aus einer Vielzahl von Systemen zu verwalten. Ist-Daten aus System A wollen in einer Auswertung mit Plan-Daten aus System B angereichert werden. Eine Verknüpfung ist meist aufwändig bzw. gar nicht möglich, da die Datensätze zwar logisch ident sind, aber aufgrund der Schreibweise trotzdem unterschiedlich sind (z.B. Halle8 <> Halle 08).

MDM Systemlösungen

Zur Umsetzung von MDM gibt es bereits viele Produkte: SQL Server, MUM, inubit, SAP MDM, Biztalk, etc. Viele davon bieten einen vordefinierten Bausatz an Funktionen, um sich dem Thema zu nähern.

Eine Standardlösung, ohne jegliche Zusatzprogrammierung, ist aber weder mit Produkt A noch mit Produkt B realistisch – auch wenn das gerne postuliert wird.

Die hohe Kunst im Bändigen von MDM besteht darin, die Verflechtung von organisatorischen und IT-technischen Aktivitäten a) bestmöglich zu koordinieren und b) ein Tool zu verwenden, das die Abläufe und Datenflüsse bestmöglich visualisiert und beim Bearbeiten von Dateninkonsistenzen unterstützt.

Eine optimale MDM-Lösung ist ein Zusammenspiel aus Systemkomponenten (IT) und organisatorischen Verantwortlichkeiten (Fachbereich), bei dem nicht das IT-Tool im Vordergrund steht. Vielmehr ist das Bewusstsein für ein integratives, workflowbasiertes „Doing“ zu beachten.

MDM Projektansatz bei PASO Solutions

Ein Ansatz, den wir bei PASO Solutions in MDM-Projekten bereits erfolgreich umsetzen konnten, wird in folgender Architekturskizze beleuchtet.

  1. Vorsysteme tauschen Daten über eine sog. Datendrehscheibe – kurz DDS – aus, welche in der Regel als relationale Datenbank realisiert wird. Dadurch ist gewährleistet, dass die Daten mittels SQL-basierten Tools abgelegt und analysiert werden können. Auch dateibasierte Schnittstellen (z.B. XML) können mittels EAI-Tools (vgl. inubit, BizTalk) in die DDS überführt werden.
  2. In der DDS gibt es ein mehrstufiges System zur Datenqualitätsabsicherung. Dazu werden die Rohdaten zuerst in einem sog. Staging-Bereich gesammelt. Neuartige, noch nicht validierte Datensätze werden vom Staging-Bereich in den MDM-Bereich transferiert. Sie haben somit den Status DATEN_UNGEPRÜFT.
  3. Im MDM-Bereich erfolgt die klassische Validierung, insb. auf Dubletten und Inkonsistenzen. Dazu werden Standardalgorithmen wie bspw. Fuzzy-Logic und sog. Mapping-Tabellen herangezogen, um Datensätze zu identifizieren und in unterschiedliche Problemklassen einzuteilen. Der neue Status ist nun DATEN_KLASSIFIZIERT.
  4. Mittels automatisierter Berichte (vgl. SSRS-Abonnements) ist es möglich, Dateninkonsistenzen periodische an sog. Clearing-Stellen zu berichten. Solche Prüfberichte können mittels HTML-Links in webbasierte MDM-Systeme verbinden, um den Korrektur-Ablauf für die Benutzer bestmöglich zu gewährleisten.
  5. Manuell nachbearbeitete Datensätze werden vom MDM zurück an die DDS geliefert und überführen die Datensätze in den nächsten Datenqualitätsstatus DATEN_VALIDIERT.
  6. Über eine konfigurierbare Signal-Funktion werden von der DDS die validierten Daten an andere Systeme weitergeleitet (Trigger-basiert).
Blogeintrag_MDM
Architekturskizze

Vorteile durch MDM mittels Microsoft SQL Server Stack

Microsoft SQL Server bietet neben der klassischen relationalen Datenbank viele weitere Services out-of-the-box. Neben den bekannten Themen wie Analysis Services (SSAS), Reporting Services (SSRS) und Integration Service (SSIS) drängen nun verstärkt die neuen, exotischen Services in den Vordergrund:

Machine-learning Services (vormals R-Services) und Master-Data-Services bilden im Verbund mit den tradierten Services ein optimales Toolset, um den MDM Projektansatz umsetzen zu können.

Mittels MDM können im Clearing-Center durch Machine-learning-Services vorvalidierte Datensätze nachbearbeitet werden, um dann mittels Integration Services zwischen den Datenqualitätsstufen transferiert zu werden.

Alles aus einer Hand, mit einem Toolset und zu einem lukrativen Preis, insbesondere dann, wenn Microsoft-SQL-Server-Lizenzen bereits vorhanden sind, nahezu kostenfrei.

Conclusio

MDM Services von Microsoft ist eine Komponente, um MDM erfolgreich umzusetzen. Aber erst das Zusammenspiel des kompletten SQL Server Stacks ermöglicht eine umfassende und integrative Behandlung des Themas. Organisatorische Rahmenbedingungen (Clearing-Stelle) und Workflow-basierte Abarbeitung sind das A und O, um die Komplexität zu beherrschen.

SAP HANA und Microsoft BI: a true love-story?

Mit der neuen SAP HANA In Memory Technologie ist nun auch ein einfacher Zugriff auf SAP-Daten möglich.

Dazu gibt es im Microsoft BI Umfeld interessante Möglichkeiten, um an wertvolle ERP-Informationen zu gelangen

1. Zugriff mittels PowerBI Desktop

In der Self-Service-BI Suite „PowerBI Desktop“ ist ein Zugang mit dem neuen SAP HANA Connector möglich.

Zuerst ist es aber erforderlich, die SAP HANA ODBC Treiber für Windows zu installieren. Diese können unter https://support.sap.com/en/my-support/software-downloads.html direkt von SAP bezogen werden. Hier ist eine S-ID Voraussetzung, die man vom unternehmensinternen SAP-Admin erhalten kann.

Sind die ODBC-Treiber installiert, kann mit wenigen Klicks eine Verbindung zum HANA Server aufgebaut werden. Single-Sign-On und Berechtigung im SAP sind hier Voraussetzung.

Ist die Berechtigungshürde gemeistert, kann auf die entsprechenden Entitäten im HANA Datenbankmodell zugegriffen werden. Eine detaillierte Anleitung findet sich unter dem BI Channel von PowerBI https://www.youtube.com/watch?v=Zpbh6UE3pSE

2. Zugriff über SAP-PO und ETL

Ein Zugriff auf SAP Daten funktioniert am besten über die Schiene SAP PO (Process Orchestration) bzw. dem Vorgänger-System PI (Process Integration: https://de.wikipedia.org/wiki/SAP_Process_Integration ).

Dabei werden die SAP-Daten mittels PO auf eine unabhängig Datendrehscheibe (DDS) transferiert. PO kümmert sich nur um die erste Meile (von SAP zur DDS) und um die letzte Meile (von DDS nach SAP). SAP PO kann dabei auf BAPI, RFC sowie neue HANA Methoden zugreifen.

Die Datenextrakte werden mittels SQL-Statements auf Basis von JDBC direkt in eine SQL-basierte DDS geschrieben. Bspw. können mit einem SAP-Report alle FI-Belege eines Geschäftsjahres extrahiert werden. Diese Daten greift die PO auf, generiert ein SQL-Insert-Statement, welches dann auf die DDS abgesetzt wird. Sobald der Extraktionsvorgang fertig ist, ruft die PO eine Stored-Procedure auf der DDS auf, welche die Fertigmeldung absetzt und Folgeprozesse anstößt (bspw. den Weitertransport von der DDS in das DWH).

Hinweis: die PO/PI ist asynchron, d.h. man muss einen „Wait-On-PO“-Job anstoßen, der solange wartet, bis alle Daten aus der PO in die DDS übertragen wurden. Das ist zwar nicht ganz schön, funktioniert aber insofern charmant, weil die PO vor dem Übertrag nach DDS weiß, wie viele Datensätze ankommen sollen. Der WaitOnPO-Job wartet dann solange, bis in der DDS diese Anzahl an Datensätzen angekommen ist.

Alle anderen Schritte der klassischen ETL-Strecke – also Transformation/Harmonisierung und Datenkonvertierungen sollen in dafür spezialisierten EAI-Tools gemacht werden (inubit, SSIS, etc.).

Aus heutiger Sicht ist die PO leider zu schwerfällig und benutzerunfreundlich.

PowerBI-Reportserver: Was steckt wirklich dahinter?

Mit Juni und später mit August 2017 stellte Microsoft seine Antwort auf die Konkurrenz durch Qlikview und Tableau vor: Lokale Berichterstellung mit Power BI-Berichtsserver (https://powerbi.microsoft.com/de-de/report-server/)

Versprochen wird eine Verknüpfung der neuen Self-Services-Features, die seit 2016 durch Power BI Desktop bekannt sind, kombiniert mit den mächtigen Standard-Reporting-Funktionen der Reporting-Services aus dem SQL Server Stack. Damit können moderne, interaktive Berichte on-premise den unternehmens-internen Benutzern zur Verfügung gestellt werden.

Look&Feel sowie Funktionalität halten auf den ersten Blick die Versprechungen einer „Self-Service-BI und Enterprise-Berichterstellung – in einer Komplettlösung“. Berichte, die mittels einer speziellen Power BI Desktop-Version gewohnt intuitiv erstellt werden, können mit wenigen Klicks auf der Reportwebsite bereitgestellt werden. Bekannte PowerBI Rendering-Elemente stehen ebenso zur Verfügung wie exotischere Varianten von Stacked-Bars und Funnel-Diagrammen. Außerdem können bestehende paginierte Standardberichte Seite an Seite auf dem Power BI-Reportserver veröffentlicht werden. Das von QlikView vorzelebrierte Rendering ohne Fullsite-Postbacks ist in der gänzlich HTML5 basierten Power BI Reportserver-Umgebung exzellent umgesetzt. Das Warten auf bestimmte Ereignisse bereitet dank asynchroner Webabrufe kaum Probleme. Die Berichts-Visualisierung ist am Smartphone, Tablet und PC ohne zusätzliche Programmierung möglich.

Zu all dem Licht gehört leider auch ein wenig Schatten: um eine vollständige Konkurrenz zu den großen Playern im on-premise Self-Service darzustellen, fehlt leider die letzte Konsequenz. Was sicher auch der ersten, Microsoft-Philosophie folgenden „unvollständigen“ Preview-Version zu schulden ist. Gerade die bekannten Features „Abonnement“ und „Security-Einstellungen“ aus SSRS fehlen, um einen vollwertigen Einsatz in Organisationen zu ermöglichen. Auch die Einschränkung auf multi-dimensionale Datenquellen (SSAS) stellte im „June“-Release eine größere Einstiegshürde dar – gerade dann, wenn Kerberos und Server-Hoping unbekanntes Terrain ist.

Mit dem „August“-Release sind mittlerweile auch relationale Datenquellen verfügbar.

Eine Empfehlung ist an dieser Stelle schwierig:

Auf der einen Seite ist der erste Wurf (der Konkurrenz geschuldet) zu schnell erfolgt: wie bei vielen Microsoft-Produkten!

Durch das frühe Release ist es zwar möglich, die Zielrichtung zukünftiger Funktionen abzuschätzen. Dennoch ist von einem produktiven Einsatz in ergebnis-orientierten Organisationen aus heutiger Sicht abzuraten.

Auf der anderen Seite ist ein frühes Auseinandersetzen mit den neuen Power PI Funktionen durchaus sinnvoll. Gerade unendliche Erweiterungsmöglichkeiten durch R und CustomVisuals legen die Grundlage für moderne Reporting-Plattformen, die nicht mehr nur reine Datenfriedhöfe sondern moderne Self-Service-Reporting-Shops realisieren.

SQL Server 2017 SSIS Catalog und Project Connections

SSIS Catalog ist eine zentrale Ablage von SSIS-Paketen, die nun mit Click-Once Deployment direkt aus dem Visual Studio auf den SQL Server veröffentlicht werden können.

Im Zuge der zentralen Ablage können nun auch Project-Connections verwendet werden, die so für alle Packages einer SSIS-Projektes verwendet werden können.

Beim Deployen von SSIS-Paketen, die auf Project-Connections verweisen, ist darauf zu achten, dass vorher auch die in diesem Paket verwendeten Project-Connections veröffentlicht werden.

Das Veröffentlichen von Project-Connections funktioniert leider nicht singulär, sondern es muss die gesamte SSIS-Projektmappe veröffentlich werden.

Unbenannt

 

POWER BI REPORT SERVER

Technical Preview:
Funktionsumfang & Einschränkungen

Die am 17.05.2017 vorgestellte Power BI Report Server Preview (Blog Announcement) erweitert die bisherigen SQL Server Reporting Services. Zu den unterstützten Berichtstypen gehört nun neben den vorhandenen Berichttypen, Paginierter (RDL) und Mobil (Datazen), auch der Power BI Bericht.

pbrs
Produktvergleich

Bisher war Power BI fast gänzlich in der Cloud. Entweder durch benutzen des Power BI Online Portals bzw. Azure Power BI Embedded konnten die Berichte zentral gespeichert und gerendert werden. Mithilfe von Power BI Desktop und SQL Server Reporting Services (welches die Power BI Berichte nur ablegen jedoch nicht darstellen kann) konnte man zwar die Cloud umgehen war aber dadurch auch sehr eingeschränkt. Die On-Prem Enterprise Lösung bietet nun der Power BI Report Server.

Konfiguration

Um den Power BI Report Server zu installieren ist ein installierter SQL Server notwendig. Weitere Voraussetzungen sind unter Reportserver System Requirements detailliert aufgelistet.

Über den Installer kann der Power BI Report Server installiert werden (Downloadlink). Nach erfolgreicher Installation muss das Ganze noch über den Report Server Configuration Manager konfiguriert werden. Diese Konfiguration ist ident mit dem Reporting Services Configuration Manager. Falls bereits SSRS installiert ist muss darauf geachtet werden verschiedene Zugriffs URLs festzulegen, da beide dieselben Standardeinstellungen verwenden. Eine detaillierte Anleitung zur Installation & Konfiguration findet man unter folgendem Link:  Reportserver Installation

Workflow

Über das Webportal und Power BI Desktop können nun Berichte hinzugefügt, erstellt und verwaltet werden. Hierbei zu beachten ist, dass dazu derzeit eine spezielle Version von Power BI Desktop für die Erstellung zu verwenden ist. Diese kann unter demselben Link wie die Report Server Installationsdatei heruntergeladen werden. Der Workflow ist sehr ähnlich wie bei den anderen Berichtstypen. (Handbuch)

Einschränkungen

Eine wesentliche Einschränkung der aktuellen Version ist, dass derzeit nur Berichte mit einer Live-Verbindung zu Analysis Services unterstützt werden.

Zusammenfassung

Der neue Power BI Report Server unterstützt nun alle Berichtstypen des Microsoft Technologie Stacks. Da Power BI Berichte vom Funktionsumfang, Interaktivität und Usability sich in gewisser Weise von den anderen Berichtstypen absetzen und auch deren Weiterentwicklung von Microsoft stark vorangetrieben wird ist eine On-Prem Unterstützung ein logischer und notwendiger Schritt um sich als Standard für Berichte zu etablieren.