Presentation

PoC code

camunda_poc.zip

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). (warning) 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 



  • No labels

2 Comments

  1. 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).    


  2. 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.

    1. the version control of BPMNs is important for dynamic workflow support, especially for workflows with asynchronous or manual tasks. In this case, the Camunda engine passivates the workflow instances and waits for message injection to resume the instance processes. When a workflow instance is resumed, Camunda is looking for the original workflow (that is the default behavior, but can be changed). If an updated workflow is uploaded and the dynamic uploading process overwrites the old workflow with a new workflow (we need to verify Camunda behaviors based on process id or version), the process instance resume could be failed. So, typically, we add new versions of workflows, not overriding. Then, through a separate purge process, obsolete workflows would be removed by the operators/admins. 
    2. Centralization of workflow storage/distribution is important since we end up uploading many customized workflow packages dynamically. new workflows packages should be distributed to all the Camunda engine instances.
    3. The demo showed how to handle hot-deployment by dropping the new workflow package file into the embedded Tomcat directory. It would better if we automate the workflow uploading via UI or scripts. UI is preferable, e.g., let user to upload the workflow package file thru UI and the UI, on behalf of the user, handles the hot-deployment behind the scene to Camunda engine process instance(s), depending on the Camunda engine deployment scenarios. 

    That is my two cents for now. If I think of additions, I will add. 

    Thanks.