3 Replies Latest reply on Aug 8, 2011 1:03 PM by Maciej Swiderski

    Can JBPM Console be used for visibility into processes being initiated from a different container

    jjfutt Newbie

      Hello Everybody,

       

      I'd appreciate if somebody could provide the guidance on the level of integration between CONSOLE and processes initiated from different containers. Here's our scenario:

       

      (1) I'd like to deploy a JBPM process in a Web Container (Jboss or Tomcat), and I am going to use the instructions provided in the JBPM 5.1 Documentaiton to enable 'PERSISTENCE' on it.

       

      However, the instructions provided for enabling persistence on JBPM don't highlight how persistence can be enabled for the console itself. I do get the impression that CONSOLE can be persistence enabled, and can be used to track, view and manage JBPM process instsances that might have been initiated from different containers, but can't find any instructions or information to implement the same. Can somebody please answer these two questions:

       

      Q1: How do we enable persistence for JBPM Console. Right now, if I initiate an exmaple JBPM process deployed within console itself, it's lose after the Jboss server is recycled.

       

      Q2: The instructions for enabling persistence specify how our Java Programs should initiate a process to make them persistence capable. But I couldn't find information if the console itself will use the similar steps when initiating instances from the console?

       

      Q3: Is integration between console and other containers, supported ? (Using console for graphical visibility into processes initiated from other containers). Or is this not a typical scenario and requires creative soution?

       

      Thanks in advance.

        • 1. Re: Can JBPM Console be used for visibility into processes being initiated from a different container
          Maciej Swiderski Master

          Hi,

           

          let me start with last question first:

           

          jjfutt wrote:

           

          Q3: Is integration between console and other containers, supported ? (Using console for graphical visibility into processes initiated from other containers). Or is this not a typical scenario and requires creative soution?

          Console consists of two components: client side (GWT presentation) and server (REST services). They communicate over http so in theory it should be possible to have them on two nodes but that does not make to much sense since client components will be running on the browser, besides there could be some security issues if GWT could communicate with another server that it was downloaded from?! So I do not think you could have a console accessing remotely process engine (knowledge base) out of the box. But I also consider that as very important issue especially thinking about enterprise ready BPM.

           

          Moving forward to another question,

           

          jjfutt wrote:

           

          Q1: How do we enable persistence for JBPM Console. Right now, if I initiate an exmaple JBPM process deployed within console itself, it's lose after the Jboss server is recycled.

          Console itself does not have any persistence needs, it relies on what jBPM and Task Service provides. The reason why your processes are gone after JBoss restart is most likely cause by db configuration, in memory db by default with console installed by jBPM installer.

           

          Last question

           

          jjfutt wrote:

           

          Q2: The instructions for enabling persistence specify how our Java Programs should initiate a process to make them persistence capable. But I couldn't find information if the console itself will use the similar steps when initiating instances from the console?

           

          Console on startup will create knowledge base and knowledge session to access it. As well Task Service client is created and Human Task work item handler is registered on that session. By default console uses JPA knowledge session. And next whatever action you do from the console uses that session to work with processes and tasks.

          Most likely here is the place to implement remote access to knowledge base/session to be able to have a console deployed on another server than the process engine, more over to be able to use console for more than one process engine, which in my opinion would the biggest benefit.

           

          Hope any of my comments will be useful for you

           

          Cheers

          • 2. Re: Can JBPM Console be used for visibility into processes being initiated from a different container
            jjfutt Newbie

            Maciej:

             

            Thank you very much for your detailed reply. I do have some follow up questions, primarily because I didn't explain my questions properly. Let me take another shot and I hope that you or somebody else can clarify.

             

            Goal:

            1. To initiate and launch long running, "persistence enabled" JBPM processes from a servelet/jsp web application. 

            2. Using the console to view and manage the processes initiated by this servlet/jsp web application mentioned in (1).

             

             

            My understanding is that I have to make my JBPM application persistence enabled, and I have found instructions for that.

             

            Q1: However, the console itself should be pointing to the same database as my standalone java application. I am looking for pointers on how to change the console configuration to read the process information from the same database that I will be using in my java application so that it can allow me to view the status of those processes.

             

            Q2: Can I also assume that if a process is initiated ("Started") in the console (as opposed to stared by my java application), that I can find the session, and process id's in the database, and then I can make my java application read the database for entries created by the console and interact with the processes within my java application?

             

            Q3: I am able to deploy JBPM processes into my JSP/Servlet application and launch them. For console to allow me visibility into the status and state of these processes, I have to do two things (1) piont the console to the same database as being used by my serlvet application and (2) deploy the process definition on the classpath of the console, so that console has access to process definition as well... (Correct)? Note: For question 3, please assume that Guvnor repository is not being used at this time.

             

            Thank you in advance.

            • 3. Re: Can JBPM Console be used for visibility into processes being initiated from a different container
              Maciej Swiderski Master

              Looks like I went bit too far with my understanding of what you try to achieve

               

              Now I know what you really after - and I think a shared knowledge base and session is a good choice for that. Now the question is how to make both shared?

              I started to work a bit on JBoss services for jBPM and Task Service so that would probably suit your needs too. What will it do is simple build a Knowledge Base based on configuration and register it in JNDI so both applications and console could simple look it up and use it. There will be possibility to define more than one knowledge base with various sources (class path, file system, Guvnor). But that is still to come.

               

              For now I would give it a try with small change to console code to make knowledge base and session accessible from outside (for you application) or at least make the session id accessible by the application so you could restore it, just not entirely sure if you can have same session loaded twice?!

               

              Another alternative (that does not require any development in jBPM code base) would be to utilize REST interface of the console-server project. That way you will ensure that all of the processes are executed in the same session.

               

              Please treat this post more like a elaboration of possibilities... hopefully by collaboration we could come up with a good solution.