FORMCYCLE 7.0.0

Hinweise

• FORMCYCLE Version 7 benötigt Java 11+ !! und unterstützt in 7.0 Java 15/16/17 noch nicht. In Java 15 ist keine ScriptEngine für JavaScript mehr enthalten, diese wird von PrimeFaces 8 für die Validierung von Uploads im Backend verwendet. Ab 7.1 werden wir voraussichtlich auf PrimeFaces 10 aktualsieren, dann sollte auch Java 15 möglich sein. Wenn Java 15 unbedingt erforderlich ist, sollte es auch möglich sein, im lib-Ordner vom Tomcat die entsprechende Jar mit der Java-Engine abzulegen (testen!).
• 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).
• Bisher waren WebSockets optional. WebSockets werden in V7 viel im Designer verwendet. Um die korrekte Funktionalität zu gewährleisten, sollte geprüft werden, dass WebSockets entsprechend ermöglicht werden, hier müssen ggf. z.B. entsprechende Ports freigegeben werden.
• 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 in den Einstellungen es so eingestellt werden, dass SameSite=None und Secure immer gesetzt wird.

Features

• Neuer Workflow-Designer für die grafische Erstellung der Verarbeitung des Formulars
• Neue Eigenschaft im Designer -> Formular -> Absendeknopf validieren. 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.

Plugins

• Neue Plugins für Aktionen und Trigger im neuen Workflow. Diese ersetzen IPluginProcessing.
• 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.

Diverses

• Platzhalter für Aktionsergebnises im neuen Workflow sind leicht anders. Jede Aktion liefert ein JSON-Objekt zurück, darauf kann mittels [%$AKTIONSNAME.RESULT%] zugegriffen werden. Alles danach ist ein JSON-Pfad. Wie das JSON aussieht, legt jede Aktion fest. In der UI werden die entsprechenden Platzhalter angzeigt. Bei der SQL-Aktion z.B. ist [%$AKTIONSNAME.RESULT.rows[0].firstCol%] die Spalte "firstCol" der ersten zurückgelieferten Zeile.
• Neue Platzhalter für Fehler-Code und Fehlernachricht von Aktionen des neuen Workflows:
  • [%$<AKTIONSNAME>.ERROR_CODE%]
  • [%$<AKTIONSNAME>.ERROR_MESSAGE%]
  • [%$<AKTIONSNAME>.COUNT%] wird nicht mehr unterstützt.
• 2 neue Platzhalter zum Auslesen, ob Vorgang gelesen oder ungelesen ist. Kann etwa verwendet werden, um bei zeitgesteuerten Triggern im Workflow zu prüfen, ob Vorgang gelesen ist:
  • RECORD_READ
  • RECORD_UNREAD
• Eigenschaften in application.properties hinzugefügt
  • processing.limit.single.action
  • form.record.lock.poll.interval.millis
  • form.record.lock.timeout.millis
  • form.record.lock.max.duration.seconds
• Neuer Systemplatzhalter zum Auslesen von Daten, die ein Trigger bereitstellt. Z.B. stellt der DOI-Trigger Informationen über die DOI-Init-Aktion bereit, die den DOI ursprünglich ausgelöst hat
  • allgemein: [%$TRIGGER.<JSON_PATH>%]
  • konkret gibt es:
  • [%$TRIGGER.actionName%] - Name der DOI-Init-Aktion
  • [%$TRIGGER.taskName%] - Name des Tasks, wo sich die DOI-Init-Aktion befindet
  • [%$TRIGGER.triggerName%] - Name des Trigger des Tasks, wo sich die DOI-Init-Aktion befindet
• Neue System-Platzhalter zum Auslesen des aufgetretenen Fehlers bei try-catch-Blöcken und Fehler-Triggern, z.B. LAST_ERROR_CODE, LAST_ERROR_MESSAGE(3) oder LAST_ERROR.key.subkey siehe https://redmine.formcycle.de/issues/10467 und https://redmine.formcycle.de/issues/10355
• Zusätzlich zu den bestehenden System-Platzhalter [%$STATUS_NAME%] und [%$STATUS_ID%] gibt es neuen PH [%$STATUS_TYPE%]. Im neuen Workflow gibt es System-Status, z.B. "Eingegangen". Diese haben keinen Namen, der angezeigte Name an der UI hängt von der aktuellen Sprache ab. Um z.B. im Workflow in einer Bedingung zu prüfen, ob der aktuelle Status der Systemstatus "Eingegangen" ist, kann dieser neuen PH verwendet werden. Folgende Werte sind möglich für [%$STATUS_TYPE%]
  • RECEIVED - Eingegangen
  • SAVED - Zwischengespeichert
  • ERROR - Fehlerstatus
  • CUSTOM - Benutzerdefinierter Status, der durch Nutzer angelegt wurde
• Neuer Systemplatzhalter zum Auslesen von Vorganswerten (Custom-Attribute am Vorgang). Gedacht als Pendant zur Workflow-Aktion "Vorgangswerte schreiben." Damit können am Vorgang Werte gespeichert und in jeder Aktion darauf zugegriffen werden.
  • [%$RECORD_ATTR.<customAttrKey>%]
  • z.B. [%$RECORD_ATTR.loopCount%]
• Bei Ausführung des Workflows werden MDC-Parameter gesetzt, welche in der Logging-Konfiguration verwendet werden können:
  • wfElementType Typ der Workflow-Aktion, z.B. FC_EMAIL
  • wfElementUuid UUID der Workflow-Aktion
  • wfElementName Name der Workflow-Aktion, z.B. "E-Mail an Antragsssteller"
  • formRecordId ID des Vorgangs
  • processId UUID des Vorgangs (Prozess-ID)
  • projectName Name des Projekts
  • projectId ID des Projekts
  • sessionId ID der HTTP-Session, falls eine aktive ist
• Neuer System-Platzhalter zum Auslesen von am Vorgang hinterlegten Attributen
  • Pattern: [%$RECORD_ATTR.<customAttrKey>%]
  • <customAttrKey> ist der Key, unter dem ein Wert in den Custom-Attributen am Vorgang hinterlegt wurde
  • über die neue WF-Aktion 'Server-Attribute setzen' können neue Custom-Attribute am jeweiligen Vorgang hinterlegt werden
• Neuer System-Platzhalter zum Zugriff auf den aktuellen Wert eines Mandantzählers
  • Pattern: [%$COUNTER_CLIENT.<name>%]
• Neues Servlet zum Zugriff auf Mandantzähler: .../form/clientcounter/?frid=...&uuid=...
  • Diese URL ist unter XFC_METADATA.urls.counter_client verfügbar.