Business Logic Komponenten¶

Paket-Struktur¶

Das Java-Projekt hat eine Verzeichnisstruktur zur übersichtlichen Strukturierung der verschiedenen Inhalte. Eine Vorgabe ist, das Verzeichnis mit dem Quellcode und den übersetzten Klassendateien zu trennen. Die üblichen Ordnernamen für Java EE-Projekte sind src und bin.

Die Verzeichnisstruktur hat zusätzlich einen lib und resource-Ordner. Im lib-Ordner werden die von der Business Logic verwendeten Bibliothek abgelegt. Der resource-Ordner unterteilt sich nochmal in localization für Sprachdateien, media für multimediale Dateien, sowie templates für Nachrichten-Vorlagen. Die Projektstruktur schaut wie folgt aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

BusinessBot<Projectname>
|- src
   |- Package <country.company.businesslogic.<application name>
   |- Package <country.company.businesslogic.<common>
   |- Package <country.company.businesslogic.<database> (optional)
   |- Package <country.company.businesslogic.plugin (required)
      |- PluginClient.java (required) (Schnittstelle)
   |- Package <country.company.businesslogic.<services>
|- classes
   |- extension.idx (Extension Point für den Klassenlader)
   |- MANIFEST.MF (META Informationen)
|- lib (Bibliotheken)
   |- de.citunius.businesslogic.api-1.0.0.jar (Common API für die Business Bot Plattform)
   |- de.citunius.businesslogic.api.messenger-1.0.0.jar (Generic Messenger API für die Business Bot Plattform)
   |- de.citunius.businesslogic.api.sfb-1.0.0.jar (Skype for Business API für die Business Bot Plattform)
   |- de.citunius.businesslogic.api.telegram-1.0.0.jar (Telegram Messenger API für die Business Bot Plattform)
|- resources
   |- localization
      |- string_de.properties (Sprachlabels für Deutsch)
      |- string_en.properties (Sprachlabels für Englisch)
      |- string.properties (Default-Sprachlabels)
   |- media
      |- images
         |- icon.png (Business Logic Icon)
   |- templates
      |- list.ftl (Vorlage für Instant-Nachrichten - Vorlage: Liste)
   build.xml (Apache Ant Build-Konfiguration)
   MANIFEST.MF (Default Projekt META-Informationen)
   plugin.properties (META-Informationen für das Plugin)

Plugin Manager¶

Der Plugin Manager sucht nach den META-Informationen des Plugins, die in der Manifest-Datei unter classes/MANIFEST.MF festgelegt werden. Die MANIFEST.MF-Datei beinhaltet die Einträge wie im folgenden Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Manifest-Version: 1.0
Implementation-Title: calculator Plugin #1
Implementation-Version: 1.2.0-SNAPSHOT
Plugin-Id: de.citunius.telegram.calculator
Built-By: ME
Created-By: Apache Maven 3.3.9
Plugin-Version: 1.0.0
Plugin-Provider: Citunius GmbH
Plugin-Class: de.citunius.businesslogic.plugin.PluginClient
Plugin-Dependencies: 
Implementation-Vendor-Id: de.citunius.plugins
Build-Jdk: 1.7.0_67
Specification-Title: calculator Plugin #1
Specification-Version: 1.2.0-SNAPSHOT
Archiver-Version: Plexus Archiver

In der Beispiel-Manifest wurde ein Plugin mit der Id de.citunius.telegram.calculator beschrieben, mit der Klasse de.citunius.businesslogic.plugin.PluginClient und Version 0.0.1. Die Plugin-Id muss eindeutig sein und den Konvensionen ... entsprechen, da sonst die Registrierung des Plugins abgelehnt wird. Zudem muss die Plugin-Version mit Semantic Versioning kompatibel sein (Die Business Bot Plattform benutzt jsemver als Implementation für SemVer, weil es den Vergleich von Versionen unterstützt).

Eine andere interne Komponente des Plugin-Managers ist der ExtensionFinder der beschreibt, wie der Plugin-Manager die Erweiterung über den Extensionpoint findet. Der DefaultExtensionFinder sucht nach der Erweiterung mit einer Extension Annotation in der Datei META-INF/extensions.idx. Die Business Bot Plattform benutzt dabei Java Annotation Processing, um alle Klassen der Erweiterung zur Laufzeit zu kompilieren, die mit @Extension annotiert sind und erstellt dafür die entsprechende Extension Index-Datei.

Plugin Lebenszyklus¶

Jedes Plugin durchläuft die festgelegten Lebenszykluszustände. Der PluginState definiert dabei alle möglichen Zustände. Die primären Plugin-Zustände sind:

• CREATED (The runtime knows the plugin is there. It knows about the plugin path, the plugin descriptor.)
• ENABLED (The plugin can be used.)
• DISABLED (The plugin cannot be used.)
• STARTED (The Plugin.start() of the business logic has executed. A started plugin may contribute extensions.)
• STOPPED (The Plugin.stop() of the business logic has executed.)
• RESOLVED (The plugin is created. All the dependencies are created and resolved. The plugin is ready to be started.)

Der DefaultPluginManager enthält die folgende Logik:

• Alle Plugins werden aufgelöst und geladen
• DISABLED-Plugins werden NICHT automatisch von der Business Bot Plattform gestartet, ABER Sie können ein DISABLED-Plugin manuell starten (und damit aktivieren), indem Sie startPlugin auf der Business Bot Plattform ausführen, anstelle von enablePlugin() + startPlugin()
• Nur STARTED Plugins können Erweiterungen beitragen. Jeder andere Zustand sollte nicht als betriebsbereit angesehen werden, da die Erweiterung nicht dem laufenden System hinzugefügt wird.

Die Unterschiede zwischen einem DISABLED Plugin und einem STARTED Plugin sind:

• Ein STARTED Plugin hat die Methode Plugin.start() ausgeführt, ein DISABLED Plugin jedoch nicht.
• Ein STARTED Plugin kann Erweiterungsinstanzen der Business Bot Plattform hinzufügen, ein DISABLED-Plugin kann dies nicht.

DISABLED-Plugins haben immer gültige Klassenlader und die Klassen können manuell geladen und untersucht werden, allerdings wird der Ressourcenlader - der für die Inspektion wichtig ist - durch die DISABLED-Prüfung blockiert.

Schnittstelle¶

Der Übergabepunkt des Plugin-Managers zwischen der Business Bot Plattform und der Business Logic erfolgt in der Klasse PluginClient im Paket de.citunius.businesslogic.plugin. In der Klasse finden sich die Methoden start(), stop() sowie die Klasse BusinessLogic die das Interface BusinessLogicInterface implementiert. In dieser Klasse werden vom Benutzer eingehende Nachrichten durch die Methode handleIncomingMessage() und vom Geschäftssystem ausgehende Nachrichten in der Methode sendMessage() festgelegt. Die Übergabe von Parameter erfolgt über die HashMap pluginMap.

Business Logic Bibliothek¶

Folgende Business Logic Bibliotheken werden ausgeliefert:

• de.citunius.businesslogic.api-1.0.0.jar (Common API für die Business Bot Plattform)
• de.citunius.businesslogic.api.messenger-1.0.0.jar (Generic Messenger für die Business Bot Plattform)
• de.citunius.businesslogic.api.sfb-1.0.0.jar (Skype for Business API für die Business Bot Plattform)
• de.citunius.businesslogic.api.telegram-1.0.0.jar (Telegram Messenger API für die Business Bot Plattform)

Es darf nur eine der Messenger Bibliothek (Datei de.citunius.businesslogic.api.<messenger>-<version>.jar) pro Business Logic verwendet werden, da es sonst zu Problemen mit den Klassenlader kommen kann. Die Messenger Bibliothek enthält spezifische Funktionen, die nur für den jeweiligen Messenger gültige sind, wie beispielsweise Menü-Struktur.

Menü-Struktur¶

Möchte man für der Business Logic ein Menü kreieren, so kann man die vorgefertigten Funktionen aus der Messenger Bibliothek verwenden. Damit sich die Business Logic merkt, in welchen Menü oder Untermenü sich der Benutzer befindet, muss der UserState abgespeichert werden. Die kann man über eine Datenbankfunktion realisieren, welche die UserState für alle Benutzer abspeichert.

Ein Menü wird mit dem Objekt ReplyKeyboardMarkup zusammengestellt. Dazu wird das Objekt ReplyKeyboardMarkup instanziiert, einige Eigentschaft mitgegeben und die Buttons definiert. Folgendes Programmierbeispiel dient zur Veranschaulichung:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

/**
 * 
 * @return
 */
 private ReplyKeyboardMarkup getKeyboardPreferencesMainMenu() {
     ReplyKeyboardMarkup replyKeyboardMarkup = new ReplyKeyboardMarkup();
     replyKeyboardMarkup.setSelective(true);
     replyKeyboardMarkup.setResizeKeyboard(true);
     replyKeyboardMarkup.setOneTimeKeyboad(false);

     List<List<String>> keyboard = new ArrayList<>();
     List<String> keyboardFirstRow = new ArrayList<>();
     keyboardFirstRow.add(getCommandLanguages(language));
     keyboardFirstRow.add(getCommandAbout());
     keyboard.add(keyboardFirstRow);
     replyKeyboardMarkup.setKeyboard(keyboard);
     return replyKeyboardMarkup;
 }

Im obigen Beispiel wird ein Preferences-Menü erzeugt, das die Button Languages und About besitzt.

Datenbankzugriff¶

Business Logics müssen die Datenhaltung entweder Datei-basiert realisieren oder eine Datenbank verwenden. Der Datenbank-basierte Ansatz muss für jede Business Logic individuell implementiert werden. Dazu muss die entsprechende Bibliothek für den Datenbankzugriff ins lib-Verzeichnis kopiert werden. Für weitere Information zwecks Implementierung entnehmen Sie bitte der Dokumentation der jeweiligen Hersteller.

National Language Processing (NLP)¶

Business Logics können um die Fähigkeit von National Language Processing (NLP) und KI (Künstliche Intelligenz) durch entsprechende Bibliotheken erweitert werden. Beispielsweise können hierbei Bibliotheken wie Apache OpenNLP und IBM Watson eingesetzt werden. Für mehr Informationen schauen Sie bitte in die Dokumentation der jeweiligen Hersteller.