So this is some details about a project we are working on to provide Camunda with a Form Builder.
This has been raised by others in the past: https://groups.google.com/forum/#!searchin/camunda-bpm-users/form$20builder/camunda-bpm-users/kaJLKNz2KHY/tD77spQf4BIJ.
The purpose is to solve two problems:
Ability to easily create the equivalent of Camunda Embedded Forms using a “Drag and Drop Form builder”, but also allow those same forms to be built using pure JSON.
To solve these problems we have been working with https://github.com/formio, more specifically:
Form Builder: https://github.com/formio/ngFormBuilder
Form Renderer: https://github.com/formio/ngFormio
Form Server: https://github.com/formio/formio
Do not build something that places Camunda Form Building in a “island”. We want the tools used to be based on a large user base, standards, and easily extendable. You should be able to technically take the same solution and use it in other non-Camunda based apps. Why? Because we help to ensure more community support and easier extendability rather than being stuck on the ‘island’.
Nothing overly complicated, but can still increase in complexity because of its ability to extend.
As a starting point allow the Form to integrate with Camunda’s current Embedded Forms / CamForm SDK JS. This means leveraging the camunda html attributes and some relatively small adjustments to Tasklist.
Allow Server Side Validations with the same system that provide client side validations
(Eventually) allow Form draft Saving/persistence of data to DB.
So what does this look like?
Well Formio is a Angular based Form builder and Renderer but more so it is a standard to follow for building forms (JSON), and you can rebuild the renderer in any lang (such as Formio’s React renderer).
We allow the user to build and store a angular generated form using a drag and drop form builder, have the json of that form structure stored independently of the BPMN and camunda server, and use the Form server for server side validations (bonus: the server is Node so we can write client side and server side validations in the same language, and often in one place).
This setup will require some small modifications to the Tasklist to support a new type of FormKey format, and a extension to the Camunda server to proxy data to formio (nodeJS server), and only accept data into Camunda once the formio server side validations are accepted.
Requests for the Form Structure and the Form Structure JSON response that is passed between Tasklist and Formio would also be proxied by Camunda Server.
From modeler perspective the key would be something like ‘formio:FormSystemName’. This way forms could be used across deployments in a very reusable way, and you could technically update forms without having to redeploy. (of course if we wanted the aspects of having to redeploy when a form changes, this could be easily supported as well).
I see this formio scenario sort of a mix between Embedded Forms and External Forms. In Formio form config we would still add the Camunda attributes to fields so when the JSON is loaded through the Formio Directive in Tasklist, Tasklist will still be able to pull or push variables.
Submission to Camunda Server will still be the same as the Camunda attributes, as they will be maintained as part of camFrom API/SDK.
The Form builder is highly themeable so it could easily be added as a new page into Admin, Cockpit, or Tasklist.
Here is how we have been thinking about the data flow (very draft):
Would love feedback thoughts, use cases, issues, etc