API Server analog Hibiscus Server

[almereyda]

Wenn JVerein per auf eine SQL Datenbank konfiguriert wird, ließe sich ein Webdienst vorstellen (#29 (comment)), welcher die JVerein Daten analog Hibiscus Server per standardisierter APIs verfügbar und bearbeitbar macht.

Als Workaround ließen sich No- und Low-code Angebote nutzen, welche über bestehende SQL Datenbanken gestülpt werden können.

Beispiele:

• https://docs.nocodb.com/setup-and-usages/column-types/#available-database-types
• https://docs.directus.io/user-guide/overview/glossary.html#database-abstraction
• https://www.datatrucker.io/docs/Database%20API/MariaDB
• https://docs.lowdefy.com/MySQL#page_title

[almereyda]

Da das Datenmodell von JVerein sehr ausgereift ist, kann es vermutlich auch mehr Web-orientierte Workflows unterstützen, wenn mensch die Daten über REST oder GraphQL aus der Datenbank bekäme.

Auch als Ziel von Integrationen könnte JVerein ein nützlicher Knotenpunkt sein, um verteilte Datenbestände in einer Organisation zu bündeln.

[dippeal]

Konntest du hier bereits etwas testen? Die Überlegung einer REST API für openJVerein finde ich toll.

[almereyda]

Noch nicht, aber wir sind eingeladen diesen Herbst ein Projekt einzureichen, um 2025 an solchen Dingen zu arbeiten. Vielleicht kommt auch für JVerein etwas dabei heraus.

[lenilsas]

Ich habe den Angang einer REST API in einem eigen Plugin erstellt: https://github.com/lenilsas/jverein.rest
Bisher habe ich umgesetzt:
-Mitglieder anzeigen
-Eigenschaften, Zusatzfelder, Sekundäre Beitragsgruppen, Zusatzbeiträge von Mitgliedern anzeigen
-Beitragsgruppen anzeigen
-Erstellen und Ändern von Mitgliedern
-Zusatzbeiträge erstellen

[almereyda]

Hervorragend.

Ist diese API selbstbeschreibend bzw. ist es angedacht, dass sie es ist? In anderen Worten, gibt es bereits eine OpenAPI-Spezifikation bzw. einen bekannten Pfad dorthin, bspw. per Codegenerierung aus der API selbst?

Bei unseren Nutzenden finden auch die Lastschriftläufe mit der XML-Datei (die je nach Bank ggf. gepatcht werden muss) rege Verwendung.

Ließe sich eine Liste zusammenstellen, welche Teile des Modells potentiell portiert werden können und wie weit der Fortschritt der Umsetzung jeweils ist?

[lenilsas]

Das Plugin baut auf jameica.webadmin auf und erweitert die REST Schnitstelle. unter http://localhost:8080/webadmin/rest.html kann eine Liste der implementierten Funktionen aufgerufen werden.

Bei unseren Nutzenden finden auch die Lastschriftläufe mit der XML-Datei (die je nach Bank ggf. gepatcht werden muss) rege Verwendung.

Meinst du Den Abrechnungslauf mit Ausgabe einer XML Datei? Da verstehe ich nicht was das mit der REST API zu tun hat.

Kannst du das Plugin testen und mir rückmelden welche funktionen dir noch fehlen oder geändert werden sollten.

[almereyda]

Danke für die Details und den Aufschlag.

Die XML Datei eines Abrechnungslaufs erwähnte ich, um nicht zu vergessen, dass es Bedarf danach gibt. Wenn eine authentifizierte REST API komplett mit AuthN und AutzZ vorliegt, ließe sich der Dienst vermutlich vollständig "headless" bedienen, was die Erstellung dieser Dateien mit einbeziehen würde. Ich weiß aber auch nicht, wie gut das ins REST Modell passt, erscheint mir solch ein Auftrag doch eher als ein "Remote Procedure Call". Das ist für eine erste Implementierung eher ein Folgeticket, das stimmt.

Ich werde das Plugin bei nächster Gelegenheit testen und Rückmeldung geben.

[lenilsas]

Ich habe die API in erster Linie als Ergänzung zur normalen Anwendung gedacht, so dass Beispielsweise die Mitgliedsdaten online bearbeitet werden können oder von Drittsystemen Zusatzbeiträge angelegt werden. Funktionen wie Abrechnung und Einstellungen hatte ich nicht vor zu implementieren. Auch bei der Buchhaltung ist die Frage, ob da ein Zugriff per REST nötig/sinnvoll ist.