-
1. Re: Node as a milestone
kukeltje Jun 16, 2008 3:31 PM (in response to pjacobsen)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
-
2. Re: Node as a milestone
pjacobsen Jun 16, 2008 4:16 PM (in response to pjacobsen)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 bynot 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. -
3. Re: Node as a milestone
kukeltje Jun 17, 2008 3:30 AM (in response to pjacobsen)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. -
4. Re: Node as a milestone
pjacobsen Jun 18, 2008 12:28 PM (in response to pjacobsen)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. -
5. Re: Node as a milestone
kukeltje Jun 18, 2008 3:24 PM (in response to pjacobsen)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...
-
6. Re: Node as a milestone
estaub Jun 30, 2008 1:39 PM (in response to pjacobsen)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.