3 Replies Latest reply on Apr 1, 2013 9:59 PM by calca

    Design pattern for routing to multiple jBPM processes?

      I am using jBPM 5.4 with persistence.  I am still a jBPM noob, so thanks in advance for your patience getting through this explanation...

       

      I have a ksession that will be running multiple long-running processes.  These process flows are the same - only the variables in the processes are different. 

       

      The basic use case it that I have events coming into a "router" that based upon message content will be passed to an existing process instance (if the related process exists).  If a process instance does not yet exist for that event, a new one is created. 

       

      I would greatly appreciate any thoughts on design patterns to implement this (managing processes in the kession and routing events to them).

       

      Relating to design, I have considered;

       

      1) Create a single-node process with a "routing" WorkItemHandler node.  This instance will receive the event and perform all of the checking/routing/process instantiation logic.  Basically, iterate through each process in the kession for the correct information and if the related process doesn't exist, create it.

       

      2) Create business rules that checks for (and creates) objects in the ksession representing each process that is running.

       

         Pseudo code for rules would be something like:

       

         rule "Send to existing process"

              when

                    $newEventBean : NewEventBean()

                    $myProcessBean : MyProcessBean(subject matches $newEventBean.subject)

              then

                   <signal  $myProcessBean.processId  with $newEventBean>

       

         rule "Create if process doesn't exist"

              when

                    $newEventBean : NewEventBean()

                    not($myProcessBean : MyProcessBean(subject matches $newEventBean.subject))

               then

                    $newProcessBean: NewProcessBean();

                    $newProcessBean.subject = $newEventBean.subject;

                    $newProcessBean.instantiate(thisKsession);       <<---inserts new process instance into ksession

                    insert($newProcessBean);

       

           (and when a process ends, it would need to retract the related newProcessBean)

       

      I am more familiar with java development than drools rule-jbpm integration, so I am leaning towards option 1.  (Specifically, for example, I'm not sure how to create a process from a rule or how to signal one, so I'd more likely to implement methods like NewProcessBean.instantiate() in a java method in my newProcessBean anyway )

       

      Any thoughts about option 1 or 2?  Am I missing a more obvious/better solution?

       

      (Possibly something like sending a signal to a ksession where the correct process catches it and acknowledges it in some way - so that if an acknowledgement isn't received a new process is created.  Can a process be configured to ALWAYS catch a signal AFTER another process, so that my "final" process could act like an "otherwise" statement and would just instantiate a new process?)

       

      Thank you again for any thoughts,

       

      -J

        • 1. Re: Design pattern for routing to multiple jBPM processes?
          swiderski.maciej

          Looks like a perfect case for correlated process instances - meaning that you can assign business key to process instances that later on can be used to get hold of process instance. That will come in with version 6.0. And in meantime...

           

          option 1 has an issue if you consider to use persistence (and I assume you do as there are long running processes). The issue is you cannot simply query for processes in that session as process instance resides in ksession only when it is being currently executed/processed by the engine. As soon as it reaches a safe state it is persisted and removed from ksession to save memory, etc

           

          Option 2 is one way to go and you can easily create processes from rules and as you said you need to make sure you retract fact when process completes.

           

          HTH

          1 of 1 people found this helpful
          • 2. Re: Design pattern for routing to multiple jBPM processes?

            Maciej, thank you for your response - being able to assign a business key sounds ideal. 

             

            Unfortunately, I have just about completed option one (of course!)  I am using the processinstancelog to find active processes:

             

                 List<ProcessInstanceLog> pil = JPAProcessInstanceDbLog.findActiveProcessInstances(myProcessName)

             

            My test program uses a signal to insert the object to a "routing" process (a start/stop node with my RoutingWorkItemHandler in the middle).  This process uses a signal start node, so it instantiates at each signal, looks for an existing (long running) process then creates one if it doesn't exist or adds some information to the process if it already exists.

             

            To your point, it seems pretty kludgy to use transactions yet rely on the log to get the process ids.  However, thus far things seem to be working - I have inserted several signals at once and they have been properly handled.  Specifically, when I insert two of the same signals back to back, the RoutingWorkItemHandler sees the process created from the previous signal and thus does not create a new one.  I made the executeWorkItem method in my RoutingWorkItemHandler synchronized, but it doesn't seem necessary.

             

            So, my question is, does this seem logical to you, or does it just seem like dumb luck?

             

            Thanks again,

            -J

            • 3. Re: Design pattern for routing to multiple jBPM processes?
              calca

              Hey. In my opinion, it could work ok to use the audit tables (or some other table if you implement your own process instance listener if you have some problem with transactions).

               

              But having a single node process to make the routing seems a bit unnatural in contrast to using rules to make it. I think using rules for this will give you more flexibility to add more cases into the future, and easier to understand.

               

              My 2 cents

               

              Demian

              1 of 1 people found this helpful