Announcing Mule’s Activiti transport


Hi all!

A couple of weeks ago I started the integration between Mule ESB and Activiti BPMN. Activiti is a Business Process Management () and workflow system targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. It’s open-source and distributed under the Apache license. Activiti is being written from the ground up with the requirement that the engine should be easily embedded and that the project would be aimed at developers not the business. This is a very natural fit for MuleSoft since our approach to middleware starts with the developer. We have been working with the Activiti guys since July focusing in the integration aspects of the project.

The idea behind Mule’s Activiti transport is that you are able to perform several administrative actions in an Activiti server from Mule. For example, let’s suppose that you would like to retrieve the candidate tasks of the user kermit, do some processing and CLAIM a subset of those tasks. The following configuration will work for you:

<activiti:connector name="actServer"
    username="kermit" password="kermit" />

    <service name="Activiti service">
            <activiti:inbound-endpoint activiti-server="actServer">
                <activiti:list-candidate-tasks user="kermit" />

        <component class="org.mule.transport.activiti.SelectTaskComponent" />
                <vm:outbound-endpoint path="out" connector-ref="asynchVm" />
                <activiti:outbound-endpoint activiti-server="actServer" >
                    <activiti:perform-task-operation operation="CLAIM" />

We next describe each part of the configuration, but for those of you who are familiar with Mule, the configuration is pretty straightforward.

Let’s start with the basics; for configuring the transport you need a connector. The connector will hold all the information related with the Activiti server such as server URL, administrative user and password, e.g:

Then you can configure an inbound endpoint for polling information from the Activiti server. For example the following endpoint polls the list of candidate tasks of the user pablo.

Finally, you can execute operations in the outbound endpoints. For example, the following endpoint executes the operation claim over the task that comes inside the message. The payload of the message must be a map which must contain a task id and a operation. If the operation inside the map is null then the default operation configured in the endpoint is used.

For further examples please check the following configuration files in the SVN:

  • activiti-processes-config.xml
  • activiti-tasks-config.xml

You can obtain a snapshot version of the transport from here. Currently the transport has been tested with Mule 2.2.6 and shortly with Mule 3.0.

In future releases we plan to cover more operations that could be perform on the server and let the user provide custom spring beans for operations that are not covered by the implementation.

Looking forward to hearing your comments!

We'd love to hear your opinion on this post

4 Responses to “Announcing Mule’s Activiti transport”

  1. Well, i have one week try integrate with intalio and it was very laborious… i believe try with Activity and compare performance.

  2. Very good start 8th anniversary + Activiti transport , I would like to expect Mule Enterprise edition 3 version.

  3. Like many others I was looking for an easy “how to” about making Activiti work on Ubuntu, I couldnÂ’t find it so I wrote my own. Check my website:



  4. @Alejandro: Good luck with the integration. Activiti is a excellent solution, open source and under active development. Please try it 🙂

    @sasikumar: I’m starting to move Activiti into Mule 3 so stay in touch!

    @Winko: Did you fill a Jira ticket? Please go ahead and give steps to reproduce the problem.