3 Replies Latest reply on Aug 24, 2011 3:21 AM by lukasz.kozerski

    Problem with starting process

    lukasz.kozerski

      Hi,

       

      I have some problem with startring the process. Unfortunetly it is related to process persistence.

       

      I have some breakpoints, here:

      org.jbpm.process.instance.impl.ProcessInstanceImpl.start()

       

      and here:

      org.jbpm.persistence.processinstance.ProcessInstanceInfo.update()

       

      When I'm starting process:

              ProcessInstance process = ksession.startProcess("process", parameters);

              ksession.insert(object);

              ksession.insert(process);

              ksession.fireAllRules();

              ksession.dispose();

       

      everything seems to be ok. Breakpoints fires in correct order: start() and then update().

       

      But I need to start the process like this:

              ProcessInstance process = ksession.createProcessInstance("process", parameters);

              long processId = process.getId();

              ksession.startProcessInstance(processId);

              ksession.insert(object);

              ksession.insert(process);

              ksession.fireAllRules();

              ksession.dispose();

       

      In this example breakpoints fires in this order: update(), start().

       

      Why this is problem?

       

      If the server restarts and ProcessInstance is deserialized it has state STATE_PENDING. If now we complete some work item there is one line of code here:

      org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.signalEvent(String, Object)

       

      I looks like this:

      if (getState() != ProcessInstance.STATE_ACTIVE) {

                                              return;

                                    }

       

      and process is not continuing.

       

      What am I doing wrong?

       

      Lukasz

        • 1. Re: Problem with starting process
          salaboy21

          The update method is executed first because you are creating the instance without starting the process. That means that the instance is created in the database and later is started.

          If you signal an event you are not completing the work item, and because you don't share how your process looks like it's almost imposible for us to understand where your process is stopped.

          Cheers.

          • 2. Re: Problem with starting process
            lukasz.kozerski

            The process is as simple as can be:

            Start -> Simple script -> WorkItem -> Simple script -> End.

             

            As you mentioned I'm not completing work item.

             

            In my opinion the problem is that state of the process is not persisted when work item waits to complete.

            • 3. Re: Problem with starting process
              lukasz.kozerski

              Please consider attached example (http://community.jboss.org/servlet/JiveServlet/download/622346-39304/drools-serialization-test.zip).

               

              There is one test method:

              luk.SerializationTest.shouldSerializeVariable()

               

              Right now it works fine. Script1 prints Foo: A, X and Script2 prints Foo: A, Y.

               

              But if we change method of starting process from this:

                      ksession.startProcess("process", parameters);

                      // ProcessInstance process = ksession.createProcessInstance("process",

                      // parameters);

                      // long processId = process.getId();

                      // ksession.startProcessInstance(processId);

               

              to this:

                      // ksession.startProcess("process", parameters);

                      ProcessInstance process = ksession.createProcessInstance("process", parameters);

                      long processId = process.getId();

                      ksession.startProcessInstance(processId);

               

              then Script2 isn't fired.