Presentation
PoC code
Running PoC
Install Tomcat with pre-packaged Camunda engine
Follow installation instructions from here: https://docs.camunda.org/manual/7.5/installation/full/tomcat/pre-packaged/
No need for any manual configuration, just unpack it and start Tomcat.
PoC was tested on https://camunda.org/release/camunda-bpm/tomcat/7.11/camunda-bpm-tomcat-7.11.0.tar.gz.
Build PoC code
Maven is needed to build it.
Unzip the PoC package attached above and run mvn clean install from camunda_poc directory.
Run PoC
Copy PoC shared lib to Tomcat lib directory: copy camunda_poc/common_code/target/camunda-poc-common-code-1.0-SNAPSHOT.jar to Tomcat lib directory (server/apache-tomcat-9.0.19/lib). You need to restart Tomcat after this.
Now you can deploy test applications on running Tomcat without restarts:
- copy camunda_poc/test_app1/target/camunda-poc-test-app1.war to Tomcat webapps directory (server/apache-tomcat-9.0.19/webapps).
- do the same thing for test_app2
Go to Camunda Tasklist application (http://localhost:8080/camunda/app/tasklist), click Start process and run App1_process (or any other for that matter).
Observe Tomcat logs in server/apache-tomcat-9.0.19/logs/catalina.out.
You should get output similar to following in the logs:
>>>>>>>>>> App1LocalDelegateBean invoked >>>>>>>>>> App1LocalDelegateBean invoked >>>>>>>>>> App1LocalComponentBean.beanMethod() invoked >>>>>>>>>> COMMON Delegate Bean invoked >>>>>>>>>> COMMON Delegate Bean invoked >>>>>>>>>> COMMON SpringBean.beanMethod() invoked >>>>>>>>>> App1AnotherDelegateBean invoked >>>>>>>>>> App2LocalDelegateBean invoked >>>>>>>>>> App2LocalDelegateBean invoked >>>>>>>>>> App2LocalComponentBean.beanMethod() invoked >>>>>>>>>> COMMON Delegate Bean invoked >>>>>>>>>> COMMON Delegate Bean invoked >>>>>>>>>> COMMON SpringBean.beanMethod() invoked >>>>>>>>>> App2LocalGroovyClass.someMethod() invoked >>>>>>>>>> CommonGroovyClass.someMethod() invoked
Important configuration files
Files crucial for making this PoC work.
processes.xml
This is a Camunda-specific file.
Located in camunda_poc/test_appX/src/main/resources/META-INF/processes.xml.
This tells Camunda engine that this is process application. Camunda will scan these kind of applications and will load all BPMNs found.
applicationContext.xml
This is Spring-specific file.
Located in camunda_poc/test_appX/src/main/webapp/WEB-INF/applicationContext.xml
This file tells Spring to load all required by Camunda beans. It also bootstraps Camunda process application and tells Spring to scan the application for other Spring beans.
web.xml
This is Java EE-specific file (required by Java web applications)
Located in camunda_poc/test_appX/src/main/webapp/WEB-INF/web.xml
2 Comments
Lukasz Grech
There was also a question whether we can pack process applications as Spring boot applications instead of WAR files (if I understood the question correctly). As I commented I don't think that this will work for the deployment I'm proposing.
At least for now I don't see any way that we could mix Spring boot applications with stand-alone Tomcat. As far as I know you can't deploy Spring boot applications on stand-alone Tomcat - I don't even think this is something anyone would want. And for this solution to work all applications have to be managed by the same Tomcat instance. Otherwise it would be impossible for the applications to use shared lib code (i.e. shared Spring beans).
There's another deployment possibility though that Camunda supports called Standalone (Remote) Process Engine Server. Please take a look at the short description here: https://docs.camunda.org/manual/latest/introduction/architecture/#standalone-remote-process-engine-server. This gets more complex but maybe this is something that someone on the meeting had in mind (sorry I didn't get the name).
Byung-Woo Jun
Hi Lukasz and team, it is a great work. For the production quality SO, this feature (dynamic BPMN loading into SO) is much needed. By leveraging this feature, the clients can upload their customized BPM workflows to SO dynamically without recompiling SO components nor bouncing running SO Camunda engine instances. Also, I think this would be a good foundation for SDC workflow design UI to distribute the customized workflows into SO in an automated fashion; i.e.., SDC can push the workflow design into the runtime SO dynamically.
A few comments.
That is my two cents for now. If I think of additions, I will add.
Thanks.