How are we supposed to display the comments back to the user, when they would like to take a look at the history of what they did?
looking at it. will let you know later today how we'll proceed with this.
Had a few more comments about how history is currently being tracked.
I am not aware of what the plan is in terms of providing history related features, for jbpm 4.xx similar to the lines of what was supported by jbpm3, hence my curiosity. Let me try to make my case here:
A typical way of using jbpm is to embed/integrate it into the client application. So the domain data of the client application is linked up to the domain of the workflow(process definition, process instance, tasks, etc).
The domain entity that is workflow enabled is linked up to process-instance. So this way jBPM is responsible for managing the workflow, keeping track of state, creating tasks, etc etc. Whereas the client domain would contain all the other data that is needed by the client application.
So you essentially are linking up two different pieces of data together. An insurance claim table would likely store the process_instance_id as one of it's columns,(and also vice versa, especially with the key based ids in jbpm4).
Now every step/task in the workflow, users of the client application might do one or more of the following:
1.) add comments to the task/process_instance.
2.) maybe even store some files.
3.) add some data to the workflow.
This is where history and the ability to track it comes into place. If there is any data that we want to store on the process-instance level, we can store it using the process-instance key.
Any data that we want to store on the task level, like associating which attachment was added at what step of the workflow, seems to be difficult to do in a straightforward manner currently. The task is being deleted from the task table, and is inserted into the JBPM4_HIST_ACTINST. At this point we lose the 'id' related to the task. So now way to associate the attachment with the task that it was added to.
I might be missing an angle here w.r.t doing this in v4. But it would seem that at least for the activity_history, we need to store the id of the activity so as to track items on the individual activity level?
This helps us to display a comprehensive history of what all happened, combining the data from the jbpm and client end and display it to the user.
Let me know your thoughts,
Quick comment: Keeping the original ID in the history table make sense to me.
I agree, we need some reference to the original id so that it can be linked back to the client application. This is a very key feature in a couple of jbpm v3 implementations that we currently have at our end.
To keep things consistent, I think it would be a good idea to see if we can add a String based id to task/activity too.
So just as we have processinstance ids as SimpleProcess.1, would it not make sense to have something similar for Tasks?
the api already switched to string ids. for tasks, there is no good candidate for generating a meaningfull composite key that still is guaranteed unique. the dbid (= PK) would have to be part of it anyway
initially i overlooked tasks and comments with respect to runtime/history split. that
today, i added a history task today and moved the comments to the history data. this is in line with the new split up: history data remains and runtime data only contains the current runtime state.
that way the history tasks and the comments will be available after the tasks themselves are completed.
That is cool! I was just going through the changes you made a while ago,
Thanks for the lightning fast response! :)