Activiti Engine Architecture

[skosov]

Dear Colleagues,
I have got a task to implement BPM in a (relatively) big company. I am thinking to use Activiti as a BMP platform but I am hitting some problems which are due to Activiti limitation or lack of my  understanding it. I am asking you to help me with your opinions.
Let consider a task when we need to develop 3 processes/applications A, B, C which are similar by structure but have different business logics. Also I need to develop a single front-end to manage these processes. I understand that provided Activiti-Explorer (AE) is not a complete application to use in real environment but for now let consider that AE will be used as front-end.   These 3 processes A, B, C should be developed, deployed and supported by 3 different independent teams.  In order to manage processes A, B, C from AE all 3 webapps A, B, C should be included in AE classpath or in other words packaged into activiti-explorer.war. Other solution would be to package front-end into each application (A,B,C) war. Non of these solutions look great for me. I need 3 independent web applications A, B, C and one independent front-end web app. Is there any way to implement this using Activiti as platform? 
All opinions are welcome.
Thanks in advance.
Sergey.

[jbarrez]

Sure: point another Activiti engine to the same database as the one in AE and you can access all the data. Use that engine in your other user interface.

[pmsevestre]

I´ve faced more or less the same challenge you´ve tasked with and our team have come up with the following approach:

1. We developed our own user front-end (very imaginatively named "userfront");
2. We use standard activiti-explorer for admin tasks only (user/group assignment, process deployment, etc).
3. Forms are developed using plain html and/or template languages like velocity, supported by javascript were necessary. Those forms are packed with the process themselves and pulled from there by the front-end.
4. All process-specific data used to support the forms (eg: lookups) use ajax and are routed by the userfront to an ESB (WSO2 ESB in our case)
5. No process-specific jars are deployed in the userfront, ever.
6. Process-specific logic is always coded in groovy (our choice), but we try to limit this code to what we call "glue-logic", meaning code that is mainly used to prepare calls to external web services (SOAP and/or REST-style ones) and/or handle its results. In order to reduce configuration isses, we allways call external services through the ESB
7. Groovy scripts are packed together with the process themselves. We´ve developed a custom deployer and behaviour that extracts the scripts on demand and execute them when the process reaches a "script activity". The custom behaviour was necessary in order to execute an external script instead of the standard behaviour of executing an embedded script. This makes much easier to create standalone projects for each process where the developer can start a standalone engine instance and create scripts using standard Groovy IDE integration, including the hability to set breakpoints, inspect variables, etc
8. Individual process development teams use a maven archetype to quickly setup a new project, which helps a lot in terms of reducing the required time for onboarding new developers.

[jbarrez]

Thanks for sharing this. Really cool setup you have!