Dieser Blog-Beitrag wurde noch nicht veröffentlicht.

Xima® Formcycle benötigt ab Version 7.0.0 Java 11+. Java 15/16/17 werden noch nicht unterstützt.

Bisher waren WebSockets optional. Ab Version 7.0.0 sind diese allerdings zwingend notwendig. Um die korrekte Funktionalität zu gewährleisten, sollte geprüft werden, dass WebSockets entsprechend ermöglicht werden. Hier müssen ggf. entsprechende Ports freigegeben werden.

Für den Betrieb von Xima® Formcycle ab Version 7.0.0 muss eine aktualisierte Lizenz ausgestellt werden.

Falls eine eigene Protocol-Stack-Konfigurationsdatei für das Xima® Formcycle-Cluster (cluster.properties, Eintrag cluster.protocol.file) verwendet wird, muss diese geprüft werden. JGroups wurde auf Version 5 aktualisiert. Einige veraltete Protokolle sind nicht mehr verfügbar und einige Einstellungen können sich geändert haben. Siehe hierzu auch die Dokumentation von JGroups

Der neue Workflowdesigner

feature_workflow_designer_de.png

Der neue Workflowdesigner ermöglicht es die Verarbeitung von Formularen auf eine intuitive & visuelle Weise per Drag&Drop zu erstellen. Die Verarbeitung wird nun über ein ereignisbassiertes Flussdiagramm dargestellt. Ereignisse, wie der Klick auf einen Formularbutton, das Bestätigen eines Double-Opt-In-Vorgangs oder das Überschreitung eines definierten Zeitpunktes, lösen nun die Verarbeitungsketten aus. Bedingungen innerhalb dieser Verarbeitungsketten werden visuell durch Abzweigungen im Graphen dargestellt. Dieser neue Workflowdesigner stellt die Grundlage für die zukünftige Formularverarbeitung in Xima® Formcycle dar und wird mit kommenden Updates durch weitere Ereignis- und Aktionstypen erweitert. Die alte Status- und Aktionsverarbeitung wird nicht aktiv weiterentwickelt.

Weitere Features

W3C konformer Modus
Sorgt dafür, dass das durch das Formular erzeugte HTML wohlgeformt & gemäß der W3C-Spezifikation W3C valide ist. Dieser Modus ist aktiv für alle neuen Formulare und deaktiviert für bereits bestehende Formulare. Mit aktiviertenm W3C-Modus stehen einige Attribute an den HTML-Elementen nicht mehr zur Verfügung, z.B.: "cn=" und "xn=". Im JavaScript und CSS sollten daher die Selektoren [data-cn=...] , [data-name=...], [data-xn=...] usw. verwendet werden. Die neuen data-Attribute werden sowohl bei aktiven als auch deaktivierten W3C-Modus gerendert.
Validierung des Submitknopf
Es gibt die neue Eigenschaft Submitknopf validieren im Designer unter Formular -> Validierung. Wenn aktiviert, wird geprüft, ob es den Absendeknopf zum Zeitpunkt der Auslieferung des Formulars wirklich gab. Wird im Workflow ein Button-Trigger verwendet, kann hiermit eine Manipulation des Workflows verhindert werden.
Formularelement-Refactoring
Wenn Formularelemente umbenannt werden, funktionieren möglicherweise Teile des Formularscripts oder der Verarbeitung nicht mehr korrekt, da diese das Formularelement über dessen Namen referenzieren. Mit dem Formularelement-Refactoring können Formularelemente umbenannt werden, wobei sämtliche Referenzen auf dieses Formularelement automatisch angepasst werden.
Zähler
Neue Zähler-Komponente zum Anlegen von Zählern inklusive einer neuen Workflow-Aktion zum Ändern des Zählerwerts & Zugriff auf den Zählerwert über Platzhalter und URL.
Neue Workflow-Aktion Server-Attribut setzen
Über die neue Workflow-Aktion Server-Attribut setzen können Attribute an einem Vorgang hinterlegt werden und diese über einen Platzhalter ausgelesen werden.
Neue Workflow-Aktion LDAP-Abfrage
Mit dieser Aktion können im neuen Workflow LDAP-Abfrage getätigt und die Ergebnisse weiterverarbeitet werden.
Zusätzliche Header in der Aktion POST-Request
In der neuen Workflow-Aktion POST-Request können zusätzliche Request-Header konfiguriert werden.
Verarbeitung von Vorgangsanhängen
Im neuen Workflow kann in den Aktionen E-Mail & Speichern im Dateisystem auf Vorgangsanhänge zugegriffen werden. Diese Dateien können als Anhang in E-Mails verwendet bzw. im Dateisystem gespeichert werden.
Loginschutz pro Status
Im neuen Workflow kann, analog zum intialen Aufruf eines Formulars, pro Status konfiguriert werden welche Anmeldeoptionen für Vorgänge in diesem Status zur Verfügung stehen.
Neuer Externer Benutzer: OAuth 2.0
Es können nun auch Externe Benutzer für das Authorisierungprotokoll OAuth 2.0 angelegt werden.
Kontextsensitve Parameter für Logging-Pattern
Logging-Pattern können um kontext-sensitive Parameter erweitert werden um detailierte Logausschriften zu erhalten.

Neue Platzhalter

[%$COUNTER_CLIENT.<name>%]
Gibt den aktuellen Wert eines Zählers zurück.
[%$RECORD_ATTR.<customAttrKey>%]
Auslesen von benutzerdefinierten Vorgangswerten.
[%$STATUS_TYPE%]
Gibt den Statustyp eines Vorgangs zurück.
[%$RECORD_READ%]
Ist der aktuelle Vorgang gelesen.
[%$RECORD_UNREAD%]
Ist der aktuelle Vorgang ungelesen.
[%$<AKTIONSNAME>.ERROR_CODE%]
Fehlercode zur Identifizierung von potentiellen Aktionsfehlern im neuen Workflow.
[%$<AKTIONSNAME>.ERROR_MESSAGE%]
Fehlernachricht bei potentiellen Aktionsfehlern im neuen Workflow.
[%$TRIGGER%] & [%$TRIGGER.<JSON_PATH>%]
Systemplatzhalter zum Auslesen von Daten, die ein Trigger bereitstellt. Z.B. stellt der Double-Opt-In-Trigger Informationen über die Aktion bereit, die den Double-Opt-In initialisiert hat.
[%$LAST_ERROR_CODE%]
Bei Fehlern im neuen Workflow gibt dieser Code den Typ des Fehlers an.
[%$LAST_ERROR_MESSAGE%]
Detaliertere Nachricht für Fehler im neuen Workflow.
[%$LAST_ERROR_NODE_NAME%]
Name des Knoten im neuen Workflow, der einen Fehler ausgelöst hat.
[%$LAST_ERROR_NODE_TYPE%]
Typ des Knoten im neuen Workflow, der einen Fehler ausgelöst hat.
[%$LAST_ERROR%] & [%$LAST_ERROR.<JSON_PATH>%]
Der Platzhalter [%$LAST_ERROR%] liefert ein JSON-Objekt mit Informationen zum letzten Fehler zurück, auf welche per JsonPath zugrgriffen werden kann.

Plugins

  • Neue Pluginschnittstellen für Aktionen und Trigger im neuen Workflow. (IPluginProcessing gilt nur für die alte Status- und Aktionsverarbeitung).
  • Die Pluginschnittstellen der alten Status- und Aktionsverarbeitung wird nicht aktiv weiterentwickelt. Bestehende Pluginaktionen sollten für den neuen Workflow angepasst werden. IPluginFormPreRespondParams#getWorkflowResponse ist deprecated, es sollte #getTaskExecutionResult für den neuen Workflow verwendet werden.
  • Neue Pluginschnittstellen für die Unterscheidung von Pluginsscopes: IPluginScopeClient & IPluginScoopeSystem
  • Es wurden einige Abhängigkeit aktualisiert. Plugins, die Abhängigkeiten als "provided" einbinden, müssen prüfen, welche Version von FORMCYCLE ausgeliefert wird und ob diese mit dem Plugin-Code kompatibel ist.
  • Es wurde auf CDI 2.0 und JSF 2.3 aktualisert. Plugins mit eigener Oberfläche (xhtml / Beans) müssen entsprechend geprüft werden und sollten CDI (Context Dependency Injection) verwenden.

Changes

  • Gesperrte Vorgänge können in der Inbox mit der entsprechenden Berechtigung entsperrt werden.
  • Initialisierte Double-Opt-In-Vorgänge können mit der entsprechenden Berechtigung überprüft & Double-Opt-In-Nachrichten erneut gesendet werden.
  • Die enthaltenen Plugins werden auch bei deaktivierten Pluginbundles angezeigt.
  • Das HTML-template Systeminformationen ist als veraltet markiert und sollte nicht mehr verwendet werden.
  • Der Kompatibilitätsmodus beim Formularexport wurde entfernt. Formulare mit neuem Workflow können nur in Xima® Formcycle-Installationen der Version 7+ importiert werden.
  • Aktualisierung von in FORMCYCLE verwendeten Abhängigkeiten.

Hinweise

  • Das initiale Einrichten der Datenbank kann unter MySQL etwas länger dauern (1 1/2 Stunden), wenn das information_schema verwendet wird. Es kann der Parameter "useInformationSchema=false" an die JDBC-URL angefügt werden, um diese Zeit zu reduzieren (10-20 Minuten).
  • Es gibt neue Cookie-Richtlinien in aktuellen Browsern. Standardmäßig wird nun SameSite=Lax angenommen. Damit funktioniert z.B. die AJAX-Einbindung von Formularen nicht mehr, da der Session-Cookie abgewiesen wird. Es muss nun SameSite=None gesetzt werden. Unter System -> Allgemein kann festgelegt werden, welche Einstellungen für den Session-Cookie gelten sollen, siehe auch die Hinweise dort. Zudem erfordert SameSite=None das Secure-Flag, die AJAX-Einbindung funktioniert daher in neuen Browsern nur per HTTPS!  Das Standardverhalten ist, dass SameSite=None gesetzt und das Secure-Flag, wenn FORMCYCLE über HTTPS aufgerufen wird (bei Proxy-Servern ist es nicht immer möglich, zu erkennen, wie das Request durchgeführt wurde). Wenn sicher ist, dass immer HTTPS verwendet wird, kann es in den Einstellungen so eingestellt werden, dass SameSite=None und Secure immer gesetzt wird.
Tags:
Copyright 2000-2024