Wednesday, October 5, 2016

Adding dynamic behaviour to the Flowable Engine

We have added a new feature to the Flowable 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" 
  flowable:class="org.flowable.PreviousTask" />

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

After the invocation of the saveProcessDefinitionInfo method the Flowable 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 Flowable 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 Flowable database. The cache that's used to retrieve the process definition info data is versioned and designed to work in a clustered Flowable environment.

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

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

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

Again, after saving the JSON object, the Flowable 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 Flowable 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 Flowable 6, that will include this feature. And you can already create your own build using the code on Github of course.

14 comments:

  1. What about changing the script inside a script task without redeploying?

    ReplyDelete
  2. Good point, will include that as well.

    ReplyDelete
  3. What about creating ad-hoc processes/tasks, ACM so to say?

    ReplyDelete
  4. What about creating ad-hoc processes/tasks, ACM so to say?

    ReplyDelete
  5. This is a really nice feature.
    This could also be interesting for the properties of a mail task, the properties for a timer event and even the signal reference for the signal event.

    ReplyDelete
  6. When is the next official release date? Will it include Spring Boot 1.3+ to take advantage of the new dev tool capabilities?

    ReplyDelete
  7. Thanks for the feedback, I've added sequence flow condition and script task support for the dynamic BPMN functionality. @Tom, your suggestions are welcome as well, and I'll have a look at adding support for it.
    We didn't upgrade to Spring boot 1.3 yet, any help with this would be welcome.

    ReplyDelete
  8. Srinivasan VaradarajanNovember 19, 2015 at 11:03 PM

    This is a great feature for building a process framework where multiple tenants will use a standard process model (a Reference Data pipeline model with ETL like properties, for instance), but each tenant can supply their own variations of the task class implementations.
    Thank you!

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. hello rally good feature. i am new in activiti-explore and i m read many post but i don't have idea how to use it in android app or web app . i am use activiti 5.18 throught rest but it is more hardcoded . can i used these java classes in my android app or have any sdk? please help

    ReplyDelete
  11. Right now, this is a Java API only feature, but we'll add support for the new DynamicBpmnService interface to our REST API as well.

    ReplyDelete
  12. hello i am using the activiti 6ui.
    but here is a problem when i create a workflow through kikstart app
    In user task , from properties attribute , when select type is enum type then not come its value type for choose yes or no ?

    ReplyDelete
  13. palanirajkumar

    hello sir ,
    sir give me the simple program for activiti bpmn restfulservices

    ReplyDelete
  14. This comment has been removed by the author.

    ReplyDelete