• Tobias Belkner
• Lukas Danckwerth
• Jan Fromme
• Denny Schumann

Es wurden verschieden Github Projekte wie, Telegram Bot, Gateway, Deconcentrator, Rasa, Registry, Weather, Scraper( Öffnungszeiten ) und Mensa vorgefunden. Jedes dieser Projekte besaß seine eigene docker-compose.yml file. Die in jedem Projekt vorgefundenen .env Dateien waren wie zu erwarten leer, leider wurde in der Dokumentation nicht beschrieben wie diese zu befüllen sind. Zudem existierte ein Token, welcher für den Telegram Bot benötigt wurde. Ebenso konnte der Bot nicht vollständig ausgeführt werden, da der Service Deconcentrator fehlerhaft war. Auch konnte die virtuelle Maschine, welche zur verfügung gestellt wurde nicht standart gemäß ausgeführt werden. Leider wies die Dokumentation einige Lücken, im bezug auf das starten des Bots auf, wodurch es zu vielen Selbstrechergen und verzögerungen kam. Auch fehlte die Zugangsberechtigung des Servers, auf dem der Bot lief, da es ein “privater” Server eines Studenten gewesen war.

Es wurde anfangs versucht alle Docker-Container der einzelnen Services des Bots lokal zu starten. Dabei musste erst einmal herausgefunden werden welche URLs bzw. welcher Token zu benutzen war. Da wir keinen Token in der bereits vorhandenen Dokumentation finden konnten bzw. es keinen hinterlegten gab, wurden übergangsweise mehrere Test-Tokens mit BotFather erstellt. Ebenso wurde versucht die Container sowohl auf Windows, also auch auf Linux zu starten. Daraufhin wurde versucht das Image des Beuth Bots auf einer virtuellen Maschine zu starten. Um dies ausführen zu können musste Anfangs erst einmal die Datei mit lz4 dekomprimiert werden. Dafür musste erst einmal das Github lz4( https://github.com/lz4/lz4 ) gedownloadet und ausgeführt werden, welches einige Zeit in Anspruch nahm. Danach wurde die kvm Datei mit qemu zu einer vdi Datei konvertiert, damit VirtuelBox diese Datei akzeptiert. Nach dem erfolgreichen starten der virtuellen Maschine gab es das Problem, dass das Passwort nicht richtig war, welches uns gegeben wurde. Letztendlich musste dies mit folgenden Codezeilen umgangen werden:

mount -o remount,rw /
passwd
# passwort eurer wahl eingeben
# oder, müsste auch gehen:
passwd --delete
mount -o remount,ro /

Nun wurde der Beuth Bot gestartet, konnte allerdings nicht in Betrieb genommen werden, da dieser keine Netzwerkverbindung nach draußen hatte. Daraufhin wurde uns ein Server auf der Beuth zur verfügung gestellt, auf welchem der Beuth Bot letztendlich laufen sollte. Nachdem dieser dort versucht wurde eingerichtet zu werden, fehlte es dem Server an zugewiesenem Speicher, was erst behoben werden musste um den Bot vollständig installieren und in Betrieb nehmen zu können. Es konnten nach der Behebung des fehlenden Speichers letztendlich fast alle Docker-Container erfolgreich gestartet werden, bis auf den Service Deconcentrator, welcher sich erst nicht richtig starten ließ und als er lief nicht funktionierte. Nach mehreren Wochen der Versuche diesen Service zum laufen zu bekommen entschieden wir uns in Absprache mit Herrn Ziemer diesen zu verwerfen und einen neuen Deconcentrator zu schreiben.

Aktuell Ist der Beuth Bot vollständig in Betrieb genommen, dank des neu geschriebenen Deconcentrators. Ebenso liegt dieser nun, auf einem für uns zugreifbaren Server, welcher dort erfolgreich in Betrieb genommen wurde. Auch wurde er nun ermöglicht den gesamten Bot, welcher 8 Services beinhaltet mit zwei docker-compose files zu starten. Das Projekt wurde nun in 2 Git Submodule unterteilt, welche in Zukunft leichter bearbeitet werden können. Ebenfalls wurden sowohl in diesem Semester zu bearbeitende, also auch zukünftige Projektideen erschlossen. Die Arbeitsteilung der einzelnen Gruppenmitglieder wurde durchgeführt und ein Zwischenbericht wurde angelegt.

• was werden wir tun?

Starting this project we found the following structure:

• Complex Project Structure
• Bad documentation of final state. So we …
• Focused to long on the image of virtual machine
• Bad documentation of JSON format of messages
• Running out of space on Virtual Machine
• Current Situation with the Corona Virus

• Complete Documentation
• „Kick out“ the `deconcentrator` and `scraper`
• Create a master project containing the packages as submodules

https://github.com/beuthbot/beuthbot

https://github.com/beuthbot/deconcentrator-js

Model of an incoming message.

Model of an answer from deconcentrator.

Install BeuthBot on a virtual machine:

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

# change into directory
$ cd beuthbot

# initialize submodules
$ git submodule init

# clone all submodules
$ git submodule update

# edit environment file
$ vim .env

# start BeuthBot
$ docker-compose up -d

Install Telegram Bot on a virtual machine:

# clone with HTTPS
$ git clone https://github.com/beuthbot/telegram-bot.git

# change into directory
$ cd telegram-bot

# edit environment file
$ vim .env

# start Telegram Bot
$ docker-compose up -d

Current output of `docker ps` on virtual machine:

CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                              NAMES
881848bfaa3c        beuthbot_gateway            "docker-entrypoint.s…"   55 minutes ago      Up 54 minutes       0.0.0.0:3000->3000/tcp             beuthbot_gateway_1
c5ef1f78da2f        beuthbot_deconcentrator     "docker-entrypoint.s…"   55 minutes ago      Up 55 minutes       0.0.0.0:8338->8338/tcp             beuthbot_deconcentrator_1
992d5ed6d94b        beuthbot_registry           "docker-entrypoint.s…"   55 minutes ago      Up 55 minutes       0.0.0.0:9922->3000/tcp             beuthbot_registry_1
62e0bf7e2c8d        rasa/rasa:1.6.0-spacy-de    "rasa run --enable-a…"   55 minutes ago      Up 55 minutes       0.0.0.0:5005->5005/tcp             beuthbot_rasa_1
b33f342d24fd        beuthbot_weather            "docker-entrypoint.s…"   55 minutes ago      Up 55 minutes       8000/tcp, 0.0.0.0:9951->7000/tcp   beuthbot_weather_1
8beba8a324e8        beuthbot_mensa              "docker-entrypoint.s…"   55 minutes ago      Up 55 minutes       0.0.0.0:9950->8000/tcp             beuthbot_mensa_1
75b7b5653577        telegram-bot_telegram-bot   "docker-entrypoint.s…"   2 hours ago         Up 2 hours                                             telegram-bot_telegram-bot_1
7d9e26988632        rasa/duckling:0.1.6.2       "duckling-example-ex…"   24 hours ago        Up 24 hours         0.0.0.0:8000->8000/tcp             beuthbot_duckling_1

Damit der Benutzer sich selbst nicht ständig wiederholen muss, wird ihm die Möglichkeit geboten, seine Vorlieben zu speichern. Als Datenbank haben wir uns für die MongoDB entschieden.

Die Motivation hinter dem Cache besteht darin, dass externe API's, wie z.B. die WetterAPI, welche in dem Beuthbot Projekt benutzt wird, nur begrenzt Zugriffe zulassen. Daher müssen die Anfragen durch ein Cache begrenzt werden, um wiederholte Anfragen an die API zu limitieren und im Cache abzulegen. Ein positiver Effekt des Caches wird auch sein, dass Zeit gespart werden kann, weil unnötige Anfragen an die Services erspart bleiben.

Damit die Anfrage gecached werden kann, muss diese zuvor von dem Deconcentrator interpretiert werden, um die korrekte Intention hinter dieser Anfrage zu verstehen, da die Anfrage des Benutzers jedesmal anders formuliert sein könnte. Diese Intention gibt der Registry an, an welchen Microservice diese Anfrage geschickt werden soll und erhält auch die Antwort des jeweiligen Microservices. Um doppelte Anfragen in zu kurzer Zeit zu verhindern, ist die optimale Stelle für den Cache bei der Registry.

subject to change

Ebenfalls wurden weitere Mirko Service Ideen für denn zukünftigen Beuth Bot entwickelt welche da wären:

Dieser Microservice soll ausschließlich von anderen Services, wie beispielsweise Schedule benutzt werden. Er soll Informationen von Webseiten, wie von der Beuth Website scapen und in eine Datenbank speichern. Auf diese Daten können letztendlich andere Microservices zugreifen und diese für ihre Dienste benutzen.

Dieser Service erwertet eine spezielle PDF des jeweiligen Stundenplans des Studenten und gibt den Inhalt der PDF in einem JSON zurück. Der Service soll später von den Microservices Schedule und finals benutz werden, welche die Daten weiterverarbeiten.

Dieser soll dem User die Funktionalität zur Verfügung stellen seinen eigenen Stundenplan erstellen und diesen auch ändern zu können. Ebenfalls soll der Service den User Notifications senden können, wie in der folgenden Beispiel Notification: „In 3 Wochen ist in dem Fach xy folgende Abgabe: Abgabe 3“. Dabei werden mehrere Möglichkeiten der Eingabe der Module in Betracht gezogen, wie Grundlegend das ganz normale manuelle einfügen per Text( Chat Eingabe ), aber auch das Hinzufügen von Modulen über die Module ID. Für das hinzufügen eines Modules über die Modul ID wurde überlegt in eine Datenbank alle sich in diesem Semester existierenden Fächer abzuspeichern und aus diesen Einträgen die Daten der Modul ID abzugleichen. Auch wurde überlegt die PDF, welche sich jeder Student frei von der Beuth herunterladen kann abzuschicken und den Stundenplan automatisch anhand der Daten auf der PDF zu generieren. Dabei wird darauf geachtet, dass die PDF nicht zwischengespeichert wird, sondern nur eingelesen, Übersetzt und aus den Zwischenspeicher wieder gelöscht wird.

Dieser Dienst bietet dem User seine noch ausstehenden Prüfungen einsehen zu können. Dabei soll der Service das Datum der noch ausstehenden Abgaben bzw. Prüfungen, sowie dessen Fach und Inhalt wiedergeben. Auch soll dem User ermöglicht werden eigene Abgaben über eine Chat-Funktion hinzuzufügen, bzw. zu ändern. Die Daten werden einerseits aus dem vom User selbst eingetragenen Daten ermittelt, aber auch durch einen Scraper, welcher die aktuell eingetragenen Prüfungen des jeweiligen Faches über die Beuth Website ermittelt. Für das automatische ermitteln der Prüfungsdaten muss entweder der Studiengang, sowie das Semester und der Zug eingegeben werden, oder aber der Stundenplan als PDF gesendet werden.

Current State:

Target State:

subject to change