Skip to main content
The following steps describe how to update the ASEE Flow artifacts on a JBoss AS 7 and Wildfly 8 server in a shared process engine setting. For the entire procedure, refer to the update guide. If not already done, make sure to download the ASEE Flow 7.4 JBoss distribution or ASEE Flow 7.4 Wildfly distribution. In the following instructions $APP_SERVER should be replaced with either jboss or wildfly, depending on the used application server. The update procedure takes the following steps:
  1. Update the ASEE Flow Modules
  2. Update Optional ASEE Flow Modules
  3. Maintain Process Engine Configuration
  4. Maintain Process Applications
  5. Update ASEE Flow 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.
Updated Wildfly VersionThe pre-built ASEE Flow 7.4 distribution ships with Wildfly 8.2.1.Final, whereas 7.3 comes with Wildfly 8.2.0.Final. The patch version of Wildfly contains some security bug fixes and component updates. ASEE Flow 7.4 is supported on Wildfly 8.1 and 8.2 such that an update is not required when migrating from 7.3 to 7.4.Should you want to update Wildfly along with ASEE Flow, perform the following steps either before or after updating ASEE Flow:
  • Copy all your ASEE Flow-related modules from $WILDFLY_HOME/modules to the new Wildfly server’s module-directory.
  • Apply all modifications to Wildfly configuration files such as standalone.xml to the files located in the new Wildfly server’s directory.
  • Undeploy all process applications and copy them to the new Wildfly server’s directory for redeployment.
See the Wildfly 8.2.1.Final release notes for any relevant changes compared to 8.2.0.Final.

1. Update the ASEE Flow Modules

Replace the following modules from the folder $APP_SERVER_HOME/modules/ with their new versions from the folder $APP_SERVER_DISTRIBUTION/modules/:
  • org/camunda/bpm/camunda-engine
  • org/camunda/bpm/$APP_SERVER/camunda-$APP_SERVER-subsystem
  • org/camunda/bpm/model/camunda-bpmn-model
  • org/camunda/bpm/model/camunda-cmmn-model
  • org/camunda/bpm/model/camunda-xml-model
Add or replace (if already present) the following modules:
  • org/camunda/bpm/dmn/camunda-engine-dmn
  • org/camunda/bpm/dmn/camunda-engine-feel-api
  • org/camunda/bpm/dmn/camunda-engine-feel-juel
  • org/camunda/bpm/model/camunda-dmn-model
  • org/camunda/commons/camunda-commons-logging
  • org/camunda/commons/camunda-commons-typed-values
  • org/camunda/commons/camunda-commons-utils

2. Update Optional ASEE Flow Modules

In addition to the core modules, there may be optional artifacts in $APP_SERVER_HOME/modules/ for LDAP integration, ASEE Flow Connect, ASEE Flow Spin, and Groovy scripting. If you use any of these extensions, the following update steps apply:

LDAP Integration

Replace the following modules from the folder $APP_SERVER_HOME/modules/ with their new versions from the folder $APP_SERVER_DISTRIBUTION/modules/, if present:
  • org/camunda/bpm/identity/camunda-identity-ldap

ASEE Flow Connect

Replace the following modules from the folder $APP_SERVER_HOME/modules/ with their new versions from the folder $APP_SERVER_DISTRIBUTION/modules/, if present:
  • org/camunda/bpm/camunda-engine-plugin-connect

ASEE Flow Spin

Replace the following modules from the folder $APP_SERVER_HOME/modules/ with their new versions from the folder $APP_SERVER_DISTRIBUTION/modules/, if present:
  • 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

Groovy Scripting

Replace the following modules from the folder $APP_SERVER_HOME/modules/ with their new versions from the folder $APP_SERVER_DISTRIBUTION/modules/ if present:
  • org/codehaus/groovy/groovy-all

3. Maintain Process Engine Configuration

This section describes changes in the engine’s default behavior. While the change is reasonable, your implementation may rely on the previous default behavior. Thus, the previous behavior can be restored for shared process engines by explicitly setting a configuration option.

Task Query Expressions

As of 7.4, the default handling of expressions submitted as parameters of task queries has changed. Passing EL expressions in a task query enables execution of arbitrary code when the query is evaluated. The process engine no longer evaluates these expressions by default and throws an exception instead. This behavior can be toggled in the process engine configuration using the properties enableExpressionsInAdhocQueries (default false) and enableExpressionsInStoredQueries (default true). To restore the engine’s previous behavior, set both flags to true. See the user guide on security considerations for custom code for details. This is already the default for ASEE Flow versions after and including 7.3.3 and 7.2.8.

User Operation Log

The behavior of the user operation log has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property restrictUserOperationLogToAuthenticatedUsers (default true). To restore the engine’s prior behavior, i.e., to write log entries regardless of user context, set the flag to false. Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API TaskService#getTaskEvents. If you rely on this API method, the previous behavior can be restored by setting the flag restrictUserOperationLogToAuthenticatedUsers to false.

4. Maintain Process Applications

This section describes changes in behavior of API methods that your process applications may rely on.

CMMN Model API

As a consequence of supporting CMMN 1.1, the CMMN model API is now based on the schema of CMMN 1.1. This leads to limitations when editing CMMN 1.0 models. We therefore recommend to migrate your CMMN 1.0 models to CMMN 1.1.

5. Update ASEE Flow Web Applications

Update REST API

The following steps are required to update the ASEE Flow REST API on a JBoss/Wildfly 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. Alternatively, 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/Wildfly instance.

Update Cockpit, Tasklist, and Admin

The following steps are required to update the ASEE Flow web applications Cockpit, Tasklist, and Admin on a JBoss/Wildfly instance:
  1. Undeploy an existing web application with a name like camunda-webapp
  2. Download the ASEE Flow web application archive from our Artifact Repository. Alternatively, 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.war.
  3. Deploy the web application archive to your JBoss/Wildfly instance.
LDAP Entity CachingIt is possible to enable entity caching for Hypertext Application Language (HAL) requests that the ASEE Flow web applications make. This can be especially useful when you use ASEE Flow in combination with LDAP. To activate caching, the ASEE Flow webapp artifact has to be modified and the pre-built application cannot be used as is. See the REST Api Documentation for details.