Milestones as a node in BPM are for 'synchronizing' 2 parallel branches. Generic nodes just for the sake of reporting is overkill imo. Although it is 'common' practice when using e.g. SeeWhy and not specifically bad. not use specific queries to retrieve start and end date of normal tasks/nodes/joins/... whatever
Thanks for the quick reply Ronald.
I was aware of the term milestone being used in a workflow pattern for synchronizing parallel branches... although I assume this was not fully baked yet as the "milestone-node" doesn't appear the jPDL schema. Looks like there is a test case that exercises it, though.
Anyway... I was having trouble understanding you last sentence or two. Are you saying that what I'm proposing is not inherently bad when using reporting tool like SeeWhy? And what did you mean by
not use specific queries to retrieve start and end date of normal tasks/nodes/joins/... whatever
FYI... the reason we are doing this is that processes can involve tens or sometimes 100+ steps and process designers want to place milestones to logically mark of points that are of importance to them. Their goal is to set up processes so that any could be viewed from a macro perspective by looking at the progress of the milestone nodes.
hahaha... wrong cut and pasting.... some words got left out...
I meant: Why don't you use specific queries to retrieve start and end date of normal tasks/nodes/joins/... whatever
Regarding the SeeWhy thing... additional nodes or actionhandlers are put in the processdefinition to send data from jBPM to SeeWhy. Just like what you want to do.
I was planning on using standard queries to gather the data, however, the problem I was coming up with a consistent way for process designers to build in nodes that could be indentified as "different" so they when processes are executing managers can look at the execution from a macro standpoint via these "project milestone" nodes.
Example: The process designer knows that project managers will really only be interested in seeing at what date the process started, and then when it cleared all of the tasks in each phase creative, legal, and production.
Athough inconsequential to the execution of a process, it is critical for monitoring to be able to design in points in the process that are important for managers to track and "weed out" the noise from all of the other nodes. This was the concept we were trying solve with this "project milestone" node.
You can also just let the processdesigners design the process and have the BAM/BI people define these 'specific' queries with the business and have them use these specific node names, events (e.g. leaving a join) or whatever...
I'd think about using an event handler before/after the nodes that you are interested in monitoring. It would write to a DB table of your own design. This would give you a lot more flexibility - you can add whatever fields you want, etc.