6 Replies Latest reply on Jul 6, 2007 6:24 PM by kukeltje

    Tracking WF path of execution

    kevin.l.wilson

      I would like to be able to write a test case which tracks the path of WF execution through the nodes. Is there a Listener or actionHandler I can tie into which would be hit for every node (and/or) transistion. Without affecting the process design?

        • 1. Re: Tracking WF path of execution
          kukeltje

          no, there isn't, but since the source is open, such thing could be added

          • 2. Re: Tracking WF path of execution
            tom.baeyens

            i think it might be possible.

            first, read the process into memory. then programmatically, you could add events to the process definition that listen for 'transition' or 'node-enter' events.

            then you'll get the notifications you're looking for.

            there are various ways on how to read the process into memory. so you might have to search to find the right one. also you could consider writing a process parser and configure it as a deployment phase. that would be completely transparant, but to manage the custom configurations for that is probably harder then just programmatically reading and updating the process.

            • 3. Re: Tracking WF path of execution
              kukeltje

              hmmm.... dirty solution.... Wouldn't it be better if we just added a hook in the code where an external event-listener can be attached (configuration), or make it possible to e.g. register a global eventlistener (event='any' on the processdefinition)

              • 4. Re: Tracking WF path of execution

                 

                "kukeltje" wrote:
                Wouldn't it be better if we just added a hook in the code where an external event-listener can be attached (configuration), or make it possible to e.g. register a global eventlistener (event='any' on the processdefinition)



                Here here!
                I believe this is all that would be necessary in the engine to also support (remote) debugging, which is a future goal for us. In other words, from a "workflow debugger UI", someone could single-step through a workflow, let it run and watch where it goes, set breakpoints in it, etc.

                -Ed Staub

                • 5. Re: Tracking WF path of execution
                  bill.burke

                  I always thought that relying on Hibernate to both load and manage a process definition instances was a flawed approach as you cannot do things like this. This is why jBPM is also stuck with the instance-per-request for actions.

                  • 6. Re: Tracking WF path of execution
                    kukeltje

                    Bill,

                    I assume with 'process definition instances' you mean an instance of a process definition, so a 'running' one, not the definition itself.

                    If so can you elaborate a little more on this 'things like this' in relation to your remark about hibernate? I do not fully get what you mean by this. And when you are at it, I also do not grasp the 'instance-per-request for actions'