7 Replies Latest reply on Jul 22, 2009 3:13 AM by jbarrez

    current activity of execution

    camunda

      Hi.

      To query the current activity of an execution I have to cast the ProcessInstance to the ExecutionImpl class:

      ((org.jbpm.pvm.internal.model.ExecutionImpl)pi).getActivityName();
      


      because it is not part of the PVM/API. Or did I miss something?

      Why is that the case, an activity name should be available for every language, hence be part of the API, or not?

      Cheers
      Bernd

        • 1. Re: current activity of execution
          jbarrez

          Bernd,

          An execution can be anywhere in the tree of executions. So for some executions, the getActivityName() makes sense (eg sequential process) but for others (eg root execution with forked child executions), it doesn't (which should it return?).

          So that's why the only operation that is exposed is the findActiveActivityNames(), which will give you one value (eg the sequential case) or multiple (eg the forked case where the method is called on the root).

          The getActivityName() operation is only used internally, where we can be really sure of its usage.

          • 2. Re: current activity of execution
            camunda

            and the logic of the root execution ahs changed compared to jbpm 3 tokens (where the root token just remained in the fork) I guess?

            • 3. Re: current activity of execution
              tom.baeyens

              this is what i added to the migration docs especially for you :-)


              The root execution is now the same object as the
              process instance. (In jBPM 3, the ProcessInstance had
              a pointer to the root token). Also, unlike in jBPM 3, executions in jBPM 4 might
              get inactivated, create a child execution and let the child execution continue, even
              when logically this represents only one single path of execution. This happens in
              scope activities (or composite activities) that have timers or variables declared.


              • 4. Re: current activity of execution
                camunda

                Okay, I should RTFM ;-)

                But still, this doesn't lead to a problem with the getActivityName, or? If I am in a composite, the root execution may be in the scope/composite state, and the child in the "real" state.

                • 5. Re: current activity of execution
                  tom.baeyens

                  for the record: i wasn't spanking you. (at least not this time:-) i added that to the docs because you pointed out a hole in the docs. thanks !



                  But still, this doesn't lead to a problem with the getActivityName, or? If I am in a composite, the root execution may be in the scope/composite state, and the child in the "real" state.


                  exactly. the parent execution will have as execution state Execution.STATE_INACTIVE_CONCURRENT_ROOT and it should still point to the scope/composite activity. the leaves point to the real activity.

                  the difference with before is that each activity that has variables or timers declared on it, will also create a child token. the parent execution will be in state STATE_INACTIVE_SCOPE and the (single) child will be in state STATE_ACTIVE_ROOT

                  in that case the parent execution will be in state

                  • 6. Re: current activity of execution
                    camunda

                    Okay, but I want to persist the question: Why it is a problem to query the activity name then? I always can give an answer here (from the PVM/API perspective). It may be not that easy to interpret, but thats a different page...

                    • 7. Re: current activity of execution
                      jbarrez

                      You are giving the answer yourselves: it is not undoable, but it may be hard to interpret ... which leads to an api that is more difficult to use by the mainstream ;-)