Migration Guide

Overview

Migrating an existing application from Activiti 5.x (or camunda fox 6.x - see below) is straightforward. This page describes the necessary steps.

Getting Help: If you have any trouble, ask for assistance in the Forum.

The changes in short are:

  • Maven Dependencies, e.g. activiti.jar changed to camunda-engine.jar.
  • Package Names changed from org.activiti to org.camunda.bpm for all modules (including engine, cdi and spring).
  • The configuration file changed from activiti.cfg.xml to camunda.cfg.xml.
  • A couple of (internal) classes are renamed - see the lists below.

There are some things which have not changed yet:

  • Database schema and table names. Note that we based our fork on Activiti 5.11 and the tables existent in that version.
  • The camunda: Custom Extensions are kept. A camunda BPM namespace will be introduced soon but backwards compatibility will be ensured.

Migrate to 5.11

We based our fork on the database schema of Activiti 5.11. So please upgrade your project to this database using the upgrade scripts provided by Activiti. If you are using a newer version, best ask for assistance in the Forum.

Exchange Library

Exchange the existing library (here shown as Maven dependency)

<dependency>
  <groupId>org.activiti</groupId>
  <artifactId>activiti</artifactId>
  <version>5.11</version>
</dependency>

to

<dependency>
  <groupId>org.camunda.bpm</groupId>
  <artifactId>camunda-engine</artifactId>
  <version>7.0.0-Final</version>
</dependency>

Make sure that you have the camunda Maven Repository set correctly:

<repository>
  <id>camunda-bpm-nexus</id>
  <name>camunda Maven Repository</name>
  <url>https://app.camunda.com/nexus/content/groups/public</url>
</repository>

Adjust package names

Just do an Organize Imports in your IDE, that should do the trick as the API class names have not changed. Your IDE should figure out the rest for you. For Eclipse this can be done by clicking on the project and hitting Ctrl-Shift-O.

component Activiti class name camunda class name
engine ActivitiException ProcessEngineException
ActivitiClassLoadingException ClassLoadingException
ActivitiOptimisticLockingException OptimisticLockingException
ActivitiTaskAlreadyClaimedException TaskAlreadyClaimedException
ActivitiWrongDbException WrongDbException
ActivitRule ProcessEngineRule
ActivitiTestCase ProcessEngineTestCase
PluggableActivitiTestCase PluggableProcessEngineTestCase
AbstractActivitiTestCase AbstractProcessEngineTestCase
ResourceActivitiTestCase ResourceProcessEngineTestCase
spring ActivitiComponent ProcessEngineComponent
SpringActivitiTestCase SpringProcessEngineTestCase
cdi ActivitiCdiException ProcessEngineCdiException
ActivitiExtension ProcessEngineExtension
CdiActivitiTestCase CdiProcessEngineTestCase

That's it - now your application should run again.

Overview

Reading the Guide
Throughout this guide we will use a number of variables to denote common path names and constants:
  • $DATABASE expresses the target database platform, e.g. DB2, MySql etc.
  • $DISTRIBUTION_PATH represents the path of the downloaded pre-packaged camunda BPM distribution, e.g. camunda-bpm-tomcat-$PLATFORM_VERSION.zip or camunda-bpm-tomcat-$PLATFORM_VERSION.tar.gz for Tomcat etc.
  • $PLATFORM_VERSION denotes the version of the camunda BPM platform you want to install, e.g. 7.0.0.
  • $FOX_HOME points to the camunda fox server main directory.
  • $FOX_VERSION denotes the version of the camunda fox platform you have installed, e.g. 6.2.4.

As camunda fox included the Activiti engine you have to perform the above steps as well.

Before you can start with the migration from camunda fox to camunda BPM, we recommend that you download the pre-packaged distribution corresponding to your camunda fox server.

Migrate your Process Application

To migrate your process application from camunda fox to camunda BPM, you need to follow these steps:

  • Do the Activiti migration as described above, as camunda fox included the Activiti engine.
  • Remove the fox-platform-client.x.jar from your deployment - it is not needed anymore.
  • Add a Process Application Class, see Process Applications.
  • If you don't use our engine as embedded jar, you should set your maven-dependency for it to provided-scope
  • Adjust the processes.xml to the new format, see Process Applications.
  • If you completely migrate to our new distro you have to adjust your persistence.xml from FoxEngineDS to ProcessEngine
  • If you use the new camunda Tasklist component you have to adjust the formKey, as described in the Getting Started section. We will provide more information soon. For JSF-Formkeys your formkey should have the following format: /<application-context-path>/<form>.jsf. E.g.: /loan-approval/request-loan.jsf
  • If you use the fox.taskForm bean as described in Add forms to your Process Application, you have to make sure to have the camunda-engine-cdi dependency on your classpath:

    <dependency>
      <groupId>org.camunda.bpm</groupId>
      <artifactId>camunda-engine-cdi</artifactId>
      <version>$PLATFORM_VERSION</version>
    </dependency>
  • If you use @Inject with TaskForm, you have to add a @Named("...") annotation to the @Inject annotation due to backward-compatibility of fox.taskForm. There you have two choices: If you are using fox.taskForm in your process application and don't want to update all your jsf pages and beans you should use @Named("fox.taskForm"), otherwise you should use @Named("camundaTaskForm"). Your application server should write an error or a warning if you use the wrong one. So be careful! However, we recommend you to use the annotation @Named("camundaTaskForm").
  • Since camunda BPM 7.0, the unique constraint for the business key has been removed in the runtime and history tables and the database schema create and drop scripts. The migration scripts do not include the drop statements of the unique constraint for the business key. So if you do not rely on the unique constraint for the business key, you can delete the unique constraint yourself. See the following documentation about the Business Key to delete the unique constraint corresponding to your database.
  • If you do a JNDI lookup to get one of the Platform Services (i.e. ProcessArchiveService or ProcessEngineService), you have to adjust the JNDI name to do the lookup as follows:
    • ProcessArchiveService:
      • Old JNDI name: java:global/camunda-fox-platform/process-engine/PlatformService!com.camunda.fox.platform.api.ProcessArchiveService
      • New JNDI name: java:global/camunda-bpm-platform/process-engine/ProcessApplicationService!org.camunda.bpm.ProcessApplicationService
      • Note: The name of ProcessArchiveService has changed to ProcessApplicationService.
    • ProcessEngineService:
      • Old JNDI name: java:global/camunda-fox-platform/process-engine/PlatformService!com.camunda.fox.platform.api.ProcessEngineService
      • New JNDI name: java:global/camunda-bpm-platform/process-engine/ProcessEngineService!org.camunda.bpm.ProcessEngineService
component camunda fox class name camunda BPM class name
fox-platform-api ProcessArchiveService ProcessApplicationService
fox-platform-client ProcessArchiveSupport DefaultEjbProcessApplication

Migrate your Database

Be aware that there were major changes in our database structure. For migration from camunda fox EE 6.2 and camunda fox CE 1.34 we recommend a look at our migration scripts which are located in the following folder of your downloaded pre-packaged distribution: $DISTRIBUTION_PATH/sql/upgrade. To perform the migration of your database choose the corresponding upgrade script $DATABASE_engine_6.2_to_7.0 according to your database platform and run it.

Migrate the Server

JBoss AS 7.1.3

Upgrade the application server modules (JBoss)

  • Delete the following folders:
    • $FOX_HOME/modules/com/camunda/
    • $FOX_HOME/modules/org/bouncycastle/
    • $FOX_HOME/modules/org/livetribe/
  • Merge all content from $DISTRIBUTION_PATH/modules to $FOX_HOME/modules

Adjust the $FOX_HOME/standalone/configuration/standalone.xml

Change the camunda jboss subsystem as extension from:

<extension module="com.camunda.fox.platform.fox-platform-jboss-subsystem"/>

to:

<extension module="org.camunda.bpm.jboss.camunda-jboss-subsystem"/>

Remove the global modules:

<global-modules>
    <module name="com.camunda.fox.platform.fox-platform-api" />
    <module name="com.camunda.fox.engine.fox-engine" />
</global-modules>

and add the global module for camunda BPM:

<global-modules>
    <module name="org.camunda.bpm.camunda-engine" slot="main"/>
</global-modules>

Adjust the camunda jboss subsystem configuration from:

<subsystem xmlns="urn:com.camunda.fox.fox-platform:1.1">

to:

<subsystem xmlns="urn:org.camunda.bpm.jboss:1.1">

Add authorizationEnabled and jobExecutorDeploymentAware properties to the configured process engines:

<process-engines>
  ...
  <process-engine name="${YOUR_PROCESS_ENGINE_NAME}">
    ...
    <properties>
      ...
      <property name="authorizationEnabled">true</property>
      <property name="jobExecutorDeploymentAware">true</property>
    </properties>
  </process-engine>
  ...
</process-engines>

Since camunda BPM 7.0 you can configure built-in process engine plugins, for more details see this section.

Replace the camunda fox webapps with camunda BPM webapps (JBoss)

  • Undeploy the following camunda fox webapps which are in the folder $FOX_HOME/standalone/deployments:
    • fox-cockpit-$FOX_VERSION.war
    • fox-cycle-$FOX_VERSION.war
    • fox-tasklist-$FOX_VERSION.war
  • Deploy the following camunda BPM webapps from $DISTRIBUTION_PATH/server/jboss-as-7.1.3.FINAL/standalone/deployments to $FOX_HOME/standalone/deployments:
    • camunda-cycle-jboss-$PLATFORM_VERSION.war
    • camunda-engine-rest-$PLATFORM_VERSION.war
    • camunda-webapp-jboss-$PLATFORM_VERSION.war
  • You can delete the corresponding Cockpit tables because they are not needed anymore.

For more details about installing the camunda BPM webapps read the installation guide.

GlassFish 3.1

Clean up the $FOX_HOME/glassfish/domains/<domain>/config/domain.xml

Remove the following applications:

<application
  location="${com.sun.aas.instanceRootURI}/applications/fox-platform-jobexecutor-rar/"
  name="fox-platform-jobexecutor-rar" object-type="user">
  ...
</application>

<application
  context-root="/cockpit"
  location="${com.sun.aas.instanceRootURI}/applications/fox-cockpit-glassfish-$FOX_VERSION/"
  name="fox-cockpit-glassfish-$FOX_VERSION" object-type="user">
  ...
</application>

<application
  context-root="/cycle"
  location="${com.sun.aas.instanceRootURI}/applications/fox-cycle-glassfish-$FOX_VERSION/"
  name="fox-cycle-glassfish-$FOX_VERSION" object-type="user">
  ...
</application>

<application
  context-root="/tasklist"
  location="${com.sun.aas.instanceRootURI}/applications/fox-tasklist-$FOX_VERSION/"
  name="fox-tasklist-$FOX_VERSION" object-type="user">
  ...
</application>

and the corresponding application references:

<application-ref ref="fox-platform-jobexecutor-rar" virtual-servers="server"></application-ref>

<application-ref ref="camunda-fox-platform" virtual-servers="server"></application-ref>

<application-ref ref="fox-cockpit-glassfish-$FOX_VERSION" virtual-servers="server"></application-ref>

<application-ref ref="fox-cycle-glassfish-$FOX_VERSION" virtual-servers="server"></application-ref>

<application-ref ref="fox-tasklist-$FOX_VERSION" virtual-servers="server"></application-ref>

To adjust the JDBC Connection Pool and JDBC Resource replace the following JDBC resource:

<jdbc-resource pool-name="FoxEnginePool"
               jndi-name="jdbc/FoxEngine"
               enabled="true">
</jdbc-resource>

with:

<jdbc-resource pool-name="FoxEnginePool"
               jndi-name="jdbc/ProcessEngine"
               enabled="true">
</jdbc-resource>

and:

<resource-ref ref="jdbc/FoxEngine"></resource-ref>

with:

<resource-ref ref="jdbc/ProcessEngine"></resource-ref>

Adjust the configuration of the Thread Pool for the Job Executor from:

<resources>
  ...
  <resource-adapter-config
    thread-pool-ids="platform-jobexecutor-tp"
    resource-adapter-name="fox-platform-jobexecutor-rar">
  </resource-adapter-config>

  <connector-connection-pool
    name="platformJobExecutorPool"
    resource-adapter-name="fox-platform-jobexecutor-rar"
    connection-definition-name="com.camunda.fox.platform.jobexecutor.impl.ra.outbound.PlatformJobExecutorConnectionFactory"
    transaction-support="NoTransaction">
  </connector-connection-pool>

  <connector-resource
      enabled="true"
      pool-name="platformJobExecutorPool"
      jndi-name="eis/PlatformJobExecutorConnectionFactory" />
  ...
</resources>
...
<servers>
  <server>
    ...
    <resource-ref ref="eis/PlatformJobExecutorConnectionFactory"></resource-ref>
    ...
  </server>
</servers>

to:

<resources>
  ...
  <resource-adapter-config
    enabled="true"
    resource-adapter-name="camunda-jobexecutor-rar"
    thread-pool-ids="platform-jobexecutor-tp" >
  </resource-adapter-config>

  <connector-connection-pool
      enabled="true"
      name="platformJobExecutorPool"
      resource-adapter-name="camunda-jobexecutor-rar"
      connection-definition-name=
          "org.camunda.bpm.container.impl.threading.jca.outbound.JcaExecutorServiceConnectionFactory"
      transaction-support="NoTransaction" />

  <connector-resource
      enabled="true"
      pool-name="platformJobExecutorPool"
      jndi-name="eis/JcaExecutorServiceConnectionFactory" />
  ...
</resources>
...
<servers>
  <server>
    ...
    <resource-ref ref="eis/JcaExecutorServiceConnectionFactory"></resource-ref>
    ...
  </server>
</servers>

Upgrade the application server modules (GlassFish)

  • Delete the following modules from the folder $FOX_HOME/glassfish/lib/:
    • fox-engine-$FOX_VERSION.jar
    • fox-platform-api-$FOX_VERSION.jar
  • Merge all content from $DISTRIBUTION_PATH/modules/lib into $FOX_HOME/glassfish/lib/
  • Delete the following applications from $FOX_HOME/glassfish/domains/<domain>/applications/:
    • camunda-fox-platform
    • fox-cockpit-glassfish-$FOX_VERSION
    • fox-cycle-glassfish-$FOX_VERSION
    • fox-platform-jobexecutor-rar
    • fox-tasklist-$FOX_VERSION
  • Copy the jobexecutor resource adapter $DISTRIBUTION_PATH/modules/camunda-jobexecutor-rar-$PLATFORM_VERSION.rar to $FOX_HOME/glassfish/domains/<domain>/autodeploy. The jobexecutor resourse adapter has to be deployed first because the artifact camunda-glassfish-ear-$PLATFORM_VERSION.ear depends on it and cannot be deployed successfully without the resource adapter. If you try to deploy both components with the auto-deploy feature in one step you should be aware that in that case the deployment order is not defined. Due to this we propose to startup the GlassFish to initially deploy the jobexecutor resource adapter. After a successful startup shutdown the GlassFish.
  • Copy the artifact $DISTRIBUTION_PATH/modules/camunda-glassfish-ear-$PLATFORM_VERSION.ear to $FOX_HOME/glassfish/domains/<domain>/autodeploy.
  • After a successful startup the camunda BPM platform is installed.

Since camunda BPM 7.0 you can configure built-in process engine plugins, for more details see this section.

Replace the camunda fox webapps with camunda BPM webapps (GlassFish)

  • The camunda fox webapps have been already deleted in the previous steps. So you can additionally clean up the $FOX_HOME/glassfish/domains/<domain>/autodeploy/ folder and delete the following artifacts:
    • fox-cockpit-glassfish-$FOX_VERSION.war
    • fox-cycle-glassfish-$FOX_VERSION.war
    • fox-tasklist-$FOX_VERSION.war
  • Deploy the following camunda BPMN webapps from $DISTRIBUTION_PATH/glassfish3/glassfish/domains/domain1/autodeploy/ to $FOX_HOME/glassfish/domains/<domain>/autodeploy:
    • camunda-cycle-glassfish-$PLATFORM_VERSION.war
    • camunda-engine-rest-$PLATFORM_VERSION.war
    • camunda-webapp-glassfish-$PLATFORM_VERSION.war
  • You can delete the corresponding Cockpit tables because they are not needed anymore.

IBM WebSphere Application Server

Undeploy camunda fox webapps

  • Open the WebSphere Integrated Solutions Console.
  • Navigate to Applications / Application Types / WebSphere enterprise applications
  • Select fox-cockpit-was-$FOX_VERSION.war and fox-cycle-was-$FOX_VERSION.war and uninstall them.

Upgrade the application server modules (WebSphere)

  • Open the WebSphere Integrated Solutions Console.
  • Navigate to Applications / Application Types / WebSphere enterprise applications
  • Uninstall the camunda platform application camunda-fox-platform
  • Navigate to Resources / Resource Adapters / Resource Adapters
  • Delete the camunda-fox-platform-jobexecutor-RAR resource adapter
  • Navigate to Resources / Asynchronous Beans / Work Managers
  • Delete the camunda-fox-platform-jobexecutor-WM work manager
  • Navigate to Resources / JDBC / Datasources
  • Select the defined data sources for the fox engine
  • Change the JNDI-Name from jdbc/FoxEngine to jdbc/ProcessEngine
  • Shutdown the IBM WebSphere Application Server
  • Open the folder $FOX_HOME/lib/ext/ and delete the following artifacts:
    • fox-engine-$FOX_VERSION.jar
    • fox-platform-api-$FOX_VERSION.jar
  • Now you can install camunda BPM 7.0, to do so, see the installation guide and follow the instructions.

Since camunda BPM 7.0 you can configure built-in process engine plugins, for more details see this section.

Deploy camunda BPM webapps

  • Follow the installation instructions to deploy camunda BPM webapps (like Cycle, Cockpit etc.).
  • Furthermore, you can delete the corresponding Cockpit tables because they are not needed anymore.

Overview

Reading the Guide
Throughout this guide we will use a number of variables to denote common path names and constants:
  • $DATABASE expresses the target database platform, e.g. DB2, MySql etc.
  • $DISTRIBUTION_PATH represents the path of the downloaded pre-packaged camunda BPM distribution, e.g. camunda-bpm-tomcat-$PLATFORM_VERSION.zip or camunda-bpm-tomcat-$PLATFORM_VERSION.tar.gz for Tomcat etc.
  • $PLATFORM_VERSION denotes the version of the camunda BPM platform you want to install, e.g. 7.1.0.

Migrate your Process Application

To migrate your process application from from camunda BPM 7.0 to camunda BPM 7.1, you need to follow these steps:

  • If you use @Inject with TaskForm, you have to add a @Named("...") annotation to the @Inject annotation due to backward-compatibility of camunda.taskForm. There you have two choices: If you are using camunda.taskForm in your process application and don't want to update all your jsf pages and beans you should use @Named("camunda.taskForm"), otherwise you should use @Named("camundaTaskForm"). Your application server should write an error or a warning if you use the wrong one. So be careful! However, we recommend you to use the annotation @Named("camundaTaskForm").

Migrate your Database

For migration from camunda BPM 7.0 to camunda BPM 7.1 we recommend you to take a look at our migration scripts which are located in the following folder of your downloaded pre-packaged distribution: $DISTRIBUTION_PATH/sql/upgrade. To perform the migration of your database choose the corresponding upgrade script $DATABASE_engine_7.0_to_7.1 according to your database platform and run it.

Migrate the Server

JBoss AS 7.1.3 to 7.2.0

Upgrade the JBoss application server

camunda bpm 7.1 ships with a new version of the JBoss AS 7, namely, 7.2.0. The preferred upgrade steps are:

  • copy all your custom modules / subsystems to the new jboss server directory
  • re-add all your custom modifications from the existing $CAMUNDA_HOME/standalone/configuration/standalone.xml to the new one located in the new jboss server directory.
  • copy all deployed datasources to the new jboss server directory
  • undeploy all process applications and copy them to the new jboss server directory for redeployment

Overview

Reading the Guide
Throughout this guide we will use a number of variables to denote common path names and constants:
  • $DATABASE expresses the target database platform, e.g. DB2, MySql etc.
  • $DISTRIBUTION_PATH represents the path of the downloaded pre-packaged camunda BPM distribution, e.g. camunda-bpm-tomcat-$PLATFORM_VERSION.zip or camunda-bpm-tomcat-$PLATFORM_VERSION.tar.gz for Tomcat etc.
  • $PLATFORM_VERSION denotes the version of the camunda BPM platform you want to install, e.g. 7.2.0.

Migrate Process Engine Configuration

Set autoStoreScriptVariables

With 7.2, the default behavior of script variables has changed. Script variables are set in e.g. a BPMN Script Task using a script 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. You can re-enable the legacy behavior by setting the boolean flag autoStoreScriptVariables to true in the process engine configuration.

Alternatively you can migrate your script code by replacing all implicit declarations of process variables in script code with an explicit call to execution.setVariable('varName', 'value').

Migrate your Process Application

No content added yet.

Migrate your Database

For migration from camunda bpm 7.1 to camunda bpm 7.2 we recommend you to take a look at our migration scripts which are located in the following folder of your downloaded pre-packaged distribution: $DISTRIBUTION_PATH/sql/upgrade. To perform the migration of your database choose the corresponding upgrade script $DATABASE_engine_7.1_to_7.2 according to your database platform and run it.

Migrate the Server

No content added yet.

Migrate your cockpit plugins

In the 7.2 version, updated (and unpatched) versions of angular (1.2.16) and bootstrap (3.1.1) are used.
However, those updates bring some breaking changes in some heavily used features, such as JS promises, modal windows and a few more things described in detail below.
You might want to have a look at the angular changelog and the bootstrap migration guide.
First of all, bootstrap.js is not used anymore (it has been replaced by the angular-ui/bootstrap project), only the CSS parts are kept (and they are being rewritten in order to leverage less compilation and avoid unnecessary declarations).

JS promises

The most critical change is probably the way JS promises are implemented/used. If you had something like this in the 7.1 release:

SomeResource.$then(function(response) {
  var bar = response.data.something;
});

in the 7.2 release, it should look like:

// the resource returns an object having "$promise" (which has a method "then")
SomeResource.$promise.then(function(response) {
  // and the response does not have a "data" property
  var bar = response.something;
});

Dialogs / modal windows

Also widely used in the web interfaces, the dialogs (a.k.a. modal windows) were completely rewritten, in the 7.1 release you might have had something like:

// a controller to open the dialog
module.controller('YadaYada', [
        'BimBamBum', '$dialog', '$scope',
function(BimBamBum,   $dialog,   $scope) {
  var dialogInstance = $dialog.dialog({
    // and a controller for the dialog content
    resolve: {
      foo: function() {
        return $scope.foo;
      },
      bar: function() {
        return BimBamBum.bar;
      }
    },
    // for the example, I wrote the dialog controller here
    // but it was generally found in a separate file (could have been "BimBamBum" for instance)
    controller: [
    // here "dialog" is the dialogInstance and "foo" and "bar" are _resolved_ (see above)
            'dialog', 'foo', 'bar',
    function(dialog,   foo,   bar) {
      // ...
    }]
  });

  // and finally, you would have open the dialog...
  dialogInstance.open().then(function() {
    // ...
  });
}];

now, in the 7.2 release - using the angular-ui/bootstrap thingy - you will have something like this:

// a controller to open the dialog
module.controller('YadaYada', [
        'BimBamBum', '$modal', '$scope',
function(BimBamBum,   $modal,   $scope) {
  // calling the "open" method of the "$modal" will create an instance
  $modal.open({
    // and a controller for the dialog content
    resolve: {
      // .. you know what comes here, right?
    },
    // again, for the example, I wrote the dialog controller here
    controller: [
            '$modalInstance', 'foo', 'bar',
    function($modalInstance,   foo,   bar) {
      // ...
    }]
  });
}];

Now.. the bad news is: in some cases, I had to "rewire" the scopes (kind of) but I could not find any rule to describe why and how I did it. Happy debugging! (smile)

Tooltips

Less complicated than the others changes (but still needing some work), in the 7.1 release, you could add tooltips using a "help" attribute like this:

<div class="yada-yada"
     help
     help-text="The text shown when mouse comes over this DIV"
     help-placement="'top'">
  ...
</div>

in the 7.2 release, the attributes would be:

<div class="yada-yada"
     tooltip="The text shown when mouse comes over this DIV"
     tooltip-placement="top">
  ...
</div>

Note the "tooltip-placement" value is not wrapped between single quotes anymore.

Pagers

Pagers need special attention because you might need to adapt some setup and change your HTML. But generally speaking if you have something like this in your 7.1 release:

$scope.pages = {
  size: 10,
  total: 0,
  current: 1
};
// ...
$http.post(Uri.appUri('plugin://base/:engine/incident/count'), params).success(function(data) {
  pages.total = Math.ceil(data.count / pages.size);
});
<div paginator total-pages="pages.total" current-page="pages.current"></div>

Then you will have something like this in the 7.2 release:

$scope.pages = {
  size: 10,
  total: 0,
  current: 1
};
// ...
$http.post(Uri.appUri('plugin://base/:engine/incident/count'), params).success(function(data) {
  pages.total = data.count;
});
<pagination ng-if="pages.total > pages.size"
            class="pagination-sm"
            page="pages.current"
            ng-model="pages.current"
            total-items="pages.total"
            items-per-page="pages.size"
            max-size="7"
            boundary-links="true"></pagination>

Overview

Reading the Guide
Throughout this guide we will use a number of variables to denote common path names and constants:
  • $DATABASE expresses the target database platform, e.g. DB2, MySql etc.
  • $DISTRIBUTION_PATH represents the path of the downloaded pre-packaged camunda BPM distribution, e.g. camunda-bpm-tomcat-$PLATFORM_VERSION.zip or camunda-bpm-tomcat-$PLATFORM_VERSION.tar.gz for Tomcat etc.
  • $PLATFORM_VERSION denotes the version of the camunda BPM platform you want to install, e.g. 7.1.0.

Enterprise Feature

Please note that Patch Level Upgrades will only be provided to enterprise customers, they are not available in the community edition.

Check the camunda enterprise homepage for more information or get your free trial version.

Upgrade your Database

Within a minor version we will not change anything in our database structure. The database structure of all patch releases is backwards compatible to the corresponding minor version.

Upgrade your Server

Depending on the scenario in which the camunda BPM platform is deployed you have to adjust the upgrade process. Please note that the following procedure my differ for cluster scenarios. Contact our support team if you need further assistance.

  • Shut down your server
  • Exchange camunda bpm libraries, tools and webapps (EAR, RAR, Subsystem (JBoss), Shared Libs) - essentially, follow the installation guide for your server.
  • Restart your server