1. Inhalt
2. Abstract
3. Uebersicht / Inbetriebnahme
4. Deconcentrator-JS
5. Database
6. Database Microservice
7. RASA Trainieren
8. Cache
9. Update Wetter Microservice
10. Geoservice Erweiterung des Wetter Microservices

Die folgende Liste zeigt die Erweiterungen, welche in diesem Semester umgesetzt wurden.

• BeuthBot Master Repository erstellt um die Organisation des Projektes zu vereinfachen.
• Dokumentation des Master Repository, Erweiterung der bestehenden Dokumentation.
• Ersetzen des Deconcentrators durch Deconcentrator-JS.
• Einbauen einer Persistenz:

  • Realisierung eines passenden Models für die Persistierung der Daten.
  • Implementierung des Database-Controllers welcher eine MongoDB nutzt um die User Daten zu speichern.
  • Implementierung des Database-Microservice welcher Datenbank-Anfragen auflöst und sie durchsetzt.
• Einbau Cache in Registry.
• Umbau / Verbesserung des Weather-Microservice:

  • Formatierung der Antworten
  • Refactoring des bestehenden Codes
  • Einbau von zeitbezogenen Daten
  • Einbau von ortsbezogenen Daten

Wie dem Zwischenbericht entnommen werden kann, hatten wir am Anfang ziemliche Schwierigkeiten das gesamte Projekt in Betrieb zu nehmen. Jedes Repository musste einzeln gecloned werden und danach jede Komponente einzeln gestartet werden. Aus dieser Not haben wir ein Master-Repository erstellt, welches die einzelnen Module als Git-Submodules beinhaltet. So ist es nun möglich mit einem einzigen Befehl das gesamte Projekt zu laden. Das Projekt kann unter dem Link https://github.com/beuthbot/beuthbot angeschaut werden.

# clone project
$ git clone --recursive https://github.com/beuthbot/beuthbot.git

# or with ssh
$ git clone --recursive git@github.com:beuthbot/beuthbot.git

# change into directory
$ cd beuthbot

# edit environment file
$ cp .env.sample .env && vim .env

# create docker network
$ docker network create beuthbot_network

# start BeuthBot
$ docker-compose up -d

# check whether the gateway is running on port 3000
$ curl http://localhost:3000          # prints: Hello from BeuthBot Gateway

Der Deconcentrator-JS übernimmt die gleiche Aufgabe wie der Deconcentrator und ersetzt diesen. Die Entscheidung den Deconcentrator auszutauschen kam daher, dass es uns am Anfang des Semester nicht möglich war, den Deconcentrator aus dem vorherigen Semester in Betrieb zu nehmen. Auch nach langer Beschäftigung und der Hilfe eines Studenten aus dem letzten Semester blieben Erfolge aus. Da dieses Projekt noch weiter entwickelt werden und somit ein einfacher Einstieg und eine überschaubare Komplexität gewährleistet werden soll, erschien es uns also sinnvoll den Deconcentrator durch den neuen Deconcentrator-JS auszutauschen. Ein weiterer Faktor bestand darin, dass der alte Deconcentrator in Python geschrieben war. Eine Vorgabe des Projekts ist aber die Verwendung der Programmiersprache JavaScript. Mehr Informationen über den Deconcentrator-JS befinden sich hier im Wiki. Das Projekt kann unter dem Link https://github.com/beuthbot/deconcentrator-js angeschaut werden.

Neue Funktionen oder Microservices müssen dem BeuthBot „beigebracht“ werden. Konkret für Rasa heißt das, dass es neue Trainings-Daten braucht aus denen das Model generiert werden kann. Dieses Model nutzt Rasa zur Laufzeit um Anfragen zu interpretieren. Am Anfang des Semesters haben wir bereits ein funktionierendes Model und die dazugehörigen Trainings-Daten vorgefunden. Die Trainings-Daten wurde mit Hilfe von Tracy generiert. Tracy wird mit einem Web-Interface bedient. Man kann dort Sätze und Entities eingeben aus denen sich Trainings-Daten generieren lassen welche dann exportiert werden können. Die Daten wurden damals manuell eingegeben. Als wir das Model erweitern wollten, hätten wir diese Daten wieder manuell eingeben und ergänzen müssen. Da dies nicht praktikabel erschien haben wir nach alternativen Lösungen gesucht und eine gefunden. Chatito ist ein Tool mit dem wie bei Tracy Trainings-Daten generiert werden können. Der Unterschied ist das bei Chatito die Daten nicht manuell über ein Web-Interface eingeben werden, sondern mit einer DSL (Domain Specific Language) in *.chatito-Dateien definiert werden. Chatito generiert dann aus einer beliebigen Anzahl gegebener .chatito-Dateien die Trainings-Daten welche dann von Rasa genutzt werden können um das Model zu erstellen. Die Chatito Dateien liegen im Rasa Projekt im Ordner /training/app/input.

Eine Anleitung zum Trainieren eines neuen Models ist hier in diesem Wiki. Die gleiche Anleitung und mehr Informationen befinden sich in der TRAINING.md Datei des Rasa Projektes.

Der Wetterservice ist ein Dienst, welche aktuell über den Telegram Client angesprochen wird. Dabei kann der Service per Chat einfach angesprochen werden ohne das der User im Vorfeld etwas einrichten muss. Dieser Dienst antwortet dabei auf Fragen, welche das Wetter im Allgemeinen, aber auch im Stündlichen betreffen, ebenso wie das vergangene Wetter. Aktuell ist eine Anfrage von bis zu 7 Tage in der Zukunft, sowie 5 Tage in der Vergangenheit möglich. Ab 47 Stunden in der Zukunft kann der Bot nur noch mit dem allgemeinen Wetter antworten, sprich keine stündliche anfrage.

Node.js( https://nodejs.org/en/ ) Express.js( https://expressjs.com/de ) Axios.js( https://www.npmjs.com/package/axios ) OpenWeatherMap( https://openweathermap.org )

Open Weather Map ist eine Api, welche einem die Möglichkeit bietet Wettervorhersagen abzurufen. Dabei bietet sie 4 verschiedene Arten von Calls: /weather → Aktuellen Wettervorhersage /onecall → Aktuellen Wettervorhersage, bis 7 Tage in die Zukunft /forecast → Wettervorhersage bis zu 5 Tage in die Zukunft /history → Wettervorhersage bis zu 5 Tage in die Vergangenheit In dieses Service wurden /onecall und /history verwendet, da /forecast nur 5 Tage in die Zukunft geht und auch nur in 3 Stunden abständen. Ebenso wurde /weather nicht genommen, das nur das aktuelle Wetter zurückgibt, welches in /onecall schon enthalten ist. Um diese Api nutzen zu können muss erst einmal ein Key auf der Seite generiert werden, welcher dann am Ende jeweils als Parameter an die URL angehängt werden muss.

Hier wird die Request vom Service registry aufgenommen und eine Response erstellt und gesendet. Als erstes wird die Request in message und Ort aufgeteilt. Daraufhin wird der Ort, welcher in der Request mitgesendet wurde in Längen.- und Breitengrad via eines Geoservices umgerechnet und wieder gegeben. Dies muss passieren, da die OpenWeatherMap Api bei einigen Anfragen nicht die Ortschaft selbst, sondern nur die Latitude und longitude nimmt. Ist kein Ort in der Request vorhanden wird standardmäßig Berlin oder der durch die Persistenz abgespeicherte Wohnungsort genommen. Daraufhin wird geprüft, ob die Request eine Uhrzeit enthält, um festzustellen ob eine allgemeine oder eine zeitspezifische Anfrage gestellt wurde. Bevor die Bearbeitung anfängt, wird vorher festgestellt, ob das Angefragte Datum auf dem Rahmen fällt, sprich z.B. zu weit in der Zukunft. Ist alles Regelkonform, wird festgelegt, in welchem Zeitraum das Wetter angefragt wird, welches dann an den richtigen Codeblock weitergeleitet wird. Im Block angekommen wird als erstes immer ein Api Call an OpenWeatherMap über die Datei weatherService mit dem Datum und den Koordinaten getätigt, welches dann in der Variable weather gespeichert wird. Danach werden weather( Response vom api call ), date( Datum ) und city( Stadtname ) an generatedMessage und die jeweilige Methode weitergeleitet, welche dann die fertige Nachricht zurückgibt. Diese wird letztendlich als Response an des User weitergeleitet.

Diese Datei besitzt zwei Methoden, welche jeweils mit axios einen Api call an OpenWeatherMap machen und diesen zurückgeben. Beide Funktionen benötigen jeweils die Koordinaten des gefragten Bereiches. Die Methode getForecast gibt ein JSON zurück in welchem das aktuelle, das stündliche und das tägliche Wetter befindet, welche dann später in generatedMessage.js wiederverwertet werden. Die Funktion getHistory hingegen benötigt noch die spezifische Zeit als long Wert und gibt ebenfalls ein JSON zurück, allerdings nur mit dem exakt gefragten Moment, sowie ein Objekt mit den Stündlichen vergangenen Wetterdaten.

Diese ist die zuletzt aufgerufene Datei, in welcher drei Methoden existieren, welche den Response Text für Telegram zusammenstellen. Jede Funktion benötigt die Parameter weather( Response vom weatherService.js api call ), date( Datum ) und city( Stadtname ). Es müssen diverse Zeitformate erstellt, bzw. angepasst werden, welche dann in der Response eingefügt werden. Ebenso befindet sich in der Response von OpenWeatherMap ein Icon String, welches dann in folgende Text Icons umgewandelt wird: ☀️, ⛅, ☁️, 🌧️, 🌦️, 🌩️, ❄️, 🌫️. Diese ganzen umgewandelten Daten werden daraufhin in einen fest definierten String integriert und als messageText zurückgegeben.

Dies ist eine Chatanfrage ohne dabei einen spezifischen Ort zu nennen. Wenn keine Ort genannt wird, wird standardmäßig der Sitzt der Beuth Hochschule, also Berlin genommen oder aber der User hat seinen Wohnort gesetzt, dann wird dieser genommen, es seiden die Geo Api kenn diesen nicht.

Bei dieser Chatanfrage wurde zusätzlich die Uhrzeit mit angegeben. Wenn es sich um die nächsten 47 Stunden handelt, dann wird dementsprechend ein Response mit der Uhrzeit gesendet. Überschreitet das Datum allerdings 47 Stunde, so wird es wie eine allgemeine Anfrage gehandhabt.

Wir ein Ort, allerdings keine Uhrzeit mit geschickt, so handhabt der Bot die Anfrage wir im ersten Bild, nur das er denn mitgesendeten Ort nimmt, es seiden die Geo Api kennt diesen nicht, dann wir standardmäßig Berlin genommen.

Wird neben der Uhrzeit noch ein Ort gesendet und überschreitet es nicht 47 Stunden in die Zukunft, kann der Bot da Wetter an dem Ort mit der spezifisch mitgesendeten Uhrzeit zurückgeben, vorausgesetzt die Geo Api kennt diesen auch.