6 Replies Latest reply on Jun 30, 2008 1:39 PM by estaub

    Node as a milestone

      We have a need for process designers to place nodes in their processes to pattern a milestone that fulfills some reporting needs. For instance, they may want to report on what date each instance of a process started and then on what date each of their their milestones were reached.

      Is doing this as a plain "Node" the best way to achieve this? And then to gather the execution data from the JBPM_LOG table? My only concern about this approach would be filtering out Nodes that may have been utilized to execute logic and weren't placed there to serve as milestones.

      Thanks!
      Paul

        • 1. Re: Node as a milestone
          kukeltje

          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

            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.






            • 3. Re: Node as a milestone
              kukeltje

              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

                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

                  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

                    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.