Diese technische Dokumentation soll die Wiederverwendbarkeit des Quelltextes ermöglichen. Im Folgenden wird auf die Projektstruktur, die einzelnen Module und letztlich auch auf den Build- und Deploy-Prozess Bezug genommen.
Bei Fragen stehe ich gerne per Mail zur Verfügung.
Tobias Dillig
mail@tdillig.de
Das Projekt ist in 3 Module gegliedert:
Im Folgenden ist die Struktur des “seed”-Moduls abgebildet.
de.tdillig.ba.seed
model
Appointment.java
Patient.java
MyFactory.java
ApplicationLogger.java
Config.java
Myfhir.java
RDFReader.java
RDFWriter.java
Die Klasse “MyFactory” dient dem Instanziieren von “Appointment”- und “Patient”-Objekten aus CSV- oder RDF-Daten. Der ApplicationLogger stellt eine einfache Logging-Funktion für die Wrapper bereit. Die Config-Klasse stellt Funktionen und Variablen bereit, welche von den Config-Klassen der Wrapper überschrieben werden können. Die Myfhir-Klasse ist automatisch generiert und ermöglicht die einfache Verwendung des Myfhir-Vokabulars mit Apache Jena. Der RDFReader und RDFWriter stellen MessageBodyReader und MessageBodyWriter für Jersey bereit.
Beim Build-Prozess des Moduls wird eine JAR-Datei erstellt und diese als Bibliothek im lokalen Maven-Repository hinterlegt. Die beiden Wrapper haben diese Bibliothek als Abhängigkeit eingetragen, sodass diese erst kompiliert werden können nachdem das “seed”-Modul kompiliert wurde.
Das Modul “betty2rdf” ist einer der beiden Wrapper. Im Folgenden ist die Struktur des “betty2rdf”-Moduls abgebildet.
de.tdillig.ba.betty2rdf
controller
Calendar.java
CalendarList.java
Config.java (erbt von de.tdillig.ba.seed.Config)
Die beiden Controller stellen folgende REST-APIs bereit:
HTTP-Methode | Pfad | Beschreibung |
---|---|---|
GET | /betty2rdf/rest/CalendarList | Auflistung aller bei Betty24 verfügbaren Kalender |
GET | /betty2rdf/rest/Calendar/[id] | Auflistung aller neuen/geänderten Termine pro Kalender (id = KalenderId aus der Kalenderliste) |
POST | /betty2rdf/rest/Calendar/[id] | Hinzufügen eines neuen Termins zum Kalender mit der entsprechenden ID |
Die Requests an die APIs des Wrappers werden verarbeitet, indem die Betty24-API abgerufen wird. Die JSON-Daten von Betty24 werden mittels Apache Jena in RDF umgewandelt und - im per Content-Negotiation angeforderten Format - ausgegeben. Per Post übermittelte RDF-Daten werden per Apache Jena gelesen und an die Betty24-API zum Blocken von Zeitslots weitergegeben.
Das Modul “rdf2csv” ist einer der beiden Wrapper. Im Folgenden ist die Struktur des “rdf2csv”-Moduls abgebildet.
de.tdillig.ba.rdf2csv
controller
Calendar.java
CalendarList.java
Config.java (erbt von de.tdillig.ba.seed.Config)
Die beiden Controller stellen folgende REST-APIs bereit:
HTTP-Methode | Pfad | Beschreibung |
---|---|---|
GET | /rdf2csv/rest/CalendarList | Auflistung aller bei Betty24 verfügbaren Kalender |
GET | /rdf2csv/rest/Calendar/[id] | Auflistung aller neuen/geänderten Termine pro Kalender (id = KalenderId aus der Kalenderliste) |
POST | /rdf2csv/rest/Calendar/[id] | Hinzufügen eines neuen Termins zum Kalender mit der entsprechenden ID |
Die Requests an die APIs des Wrappers werden auf Basis einer internen Ordnerstruktur verarbeitet. Die vorliegenden CSV-Dateien werden mittels Apache Jena in RDF umgewandelt und - im per Content-Negotiation angeforderten Format - ausgegeben. Per Post übermittelte RDF-Daten werden per Apache Jena gelesen und als CSV-Datei in der Ordnerstruktur abgelegt.
install -X
) des Seeds, dann der beiden anderen Wrapper durchführentomcat7:redeploy -e