The following steps describe how to update the Camunda artifacts on a JBoss AS 7 server in a shared process engine setting. For the entire migration procedure, refer to the migration guide. If not already done, make sure to download the Camunda 7.2 JBoss distribution.

The update procedure takes the following steps:

1. Update the Camunda 7 modules
2. Configure process engines
3. Configure optional Camunda 7 extensions (optional)
4. Update Camunda web applications

Whenever the instructions are to replace a module, make sure to delete the previous version of the module first to avoid orphan jars.

1. Update the Camunda 7 Modules

Replace the following modules from the folder $JBOSS_HOME/modules/ with their new versions from the folder $JBOSS_DISTRIBUTION/modules/:

• org/camunda/bpm/camunda-engine
• org/camunda/bpm/jboss/camunda-jboss-subsystem
• org/camunda/bpm/model/camunda-bpmn-model
• org/camunda/bpm/model/camunda-xml-model
• org/mybatis/mybatis

If present, also replace the following optional module:

• org/camunda/bpm/identity/camunda-identity-ldap

Add the following modules from the folder $JBOSS_DISTRIBUTION/modules/ to the folder $JBOSS_HOME/modules/:

• org/camunda/bpm/model/camunda-cmmn-model
• org/camunda/commons/camunda-commons-logging
• org/camunda/commons/camunda-commons-utils
• org/camunda/connect/camunda-connect-core
• org/camunda/connect/camunda-connect-http-client
• org/camunda/connect/camunda-connect-soap-http-client
• org/camunda/bpm/camunda-engine-plugin-connect
• org/apache/httpcomponents/httpclient
• org/apache/httpcomponents/httpcore
• commons-codec/commons-codec
• commons-logging/commons-logging
• org/camunda/spin/camunda-spin-core
• org/camunda/spin/camunda-spin-dataformat-json-jackson
• org/camunda/spin/camunda-spin-dataformat-xml-dom
• org/camunda/bpm/camunda-engine-plugin-spin
• com/fasterxml/jackson/core/jackson-core
• com/fasterxml/jackson/core/jackson-databind
• com/fasterxml/jackson/core/jackson-annotations
• com/jayway/jsonpath/json-path
• org/codehaus/groovy/groovy-all
• org/camunda/template-engines/camunda-template-engines-freemarker
• org/freemarker/freemarker

2. Configure Process Engines

Script Variable Storing

As of 7.2, the default behavior of script variables has changed. Script variables are set in e.g., a BPMN Script Task that uses a language such as JavaScript or Groovy. In previous versions, the process engine automatically stored all script variables as process variables. Starting with 7.2, this behavior has changed and the process engine does not automatically store script variables any longer. You can re-enable the legacy behavior by setting the boolean property autoStoreScriptVariables to true for any process engine in the standalone.xml:

<subsystem xmlns="urn:org.camunda.bpm.jboss:1.1">
  ...
  <process-engines>
    <process-engine name="default" default="true">
      ...
      <properties>
        ... existing properties ...
        <property name="autoStoreScriptVariables">true</property>
      </properties>
      ...
    </process-engine>
  </process-engines>
  ...
</subsystem>

As an alternative, process application developers can migrate script code by replacing all implicit declarations of process variables in their scripts with an explicit call to execution.setVariable('varName', 'value').

3. Configure Optional Camunda 7 Modules

In addition, there are modules for Camunda Connect, Camunda Spin, the Freemarker template language and Groovy scripting that extend Camunda 7 functionality. Since all these artifacts add new functionality, the following steps are not required for migration.

Camunda Connect

In order to activate Camunda Connect functionality for a process engine, a process engine plugin has to be registered in $JBOSS_HOME/standalone/configuration/standalone.xml as follows:

<subsystem xmlns="urn:org.camunda.bpm.jboss:1.1">
  ...
  <process-engines>
    <process-engine name="default" default="true">
      ...
      <plugins>
        ... existing plugins ...
        <plugin>
          <class>org.camunda.connect.plugin.impl.ConnectProcessEnginePlugin</class>
        </plugin>
      </plugins>
      ...
    </process-engine>
  </process-engines>
  ...
</subsystem>

Camunda Spin

In order to activate Camunda Spin functionality for a process engine, a process engine plugin has to be registered in $JBOSS_HOME/standalone/configuration/standalone.xml as follows:

<subsystem xmlns="urn:org.camunda.bpm.jboss:1.1">
  ...
  <process-engines>
    <process-engine name="default" default="true">
      ...
      <plugins>
        ... existing plugins ...
        <plugin>
          <class>org.camunda.spin.plugin.impl.SpinProcessEnginePlugin</class>
        </plugin>
      </plugins>
      ...
    </process-engine>
  </process-engines>
  ...
</subsystem>

4. Update Camunda Web Applications

Update Camunda REST API

The following steps are required to update the camunda REST API on a JBoss instance:

1. Undeploy an existing web application with a name like camunda-engine-rest
2. Download the REST API web application archive from our Artifact Repository. Or switch to the private repository for the enterprise version (User and password from license required). Choose the correct version named $PLATFORM_VERSION/camunda-engine-rest-$PLATFORM_VERSION.war.
3. Deploy the web application archive to your JBoss instance.

Update Camunda Cockpit, Tasklist, and Admin

The following steps are required to update the Camunda web applications Cockpit, Tasklist, and Admin on a JBoss instance:

1. Undeploy an existing web application with a name like camunda-webapp
2. Download the Camunda web application archive from our Artifact Repository. Or switch to the private repository for the enterprise version (User and password from license required). Choose the correct version named $PLATFORM_VERSION/camunda-webapp-jboss-$PLATFORM_VERSION.war.
3. Deploy the web application archive to your JBoss instance.