BPM (jBPM or Activiti) with Play2.0

mink....@gmail.com

unread,

Jul 13, 2013, 12:29:58 AM7/13/13

to play-fr...@googlegroups.com

I wanted to hear from the Play! users if anyone has experience embedding jbpm or activiti in it. Basically I am trying to see if I can use the designer/modeler directly inside Play!
Please direct me to any writing that may help me integrate (preferably) jbpm or activiti wuth Play.
Thanks you for reading the question (and a bigger thank you if you reply)

mauro.michele

unread,

Jul 15, 2013, 3:43:19 AM7/15/13

to play-fr...@googlegroups.com

We have an application in production (2+ years, >1k users, intranet-only image management, >150k images so far) with Play1 and Activiti.
Integration was not a problem: we set up Activiti as a library, and wrote a small plugin to start it up and manage deployments. Since the integration has nothing to do with Play, our experience is still valuable to you even if we only use 1.

Our main takeaways from this experience are:

1) you must be able to code: you can't embed Activiti (or jBPM) and expect to use the same default tools that come with the distribution. You'll have to code the glue between the library and your application. If you have problems with this, you'll have to rethink your strategy.
2) be careful in mixing your data with the process variables: think carefully about transactions, which db connection Activiti is using, and thing like that. You need to be in control and know what is happening
3) Activiti's data model is not good for querying: if you have to present in the UI lists of open processes or pending tasks, you'll probably need data from the process variables to help the users identify the processes/tasks, and Activiti's data model is not efficient for that type of queries. You'll need your own. It's a bit tricky to keep it in sync, but not difficoult.

When you cover these problems, Activiti will work for you very very well. It's very easy to embed, and does its work without many dependencies.

The designer is a totally different beast: it's only use is to draw processes, so there is very little to integrate; you only need to know where it writes them so you can pick them up. I must advise you however that a process is directly deployable from the designer only in the simplest cases. It depends very much on your domain and expected semantics.

When we started our project our first test was with jBPM5, since we have another BPM application 6 years in production with jBPM3. But we couldn't make the persistence model work inside Play!: Drools requirement for a fully functional JTA configuration was very difficult to manage inside Play!, so we switched to Activiti's much simpler architecture.

Hope this helps,

Michele Mauro

Message has been deleted

D M

unread,

Jul 15, 2013, 11:22:59 PM7/15/13

to play-fr...@googlegroups.com

Thank you for taking out time to reply, it's really helpful.
After reading it I have few more questions
1) If the default tools can't be integrated then won't it be easy to run the business process independently (in activiti or jBPM) and just use the REST APIs? What's your thought on this approach, does it limit us in any way, is it slower etc.
2) If the process is not directly deploy-able from designer than how are processes designed and deployed at your place - do you create them in the designer and then modify things manually?
3) Are you using Scala for integrating Actiiti, if yes then how has your experience been?

Thanks again for replying

mauro.michele

unread,

Jul 17, 2013, 3:39:36 AM7/17/13

to play-fr...@googlegroups.com

Il giorno martedì 16 luglio 2013 05:22:59 UTC+2, D M ha scritto:

Thank you for taking out time to reply, it's really helpful.
After reading it I have few more questions
1) If the default tools can't be integrated then won't it be easy to run the business process independently (in activiti or jBPM) and just use the REST APIs? What's your thought on this approach, does it limit us in any way, is it slower etc.

It can be done, but depends on how much data you have inside your business processes, how frequently and with what parameters you query them to find some instances, and in general the shape of your interaction with the process engine. There are many use cases where this can be done, many in which probably this is the best way to do it. However it wasn't mine, and I can't tell you if it is yours.

2) If the process is not directly deploy-able from designer than how are processes designed and deployed at your place - do you create them in the designer and then modify things manually?

I create them in the designer, check or modify them manually if necessary, and feed them to my uploader/deployer, that calls the deployment API the way I need.