Der neue Workflowdesigner
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 HTML von Formularen wohlgeformt & W3C konform ist.
- 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.
- 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.
- 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.
- 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 Pluginmöchglichkeiten für Aktionen und Trigger im neuen Workflow. (IPluginProcessing gilt nur für die alte Statusverarbeitung).
- Klassen und Methoden des alten Workflows sind deprecated (IWorkflowProcessing, IWorkflowProcessingContext, IPlugin
- IPluginFormPreRespondParams#getWorkflowResponse ist deprecated, es sollte #getTaskExecutionResult für den neuen Workflow verwendet werden
- 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 und JSF 2.3 aktualisert. Plugins mit eigener Oberfläche (xhtml / Beans) müssen entsprechend geprüft werden und sollten (nicht müssen) CDI (dependency injection) verwenden.
Breaking changes
- Falls eine eigene Protocol-Stack-Konfigurationsdatei für das 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: http://www.jgroups.org/manual5/index.html
- Neue Formulare werden im W3C-Modus gestartet, wobei das erzeugte HTML valide gemäß der W3C-Spezifikation ist. Dazu mussten einige Attribute wie "cn=", "xn=" etc. an Formularelementen entfernt werden. JavaScript und CSS sollte daher die Selektoren "[data-cn=...]" , "[data-name=...]", "[data-xn=...]" usw. verwenden. Für bestehende Formulare ist dieser Modus initial deaktiviert. Die neuen data-Attribute werden aber immer mit geschrieben, sodass JavaScript und CSS bereits angepasst werden kann.
Weitere 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.