6 Replies Latest reply on Apr 22, 2013 4:48 AM by Andrea Carpineti

    SignalEvent issue in jBPMConsole

    Herman Post Newbie

      We have run into an issue with jbpmConsole that we do not understand.  The sample code runs as expected in eclipse but does not run the same in jbpmConsole.  (project attached running jBPM 5.3/Drools 5.4)

       

       

      The sample demonstrates starting two different processes in the same kSession and having one process signal an event in the other process. 

       

       

      The sample code in ProcessApp creates an instance of Hello.bpmn which blocks waiting for a SignalEvent.   It then creates an instance of DataDriveProcess.bpmn which has a single action node that calls kcontext.getKnowledgeRuntime().signalEvent("TestSignal", false);

       

       

      In eclipse this works fine and the Hello process terminates when it receives the SignalEvent from DataDriveProcess.

       

       

      If these processes are uploaded to Guvnor and packaged, and then started in jbpmConsole, Hello process does not receive the SignalEvent.   It can be made to work though, if you start the Hello process, note the processInstanceId, then edit the DataDriveProcess in Guvnor to call signalEvent("TestSignal", false, 8) with the explicit processInstanceId, and rebuild and start DataDriveProcess.

       

       

      So to summarize, signalEvent in 'broadcast' mode, without a specific processInstanceId does not appear to work in jbpmConsole, but does work in eclipse.

       

       

      We also tried to iterate through all of the process instances from the Action node in jbpmConsole and just SignalEvent on each, but no other process instances are visible.  They are visible in eclipse.

       

      Thanks,

       

      Herm

        • 1. Re: SignalEvent issue in jBPMConsole
          Darin Wilcox Newbie

          Upon looking into this issue, it appears the problem actually stems from the way persistence is used.  When running stateless inside Eclipse, the issue is when the kcontext.getKnowledgeRuntime() from within the action node is returning a StatefulKnowledgeSessionImpl the same as what is being used by the other process signaling the event.  While in jbpm-console, the processes are started using an instance of CommandBasedStatefulKnowledgeSession and then while trying to fire from one process to the other is still using an instance of StatefulKnowledgeSessionImpl and they aren't finding each other.

           

          It does seem like a bug that when the process is started using a CommandBasedStatefulKnowledgeSession that the kcontext should return the same instance of the StatefulKnowledgeSession implementation instead of returning a separate StatefulKnowledgeSessionImpl.  Can anyone comment on that or give some insights?

           

          Thanks,

           

          - Darin

          • 2. Re: SignalEvent issue in jBPMConsole
            Maciej Swiderski Master

            Alright, took a look at your case and first thing that brought my attention is - why you use script task to signal other process instances? There is dedicated mechanism for that - throwing signal events. Please find attached both definitions that is modified to include throw signal event instead of doing it from script task and was able to run both processes in jbpm console.

             

            P.S.

            I think I modified only Data Drive Process but attached both for the sake of completnes.

             

            HTH

            • 3. Re: SignalEvent issue in jBPMConsole
              Herman Post Newbie

              Thanks Maciej, the intermediate throw event worked.   We are not currently using the web-based Designer for development but are using the old eclipse-based BPMN editor.   Please let me explain why.

               

               

              We are programmers and we are trying to develop complex protocols.  We use eclipse for most of our develpment tasks and would like to use it for BPMN development for a number of reasons.

               

               

              * ability to debug processes and rules

              * ability to unit test processes and rules

              * have a common project structure and source repository for processes, rules, custom workitems, fact models, etc.

              * have a highly efficient development environment with keyboard shortcuts, code completion, etc.  We'd really like the 'code, compile, debug' cycle for Drools to be as efficient as any other language.

               

               

              Designer is evolving into a very nice tool and we hope our business users (clinicians in our case) will begin using it to model high level workflow.  We do use Designer and jBPMConsole to demo our work to end users and to let them review the logic.  I doubt we will ever use Guvnor as a repository as we already have an enterprise Knowledge Repository available to us.

               

               

              We really want to use the new BPMN2 modeling elements and are anticipating a stable release of the eclipse-based BPMN2 editor.  It will be very important to us to be able to round-trip processes from eclipse to Guvnor so we can collaborate with our users.   We hope the jBPM Development Team recognizes the importance of this tool.  We hope that development of rules and processes in eclipse becomes as efficient as Java development.   We'd love to see rules and processes compile into intermediate binary files and packages in the default 'target' folder to speed up development. 

               

               

              I expect you might respond that we are welcome to participate in the development of these new features, but unfortunately our leadership does not currently support such a contribution to any significant level.  They do however support purchasing the RedHat BRMS product once these key features have been implemented.

               

               

              Thank you again for your response, and please let us know if we've misconstrued something.

               

               

              Thanks,

               

               

              Herm

              • 4. Re: SignalEvent issue in jBPMConsole
                Darin Wilcox Newbie

                Hi Maciej,

                 

                I tried out your solution, but the Howdy Process never received the signal event from the Data Drive Process.  Just to double-check, are you using jbpm 5.3.0 and then executing the process within the jbpm-console?  I can successfully get the solution to work from a unit test that extends JbpmJUnitTestCase, but from the jbpm-console, I never see the signal received.

                 

                Thanks,

                 

                - Darin

                • 5. Re: SignalEvent issue in jBPMConsole
                  Maciej Swiderski Master

                  Darin, I tested with master version (5.4.0-SNAPSHOT)

                   

                  HTH

                  • 6. Re: SignalEvent issue in jBPMConsole
                    Andrea Carpineti Newbie

                    Maciej Swiderski wrote:

                     

                    Alright, took a look at your case and first thing that brought my attention is - why you use script task to signal other process instances?


                    I use the jBPM Designer 2.4.0 Final and I use the script task when I want to send a signal to a specific pid because. For ex to send a signal from/to the same process instance my script will be something like:

                     

                    long dest = ((java.lang.Long) kcontext.getProcessInstance().getId()).longValue();

                    org.drools.impl.StatefulKnowledgeSessionImpl sps = (org.drools.impl.StatefulKnowledgeSessionImpl) kcontext.getKnowledgeRuntime();

                    sps.signalEvent("MYSIGNALREF", "", dest);

                     

                    What's the right way to do this with the default throw signal in the jBPM Designer (embedded in Drools)?

                     

                    thanks,

                    --ac