13 Replies Latest reply on Dec 28, 2011 3:38 AM by lvdberg

    jBPM a silent application killer

    lvdberg

      Dear forum members,


      This not really a question but more a number of warnings if you include jBPM in your Seam project. We are using Seam 2.2 (and peeking alredy at Seam 3..) and we have included different workflows and decisions handled by the jBPM/Drools modules.


      1. The quality of the jBPM documentation isn't the same as the Seam documentation, so you need a lot of additional Googling to get your stuff working. The additional (free) Seam in Action chapter helps a lot, but see warning 4


      2. if you're doing something which is not really PersonTask related, it's better to work directly with the jBpm API, because it saves you a lot of headache; The integration of the non-Task stuff isn't that good and the jBPM API's are very easy.


      3. Never (I mean never) use the jBPM core to store domain objects/values, Searching for them in the database is very slow (tables are NOT indexed). You can do different things to solve the problem of retrieving processes based on domain object; (a) change some core classes of jBPM (b) add indexes to the tables yourself, (c) add simple searchtables which contains the relation between the domain object and the process/task.


      4. Replace or remove the default logging of jBPM, all examples of jbpm.cfg.xml include this (even oru Seam in Action bible....), but it is the worst thing you can have in your production environement. We found that out the hard way.


      5. Try to use the workflow as asynchronous as practically possible, jBpm is not really fast, and slows down your rerender process if it's in the normal requiest/response chain. Combine it with Seam events and rich.push and you see miracles happen.


      Hopefully this can be useful to others.


      Leo







        • 1. Re: jBPM a silent application killer
          yahawari

          man .. u r speaking my mind!. i have came across all the points mentioned. they are very valid.

          • 2. Re: jBPM a silent application killer
            hbender

            Thank you for contributing your experiences.


            Maybe you will tell us also which version of jBPM you are talking about?


            Beside this I suggest to put your observations as an article into the jBPM-Forum (see here).


            Heri

            • 3. Re: jBPM a silent application killer
              lvdberg

              Hi,


              the version we are using is 3.3.0.GA (used in combination with seam 2.2)


              thanks for your replies,


              Leo

              • 4. Re: jBPM a silent application killer
                ajanz

                Hi Leo,


                found your tips/comments very useful. would be nice if we both could talk a little about it.


                our goal was to design a flexible workflow app based on seam,richfaces,jbpm and drools.


                but processdefinition must be bundled with seam app. so i decided to use jbpm seperated from user interface implemented by seam and richfaces. the user interface is configured from files, so we can easily change layout and behaviour.processdefinitions could be dynamically deployed on an upload page. for  jbpm commands we use the commandservicebean. i tried to use internal jbpm of seam application but i got an error on cancelprocess which i could not solve.


                what do you mean with asynchronous?  i found out that saveprocessinstance is really really slow. but i don't know why.


                would be great if we can talk a little bit more on it.


                email is sascha.janz@gmx.net


                regards
                sascha



                ps: my sons name is also leo... :-)


                • 5. Re: jBPM a silent application killer
                  lvdberg

                  Hi,


                  It took us some time to get things working. The application we are (continuously..) developing is Transport related and consists on different modules. Its main core is a DB to persist the domain-modela and to save all changes (using Envers), and to index all text input (using Search). We have different user interface; web based and swing based and to make it a real Decision support system we added Workflow/Drools.


                  What we basically do is assist a operator in taking decsions during the handling of traffic incidents. He receives automatically messages from other organisations or creates a incdient himself. The smart part of the application is to handle each change automatically and to chexck for anomalies or missing data. For this we use audit data; For each DB-save we re-load the previous values and start a process. We support decisions by informing the operator, so he can take additional actions.


                  For this we have designed the difffernt JBPM/DROOLS parts and it  runs very smoothly now. The application is now in the 95% ready stage and we started marketting the product. At tyhe same time we are looking for the missing tools, such as loaders for workflow/decisions. What you state about bundling the definitions is not necessary. You can define the workflows/decsions in components, which makes Seam do the work, however you can also upload the definitions yourself (jBpm has a very nice XML-parser), but you need to write some additional code (the thing we are doing now...)


                  The asynchronous use we have has to do with the way we split up the application. An operator works very, very fast and is not willing tio wait for system output. jBPM is a workflow component and its designers are not really DB-experts, because the DB-interaction is not up for a efficiency award, but that's the price you pay for a generic database layer like Hibernate. We were able to split the advice part from the basic workflow (so things POP-UP after a few seconds through Prime-Growl and Rich-PUSH) and the user is more than happy.


                  When we started with including workflow in our application I was ver sceptic about the performance of jBPM, but - to be honest - it takes a lot of work out of your hands. There are a lot of other components available, but nothing integrates so smoothly as jBPM. The documentation is my main problem. The avialble documentation for the version I am using is a mixture of parts of a scientific paper and a user manual (the designers work, just like me, in a academic environment, so it pretty understandable) and there are not much people using it yet, They are working very hard to get everything at the same Richfaces-SEAM quality level, but it takes some time.


                  Let's be honest we get it for free.


                  Leo





                       

                  • 6. Re: jBPM a silent application killer
                    serkan.s.eskici.online.nl

                    3. Never (I mean never) use the jBPM core to store domain objects/values, Searching for them in the database is very slow (tables are NOT indexed). You can do different things to solve the problem of retrieving processes based on domain object; (a) change some core classes of jBPM (b) add indexes to the tables yourself, (c) add simple "searchtables" which contains the relation between the domain object and the process/task.

                    I don't get it...Why don't you just store the primary key in the Business Proces context and retrieve your Entity Bean with the EntityManager (.find(Class, id)) ?

                    • 7. Re: jBPM a silent application killer
                      lvdberg

                      Hi,


                      look at the way business data is stored in the jBPM context. To retrieve it you need quite an expensive (in efficiency I mean) query, because the tables are NOT indexed. A shortcut with a separate Entity is really more efficient.


                      Just take the jBPM config and see for yourself.


                      Leo

                      • 8. Re: jBPM a silent application killer
                        serkan.s.eskici.online.nl

                        If indexing is what you need, then why don't you add it in the hibernate.cfg.xml file ?

                        • 9. Re: jBPM a silent application killer
                          lvdberg

                          Hi,


                          Look at the way jBPM stores variables and you will see it is not that easy as you think. As long as you have one variable type you can add the stuff you want, but jBPM doesn't work that way. Furthermore jBPM is not the place where you should store object state, but only process state. Hence my remark about helper entities.


                          And last but not least. Just for maintenance reasons: Stick to the out-of-the-box stuff unless you really have a need to adapt.


                          Leo

                          • 10. Re: jBPM a silent application killer
                            pouria62

                            Hi experts I have a problem with overriding persist built in method which i access that by extending from EntityHome. I have 3 xhtml page which we name them A B C.page A is a page that shows the data of fields of table A .from page A we go to page B which we want to data entering for table B and in page B we have an Id field from page A and table B has a foreign key from table A. in page C we show both table A and B fields. now i cannot persist my page B.xhtml and does any body know how to do? thanx

                            • 11. Re: jBPM a silent application killer
                              lvdberg

                              Hi,


                              would you be so kind to start a new Thread for this question?, because your problem doesn't fit in this one, so there is a big possibility your problem stays unsolved.


                              Leo


                              P.S:Also cut and past relevant parts of your code. Although we possibly are experts, we are not paranormally gifted.

                              • 12. Re: jBPM a silent application killer
                                bobos20

                                Hi Leo


                                Did you do any load test on your application? My application uses Task a lot. I have turned jbpm log off, but @StartTask and @BeginTask methods are very slow which take more than 200 ms for each call on our production server (64-bit 4 cpu 2.3 GHz, 6G Ram for jvm) with 100 concurrent users. My aim is 500 concurrent users with one server node. Any suggestion?


                                Thanks
                                Kevin

                                • 13. Re: jBPM a silent application killer
                                  lvdberg

                                  Hi  Kevin,


                                  One of the best kept secrets of Seam is speeding up the bean by bypassing all kind of unnecessary interception. Dan Allen wrote a very interesting piece on this subject.


                                  Using jBPM in combination with Seam has to follow the same rules.


                                  For instance If you have a lot of getters and setters in your beans (for properties in the view), the whole lot will be in- and outjected for every call you make to these gets/sets.


                                  The BypassInterceptor annotation does wonders there and I've seen speed improvements of up to ten times.


                                  If you send me some code, I can take a look at it.


                                  Leo