Am Samstag, 22. April 2017 fand das weltweite Community-Event „Global Azure Bootcamp 2017“ statt. Auch in Österreich und zwar im Linzer Wissenstrum organisierte Rainer Stropek und sein Team dieses Ereignis. Es war ein schönes Erlebnis dort teilnehmen zu dürfen. Wir, d.h. Nahed Hatahet und ich durften gemeinsam das Thema „Microsoft Teams um smarte Bots erweitern“ vortragen.
Mein Teil des Vortrags war einerseits eine Live-Demo, die zeigt, wie man einen Bot grundlegend mit Visual Studio erstellt, und andererseits eine Demo, die zeigt, wie man einen Bot mit den kognitiven Diensten von Microsoft erweitert. Diese Demos möchte ich hier nochmals herzeigen und allen Interessierten damit den Anfang eigene Bots mit dem Microsoft Bot Framework zu erstellen, erleichtern. Da es sich um zwei Demos handelt, hab ich auch zwei Artikel vorbereitet, hier folgt nun Teil 1, der sich ganz einfach an dieses Thema annähert. 🙂
Damit stürzen wir uns auch gleich auf einen wichtigen Punkte, nämlich das Microsoft Bot Framework. Allen Interessierten sei diese Website ans Herz gelegt. Dort findet man alle Informationen rund um die Entwicklung. Die Doku ist wirklich schon sehr gut, bedenkt man, dass das Bot Framework immer noch im „Preview“ Stadium ist.
Zum einen ist es möglich mit NodeJS einen Bot zu entwickeln, zum anderen – und das wird die .NET Developer unter uns freuen – natürlich auch mit .NET und C# 😉 und da ich selbst aus der .NET Ecke komme, zeige ich die Demos natürlich mit C# und Visual Studio (2017).
Wenn man mit Visual Studio 2017 startet (oder auch mit Visual Studio 2015) dann sollte man sich zuerst einmal das Template für Visual Studio besorgen und ins lokale Templates Verzeichnis kopieren. Man findet ihn im Normalfall unter „C:\Users\<USERNAME>\Documents\Visual Studio 2017\Templates\ProjectTemplates\Visual C#“, außer man hat es in den Optionen von Visual Studio anders eingestellt.
Das Template selbst findet man unter den Ressourcen https://docs.botframework.com/en-us/downloads/#navtitle. Wenn man es von dort runtergeladen hat braucht man es nur in den besagten Pfad zu kopieren (als ZIP-Datei).
Ab diesen Zeitpunkt, kann dann ein Projekt auf Basis der Vorlage „Bot Application“ mit Visual Studio 201x erzeugt werden.
Bestätigt man den Dialog, dann wird ein Projekt angelegt, dass allen ASP.NET Entwicklern, die bereits MVC Projekte bzw. WebAPI Projekte implementiert haben, bekannt vorkommen wird. Denn eigentlich handelt es sich ja bei einem Bot um nichts anderes als einer WebAPI bzw. um einen Service-Endpunkt.
Neben der WebApiConfig.cs Datei, wo das Routing für die Lösung und das JSON Handling definiert wird, findet man auch eine MessageController Klasse, die von der ApiController Basis-Klasse erbt und somit den REST Endpunkt für das Posten von Nachrichten zum Bot darstellt. Darin enthalten ist bereits Code, den man auch gleich verwenden kann.
Aus der Projektvorlage wurde also ein einfacher Echo-Bot (Basic-Bot) erstellt, den wir nun als Grundlage verwenden können, um mehr Logik, d.h. Bot-Intelligenz einzuarbeiten. Zur Vorlage sei noch erwähnt, dass einige NuGet-Packages automatisch für das Projekt verwendet werden. Dazu gehören das Microsoft.Bot.Builder Paket (d.h. das Bot-Framework itself) und weitere nützliche Packages wie z.B. Newtonsoft.Json, Microsoft.AspNet.WebApi.Client usw. Wen es interessiert, der kann ja ganz einfach in Visual Studio den NuGet-Package Manager der Lösung aufrufen und einen Blick reinwerfen.
Damit man damit auch gleich mal starten kann, empfiehlt es sich, den Bot Framework Channel Emulator ebenfalls von der Bot-Framework Website runterzuladen (https://docs.botframework.com/en-us/tools/bot-framework-emulator/#navtitle). Damit ist es nämlich möglich komplett lokal auf einem Rechner zu arbeiten, ohne bereits den Bot in die Azure Cloud hochzuladen. Das erleichtert vor allem das Debuggen.
Wie man sieht hat der Bot Framework Channel Emulator vier „Teile“. Ganz Links oben „Enter your endpoint URL“ dort muss man die URL des Bots eingeben (bei mir ist das http://localhost/3979/api/messages). Darunter, der weiße Bereich ist zum Chatten gedacht. Rechts oben, stehen Details bezüglich der Messages die ausgetauscht werden und recht unten befindet sich das Log, wo alle Aktivitäten, die beim Chatten getätigt werden, protokolliert sind. Der Emulator selbst hört am localhost auf Port 57642 (das zeigt der Log-Bereich und dort der 1. Eintrag). An diese Adresse sendet der Bot dann in weiterer Folge seine Nachrichten, um sie im Chat-Bereich anzuzeigen.
Bei der Verbindung zum Bot, d.h. bei der Eingabe der URL des Bots erscheinen außerdem noch zwei wichtige „Punkte“ die man angeben kann. Die Microsoft App ID bzw. das Microsoft App Password des Bots. Wir erinnern uns, der Bot ist ja eine WebAPI, ein Rest Endpunkt und damit man „ihn“ in der großen weiten Welt auch verwenden kann, braucht „er“, wie jede andere App auch, eine ID und ein Passwort, damit er sich im Microsoft Azure Ökosystem auch „bewegen“ kann (Stichwort: OAuth2). Hier in meiner Development-Umgebung brauche ich das natürlich (noch) nicht, da ich ja defacto offline arbeite. Sobald wir aber den Bot registieren (https://dev.botframework.com/bots/new) wird dem Bot ein ID verpasst und auch ein Passwort.
Die ID und das Passwort müssen dann beim Bot C# Projekt in der web.config eingetragen werden. Wenn man „ihn“ dann noch auf einem Azure WebAPI Service deployed, dann kann man „ihn“ auch schon richtig verwenden. Der Bot selbst ist zwar dann noch nicht offiziell im öffentlichen Bot-Verzeichnis vorhanden, dazu muss „er“ von Microsoft selbst noch abgesegnet werden (das kennt man ja schon von der App Entwicklung), kann aber dennoch z.B. in eigenen Microsoft Teams verwendet werden. Das beschreibe ich dann im 2. Teil dieser Reihe. Um mit dem Bot Framework Channel Emulator und einem Bot, der z.B. in Azure schon deployed wurde arbeiten zu können, braucht man übrigens ngrok (steht auch im LOG Bereich, 2. Zeile :)). Wie das funktioniert kann im Blog Beitrag von Nahed nachgelesen werden.
Übrigens, der Port 3979 im obigen Screenshot ist nicht willkürlich gewählt worden, denn startet man den Bot in Visual Studio 2017 mit F5 dann wird der lokale IISExpress mit dem Port 3979 gestartet. Das und die Route /api/messages ergeben dann den Service-Endpunkt des Bots.
So und jetzt kann sich der Emulator auch tatsächlich darauf verbinden. Es werden zu Beginn einer Verbindung, zwei sogenannte „conversationUpdate“ System-Activities an den Bot gesendet. Auf diese muss man dann im Bot-Code extra reagieren. Dies kann hilfreich sein, um z.B. Aktualisierungen bezüglich der Konversation durchzuführen und darauf auch richtig zu reagieren (z.B. um zu signalisieren, dass ein Benutzer zu Konversation hinzugefügt oder entfernt wurde). Es gibt noch weitere System Activities, wie z.B. typing, ping, usw. die man per Emulatur auch direkt an den Bot senden kann. Das Handling muss für diese System Activities explizit implementiert werden. Ich gehe hier aber nicht näher darauf ein, um nicht den Rahmen dieser Demo zu sprengen.
Hat man nun den Emulator erfolgreich mit dem Bot verbunden kann man auch schon losgehen. Der nächste Screenshot zeigt das auch, ich begrüße den Bot und er gibt einfach den eingegebenen Text nochmals zurück und zusätzlich noch die Anzahl der Zeichen, die eingegeben wurden.
Klickt man jetzt noch auf den Link „Post 200“ Reply [message] dann kann man sich ansehen, was tatsächlich zwischen dem Bot-Framework und dem Bot Emulator ausgetauscht wurde.
Im JSON sieht man z.B. den Text und diverse IDs betreffend der Konversation, der Nachricht, bzw. des Absenders usw. Wenden wir uns jetzt aber nochmal ganz kurz dem C# Code zu, den wir hier durch die Vorlage automatisch erzeugt bekommen haben. Speziell möchte ich hier auf die Post Methode eingehen.
Ist die übermittelte Activity vom Typ Message, dann wird eine Antwort generiert. Ist sie das nicht, dann handelt es sich wahrscheinlich um eine System Activity und diese wird dann in der Methode HandleSystemMessage(activity) abgearbeitet. Wie bereits zuvor erwähnt muss man sich hier darum selbst kümmern, die Vorlage bringt hier nur die Method mit einer switch-case Anweisung mit, die man dann bei Bedarf selbst ausprogrammiert.
In unserem Fall wurde eine Message übertragen und nun kommt die Bot-Intelligenz zum Einsatz. Die ConnectorClient Klasse baut eine Verbindung zum Bot auf. Erkennbar ist das aufgrund des Parameters activity.ServiceUrl, d.h. die erhaltene Activity beinhaltet auch den Absender, in unserem Fall den Bot Emulator. Wie ich oben bereits geschrieben habe lauft bzw. lauscht dieser auf Port 57642 am localhost.
Die Bot-Intelligenz selbst besteht jetzt nur daraus, dass einerseits die Characters gezählt werden und andererseits der erhaltene Text nochmals in einem String bzw. in eine Activity verpackt wird (Activity reply = activity.CreateReply(„…“)). Das Ganze wird dann über den Connector und dessen Conversation zurückgeschickt (natürlich asynchron) :). Das wird dann natürlich noch mit dem HttpStatusCode 200, d.h. mit OK bestätigt und abgesendet. Das Ergebnis sieht man dann sehr schön nicht nur im Chat-Bereich sondern auch im Log Bereich des Emulators.
An dieser Stelle endet vorerst Teil 1. Im nächsten Teil werde ich das Wort Bot-Intelligenz etwas wörtlicher nehmen und die Microsoft Cognitive Services einbinden, denn diese implementieren für uns Services, die tatsächlich auf Basis von künstlicher Intelligenz Aufgaben wie z.B. Bild- und Gesichtserkennung übernehmen können. Also bis dahin und ich hoffe, ihr habt jetzt Lust mal selbst einen Echo-Bot zu implementieren. 🙂
