3 Replies Latest reply on Oct 31, 2014 2:47 AM by swiderski.maciej

    Signals and deployments

    patryk.dobrowolski

      Let's suppose we have some kind of event bus. It collects all events from the environment and decides what to do with them and where to forward them.

      One of receivers is jBPM instance. Let event bus send MyEvent events to jBPM as signals.

       

      On the other side in our jBPM engine we defined process which has a boundary signal on one of human tasks. Let's have some instances waiting for that signal. Now we create new version of process and again have some instances of it. So we have few instances of process in version 1.0 and some in version 1.1 and all of them are waiting for boundary signal of MyEvent type. Rest API expects that we know deployment id (let's say my-group-id:my-deployment-id:1.0 or my-group-id:my-deployment-id:1.1). Does it mean we need to find all deployments and send signal to each of them individually? Or maybe we can do something like this using asterisk:

      http://host/jbpm-console/rest/runtime/my-group-id:my-deployment-id:*/signal?signal=MyEvent.


      On the third side, some processes have start signal events. If signal would be send to all deployments, will instances of all versions be created? I would suppose that in this case, only last version of process should be involved.


      As I investigated as far, second solution is not possible.


      In my opinion, very bad idea is to keep and update information about all process and deployments versions in event bus.

      Keeping that in database is better, but still not very good.

      I imagine, that we could update processes in jBPM without upgrading other components like mentioned event bus.

       

      I hope it's clear what I wrote.

        • 1. Re: Signals and deployments
          happyhippo

          Hi Patryk,

           

          In my opinion, very bad idea is to keep and update information about all process and deployments versions in event bus.

          Keeping that in database is better, but still not very good.

           

          we solve a similar problem like yours as follows:

          We update our process definitions regularly and needed a mechanism for only starting new processes in the newest version (while older processes keep running in parallel until they die out eventually).

          We created a table in the database, with all existing process definitions. Each one has an end-date (which is set when a newer version is deployed or can be null if it is the newest one), and we created a service (used for starting new processes) that returns the name (in your case the deployment-id) of the currently up-to-date process definition.

           

          About signaling: We dont signal to the session, but to processInstanceId's. If you want to signal to all of your running processes across all deployment id's, you could use this database table and find out which deployments are existing.

           

          Maybe there is a better way, but i hope this helps.

           

          dan

          • 2. Re: Signals and deployments
            patryk.dobrowolski

            We are considering to extend REST API and do this at jBPM side, not in our environment. Currently we stuck on building kie-wb from sources.

            We also have some ideas for new services which could be usefull for others.

             

            Patryk

            • 3. Re: Signals and deployments
              swiderski.maciej

              extending REST API is one way to go but please keep in mind that it might be rather heavy operation and then it will block the thread that issues the request (one of your event bus threads I believe). Why I see it as heavy operation is that it will need to first figure out what deployments it has calculate which one is the latest and then find out what to signal - depending on runtime strategy it could be as simple as just taking rutnime engine and then kiesession and signal it (singleton) but for per process instance you need to find out what process instances are waiting for such event.

               

              Alternative solution which I would personally go with is to great another project with process that will be capable of doing all this things as it has access to all services of the platform via CDI (either direct CDI via API or regular beans - this will require addition of jars into the jbpm console war). Moreover you can benefit from the async behavior to not block any threads incoming. So event bus just submit a data to that process (starts it) and then process does all the heavy work for you. You can have as many instances of this management process as you like running in parallel. Then the process can star/signal new process instances from within it.

               

              HTH