If you only need it occasionally, you can always just add it to the xml of the definition and read that xml file when needed and get the specific attribute/element. No need to adapt the database for this.
Thanks for the information. so putting in the xml file wont be helpful.
Is there any other way ?
Why wont that be helpful? Maybe the usage of 'occasionally' confused you. It did me when I re-read it. I meant to say that if you don't need to query based on these attributes you can just put it in the xml. If you do need to query on them, you can always when starting a task or process, read it from the xml and store it in a process/task variable.
Works perfectly for me
Thanks again. I feel this wont be performant.
take for example if i wanted to know how many processes are delpoyed by a user <> on system <>. here i need to reload all the xml defintions :-(
'all' ? 40? 6000? to query it every now and then... Still way easier than adding a table to jBPM, changing the deployer etc... or was that not what you meant?
If you meant creating your own table fully outside jBPM and when the deployer returns without an error you update your table, then I agree. One way or another I did not think you meant this.
Yes I meant after deployer returns without an error, update custom created table.
Also if you have a look at the ProcessDefinitionQuery there is no way one can use to query such meta information.
You can also create additional columns in the existing jbpm tables ..so whenever a process and task is updated it will fill these columns with the meta data you want. You might need to declare this columns in your hibernate config and write a custom handler class..I have done this and it works brilliantly..
Also if you have a look at the ProcessDefinitionQuery there is no way one can use to query such meta information.Correct, has to go though the repository service.
Yes that works (one of the advantages of open source), but is scary to a lot of people. Upgrading etc... That is why we do not advice those kinds of things.
would it be possible to share your custom handler class. I am aware of updating the hbm.xml file but not sure whether of the handler class.
Personally, I would avoid adding columns to the existing tables themselves, again this rule DOES not apply to all, but if anything were to change within jbpm you could be potentially impacted. Which could be a fairly big problem for some.
So coupling one's own data with jbpm is a little riskier. It is best if we can isolate them architecturally. Put the data in a custom table, then associate the entry in the custom table with the id from jbpm. Open to as much extension as you want. But only couples minimally,
For us this low coupling is fairly important, so we go in that direction, your needs might vary, but be aware of the tradeoffs before you commit to either approach,.