Wednesday, February 10, 2016

Activiti 6 adds ad-hoc sub process support

With the first official release of Activiti 6 approaching we have added support for ad-hoc sub processes. It's a feature that shows the strength of the Engine refactoring we have been doing, because it's a fairly simple implementation on an Engine level. Let's have a look at what's possible with ad-hoc sub processes in Activiti 6.

We haven't updated the BPMN editor yet with the ad-hoc sub process symbols and properties, as this is an Engine feature in its current state. But the editor part will be added as well of course. So let's imagine the following embedded sub process to be ad-hoc.

The ad-hoc sub process contains two tasks without any sequence flow being defined. When a process instance is started from this process definition, an ad-hoc sub process execution is created in the Activiti Engine and no user task is created yet. For an ad-hoc sub process you can get a list of enabled activities, which refers to the activities that are available within the ad-hoc sub process to work on. So you can work on Task 1 and Task 2 in any order. With the following API call you can get a list of enabled activities from the Engine.


This gives back a list of FlowNode objects that are enabled in the ad-hoc sub process for which the execution identifier is passed as parameter. In this example there will be two UserTask objects returned by this API call. So you can imagine a UI / application where a user can choose which task to work on next. The API call to start one of these tasks looks like this:

runtimeService.executeActivityInAdhocSubProcess(executionId, id);

So again the execution identifier of the ad-hoc sub process is provided, and in addition an identifier of the user task to select is provided as well. This identifier matches the id attribute of the user task element in the BPMN XML of the process definition. When this call is executed for Task 1 for example, the Activiti Engine will create a new user task, which will be available just like any other user task. 

An ad-hoc sub process by default can execute multiple enabled activities at the same time. This is defined with the ordering attribute in the BPMN XML definition. This means that we could also execute Task 2 in our example, while also having Task 1 active at the same time.

And what happens when Task 1 and/or Task 2 are completed. Without defining a completionCondition attribute in the BPMN XML, the Activiti Engine will not end the ad-hoc sub process execution automatically. The RuntimeService API provides the following method to complete an ad-hoc sub process when there are no active child executions (for example user tasks) anymore:


After invoking this method our example process will continue to the After task activity and the ad-hoc sub process will be ended.

But invoking a method to complete an ad-hoc sub process isn't appropriate for a lot of use cases. So let's look at an BPMN XML example with a defined completion condition.

<adHocSubProcess id="adhocSubProcess" ordering="Sequential">
    <userTask id="subProcessTask" name="Task in subprocess" />
    <userTask id="subProcessTask2" name="Task2 in subprocess" />


There are two differences with the previous example process definition. The first difference is the ordering attribute, which is set to Sequential. This means that only one of the user tasks can be executed at the same time. The Activiti Engine will not allow a second user task to be executed, when the first user task hasn't been completed yet. The second difference is the completion condition. This ad-hoc sub process will be automatically completed when the ${completed} expression evaluates to true. So, when we execute the first user task in the ad-hoc sub process and complete it together with a variable completed of true, the ad-hoc will end automatically after completing the user task.

Until now we have been demonstrating individual user tasks within an ad-hoc sub process only. But it's also possible to define individual task together with flows as well. Let's look at an example process model.

In this example Task 1 and Task 2 are enabled when the ad-hoc sub process is started by the Activiti Engine. So it's not possible to execute the other user tasks yet. When Task 1 is executed and completed, the Next task will be automatically created by the Engine, just like it would happen in a normal flow in a process definition. Using the completion condition, you can still determine when the ad-hoc sub process can be completed. And using the cancelRemainingInstances attribute it's possible to define whether the ad-hoc sub process should cancel any remaining executions / tasks when the completion condition evaluates to true. By default the Activiti Engine will cancel all other running executions / tasks, but when setting this attribute to false, the ad-hoc sub process will not complete before all executions / tasks have been ended.

The Activiti 6 Engine opens up a whole new range of dynamic behaviour in process instances. Because of its well defined execution structure and flexible API, there are a lot of new possibilities to add to the Engine. Ad-hoc sub processes is just an example as you will see more functionality appearing in Activiti 6 in the near future.

You can already play around with the ad-hoc sub process functionality on the activiti6 branch on Github ( We are looking for feedback from the community about this feature and other BPMN related features you would like to see implemented in Activiti 6.

Thursday, November 5, 2015

Activiti 5.19.0 released

Today we have released Activiti 5.19.0! This release provides a new feature that prevents you from needing to redeploy a process definition when you only want to change a service task class name, or a task assignment etc. 

You can also expect a new beta release of Activiti 6 next week, which will bring us one step closer to a production ready release of version 6 of the Engine.

Activiti 5.19.0 has the following highlights.

  • We introduced a new service DynamicBpmnService that allows you to change a defined set of properties of a process definition without needing to redeploy
  • Improved support for the terminate end event. According to the BPMN spec a terminate end event should only terminate the current scope. So in case of a multi instance sub process, a terminate end event inside that multi instance sub process should only kill a single instance and the rest of the instances (of the multi instance) will continue. And in case a call activity kicks off a sub process, a terminate end event in the sub process will only kill the sub process instance, and the parent process will continue. We've added a new attribute on the terminate end event (activiti:terminateAll) that allows you to terminate all parent scopes if the value is set to true. By default only the current scope is killed.
  • ACT-4072 was fixed, a repeating timer (time cycle) now works according to the defined duration values.
  • Various bug fixes.
For more information you can read the release notesEnjoy the release.

Friday, October 23, 2015

Adding dynamic behaviour to the Activiti Engine

We have added a new feature to the Activiti Engine that I would like to share with you even before it's available as part of an official release. The new feature is the ability to change a defined number of properties of a process definition without needing to redeploy the process definition.

Before I'll go into details about this feature, some examples of needing to redeploy a process definition would be good to set the context. One example is a service task with a defined class name in the process definition. This service task is part of a big process definition, and process instances can be active for over a year. After deploying the first version of the process definition to the production environment the requirements of the process execution have changed and a new Java class should be executed for the service task instead. This means that new deployment of the process definition is needed and existing process instances need to be migrated to this new process definition.

Another example is a user task with a candidate group management. Over time, the requirements have changed and the sales group needs to be set as the candidate group for this user task. Again, this would mean a new deployment of the process definition and migration of existing process instances.

With the addition of the DynamicBpmnService interface these use cases can be solved differently, without the need to redeploy the process definition. For example, the DynamicBpmnService interface has a method to change the class name of a specific service task named changeServiceTaskClassName. Let's look at a code example to change the class name of the exampleTask service task.

<serviceTask id="exampleTask" 
  activiti:class="org.activiti.PreviousTask" />

ObjectNode infoNode = dynamicBpmnService.changeServiceTaskClassName(
      "exampleTask", "org.activiti.NewTask");
dynamicBpmnService.saveProcessDefinitionInfo("procDefId", infoNode);

After the invocation of the saveProcessDefinitionInfo method the Activiti Engine will now execute the NewTask class instead of the PreviousTask defined in the BPMN XML. As you can see we are using Jackson JSON for storing the overriding process definition information in the Activiti database. Every process definition can have zero or one entry in the new ACT_PROCDEF_INFO table. All changes for a process definition are defined in the same JSON object and stored as a BLOB in the Activiti database. The cache that's used to retrieve the process definition info data is versioned and designed to work in a clustered Activiti environment.

Let's look at one more example, changing the candidateGroup of a user task:

<userTask id="exampleTask" activiti:candidateGroup="management" />

ObjectNode infoNode = dynamicBpmnService.changeUserTaskCandidateGroup(
      "exampleTask", "sales", true);
dynamicBpmnService.saveProcessDefinitionInfo("procDefId", infoNode);

Again, after saving the JSON object, the Activiti Engine will use the sales candidate group for the exampleTask user task instead of the management group.

If you want to override multiple properties of a specific process definition in different steps you need to get the currently stored JSON object first. This is easy to do like this:

ObjectNode infoNode = dynamicBpmnService.getProcessDefinitionInfo("procDefId");

These are the properties we currently support to change with this approach:

  1. Service task - class name
  2. Service task - expression
  3. Service task - delegate expression
  4. User task - name
  5. User task - description
  6. User task - due date
  7. User task - priority
  8. User task - category
  9. User task - form key
  10. User task - assignee
  11. User task - owner
  12. User task - candidate users
  13. User task - candidate groups
And there's an additional feature we have implemented with the same approach, which is localisation. It's now possible to store the user task name and description in multiple languages in the process definition info table and when you query for tasks you can set a locale to use. The returned tasks will then contain the localised name and description as defined in the process definition info table. Let's look at an example:

<userTask id="exampleTask" name="Name" />

ObjectNode infoNode = dynamicBpmnService.changeLocalizationName(
      "es", "exampleTask", "Nombre");
dynamicBpmnService.saveProcessDefinitionInfo("procDefId", infoNode);

Task task = taskService.createTaskQuery().locale("es").singleResult();

The returned task instance will now have Nombre as the name of the task.

We are really excited about this new feature that's available in both the Activiti 5 and 6 code that's in Github, and we are eager to get feedback about this new feature. Let us know what you think about it and maybe come up with suggestions of which properties we could add to this approach in addition to the current supported list. We'll do a 5.18.1 release in a couple weeks time, together with a new beta release for Activiti 6, that will include this feature. And you can already create your own build using the code on Github of course.

Monday, September 7, 2015

Getting started with the new Activiti 6 UI

We launched Activiti 6 with a new UI that replaces the Vaadin based Activiti Explorer application. The new UI is written in AngularJS and contains a number of new features that we'll introduce in this article.

But let's first get started with download the Activiti 6 beta package from the Activiti website: The package contains the JAR files files of the different Activiti modules including the Engine JAR file. It also contains the userguide, javadocs, readme files, database scripts and the two WAR files for the REST application and the new Angular web application (the focus of this article).

So when you downloaded and unzipped the Activiti 6 package, copy the wars/activiti-app.war file to a local Tomcat 7 or 8 installation. Before you start Tomcat, first the database needs to be taken of. By default, the application is configured for a MySQL database with name activiti6ui and username/password alfresco/alfresco. If you would like to change the database settings you can change the WEB-INF/classes/META-INF/activiti-app/ file in the activiti-app.war file or create a copy of this file in the Tomcat lib folder. By default the H2 and MySQL database drivers are provided by default with the activiti-app.war file, so if you want to use another database, make sure you copy the database driver to the WEB-INF/lib folder.

Now we're ready to start the Tomcat server. The database tables will be created automatically using Liquibase. When the Tomcat server is started you can open a web browser to http://localhost:8080/activiti-app and you should get a login screen. The default username/password is The dashboard page is now presented, showing the Kickstart (editor), Task and Identity management apps.

If you would like to create addition user and/or groups you can do this in the identity management application. But we'll go ahead with designing a simple process using the Kickstart app. You can see there are three main editor types supported, processes, forms and apps. Let's start with the process type and create a new process using the BPMN editor.

The BPMN editor hasn't changed so much when compared with the editor we shipped as part of the Activiti Explorer application. The main difference is that we added integration with the form editor. So let's add a form to the start event to be able to fill-in a BPM related buzzword. Click on the start event and select the Referenced form property.  A popup will be shown where you can select a form, but since we started with an empty database, no forms will be available yet. So click New form, and fill-in a name and an optional description to create a new form. The form editor will be opened and you can start dragging form fields to the canvas to create a start form.

There are a number of field types to choose from and you can also change the outcome buttons of the form. The default outcome button is Complete, if no other outcomes are defined. For this simple example, we only use a text field with label Buzzword. The value of this text field will be available in the process with variable name buzzword (the identifier of the form field, which can be defined in the configuration of the field).

Let's continue with defined sequence flow conditions for all three flows that are outgoing of the exclusive gateway. You can for example use the following conditions:

  1. ${buzzword == 'BPMN'}
  2. ${buzzword == 'BPEL'}
  3. empty, select default flow for this sequence flow.
Now let's configure the Great buzzword user task and define the assignment.

In addition to the static values and expressions you could fill-in in the previous BPMN editor version, you can now directly reference a group or a user you defined in the identity management application. You can also assign the task to the process initiator, and that's what we'll do for this process.

We also have to define a task form, to give feedback to the user. The value of the buzzword text field can be used to show a display text field like shown in the image.

You can add similar task forms to the other two user tasks to complete the process design. The next step is to create an app definition using the app editor. When you create a new app definition, you can define the icon, theme color and processes you would like to include in the app definition.

All the processes included will be available as part of the app, so it's basically a categorisation of processes. When you save the app definition, make sure you select the publish checkbox as well, so the app will be deployed to the Activiti Engine. In addition, you can choose to share the app definition with other user and/or groups and all users that are included there, will have the option to add the app to their dashboard.

When the app is published you'll notice that the app and process are automatically versioned. This ensures that there's always an exact version to point back to from a deployed application and process model. Go back to the dashboard by clicking on the Alfresco Activiti logo in the left top. You can add the newly deployed app to your dashboard by clicking the + button in the grey rectangle and choosing the app in the popup and clicking the Deploy button. The app is available in the dashboard now.

When opening the Buzzword app, a view with a task and process section is shown. We can now start a new process instance of the Buzzword process by filling in a buzzword.

After starting the process with buzzword BPMN, a new process instance is created and the Great buzzword user task is available.

There are a lot of options you can explore in the process instance details view and task view. For example, there's the possibility to show the process diagram.

But also the possibility to add comments to a running process or task. In the task details view, you can fill-in and complete the form, but also involve other people in the task and add file attachments. Take your time to explore and tryout these options and let us now if you think we should add specific actions and/or information.

There's a lot more to talk about regarding the new Activiti 6 UI, but this should be sufficient for a first introduction. Let us know what you think, this should be the start of great new UI to work with the Activiti Engine and we are looking for feedback on how to improve it.

Wednesday, September 2, 2015

Activiti 6 Beta 1 released

Today is a big day for the Activiti project and community. We released the first beta of the first major revision of the Activiti Engine.  The main reasons to introduce Activiti 6 are:

  • Complete backwards compatibility with version 5: database-wise, concept-wise and code-wise.
  • Rewrite of the core engine: direct execution of BPMN 2.0 (vs transformation to intermediate model)
  • Simpler and cleaner runtime execution data structure, where predictability of the structure is crucial
  • Decoupling of persistence layers for future possible different implementations
We also introduce a new test application to work with the Activiti Engine, that replaces the Vaadin Explorer application. The new application is just named Activiti app and uses Angular JS. It contains a lot of the Explorer functionality but there are some differences:
  • We introduced a new form editor that allows you to design task and start forms using a visual editor. There are also quite a couple of additional form field types.
  • There's a new task UI to start process instances and work with tasks.
  • There's a new concept of app definitions. App definitions is a grouping of process models and forms that can be deployed on the Activiti Engine. Each deployed app can be made available on the user dashboard.
We very much welcome any feedback on this first beta release and in specific testing the Activiti 5 backwards compatibility with your process definitions would be great. 

A couple of standard warnings about a beta release. It's not meant to be used in production and we didn't focus on performance yet.

We'll do more blog posts in the next days and weeks to talk about more details of Activiti 6. In the meantime please give feedback and help to get Activiti 6 stable and well tested!

Monday, August 10, 2015

Activiti Designer 5.18.0 released

Today we released Activiti Designer 5.18.0. This release contains the following highlights:
  • Updates to BPMN palette with support for compensation and cancel events and transaction sub processes. We also added missing signal and message event elements.
  • The Activiti Designer now supports Eclipse Kepler and Luna. Let us know if you want us to support Eclipse Luna and Mars instead.
  • Better handling of pools and lanes and sub processes with move and resizing. Bendpoints are moved on resize and move of containers as well.
  • Messages and signals are now defined on process root level and can be selected for message and signal events.
  • Internationalisation support for element labels. You can define multiple languages in the Eclipse preferences and label fields will be made available for each language.
  • Lots of bug fixes.
This release has been long overdue and we'll make sure to keep updates coming on a lot faster schedule starting from this release. Help in raising bugs, thinking of feature requests and of course pull request are very welcome.

Friday, July 31, 2015

Activiti 5.18.0 released

Today we have released Activiti 5.18.0! We are really happy to provide the new bulk insert and other improvements to the Activiti Engine starting from today. 

This release took a bit longer than expected because we have been working on Activiti 6 in parallel. We announced Activiti 6 on our well attended Paris community event. We expect to ship an alpha release of Activiti 6 at the end of August.

You can also expect a new release of our Activiti Designer in the next couple of weeks. 

So what's new in Activiti 5.18.0?

  • We enhanced the OR query support, it's now possible to use multiple OR parts in one query
  • Improvements to the async executor we introduced in Activiti 5.17.0. There were some cases that could result in deadlock exceptions and that's resolved in this version.
  • Improvements to the Activiti Modeler with terminate end events, cancel event and transaction support, and more intermediate catch and throw event support. Also, improvements to interrupting and non-interrupting solid and dashed line for boundary events.
  • Upgraded Spring dependency version to 4.1. Activiti is still working with Spring 4.0.x and 3.x as well.
  • Various bug fixes
For more information you can read the release notes.

Enjoy the release.