How to persist task form data

Hi,

I’m a new camunda user.

We have an usecase where we wanted to restore to an older snapshot of mysql data stored by the solution that has camunda in it. I wanted to understand and get the approach to store “user edited data” in the task form and persist it in DB.

For example, a process claimed through tasklist has a field in the task form named “Label”. As an user, I have modified the label in the task form and clicked on “save”.

Some observations:

  1. I don’t see the modified “Label” information in the DB for some reason, I use a mysql database, and printed the data stored in the tables. I’m not able to see any modified task form data.

  2. We have a scenario where we would want to take snapshot of the current tasklist items as a backup, and restore when needed. And after the restore is done, we should be able to continue from the point the snapshot was taken.

  3. To achieve point.2, could you please suggest the best approach to save task form data for any pending tasks.
    Do we have to use service tasks for each corresponding user task?

  4. If I have a clustered environment - say with 3 nodes, at any point of time, if one node goes down, I’d want to continue on the pending tasklist items which are waiting on user task inputs or modification. Restore process for our solution requires us to continue with the snapshot we have.

When I experimented with camunda solution, the restore of the prev. snapshot with some pending user tasks loses “modified data” and it just comes up as a new user task.

Please correct me if I’m wrong, and also direct me to any references to use or configuration changes I have to make to persist task form inputs if possible.

Hi,

the “Save” button for Tasklist is meant to store changes for a short period of time, e.g. while quickly checking another task in the Tasklist. It is not intended to be a “persistent” storage of intermediate changes.

When the user clicks the “Save” button, the form stores the data in the localStorage of the users browser. There is no communication between the Tasklist and the server. If you have an application, where losing the intermediate state of a form would be a problem, I would rather break down the task into multiple user-tasks with their own forms. That way the state is persisted between the tasks by using the “Complete” button.

Does this help you?

Cheers
Sebastian

2 Likes

Hi Sebastian,

Thanks for the reply. Yes, this is what I guessed when I investigated more on this scenario. I’ll update the notes that a ‘complete’ action is necessary for saving the information to DB.

Regards,
-Siva

We have been working on a larger solution that persists data to a DB (not necessarily Camunda DB).

There are two distinct use cases we see:

  1. Start Event Forms
  2. User Task Forms

The Start Event Form is a little different if the way you store the data because you are storing the form data against the Deployment version of the form (maybe), and for user tasks you are storing the data against the specific instance of the form.

And of course you have to deal with saved drafts where the process could be changed or the task was completed but the draft was never submitted and the form is no longer valid for the process or is not needed because the task no longer exists.

Our more immediate need is the Start Event Form scenario. I will update this thread as we make progress.

1 Like

Thanks Stephen, please post your progress, I’ll be glad to know more details on this.

It is also in my sprint backlog to persist user task form data to a database. Needless to say, I’m interested in your current solution :wink:

start taking a look at https://github.com/formio. we are looking at using their OSS server, form builder and form renderer (NodeJS and Angular), in tandem with Tasklist (we use other apps other than task list but we like to use task list for prototyping, and think would be valuable to community :slight_smile: ).

initial thoughts on how it would work:

  1. Form Structure is pulled from Formio (form structure will have html camunda attributes)
  2. Angular Directive renders Form
  3. When form is saved for persistent data it would save to Formio Server Mongo.
  4. If data is not saved or is being submitted to Camunda then Formio server is only used for “Dry Validation”(server side validations), and data is pushed into Camunda and not stored in Formio Server.

When the save occurs it would be related to the specific Process Instance, Deployment, version, etc. And for use tasks, the data would be saved related to the task instance.

if changes were made to process and/or tasks, after the save has occurred, we would have some sort of “interface” that lets the user grab the data from the previous saves and “migrate” into the new version of the form. Obviously this “migration” of the data from 1 form version to the new form version would vary in complexity based on changes and complexities of the form. Would have to be built out over time. But initial goal is to just support the scenario of persistent saving when the Task and process are unchanged.

Unfortunately bringing in formio at this point is not a possibility for me.

I thought of hacking into the camunda-bpm-sdk-js so that the state is stored and fetched from a mongodb instead of localstorage while keeping all the functionality of the form lifecycle but then again… If I ever want to migrate to a newer version of Camunda I’ll have lots of extra work.

At the core of formio is the Renderer and the server. And the server is just APIs. So assuming the issue is not with NodeJS it self and you are more stuck because of the older version of camunda + the modifications + the current implantations of your processes, you could potentially use the APIs from the formio server to store the data. Remember that when the user selects “Save” in the rendered form, it is really just calling a Formio NodeJS web service to save the Form data. This creates a sort of “submission”, and you can query for those same submissions, and the system has the concepts of submissions from a specific user. So you could tap into the API part of the Server.

TLDR: You ignore the Formio Renderer and leverage the API that allows saving Camunda data to FormioServer and drop the API calls and responses into your implementation.