Der neue Workflowdesigner
Der neue Workflowdesigner ermöglicht es, die Verarbeitung von Formularen auf eine intuitive und visuelle Weise per Drag & Drop zu erstellen. Die Verarbeitung wird nun über ein ereignisbasiertes Flussdiagramm dargestellt. Einzelne Verarbeitungsketten werden von Ereignissen ausgelöst. Ereignisse sind etwa der Klick auf einen Absendeknopf, das Bestätigen eines Double-Opt-In-Vorgangs oder die Überschreitung eines definierten Zeitpunktes. Bedingungen innerhalb dieser Verarbeitungsketten werden visuell durch Abzweigungen im Diagram 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
- Die neue Formulareigenschaft W3C konformer Modus sorgt dafür, dass das durch das Formular erzeugte HTML wohlgeformt und gemäß der W3C-Spezifikation W3C valide ist. Dieser Modus ist für alle neuen Formulare aktiviert und für bereits bestehende Formulare deaktiviert. Bei aktiviertem W3C-Modus stehen einige Attribute an den HTML-Elementen nicht mehr zur Verfügung, wie etwa cn= und xn=. Im JavaScript und CSS sollten daher die Selektoren [data-cn=...], [data-name=...], [data-xn=...] etc. verwendet werden. Die neuen data-Attribute werden sowohl bei aktiven als auch deaktivierten W3C-Modus an die Formularelemente geschrieben.
- Validierung des Absendebuttons
- Es gibt die neue Formulareigenschaft Absendebutton validieren im Designer. Wenn aktiviert, wird geprüft, ob es den Absendebutton zum Zeitpunkt der Auslieferung des Formulars wirklich gab.
- Formularelement-Refactoring
- Wenn Formularelemente umbenannt werden, funktionieren möglicherweise Teile des JavaScript 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
- Es gibt eine neue Zähler-Komponente zum Anlegen von Zählern inklusive einer neuen Workflow-Aktion zum Ändern des Zählerwerts und 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 der neuen Workflow-Aktion LDAP-Abfrage können im neuen Workflow LDAP-Abfragen getätigt und die Ergebnisse weiterverarbeitet werden.
- Zusätzliche Header in der Aktion POST-Request
- In der Workflow-Aktion POST-Request können zusätzliche Request-Header konfiguriert werden.
Dateianhänge enthalten neben der MIME-Type Angabe auch eine Charset Information zur Angabe des Zeichensatzes
- 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 beziehungsweise im Dateisystem gespeichert werden.
- Loginschutz pro Status
- Im neuen Workflow kann, analog zum initialen Aufruf eines Formulars, pro Status konfiguriert werden, welche Anmeldemöglichkeiten 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 kontextsensitive Parameter erweitert werden, um detaillierte Log-Ausschriften zu erhalten.
Changes
- Gesperrte Vorgänge können im Postfach mit der entsprechenden Berechtigung entsperrt werden.
- Initialisierte Double-Opt-In-Vorgänge können im Postfach mit der entsprechenden Berechtigung überprüft und Double-Opt-In-Nachrichten erneut gesendet werden.
- Geplante Aktionen werden im Verlauf eines Vorgangs im Postfach angezeigt.
- Es gibt nun ein separates Rollenrecht für das Ändern der Formularversion eines Vorgangs im Posteingang.
- In der Workflow-Aktion Weiterleitung kann nun auch direkt eine URL eingegeben werden.
- In den Formulareigenschaften des Designer kann ausgewählt werden, dass jedem Formularelement eine CSS-Klasse mit deren Namen hinzugefügt wird. Diese Option ist standardmäßig für neue Formulare aktiviert.
- Die enthaltenen Plugins werden auch angezeigt, wenn das Plugin-Bundle deaktiviert ist.
- Das HTML-Template Systeminformationen wurde 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. Formulare mit der alten Status- und Aktionsverarbeitung können in Xima® Formcycle-Installationen ab Version 6.2.0 importiert werden.
- Die Werte für AGB, Datenschutz, Impressum für die Anzeige auf dem Anmeldebildschirm sind standardmäßig unbelegt. Wenn noch die Standardwerte verwendet werden, werden diese beim Update auf V7 geleert.
- Der sadmin hat nicht mehr standardmäßig Zugriff auf neu angelegte Mandanten. Dieser muss erst von einem Mandantadministrator freigegeben werden.
- Bei LDAP-Verbindungen werden jetzt die Zertifikate Servers validiert. Es kann dadurch nötig sein, das Root-Zertifikat, mit denen das Server-Zertifikat ausgestellt wurde in den Java TrustStore zu importieren.
- Aktualisierung von in Xima® Formcycle verwendeten Abhängigkeiten.
- Diverse Fehlerbehebungen.
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.<JSON_PATH>%]
- Systemplatzhalter zum Auslesen von Daten, die ein Ereignis bereitstellt. Beispielsweise stellt das Double-Opt-In-Ereignis 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.<JSON_PATH>%]
- Der Platzhalter [%$LAST_ERROR%] liefert ein JSON-Objekt mit Informationen zum letzten Fehler zurück, auf welche per JSON-Path zugrgriffen werden kann.
- [%lang%]
- Platzhalter zum Auslesen der Sprache, mit der ein Formular aufgerufen oder abgesendet wurde.
- [%xf-qualifier%]
- Platzhalter zum Auslesen des Namens der Button-Leiste, in der sich der Absendebutton befindet, mit dem das Formular abgesendet wurde.
Plugins
- Neue Pluginschnittstellen für Aktionen und Ereignisse 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 Plugin-Aktionen sollten für den neuen Workflow angepasst werden. IPluginFormPreRespondParams#getWorkflowResponse ist deprecated, es sollte #getTaskExecutionResult für den neuen Workflow verwendet werden.
- Plugins welche die de.xima.fc.entities.Status-Entität nutzen, sollten überarbeitet werden. Es handelt sich hierbei um den Status des alten Workflows. Für Vorgänge mit dem neuen Workflow ist kein de.xima.fc.entities.Status gesetzt. Der neue Workflow verwendet de.xima.fc.entities.WorkflowState.
- Neue Plugin-Schnittstellen für die Unterscheidung von Plugin-Scopes: 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 (Contexts and Dependency Injection) verwenden.
Hinweise
- Das initiale Einrichten der Datenbank kann unter MySQL (vor allem Version 5) 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 (auf etwa 10-20 Minuten).
- Es gibt neue Cookie-Richtlinien in aktuellen Browsern. Standardmäßig wird nun SameSite=Lax angenommen. Damit funktioniert etwa 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 und das Secure-Flag gesetzt wird, 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 das Secure-Flag immer gesetzt wird.
- Bitte überprüfen Sie Ihre RSS-Feeds, wenn sie diese abonniert haben. Möglicherweise haben sich die URLs der Feeds geändert.