We’re using formly to render Flowable forms and currently what has been done is to write a parser from Flowable forms to Formly (quite basic).
As we need to use the the Formly features not supported in Flowable, I attempted to store the pure Formly json in Flowable and caused a parse exception on boot.
Is there a way to disable the form parser or define my own SimpleFormModel or perhaps even override the FormField type to accommodate the revised fields structure in the model?
I would love a suggestion which allows us to use Flowable to house the forms.
Thanks
My suggestion would be to not tightly couple your use of a third-party Angular form library to Flowable.
Store your JSON form definitions in the file system (or in your datasource) and create your own Angular Form Service that leverages Flowable’s formKey extension point.
Thanks for your suggestion. Ended up doing this before reading your suggestion. I had assumed that Flowable would complain if it didn’t find the referenced form key in it’s repository but once I confirmed it didn’t I ended up doing exactly what you suggested.
Correct - the formKey is there for that very reason: to allow integration with any system. Note that some methods of the formService (if you would be planning on using those) do assume the default forms and won’t work.
So, would the steps be as follows?
-
Associate a formKey to the Start event or user task forms in flowable
-
Create your form on your own form builder and store it as JSON in your file system (or repository) using the same name as formKey of flowable Start event and user task forms
-
When an assigned user clicks on the task in the task application, using the taskId, get the formKey from Flowable repository
-
Using the formKey, load the Form JSON from the file system, and render the form JSON using your own JSON renderer
-
Once the user “Submits” the form, send the form data to Flowable as process variables.
For example, for a Start event form:
(a) firstName = “Sunil”
(b) lastName = “Kosuri”
For a User task form:
(a) comments = “This is approved!”
(b) outcome = “approve”
My questions:
(1) Are the above steps and flow accurate?
(2) Do we ever need to save the above values in the forms to create form instances? If so, do we save the form instances in our our file system (or repo)?
Thank you for any information.
Sunil
(1) Are the above steps and flow accurate?
Yes.
Do we ever need to save the above values in the forms to create form instances? If so, do we save the form instances in our our file system (or repo)?
Not quite sure I follow but consider this.
- The mere fact that you’re storing your form elsewhere outside of Flowable, means you’re no longer dealing with form instances.
What I mean is that we may need to store form instance data in flowable. For example, if a user submits a vacation approval request form, the reviewer will need to look at what data has been submitted by the user prior to approving or denying the vacation.
Similarly, there may be other cases (such as in Process Admin or Reporting) where an admin may want to look at what information was submitted by the user and what actions were taken by other human actors in the chain?
If the above is true, we would need to store form instance data in Flowable?
What I mean is that we may need to store form instance data in flowable. For example, if a user submits a vacation approval request form, the reviewer will need to look at what data has been submitted by the user prior to approving or denying the vacation.
Sure, this is very much possible. It simply means that, you have to store the submitted form data as task (think ‘execution’) variables without completing the task.