camunda BPM Installation Guide (IBM WebSphere)

Overview

This document will guide you through the installation of camunda BPM and its components on an IBM WebSphere Application Server.

We support the camunda BPM platform for IBM WebSphere Application Server on
  • IBM WebSphere Application Server v 8.0.x
  • IBM WebSphere Application Server v 8.5.x
For older Versions of WebSphere, we only support the camunda BPM engine.

Enterprise Feature

Please note that this feature is only included in the enterprise edition of the camunda BPM platform, it is not available in the community edition.

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

Reading the Guide


Throughout this guide we will use a number of variables to denote common path names and constants.
$WAS_HOME points to the WebSphere application server main directory (typically something like /opt/IBM/WebSphere/AppServer).
$PLATFORM_VERSION denotes the version of the camunda BPM platform you want to install or already have installed, e.g. 7.2.0.
$WAS_DISTRIBUTION represents the downloaded camunda BPM distribution for the WAS, e.g. camunda-ee-ibm-was-$PLATFORM_VERSION.zip.

The distribution is available at the camunda enterprise release page. You will be asked to enter the credentials you received during the trial or subscription process.

Resource Configuration

The camunda BPM platform requires a set of resources that need to be configured at the application server level:

  • One or multiple datasources to be used by the engine(s).
  • A work manager for the job executor.

Define resources in the right scope

In order to perform the steps listed in this guide, make sure you understand the concept of management scopes introduced by the IBM WebSphere Application Server. We assume that resources are defined at the "Node" scope.

JDBC / Datasource Configuration

The camunda BPM engine uses one or multiple process engines. Use your application server management tooling for the configuration of the datasources. The JNDI name of the datasource must be equal to the name used in the datasource-Element of the process engine(s) configured in the bpm-platform.xml file.

Default JNDI Name

The default JNDI name used by the process engine is jdbc/ProcessEngine

The following screenshot shows the configuration of an XA datasource:

Note that you may configure multiple datasources used by different process engine instances. See the User Guide for details.

Configure a WorkManager to be used by the camunda BPM platform jobexecutor

This section explains how you can use the WebSphere Integrated Solutions Console to configure a work manager to be used by the camunda BPM platform jobexecutor. It is recommended to check the manual of the application server for additional details.

Go to Resources / Asynchronous Bean / Work Managers and select the appropriate scope, for example: Cell= Create a new work manager in the scope using the Button New.... Configure the new Work Manager. The following is a selection of sensible default values:

General Properties

Property Default Value Explanation
Name camunda-platform-jobexecutor-WM The name of the Work Manager.
JNDI name

wm/camunda-bpm-workmanager

Default JNDI name for WorkManager.

This setting value is mandatory and must not be changed.

Description "The work manager used by the camunda platform job executor" Describes the work manager. Any value can be used.
Work Request Queue Size 5 Specifies the size of the work request queue. The work request queue is a buffer that holds scheduled work objects and may be a value of 1 or greater. The thread pool pulls work from this queue. If you do not specify a value or the value is 0, the queue size is managed automatically. Large values can consume significant system resources.
Work request queue full action Fail Specifies the action that is taken when the thread pool is exhausted, and the work request queue is full. This action starts when you submit non-daemon work to the work manager. The default value is block but should be changed to "Fail".

Thread Pool Properties

Property Default Value Explanation
Number of alarm threads 2 Specifies the desired maximum number of threads that are used for alarms. The default value is 2.
Minimum number of threads 2 Specifies the minimum number of threads that are available in this work manager. Should not be below "2" since one thread is blocked by the job acquisition. If you configure multiple job acquisitions, the Minimal Size should not be below Nr. of Acquisitions + 1.
Maximum number of threads 4 Specifies the maximum number of threads that are available in this work manager used by the jobexecutor. Should be greater than "Minimum Size".
Thread Priority 5 Specifies the priority of the threads that are available in this work manager.
Growable False Specifies whether the number of threads in this work manager can be increased automatically when the maximum number of threads is reached.The default value is true, but should be changed to "False"

The following screenshot shows an example configuration of the work manager and its thread pool properties.

Install the camunda BPM platform shared libraries

The shared libraries include the camunda engine and some utility JARs. The shared libraries must be visible to both the camunda BPM platform as well as all process applications.

The shared libraries can be found in the lib folder of the distribution:

camunda-ee-ibm-was-$PLATFORM_VERSION.zip
|-- modules/
      |-- lib/  <-- The shared libs
           |-- camunda-engine-$PLATFORM_VERSION.jar
           |-- java-uuid-generator-XX.jar
           |-- mybatis-XX.jar
           |-- joda-time-XX.jar
           |-- ...
      |-- camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear

Copy the shared libraries into a folder, where it can be referenced from your IBM WebSphere Server installation. Next, go to Environment / Shared libraries, choose the correct scope in which your EAR and applications will run and define a new shared library. Name it Camunda. This name is mandatory, except when you modify the deployment.xml which is located inside the camunda BPM platform EAR accordingly. Enter as classpath the path where you have copied the camunda shared libraries, eg. /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/camunda-shared-libs. Enable the Use an isolated class loader for this shared library checkbox. Restart the WebSphere Server after this operation.

Install the camunda BPM platform modules

The camunda BPM platform distribution for IBM WebSphere Application Server includes one module in the modules folder:

camunda-ee-ibm-was-$PLATFORM_VERSION.zip
|-- modules/
      |-- camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear

The camunda-ibm-websphere-ear is a Java EE application enterprise archive (EAR) providing the camunda BPM platform services. It contains an embedded rar module. This camunda-ibm-websphere-rar module is a JCA Resource Adapter providing the jobexecutor service to the camunda BPM platform.

The EAR must be installed to your IBM WebSphere Application Server.

Install the camunda BPM platform Application

In this section, we explain how the camunda-ibm-websphere-ear module can be installed using the WebShere Integrated Solutions Console.

  1. Navigate to the Enterprise Applications page using the navigation path Applications / Application Types / WebSphere enterprise applications.
  2. Click the "Install" Button.
  3. Select the camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear file from the modules folder of the camunda BPM platform for IBM WebSphere Application Server distribution. Click Next.
  4. Select the "Fast Path" install option.
  5. In Step 1, enter an application-name, eg. "camunda-bpm-platform", customize other settings and click "Next".
  6. Continue through Steps 2-4, customize to your liking and finish the installation in Step 4 by clicking "Finish".
  7. Save the configuration.
  8. (optional) Configure location of the bpm-platform.xml file
  9. Start the camunda-bpm-platform application. If this initially fails, try to restart the server. Also make sure the EAR does correctly reference the previously created 'Camunda' shared library. If it doesn't, make sure you have correctly created the shared library as 'Camunda' or assign the 'Camunda' shared library manually after the EAR installation.

Install Optional Camunda Dependencies

This section describes how to install optional Camunda dependencies onto a WebSphere server. None of these are required to work with the core platform.

The following covers the installation of these extensions:

Install Camunda Connect

Add the following artifacts (if not existing) from the folder $WAS_DISTRIBUTION/modules/lib to the Camunda shared library folder:

  • camunda-connect-core-$CONNECT_VERSION.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

In order to activate Camunda Connect functionality for a process engine, a process engine plugin has to be registered in the BPM platform configuration as follows:

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform ... ">
  <process-engine name="default">
    ...
    <plugins>
      ... existing plugins ...
      <plugin>
        <class>org.camunda.connect.plugin.impl.ConnectProcessEnginePlugin</class>
      </plugin>
    </plugins>
    ...
  </process-engine>

</bpm-platform>

Note that this requires a custom bpm-platform.xml file.

Install Camunda Spin

Add the following artifacts (if not existing) from the folder $WAS_DISTRIBUTION/modules/lib/ to the Camunda shared library folder:

  • camunda-spin-core-$SPIN_VERSION.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

In order to activate Camunda Spin functionality for a process engine, a process engine plugin has to be registered in BPM platform configuration as follows:

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform ... ">
  ...
  <process-engine name="default">
    ...
    <plugins>
      ... existing plugins ...
      <plugin>
        <class>org.camunda.spin.plugin.impl.SpinProcessEnginePlugin</class>
      </plugin>
    </plugins>
    ...
  </process-engine>
  ...
</bpm-platform>

Note that this requires a custom bpm-platform.xml file.

Install Groovy Scripting

Add the following artifacts (if not existing) from the folder $WAS_DISTRIBUTION/modules/lib/ to the Camunda shared library folder:

  • groovy-all-$GROOVY_VERSION.jar

Install Freemarker Integration

Add the following artifacts (if not existing) from the folder $WAS_DISTRIBUTION/modules/lib/ to the Camunda shared library folder:

  • camunda-template-engines-freemarker-$TEMPLATE_VERSION.jar
  • freemarker-2.3.20.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

Install Process Applications

After installing an Process Application (PA) in your IBM WebSphere Application Server, which does not include the camunda BPM dependencies, you must assign the previously created "Camunda" shared library with the Process Application deployment. This should only be necessary when you use the "shared" engine deployment approach and not the "embedded" process engine one (aka self-contained Process Application).

Troubleshooting

Defining WebSphere Resources in the right scope

When installing the camunda BPM platform Application, you may see error messages indicating that you are referencing resources from the wrong scope. Make sure you define the resources in the right scope so all components are visible to each other. Make sure you understand the IBM WebSphere management concepts "Cell", "Node" and "Server".

Install the REST API web application

The camunda REST API WAR file resides under webapps/camunda-engine-rest-$PLATFORM_VERSION-was.war in the WAS distribution archive.

In this section we explain how to install the WAR file using the WebSphere enterprise application Wizard provided within the WebSphere Integrated Solutions Console:

  1. Open the WebSphere Integrated Solutions Console.
  2. Navigate to the Applications / Application Types / WebSphere enterprise applications page.
  3. Click the Install Button
  4. The first page of the Wizard opens. Using the File Browser, select the camunda-engine-rest-VERSION-was.war file from the distribution and upload it.
  5. Continue to the next page.
  6. Select the "Fast Path" on the next page.
  7. Step 1. Usually no changes are required.
  8. Step 2. Usually no changes are required.
  9. Step 3. Usually no changes are required.
  10. Step 4. Define a context root for the REST API. We propose to use /engine-rest
  11. Step 5. Usually no changes are required.

After completing the wizard, REST API should be successfully installed on the application server. Don't forget to save your changes to the master configuration. In some situations, you also have to start the web application manually from the Applications / Application Types / WebSphere enterprise applications page.

Install camunda Cockpit and Tasklist

The web application archive that contains camunda Cockpit and Tasklist resides under webapps/camunda-was-$PLATFORM_VERSION.war in the WAS distribution archive.

In this section we explain how to install the WAR file using the Websphere enterprise application Wizard provided by the Websphere Integrated Solutions Console:

  1. Open the Websphere Integrated Solutions Console.
  2. Navigate to the Applications / Application Types / WebSphere enterprise applications page.
  3. Click the Install Button
  4. The first page of the Wizard opens. Using the File Browser, select the camunda-was-VERSION.war file from the distribution and upload it.
  5. Continue to the next page.
  6. Select the "Fast Path" on the next page.
  7. Step 1. Usually no changes are required.
  8. Step 2. Usually no changes are required.
  9. Step 3. Usually no changes are required.
  10. Step 4. Define a context root for the applications. We propose to use /camunda
  11. Step 5. Usually no changes are required.

After completing the wizard, the applications should be successfully installed on the application server. Don't forget to save your changes to the master configuration. In some situations, you also have to start the web application manually from the Applications / Application Types / WebSphere enterprise applications page.

You can check if everything went well by accessing Cockpit and Tasklist via /camunda/app/cockpit and /camunda/app/tasklist or under the context path you configured.

Configuring LDAP for Camunda Cockpit and Tasklist

In order to set up LDAP for the WebSphere distribution, you have to perform the following steps:

Add the LDAP Library

Make sure the camunda-identity-ldap-$PLATFORM_VERSION.jar is present in the shared library 'Camunda' folder.

Adjust the Process Engine Configuration

Edit the file bpm-platform.xml located inside the Camunda BPM enterprise archive at camunda-ibm-websphere-ear-$VERSION.ear/camunda-ibm-websphere-service.jar/META-INF/ and add the LDAP Identity Provider Plugin and the Administrator Authorization Plugin.

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform xmlns="http://www.camunda.org/schema/1.0/BpmPlatform"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.camunda.org/schema/1.0/BpmPlatform http://www.camunda.org/schema/1.0/BpmPlatform ">
  ...
  <process-engine name="default"> ...
    <properties>...</properties>
    <plugins>
      <plugin>
        <class>org.camunda.bpm.identity.impl.ldap.plugin.LdapIdentityProviderPlugin</class>
        <properties>

          <property name="serverUrl">ldap://localhost:4334/</property>
          <property name="managerDn">uid=jonny,ou=office-berlin,o=camunda,c=org</property>
          <property name="managerPassword">s3cr3t</property>

          <property name="baseDn">o=camunda,c=org</property>

          <property name="userSearchBase"></property>
          <property name="userSearchFilter">(objectclass=person)</property>

          <property name="userIdAttribute">uid</property>
          <property name="userFirstnameAttribute">cn</property>
          <property name="userLastnameAttribute">sn</property>
          <property name="userEmailAttribute">mail</property>
          <property name="userPasswordAttribute">userpassword</property>

          <property name="groupSearchBase"></property>
          <property name="groupSearchFilter">(objectclass=groupOfNames)</property>
          <property name="groupIdAttribute">ou</property>
          <property name="groupNameAttribute">cn</property>

          <property name="groupMemberAttribute">member</property>

        </properties>
      </plugin>
      <plugin>
        <class>org.camunda.bpm.engine.impl.plugin.AdministratorAuthorizationPlugin</class>
        <properties>
          <property name="administratorUserName">admin</property>
        </properties>
      </plugin>
    </plugins>
  </process-engine>
</bpm-platform>

The administratorUserName property should contain the user id of the LDAP user you want to grant administrator authorizations to. You can then use this user to log into the webapplication and grant authorizations to additional users.

See our user guide for complete documentation on the LDAP Identity Provider Plugin and the Administrator Authorization Plugin.

Enable Hal Resource caching

If you use LDAP as Indentity Provider, you should consider activating caching of Users and Groups in the camunda webapplication. In order to activate this, add the following configuration to the web.xml file of camunda webapplication (camunda-webapp-was-$PLATFORM_VERSION.war/WEB-INF/web.xml):

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

  <!-- ... -->

  <listener>
    <listener-class>org.camunda.bpm.engine.rest.hal.cache.HalRelationCacheBootstrap</listener-class>
  </listener>

  <context-param>
    <param-name>org.camunda.bpm.engine.rest.hal.cache.config</param-name>
    <param-value>
      {
        "cacheImplementation": "org.camunda.bpm.engine.rest.hal.cache.DefaultHalResourceCache",
        "caches": {
          "org.camunda.bpm.engine.rest.hal.user.HalUser": {
            "capacity": 100,
            "secondsToLive": 900
          },
          "org.camunda.bpm.engine.rest.hal.group.HalGroup": {
            "capacity": 100,
            "secondsToLive": 900
          }
        }
      }
    </param-value>
  </context-param>

  <!-- ... -->

</web-app>

Migrate from Camunda BPM 7.1 to Camunda BPM 7.2

The following steps describe how to upgrade the Camunda artifacts on a WebSphere application 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 BPM 7.2 WebSphere distribution.

The upgrade procedure takes the following steps:

  1. Uninstall the Camunda libraries and archives
  2. Add the new Camunda libraries
  3. Install optional Camunda dependencies
  4. Configure process engines
  5. Create a shared Camunda library
  6. Install the Camunda archive
  7. Install the Camunda BPM web applications
  8. Associate existing applications with shared library

In each of the following steps, the identifiers $*_VERSION refer to the current version and the new versions of the artifacts.

Changing Platform Configuration

Depending on your chosen feature set for Camunda BPM, some of the (optional) migration steps may require to change the configuration of the BPM platform. The Camunda enterprise archive (EAR) contains a default platform configuration. If you want to change this configuration, you can replace it as described in the deployment descriptor reference.

1. Uninstall the Camunda Libraries and Archives

First, uninstall the Camunda web applications, namely the Camunda REST API (artifact name like camunda-engine-rest) and the Camunda applications Cockpit, Tasklist and Admin (artifact name like camunda-webapp).

Uninstall the Camunda EAR. Its name should be camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear. Then, uninstall the Camunda job executor adapter, called camunda-ibm-websphere-rar-$PLATFORM_VERSION.rar. Delete the J2E connection factory and activation specification created for Camunda BPM 7.1.

After stopping the server, delete all Camunda BPM related libraries from the $WAS_HOME/lib/ext directory. These should be:

  • camunda-engine-$PLATFORM_VERSION.jar
  • camunda-bpmn-model-$PLATFORM_VERSION.jar
  • camunda-xml-model-$PLATFORM_VERSION.jar
  • mybatis-$MYBATIS_VERSION.jar
  • java-uuid-generator-$VERSION.jar
  • joda-time-$VERSION.jar
  • slf4j-api-$VERSION.jar

Note that the non-Camunda artifacts may be depended on by other applications.

2. Add the new Camunda Libraries

Camunda BPM 7.2 ships a new installation approach for the Camunda BPM platform on WebSphere. The Camunda BPM libraries are now available through a shared library the server administrator has to create.

Copy the Camunda core modules from the folder $WAS_DISTRIBUTION/modules/lib to a folder that can be referenced from your IBM WebSphere installation when you later create the shared library. In detail, these are the following artifacts:

  • camunda-engine-$PLATFORM_VERSION.jar
  • camunda-bpmn-model-$PLATFORM_VERSION.jar
  • camunda-cmmn-model-$PLATFORM_VERSION.jar
  • camunda-xml-model-$PLATFORM_VERSION.jar
  • mybatis-$MYBATIS_VERSION.jar
  • java-uuid-generator-$VERSION.jar
  • joda-time-$VERSION.jar
  • slf4j-api-$VERSION.jar

If you have been previously using the Camunda LDAP plugin, also copy the following artifact:

  • camunda-identity-ldap-$PLATFORM_VERSION.jar

3. Install Optional Camunda Dependencies

There are artifacts for Camunda Connect, Camunda Spin, the Freemarker template language and Groovy scripting that may optionally be added to the shared library folder. Since all these artifacts add new functionality, the following steps are not required for migration.

Note: The default Camunda configuration file contained by the Camunda EAR automatically activates the newly introduced, optional Camunda dependencies, Camunda Spin and Connect. If you do not use a custom BPM platform configuration as described here and do not intend to do so, you must install the Camunda Spin and Connect core libraries to the shared libraries folder.

Not Using Connect/Spin

If you do not want to use Camunda Connect or Camunda Spin, you cannot use the default BPM platform configuration that is contained in the Camunda EAR. In this case, make sure to change the configuration location as described here. As a starting point, you can copy the default configuration from $WAS_DISTRIBUTION/modules/camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear/camunda-ibm-websphere-service-$PLATFORM_VERSION.jar/META-INF/bpm-platform.xml and remove the <plugin/> entries for the classes ConnectProcessEnginePlugin and SpinProcessEnginePlugin.

Camunda Connect

If Camunda Connect is intended to be used, copy the following library from $WAS_DISTRIBUTION/modules/lib to the Camunda shared library folder:

  • camunda-connect-core-$CONNECT_VERSION.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

If you use a custom BPM platform configuration file, Camunda Connect functionality has to be activated for a process engine by registering a process engine plugin (note that if you use the default configuration, this step is not necessary):

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform ... ">
  <process-engine name="default">
    ...
    <plugins>
      ... existing plugins ...
      <plugin>
        <class>org.camunda.connect.plugin.impl.ConnectProcessEnginePlugin</class>
      </plugin>
    </plugins>
    ...
  </process-engine>

</bpm-platform>

Camunda Spin

If Camunda Spin is intended to be used, copy the following library from $WAS_DISTRIBUTION/modules/lib to the Camunda shared library folder:

  • camunda-spin-core-$CONNECT_VERSION.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

If you use a custom BPM platform configuration file, Camunda Spin functionality has to be activated for a process engine by registering a process engine plugin (note that if you use the default configuration, this step is not necessary):

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform ... ">
  <process-engine name="default">
    ...
    <plugins>
      ... existing plugins ...
      <plugin>
        <class>org.camunda.spin.plugin.impl.SpinProcessEnginePlugin</class>
      </plugin>
    </plugins>
    ...
  </process-engine>

</bpm-platform>

Groovy Scripting

If Groovy is to be used as a scripting language, add the following artifacts to the Camunda shared library folder:

  • groovy-all-$GROOVY_VERSION.jar

Freemarker Integration

If the Camunda integration for Freemarker is intended to be used, add the following artifacts to the Camunda shared library folder:

  • camunda-template-engines-freemarker-$TEMPLATE_VERSION.jar
  • freemarker-2.3.20.jar
  • camunda-commons-logging-$COMMONS_VERSION.jar
  • camunda-commons-utils-$COMMONS_VERSION.jar
  • slf4j-api-$SLF4J_VERSION.jar

4. 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 bpm-platform.xml:

<?xml version="1.0" encoding="UTF-8"?>
<bpm-platform ... ">
  ...
  <process-engine name="default">
    ...
    <properties>
      ... existing properties ...
      <property name="autoStoreScriptVariables">true</property>
    </properties>
    ...
  </process-engine>
  ...
</bpm-platform>

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

5. Create a Shared Camunda Library

Next, start up the server and create a shared library named Camunda for these artifacts. In detail, go to Environment / Shared libraries, choose the correct scope in which your EAR and applications will run and define a new shared library. Name it Camunda. This name is mandatory. Enter as classpath the path where you have copied the Camunda shared libraries, e.g., /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/camunda-shared-libs. Enable the Use an isolated class loader for this shared library checkbox.

JDBC Drivers, DataSource and WorkManager settings stay the same as compared to 7.1.

6. Install the Camunda Archive

Install the Camunda EAR, i.e. the file $WAS_DISTRIBUTION/modules/camunda-ibm-websphere-ear-$PLATFORM_VERSION.ear. During the installation, the EAR will try to reference the previously created Camunda shared library.

As of version 7.2, the Camunda job executor resource adapter (RAR) that you uninstalled in step 1 is part of the Camunda EAR and therefore does not need to be installed separately.

7. Install the Camunda Web Applications

Camunda REST API

The following steps are required to upgrade the Camunda REST API on a WebSphere instance:

  1. Deploy the web application $WAS_DISTRIBUTION/webapps/camunda-engine-rest-$PLATFORM_VERSION-was.war to your WebSphere instance.
  2. Associate the web application with the Camunda shared library.

Camunda Cockpit, Tasklist, and Admin

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

  1. Deploy the web application $WAS_DISTRIBUTION/webapps/camunda-webapp-ee-was-$PLATFORM_VERSION.war to your WebSphere instance.
  2. Associate the web application with the Camunda shared library.

8. Associate Existing Applications with Shared Library

The new shared Camunda library affects process applications as well because the Camunda BPM libraries which are available with 7.1 on the global classpath are gone. In order to make the Camunda libraries available to applications, the Camunda shared library has to be associated with every process application. If this is not done, the applications fail due to missing resources.

LDAP Entity Caching

With 7.2, it is possible to enable entity caching for Hypertext Application Language (HAL) requests that the Camunda web applications make. This can be especially useful when you use Camunda in combination with LDAP. To activate caching, the Camunda webapp artifact has to be modified and the pre-built application cannot be used as is. See the REST Api Documentation for details.