Concept of Process Application

After going through all relevant sections in documentation, i.e. shared engine architecture, section about Process Applications and scripting and skimming through the forum I think I am sufficiently confident that I did not receive answer to following question.

What is exact concept of Process Application? Is it application archive like JAR/WAR etc. made for deployment or also a logical abstrcation entity which must be specified programmatically (like through Java class)?

My confusion about this stems from following facts.

  • Process Application section talks heavily about Servlet or EJB or Spring deployment type and different capabilities.

  • There are references that script engines are by default cached per Process Application.

  • There seems to be no need to define a Process Application (programmatically or through deployment descriptor) if the processes are self sufficient through embedded or even external scripts. Reference.

Could someone please shed light on this? Moreover, if I deploy my processes through REST API/Modeller will a Process Application be created? Or is there a default one always present?

Thanks in advance.

Hi @chaitanyajoshi,

let me try to clarify the term “Process Application”: You need a process application to run a process model on a shared, container managed engine.

Physically it’s a war file that you deploy to your application server, where the Camunda engine is installed as a central library. The process application contains a processes.xml file as deployment descriptor and a class annotated with @ProcessApplication.

The idea behind this is to enable different developer teams to create automated processes and run them on a central engine. In an insurance company this could be an insurance application process and a claim management process and some other processes. The teams can develop thier processes independently from the others but run them on a shared server.

Even a Camunda Spring Boot application can be assumed somehow as a process application, without sharing the common application server.

Hope this helps, Ingo

Thanks a lot @Ingo_Richtsmeier for your reply but it still does not fully answer my question. What happens when I deploy simple processes with embedded scripts (JavaScript or Groovy) directly from Modeller (or using REST API for that matter)? In that case, I do not create any process application explicitly. Then will a process application be internally created for every process diagram that I deploy? Or will they all use the same, some kind of default process application?

Hi @chaitanyajoshi,

if you deploy a process model without reference to other artifacts (Only scripts, included in the model and generated forms), you don’t need a process application.

On the other way, if you deploy a single process model from the modeler, the process instances can not access the java classes implmenting the delegate as they are part of a (now separated) process application.

Internally each process application registers at the shared engine for their deployments. (This registration can be done programatically, but only with the Java API.)

Hope this helps, Ingo

OK. So a process application is a construct/entity that is not mandatory and one can live without it if all the processes are self contained (contain their own forms, scripts) but then such processes do not have access to the full process object model. So it’s a definite trade-off.

On the other hand, when I want to have delegate or execution listener code, I must have a process application irrespective of whether the delegate code is Java or JavaScript (or Ruby, Groovy, Python etc.). Right?

Thanks a lot Ingo. This clears up the air.