Systemarchitektur


Xima® Formcycle ist einer reine Java-Anwendung und basiert auf einer modularisierten und schichtenorientierten Komponenten-Architektur, die sich mit jedem Java-fähigen Betriebssystem unter einem Anwendungsserver (Tomcat, JBOSS) nutzen lässt. Der Datenbankzugriff basiert vollständig auf der Java Database Connectivity API (Jdbc). Im folgenden werden bestimmte Komponenten und Eigenschaften genauer beschrieben.

Laufzeitumgebung

Für den Betrieb von Xima® Formcycle ist Java in mindestens der Version 11 sowie ein entsprechender Servlet-Container (z.B. Tomcat) nötig. Ferner wird für die Daten-Persistenz eine relationale Datenbank benötigt. FORMCYCLE unterstützt hierbei MySQL, MS SQL, PostgreSQL und Oracle.

Überblick der Modularisierung

Überblick der Modularisierung von Xima® Formcycle.

Xima® Formcycle basiert auf einer hoch-modulare Anwendungs-Architektur welche sich in die folgenden Teile gruppieren lässt:

Commons

Innerhalb der Commons Module stehen die in der kompletten Anwendung verwendeten Model- und Entitäts-Klassen zur Verfügung.

DAO

Innerhalb der DAO-Module ist die Logik für die Daten-Persistenz gekapselt. Hierbei kommt Hibernate als JPA-Implementierung zum Einsatz und ist für die entsprechenden CRUD-Operationen der einzelnen Entitäten verantwortlich. Die Kommunikation mit der verwendeten Datenbank wird mittels HikariCP und den jeweiligen JDBC-Treibern realisiert.

Logik

Innerhalb der einzelnen Logik-Module ist die eigentliche Business-Logik von Xima® Formcycle gekapselt. Die relevantesten Funktionalitäten einzelner Module sind hierbei folgende:

  • Durchführung der Workflow-Verarbeitung (Abarbeiten der konfigurierten Aktionen)
  • Das Integrieren und Ausführen von installierten Plugins
  • LDAP-Anbindung an Fremdsysteme (UnboundID LDAP SDK)
  • Cluster-Kommunikation mehrerer Xima® Formcycle-Server (JGroups)
  • Das Ausführen zeitgesteuerter Aufgaben (Quartz)

Formular-Designer

Die Module des Formular-Designers sind neben dem eigentlichen Design-Prozess auch für das Rendern bestehender Formulare sowie das Validieren von eingegebenen Daten innerhalb eines Formular-Aufrufs verantwortlich.

APIs

Basierend auf den Logik- bzw. Formular-Designer-Modulen setzten mehrere Schnittstellen auf welche es ermöglichen die entsprechenden Funktionalitäten zu nutzen. So steht neben einer Java-API basierend auf RPC (SIMON/MINA) auch eine REST-Schnittstelle zur Verfügung. Ebenso lassen sich hierrüber die CRUD-Operationen der DAO-Schicht aufrufen.

Verwaltungs-Frontend

Das Frontend zur Verwaltung und Konfiguration von Xima® Formcycle besteht aus mehreren Modulen welche mittels entsprechender Beans (JSF) sowohl DAO, Logik oder auch entsprechende API-Module ansteuert und dem Benutzer die dazu benötigten Web-Oberflächen bereitstellt.

Formular-Frontend

Beim Formular-Frontend handelt es sich um Module welche für die Auslieferung und Verarbeitung der Formulare verantwortlich sind. Hierfür wird neben der RPC-API zum Aufruf des eigentlichen Renderns des entsprechenden HTML-Codes (inkl. CSS, JavaScript) auch die REST-API benutzt um weitere Daten oder Dateien innerhalb der Ausführung im Client-Browser bereitzustellen. Ferner werden über die RPC-API auch weitere Funktionalitäten wie z.B. die Benutzer-Authentifizierung oder das Ausführen von Plugins realisiert.

Verwendete Technologien/Bibliotheken

Innerhalb von Xima® Formcycle kommen unter anderem folgende Bibliotheken und Technologien zum Einsatz:

  • Java ab Version 11
  • JSF inkl. Primefaces und Omnifaces
  • HTML, CSS und JavaScript
  • Aspose Word, Apache PDFBox, Apache POI
  • div. Apache Commons Bibliotheken
  • JPA, Hibernate ORM, HikariCP, JDBC
  • Liquibase
  • Hibernate Validator
  • JavaMail
  • Log4j2 über SLF4J
  • Quartz
  • EHCache
  • JGroups
  • SIMON, MINA
  • UnboundID LDAP SDK
  • SimpleXML, fastjson
  • Xalan XSLT processor
  • Mozilla Rhino
  • pac4j

Systemarchitektur beim Einsatz eines optionalen Frontend-Servers

Architektur von Xima® Formcycle, wenn sowohl ein Master-Server als auch ein Frontend-Server genutzt wird.

Der Einsatz eines Frontend-Servers ist sinnvoll bei:

  • Netzwerkübergreifende Installation (etwa lokales Intranet + DMZ)
  • Lastverteilung
  • Regionale Aufteilung (Jeder Mandant hat einen eigenen Frontend-Server mit eigenen Formularen)
  • Kundenspezifische Erweiterungen (Integration in vorhandene Systemumgebung, eigene Verwaltungsoberflächen)
ModulBeschreibung
FrontendInformationen zum Status des Servers, eigene Oberflächen.
API (RPC)Ermöglicht den Zugriff auf Vorgänge, Status, Aktionsverarbeitungen, Aktionen und vieles mehr.
CommonSchichtenübergreifende Funktionalitäten.
BSVBidirektionale Socket-Verbindung zur Kommunikation zwischen Master-Server und Frontend-Server.