-
1. Re: jBPM a silent application killer
yahawari Jun 17, 2010 4:46 AM (in response to lvdberg)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 Jun 17, 2010 5:11 AM (in response to lvdberg)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 Jun 17, 2010 5:46 AM (in response to 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 Jun 24, 2010 6:03 PM (in response to lvdberg)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
saschaps: my sons name is also leo... :-)
-
5. Re: jBPM a silent application killer
lvdberg Jun 25, 2010 3:26 AM (in response to 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. Wesupport 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 aboutbundling
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 Jun 25, 2010 9:49 AM (in response to lvdberg)
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 Jun 25, 2010 9:54 AM (in response to 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 Jun 28, 2010 7:58 AM (in response to lvdberg)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 Jun 28, 2010 8:14 AM (in response to 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 Jan 15, 2011 5:35 AM (in response to lvdberg)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 Jan 15, 2011 8:48 AM (in response to 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 Dec 28, 2011 12:20 AM (in response to lvdberg)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 Dec 28, 2011 3:38 AM (in response to 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